product-playbook 1.0.0

package/i18n/ko/references/04b-solutions.md

@@ -0,0 +1,269 @@
+# 3단계: Develop — 솔루션 설계 및 우선순위 결정
+
+## 3.2 병렬 프로토타이핑 원칙
+
+단일 솔루션을 설계하고 급하게 실행하지 말고 — 여러 가지 병렬 접근법을 동시에 개발하세요:
+
+```
+| HMW 질문 | 솔루션 A (보수적/점진적) | 솔루션 B (균형적) | 솔루션 C (대담한/파괴적) |
+|---------|---------------------|----------------|---------------------|
+| [HMW1] | | | |
+```
+
+세 가지 솔루션 품질 게이트:
+- 솔루션 A가 현재 접근법보다 확실히 나은가?
+- 솔루션 C가 실제로 핵심 JTBD를 해결하는가?
+- 세 가지 솔루션이 진정으로 다른가, 같은 아이디어의 변형인가?
+
+## 3.3 Shreyas Doshi의 Pre-mortem
+
+**적용: 중간/높은 완성도 / 독자가 엔지니어/내부 기획인 경우**
+
+솔루션에 커밋하기 전에, 이미 실패했다고 가정하세요:
+
+```
+가정: 솔루션 X를 선택했고 [기간] 후 실패를 선언했습니다. 왜 실패했을까요?
+
+| 실패 원인 | 가능성 (높음/중간/낮음) | 예방 가능성 (높음/중간/낮음) | 예방 조치 |
+|----------|---------------------|-------------------------|----------|
+| | | | |
+```
+
+**보안 실패 시나리오** (최소 1개 고려 필수, 특히 사용자 데이터를 다루는 제품):
+
+```
+| 보안 리스크 | 가능성 | 예방 가능성 | 예방 조치 |
+|-----------|-------|-----------|----------|
+| 사용자 데이터 유출 (데이터베이스 침입, 무단 API 접근) | | | |
+| 대량 계정 탈취 (무차별 대입, 크리덴셜 스터핑) | | | |
+| API 남용 (속도 제한 없음, 대량 스크래핑) | | | |
+| XSS / CSRF 공격으로 사용자 피해 | | | |
+| 민감한 데이터 우발적 노출 (버전 관리의 시크릿, 로그의 비밀번호) | | | |
+```
+
+> 제품이 사용자 인증이나 민감한 데이터를 다루지 않는 경우, "해당 없음"으로 표시하고 이유를 설명하세요.
+
+## 3.4 Gibson Biddle의 GEM 우선순위 모델 (Netflix)
+
+```
+| 기능 | G (Growth) | E (Engagement) | M (Monetization) | 전체 우선순위 |
+|------|-----------|----------------|------------------|------------|
+| | | | | |
+```
+
+**Impact / Effort 매트릭스:**
+
+```
+| 기능 / 솔루션 | 임팩트 (높음/중간/낮음) | 필요 노력 (높음/중간/낮음) | 사분면 |
+|-------------|---------------------|------------------------|--------|
+| | | | Quick Win / 전략적 / 채우기 / 회피 |
+```
+
+## 3.5 RICE 정량적 우선순위 결정
+
+**적용: 높은 완성도 / 독자가 데이터 사이언티스트/경영진인 경우**
+
+```
+RICE Score = (Reach x Impact x Confidence) / Effort
+
+| 기능 | Reach (월간 영향 사용자) | Impact (0.25/0.5/1/2/3) | Confidence (%) | Effort (인월) | RICE Score |
+|------|----------------------|------------------------|----------------|-------------|------------|
+| | | | | | |
+```
+
+**Impact 척도 정의:**
+| 점수 | 수준 | 기준 |
+|------|------|------|
+| 3 | 대규모 | 사용자 경험을 근본적으로 변화; 핵심 JTBD를 직접 해결 |
+| 2 | 높음 | 사용자 경험을 크게 개선; North Star Metric에 명확한 긍정적 영향 |
+| 1 | 중간 | 체감 가능한 개선; 일부 사용자나 시나리오에 도움 |
+| 0.5 | 낮음 | 소소한 개선; 있으면 좋은 수준 |
+| 0.25 | 최소 | 거의 체감할 수 없는 차이; 유지보수 수준의 작업 |
+
+**Confidence 판단 기준:**
+- 100%: 정량 데이터 지원 (A/B 테스트, 사용자 데이터)
+- 80%: 정성 데이터 지원 (사용자 인터뷰, 경쟁 검증)
+- 50%: 합리적 가설이지만 미검증
+- 20%: 순수한 직감 또는 추측
+
+> "기능의 우선순위를 정하지 마세요 — 문제의 우선순위를 정하세요. 기능은 솔루션이고, 문제의 우선순위를 확인한 후에야 의미가 있습니다." — Shreyas Doshi
+
+## 3.6 User Story 테이블
+
+**적용: 독자가 엔지니어인 경우**
+
+```
+| # | User Story | 인수 기준 | 우선순위 |
+|---|-----------|----------|---------|
+| US1 | [Persona]로서 나는 [행동]을 하고 싶어서 [가치]를 얻고 싶다 | | |
+```
+
+---
+
+## 📄 PRD 출력 형식 (독자가 엔지니어인 경우 사용)
+
+사용자가 "PRD를 작성해 주세요" 또는 "엔지니어용 문서를 작성해 주세요"라고 말하면, 관련 선행 단계를 통합하여 다음 완전한 형식을 작성하세요:
+
+```
+# [제품명] 제품 요구사항 명세서
+
+**버전**: v[X.X]　**날짜**: [날짜]　**작성자**: [PM 이름]
+**상태**: 초안 / 검토 중 / 승인됨
+
+---
+
+## 1. 배경 및 목표
+
+**문제 정의**: [HMW 질문에서 변환 — 누구를 위해 어떤 문제를 해결하는지 한 문단]
+**타겟 Persona**: [어떤 Persona]
+**핵심 JTBD**: [타겟 고객] + 이 원하는 것은 [Job] + [Job 맥락]에서
+**성공 지표**: [North Star Metric + Hero Metric]
+
+---
+
+## 2. 솔루션 개요 (PR-FAQ 기반)
+
+**제품 원라이너**: [PR-FAQ 헤드라인]
+**Aha Moment**: 사용자가 [행동]을 완료했을 때, 핵심 가치를 경험
+**제품 포지셔닝**: [April Dunford 포지셔닝 요약, 완료된 경우]
+
+---
+
+## 3. 기능 범위
+
+### MVP 필수 기능
+| 기능 | 설명 | 우선순위 | 비고 |
+|------|------|---------|------|
+| | | P0 | |
+
+### V2 추가 기능
+| 기능 | 설명 | 우선순위 | 비고 |
+|------|------|---------|------|
+| | | P1 | |
+
+### 명시적 제외 (Not Doing List)
+| 제외 항목 | 이유 |
+|----------|------|
+| | |
+
+---
+
+## 4. User Stories
+
+| # | ...로서 | 나는 ...하고 싶다 | 왜냐하면 ...하기 위해 | 인수 기준 | 우선순위 |
+|---|---------|----------------|---------------------|----------|---------|
+| US-001 | [Persona] | [행동] | [가치] | - [ ] 조건 1 | P0 |
+
+---
+
+## 5. 기능 상세
+
+> 각 P0 기능에 대해 다음을 기록하세요:
+
+### [기능명]
+- **설명**: [이 기능이 하는 것]
+- **트리거 조건**: [언제 트리거되는가]
+- **정상 경로**: [단계 1 → 2 → 3]
+- **엣지 케이스**: [에러 시나리오, 경계 조건]
+- **인수 기준**:
+  - [ ] [구체적 테스트 가능 조건]
+  - [ ] [구체적 테스트 가능 조건]
+
+---
+
+## 6. 기술 고려사항
+
+**알려진 기술 제약**: [엔지니어가 알아야 할 제약]
+**의존성**: [서드파티 서비스, API, 다른 기능의 선행 조건]
+**성능 요구사항**: [로드 타임, 동시성 등, 해당되는 경우]
+**보안 요구사항**: [데이터 보호, 권한 등, 해당되는 경우]
+
+---
+
+## 7. 리스크 및 가정 (Pre-mortem 기반)
+
+| 리스크 | 가능성 | 영향 | 예방 조치 |
+|--------|-------|------|----------|
+| | 높음/중간/낮음 | 높음/중간/낮음 | |
+
+**핵심 가정**: [검증이 필요한 가정 — 틀리면 방향 재검토 필요]
+
+---
+
+## 8. 마일스톤 및 일정
+
+| 마일스톤 | 목표 일자 | 포함 내용 |
+|---------|----------|----------|
+| Alpha | | [최소 테스트 가능 버전] |
+| Beta | | [제한적 사용자 테스트] |
+| Launch | | [공식 출시] |
+
+---
+
+## 9. 미해결 질문
+
+| 질문 | 담당자 | 예상 해결 일자 |
+|------|-------|--------------|
+| | | |
+```
+
+---
+
+## 🗂️ 개발 아티팩트 (필요시 트리거)
+
+### 플로우차트 (Mermaid 구문)
+
+사용자가 "플로우차트를 만들어 주세요"라고 말하면, User Stories와 기능 상세를 기반으로 Mermaid 플로우차트를 생성하세요:
+
+```mermaid
+flowchart TD
+    A[사용자 진입] --> B{로그인 여부?}
+    B -- 예 --> C[메인 화면 표시]
+    B -- 아니오 --> D[로그인으로 리디렉트]
+    C --> E[핵심 행동 완료]
+    E --> F[Aha Moment 도달]
+```
+
+포함: 주요 사용자 플로우 / 핵심 분기점 / 에러 시나리오
+
+### DB Schema (Mermaid ERD 구문)
+
+사용자가 "DB Schema를 만들어 주세요"라고 말하면, MVP 기능 범위를 기반으로 Mermaid erDiagram을 생성하세요:
+
+```mermaid
+erDiagram
+    USER {
+        int id PK
+        string name
+        string email
+        datetime created_at
+    }
+    PRODUCT {
+        int id PK
+        string name
+        int owner_id FK
+    }
+    USER ||--o{ PRODUCT : "owns"
+```
+
+포함: 주요 엔터티 / 관계 / 핵심 필드 (FK, 인덱스 권장사항)
+
+### UI 와이어프레임 (HTML 와이어프레임)
+
+사용자가 "UI 와이어프레임을 만들어 주세요"라고 말하면, HTML + 인라인 CSS로 저충실도 와이어프레임을 출력하세요:
+- 핵심 페이지 (User Stories에 따라 페이지 수 결정)
+- 그레이스케일 색상, 브랜드 색상 없음
+- 각 요소의 기능적 목적 주석
+- Aha Moment이 발생하는 위치 주석
+
+---
+
+## 📎 이 단계의 파일 통합 팁
+
+| 업로드 내용 | 통합 대상 | 통합 작업 |
+|------------|----------|----------|
+| 기존 PRD / 요구사항 문서 | 3.7 MVP | 기존 기능 목록을 MVP 경계 결정 참고자료로 추출 |
+| 기술 아키텍처 문서 | 3.5 RICE (Effort) | 실제 기술 복잡성으로 Effort 점수 평가 |
+| 디자인 목업 / 와이어프레임 | 3.2 병렬 프로토타이핑 + UI 와이어프레임 | 솔루션의 시각적 참고자료로 사용; 기존 vs. 신규 디자인 니즈 식별 |
+| 엔지니어링 공수 추정서 | 3.5 RICE + 3.7 MVP | 가정 기반 Effort를 실제 추정치로 대체; MVP 범위 조정 |
+| 이전 버전 포스트모템 | 3.3 Pre-mortem | 과거 실패 교훈으로 리스크 목록 보완 |

package/i18n/ko/references/04c-mvp.md

@@ -0,0 +1,21 @@
+# 3단계: Develop — MVP 범위 정의
+
+## 3.7 MVP 범위 정의
+
+MVP 결정 기준: **핵심 가설을 검증할 수 있는가? 타겟 사용자가 Primary JTBD를 완전히 경험할 수 있는가?**
+
+```
+| 카테고리 | MVP 필수 | V2 추가 | 향후 고려 |
+|---------|---------|--------|----------|
+| 핵심 기능 | | | |
+| 사용자 경험 | | | |
+| 기술 요구사항 | | | |
+```
+
+**Not Doing List (동등하게 중요):**
+
+```
+| 하지 않는 것 | 이유 |
+|------------|------|
+| | |
+```

package/i18n/ko/references/05a-northstar-aha.md

@@ -0,0 +1,93 @@
+# 4단계: Deliver — North Star + Aha Moment
+
+## 4.1 Marty Cagan의 Empowered Teams 원칙
+
+**적용: 높은 완성도 / 납품 대상이 리더십 또는 크로스펑셔널 팀인 경우**
+
+> 4.1 Empowered Teams는 납품 대상이 리더십 또는 크로스펑셔널 팀인 경우에만 표시; 그 외에는 건너뛰기.
+
+```
+| 차원 | Feature Team (지양) | Empowered Team (목표) |
+|------|-------------------|---------------------|
+| 할당 | 기능 목록 (Output) | 해결할 문제 (Outcome) |
+| 성공 정의 | 기능을 제시간에 전달 | 사용자 및 비즈니스 지표 달성 |
+| PM의 역할 | 요구사항 수집자 및 프로젝트 관리자 | 문제 탐색자 및 솔루션 검증자 |
+| 엔지니어의 역할 | 스펙 실행 | 문제 탐색 및 솔루션 설계에 참여 |
+```
+
+> "진정한 제품 디스커버리는 PM이 혼자 완료된 작업을 넘기는 것이 아니라, 엔지니어와 디자이너와 **함께** 수행하는 것입니다." — Marty Cagan
+
+**Lenny의 PM 3가지 책임:**
+- **Shape**: 사용자 인사이트, 데이터, 시장 정보를 종합하여 무엇을 만들지 결정
+- **Ship**: 고품질 제품이 일정대로 출시되도록 보장, 깜짝 이벤트 없이
+- **Synchronize**: 모든 이해관계자가 비전, 전략, 목표, 로드맵에 정렬되도록 유지
+
+## 4.2 성공 지표 프레임워크 (North Star + 3계층 시그널)
+
+North Star Metric은 다음을 충족해야 합니다:
+- 사용자가 받는 실제 가치를 반영 (허영 지표가 아닌)
+- 지속적으로 성장 가능 (자연적 상한선에 도달하지 않는)
+- 전체 팀을 단일 목표로 정렬
+
+```
+| 회사 | North Star Metric | 이 지표인 이유 |
+|------|-------------------|-------------|
+| Airbnb | 예약된 숙박 수 | 호스트와 게스트 모두에게 전달되는 가치 대표 |
+| Spotify | 월간 청취 시간 | 사용자가 진정으로 음악을 사용하고 즐기는 것을 대표 |
+| Facebook | DAU / MAU 비율 | 습관적 재방문을 대표 |
+| Slack | 주간 발송 메시지 수 | 팀이 진정으로 협업하는 것을 대표 |
+| Salesforce | 활성 고객 ACV (연간 계약 가치) | 고객이 지속적으로 비즈니스 가치를 얻는 것을 대표 (B2B) |
+```
+
+**당신의 North Star Metric:**
+```
+North Star Metric: [사용자와 제품에 제공되는 핵심 가치를 대표하는 단일 숫자]
+정의: [정확한 계산 방법]
+이 지표인 이유: [비즈니스 결과가 아닌 실제 사용자 가치를 대표하는 이유 설명]
+```
+
+### 📝 North Star 품질 체크리스트
+- ✅ 사용자가 받는 가치를 반영하는가? (매출이 아닌, DAU가 아닌)
+- ✅ 지속적으로 성장 가능한가? (자연적 상한선에 도달하지 않는)
+- ✅ 이 지표를 보면 팀 전원이 무엇을 해야 하는지 아는가?
+- ✅ 조작될 수 있는가? (그렇다면 가드레일 지표 필요)
+- ✅ B2B 제품: 개별 사용자가 아닌 조직 수준의 가치를 반영하는가?
+- ❌ 흔한 문제: 매출을 North Star로 사용 (매출은 결과이지 동인이 아님), 지표가 너무 복합적이어서 행동으로 옮길 수 없음
+
+**3계층 시그널 시스템 (반드시 순서대로 달성):**
+
+```
+| 계층 | 지표 유형 | 정의 | B2C 목표 | B2B 목표 |
+|------|----------|------|---------|---------|
+| 1계층 (전제) | 핵심 행동 성공률 | 사용자가 제품의 핵심 행동을 완료했는가? | 30-40%+ | 60-80%+ (사용자 동기가 더 높음) |
+| 2계층 (가치 대리) | D14 / D28 리텐션율 | 사용자가 계속 돌아오는가? | 소비자 제품 15-20%+ | 로고 리텐션 90%+; 순매출 리텐션 100%+ |
+| 3계층 (열정 시그널) | Sean Ellis Score | "이 제품을 더 이상 사용할 수 없다면 얼마나 실망하시겠습니까?" | 40%+가 "매우 실망" 답변 | 40%+가 "매우 실망" 답변 |
+| 가드레일 지표 | 과최적화 방지 | 다른 중요한 차원이 손상되지 않도록 보장 | 맥락에 따라 다름 | 맥락에 따라 다름 |
+```
+
+참고: 1계층은 2계층의 전제입니다. 핵심 행동 성공률이 매우 낮으면, 사용자가 제품의 가치를 경험할 기회가 없었기 때문에 리텐션 데이터는 무의미합니다.
+
+## 4.4 Aha Moment 설계
+
+```
+Aha Moment 정의:
+사용자가 [특정 행동]을 완료하면, 이 제품의 핵심 가치를 경험한 것입니다.
+목표: 제품 진입 후 [X분 / X단계] 이내에 이 순간에 도달하게 하기.
+
+Aha Moment 도달률: [목표 %]
+현재 장벽: [사용자가 Aha Moment에 더 빨리 도달하지 못하게 하는 것]
+개선 계획: [장벽을 어떻게 제거할 것인가?]
+```
+
+**예시:**
+| 제품 | Aha Moment | 시간 목표 |
+|------|-----------|----------|
+| Slack | 팀이 2,000번째 메시지를 보냄 | 첫 2주 이내 |
+| Dropbox | 두 번째 기기에 첫 파일 동기화 | 첫 사용 후 10분 이내 |
+| Zoom | 원클릭 참여로 부드러운 영상 통화 | 첫 사용 |
+
+### 📝 Aha Moment 품질 체크리스트
+- ✅ 구체적이고 추적 가능한 행동인가? ("제품이 유용하다고 느낌"이 아닌)
+- ✅ JTBD의 기능적 Job과 직접 연결되는가?
+- ✅ 시간 목표가 합리적인가? (B2C는 첫 사용 내; B2B는 트라이얼 기간 내일 수 있음)
+- ✅ 사용자가 더 빨리 도달하도록 온보딩을 설계할 수 있는가?

package/i18n/ko/references/05b-pmf-gtm.md

@@ -0,0 +1,102 @@
+# 4단계: Deliver — PMF + GTM + 비즈니스 모델
+
+## 4.3 Todd Jackson의 (First Round Capital) 4단계 PMF 프레임워크
+
+```
+| 단계 | 이름 | 특징 | 해야 할 일 | 전형적 회사 단계 |
+|------|------|------|----------|---------------|
+| Level 1 | 초기 PMF | 솔루션에 기꺼이 비용을 지불할 고객 3-5명 확보 | 이 초기 사용자를 깊이 서비스하고, 반복 가능한 패턴 찾기 | Pre-seed / Seed |
+| Level 2 | 발전하는 PMF | 입소문 시작, 하지만 성장이 아직 불안정 | 확장 가능한 획득 채널 찾기, 리텐션 개선 | Seed / Series A |
+| Level 3 | 강력한 PMF | "물고기가 배에 뛰어들어옴" — 추천이 주요 성장 동력 | 확장 가능한 수요 채널 구축, 효율 지표 개선 | Series A / B |
+| Level 4 | 극강의 PMF | 지표가 견고, 회사 100명 이상, TAM 확장 고려 | 새로운 시장 진출 또는 새 제품 출시 | Series C+ |
+```
+
+**Four P's (Level 1-2에서 PMF를 찾기 위한 핵심 질문):**
+1. Problem: 해결하려는 문제가 정말로 충분히 긴급하고 중요한가?
+2. Promise: 제품이 사용자에게 어떤 약속을 하는가? 그들이 믿는가?
+3. Product: 제품이 실제로 그 약속을 이행하는가?
+4. Pitch: 타겟 사용자가 어떻게 제품을 발견하고 믿게 할 것인가?
+
+## 4.7 GTM 전략 (Go-to-Market)
+
+**적용: 풀 모드 / 높은 완성도 / 독자가 경영진/영업/마케팅인 경우**
+
+제품이 만들어진 후, 타겟 사용자가 어떻게 알고 사용하기 시작하게 할 것인가?
+
+### 획득 채널 선택
+
+```
+| 채널 유형 | 적합한 경우 | 전형적 방법 | 핵심 지표 |
+|----------|-----------|-----------|----------|
+| Product-Led Growth (PLG) | 사용자가 셀프서비스로 가치를 경험할 수 있는 제품 | 무료 체험, Freemium, 바이럴 초대 | 가입 전환율, 활성화율, 초대율 |
+| 콘텐츠 & 커뮤니티 | 타겟 사용자가 공통 정보 니즈나 커뮤니티를 공유 | 블로그, SEO, 커뮤니티 구축, KOL | 트래픽, 콘텐츠 전환율, 커뮤니티 참여도 |
+| 유료 획득 | 빠른 검증이 필요하거나 명확한 ROI | SEM, 소셜 광고, 리타게팅 | CAC, ROAS, LTV/CAC |
+| Sales-Led | B2B 고가 ACV, 데모와 협상 필요 | SDR, AE, 데모, 기업 계약 | 파이프라인, 성사율, ACV |
+| 파트너십 | 타겟 사용자가 특정 플랫폼이나 생태계에 집중 | API 통합, 수익 공유, 공동 마케팅 | 파트너 채널 전환율, 파트너 수 |
+```
+
+### 첫 100명 사용자 획득 계획
+
+```
+타겟 사용자 프로필: [Persona에서]
+어디서 찾을 것인가: [그들이 모이는 온/오프라인 장소]
+어떤 훅으로 끌 것인가: [PR-FAQ의 Aha Moment에서]
+어떻게 체험하게 할 것인가: [진입 장벽을 낮추는 방법]
+초기 목표: [Y일 내에 X명이 제품을 체험]
+```
+
+### 출시 전략
+
+| 전략 | 설명 | 적합한 경우 |
+|------|------|-----------|
+| 클로즈드 베타 | 10-50명을 수동 초대, 심층 피드백 수집 | PMF Level 1, 제품이 아직 다듬어지는 중 |
+| 오픈 베타 | 공개하되 베타 라벨, 기대치 관리 | PMF Level 1-2, 더 많은 데이터 필요 |
+| 소프트 런치 | 특정 시장이나 채널에서 저프로필 런치 | 전면 노출 없이 실제 환경 테스트 필요 |
+| 정식 런치 | 전 채널 공식 출시 | PMF Level 2-3, 제품이 안정적 |
+
+## 4.8 비즈니스 모델 & 프라이싱
+
+**적용: 풀 모드 / 높은 완성도 / 독자가 경영진/영업인 경우**
+
+### 수익 모델 선택
+
+```
+| 모델 | 작동 방식 | 적합한 경우 | 핵심 지표 |
+|------|----------|-----------|----------|
+| Freemium | 무료 기본 + 유료 프리미엄 | 대규모 사용자 베이스, 무료 티어가 가치를 보여줌 | 무료→유료 전환율 (목표 2-5%) |
+| 구독 | 월간/연간 구독 | 지속적 가치를 제공하는 도구 또는 서비스 | MRR/ARR, 이탈률 |
+| 사용량 기반 | 사용한 만큼 결제 | API, 클라우드 서비스, 거래 플랫폼 | 사용자당 평균 지출, 사용량 성장률 |
+| 일회성 구매 | 일괄 구매 | 도구 소프트웨어, 강좌 | 평균 주문 가치, 재구매율 |
+| 거래 수수료 | 거래당 일정 비율 | 플랫폼, 마켓플레이스 | GMV, 수수료율 |
+| 사용자당 과금 | 사용자 수별 과금 | B2B 협업 도구 | 계정당 평균 좌석 수, 확장률 |
+```
+
+### 가치 기반 가격 정렬
+
+```
+핵심 가격 질문:
+1. 제품이 사용자에게 얼마나 절약하거나 벌어주는가? (가치 앵커)
+2. 사용자가 현재 대안에 얼마를 지불하고 있는가? (경쟁 기준)
+3. 가격이 사용자가 받는 가치에 비례하는가? (공정성 인식)
+
+가격 전략:
+  - 모델 선택: [Freemium / 구독 / 사용량 기반 / ...]
+  - 가격 범위: [가치 앵커와 경쟁 기준 기반]
+  - 무료 티어 포함: [Aha Moment에 도달할 수 있되, 고급 니즈에는 충분하지 않게]
+  - 유료 전환 트리거: [어떤 사용 행동이나 사용량이 업그레이드를 트리거하는가?]
+
+⚠️ 흔한 가격 실수:
+  - 가격이 너무 낮음 ("가치가 크지 않다"는 신호)
+  - 무료 티어가 너무 관대 (업그레이드 동기 없음)
+  - 가격-가치 불일치 (기능 기반 vs. 가치 기반 가격 책정)
+  - B2B에서 연간 계약 할인 없음 (현금 흐름 안정성 놓침)
+```
+
+---
+
+## 📎 이 단계의 파일 통합 팁
+
+| 업로드 내용 | 통합 대상 | 통합 작업 |
+|------------|----------|----------|
+| 재무 데이터 / 매출 보고서 | 4.8 비즈니스 모델 | 가정을 실제 매출 구조로 대체, 가격 합리성 평가 |
+| 마케팅 채널 데이터 | 4.7 GTM | 실제 CAC, 전환율 등 데이터로 채널 선택 평가 |

package/i18n/ko/references/05c-validation-spec.md

@@ -0,0 +1,117 @@
+# 4단계: Deliver — 가설 검증 + 제품 스펙 요약
+
+## 4.5 가설 검증 계획
+
+**적용: 중간/높은 완성도 / 독자가 데이터 사이언티스트/본인인 경우**
+
+```
+| 핵심 가설 | 검증 방법 | 검증 시점 | 성공 기준 | 가설이 틀리면... |
+|----------|----------|----------|----------|----------------|
+| | 알파 사용자 인터뷰 / 데이터 | | | |
+```
+
+원칙: 정성적 검증(사용자 인터뷰, 일지 연구) + 정량적 검증(데이터)의 비중은 동등; 자신의 확증 편향에 경계하세요.
+
+## 4.6 제품 스펙 요약
+
+제품 스펙 요약은 모든 모드의 최종 산출물입니다 (퀵 모드는 1페이지 방향 요약을 작성 — 구조는 다르지만 취지는 동일).
+제품 스펙 요약은 세 가지 섹션으로, 각기 다른 읽기 깊이에 대응합니다:
+
+### 섹션 1: 의사결정 요약 (30초 내 읽기 가능)
+
+```
+**제품 원라이너**: [PR-FAQ 헤드라인]
+**대상**: [타겟 Persona 한 문장]
+**핵심 가치**: [JTBD 기능적 Job + 감정적 Job, 한 문장]
+**North Star Metric**: [지표명 + 정의]
+**현재 PMF 수준**: [Level 1-4 + 한 문장 설명]
+```
+
+### 섹션 2: 실행 경계 (2분 내 읽기 가능)
+
+```
+**핵심 JTBD 선언문**: [타겟 고객] + 이 원하는 것은 [Job] + [Job 맥락]에서
+**Aha Moment**: 사용자가 [행동]을 완료하면, 핵심 가치를 경험. 목표: [X] 이내 도달.
+**MVP 필수 기능**: [가장 중요한 기능/역량 3-5개]
+**명시적 제외 (이 버전에서 의도적으로 배제)**: [명시적 제외 항목 + 이유]
+**핵심 가설**: [검증이 필요한 핵심 가설 2-3개]
+**Pre-mortem 상위 리스크**: [가장 가능성 높은 실패 원인 2-3개]
+**Hero Metric**: [가장 중요한 성공 지표 1-2개 + 목표 값]
+```
+
+### 섹션 3: 심층 참조 (필요시 참고)
+
+```
+**JTBD 분석**:
+  - 기능적 Job:
+  - 감정적 Job:
+  - 사회적 Job:
+**April Dunford 포지셔닝**:
+  - 실제 경쟁 대안:
+  - 고유 속성:
+  - 타겟 사용자를 위한 핵심 가치:
+  - 타겟 시장 특성:
+  - 시장 카테고리:
+**핵심 HMW 질문**: [Define 단계에서]
+**솔루션 설명**: [PR-FAQ 요약에서]
+**비즈니스 모델**: [수익 모델 + 가격 전략, 완료된 경우]
+**GTM 전략**: [초기 획득 채널 + 출시 전략, 완료된 경우]
+```
+
+세 가지 섹션을 완료한 후, Claude는 **사용자가 요청하지 않아도 다음 세 가지 섹션을 능동적으로 추가해야 합니다**:
+
+---
+
+### ⚠️ 리스크 레지스터
+
+전체 기획 프로세스에서 식별된 모든 리스크를 통합하세요 (출처: Pre-mortem + 기회 평가 + 가설 검증):
+
+```
+| 리스크 유형 | 리스크 설명 | 심각도 (높음/중간/낮음) | 완화 조치 있음? |
+|-----------|-----------|---------------------|--------------|
+| 시장 리스크 | | | |
+| 사용자 가정 리스크 | | | |
+| 기술 리스크 | | | |
+| 경쟁 리스크 | | | |
+| 실행 리스크 | | | |
+```
+
+---
+
+### 🔍 갭 및 사각지대
+
+Claude는 전체 대화 플로우를 기반으로 다음 유형의 갭을 능동적으로 식별합니다:
+
+```
+| 유형 | 설명 | 권장 다음 단계 |
+|------|------|-------------|
+| 미실행 단계 | [어떤 프레임워크가 건너뛰어졌고 어떤 사각지대를 유발할 수 있는지] | |
+| 불충분한 데이터 | [어떤 결정이 실제 사용자 데이터가 아닌 가정에 기반하는지] | |
+| 논리적 비약 | [추론에 중간 근거가 부족한 부분] | |
+| 미검증 가설 | [아직 검증 방법이 없는 모든 핵심 가설 나열] | |
+| 불명확한 정의 | [실행 전 더 정밀한 정의가 필요한 개념] | |
+```
+
+---
+
+### 💡 추가 권장사항
+
+Claude는 제품의 특성, 단계, 알려진 리스크를 기반으로 3-5개의 구체적이고 실행 가능한 권장사항을 제공합니다:
+
+```
+1. [최우선]: [구체적 행동] — 이유: [왜 이것이 가장 중요한지]
+2. [2순위]: [구체적 행동] — 이유:
+3. [3순위]: [구체적 행동] — 이유:
+...
+```
+
+권장사항은 다음을 포함할 수 있습니다: 사용자 검증 방법, MVP 경계 조정, 경쟁 전략, 지표 설계, 팀 배분, 다음 마일스톤 우선순위.
+
+---
+
+## 📎 이 단계의 파일 통합 팁
+
+| 업로드 내용 | 통합 대상 | 통합 작업 |
+|------------|----------|----------|
+| 사용자 행동 데이터 (CSV / Excel) | 4.2 North Star + 4.3 PMF | 실제 리텐션 및 참여 데이터로 PMF 수준 평가; North Star 기준선 조정 |
+| Sean Ellis 설문 결과 | 4.3 PMF + 4.2 3계층 시그널 | Score를 직접 계산, 3계층에 입력 |