바이브코딩 관련 자료를 검색하면 자주 등장하는 표현이 있습니다. "기획에 90%를 써라." 타당한 표현입니다. 따라서 대부분 요구사항 문서(PRD)를 작성하고 화면 초안을 설계합니다. 기능 목록까지 정리하면 기획이 완료되었다고 판단합니다.
이후 개발은 빠르게 진행됩니다. Cursor에 몇 줄의 지시를 입력하면 수일 내에 앱이 개발됩니다. 그러나 출시 후 1주일이 지나도 이용자가 유입되지 않습니다. 내려받기 수는 변동이 없고 가입자도 재방문하지 않습니다. 이 시점에 다음 의문이 생깁니다. "기획을 했는데 성과가 없는 원인은 무엇인가?"
90%를 투입하라는 그 기획이
요구사항 문서가 아니었기 때문입니다.
요구사항 문서로 답할 수 없는 질문
요구사항 문서의 작성은 중요합니다. 지시가 구체적일수록 AI가 더 정확한 코드를 생성합니다. 화면 흐름까지 미리 설계하면 개발 속도도 향상됩니다.
다만 문서가 정교해도 확인할 수 없는 사항이 있습니다. 앱의 이용자와 기능의 필요성입니다. 요구사항 문서는 개발 대상을 정리하는 문서이며, 개발 목적을 정리하는 문서가 아닙니다.
일반적으로 90%로 인식하는 업무, 실제 비중 10%
요구사항 문서 작성, 화면 초안 설계, 기능 목록 정리
실제 비중 90%의 업무
고객 확인, 문제의 실재 여부 확인, 비용 지불 의향 확인
따라서 실제로 시간을 투입할 업무는 문서 작성 이전 단계입니다. 이 단계가 어려운 이유는 가시적인 결과물이 산출되지 않기 때문입니다. 문서를 작성하면 분량이, 코드를 작성하면 화면이 산출됩니다. 이 단계에는 그러한 결과물이 없습니다. 검토가 내부에서만 진행되므로 생략하는 경우가 많습니다.
코드 작성 이전의 선행 업무
바이브코딩으로 빨라진 것은 개발 단계입니다. Cursor에 몇 가지 지시를 입력하면 화면이 생성되고 기능이 추가됩니다. 이 속도는 강점입니다. 다만 이 속도가 제 역할을 하려면 방향이 먼저 확정되어 있어야 합니다.
개발하려는 앱이 해결하려는 문제가 실재하는지 여부.
해당 문제를 현재 겪고 있는 사람이 실제로 존재하는지 여부.
해당 이용자가 이 문제를 비용을 지불하고 해결할 의향이 있는지 여부.
코드 외부 업무, 90%
이용자 면담 → 문제 확인 → 가설 수립 → 검증
코드 내부 업무, 10%
요구사항 문서 작성 → 코드 작성
이 질문에 대한 답은 Cursor로 확인할 수 없습니다. 현장에서 이용자를 직접 만나야 합니다. 모임에 글을 게시해 반응을 확인해야 합니다. 가설을 수립한 후 직접 검증하는 과정입니다. 이것이 기획의 실제 90%입니다.
이용자가 확정되지 않은 기능 목록의 한계
한 창업자의 사례가 있습니다. 문서에 기능 20개를 정리하였고, 화면 흐름의 정합성과 데이터 구조까지 확정된 상태였습니다. 그러나 앱의 이용자를 질문하자 장시간 답을 하지 못하였습니다. 답변은 다음과 같았습니다.
바이브코딩으로 해당 앱은 1주일 만에 개발됩니다. 그러나 이용자가 없으면 그 1주일은 성과로 이어지지 않습니다. 따라서 코드 작성 전에 이용자를 먼저 만나야 합니다. 이 문제를 겪는 사람을 현장에서 확인하십시오. 오픈채팅에서 반응을 확인하십시오. 그리고 직접 질문하십시오.
"이 기능이 있으면 비용을 지불하고 사용할 것인가." 이 질문에 긍정적인 답을 얻은 후 문서를 작성합니다.
Cursor 사용 전 작성할 세 줄
작성 형식은 무관합니다. 다음 세 줄만 작성하십시오.
이 앱이 해결하려는 문제는 무엇인가.
이 문제를 현재 겪고 있는 사람은 누구인가.
해당 이용자가 현재 이 문제를 어떤 방식으로 해결하고 있는가.
세 줄이 모두 작성되면 1차 출시에 포함할 기능과 제외할 기능이 확인됩니다. 기능 20개를 검토하던 작업이 이 세 줄을 기준으로 2개에서 3개로 압축됩니다. 문서도 이 세 줄을 기준으로 작성하면 내용이 달라집니다.
현재 작성이 어렵더라도 일반적인 상황입니다. 구상은 있으나 문장으로 정리하기 어려운 경우가 많습니다. 다만 외부 검토자가 의미를 확인하는 질문을 하면 1시간에서 2시간 내에 정리되는 사항입니다.
방향 확정 후 바이브코딩 속도의 향상
바이브코딩의 속도를 저하시키는 원인은 코드가 아닙니다. 방향이 확정되지 않은 상태에서 기능 추가와 제거를 반복하는 구조가 속도를 저하시킵니다. 이 반복이 지속되면 바이브코딩의 속도와 무관하게 진척이 없습니다.
반대로 방향이 확정되어 있으면 결과가 달라집니다. 개발할 기능과 이를 사용할 이용자가 정해져 있으면 그 속도가 경쟁력이 됩니다. 동일한 도구를 사용하는데 결과가 상이한 원인은 도구가 아니라 출발점의 차이입니다.
Cursor 사용 전에 앞의 세 줄을 작성하십시오. 작성이 가능하면 그대로 진행합니다. 작성이 어려우면 코드보다 세 줄의 작성이 우선입니다.
기획서와 설계서의 차이는 기획서와 설계서 비교에서 설명합니다. 세 줄의 작성 양식은 아이디어 1장 요약 예시를 참고하십시오. 개발 전후의 전체 과정은 앱, 홈페이지 개발 기획 가이드에 단계별로 정리하였습니다. 코드를 먼저 작성할 때 오류가 발생하는 원인은 MVP 실패를 줄이는 방법에서 설명합니다.
자주 묻는 질문
01기획에 90%를 쓰라는 말에서 기획은 요구사항 문서를 뜻합니까
아닙니다. 요구사항 문서 작성, 화면 밑그림, 기능 목록 정리는 10%에 해당하며, 진짜 90%는 고객이 누구인지 찾고 문제가 진짜인지, 돈을 낼 만큼 불편한지 확인하는 일입니다.
02요구사항 문서(PRD)를 잘 쓰면 무엇이 좋아지나요
지시를 구체적으로 넣을수록 AI가 더 정확한 코드를 만들고 화면 흐름을 미리 그려 두면 만드는 속도도 빨라집니다. 다만 요구사항 문서는 무엇을 만들지 정리하는 문서이며 누가 쓰는지, 왜 필요한지는 알려 주지 않습니다.
03코드를 작성하기 전에 확인할 질문은 무엇입니까
앱이 풀려는 문제가 실제로 있는지, 그 문제를 지금 겪는 사람이 있는지, 그 사람이 돈을 내면서까지 풀고 싶어 하는지 세 가지입니다. 이 질문은 개발 도구가 아니라 사람을 만나고 반응을 확인해서 답합니다.
04Cursor 같은 도구를 열기 전에 적어 둘 세 줄은 무엇입니까
앱이 풀려는 문제, 그 문제를 지금 겪는 사람, 그 사람이 지금 그 문제를 어떻게 풀고 있는지입니다. 세 줄이 적히면 기능 스무 개가 두세 개로 걸러져 첫 판에 넣을 것과 제거할 것이 정해집니다.