바이브코딩 프로젝트를 시작할 때 가장 먼저 할 일: AI와 PRD 작성하기
바이브코딩 프로젝트는 코드를 만들기 전에 AI와 PRD부터 작성하는 편이 좋아요. 사용자와 문제, 핵심 흐름, 첫 버전 범위와 완료 조건을 먼저 정하면 AI의 추측과 뒤늦은 화면·데이터 구조 수정을 줄일 수 있어요.
핵심 요약
- 누구의 어떤 문제를 해결하고 사용자가 얻을 결과가 무엇인지 먼저 정합니다.
- 첫 버전의 핵심 사용자 흐름과 포함할 기능·제외할 기능을 명확히 나눕니다.
- PRD를 프로젝트에 남겨 작업 계획과 완료 조건으로 쓰되 처음부터 완벽하게 만들 필요는 없습니다.
만들고 싶은 아이디어가 생기면 AI에게 바로 이렇게 요청하기 쉽습니다.
아직 만들고 싶은 것이 없다면 PRD보다 먼저 업무와 관심사에서 클로드코드 첫 프로젝트를 찾는 방법을 살펴보세요.
습관 기록 앱을 만들어줘.
AI는 곧바로 화면과 코드를 만들 수 있습니다. 하지만 누구를 위한 앱인지, 어떤 습관을 어떻게 기록하는지, 가장 중요한 기능이 무엇인지는 아직 정하지 않았어요.
정하지 않은 부분은 AI가 추측해서 채웁니다. 처음에는 그럴듯해 보여도 기능을 하나씩 확인하다 보면 생각한 서비스와 다르다는 사실을 발견하게 돼요.
화면을 만든 뒤 기능 변경
→ 데이터 구조 변경
→ 이미 만든 화면 다시 수정
→ 서로 맞지 않는 코드가 늘어남
바이브코딩 프로젝트를 시작할 때 가장 먼저 할 일은 코드를 만드는 일이 아닙니다. AI와 대화하며 PRD를 작성하는 일이에요.
PRD가 무엇인가요?
PRD는 Product Requirements Document의 줄임말입니다. 우리말로는 제품 요구사항 문서라고 해요.
이름은 어렵지만 담는 내용은 단순합니다.
누가 사용하나요?
어떤 문제를 해결하나요?
사용자는 무엇을 할 수 있나요?
처음 만들 기능은 어디까지인가요?
기능이 어떻게 작동해야 하나요?
PRD는 화면 디자인이나 코드 설명서가 아닙니다. 무엇을 왜 만들고, 사용자가 어떻게 이용해야 하는지 정리한 문서예요.
AI에게 코드를 맡기기 전에 PRD가 필요한 이유
AI는 분명한 요구사항이 있을수록 일관된 결과를 만듭니다.
“습관 기록 앱을 만들어줘”라고만 하면 AI가 로그인, 달력, 통계, 친구 기능과 알림까지 마음대로 추가할 수 있어요. 반대로 내가 꼭 필요하다고 생각한 연속 기록이나 하루 한 번만 저장하는 규칙은 빠질 수도 있습니다.
PRD가 있으면 AI가 계속 돌아볼 기준이 생깁니다.
기능을 추가해도 되는가?
→ PRD의 첫 버전 범위 확인
누가 이 화면을 사용하는가?
→ PRD의 사용자 확인
저장 버튼을 두 번 누르면 어떻게 되는가?
→ PRD의 작동 규칙 확인
작업 도중 새로운 생각이 생겨도 현재 범위를 바꿀지, 다음 버전으로 남길지 판단하기 쉬워져요.
처음부터 완벽한 기획서를 쓸 필요는 없어요
PRD를 작성한다고 수십 장짜리 기획서를 혼자 준비할 필요는 없습니다.
처음에는 아이디어를 한 문장으로 설명하세요.
매일 운동했는지 간단히 기록하고
지난 기록을 확인하는 앱을 만들고 싶어.
정보가 부족하면 AI가 질문하게 합니다.
내 아이디어를 바탕으로 PRD를 작성하려고 해.
아직 코드를 만들지 마.
PRD에 필요한 정보가 부족하면 한 번에 질문 하나만 해줘.
내 답을 들은 뒤 다음 질문을 이어가고,
답하지 않은 내용은 임의로 정하지 마.
한 번에 질문을 열 개씩 받으면 답하기 어렵습니다. 질문 하나에 답하고 다음 질문으로 넘어가면 내 생각도 함께 구체화할 수 있어요.
먼저 사용자 및 문제를 정해요
기능 목록부터 만들지 말고 누가 어떤 상황에서 사용할지 정합니다.
사용자
→ 운동을 꾸준히 하고 싶지만 기록이 번거로운 사람
문제
→ 복잡한 운동 앱은 입력할 내용이 많아 며칠 뒤 사용을 멈춤
해결 방법
→ 오늘 운동했는지 짧게 기록하고 연속 기록을 확인함
“누구나 사용하는 앱”처럼 범위를 넓게 잡으면 필요한 기능을 고르기 어렵습니다. 처음에는 가장 먼저 만족시킬 사용자 한 명을 구체적으로 정하는 편이 좋아요.
핵심 사용자 흐름을 한 줄로 연결해요
사용자가 앱을 열고 원하는 결과를 얻을 때까지 어떤 행동을 하는지 순서대로 적습니다.
앱 열기
→ 오늘 운동 입력
→ 기록 저장
→ 연속 운동 일수 확인
핵심 흐름은 프로젝트의 중심입니다. 첫 버전에서는 이 흐름이 처음부터 끝까지 작동하는 것을 목표로 해요.
화면을 많이 만드는 것보다 중요한 행동 하나가 실제로 이어지는 편이 낫습니다.
첫 버전에 넣을 기능과 나중에 만들 기능을 나눠요
아이디어를 이야기하다 보면 필요한 기능이 계속 늘어납니다.
첫 버전에 꼭 필요함
→ 오늘 운동 기록
→ 지난 기록 확인
→ 연속 운동 일수 확인
나중에 추가
→ 친구와 기록 공유
→ 운동 통계
→ 푸시 알림
이번에는 만들지 않음
→ 유료 회원권
→ 운동 영상 추천
PRD에 만들 기능만 적지 말고 이번에는 만들지 않을 기능도 적으세요. AI가 요청하지 않은 기능을 미리 추가하는 일을 막을 수 있습니다.
기능이 작동하는 규칙을 구체적으로 적어요
“기록 기능”이라는 이름만으로는 부족합니다. 같은 말도 사람마다 다르게 이해할 수 있어요.
다음 질문에 답하면서 작동 방식을 정합니다.
- 사용자는 무엇을 입력하나요?
- 꼭 입력해야 하는 값은 무엇인가요?
- 같은 날짜에 여러 번 기록할 수 있나요?
- 저장한 기록을 수정하거나 삭제할 수 있나요?
- 입력에 실패하면 어떤 안내를 보여주나요?
- 로그인하지 않은 사용자는 어디까지 이용할 수 있나요?
예를 들어 “오늘 운동 기록”을 다음처럼 구체화할 수 있습니다.
사용자는 운동 종류와 시간을 입력함
운동 종류는 반드시 선택함
운동 시간은 1분 이상 입력함
하루에 여러 운동을 기록할 수 있음
저장한 기록은 수정하거나 삭제할 수 있음
저장에 실패하면 입력 내용을 유지하고 다시 시도할 수 있음
이 정도로 정리하면 AI가 화면, 데이터와 오류 처리를 같은 기준으로 만들 수 있어요.
PRD에는 이 항목을 넣어요
처음 작성하는 PRD라면 다음 구성이면 충분합니다.
- 제품 한 줄 설명
- 주요 사용자
- 해결하려는 문제
- 핵심 사용자 흐름
- 첫 버전에 넣을 기능
- 나중에 추가할 기능
- 이번에는 만들지 않을 기능
- 필요한 화면
- 기능별 작동 규칙
- 완료했다고 판단할 기준
완료 기준은 “화면을 만들었다”가 아니라 사용자가 원하는 결과를 얻을 수 있는지로 적습니다.
사용자가 운동을 기록할 수 있음
앱을 다시 열어도 저장한 기록이 남아 있음
지난 날짜의 기록을 확인할 수 있음
잘못 입력한 기록을 수정하거나 삭제할 수 있음
AI와 PRD를 작성할 때 사용할 요청문
다음 문장에서 대괄호 안의 내용만 내 아이디어에 맞게 바꿔보세요.
[만들고 싶은 서비스]의 PRD를 함께 작성해줘.
아직 코드를 만들거나 기술을 선택하지 마.
먼저 다음 내용을 파악해야 해.
- 주요 사용자
- 사용자가 겪는 문제
- 서비스가 제공할 해결 방법
- 가장 중요한 사용자 흐름
- 첫 버전에 꼭 필요한 기능
- 나중에 추가할 기능
- 이번에는 만들지 않을 기능
- 필요한 화면
- 기능별 작동 규칙과 예외 상황
- 완료했다고 판단할 기준
정보가 부족하면 한 번에 질문 하나만 해줘.
내가 답하지 않은 내용은 추측해서 확정하지 말고
결정이 필요한 항목으로 표시해줘.
질문이 끝나면 입문자도 읽기 쉬운 PRD로 정리하고
서로 충돌하거나 모호한 요구사항이 있는지도 확인해줘.
AI가 초안을 만들면 바로 개발을 시작하지 말고 내가 실제로 원하는 내용인지 읽어보세요.
특히 “간단하게”, “자동으로”, “관리할 수 있음”처럼 여러 방식으로 해석할 수 있는 표현은 구체적인 행동과 조건으로 바꾸는 편이 좋습니다.
PRD를 프로젝트 안에 보관해요
내용을 확인했다면 AI에게 PRD를 프로젝트 안에 문서로 저장해달라고 요청하세요.
확정한 내용을 프로젝트의 docs/prd.md에 저장해줘.
앞으로 기능을 계획하거나 수정하기 전에 이 문서를 먼저 확인해줘.
터미널에 명령어를 직접 입력할 필요는 없습니다. 사용 중인 바이브코딩 도구가 파일을 만들게 하면 돼요.
PRD는 한 번 작성하고 끝내는 문서도 아닙니다. 사용자 흐름이나 기능 범위를 바꾸기로 했다면 코드만 수정하지 말고 PRD도 함께 업데이트하세요.
요구사항 변경
→ PRD 먼저 수정
→ 영향을 받는 화면·데이터·기능 확인
→ 코드 수정
→ 완료 기준으로 확인
PRD 다음에 기술과 작업 순서를 정해요
PRD를 작성하면 필요한 화면, 저장할 데이터와 서버 기능이 보이기 시작합니다. 이제 요구사항에 맞는 기술 스택을 정하고, 핵심 사용자 흐름을 작은 작업으로 나눌 수 있어요.
화면, 데이터와 기능을 어떤 순서로 나눠야 할지 막막하다면 PRD를 개발 계획으로 바꾸는 방법을 이어서 읽어보세요.
기술 스택이라는 말이 낯설다면 기술 스택이 무슨 뜻인지 설명한 글을, 웹 애플리케이션의 기본 조합이 필요하다면 바이브코딩 기술 스택 추천을 참고하세요.
정리
바이브코딩 프로젝트를 시작할 때 AI에게 곧바로 코드를 만들어달라고 요청하지 마세요.
아이디어 설명
→ AI가 한 번에 질문 하나씩 진행
→ 사용자와 문제 정의
→ 핵심 사용자 흐름 정리
→ 첫 버전의 범위 결정
→ 기능의 작동 규칙과 완료 기준 작성
→ PRD 확인 후 프로젝트에 저장
좋은 PRD는 길고 어려운 문서가 아닙니다. AI와 내가 같은 서비스를 생각하고 있는지 확인할 수 있을 만큼 구체적인 문서예요.
PRD를 먼저 작성하면 AI가 무엇을 만들어야 하는지, 무엇은 아직 만들지 않아야 하는지 분명해집니다. 그때부터 코드를 만들기 시작하세요.
개발 지식이 없어도 시작할 수 있을지 걱정된다면 코딩 경험 없이 바이브코딩을 시작하는 데 필요한 것부터 확인해보세요.
인스타그램 @ddukddak.build · 페이스북 뚝딱








