음악 전공 출신 PM이 있다. 코드를 한 줄도 몰랐다. 그런데 지금은 혼자서 제품 두 개를 출시했고, Meta 엔지니어링 팀이 그에게 워크플로우를 가르쳐달라고 요청한다. Zevi Arnovitz 이야기다.
Lenny’s Podcast에 출연한 Zevi는 약 1년 만에 Cursor와 Claude Code를 활용해 독자적으로 제품을 개발하는 수준에 도달했다고 밝혔다. 그가 만든 건 막연한 프로토타입이 아니라 실제 사용자가 쓰는 StudyMate와 Dibur2text 같은 서비스다.
솔직히 이런 이야기를 처음 들으면 과장이라고 생각하기 쉽다. 하지만 그의 워크플로우를 뜯어보면, 단순한 바이브 코딩(Vibe Coding)과는 결이 다르다.
바이브 코딩의 함정부터 짚고 가자
바이브 코딩이라는 말은 Andrej Karpathy가 2025년 초에 만든 표현이다. 자연어로 원하는 걸 설명하면 AI가 코드를 생성하는 방식을 뜻한다. 2026년 들어 Bolt, Lovable, Replit 같은 도구들이 쏟아지면서 “코딩 없이 앱 만들기”가 하나의 트렌드가 됐다.
문제는 여기서 시작된다. Zevi도 처음에는 Bolt와 Lovable로 시작했다. 채팅 UI에서 “결제 기능 추가해줘”라고 말하면 코드가 뚝딱 나왔다. 그런데 결제 연동처럼 복잡한 기능에서 심각한 버그가 터졌다. 이 도구들의 시스템 프롬프트가 계획 없이 바로 코드를 작성하도록 설계되어 있었기 때문이다.
AI가 생성한 코드의 약 45%가 보안 결함을 포함한다는 연구 결과도 있다. 인증 처리 미흡, 입력값 검증 누락 같은 문제들이다. 자연어로 “만들어줘”라고만 했을 때 이런 구멍을 잡을 방법이 없다.
Zevi가 Cursor와 Claude Code로 전환한 건 이 지점이었다. “코드는 결국 단어다. 컴퓨터의 파일들이다”라는 인식이 생기면서, 코드 파일을 직접 들여다보고 모든 결정권을 자기가 쥐는 방식으로 바꿨다.
6단계 워크플로우의 실체
Zevi의 핵심은 Claude Code의 슬래시 커맨드(/commands) 시스템이다. 마크다운 파일로 저장된 프롬프트를 /파일명으로 즉시 실행하는 방식인데, 이걸 6단계 파이프라인으로 조합했다.
이슈 캡처와 탐색
/create-issue로 시작한다. 개발 중 떠오른 버그나 아이디어를 Linear 이슈로 바로 캡처한다. 컨텍스트를 잃지 않으면서 현재 작업 흐름을 유지하는 게 목적이다.
다음은 /exploration이다. Claude에게 문제를 던지면 분석하고 명확화 질문을 제기한다. 여기서 흥미로운 점은 Claude가 사용자의 생각에 “도전”하도록 프롬프트가 설정되어 있다는 거다. “정말 그게 맞아?”라고 되묻게 만들어놓은 셈이다. 비기술자가 빠지기 쉬운 잘못된 가정을 초기에 잡아내려는 장치다.
계획 수립과 실행
/create-plan으로 마크다운 계획 파일을 생성한다. TLDR, 주요 결정 사항, 태스크별 상태 추적이 포함된 템플릿이 나온다. 이 계획 파일이 핵심인 이유는 여러 AI 모델이 공유할 수 있다는 점이다. 백엔드는 Claude에게, 프론트엔드는 Gemini에게 같은 계획을 기반으로 나눠줄 수 있다.
/execute-plan으로 실행에 들어간다. 복잡하지 않은 작업은 Cursor Composer(속도가 빠르다), UI 작업은 Gemini 2.5를 쓴다. 모델마다 잘하는 게 다르다는 걸 파악하고 적재적소에 배치하는 방식이다.
다중 모델 피어 리뷰
여기가 이 워크플로우에서 가장 주목할 부분이다. /review로 Claude가 자기 코드를 먼저 리뷰한다. 그 다음 Codex(GPT)와 Cursor Composer가 각각 독립적으로 리뷰한다. 그리고 /peer-review 커맨드로 다른 모델의 리뷰 결과를 Claude에게 붙여넣는다.
그러면 Claude가 “이 지적은 세 번째로 제기된 사항이다. 이건 버그가 아니라 의도된 설계다”라고 방어하거나, 타당한 지적은 수용한다. AI 모델끼리 논쟁을 시키는 거다.
GPT-4o와 Gemini 2.0 Flash를 대상으로 한 연구에서, 각 모델이 코드 정확성을 판별하는 비율은 각각 68.50%와 63.89%였다. 단일 모델로는 놓치는 게 있다는 뜻이다. 서로 다른 모델이 서로 다른 관점에서 잡아내는 문제가 있고, 이걸 교차 검증하면 품질이 올라간다.
세 AI를 팀원처럼 쓰는 법
Zevi는 각 모델을 완전히 다른 성격의 팀원으로 묘사한다.
Claude는 이상적인 CTO다. 소통을 잘하고 의견이 분명하다. 무조건 동의하지 않고 도전하면서도 협업적이다. 다만 기본적으로 “인플리저(people pleaser)” 성향이 있어서, CLAUDE.md 시스템 프롬프트로 이걸 억제해놓았다.
Codex(GPT)는 회사에서 가장 뛰어난 코더다. 후드 쓰고 어두운 방에서 일하며 소통은 안 하지만, 최악의 버그를 고친다. 복잡한 디버깅에 특화된 역할이다.
Gemini는 재능 있는 예술가형 과학자다. UI를 만들면 결과물이 좋은데, 작업 과정이 무섭다. 대시보드를 통째로 삭제했다가 복원하는 방식으로 진행하기도 한다. 과정은 불안하지만 최종 산출물의 UI 품질은 높다.
이 분업이 가능한 이유는 계획 파일이라는 공유 문서가 있기 때문이다. 같은 계획을 보고 각자 맡은 영역을 실행하니, 마치 소규모 팀을 운영하는 것과 비슷하다.
실무에서 쓸 수 있는 건 뭔가
솔직히 이 워크플로우를 그대로 따라하기는 쉽지 않다. Zevi도 1년이 걸렸다. 다만 당장 가져갈 수 있는 게 몇 가지 있다.
슬래시 커맨드 기반의 재사용 가능한 프롬프트 시스템은 팀 단위로 도입할 수 있다. 반복되는 작업을 매번 새로 프롬프트로 치는 대신 .claude/commands/ 폴더에 마크다운 파일로 저장해두면 /커맨드명으로 바로 실행된다. 버전 관리도 되고, 팀 전체가 같은 워크플로우를 공유할 수 있다. 실제로 이런 방식을 적용한 팀에서 코드 리뷰 시간이 58% 줄었다는 사례도 보고되고 있다.
다중 모델 피어 리뷰는 코드뿐 아니라 리포트나 콘텐츠 검증에도 적용된다. Claude가 작성한 글을 GPT에게 검토시키고, 그 결과를 다시 Claude에게 보여주는 방식이다.
그리고 AI 실패 후 문서 업데이트 루프. Zevi의 /update-docs 커맨드는 AI가 반복적으로 같은 실수를 하면 원인을 CLAUDE.md나 문서에 반영한다. 같은 실수가 다시 발생하지 않도록 시스템 수준에서 학습시키는 셈이다.
그래서 PM이 코딩해야 하는 건가
Zevi는 이 질문에 대해 명확하다. PM의 역할은 가장 빠르게 올바른 솔루션을 사용자에게 전달하는 것이다. AI가 그 수단이 될 수 있다면 활용하는 게 맞다. 단, 결과물에 “AI가 만들었다”고 변명하는 순간 그건 실수라고 못 박는다. 출력물의 소유권과 책임은 여전히 사람에게 있다.
대기업 환경에서는 제약이 분명하다. 복잡한 데이터베이스 마이그레이션 같은 건 아직 PM 영역이 아니다. 하지만 격리된 UI 프로젝트에서 PM이 직접 PR을 만들고 엔지니어에게 최종 검토를 요청하는 건 이미 현실이 됐다. Meta 엔지니어링 팀이 Zevi에게 워크플로우를 배우려 한다는 사실이 이를 방증한다.
결국 이건 코딩 능력의 문제가 아니다. AI를 팀원처럼 관리하고, 체계적인 워크플로우를 설계하고, 품질에 대한 책임을 지는 능력의 문제다. 그리고 그건 원래 PM이 잘하는 일이다.
