AI가 코드를 잘 쓰는지보다 먼저 결정되는 것이 있습니다. 무엇을 만들어야 하는지 얼마나 선명하게 전달했는지입니다. Cursor, Claude Code, Codex, ChatGPT에 “예약 앱 만들어줘”라고 입력하면 그럴듯한 결과는 나올 수 있지만, 실제로 필요한 메뉴, 화면, 저장 데이터, 권한, 예외 상황이 빠져 있으면 곧바로 수정 요청이 반복됩니다.

바이브 코딩에서 기획서는 개발자에게 넘기는 긴 문서라기보다, AI가 오해하지 않도록 기준을 고정하는 작업에 가깝습니다. 문장이 화려할 필요는 없습니다. 대신 “누가”, “어떤 화면에서”, “무엇을 입력하고”, “어떤 데이터가 저장되며”, “문제가 생기면 어떻게 처리할지”가 분명해야 합니다.

왜 기획서가 결과물의 품질을 좌우하나

AI 코딩 도구는 입력된 요구사항을 바탕으로 파일 구조, 화면 구성, 데이터 모델, API 흐름을 추론합니다. 문제는 기획이 비어 있는 부분까지 AI가 알아서 추측한다는 점입니다.

예를 들어 “회원가입 기능을 만들어줘”라고만 하면 다음 항목들이 모두 불명확합니다.

- 이메일 가입인지, 소셜 로그인인지

- 비밀번호 규칙이 있는지

- 닉네임을 받는지

- 가입 후 바로 로그인되는지

- 중복 이메일이면 어떤 문구를 보여줄지

- 탈퇴한 사용자가 재가입할 수 있는지

AI는 이 중 일부를 일반적인 방식으로 채워 넣습니다. 처음에는 편해 보이지만, 나중에 “이건 우리 서비스 방식이 아닌데요”라는 수정이 계속 발생합니다. 그래서 기획서는 AI에게 주는 첫 프롬프트이자, 이후 검수할 때 사용하는 체크리스트가 됩니다.

좋은 기획서는 길이가 아니라 결정된 항목의 수로 판단하는 편이 좋습니다. 아직 결정하지 못한 내용도 “미정”이라고 표시해 두면 됩니다. 미정 항목을 숨기는 것보다, AI에게 “이 부분은 임시로 구현하지 말라”거나 “기본값으로 제안해 달라”고 요청하는 쪽이 훨씬 안전합니다.

메뉴·기능 목록 정리하기

가장 먼저 할 일은 서비스에 들어갈 메뉴와 기능을 나누는 것입니다. 이때 메뉴와 기능을 섞어 쓰면 AI가 화면 구조를 잘못 잡기 쉽습니다.

메뉴는 사용자가 이동하는 큰 영역입니다. 기능은 그 메뉴 안에서 수행하는 행동입니다.

예시로 작은 독서 기록 서비스를 만든다고 가정하면 다음처럼 나눌 수 있습니다.

| 구분 | 내용 |

|---|---|

| 메뉴 | 홈 |

| 기능 | 최근 기록한 책 목록 보기, 읽는 중인 책 보기 |

| 메뉴 | 책 등록 |

| 기능 | 책 제목 입력, 저자 입력, 상태 선택, 저장 |

| 메뉴 | 독서 기록 |

| 기능 | 날짜별 메모 작성, 별점 입력, 기록 수정 |

| 메뉴 | 마이페이지 |

| 기능 | 프로필 확인, 로그아웃, 계정 탈퇴 |

이 단계에서 중요한 것은 “있으면 좋겠다”와 “반드시 필요하다”를 구분하는 것입니다. AI에게 한 번에 모든 기능을 맡기면 화면과 코드가 불필요하게 커질 수 있습니다. 입문 단계에서는 우선순위를 표시하는 방식이 좋습니다.

| 우선순위 | 의미 | 예시 |

|---|---|---|

| 필수 | 첫 버전에 반드시 포함 | 책 등록, 목록 조회, 기록 작성 |

| 선택 | 시간이 있으면 포함 | 책 표지 이미지 업로드 |

| 제외 | 지금은 만들지 않음 | 다른 사용자 팔로우, 추천 알고리즘 |

“제외” 항목을 적는 것도 도움이 됩니다. AI는 흔한 서비스 패턴을 따라 댓글, 좋아요, 관리자 페이지 같은 기능을 임의로 제안할 수 있습니다. 만들지 않을 기능을 명시하면 범위가 안정됩니다.

화면(UI)과 사용자 흐름 정의

기능 목록만으로는 실제 화면이 어떻게 이어지는지 알기 어렵습니다. 화면 정의는 사용자가 어떤 순서로 움직이는지 보여주는 작업입니다.

복잡한 와이어프레임을 그릴 필요는 없습니다. 처음에는 화면 이름, 화면 목적, 주요 요소, 이동 경로만 적어도 충분합니다.

| 화면 | 목적 | 주요 요소 | 이동 |

|---|---|---|---|

| 홈 화면 | 독서 현황 확인 | 최근 기록 목록, 책 추가 버튼 | 책 등록 화면, 기록 상세 화면 |

| 책 등록 화면 | 새 책 저장 | 제목 입력, 저자 입력, 상태 선택, 저장 버튼 | 저장 후 홈 화면 |

| 기록 상세 화면 | 책별 기록 확인 | 책 정보, 메모 목록, 기록 추가 버튼 | 기록 작성 화면 |

| 기록 작성 화면 | 독서 메모 저장 | 날짜, 메모, 별점, 저장 버튼 | 저장 후 기록 상세 화면 |

여기서 AI가 특히 필요로 하는 정보는 버튼을 눌렀을 때의 결과입니다. “저장 버튼이 있다”보다 “저장 버튼을 누르면 입력값을 검증한 뒤 DB에 저장하고 홈 화면으로 이동한다”가 훨씬 명확합니다.

사용자 흐름은 짧은 문장으로 적으면 됩니다.

1. 사용자는 홈 화면에 들어온다.

2. 책 추가 버튼을 누른다.

3. 책 제목과 저자를 입력한다.

4. 읽기 상태를 선택한다.

5. 저장 버튼을 누른다.

6. 입력값이 정상이라면 책이 저장되고 홈 화면으로 이동한다.

7. 제목이 비어 있으면 저장하지 않고 오류 문구를 보여준다.

이 정도만 있어도 ChatGPT나 Claude Code에 “이 흐름을 기준으로 화면과 컴포넌트를 설계해 달라”고 요청할 수 있습니다. Cursor나 Codex에서 구현을 맡길 때도 화면 단위 작업 지시가 쉬워집니다.

데이터(DB) 구조와 저장 항목

서비스는 결국 데이터를 저장하고 불러오는 구조로 움직입니다. 개발 경험이 없으면 DB 설계가 어렵게 느껴질 수 있지만, 처음에는 “무엇을 저장해야 하는가”부터 적으면 됩니다.

독서 기록 서비스라면 최소한 다음 데이터가 필요합니다.

| 데이터 묶음 | 저장 항목 |

|---|---|

| 사용자 | 사용자 ID, 이메일, 닉네임, 가입일 |

| 책 | 책 ID, 사용자 ID, 제목, 저자, 읽기 상태, 등록일 |

| 독서 기록 | 기록 ID, 책 ID, 날짜, 메모, 별점, 작성일 |

여기서 ID는 각 데이터를 구분하기 위한 고유값입니다. 사용자 ID가 책에 들어가면 “이 책은 어떤 사용자가 등록했는지” 알 수 있습니다. 책 ID가 독서 기록에 들어가면 “이 기록은 어떤 책에 속하는지” 연결할 수 있습니다.

AI에게 DB 구조를 맡길 때는 다음을 함께 적어야 합니다.

- 필수 입력값: 비어 있으면 안 되는 값

- 선택 입력값: 없어도 저장 가능한 값

- 기본값: 사용자가 입력하지 않았을 때 들어가는 값

- 관계: 어떤 데이터가 어떤 데이터에 연결되는지

- 삭제 방식: 삭제 시 완전히 지울지, 숨김 처리할지

예를 들어 책 제목은 필수, 저자는 선택, 읽기 상태는 기본값을 “읽는 중”으로 둘 수 있습니다. 이런 기준이 없으면 AI가 임의로 필수값을 정하거나, 삭제 방식까지 단순하게 처리할 수 있습니다.

DB를 문장으로만 설명하면 누락이 생기기 쉽습니다. 표 형태로 적으면 AI가 구조를 파악하기 쉽고, 나중에 실제 코드와 비교하기도 편합니다.

| 항목 | 타입 설명 | 필수 여부 | 비고 |

|---|---|---|---|

| title | 책 제목 | 필수 | 빈 문자열 저장 불가 |

| author | 저자 | 선택 | 모르면 비워둘 수 있음 |

| status | 읽기 상태 | 필수 | 읽는 중, 완료, 보류 중 하나 |

| createdAt | 등록일 | 필수 | 생성 시 자동 저장 |

타입 설명은 처음부터 전문 용어로 완벽히 쓸 필요는 없습니다. “문자”, “날짜”, “숫자”, “참/거짓” 정도로 적어도 AI가 구체적인 DB 타입으로 변환하는 데 도움이 됩니다.

예외 상황·권한·정책 명시

초보자가 가장 자주 빠뜨리는 부분이 예외 상황입니다. 정상 흐름만 적으면 화면은 만들어지지만, 실제 사용 중 문제가 생겼을 때 서비스가 쉽게 깨집니다.

책 등록 기능만 봐도 다음 예외가 있습니다.

| 상황 | 처리 방식 |

|---|---|

| 제목을 입력하지 않음 | 저장하지 않고 “책 제목을 입력해 주세요” 표시 |

| 메모가 너무 김 | 저장 제한 또는 글자 수 안내 |

| 네트워크 오류 | “잠시 후 다시 시도해 주세요” 표시 |

| 이미 삭제된 책의 기록 접근 | 홈 화면으로 이동 또는 오류 화면 표시 |

| 로그인하지 않은 사용자 접근 | 로그인 화면으로 이동 |

권한도 반드시 적어야 합니다. 특히 사용자별 데이터가 있는 서비스라면 “내 데이터만 볼 수 있다”는 조건을 분명히 해야 합니다.

예시는 다음과 같습니다.

| 대상 | 권한 |

|---|---|

| 비로그인 사용자 | 로그인 화면만 접근 가능 |

| 로그인 사용자 | 본인이 등록한 책과 기록만 조회, 수정, 삭제 가능 |

| 다른 사용자 데이터 | 조회, 수정, 삭제 불가 |

| 관리자 | 이번 버전에서는 없음 |

정책은 서비스의 운영 기준입니다. 예를 들어 계정 탈퇴 시 데이터를 즉시 삭제할지, 일정 기간 보관할지, 사용자가 작성한 기록도 함께 삭제할지 같은 내용입니다. 입문 단계에서 법률적 세부 정책까지 깊게 다룰 필요는 없지만, 기능 구현에 직접 영향을 주는 기준은 적어야 합니다.

기획서 마지막에는 AI에게 전달할 수 있는 작업 범위를 붙이면 좋습니다.

- 첫 버전은 로그인, 책 등록, 책 목록, 독서 기록 작성까지만 포함한다.

- 이미지 업로드, 팔로우, 추천 기능은 제외한다.

- 모든 데이터는 로그인한 사용자 본인 것만 접근할 수 있어야 한다.

- 입력값이 잘못된 경우 저장하지 않고 사용자에게 이유를 보여준다.

- 화면은 모바일 기준으로 먼저 구성한다.

이 정도의 기획서가 있으면 AI에게 “서비스를 만들어줘”가 아니라 “이 기준에 맞춰 구현해 달라”고 요청할 수 있습니다. 결과물도 더 안정적이고, 수정 요청도 구체적으로 바뀝니다. 기획서는 개발 전에 한 번 쓰고 끝나는 문서가 아니라, AI가 만든 결과물이 의도와 맞는지 확인하는 기준표로 계속 사용됩니다.