🔄 기획서 쓰는 것보다 직접 만드는 게 더 싸진다면?

 

"9일 만에 만들었습니다" — 이 말이 뒤흔드는 것

요즘 IT 업계에서 심심치 않게 들려오는 이야기가 있어요.

농업 핀테크 회사의 한 프로덕트 리더, 펠리페 페르난데스. 그는 위성 데이터를 불러오고 리스크 분석 결과를 보여주는 모니터링 모듈을 개발팀에 견적을 물어봤는데요. 돌아온 답이 "풀타임 개발자 2명, 8~10주"였습니다. 약 800시간에 달하는 작업이었죠.

그런데 2025년 초, 그는 그 모듈을 혼자서, 9일 만에 만들었습니다.

완성도가 완벽한 건 아니었어요. 에러 처리도 부실하고, 오류가 나면 새로고침을 해야 했죠. 하지만 실제 데이터를 불러오고, 실제 계산을 돌리고, 클라이언트사의 리스크 분석가가 로그인해서 결과를 직접 확인할 수 있었습니다.

이게 단순히 "AI가 빠르네"로 끝나는 이야기가 아니에요. 여기엔 제품 개발의 경제학 전체를 뒤흔드는 논리의 전환이 숨어 있거든요.

소프트웨어 개발, 오랫동안 '비싼 것'은 무엇이었나

수십 년 동안 소프트웨어에서 '비싼 것'은 만드는 행위 자체였습니다.

개발자는 희소했고, 개발 도구는 복잡했고, 인프라 비용도 만만치 않았죠. 그래서 기업들은 만들기 전에 최대한 정확하게 정의하려 했습니다. 요구사항 정의서, 기획서, 디자인 리뷰, 개발 견적, 스프린트 계획, 승인 게이트...

이 모든 프로세스의 목적은 딱 하나였어요. 비싼 개발 시간을 낭비하지 않기 위해서.

문서 작성에 4주를 쓰더라도 12주짜리 잘못된 개발을 막을 수 있다면, 합리적인 선택이었습니다. 제품 개발 조직의 구조 자체가 이 '비싼 제조 비용'에 최적화되어 있었던 거죠.

그런데 지금, 이 계산식이 뒤집히고 있습니다.

바이브 코딩(Vibe Coding)이 바꾼 것

바이브 코딩이라는 용어는 저명한 AI 연구자 안드레이 카르파티가 2025년 2월에 처음 소개했으며, 사용자가 자연어로 의도를 표현하면 AI가 그 생각을 실행 가능한 코드로 바꿔주는 새로운 개발 방식을 말합니다.

Claude Code, Cursor, Bolt, Lovable 같은 도구들이 대표적인데요.

기존의 단순한 AI 코드 어시스턴트 개념과 차별화되는 핵심 특징은, 코드의 작동 원리를 완전히 이해하지 않아도 코드를 작성한다는 점입니다. 코드를 생성하는 주도권이 사람보다 AI 쪽에 있다는 것이 핵심이에요.

이 흐름이 가져온 가장 중요한 변화는 비개발자도 소프트웨어를 만들 수 있는 시대의 개막입니다. 기획자, 디자이너, 심지어 일반 사용자도 자신의 아이디어를 직접 구현해볼 수 있는 기회가 생겼고, 기술적인 제약 없이 창의적인 아이디어를 현실화할 수 있게 된 거예요.

1980년대에 스프레드시트가 재무 모델링을 모든 직군의 기술로 만들었듯, AI 빌딩 툴은 기능하는 소프트웨어를 만드는 능력을 수평적 기술로 확산시키고 있습니다.

사양 정의 비용 vs. 프로토타입 제작 비용, 역전됐다

이제 실제 숫자로 비교해볼게요.

기획자가 상세한 PRD를 작성하는 데 3~5일. 이해관계자 리뷰, 디자인 검토, 개발 가능성 확인을 거치면 추가로 며칠이 더 필요합니다. 거기에 디자이너의 화면 설계, 개발 견적과 스프린트 계획까지 더하면...

첫 번째 코드 한 줄이 작성되기 전까지 조직은 이미 150~250시간의 인력 시간을 써버립니다. 그리고 그 결과물은? 아직 아무도 사용해보지 않은 제품을 설명하는 문서 더미예요.

반면 기획자가 AI 툴로 40시간을 들여 만든 기능하는 프로토타입은, 문서가 아니라 제품입니다. 거칠고 불완전하지만 실제로 만질 수 있는 무언가죠. 사용자가 써볼 수 있고, 진짜 반응을 확인할 수 있어요.

사양을 정의하는 비용이, 테스트 가능한 버전을 만드는 비용보다 높아지는 순간이 온 겁니다.

이 한 문장이 지난 수십 년간 제품 개발을 지배해온 경제적 논리를 뒤집어요.

사람들이 흔히 하는 오해 — "이제 기획자는 없어지는 건가요?"

여기서 오해하지 말아야 할 부분이 있어요.

사용자 리서치는 사라지지 않습니다. 오히려 더 중요해지는데, 다만 '리서치가 완료됐다'는 선언이 빌딩의 전제 조건이 아닌 게 달라지는 거예요.

기획서도 사라지지 않습니다. 의사결정을 문서화하고 이해관계자를 정렬하는 기획서는 여전히 필요해요. 하지만 무엇을 만들지 탐색하기 위한 주요 도구로서의 기획서가 설 자리를 잃어가는 거죠.

개발도 사라지지 않습니다. 프로덕션 수준의 소프트웨어는 여전히 설계, 보안, 성능 최적화, 확장성이 필요합니다. 바이브 코딩은 MVP 이전 단계, 가능한 실체를 최대한 빨리 만들어야 하는 상황에서 특히 강력한 도구예요. 그 이상으로 가면 여전히 개발자의 손길이 필요합니다.

사라지는 건 '갭'입니다. 누군가 통찰을 얻은 순간과 실제 사용자가 무언가를 만져보는 순간 사이의 그 긴 갭. 그 갭을 채우던 게 문서, 회의, 추측이었는데, 이제 그 자리를 실제로 작동하는 소프트웨어와 관찰된 사용자 행동이 채울 수 있게 됐습니다.

각 역할의 가치, 이렇게 재정의된다

기획자의 가치는 "상세한 기획서를 잘 쓰는 능력"에서 "무엇을 만들 가치가 있는지 판별하고 빠르게 증명하는 능력"으로 이동합니다.

기획자는 더 이상 문서를 넘기는 사람이 아니라, 혁신적으로 짧아진 기획→시제품 제작→테스트→개선의 사이클을 통해 아이디어를 바로 제품으로 연결시키는 사람이 될 수 있습니다. 그 핵심 역량은 내 의도를 AI가 이해할 수 있는 언어로 표현하는 기술이 됩니다.

디자이너의 가치는 "개발 전에 완벽한 화면을 만드는 것"에서 "기능이 검증된 후 경험을 설계하는 것"으로, 개발자의 가치는 "기획서를 코드로 번역하는 것"에서 "검증된 것을 확장하고, 안전하게 만들고, 최적화하는 것"으로 이동해요.

어떤 역할도 없어지지는 않습니다. 다만 각 역할에서 진짜 중요한 게 무엇인지가 명확해질 뿐이에요. 개발자의 역할이 코더에서 제품 관리자로 전환되고 있다는 점이 핵심인데, 기획자도 마찬가지입니다. 전략적 사고와 검증 능력이 그 어느 때보다 중요해지는 시대가 오고 있어요.

혁신의 속도가 달라진다는 게 뭔 의미냐면요

기존 방식에서 혁신은 희소했습니다. 실험 하나에 수개월과 수천만 원이 들었기 때문이에요.

아이디어는 우선순위 회의를 통과해야 했고, 사업성 검토와 ROI 예측을 거쳐야 했습니다. 대부분의 아이디어는 그 문턱을 넘지 못했어요. 나쁜 아이디어여서가 아니라, 테스트 비용이 너무 비쌌기 때문에.

앞서 소개한 농업 핀테크 팀의 사례를 보면, 이전에는 분기당 몇 가지 아이디어만 테스트했지만 지금은 약 20개를 테스트합니다. 성공률은 비슷하게 5개 중 1개 정도지만, 살아남는 아이디어의 절대적인 수가 연간 1~2개에서 4~5개로 늘었어요.

이건 점진적 개선이 아닙니다. 혁신 역량 자체가 달라진 거예요.

바이브 코딩은 창업자가 먼저 초기 비전을 설명해 작동하는 프로토타입을 받고, 그 결과물을 바탕으로 요청 사항을 세밀하게 다듬어나갈 수 있어, 사용자 피드백이나 급변하는 시장 상황에 맞춰 방향을 전환하거나 조정하는 것을 훨씬 수월하게 만들어줍니다.

혁신을 가로막던 건 아이디어의 부족이 아니었습니다. 테스트 비용이었어요. 그 비용이 무너졌습니다.

PM과 기획자라면 지금 당장 무엇을 해야 할까

바이브 코딩은 단순한 유행어를 넘어 개발 생태계 전반의 패러다임을 바꾸는 흐름으로 자리 잡았습니다. "바이브 코딩, 할 줄 모르면 잘리는 건가?"라는 불안에서 시작해, 실무자들이 실제로 현장에서 어떻게 쓰고 있는지까지 그 흐름이 꽤 입체적으로 전개되고 있어요.

지금 당장 모든 기획자가 Claude Code를 배워야 한다는 게 아닙니다.

하지만 "만들어보기 전에 알 수 없는 것들"이 있다는 걸, 그리고 이제 만들어보는 비용이 상상을 정리하는 비용보다 낮아졌다는 걸 인식해야 해요.

'기획 완료 → 개발 시작'의 순서가 절대적인 진리가 아닐 수 있습니다. '빠르게 만들어 배우고 → 제대로 만든다'는 흐름이 더 합리적인 선택이 되는 맥락이 점점 늘어나고 있어요. 이 흐름에 올라타는 조직과 개인은 더 많은 것을 더 빨리 배우게 되고, 그 학습이 쌓이면 따라잡기 어려운 격차가 만들어집니다.

마무리

만드는 비용이 정의하는 비용보다 낮아지는 순간, 제품 개발의 논리 전체가 바뀝니다.

더 많은 실험, 더 빠른 학습, 더 정확한 제품. 이 세 가지는 더 이상 이상론이 아닙니다. 지금 이미 이 방식으로 움직이는 팀들이 만들어내고 있는 현실이에요. 우리가 물어야 할 질문은 "이 흐름이 진짜인가?"가 아니라 "나는 어느 쪽에 있고 싶은가?"입니다.