Vibe coding은 이미 구식이 됐습니다——그리고 이건 프로덕트 매니저에게 희소식입니다
2026년, 「vibe coding」이라는 말을 세상에 퍼뜨린 Andrej Karpathy가 무대 위에 올라 그것이 이미 구식이 됐다고 선언했습니다. 그가 대안으로 제시한 개념은 **agentic engineering(에이전트 공학)**이었고, 이를 일련의 활동들로 풀어냈습니다: 설계 스펙 작성, 계획 감독, diff 검토, 테스트 작성, 평가 루프 구축, 권한 관리, 품질 수호.
그 목록에서 엔지니어 특유의 단어들을 걷어내고 다시 읽어보세요. 무엇을 만들어야 할지 결정하기. 결과물이 의도와 일치하는지 확인하기. ‘충분히 좋다’는 기준을 정하고, 그 아래에서는 출시를 거부하기. 이건 새로운 직무가 아닙니다. Jeff Gothelf의 표현을 빌리면, 판단하는 버전이 곧 그 일 자체였습니다——언제나 그래왔습니다. AI는 다만 우리가 그것을 숨겨왔던 자리들을 모조리 걷어냈을 뿐입니다.
지금 제품을 만드는 모든 사람에게 가장 중요한 전환이 바로 이것이고, 그 방향은 대부분의 사람들에게 반직관적으로 느껴집니다.
살아남는 역량은 코딩이 아닙니다
지난 10년간 「코딩을 배워라」는 말은 제품 아이디어를 가진 누구에게나 통용되는 조언이었습니다. 2026년, 그 조언은 조용히 뒤집혔습니다. AI 에이전트가 명확하게 정의된 문제를 실제 동작하는 소프트웨어로 변환할 수 있게 되면서, 문서를 쓰는 것이 더 이상 핵심 업무가 아니라——의도, 명확성, 판단력이 업무의 본질이 됐습니다. 업계는 지금 중요한 사람들에게 이름을 붙였는데, 그 이름은 「프롬프트 엔지니어」가 아닙니다. Product School의 판단은 단호합니다: 2026년에 진짜 중요한 PM은 AI 제품 매니저입니다.
실제로 하는 일들이 이를 뒷받침합니다. AI 네이티브 PM이 실제로 무엇을 하는지에 대한 업계의 합의는 세 가지 동사로 수렴됩니다:
- 묘사(Describe): 유능한 에이전트가 실행에 옮길 수 있을 만큼 명확하게 원하는 것을 설명한다.
- 분해(Decompose): 하나씩 검증할 수 있을 만큼 작은 단위로 문제를 나눈다.
- 판단(Judge): 결과물이 의도와 일치하는지 평가하고——맞지 않는 15%에서 무엇을 할지 결정한다.
이 세 가지 중 코딩은 하나도 없습니다. 세 가지 모두 제품 관리입니다.
코드를 모르는 것이 오히려 강점인 이유
이 부분은 틀린 말처럼 들리지만, 틀리지 않습니다. 코딩할 줄 아는 사람은 머릿속 한편에서 이걸 만들기가 얼마나 어려운지를 계속 추산하고 있습니다. 직접 만드는 사람에게 그 추산은 유용합니다——하지만 무엇이 존재해야 하는지 결정하는 사람에게는 짐이 됩니다. 아이디어가 입 밖으로 나오기도 전에, 사용자 가치가 아닌 구현 비용에 의해 다듬어지고 제한됩니다.
코딩을 모른다면, 그런 반사적 자기검열이 없습니다. 시작 단계에서 진짜로 중요한 두 가지 질문만 손에 쥐게 됩니다: 사용자가 실제로 무엇을 필요로 하는가, 그리고 이 경험이 맞는가? 그다음 해야 할 일은 그것을 명확하게 말하는 것입니다. 그리고 「아이디어를 명확하게 말하는 것」은 프로덕트 매니저가 가진 가장 오래된 핵심 역량입니다.
이건 무지함을 유지하라는 주장이 아닙니다. 병목이 이동했다는 주장입니다. 이제 희소한 자원은 텍스트 에디터에서 타이핑하는 속도가 아니라, 요청하는 대상이 얼마나 명확한가입니다.
言出法随 / “말하면 AI가 만든다”는 방법론이지, 감각이 아닙니다
핵심은 이것입니다: vibe coding이 부고장을 받은 데는 이유가 있습니다. 느슨하게 프롬프트하면 매번 결과가 흘러내립니다. 디자이너들은 이미 주목하고 있습니다——AI 프로토타입이 과거 와이어프레임이 차지했던 자리를 채우고 있지만, 같은 프롬프트를 반복 실행할 때마다 결과가 미묘하게 달라지고, 그 의미론적 편차는 빠르게 벌어집니다. 의도가 흐릿하게 들어가면, 제품은 일관성 없이 나옵니다.
그래서 답은 프롬프트를 더 힘주어 쓰는 게 아닙니다. 규율을 갖추고 작업하는 것입니다. 그 규율을 우리는 DO AI PM이라고 부르며, 몇 가지 약속으로 정리됩니다:
- 고충실도 우선. 와이어프레임은 건너뛰세요. 실제로 동작하는 것을 바로 만드세요——실제 콘텐츠, 실제 상태(로딩, 빈 화면, 에러, 성공), 실제 인터랙션——그리고 직접 실행해서 검증하세요. 동작하는 프로토타입은 언제나 묘사된 프로토타입을 이깁니다. 의사결정이 이루어지는 회의실에서도 마찬가지입니다.
- 다섯 단계, 작은 걸음. 발견(Discover) → 정의(Define) → 설계(Design) → 개발(Develop) → 검증(Validate). 정의 단계에서는 AI가 스펙을 작성하기 전에 먼저 질문을 던지게 하세요. 개발 단계에서는 한 번에 하나씩만 바꾸세요.
- 안전망. 프로토타입에는 실제 비밀 키나 프로덕션 데이터를 넣지 마세요. 되돌릴 수 없는 버튼——발행, 삭제, 결제——은 사람이 누르세요. 프로덕션은 건드리지 마세요. 확실하지 않으면 물어보세요.
마지막 목록이 「운 좋게 프롬프트 하나 맞췄다」와 「다음 주 월요일에도 다시 할 수 있다」 사이의 차이입니다.
성과물이 곧 증거입니다
자기 자신만 설명하는 방법론은 아무 가치가 없습니다. 그래서 이 모든 것은 Claude Code로 실제로 만든 제품들에서 비롯됩니다: SoloMD(마크다운 에디터), Unterm(AI 에이전트가 조작할 수 있는 터미널), unfetch(사람과 AI 모두를 위한 다운로드 매니저), StoryAlter(AI 글쓰기 동반자), Unflick(사람과 AI 모두를 위한 미디어 플레이어). 지금 읽고 계신 이 웹사이트——8개 언어, 이 블로그, 발표 자료——도 같은 방식으로 「말해서」 존재하게 됐습니다. 손으로 직접 쓴 코드는 단 한 줄도 없습니다.
방법론이 작품을 설명하고, 작품이 방법론을 증명합니다.
Karpathy의 말은 옳았습니다. vibe coding은 끝났습니다. 그것을 대체하는 것은 더 어려운 종류의 공학이 아닙니다——잘 결정하고 명확하게 설명하는 규율입니다. 그 일에는 이름이 있고, 지금이 바로 그 일을 하기에 좋은 때입니다.
言出法随——「말하면 AI가 만든다」가 실제로 어떤 느낌인지 경험해 보고 싶다면, 방법론 센터에서 시작하세요.
더 읽어보기
토론