vibe coding은 죽었고, 이제 스펙을 써야 한다고요? PM에게는 세 번째 길이 있습니다——言出法随
요즘 방법론 커뮤니티에서 한바탕 싸움이 벌어지고 있습니다. 제목들이 다들 자극적입니다: 「vibe coding은 이미 죽었다, 어서 spec-driven development(규격 주도 개발)로 갈아타라.」
흐름은 분명히 바뀌고 있습니다. GitHub의 Spec Kit은 이미 별이 9만 개를 넘겼고, AWS는 「먼저 스펙을 정하고 코드를 짜라」는 철학을 중심에 놓은 Kiro를 출시했으며, Thoughtworks는 규격 주도 개발을 기술 레이더에 올렸습니다. 주류 논리는 이렇습니다: 규격이 유일한 사실의 원천이고, 코드는 그것의 산물일 뿐이다. 둘이 충돌하면 코드를 고쳐라, 규격은 건드리지 마라.
그럴듯하게 들립니다. 하지만 당신이 PM이라면, 「스펙 쓰기」 공부를 서둘러 시작하기 전에 잠깐 멈춰볼 필요가 있습니다.
진자가 너무 많이 흔들렸습니다
사건의 전말은 이렇습니다:
먼저 vibe coding이 떴습니다——한 마디 던지면 AI가 줄줄 코드를 뱉어냅니다. 신났지만 금방 탈이 났습니다. 구조가 없고, 고치기 어렵고, 자기가 뭘 만들었는지도 모르는 상태. 그러자 사람들은 반대 극단으로 달려갔습니다: 그럼 모든 걸 먼저 스펙으로 써놓자, 최대한 세세하게, 그걸 보고 AI가 만들게 하자.
문제는, PM에게 「방대한 사전 규격 문서를 쓰는 일」은 너무나 익숙하다는 겁니다——그게 바로 PRD입니다. 수십 페이지짜리, 다 쓰면 이미 구식이 되어 있고, 끝까지 읽는 사람도 없는 그 PRD. AI 시대의 가장 큰 해방 중 하나가 바로 이런 문서 고역에서 벗어나는 것이었는데, spec-driven은 그걸 그대로 다시 불러들이면서 세련된 새 이름만 붙여준 셈입니다.
「막연하게 짜기」에서 「스펙 쓰기」로 진자가 흔들리는 건, 한 극단에서 다른 극단으로 옮겨가는 것일 뿐입니다. 어느 쪽도 PM이 서야 할 자리가 아닙니다.
세 번째 길: 규격은 쓰는 게 아니라, 말로 명확히 하고 + 실행으로 만들어지는 것입니다
vibe coding은 너무 허술하고, 스펙 쓰기는 너무 무겁습니다. 그 중간에 또 다른 길이 있습니다——doaipm이 줄곧 걸어온 그 길——言出法随.
핵심은 이겁니다: 문서로 쓰인 규격이 필요한 게 아닙니다. 하고 싶은 것을 명확히 말할 수 있으면 됩니다. 그리고 「말을 명확히 하는 것」은 PM이 원래부터 가진 가장 기본적인 능력이지, 새로 배워야 할 기술이 아닙니다.
구체적으로는 두 가지로 나뉩니다:
첫째, 규격은 대화 속에 살아 있습니다, 문서 속이 아니라. 완전한 스펙을 먼저 다 써야 시작할 수 있는 게 아닙니다. 의도를 명확히 말하면 됩니다——누구의 어떤 문제를 풀려 하는지, 핵심 제약은 무엇인지, 무엇이 되면 올바른 것인지——그러고 나서 AI가 바로 실행 가능한 결과물로 바꾸게 합니다. 말이 불명확한 부분은 AI가 반문합니다(좋은 에이전트라면 먼저 3–5개의 날카로운 질문을 해야 합니다). 그 대화 속에서 빈틈을 채워나갑니다. 명확화는 소통 속에서 일어납니다, 아무도 읽지 않는 문서 속이 아니라.
둘째, 실행 가능한 고충실도 프로토타입 자체가 최고의 규격입니다. 글로 쓰인 규격은 열 명이 읽으면 열 가지 해석이 나옵니다. 실제로 클릭되고 작동하며 진짜 상태(로딩/빈/오류/성공)를 가진 프로토타입은, 누가 봐도 맞는지 아닌지 바로 압니다. 고충실도 프로토타입은 스스로 말하는 규격입니다——해석이 필요 없고, 직접 체험됩니다. 이것이 doaipm이 저충실도 와이어프레임을 반대하는 이유이기도 합니다. AI 시대에는 진짜를 바로 만드는 것이 가짜 스케치보다 더 빠르고 오해도 적습니다.
그렇다면 「구조」는 어디서 오는가——작은 걸음과 안전망
어떤 사람은 이렇게 물을 겁니다: 두꺼운 규격 없이 어떻게 vibe coding의 전철을 밟지 않고, 통제력을 잃지 않을 수 있나?
두꺼운 문서가 아니라 두 가지에 기댑니다:
- 작은 걸음으로 빠르게. 한 번에 한 가지만 바꾸고, 실행해보고, 확인하고, 다음 걸음으로 넘어갑니다. 구조는 검증 가능한 작은 걸음들의 연속 속에서 자라납니다. 착수 전에 한꺼번에 계획을 굳히는 게 아닙니다.
- 안전망. 프로토타입에 진짜 키나 진짜 데이터를 넣지 않습니다. 되돌릴 수 없는 버튼(배포, 삭제, 결제)은 항상 사람이 누릅니다. 프로덕션은 건드리지 않습니다. 확신이 없으면 묻습니다. 판단권은 언제나 당신 손에 있습니다——이것이 바로 PM이 대체될 수 없는 부분입니다.
규격이 유일한 사실의 원천이라는 말에는 사실 한 마디가 빠져 있습니다: AI 시대에 가장 충실도 높은 「사실의 원천」은 문서가 아니라, 지금 당신 눈앞에서 돌아가고 있는 그 제품입니다.
그래서, 오늘 무엇을 믿어야 하는가
「vibe coding」과 「spec-driven」 사이에서 편을 고를 필요 없습니다. 그건 가짜 양자택일입니다.
- vibe coding처럼, 아무 생각 없이 AI에 뇌를 통째로 외주 주지 마세요.
- 두꺼운 규격 쓰기처럼, AI 시대가 겨우 내려준 문서 짐을 다시 등에 짊어지지도 마세요.
- 그 중간을 걸으세요: 명확히 말하고(당신은 원래 할 수 있습니다), 고충실도 프로토타입이 대신 말하게 하고(AI가 만들어줍니다), 작은 걸음으로 나아가고, 안전망을 지키세요.
이건 또 새로 배워야 할 프레임워크가 아닙니다——프레임워크는 이미 넘쳐납니다. 이건 PM의 가장 원초적인 동작으로 돌아가는 겁니다: 무엇을 원하는지 명확히 생각하고, 분명히 말하고, 그것이 실행되게 하라.
言出，法随。
토론