# 바이브코딩 PRD 템플릿 — 만들기 전에 딱 이만큼만 적으세요

> **이 템플릿을 어떻게 쓰나요?**
> 1. 아래 12개 섹션의 `[대괄호]` 부분을 본인 아이디어로 채웁니다.
> 2. 다 채운 파일을 `prd.md`로 저장합니다.
> 3. Claude Code에 이 파일을 주고 "이 PRD대로 만들어줘"라고 합니다.
>
> **섹션 헤더(01~12)와 번호는 바꾸지 마세요.** Claude Code가 이 번호를 "어디를 만들라는 지시인지" 알아보는 단위로 씁니다.
> 각 섹션마다 **📝 예시**(리뷰답이라는 가상의 서비스로 채워봤어요 — 지우고 본인 것으로)와 **💡 사수 노하우**(15년차 마케터가 실제로 PRD 열 번 넘게 고치며 배운 것)를 넣어뒀습니다.

---

## 시작 전에 — PRD가 뭐고, 왜 이걸 먼저 쓰나

PRD는 Product Requirements Document, 만들기 전에 **무엇을, 왜, 누구를 위해 만드는지** 적어두는 문서예요.

AI한테 "만들어줘"라고 하면 뭐든 하루면 나옵니다. 그래서 다들 이 단계를 건너뛰어요. 머릿속에 그림이 있으니까요. 그런데 만들다 보면 AI가 자꾸 내 생각과 미묘하게 다른 걸 내놓습니다. 고쳐달라 하면 또 다른 게 나오고, 나중엔 내가 뭘 만들려던 건지도 헷갈려요. **방향을 안 정해두면 결과물이 매번 흔들립니다.**

PRD를 쓰는 건 문서 작업이 아니라 **생각을 정리하는 일**이에요. 무엇을 안 만들지, 누구는 고객이 아닌지, 이게 정말 풀 만한 문제가 맞는지. 이걸 글로 적어두면 AI한테도, 나 자신한테도 흔들리지 않는 방향이 생깁니다.

**시간 없으면 딱 다섯 줄만 먼저 적어보세요.** 이 다섯 줄이 이 템플릿 전체의 뼈대예요.
1. 무엇을 만드는가 (한 줄)
2. 왜 만드는가 (누구의 어떤 문제)
3. 누구를 위해 만드는가 (딱 한 명을 떠올려서)
4. 무엇은 안 만드는가 (이게 제일 중요)
5. 무엇이 성공인가 (숫자로)

**이 프로젝트, 잘 됐는지 판단하는 4가지 관점** (KAIST 평가 기준을 빌려왔어요):
돈이 되는가 · 남다른가 · 진짜 만들 수 있는가 · (팀이라면) 역할이 나뉘는가.

---

**팀명:** [혼자면 본인 이름, 팀이면 팀명]

**제품명:** [한 줄 요약 — "무엇을 하는 무엇"]

**작성일:** [YYYY-MM-DD]

---

## 01. 조원 및 소개

| 이름 | 소속 | 역할 | 이메일 |
|---|---|---|---|
| [홍길동] | [본인 브랜드/회사] | [기획·개발·발표] | [me@example.com] |

> 📝 **예시 (리뷰답)**
> | 이름 | 소속 | 역할 | 이메일 |
> |---|---|---|---|
> | 김사장 | 무해상점(1인 스마트스토어) | 전부 혼자 | kim@muhae.kr |

> 💡 **사수 노하우 — 혼자여도 이 표를 채우세요.**
> 1인 창업이면 "혼자 다 함"이라고 쓰면 됩니다. 중요한 건 **뒤에 나오는 12번(역할 분담)과 짝을 맞추는 것**이에요. 혼자라도 "이번 주는 기획자 모드", "이번 주는 개발자 모드"로 역할을 나눠 생각하면 일이 훨씬 안 엉킵니다.

---

## 02. 어떤 분야에 AI를 도입하려고 하는가

[한 문장으로. 예: OOO을 하는 OOO의 OOO 업무에 AI를 도입합니다.]

> 📝 **예시 (리뷰답)**
> 1인 온라인 쇼핑몰 운영자의 **고객 리뷰 답글 작성** 업무에 AI를 도입합니다.

> 💡 **사수 노하우 — "AI를 넣는다"가 아니라 "어떤 업무를 던다"로 쓰세요.**
> "AI 챗봇을 만든다"처럼 기술로 시작하면 방향이 안 잡혀요. "누구의 / 어떤 반복 업무를 / 얼마나 던다"로 쓰면 만들 것이 저절로 좁혀집니다. 한 문장에 업무가 두 개 이상 들어가면 너무 넓은 거예요. 하나로 줄이세요.

---

## 03. 현재 어떤 문제가 있는가

- **고통:** [구체적으로 어떤 업무가 얼마나 힘든가]
- **기존 대안의 한계:** [지금 쓰는 방법이 왜 안 되는가]
- **문제의 규모:** [몇 명이 겪는 문제이며, 연간·월간 얼마나 손해인가]

> 📝 **예시 (리뷰답)**
> - **고통:** 리뷰 하나하나 답글 다는 데 매일 1시간 넘게 쓴다. 늦게 달면 평점·재구매가 떨어지고, 급해서 복붙하면 "성의 없다"는 인상을 준다.
> - **기존 대안의 한계:** 복붙 템플릿은 티가 나고, 챗봇에 매번 리뷰를 붙여넣어 톤을 설명하는 것도 번거롭다. 브랜드 말투가 답글마다 들쭉날쭉하다.
> - **문제의 규모:** 스마트스토어 1인 운영자 수십만 명이 겪는 일상 업무. 하루 1시간이면 한 달 20시간, 최저시급으로만 쳐도 월 20만 원어치 시간.

> 💡 **사수 노하우 — 숫자가 없으면 "진짜 문제"가 아닐 수 있어요.**
> "불편하다"는 문제가 아니라 느낌이에요. "하루 1시간", "월 20만 원어치 시간"처럼 **시간이나 돈으로 환산**되어야 남들도, 나중의 나도 "이건 풀 만하다"고 납득합니다. 환산이 안 되면 아직 문제를 덜 판 거예요. 여기서 막히면 만들기를 멈추고 문제를 더 파세요. 이게 KAIST 평가의 "돈이 되는가(30%)"와 직결됩니다.

---

## 04. 사용자는 누구인가

- **이름:** [김OO, 38세 — 실제 한 명처럼]
- **소속·상황:** [무슨 일을 몇 년째 하는가]
- **일과:** [하루에 어떤 업무를 하는가]
- **지불 의사:** [본인/회사가 얼마까지, 얼마나 자주 낼 수 있는가]

> 📝 **예시 (리뷰답)**
> - **이름:** 김사장, 38세
> - **소속·상황:** 4년차 1인 스마트스토어 운영자. 패션 잡화를 판다.
> - **일과:** 오전 주문 처리·CS, 오후 상품 등록·사진, 저녁에 리뷰 답글 몰아서. 리뷰는 하루 20~40개.
> - **지불 의사:** 시간 아껴주면 월 2~3만 원은 낸다. 무료 체험으로 먼저 써보고 결정.

> 💡 **사수 노하우 — "모두"를 위해 만들면 아무도 안 씁니다.**
> 사용자는 딱 한 명을 아주 구체적으로 떠올리세요. 나이·상황·하루 일과까지. "20~40대 온라인 셀러 전체"보다 "패션 잡화 파는 4년차 1인 셀러 김사장"이 백 배 낫습니다. 구체적인 한 명을 만족시키면 비슷한 사람들이 따라옵니다. 이 사람이 실제로 돈을 낼지(지불 의사)까지 적어야 리뷰답이 취미인지 사업인지 갈립니다.

---

## 05. 문제 해결을 위한 기능

### P0 — 이게 없으면 제품이 아닌 것 (MVP 필수)
- [기능 1]
- [기능 2]
- [기능 3]

### P1 — 있으면 좋음 (나중에)
- [기능 A]

### P2 — 안 만드는 것 (Non-Goals) ⭐
- [하지 않을 것 1]
- [하지 않을 것 2]
- [하지 않을 것 3]

> 📝 **예시 (리뷰답)**
> **P0** — 리뷰를 붙여넣으면 브랜드 톤에 맞춘 답글 3안 생성 / 별점·감정(긍정·부정) 자동 분류 / 부정 리뷰 먼저 보여주기
> **P1** — 내 브랜드 말투 프리셋 저장(다음부터 설명 안 해도 됨)
> **P2 (안 만듦)** — 스마트스토어 자동 발행(직접 붙여넣기로 충분) · 다국어 답글 · 리뷰 자동 수집 크롤링

> 💡 **사수 노하우 — P2(안 만드는 것)를 P0보다 공들여 쓰세요.**
> 대부분 P0(만들 것)만 잔뜩 적고 P2를 비웁니다. 그런데 프로젝트를 망치는 건 "이것도 되면 좋지 않을까"로 계속 붙는 기능이에요. **"안 만든다"고 미리 못 박아두면 AI도 나도 곁길로 안 샙니다.** 특히 바이브코딩은 AI가 요청하지도 않은 기능을 얹어주는 경우가 많아서, P2가 브레이크 역할을 합니다. 첫 버전은 P0 3개 이하로 줄이세요.

---

## 06. 사용자 시나리오

사용자가 처음부터 끝까지 어떻게 쓰는지 순서대로 적습니다.

**Step-by-step:**
- [사용자가 ___ 한다]
- [그다음 ___ 한다]
- [결과를 확인하고 ___ 한다]

> 📝 **예시 (리뷰답)**
> - 김사장이 스마트스토어에서 리뷰 하나를 복사해 리뷰답에 붙여넣는다.
> - 답글 톤(친근함/정중함)을 고른다.
> - 답글 3안이 뜬다. 마음에 드는 걸 골라(또는 살짝 고쳐) 복사한다.
> - 스마트스토어 답글창에 붙여넣고 등록한다.

> 💡 **사수 노하우 — "화면 순서"가 아니라 "사람의 동작"으로 쓰세요.**
> 로그인→메뉴→저장 같은 기계 순서 말고, 김사장이 실제로 손으로 뭘 하는지를 적으세요. 이 시나리오를 소리 내 읽었을 때 어색한 단계가 있으면 거기가 진짜 불편한 지점입니다. 그리고 이 흐름이 다음 07번(화면)을 저절로 정해줍니다 — 동작 하나에 화면 하나.

---

## 07. 화면 정의 ⭐

### 화면 S-001: [화면 이름]
- **목적:** [이 화면이 하는 일 한 줄]
- **동작:** [버튼을 누르면 무엇이 일어나는가]
- **빈 상태:** [아무것도 없을 때 뭐라고 보이는가]
- **에러 상태:** [잘못됐을 때 어떻게 알려주는가]

### 화면 S-002: [다음 화면 이름]
[같은 형식으로]

> 📝 **예시 (리뷰답)**
> **S-001 리뷰 입력**
> - 목적: 리뷰를 붙여넣고 톤을 고르는 화면
> - 동작: "답글 만들기"를 누르면 3안 생성 화면으로 넘어감
> - 빈 상태: "고객 리뷰를 붙여넣어 보세요" 안내문
> - 에러 상태: 리뷰가 비었으면 상단에 "리뷰를 먼저 붙여넣어 주세요"
>
> **S-002 답글 결과**
> - 목적: 답글 3안을 보여주고 복사하게 하는 화면
> - 동작: 답글 카드의 "복사"를 누르면 클립보드에 담김
> - 빈 상태: (해당 없음 — 항상 3안 표시)
> - 에러 상태: 생성 실패 시 "다시 시도" 버튼

> 💡 **사수 노하우 — 빈 상태·에러 상태를 빼먹지 마세요.**
> 초보 PRD는 "잘 될 때"만 그립니다. 그런데 실제로 사람을 당황시키는 건 **아무것도 없는 첫 화면**과 **뭔가 잘못됐을 때**예요. 이 두 개를 미리 정해두면 AI가 만든 결과물이 훨씬 완성도 있게 나옵니다. 비개발자일수록 이 섹션이 특히 중요해요 — 화면을 말로 그려주면 AI가 헤매지 않습니다.

---

## 08. 기술 요구사항 ⭐

### 기술 스택
- **언어:** [모르면 비워두세요]
- **프레임워크:** [ ]
- **DB(데이터 저장소):** [ ]
- **프론트(화면):** [ ]
- **배포(어디에 올릴지):** [ ]

### 데이터 모델
- [저장해야 할 정보 목록 — 예: 리뷰 원문, 생성된 답글, 톤 설정]

### 비기능 요구사항
- 응답 시간 ≤ [1초]
- 동시 사용자 [10명]
- 배포 시간 ≤ 3분
- 오픈소스·무료로 시작 가능한 것만 사용

> 📝 **예시 (리뷰답)**
> **스택:** 언어·프레임워크는 Claude Code가 추천하는 걸로. DB=Supabase, 배포=Vercel(둘 다 무료로 시작 가능).
> **데이터 모델:** 리뷰 원문 / 생성된 답글 3안 / 내 브랜드 톤 프리셋
> **비기능:** 답글 생성 5초 이내, 혼자 쓰니 동시 사용자 1명, 무료 티어로 운영

> 💡 **사수 노하우 — 비개발자면 스택을 억지로 정하지 마세요.**
> 기술 용어를 모르면 이 칸은 **비워두고 Claude Code한테 "가장 쉽고 무료로 시작할 수 있는 스택으로 정해줘"라고 하면** 됩니다. 딱 하나만 못 박으세요: **"공짜로 시작할 수 있게(Vercel·Supabase 무료 티어)."** 이걸 안 적으면 나중에 돈 나가는 서비스로 만들어놓는 경우가 있어요. 데이터 모델은 "무엇을 저장하는지" 목록만 있어도 충분합니다.

---

## 09. 데이터 확보 방안

- **필요한 데이터:** [무엇이 필요한가]
- **출처:** [공개 API · 크롤링 · 합성 · 사용자가 직접 입력 · 실제 데이터]
- **난이도:** [상 · 중 · 하]
- **저작권·개인정보:** [어떻게 처리하는가]

> 📝 **예시 (리뷰답)**
> - 필요한 데이터: 고객 리뷰 텍스트
> - 출처: 사용자(김사장)가 직접 붙여넣음 — 크롤링·수집 안 함
> - 난이도: 하
> - 저작권·개인정보: 리뷰에 이름·연락처가 있으면 저장 전에 가리기(마스킹). 붙여넣은 리뷰는 답글 생성에만 쓰고 따로 쌓아두지 않음.

> 💡 **사수 노하우 — 개인정보는 만들기 전에 정하세요.**
> 고객 데이터를 다루는 서비스는 "나중에 처리하지"가 제일 위험합니다. **사용자가 직접 입력하게 하면** 크롤링 저작권 문제도, 수집 동의 문제도 대부분 사라져요(리뷰답이 크롤링 대신 붙여넣기를 택한 이유). 사람 이름·연락처가 들어올 수 있으면 "저장 안 함" 또는 "가린다"를 여기 명시하세요. 이게 09번을 진지하게 쓰는 이유입니다.

---

## 10. 구현 방안 및 일정

| Phase | 기간 | 목표 | 완료 조건 (숫자로) |
|---|---|---|---|
| Phase 1 | [1일차/1주차] | [화면 뼈대] | [S-001 화면 뜸] |
| Phase 2 | [2일차/2주차] | [핵심 기능] | [답글 3안 실제 생성] |
| Phase 3 | [3일차/3주차] | [연결·다듬기] | [복사→붙여넣기 동작] |
| Phase 4 | [4일차/4주차] | [배포] | [URL로 접속 가능] |

각 Phase는 **5~15분짜리 작은 작업**들로 쪼개서 시킵니다.

> 📝 **예시 (리뷰답)**
> - Phase 1: 리뷰 붙여넣는 화면 만들기 → 완료 = 화면이 뜬다
> - Phase 2: 답글 3안 생성 붙이기 → 완료 = 진짜 답글이 나온다
> - Phase 3: 복사 버튼·부정 리뷰 표시 → 완료 = 손 안 대고 한 바퀴 돈다
> - Phase 4: Vercel 배포 → 완료 = 폰으로 URL 열림

> 💡 **사수 노하우 — "완료 조건"을 눈으로 확인 가능하게 쓰세요.**
> "핵심 기능 구현"은 완료됐는지 알 수가 없어요. "답글 3안이 실제로 나온다", "폰으로 URL이 열린다"처럼 **눈으로 보고 O/X 할 수 있게** 적으세요. 그리고 AI한테는 한 번에 다 시키지 말고 Phase 하나씩, 그 안에서도 5~15분짜리로 쪼개서 시키세요. 크게 시키면 크게 어긋납니다. (이게 "쪼개기·맡기기·남기기"의 쪼개기예요.)

---

## 11. 성과 측정 방법 (KPI)

| KPI | 목표 값 |
|---|---|
| [핵심 시간 절감률] | [≥ 70%] |
| [채택률·정확도] | [≥ 50%] |
| [실패·누락률] | [≤ 5%] |

모두 **기계나 내가 셀 수 있는 숫자**로 적습니다.

> 📝 **예시 (리뷰답)**
> - 답글 작성 시간: 리뷰당 3분 → 30초 (절감률 ≥ 80%)
> - 답글 채택률(거의 안 고치고 그대로 사용): ≥ 50%
> - 부정 리뷰 응답 누락: 0건

> 💡 **사수 노하우 — KPI는 "만들었다"가 아니라 "먹혔다"를 재세요.**
> "기능 3개 완성" 같은 건 KPI가 아니에요. 그건 그냥 할 일 목록이죠. 진짜 KPI는 **사용자의 삶이 숫자로 바뀌었나**입니다. 리뷰답이라면 "시간이 3분→30초로 줄었나". 이 숫자를 미리 정해두면, 다 만들고 나서 "이거 잘 된 건가?"를 감이 아니라 숫자로 판단할 수 있어요. 처음엔 KPI 하나만 있어도 충분합니다.

---

## 12. 역할 분담

| 사람 | 담당 섹션 | 담당 기능 | 작업 범위 |
|---|---|---|---|
| [홍길동] | [전부] | [전부] | [전부] |

> 📝 **예시 (리뷰답 · 1인)**
> | 사람 | 담당 | 언제 |
> |---|---|---|
> | 김사장 | 기획(02~05)은 월요일, 개발(06~10)은 화·수, 검수(11)는 목 | 혼자지만 요일로 역할을 나눔 |

> 💡 **사수 노하우 — 혼자여도 "모드"를 나누세요.**
> 팀이면 이 표대로 사람마다 담당을 나눕니다. 겹치는 코드(Git 커밋 범위)를 미리 나눠두면 서로 안 부딪혀요. **혼자면 요일이나 시간대로 역할을 나누세요** — "지금은 기획자", "지금은 개발자". 이렇게 모드를 갈라두면 기획하다 말고 코드 만지고, 코드 만지다 말고 또 기획을 뒤엎는 악순환이 줄어듭니다. AI 시대의 1인 창업은 결국 **여러 역할을 혼자 번갈아 하는 일**이거든요.

---

## 다 채웠다면

1. 이 파일을 `prd.md`로 저장하세요.
2. Claude Code를 열고 이 파일을 준 뒤 "이 PRD의 Phase 1부터 만들어줘"라고 하세요.
3. 만들다 방향이 흔들리면 코드를 고치지 말고 **PRD를 먼저 고치세요.** PRD가 흔들리면 결과물이 흔들립니다. 저는 이 문서를 열 번 넘게 고쳤어요. 고칠 때마다 생각이 선명해졌습니다.

---

*이 템플릿의 12섹션 뼈대는 KAIST 김재철AI대학원 CAIO 과정 장동인(Dong In Chang) 교수님의 PRD 표준 양식을 바탕으로 했습니다(공유 허락). 예시(리뷰답)와 사수 노하우·코멘트는 에이음이 1인 창업자·바이브코더를 위해 새로 썼습니다.*