바이브코딩 시대, 자연어로 의도만 전달하면 AI가 코드를 만들어주는 세상이 열렸습니다.

그런데 자세히 들여다보니 내부는 엉망이었습니다. GitClear가 최근 배포된 2억 줄 이상의 코드를 분석한 결과, AI 도입 이후 복붙 코드가 8배나 늘었습니다. 리팩토링 비율도 25%에서 10% 미만으로 뚝 떨어졌고요. 리팩토링이란 기능은 그대로 두고 코드를 더 깔끔하게 정리하는 작업인데, 이게 줄었다는 건 만들어진 코드의 품질 관리에 손을 놓고 있다는 뜻입니다.

더 흥미로운 건 개발자들의 반응입니다. AI 도구를 신뢰한다는 응답은 18개월 사이 43%에서 29%로 급락했는데, 사용률은 오히려 92%까지 치솟았어요.

믿지 않으면서도 쓸 수밖에 없는 도구. 이 역설은 왜 생긴 걸까요?

저희 팀도 직접 부딪혀보고 나서야 답을 찾았습니다. 문제는 AI의 성능이 아니었어요. AI에게 입력되는 기획의 형태에 있었습니다.

"어? 이거 기획서에 있었는데요?"

저희 팀 매니패스트가 리셀러 정산 대시보드를 개발할 때 일이에요. 노션에 기획서는 꼼꼼하게 작성해뒀고, 개발도 어느 정도 마무리된 상태였죠. AI 코딩 도구 덕에 개발 속도는 확실히 빨랐어요.

문제는 QA에서 터졌습니다.

PM: "어... 리셀러가 할인 코드를 만들어도 실제 할인이 안 되는데요?"
개발자: "네? DB에 잘 들어가는데요?"
PM: "Paddle(결제 대행 서비스)이랑 연동해야 실제로 할인이 적용되잖아요. 기획서에 써있었는데..."
개발자: "...(기획서 뒤적뒤적) 아, 여기 있네요. 처음엔 봤는데, AI가 반영을 못했네요. 죄송합니다."

AI가 코드를 그렇게 잘 만들어준다면서, 기획서대로 개발됐는지 확인하는 건 왜 여전히 사람이 눈으로 해야 하는 걸까요?

사실 이건 AI 코딩 도구의 잘못이 아닙니다. 노션에 쭉 써놓은 텍스트, 컨플루언스에 올려둔 표, 피그마에 흩어진 코멘트들. 사람 눈에는 다 읽히지만, AI에게는 비정형 텍스트 덩어리일 뿐이에요. "결제 완료 후 Paddle API를 호출해야 한다"는 문장이 어떤 화면의 어떤 기능과 연결되는지, AI는 알 길이 없습니다.

"리셀러 대시보드 문서 읽어줘" — 한 마디로 시작된 실험

그래서 다르게 해봤어요. 예전 같았으면 노션이나 구글 독스의 기획서를 열어놓고, 작성된 코드와 비교하며 눈으로 하나하나 대조했을 겁니다. 반나절은 족히 걸리는 작업이죠.

이번엔 저희가 개발 중인 AI 에이전트의 도움을 받아 구조화된 PRD를 작성한 뒤, Claude Code에 이렇게 말했어요.

"리셀러 대시보드 기획 문서 읽어줘"

Claude Code가 MCP를 통해 기획서를 직접 읽어왔습니다. PRD와 기능명세서 전체를 파싱해서 이렇게 정리해주더라고요.

"리셀러 시스템은 Feature 3개, Spec 8개, Userflow 6개로 구성되어 있습니다. 정산 로직은 2구간 체계로, 1구간(4개월)은 A%, 2구간(3개월)은 B% 커미션입니다."

그리고 바로 이어서 세 개의 코드베이스를 동시에 탐색하면서, 각 Spec이 실제로 구현됐는지 자동으로 대조해줬어요. 결과요? 치명적인 버그 하나를 찾아냈습니다.

AI가 잡아낸 치명적 버그

기획서에는 이렇게 적혀 있었어요.

"리셀러 할인 코드는 카드 등록을 필요로 하는(Paddle과 연동되는) 코드이다"

그런데 코드를 보니, createCode() 함수가 DB에 레코드만 만들고 Paddle API는 전혀 호출하지 않고 있었습니다. 리셀러가 할인 코드를 만들어서 공유해도, 유저가 그 코드를 입력하면 아무 일도 일어나지 않는 상황이었던 거죠.

이 버그가 정말 무서운 이유가 있어요.

코드 리뷰로 안 잡힙니다. 단위 테스트도 통과해요. DB에 잘 저장되니까요. QA에서도 "코드 생성 됩니다 ✓" 하고 넘어가기 십상이에요. 실제로 할인이 적용되는지 Paddle 대시보드까지 가서 확인해봐야 발견되는 종류의 버그였습니다.

그런데 AI가 이해하는 기획서를 작성하니, "Paddle 결제모듈 연동이라고 써있는데 코드에 Paddle 호출이 없네요?"라고 짚어준 거예요.

왜 이게 가능했을까? — 기획서의 '구조'가 달랐다

핵심은 기획서가 단순한 텍스트가 아니었다는 점입니다.

우리가 개발 중인 AI 에이전트가 작성한 PRD는 Requirement → Feature → Spec → Userflow로 계층화된 데이터 형태로 구조화가 되어있었습니다. 각 Spec이 어떤 기능이 구현되어야 하는지, 어떤 역할이 사용하는지, 어떤 예외 케이스가 있는지가 구조적으로 연결되어 있죠.

이 구조가 있으니까 AI가 쉽게 추론할 수 있었습니다.

• "이 Spec은 '할인코드 발급' 기능이고, Paddle 연동이 명시되어 있다"

• "코드베이스에서 createCode 함수를 보니 Paddle 호출이 없다"

• "이건 GAP(미구현 항목)이다"

노션에 자유롭게 자연어 기반으로 쓴 기획서였다면? AI는 "할인코드", "Paddle"이라는 단어가 있다는 것만 알 뿐, 이게 어디에 어떻게 구현되어야 하는지 연결 짓지 못했을 겁니다.

워크플로우를 비교해보면 차이 또한 명확합니다.

기존 방식 (반나절~하루)

기획서 열기 → 내용 복사 → 코드 열기 → 눈으로 대조 → 누락 항목 수동 정리 → 개발자에게 전달 → 재작업

구조화된 PRD + Claude Code (2시간)

"리셀러 기획 문서 읽어줘" → PRD 자동 파싱 → 3개 코드베이스 동시 탐색 → Spec별 자동 대조 → GAP 리포트 → 즉시 수정 → PR

실제로 저희는 버그 발견부터 수정, PR 생성까지 2시간 만에 끝냈어요. 기존 방식이었다면 QA 단계에서 발견하고, 원인 파악하고, 수정하고... 최소 이틀은 걸렸을 작업입니다.

바이브코딩 시대, 기획 방식은 왜 2005년에 머물러 있나

여기서 한 발 물러서서 큰 그림을 보면, 이상한 점이 보여요.

소프트웨어 기획은 원래 두 축으로 움직입니다. 한쪽엔 문서화(요구사항 정의서, PRD, 최소기능명세서)가 있고, 다른 한쪽엔 시각화(정보구조도, 플로우차트, 와이어프레임)가 있죠. 전통적인 기획 프로세스는 이 두 축을 반복하면서 모호함을 제거하고, 팀 전체가 같은 그림을 보게 만들어요.

그런데 지금 바이브코딩에서 '기획'이라고 부르는 건 뭔가요? 대부분 마크다운 PRD가 고작입니다. 시각화? "AI가 알아서 하겠지"로 넘기는 경우가 대부분이에요.

Springer Nature에 게재된 126개 연구 분석에서도, AI 시스템 개발의 가장 큰 과제는 "요구사항 명세화"와 "ML 엔지니어와 최종 사용자 간의 간극"으로 나타났어요. 개발 도구는 2025년인데, 기획 도구와 방법론은 2005년 수준에 머물러 있는 거죠.

바이브코딩으로 10만 줄의 앱을 만든 Josh Anderson의 경험담이 이 문제를 잘 보여줍니다. 10만 줄에 도달했을 때 그는 더 이상 AI로 코딩하는 게 아니라, 코딩하는 척하는 AI를 관리하면서 실제 작업을 본인이 하고 있었다고 해요. 모든 프롬프트가 도박이었다고요.

코드가 복잡해질수록, 인간 의사결정자가 AI 산출물을 이해하고 검증할 방법이 사라지는 겁니다. 텍스트 PRD만으로는 AI가 만든 복잡한 시스템의 아키텍처, 데이터 흐름, 사용자 경험을 파악할 수 없으니까요.

해답은 '구조화'와 '시각화'의 개선

저희가 이 문제를 직접 겪고 내린 결론은 이렇습니다. 기획서가 AI의 컨텍스트가 되려면 두 가지가 필요해요.

첫째, 구조화. 기획서가 "읽을 수 있는 형태"여야 합니다. Requirement → Feature → Spec 처럼 계층화된 데이터로 정리되어야 AI가 "이 기능은 이 화면에서 이렇게 작동해야 한다"를 이해할 수 있어요. 저희 사례에서 AI가 Paddle 연동 누락을 잡아낸 것도 이 구조 덕분이었죠.

둘째, 시각화. "사용자가 쉽게 로그인할 수 있어야 한다"라고 텍스트로 쓰는 것과, 실제 로그인 화면의 와이어프레임을 보여주는 건 명확성 차원이 완전히 다릅니다. 시각화된 기획은 AI가 해석해야 할 모호함 자체를 줄이고, 의사결정자에게는 AI 산출물을 검증할 기준이 됩니다.

현재 기획 도구의 근본적인 문제는 이 두 가지가 분리되어 있다는 거예요. 한쪽에 Notion이나 Confluence 같은 문서 도구가 있고, 다른 한쪽에 Figma나 Sketch 같은 디자인 도구가 있죠. Mermaid로 플로우차트 만들고, V0.dev로 와이어프레임 만들고, 그걸 또 PRD 문서에 붙이고... 도구가 파편화되니 컨텍스트도 파편화됩니다.

바이브 코딩의 다음 단계, '바이브 기획'

AI 코딩 도구들이 "의도만 말하면 자동으로 코드가 나온다"를 실현했죠. 그 다음 단계는 뭘까요?

"기획서를 입력하면 자동으로 검증이 된다" 입니다.

기획서가 구조화되어 있으면, AI가 읽을 수 있어요. AI가 읽을 수 있으면, 자동 대조가 가능해요. 자동 대조가 가능하면, "기획서에 있었는데요" / "못 봤는데요"의 공방이 사라집니다.

저희는 이걸 바이브 기획(Vibe Planning)이라고 부르기로 했어요. 대충 의도만 말하는 게 아니라, 구조화된 기획서가 AI와 소통하는 시대. 기획서가 죽은 문서가 아니라 살아있는 시스템이 되는 거죠.

오늘 당장 시작할 수 있는 '바이브 기획' 실천법

기획서를 AI에게 읽혀보세요. Claude나 ChatGPT에게 현재 기획서를 붙여넣고 "이 기획서에서 Feature 목록 찾아줘" 그리고 "기능의 우선순위들을 구분해서 구현 우선도를 알려줘"라고 해보세요. 제대로 된 목록과 개발 우선도 및 Scope이 나오면 구조화가 잘 된 거고, 횡설수설하면 AI가 이해 못 하는 형태인 겁니다.

하나의 기능이라도 계층으로 쪼개보세요. "로그인 기능"을 예로 들면, Requirement는 "사용자 인증 시스템", Feature는 "이메일 로그인, 소셜 로그인", Spec은 "이메일 형식 검증, 비밀번호 암호화, 세션 만료 정책"으로 쪼개보는 거예요. 한 번만 해보면, 우리가 생각 없이 작성하고 있던 기획서에 얼마나 많은 "당연히 알겠지" 가정이 숨어있었는지 깨닫게 될 겁니다.

코드 전에 기획서를 먼저 읽히세요. Claude Code나 Cursor 쓸 때, 코드부터 짜달라고 하지 말고 기획서부터 읽히세요. "이 기획서 읽고, 구현해야 할 것들 정리해줘"라고요. AI가 뭘 이해했고 뭘 못 이해했는지 보이면, 기획서의 빈틈이 보입니다.

그래도 어렵다면, AI 기획 에이전트 '매니패스트'를 사용해 보세요.

직접 구조화된 기획서를 작성하고 AI와 대조하는 과정이 여전히 번거롭고 막막하게 느껴지시나요? 파편화된 문서 도구와 디자인 도구를 오가며 컨텍스트를 유지하는 것은 결코 쉬운 일이 아닙니다. 그래서 우리는 이 모든 과정을 시스템화한 매니패스트(Manyfast)를 만들고 있습니다.

매니패스트는 기획을 작성하는 즉시 데이터가 되는 구조화된 기획 환경을 제공합니다. 문서화와 시각화를 동시에 수행하며, AI가 즉시 읽고 코드와 대조할 수 있는 '살아있는 기획서'를 만들어줍니다. "기획서에 있었는데요"라는 공방 대신, AI가 "기획서의 이 Spec이 코드에 누락되었습니다"라고 먼저 말해주는 환경을 경험해 보세요.

바이브 코딩의 시대, 우리는 가장 확실한 기획의 표준을 만들어 나갑니다.