「바이브 코딩 (Vibe Coding)에서 가장 중요한 것은 구현이 아니다. 요건 정의 (Requirements Definition)다」

9개월 동안 SaaS를 혼자서 만들면서, 진심으로 그렇게 느꼈다.

하나의 AI에게만 맡기면 사양의 차이가 쌓여 나중에 치명적인 재작업(rework)으로 이어진다. Claude · ChatGPT · Cursor를 **삼각 리뷰 (Three-way Review)**로 돌린 실체험을 바탕으로, 요건 정의 단계의 운영론을 공유한다.

이 기사는 「요건 정의가 전부다——AI 주도 개발은 Claude × ChatGPT × Cursor의 삼각 리뷰로 돌린 이야기」의 다이제스트 버전입니다.

익명 공유 링크나 결제 설계에서 실제로 효과가 있었던 구체적인 에피소드는 위의 완전판을 확인해 주세요.

보충: 수법은 2025년 6월~12월경의 언어 모델을 전제로 합니다. 물건을 만드는 본질은 변하지 않지만, 베스트 스택(Best Stack)은 업데이트되고 있습니다.

ChatGPT 출시 초기부터 접해온 감각으로서, 채팅 베이스로 사양을 다듬기에는 AI 단독으로는 불완전하다.

• 논리의 허점을 놓침
• 전제를 확인하지 않고 답을 내놓음
• 일관성 있는 텍스트로 정리하기 때문에 올바르게 보임

그리고 실체험으로서 확신한 것은, 세세한 사양의 차이는 후속 공정에서 반드시 복리로 작용한다는 것이다. 경우에 따라서는 상황이 매우 어려워질 수도 있다.

하나의 AI에게 맡긴다는 것은, 그 AI의 '맹점'을 그대로 프로덕트의 맹점으로 받아들이는 것이다. Claude가 놓치는 패턴, ChatGPT가 흘려보내는 패턴, Cursor가 신경 쓰지 않는 패턴——각각 미묘하게 다르다. 인간 엔지니어와 마찬가지로 AI에게도 개성과 버릇이 있다. 하나에 의존하면 그 버릇을 통째로 짊어지게 된다.

「Claude 초안 작성 → ChatGPT와 Cursor로 리뷰 → Claude로 복귀」의 사이클을 요건 1항목당 3~5회 반복하는 운영이다.

Claude를 초안 작성자로 삼은 이유는 문장의 유창함과 논리의 일관성 면에서 한발 앞서 있다고 느꼈기 때문이다. 갑자기 ChatGPT로 쓰게 하면, 좋든 나쁘든 불렛 포인트와 정보의 나열로 치우친다. 첫 전체상은 이야기로서 읽히는 편이 이후의 논의를 하기 쉽다.

게다가 Claude는 명명 규칙 (Naming Convention)에서 정말 좋은 결과물을 내놓는다. 변수명, 함수명, 엔드포인트명, 화면 전환 ID——후속 공정의 구현에서도 그대로 사용할 수 있는 명칭이 올라온다.

다만 Claude는 '논리가 통하는 것처럼 보이는 것'이 오히려 위험할 수도 있다. 일관성이 있으면 '이대로 괜찮겠지'라고 생각하게 된다. 여기서 ChatGPT와 Cursor의 차례가 온다.

요건 정의부터 상세 설계까지, 2개월간의 집중(缶詰) 페이스를 두었다. 9개월의 개발 기간 중 꼬박 2할 이상을 여기에 사용한 계산이다. 너무 길다고 생각할 수도 있지만, 여기가 토대가 된다.

요건 정의 전에는 **요구 정의 (Requirements Analysis)**가 있다. '무엇을 만들 것인가' 이전에 '무엇을 실현하고 싶은가'를 모두 나열하는 페이즈다.

Claude와 잡담 베이스로 하고 싶은 것을 전부 꺼낸다. 기능, 원하는 경험, 해결하고 싶은 과제, 전부 다. 이 단계에서 다 꺼내지 않으면, 나중에 '저 기능도 필요해', '이거 잊고 있었어'라는 말이 1억 % 나온다.

요구를 다 꺼내지 않은 채 요건 정의로 넘어가면, 도중에 '이 기능의 전제가 바뀌었다' 계열의 붕괴가 일어나기 쉽다.

Claude에게 요건 정의 문서의 초안을 쓰게 한다. 화면 전환, 기능 목록, 데이터 모델, 비기능 요건, 기본 설계, 상세 설계까지 일관되게.

그대로 채택하지 않는다. 복사해서 ChatGPT와 Cursor에 던진다. 올라온 지적 사항을 Claude에게 다시 돌려준다. "이런 지적이 왔으니 요건 정의를 수정해줘"라고. Claude가 수정본을 내놓으면 다시 양쪽에게 돌린다.

요건의 각 섹션에서 3~5회 왕복한다. 막히는 정도에 따라 그 이상 반복할 때도 있다.

이 부분이 가장 중요하다. AI로 몇 번을 다듬어도, 마지막에 프로덕트 오너 (Product Owner, 자신)의 눈을 거치지 않으면 요건 정의는 완성되지 않는다. AI는 '타당한 요건 정의'를 내놓지만, '내가 만들 의미가 있는 요건 정의'는 마지막에는 자신만이 낼 수 있다.

▶ 익명 공유 링크의 「전송될 것을 전제로 한」 설계나 결제 설계에서 실제로 효과를 본 구체적인 에피소드는 이쪽으로 → 요건 정의가 전부다—AI 주도 개발은 Claude × ChatGPT × Cursor의 삼각 리뷰로 돌린 이야기

편리한 이야기만 하고 끝내는 것은 공정하지 않다. 삼각 리뷰(Three-way review)에는 명확한 비용이 따른다.

「Claude는 A안을 추천한다」, 「ChatGPT는 B안의 리스크를 지적한다」, 「Cursor는 구현상의 이유로 C안을 제안한다」——이렇게 되면 판단 재료가 늘어날수록 결정을 내리기가 더 어려워진다. 체감상으로는 하나의 AI만 사용할 때보다 피로도가 분명히 높다.

하지만 이것은 삼각 리뷰의 피할 수 없는 비용이기도 하다. AI에게 판단을 통째로 맡기지 않았기에, 마지막에는 자신이 설계 책임을 가져야 한다.

「ChatGPT가 지적 → Claude가 수정 → Cursor가 구현 관점에서 다른 문제 제기 → Claude가 다시 수정 → ChatGPT가 원래의 논점을 재제기」. 이렇게 되면 아무리 파고들어도 끝이 나지 않는다. 실제로 요건 정의의 세부 사항을 다투느라 반나절 가까이 허비한 날도 있었다. 품질을 높이고 있다고 생각했는데, 어느샌가 「결정하지 않기 위한 리뷰」가 되어 있었다.

도중에 정한 심플한 규칙은 이것이다.

3라운드를 돌려도 수렴하지 않으면, 자신이 판단하여 마무리한다

AI에게 끝까지 파고들게 만드는 것이 아니라, 자신이 매듭짓는 타이밍을 갖는 것이다. 이 규칙 덕분에 삼각 리뷰는 상당히 사용하기 편해졌다.

요건 정의부터 모크(Mock) 작성까지 3개월간 철저하게 파고들었다. 9개월의 개발 기간 중 구현 전에 3분의 1을 사용한 계산이다.

후반 6개월의 구현 단계에서 재작업(Rework)은 물론 있었다. 이 정도로 파고들어도 재작업은 반드시 발생하며, 절대 제로가 될 수는 없다. 하지만 치명적인 것은 없었다. 데이터 모델을 다시 짜야 하는 수준처럼, 일주일 전체를 날려버리는 사고는 제로였다. 이것이 전부라고 생각한다.

바이브 코딩(Vibe Coding)의 시대, AI로 구현은 폭속(爆速)이 된다. 그렇기에 구현 전에 결정해야 할 것을 철저하게 결정한다. 이것이 개인 개발의 가장 중요한 열쇠다.

AI는 구현을 빠르게 한다. 하지만 「무엇을 만들어야 하는가」는 가속해 주지 않는다. 그 부분은 인간이 천천히, 정성스럽게, 자신의 책임하에 결정할 수밖에 없다.

요건 정의가 전부다. 구현은 마지막이다. 다시 한번 말한다. 요건 정의가 전부다. 구현은 마지막이다.

• AI 하나에만 의존하면, 그 AI의 사각지대를 통째로 떠안게 된다
• Claude는 초안 작성 + 명명 규칙(Naming convention), ChatGPT는 기술적 깊이와 미래 관점, Cursor는 구현 관점의 보강
• 요구 정의에서 "하고 싶은 것"을 모두 쏟아낸다 → 요건 정의 ~ 상세 설계 단계를 삼각 리뷰로 파고든다
• 마지막은 반드시 프로덕트 오너(Product Owner, 자신)의 눈으로 확인한다
• 3라운드 내에 수렴하지 않으면 자신이 마무리한다는 규칙을 세운다
• 재작업은 반드시 발생한다. 제로가 될 수는 없다.
  하지만 "치명적인 재작업"은 방지할 수 있다

구현 페이즈는 또 다른 이야기다. Claude Code를 본격적으로 도입하자마자 이 삼각 리뷰 체제는 무너졌다——그 뒷이야기는 완전판으로 이어진다.

▶ 완전판 가이드는 이쪽으로 → 요건 정의가 전부다—AI 주도 개발은 Claude × ChatGPT × Cursor의 삼각 리뷰로 돌린 이야기

▶ 무료로 스킬 시트(Skill sheet)를 만들어 보기 → https://www.skillsheet-port.com/