안녕하세요, 채원입니다.
최근 1년간의 업무 방식을 작년과 비교해보자면, 업무 속도 차이의 체감이 꽤 큰 것 같습니다.
기획-디자인-개발의 이어달리기가 무너졌습니다
1년 전 만해도 제 일은 '이어달리기'였습니다. 기획서와 기능명세서를 디자인팀에 넘기면, 디자인팀에서 UI/UX를 잡고, 이후 개발팀에서 개발이 완료될 때까지 기다리는 시간의 연속이었습니다. 그 다음엔 테스트하고, 버그 픽스를 잘 챙기고, 출시해서 고객 반응을 보고... 제가 바통을 넘겨야 다른 단이 뛸 수 있으니 마음이 늘 급하기도 했습니다.
그런데 AI를 본격적으로 활용하기 시작하면서, 이 순차적인 프로세스가 무너졌다고 느낍니다. 바이브코딩 툴을 켜고 아이디어를 던지면, 금방 코드가 돌아가고 화면이 나옵니다. 예전 같으면 디자이너에게 "UI 이렇게 해도 될까요?" 물어보고, 개발팀에 "이 기능 구현 가능할까요?" 물어보며 며칠을 썼을 일입니다. 하지만 지금은 제가 직접 만들어보고 "어, 되네?"하고 검증을 끝냅니다.
기획-디자인-개발이 별개의 단계가 아니라 '하나의 덩어리'로 뭉쳐진 것입니다.
요즘엔 '작동하는 명세서'를 만듭니다
저희 팀은 요즘 이렇게 일합니다. 예전엔 제가 텍스트로 된 기능 명세서를 썼다면, 지금은 직접 AI로 '작동하는 프로토타입'을 만듭니다.
예를 들어, 급하게 '결제수단 변경링크 생성기'를 만들어야 하는 상황이라고 가정해봅시다. 예전이라면 "화면에 이런 문구와 버튼을 배치해서, 고객이 누르면 고유한 결제수단 변경링크가 생성되게 해주세요"라고 문서로 적어 넘겼을 겁니다. 하지만 지금은 다릅니다. 제가 AI에게 API Doc 문서를 주고, 직접 코드를 돌려봅니다. 그리고 개발자에게 이렇게 요청합니다. "제가 대충 이렇게 짜봤어요. 제 의도와 로직이 이 링크처럼 작동하길 원합니다."
이 차이는 엄청납니다. 개발자는 기획서를 해독할 필요가 없어졌거든요. 대신 '움직이는 사양서'를 보고, 보안과 안정성을 고려해서 제대로 된 구조로 다시 짜는 일에 집중할 수 있게 됩니다.
물론, 모든 영역이 그렇지는 않습니다. 기존에 개발자들이 한 땀 한 땀 코딩해서 만든 레거시 제품, 코어 로직 등은 함부로 건들 수 없습니다. 하지만 신규 모듈이나 사내 도구, 검증이 필요한 기능은 '백마디 말보다 한 번의 실행'이 효율적으로 느껴집니다.
'How'가 아니라 'Why'를 증명하자
"개발자도 아닌데 코딩하느라 시간까지 써야하나요?"
사용자의 문제를 정의하는 능력이 여전히 가장 중요합니다.
코딩은 목적이 아니라 수단일 뿐입니다. 이 도구를 사용하는 이유는, 문제를 해결하는 속도를 10배 높이기 위함입니다. 말로 설득하고 회의하는 시간을 아껴서, 빠르게 만들어서 보여주고 "이게 맞나요?"라고 시장에 묻는 것. 그것이 진짜 우리가 해야 할 일이라고 믿기 때문입니다.
그래서 저는 상상하는 기획자/프로덕트 매니저에서, 구조를 설계하는 아키텍트로 진화하기로 했습니다.
그럼 이제는 무엇을 해야할까요?
막막할 분들을 위해, 제가 현장에서 깨달은 현실적인 3가지 팁을 공유합니다.
1. 코딩 '공부'보다 '질문'이 먼저입니다
갑자기 개발자가 되려고 문법책을 파지 마세요. 우리는 코드를 짜는게 아니라, AI에게 일을 시키는 사람입니다. "이거 만들고 싶은데 코드 좀 짜줘"라고 묻고, 그 결과물을 동료에게 보여주는 순간 변화는 시작됩니다. 중요한 건 코드를 직접 짜는 능력이나 문법이 아니라, '명확한 지시'입니다. 문법은 AI 몫으로 남겨두고, 우리는 '의도'에 집중합시다.
2. 쓰레기 코드라도 괜찮습니다. '의도'를 보여주세요.
우리가 짠 코드는 구조도, 보안도 엉망일 겁니다. 상관없습니다. 우리의 목적은 완벽한 코드를 짜거나, 이 코드를 제품에 쓰는게 아닙니다. 개발자에게 '내 기획의 의도'를 오해 없이 전달하기 위해 눈으로 보여주는 것입니다. 백 마디 말로 적힌 문서보다, 작동하는 링크 하나가 텍스트 명세서의 모호함을 없애줍니다.
3. SQL 몰라도 됩니다. '데이터 흐름'만 보세요.
공학적 사고는 복잡한 코드를 짜는게 아닙니다. 입력값과 출력값의 인과관계를 따지는 힘입니다. 예를 들어 "AI에게 1,000원을 입력했는데 왜 결과가 $1,000로 나왔지?"라는 문제가 생겼다고 해봅시다. 이 때 '아 중간에 환율 계산 로직이 빠졌구나'라고 흐름의 구멍을 찾아낼 수 있다면 충분합니다. 데이터가 어디서 들어와서 어떻게 바뀌어 나가는지, 그 흐름을 보는 눈이 곧 설계 능력입니다.
이 모든 변화가 말하는 건, 단 한 가지
결국 이 모든 변화가 말하는 건 하나입니다. 우리가 하는 일의 본질이 '설명'에서 '증명'으로 넘어갔다는 것입니다.
지난 10년간 기획자는 '문서로 설득하는 사람'이었습니다. 실제로 만드는 건 비싸고 오래 걸리니까, 만들기 전에 가급적 합리적이고 납득가는 예측을 해서 남들을 믿게 만들어야 했거든요.
하지만 이제는 아이디어를 눈으로 확인하는 비용이 0원에 수렴합니다. 문서는 '가설'이지만, 코드는 '현실'입니다. 말로 설득할 시간에 만들어서 보여주는 게 더 강력한 설득이 되었습니다. 더 이상 종이 위에서만 설득하려 애쓰지 마세요. 이제 우리는, 우리가 상상한 미래를 증명하기 위한 무기가 널려있으니까요.
당신은 지금 미래를 '예측'하고 있나요, 아니면 '검증'하고 있나요?
물론 '기획의 본질'을 지키는 것은 여전히 중요합니다. 하지만 도구가 바뀌면 본질을 지키는 방식도 달라져야 한다고 믿습니다. 저는 이 변화가 거스를 수 없는 흐름이라 생각합니다. 현장에 계신 여러분은 이 거대한 파도를 어떻게 타고 계신가요? 각자의 치열한 고민과 시도가 궁금하네요. 편하게 이야길 들려주세요 :)
의견을 남겨주세요