@didim365/agent-cli-core 0.1.0

package/dist/docs/00_project/white_labeling/template/00_vibecoding_workflow.md

@@ -0,0 +1,627 @@
+## _TDD 기반 설계 중심 · 인간 검증 중심 · 다중 AI 순환 개발 방법론_
+
+> "빠르게 짜는 방법"이 아니라  
+
+> **"빠르게 설계하고, 빠르게 검증하고, 빠르게 수정하는 구조"**
+
+---
+
+## 슬라이드 1. 기존 바이브코딩의 진짜 문제
+
+❌ 문제의 본질은 **속도**가 아니다  
+
+❌ 문제의 본질은 **검증 구조의 부재**
+
+**정리**
+
+- AI는 빠르다
+- 하지만 **틀린 방향으로도 매우 빠르다**
+- 방향을 잡는 구조가 없으면 → 실패 속도만 빨라진다
+
+> 👉 그래서 이 방법론은 "속도"가 아니라 **"짧은 검증 순환"을 목표로 한다**
+
+---
+
+## 슬라이드 2. R2-D2란 무엇인가?
+
+### **R**ecursive **R**eview - **D**esign **D**riven (TDD)
+
+|      |                    |                         |
+| ---- | ------------------ | ----------------------- |
+| 약어 | 의미               | 설명                    |
+| R2   | Recursive Review   | 다중 AI 순환 검증 구조  |
+| D2   | Test Design Driven | TDD 기반 설계 중심 개발 |
+
+**핵심 정의**
+
+> R2-D2는 AI가 생성한 결과물을    
+> **다른 AI로 교차 검증**하고,    
+> **인간이 최종 승인**하는    
+> **설계 중심 순환 개발 프레임워크**이다.
+
+---
+
+## 슬라이드 3. 이 방법론의 핵심은 3가지다
+
+### ❌ "AI를 잘 쓰는 방법론" 아님
+
+### ⭕ **"검증을 구조화한 TDD 기반 개발 방법론"**
+
+| 핵심 원칙      | 설명                                      |
+| -------------- | ----------------------------------------- |
+| TDD 기반       | 테스트 = AI를 위한 설계 명세이자 가드레일 |
+| 인간 검증 중심 | 최종 판단은 항상 인간                     |
+| 다중 AI 순환   | 교차 검증으로 편향 제거                   |
+
+---
+
+## 슬라이드 4. R2-D2 방법론의 기반 문서 체계
+
+| 문서              | 역할                            | 파일                                                                         |
+| ----------------- | ------------------------------- | ---------------------------------------------------------------------------- |
+| TDD 방법론        | Kent Beck TDD + Tidy First 원칙 | [99_TDD_plan.md](./99_TDD_plan.md)                                           |
+| 성능 가이드       | 파이썬 성능 최적화 기준         | [100_Python_Performance_Guide.md](./100_Python_Performance_Guide.md)         |
+| 작업계획서 템플릿 | 단계별 작업 계획 구조           | [01_todolist_performance_template.md](./01_todolist_performance_template.md) |
+| 코드리뷰 템플릿   | AI 코드 리뷰 구조               | [02_code_review_template.md](./02_code_review_template.md)                   |
+| 작업결과서 템플릿 | 작업 결과 기록 구조             | [03_work_result_report_template.md](./03_work_result_report_template.md)     |
+
+> 💡 이 문서들이 **AI 에이전트의 가드레일**이자 **인간 검증의 기준**이 된다
+
+---
+
+## 슬라이드 5. 왜 TDD가 이 방법론의 중심인가
+
+**일반적인 오해**
+
+- TDD = 테스트 많이 쓰는 개발 방식 ❌
+
+**R2-D2에서의 TDD**
+
+- **설계 중심 개발** — 테스트가 "무엇을 만들어야 하는지" 정의
+- **빠른 실패 → 빠른 수정** — 짧은 사이클로 방향 검증
+- **AI의 가드레일** — 테스트 범위 안에서만 AI가 작동
+
+---
+
+## 슬라이드 6. TDD = AI를 위한 설계 명세이자 가드레일
+
+R2-D2에서 TDD는:
+
+- "이 기능을 어떻게 구현할까?" ❌ (구현 중심 사고)
+- **"이 기능의 설계를 어떻게 정의하고, AI가 이를 따르게 할까?" ⭕** (설계 +
+  가드레일)
+
+👉 테스트는 단순 검증이 아니라 **AI를 위한 설계 명세이자 가드레일**
+
+**TDD의 3가지 역할**
+
+| 역할      | 설명                                       |
+| --------- | ------------------------------------------ |
+| 설계 정의 | 테스트 = "무엇을 만들어야 하는지"의 명세   |
+| 빠른 검증 | 작은 단위로 설계 의도대로 구현됐는지 확인  |
+| 가드레일  | AI가 설계 범위를 벗어나지 않도록 경계 설정 |
+
+**한 문장 정의**
+
+> _TDD는 AI가 코드를 쓰는 시대에,_    
+> _인간이 설계를 정의하고, AI가 그 안에서만 움직이도록_    
+> _가드레일을 세우는 장치다._
+
+📄 참고: [99_TDD_plan.md](./99_TDD_plan.md)
+
+---
+
+## 슬라이드 7. TDD의 짧은 순환 구조 (Red → Green → Refactor)
+
+`설계 가설     ↓ 🔴 실패 테스트 작성 (Red)     ↓ 🟢 최소 구현 (Green) — "Make it work"     ↓ 🔵 구조/성능 개선 (Refactor) — "Make it right, Make it fast"     ↓ 다음 설계 가설`
+
+**TDD 핵심 원칙** ([99_TDD_plan.md](./99_TDD_plan.md) 발췌)
+
+| 원칙                  | 설명                                                 |
+| --------------------- | ---------------------------------------------------- |
+| Red First             | 반드시 **실패하는 테스트**를 먼저 작성               |
+| Minimal Green         | 테스트를 통과하는 **최소한의 코드만** 구현           |
+| Safe Refactor         | 테스트가 **통과하는 상태에서만** 리팩터링            |
+| Tidy First            | 구조 변경(Structural)과 동작 변경(Behavioral) 분리   |
+| **Commit Discipline** | **작업 단계 완료 시에만** 커밋 (아래 조건 충족 필수) |
+
+**커밋 규율** (Commit Discipline)
+
+> ⚠️ **커밋은 반드시 사용자 승인 완료 후에만 수행**
+
+| 조건                 | 설명                                                                                    |
+| -------------------- | --------------------------------------------------------------------------------------- |
+| ✅ 모든 테스트 통과  | 테스트가 실패한 상태로 커밋 금지                                                        |
+| ✅ 린터 경고 0개     | 모든 경고 해결 후 커밋                                                                  |
+| ✅ 다중 AI 리뷰 완료 | 리뷰 피드백 반영 완료 ([02_code_review_template.md](./02_code_review_template.md) 활용) |
+| ✅ 사용자 최종 승인  | 인간이 검토하고 승인한 후에만 커밋                                                      |
+| ✅ 단일 논리 단위    | 하나의 변경 목적만 포함                                                                 |
+
+`# ❌ BAD: 테스트 실패 상태로 커밋 git commit -m "WIP: 작업 중"  # ✅ GOOD: 단계 완료 후 커밋 git commit -m "[Phase1-Green] 사용자 인증 최소 구현 완료" git commit -m "[Phase1-Refactor] 인증 로직 구조 개선"`
+
+**롤백 규율** (Rollback Discipline)
+
+> 🔄 **작업이 잘못된 방향으로 진행 시 즉시 롤백**
+
+| 상황                                 | 조치                               |
+| ------------------------------------ | ---------------------------------- |
+| AI가 지속적으로 잘못된 방향으로 진행 | git reset --hard HEAD 후 재시작    |
+| 테스트가 계속 실패하고 해결 불가     | 작업 직전 커밋으로 롤백            |
+| 설계 방향 자체가 잘못됨              | PRD 또는 작업계획서 재검토 후 롤백 |
+
+`# 작업 직전 상태로 롤백 (변경사항 폐기) git reset --hard HEAD  # 특정 커밋으로 롤백 git reset --hard <commit-hash>  # 변경사항 보존하며 롤백 (재작업용) git reset --soft HEAD~1`
+
+> 💡 **핵심**: 잘못된 방향으로 계속 진행하는 것보다 **빠르게 롤백하고
+> 재시작**하는 것이 효율적
+
+**권장 사이클 시간**
+
+| 작업 유형     | 권장 시간            |
+| ------------- | -------------------- |
+| 단순 기능     | 15-30분              |
+| 복잡 로직     | 30-60분              |
+| 아키텍처 변경 | 60-120분 (분할 권장) |
+
+---
+
+## 슬라이드 8. AI 검증의 핵심 원칙
+
+> **같은 AI가 자신의 결과를 검증하면 안 된다.**    
+> **다른 AI가 교차 검증 도구로 사용되어야 한다.**    
+> **최종 검증 주체는 항상 인간이다.**
+
+**왜 다른 AI로 검증하는가?**
+
+| 문제                      | 해결                       |
+| ------------------------- | -------------------------- |
+| 동일 모델 → 동일 편향     | 서로 다른 모델로 교차 검증 |
+| 같은 프롬프트 → 같은 실수 | 다른 관점의 프롬프트 사용  |
+
+👉 결과가 같으면 **신뢰도 상승**  
+
+👉 결과가 다르면 **설계 의심 신호**
+
+---
+
+## 슬라이드 9. R2-D2 전체 프로세스 (10단계)
+
+```mermaid
+flowchart TD
+  subgraph PHASE1["Phase 1: PRD 작성 및 검증"]
+    A1[1. 사용자: PRD 초안 작성<br/>01_basic_project_plan]
+    A2[2. 다른 AI: PRD 리뷰 및 개선]
+    A3[3. 사용자: PRD 최종 승인]
+    A1 --> A2 --> A3
+    A2 -.->|개선 필요| A1
+  end
+
+  subgraph PHASE2["Phase 2: 작업계획서 작성 및 검증"]
+    B1[4. 작업계획서 작성<br/>01_todolist_performance_template.md]
+    B2[5. 다른 AI: 작업계획서 리뷰]
+    B3[6. 사용자: 작업계획서 승인]
+    B1 --> B2 --> B3
+    B2 -.->|개선 필요| B1
+  end
+
+  subgraph PHASE3["Phase 3: 작업 실행 (TDD 순환)"]
+    C1[7. 사전작업 🔴<br/>컨텍스트 수집 + 테스트 작성]
+    C2[8. 본작업 🟢<br/>최소 구현]
+    C3[9. 사후작업 🔵<br/>리팩터링 + 결과서 작성]
+    C1 --> C2 --> C3
+  end
+
+  subgraph PHASE4["Phase 4: 검증 및 순환"]
+    D1[10. 다른 AI: 작업결과서 기반 리뷰]
+    D2{문제 발견?}
+    D3[사용자: Step 완료 승인]
+    D4[✅ 커밋]
+    D1 --> D2
+    D2 -->|YES 수정가능| C2
+    D2 -->|NO| D3
+    D3 --> D4
+  end
+
+  subgraph ROLLBACK["롤백 분기"]
+    R1{방향이 잘못됨?}
+    R2[git reset --hard]
+    R3[작업 직전 상태로 복원]
+    R1 -->|YES| R2 --> R3
+  end
+
+  A3 --> B1
+  B3 --> C1
+  C3 --> D1
+  D2 -->|YES 방향 잘못| R1
+  R3 -->|재시작| C1
+  D4 -->|다음 Step| C1
+  D4 -->|완료| E[릴리즈]
+```
+
+---
+
+## 슬라이드 10. Phase 1 — PRD 작성 및 다중 AI 검증
+
+### Step 1-3: PRD 순환
+
+| Step | 담당    | 내용                                  |
+| ---- | ------- | ------------------------------------- |
+| 1    | 사용자  | PRD 초안 작성 (01_basic_project_plan) |
+| 2    | 다른 AI | PRD 리뷰 및 개선 의견 도출            |
+| 3    | 사용자  | PRD 최종 검증 및 승인                 |
+
+**PRD 리뷰 포인트**
+
+- 요구사항의 명확성
+- 기술적 실현 가능성
+- 누락된 케이스/예외 상황
+- 성능 요구사항 명시 여부
+
+> 💡 PRD가 명확해야 **테스트(가드레일)도 명확**해진다
+
+---
+
+## 슬라이드 11. Phase 2 — 작업계획서 작성 및 검증
+
+### Step 4-6: 작업계획서 순환
+
+| Step | 담당      | 내용                                                                                           |
+| ---- | --------- | ---------------------------------------------------------------------------------------------- |
+| 4    | 사용자/AI | 작업계획서 작성 ([01_todolist_performance_template.md](./01_todolist_performance_template.md)) |
+| 5    | 다른 AI   | 작업계획서 리뷰 및 검증                                                                        |
+| 6    | 사용자    | 작업계획서 최종 승인                                                                           |
+
+**작업계획서 구조**
+([01_todolist_performance_template.md](./01_todolist_performance_template.md)
+기반)
+
+`Phase N: [Phase 제목] ├── N.1 사전 작업 (Pre-Work) │   ├── [CONTEXT] 작업 목적 및 배경 확인 │   ├── [REVIEW] 이전 작업 결과서 검토 │   └── [ANALYSIS] 현재 코드/설정 분석 ├── N.2 🔴 RED Phase: 실패 테스트 작성 ├── N.3 🟢 GREEN Phase: 최소 코드 구현 ├── N.4 🔵 REFACTOR Phase: 코드 개선 + 성능 최적화 └── N.5 사후 작업 (Post-Work)     ├── [TEST] 전체 테스트 실행     ├── [DOC] 작업 결과서 작성     └── [COMMIT] 변경사항 커밋`
+
+---
+
+## 슬라이드 12. Phase 3 — 작업 실행 (사전 → 본작업 → 사후)
+
+### 작업 단위의 3단계 = TDD 사이클
+
+| 단계          | TDD 매핑    | 역할                         | 원칙                               |
+| ------------- | ----------- | ---------------------------- | ---------------------------------- |
+| **사전 작업** | 🔴 Red      | 컨텍스트 수집 + 테스트 작성  | 이전 결과서 참조, 실패 테스트 먼저 |
+| **본 작업**   | 🟢 Green    | 최소 구현                    | "Make it work" — 동작 우선         |
+| **사후 작업** | 🔵 Refactor | 구조/성능 개선 + 결과서 작성 | "Make it right, Make it fast"      |
+
+**사전 작업 체크리스트**
+
+PRD 문서 검토
+
+**이전 작업 결과서 확인** (Phase 2 이후 필수)
+
+현재 코드/설정 분석
+
+🔴 실패 테스트 작성 및 실패 확인
+
+**본 작업 체크리스트**
+
+🟢 테스트를 통과하는 **최소한의 코드** 구현
+
+테스트 통과 확인
+
+**사후 작업 체크리스트**
+
+🔵 코드 구조 개선 (중복 제거, 네이밍, 책임 분리)
+
+🔵 성능 최적화 적용
+([100_Python_Performance_Guide.md](./100_Python_Performance_Guide.md) 참조)
+
+테스트 재확인 (여전히 PASS)
+
+린터 검사 통과 (경고 0개)
+
+**작업 결과서 작성**
+([03_work_result_report_template.md](./03_work_result_report_template.md))
+
+다중 AI 리뷰 요청 → 피드백 반영
+([02_code_review_template.md](./02_code_review_template.md))
+
+**사용자 최종 승인** ← 여기서 검토!
+
+**커밋** (승인 완료 후에만)
+
+  `git commit -m "[Phase{N}-{단계}] {작업 내용} 완료"`
+
+> 🔄 **롤백 판단**: 작업이 잘못된 방향이면 즉시 git reset --hard HEAD 후 재시작
+
+---
+
+## 슬라이드 13. Refactor 단계의 성능 최적화 (Make it fast)
+
+> 📄 참고: [100_Python_Performance_Guide.md](./100_Python_Performance_Guide.md)
+
+**Refactor 원칙**: 먼저 동작(Green) → 구조 개선(Right) → **성능 최적화(Fast)**
+
+| 패턴          | Before       | After          | 개선        | ⚠️ 주의         |
+| ------------- | ------------ | -------------- | ----------- | --------------- |
+| 멤버십 검사   | if x in list | if x in set    | O(1)        | 반복 검사 시만! |
+| 리스트 생성   | for + append | 컴프리헨션     | ~20-30%↑    |                 |
+| JSON 처리     | json.dumps() | orjson.dumps() | ~8배↑       | **bytes 반환**  |
+| 대량 인스턴스 | 일반 클래스  | **slots**      | 메모리 50%↓ | 제약사항 확인   |
+
+**성능 최적화 프로세스**
+
+`1. 측정 (Baseline) → 2. 분석 (체크리스트) → 3. 최적화 → 4. 검증 (테스트 + 성능)`
+
+> ⚠️ **주의**: 성능 수치는 환경별로 다름. **본인 환경에서 측정 후 적용**
+
+---
+
+## 슬라이드 14. Phase 4 — 작업결과서와 다중 AI 리뷰
+
+### Step 10: 작업결과서 기반 검증
+
+**작업결과서의 2가지 역할**
+
+| 역할              | 설명                                               |
+| ----------------- | -------------------------------------------------- |
+| **RAG 컨텍스트**  | 다음 작업의 사전작업에서 참조 → 판단의 연속성 유지 |
+| **리뷰 기준자료** | 다른 AI가 코드를 리뷰하는 기준                     |
+
+**작업결과서 구조**
+([03_work_result_report_template.md](./03_work_result_report_template.md) 기반)
+
+`Step X.X: [작업명] 작업 기록 ├── 📋 작업 개요 (목표, 범위) ├── 🔴 Red Phase (테스트 작성) ├── 🟢 Green Phase (구현) ├── ✅ 검증 결과 (테스트, 커버리지, Linter) ├── 🐛 이슈 및 해결 ├── 📝 다음 단계 └── 📊 커밋 요약`
+
+**다중 AI 리뷰 프로세스**
+
+`작업결과서 + 변경 코드         ↓ 다른 AI 에이전트 리뷰 (Codex, Claude, Gemini 등) ([02_code_review_template.md](./02_code_review_template.md) 활용)         ↓     문제/리팩터링 포인트 도출         ↓     YES → 수정 작업 → 결과서에 추가 기록     NO  → 사용자 최종 승인`
+
+---
+
+## 슬라이드 15. 작업결과서 = 지식 순환의 핵심
+
+❌ 단순 보고서    
+⭕ **다음 작업을 위한 RAG 컨텍스트**
+
+**활용 흐름**
+
+`이전 작업 결과서     ↓ 다음 작업의 [REVIEW] 사전작업에서 참조     ↓ "왜 이렇게 했는지" AI가 이해     ↓ 판단의 연속성 유지`
+
+**필수 확인 항목** (Phase 2 이후)
+
+- 이전 체크리스트 완료 여부
+- 미해결 이슈
+- 성능 개선 결과
+- 다음 단계 안내 사항
+
+> 💡 **사람의 기억을 문서화 → AI의 컨텍스트로 확장**
+
+---
+
+## 슬라이드 16. TDD 적용 예시: 사용자 인증 기능
+
+| 단계   | TDD         | 내용                                                                                       |
+| ------ | ----------- | ------------------------------------------------------------------------------------------ |
+| 사전   | 🔴 Red      | "로그인 실패 시 401 반환" 테스트 작성 (실패 확인)                                          |
+| 본작업 | 🟢 Green    | AI에게 최소 구현 요청, 테스트 통과                                                         |
+| 사후   | 🔵 Refactor | 코드 구조 개선, 성능 최적화                                                                |
+| 사후   | 📝 Record   | 작업결과서 작성 ([03_work_result_report_template.md](./03_work_result_report_template.md)) |
+| 검증   | 🔍 Review   | 다른 AI로 교차 검증                                                                        |
+| 승인   | ✅ Approve  | 사용자 최종 승인                                                                           |
+
+**테스트 예시** (가드레일)
+
+`def test_login_fail_returns_401():     """로그인 실패 시 401 반환 - AI가 이 범위 안에서만 구현"""     response = client.post("/login", json={"email": "wrong", "password": "wrong"})     assert response.status_code == 401     assert "error" in response.json()`
+
+---
+
+## 슬라이드 17. R2-D2 도구 스택 예시
+
+| 역할      | 권장 도구            | 비고            |
+| --------- | -------------------- | --------------- |
+| 메인 코딩 | Cursor (Claude)      | 주 개발 환경    |
+| 코드 리뷰 | Claude Code, Codex   | 교차 검증용     |
+| 설계 검증 | Gemini               | 다른 관점 확보  |
+| 문서화    | Notion / Obsidian    | 작업결과서 관리 |
+| 작업 관리 | GitHub Issues / Jira | 추적성 확보     |
+
+**문서 체계**
+
+`docs/working_history/ ├── 99_TDD_plan.md                    # TDD 방법론 ├── 100_Python_Performance_Guide.md   # 성능 가이드 ├── v{버전}/ │   ├── {기능}_todolist.md            # 작업계획서 │   └── working_history/ │       ├── template.md               # 결과서 템플릿 │       └── Phase{N}_{타이틀}_{날짜}.md # 실제 결과서`
+
+---
+
+## 슬라이드 18. R2-D2 Anti-Patterns
+
+### ❌ 하지 말아야 할 것
+
+| Anti-Pattern         | 문제점                          | 올바른 방법                 |
+| -------------------- | ------------------------------- | --------------------------- |
+| **자기 검증**        | 같은 AI로 작성 → 같은 AI로 검증 | 다른 AI로 교차 검증         |
+| **컨텍스트 단절**    | 작업 결과서 생략                | 모든 Phase에 결과서 필수    |
+| **Big Bang 구현**    | 테스트 없이 대규모 구현         | Red → Green → Refactor 순환 |
+| **무승인 진행**      | 인간 승인 없이 다음 단계        | 사용자 최종 승인 필수       |
+| **Green에서 최적화** | 구현하면서 성능 최적화          | Refactor 단계에서만 최적화  |
+| **사전작업 생략**    | 바로 본작업 진행                | 이전 결과서 검토 후 진행    |
+| **승인 전 커밋**     | 리뷰/승인 없이 커밋             | 사용자 승인 후에만 커밋     |
+| **잘못된 방향 고집** | 실패해도 계속 같은 방향 진행    | 즉시 롤백 후 재시작         |
+| **롤백 지연**        | 문제 인지 후에도 진행           | 빠르게 git reset 결정       |
+
+---
+
+## 슬라이드 19. 인간 검증의 위치
+
+R2-D2에서 **모든 단계는 인간이 최종 검증**:
+
+| Phase | 단계            | 실행 주체   | 검증 주체  |
+| ----- | --------------- | ----------- | ---------- |
+| 1     | PRD 작성        | 사용자      | 사용자     |
+| 1     | PRD 리뷰        | 다른 AI     | **사용자** |
+| 2     | 작업계획서 작성 | 사용자/AI   | 사용자     |
+| 2     | 작업계획서 리뷰 | 다른 AI     | **사용자** |
+| 3     | 작업 실행       | AI 에이전트 | **사용자** |
+| 4     | 코드 리뷰       | 다른 AI     | **사용자** |
+
+> 💡 **AI는 서로 교차 검증하지만,**    
+> **최종 승인 책임은 항상 사람에게 있다**
+
+---
+
+## 슬라이드 20. R2-D2는 무엇인가?
+
+| 항목                | 해당 여부 |
+| ------------------- | --------- |
+| Agile               | ✅        |
+| TDD (Kent Beck)     | ✅        |
+| Tidy First          | ✅        |
+| AI Pair Programming | ✅        |
+| 문서 중심 개발      | ✅        |
+| RAG 기반 지식 순환  | ✅        |
+| 다중 에이전트 검증  | ✅        |
+
+**정의**
+
+> _AI 에이전트를 포함한 검증 중심 Agile 개발 프레임워크_
+
+---
+
+## 슬라이드 21. 기존 방식과의 차이
+
+| 구분        | 일반 바이브코딩 | R2-D2 방법론    |
+| ----------- | --------------- | --------------- |
+| 속도        | 빠름            | 빠름            |
+| 품질        | 불안정          | 안정            |
+| 재현성      | 없음            | 있음            |
+| 기록        | 거의 없음       | 구조화 (결과서) |
+| 확장        | 어려움          | 쉬움            |
+| 검증        | 단일/없음       | 다중 순환       |
+| AI 가드레일 | 없음            | TDD 테스트      |
+| 지식 축적   | 없음            | 결과서 → RAG    |
+
+---
+
+## 슬라이드 22. 한 문장 정의
+
+> **"R2-D2는**    
+> **TDD로 AI의 가드레일을 세우고,**    
+> **다른 AI가 교차 검증하며,**    
+> **인간이 최종 승인하는**    
+> **설계 중심 순환 개발 프레임워크다."**
+
+---
+
+## 슬라이드 23. AI 시대의 개발자는 무엇을 해야 하는가
+
+- 코드를 많이 짜는 사람 ❌
+- AI를 잘 다루는 사람 ❌
+
+⭕ **설계를 정의하고, 검증하고, 판단을 축적하는 사람**
+
+**개발자의 역할 변화**
+
+| 역할      | 설명                          |
+| --------- | ----------------------------- |
+| 과거      | R2-D2 시대                    |
+| 코드 작성 | **설계 정의** (테스트 = 명세) |
+| 버그 수정 | **가드레일 설정** (TDD)       |
+| 코드 리뷰 | **다중 AI 리뷰 조율**         |
+| 문서화    | **결과서로 지식 축적**        |
+
+---
+
+## 슬라이드 24. 마지막 문장
+
+> **TDD는 더 이상 '테스트 방법론'이 아니다.**
+>
+> **AI 시대의 개발자에게**    
+> **설계를 정의하고, AI를 가드레일 안에서 움직이게 하는**    
+> **최소한의 통제 장치다.**
+
+---
+
+## 부록 A. R2-D2 Quick Reference
+
+### 10단계 프로세스 요약
+
+| #   | 단계                   | 담당      | 산출물                | 커밋    |
+| --- | ---------------------- | --------- | --------------------- | ------- |
+| 1   | PRD 초안 작성          | 사용자    | 01_basic_project_plan | ❌      |
+| 2   | PRD 리뷰               | 다른 AI   | 개선 의견             | ❌      |
+| 3   | **PRD 승인**           | 사용자    | 확정 PRD              | ✅ 가능 |
+| 4   | 작업계획서 작성        | 사용자/AI | \*\_todolist.md       | ❌      |
+| 5   | 작업계획서 리뷰        | 다른 AI   | 개선 의견             | ❌      |
+| 6   | **작업계획서 승인**    | 사용자    | 확정 계획서           | ✅ 가능 |
+| 7   | 사전작업 (🔴 Red)      | AI        | 테스트 + 컨텍스트     | ❌      |
+| 8   | 본작업 (🟢 Green)      | AI        | 최소 구현             | ❌      |
+| 9   | 사후작업 (🔵 Refactor) | AI        | 개선 코드 + 결과서    | ❌      |
+| 10  | 다중 AI 리뷰           | 다른 AI   | 리뷰 의견             | ❌      |
+| ✅  | **사용자 승인**        | 사용자    | 완료                  | ✅ 필수 |
+
+> ⚠️ **커밋 규칙**: **사용자 승인 완료 후에만** 커밋 (테스트 통과 + 린터 0개 +
+> 승인)  
+
+> 🔄 **롤백 규칙**: 작업이 잘못된 방향으로 진행 시 git reset으로 작업 직전
+> 상태로 복원 후 재시작
+
+### 핵심 문서
+
+| 문서                                                                         | 용도                                        |
+| ---------------------------------------------------------------------------- | ------------------------------------------- |
+| [99_TDD_plan.md](./99_TDD_plan.md)                                           | TDD 방법론 (Red→Green→Refactor, Tidy First) |
+| [100_Python_Performance_Guide.md](./100_Python_Performance_Guide.md)         | Refactor 단계 성능 최적화 기준              |
+| [01_todolist_performance_template.md](./01_todolist_performance_template.md) | 작업계획서 템플릿                           |
+| [02_code_review_template.md](./02_code_review_template.md)                   | 코드 리뷰 템플릿                            |
+| [03_work_result_report_template.md](./03_work_result_report_template.md)     | 작업결과서 템플릿                           |
+
+---
+
+## 부록 B. 전체 프로세스 통합 다이어그램
+
+```mermaid
+flowchart TD
+  %% =========================
+  %% R2-D2 Framework Process
+  %% Recursive Review - Design Driven (TDD)
+  %% =========================
+
+  %% --- PRD Phase ---
+  A[1. 사용자: PRD 초안 작성<br/>01_basic_project_plan]
+  A --> B[2. 다른 AI: PRD 리뷰 및 개선 의견]
+  B --> C{개선 필요?}
+  C -- YES --> A
+  C -- NO --> D[3. 사용자: PRD 최종 승인]
+
+  %% --- Planning Phase ---
+  D --> E[4. 작업계획서 작성<br/>01_todolist_performance_template.md]
+  E --> F[5. 다른 AI: 작업계획서 리뷰]
+  F --> G{개선 필요?}
+  G -- YES --> E
+  G -- NO --> H[6. 사용자: 작업계획서 승인]
+
+  %% --- Task Cycle ---
+  H --> K{다음 작업 Step 선택}
+
+  subgraph R2D2["R2-D2 작업 순환 (TDD Cycle)"]
+    direction TB
+    K --> P[7. 🔴 사전작업 Red<br/>- 이전 결과서 검토<br/>- 컨텍스트 수집<br/>- 실패 테스트 작성]
+    P --> Q[8. 🟢 본작업 Green<br/>- 최소 구현<br/>- 테스트 통과]
+    Q --> R[9. 🔵 사후작업 Refactor<br/>- 구조 개선<br/>- 성능 최적화<br/>- 작업결과서 작성]
+    R --> S[작업결과서 저장<br/>03_work_result_report_template.md]
+    S --> T[10. 다른 AI: 작업결과서 기반 리뷰<br/>Codex, Claude, Gemini]
+    T --> U{문제 발견?}
+    U -- YES 수정가능 --> V[수정 피드백]
+    V --> Q
+    U -- NO --> W[사용자: Step 완료 승인]
+    W --> COMMIT[✅ 커밋]
+  end
+
+  %% --- Rollback Branch ---
+  U -- YES 방향 잘못 --> RESET{롤백 결정}
+  RESET --> GIT[git reset --hard]
+  GIT --> RESTORE[작업 직전 상태 복원]
+  RESTORE -->|재시작| P
+
+  %% --- Iteration / Finish ---
+  COMMIT --> X{남은 Step?}
+  X -- YES --> K
+  X -- NO --> Y[릴리즈 및 회고<br/>결과서 정리]
+
+  %% --- RAG Connection ---
+  S -.->|다음 사전작업에서 참조| P
+```