@didim365/agent-cli-core 0.1.0

package/dist/docs/00_project/ai_adapter/template/01_todolist_performance_template.md

@@ -0,0 +1,436 @@
+# [프로젝트명] 작업 계획서
+
+> **TDD 방법론 기반**: Red → Green → Refactor 사이클 적용  
+> **작업 원칙**: 테스트 먼저 작성 → 최소 코드 구현 → 리팩터링 (성능 검증 포함)  
+> **리팩터링 원칙**: "Make it work → Make it right → Make it fast"  
+> **참고 문서**:
+>
+> - [99_TDD_plan.md](../99_TDD_plan.md) - TDD 방법론
+> - [100_Python_Performance_Guide.md](../100_Python_Performance_Guide.md) - 성능
+>   가이드  
+>   **작업 결과서 템플릿**:
+>   [template.md](./working_history/{버전}/template.md)  
+>   **버전**: v2.1 (TDD + Performance + 2일 단위 분할)
+>
+> **작업 분할 규칙 (필수)**:
+>
+> - 각 작업 단계(Phase)는 **최대 2일 이내** 완료 가능한 범위로 정의
+> - 2일 초과 예상 시 **하위 Phase로 분할** 후 진행
+> - 각 Phase는 독립적으로 **Red/Green/Refactor + 검증 + 결과서**를 완료해야 함
+
+---
+
+## 📋 작업 개요
+
+| 항목            | 내용                                         |
+| --------------- | -------------------------------------------- |
+| 프로젝트        | [프로젝트 설명]                              |
+| 영향 범위       | [영향받는 파일/모듈 목록]                    |
+| 위험 수준       | 🔴 Critical / 🟠 High / 🟡 Medium / 🟢 Low   |
+| **성능 민감도** | 🔴 High (대용량/실시간) / 🟠 Medium / 🟢 Low |
+| 참고 PRD        | [PRD 문서 링크](./path/to/prd.md)            |
+| 작업 브랜치     | `FEAT/[브랜치명]`                            |
+
+---
+
+## 🧩 작업 단계 분할 계획 (2일 규칙)
+
+> 아래 표를 먼저 작성한 뒤 Phase 본문을 채웁니다.
+
+| Phase ID | 목표/범위 | 예상 소요(일) | 분할 필요 여부 | 선행 Phase | 산출물(결과서) |
+| -------- | --------- | ------------- | -------------- | ---------- | -------------- |
+| P1       | [범위]    | 1~2           | N              | -          | [링크]         |
+| P2       | [범위]    | 1~2           | N              | P1         | [링크]         |
+| P3       | [범위]    | 1~2           | Y/N            | P2         | [링크]         |
+
+### 분할 기준 가이드
+
+1. 기능적으로 독립 배포/검증 가능한 단위로 자른다.
+2. 테스트 작성/구현/리팩터링/문서화가 2일 안에 끝나도록 범위를 축소한다.
+3. 성능 최적화는 해당 Phase의 변경분에 대해서만 수행한다.
+4. 대규모 리스크 항목은 별도 Phase로 분리한다.
+
+---
+
+## 🚨 핵심 리스크 요약
+
+| 리스크                        | 영향      | 대응 방안                | 상태 |
+| ----------------------------- | --------- | ------------------------ | ---- |
+| [리스크 1]                    | 🔴 High   | [대응 방안]              | ⬜   |
+| [리스크 2]                    | 🟠 Medium | [대응 방안]              | ⬜   |
+| **[성능] 대용량 데이터 처리** | 🟠 Medium | Refactor 단계에서 최적화 | ⬜   |
+
+---
+
+## 🔄 Phase 1: [Phase 제목 - 최대 2일]
+
+> 📄 **상세 참고**: [detail_prd/step01_xxx.md](./detail_prd/step01_xxx.md) (있는
+> 경우)
+
+### 1.1 사전 작업 (Pre-Work)
+
+> **목적**: 본작업의 실패를 줄이기 위한 작업 준비 과정  
+> **원칙**: 전체 작업의 목적과 배경, 이전 작업결과서를 참고하여 작업의 맥락 이해
+> 및 일관성 유지
+
+- [ ] **[CONTEXT]** 작업 목적 및 배경 확인
+  - PRD 문서 검토: [PRD 문서 링크](./path/to/prd.md)
+  - 관련 이슈/티켓 확인: [이슈 링크]
+
+- [ ] **[REVIEW]** 이전 작업 결과서 검토 _(Phase 2 이후)_
+  - 파일: `./working_history/{버전}/Phase{N-1}_{이전타이틀}_{작업일자}.md`
+  - 확인: 이전 체크리스트 완료 여부, 미해결 이슈 확인
+
+- [ ] **[ANALYSIS]** 현재 코드/설정 분석
+  - 파일: `[분석 대상 파일]`
+  - 확인 내용: [분석할 내용]
+  - 예상 데이터 규모: [항목 수, 빈도] _(성능 민감 시)_
+
+- [ ] **[SCOPE-CHECK]** 2일 이내 완료 가능 범위 확인
+  - 예상 총 소요: [X시간 또는 X일]
+  - 2일 초과 시 분할안: `Phase1-A`, `Phase1-B` 등으로 재정의
+  - 이번 Phase 완료 조건(DoD): [테스트/기능/문서 기준]
+
+- [ ] **[BACKUP]** 기존 파일 백업 (필요시)
+  ```bash
+  cp [원본 파일] [백업 파일]
+  ```
+
+---
+
+### 1.2 🔴 RED Phase: 실패 테스트 작성
+
+> **목적**: 구현할 기능을 정의하는 실패 테스트 작성  
+> **원칙**: 테스트가 실패하는 것을 확인한 후에만 구현 시작
+
+- [ ] **[RED]** 기능 테스트 작성
+
+  ```python
+  def test_xxx():
+      """[테스트 설명]"""
+      # 테스트 코드
+      assert expected == actual
+  ```
+
+- [ ] **[RED-VERIFY]** 테스트 실패 확인
+  ```bash
+  pytest [테스트 경로] -v  # 반드시 FAIL이어야 함
+  ```
+
+---
+
+### 1.3 🟢 GREEN Phase: 최소 코드 구현
+
+> **목적**: 테스트를 통과하는 최소한의 코드 구현  
+> **원칙**: "Make it work" - 동작하게 만드는 것이 최우선, 최적화는 Refactor에서
+
+- [ ] **[TASK-001]** [작업 제목]
+  - 파일: `[파일 경로]`
+  - 변경 내용:
+    ```python
+    # 최소한의 구현 (성능보다 동작 우선)
+    [구현 코드]
+    ```
+  - 예상 소요: X분
+
+- [ ] **[TASK-002]** [작업 제목]
+  - 파일: `[파일 경로]`
+  - 작업: [작업 설명]
+  - 예상 소요: X분
+
+- [ ] **[GREEN-VERIFY]** 테스트 통과 확인
+  ```bash
+  pytest [테스트 경로] -v  # 반드시 PASS여야 함
+  ```
+
+---
+
+### 1.4 🔵 REFACTOR Phase: 코드 개선 + 성능 최적화
+
+> **목적**: 동작을 유지하면서 코드 구조와 성능 개선  
+> **원칙**: "Make it right, Make it fast" - 테스트가 통과하는 상태에서만
+> 리팩터링
+
+#### 1.4.1 구조 개선 (Make it right)
+
+- [ ] **[REFACTOR-STRUCTURE]** 코드 구조 개선
+  - 중복 코드 제거
+  - 네이밍 개선
+  - 책임 분리 (SRP)
+  - 로깅 추가
+
+- [ ] **[REFACTOR-VERIFY]** 리팩터링 후 테스트 재확인
+  ```bash
+  pytest [테스트 경로] -v  # 여전히 PASS여야 함
+  ```
+
+#### 1.4.2 성능 개선 (Make it fast) ⚡
+
+> **참고**:
+> [100_Python_Performance_Guide.md](../100_Python_Performance_Guide.md)  
+> **주의**: 성능 민감도가 🟢 Low인 경우 이 섹션 생략 가능
+
+- [ ] **[REFACTOR-PERF-MEASURE]** 현재 성능 측정 (베이스라인)
+
+  ```python
+  import time
+  start = time.perf_counter()
+  result = target_function(test_data)
+  elapsed = time.perf_counter() - start
+  print(f"Baseline: {elapsed*1000:.2f}ms")
+  ```
+
+- [ ] **[REFACTOR-PERF-ANALYZE]** 성능 체크리스트 검토
+
+  | 항목                        | 현재 상태 | 개선 필요 | 주의사항                                       | 적용 |
+  | --------------------------- | --------- | --------- | ---------------------------------------------- | ---- |
+  | 데이터 구조 (list→set/dict) | [현재]    | ✅/❌     | ⚠️ 반복 검사 시만 유리, 단발성은 변환비용 확인 | ⬜   |
+  | 컴프리헨션 사용             | [현재]    | ✅/❌     | -                                              | ⬜   |
+  | `__slots__` (대량 인스턴스) | [현재]    | ✅/❌/N/A | ⚠️ 동적속성/weakref/상속 제약 확인             | ⬜   |
+  | JSON 라이브러리 (orjson)    | [현재]    | ✅/❌/N/A | ⚠️ bytes 반환, 타입 제한 확인, 테스트 필수     | ⬜   |
+  | 비동기 적정성               | [현재]    | ✅/❌/N/A | I/O 바운드만 적용                              | ⬜   |
+  | EAFP/LBYL 선택              | [현재]    | ✅/❌     | ⚠️ 키 존재 비율에 따라 결정                    | ⬜   |
+
+- [ ] **[REFACTOR-PERF-OPTIMIZE]** 성능 최적화 적용
+
+  ```python
+  # 변경 전 (Green에서 구현한 코드)
+  [기존 코드]
+
+  # 변경 후 (성능 최적화)
+  [최적화된 코드]
+  ```
+  - 적용한 최적화: [최적화 내용]
+  - 예상 개선: [X배 또는 X% 개선]
+
+- [ ] **[REFACTOR-PERF-VERIFY]** 최적화 후 테스트 + 성능 확인
+  ```bash
+  pytest [테스트 경로] -v  # 여전히 PASS여야 함
+  ```
+  ```python
+  # 성능 개선 확인
+  # Baseline: XXms → Optimized: XXms (XX% 개선)
+  ```
+
+---
+
+### 1.5 사후 작업 (Post-Work)
+
+> **목적**: 수정된 코드 검증 및 작업 결과 문서화  
+> **원칙**: 모든 검증 완료 후 작업결과서 작성
+
+- [ ] **[TEST]** 전체 테스트 실행
+
+  ```bash
+  pytest [테스트 경로] -v
+  pytest tests/integration/ -v  # 해당시
+  ```
+
+- [ ] **[LINT]** 린터 검사
+
+  ```bash
+  ruff check [경로]
+  ```
+
+- [ ] **[VERIFY]** 기능 검증
+  - 확인 항목 1: [검증 내용]
+  - 확인 항목 2: [검증 내용]
+
+- [ ] **[DOC]** 작업 결과서 작성
+  - 파일: `./working_history/{버전}/Phase1_{작업타이틀}_{작업일자}.md`
+  - 템플릿: [template.md](./working_history/{버전}/template.md)
+  - 내용:
+    - 작업 목표 및 범위
+    - Red/Green/Refactor 각 단계 결과
+    - **성능 개선 결과** (Refactor에서 적용한 최적화)
+    - 테스트 실행 결과 및 커버리지
+    - 이슈 및 해결 방법
+    - 다음 단계 안내
+
+- [ ] **[COMMIT]** 변경사항 커밋
+  ```bash
+  git add .
+  git commit -m "[Phase1] {작업타이틀} 완료"
+  ```
+
+---
+
+## 🔄 Phase 2: [Phase 제목 - 최대 2일]
+
+> 📄 **상세 참고**: [detail_prd/step02_xxx.md](./detail_prd/step02_xxx.md) (있는
+> 경우)
+
+### 2.1 사전 작업
+
+- [ ] **[REVIEW]** 이전 Phase 작업 결과서 검토
+  - 파일: `./working_history/{버전}/Phase1_{이전타이틀}_{작업일자}.md`
+  - 확인: 체크리스트 완료, 미해결 이슈, **성능 개선 결과**
+
+- [ ] **[CONTEXT]** Phase 2 작업 목적 확인
+
+- [ ] **[ANALYSIS]** [분석 대상] 확인
+
+- [ ] **[SCOPE-CHECK]** 2일 이내 완료 가능 범위 확인
+  - 예상 총 소요: [X시간 또는 X일]
+  - 2일 초과 시 분할안: `Phase2-A`, `Phase2-B` 등
+
+### 2.2 🔴 RED Phase
+
+- [ ] **[RED]** 실패 테스트 작성
+- [ ] **[RED-VERIFY]** 테스트 실패 확인
+
+### 2.3 🟢 GREEN Phase
+
+- [ ] **[TASK-001]** [작업 제목]
+- [ ] **[GREEN-VERIFY]** 테스트 통과 확인
+
+### 2.4 🔵 REFACTOR Phase
+
+- [ ] **[REFACTOR-STRUCTURE]** 코드 구조 개선
+- [ ] **[REFACTOR-PERF-ANALYZE]** 성능 체크리스트 검토 _(성능 민감 시)_
+- [ ] **[REFACTOR-PERF-OPTIMIZE]** 성능 최적화 적용 _(해당 시)_
+- [ ] **[REFACTOR-VERIFY]** 테스트 재확인
+
+### 2.5 사후 작업
+
+- [ ] **[TEST]** 테스트 실행 및 검증
+- [ ] **[DOC]** 작업 결과서 작성
+- [ ] **[COMMIT]** 변경사항 커밋
+
+---
+
+## 🔄 Phase N: [Phase 제목 - 최대 2일]
+
+_(필요한 만큼 Phase 추가 - 동일 구조, 각 Phase는 2일 이내로 제한)_
+
+### N.1 사전 작업
+
+### N.2 🔴 RED Phase
+
+### N.3 🟢 GREEN Phase
+
+### N.4 🔵 REFACTOR Phase
+
+### N.5 사후 작업
+
+---
+
+## ✅ 최종 체크리스트
+
+### TDD 사이클 완료
+
+- [ ] 모든 Phase의 Red → Green → Refactor 사이클 완료
+- [ ] 모든 Phase가 **2일 이내 범위**로 계획/실행됨
+- [ ] 전체 테스트 통과 (`pytest tests/ -v`)
+- [ ] 통합 테스트 통과 (`pytest tests/integration/ -v`)
+- [ ] 린터 경고 0개
+
+### 성능 최적화 결과 (Refactor 단계 요약)
+
+| Phase   | 적용한 최적화         | 개선 효과         |
+| ------- | --------------------- | ----------------- |
+| Phase 1 | [예: list→set 변경]   | [예: 조회 200배↑] |
+| Phase 2 | [예: 컴프리헨션 적용] | [예: 26%↑]        |
+| Phase N | [예: orjson 적용]     | [예: 8배↑]        |
+
+### 문서화
+
+- [ ] 각 Phase별 작업 결과서 작성 완료
+- [ ] README.md 업데이트 (필요시)
+- [ ] API 문서 업데이트 (필요시)
+- [ ] 변경 로그 업데이트
+
+### 최종 커밋 및 PR
+
+- [ ] 모든 변경사항 커밋 완료
+- [ ] PR 생성 및 코드 리뷰 요청
+- [ ] CI/CD 파이프라인 통과
+
+---
+
+## 📊 진행 체크리스트
+
+### 사전 준비
+
+- [ ] 작업 브랜치 생성 (`git checkout -b FEAT/[브랜치명]`)
+- [ ] 기존 테스트 전체 실행 및 결과 기록
+- [ ] 관련 PRD 문서 검토
+- [ ] 성능 가이드 검토
+      ([100_Python_Performance_Guide.md](../100_Python_Performance_Guide.md))
+
+### Phase 완료 조건
+
+| Phase   | 기간(<=2일) | 🔴 Red | 🟢 Green | 🔵 Refactor | 결과서 | 커밋 | 상태 |
+| ------- | ----------- | ------ | -------- | ----------- | ------ | ---- | ---- |
+| Phase 1 | ⬜          | ⬜     | ⬜       | ⬜          | ⬜     | ⬜   | ⬜   |
+| Phase 2 | ⬜          | ⬜     | ⬜       | ⬜          | ⬜     | ⬜   | ⬜   |
+| Phase N | ⬜          | ⬜     | ⬜       | ⬜          | ⬜     | ⬜   | ⬜   |
+
+---
+
+## ⚠️ 주의사항
+
+### TDD 사이클 원칙
+
+1. **Red First**: 반드시 실패하는 테스트를 먼저 작성
+2. **Minimal Green**: 테스트를 통과하는 최소한의 코드만 구현 (최적화 X)
+3. **Safe Refactor**: 테스트가 통과하는 상태에서만 리팩터링 진행
+
+### Refactor 단계 원칙 (구조 + 성능)
+
+4. **Make it right**: 먼저 코드 구조를 개선 (중복 제거, 네이밍, 책임 분리)
+5. **Make it fast**: 그 다음 성능 최적화 적용 (측정 → 분석 → 최적화 → 검증)
+6. **테스트 보호**: 모든 리팩터링 후 테스트 재실행으로 동작 유지 확인
+
+### 작업 관리 원칙
+
+7. **작업 결과서 필수**: 각 Phase 완료 시 결과서 작성
+8. **이전 결과서 검토**: Phase 2 이후 반드시 이전 결과서 확인
+9. **2일 제한 준수**: Phase는 반드시 2일 이내 완료 가능한 단위로 유지
+10. **커밋 단위**: Phase 단위로 커밋하여 롤백 용이하게 관리
+11. **린터 통과**: 커밋 전 반드시 린터 검사 통과
+
+---
+
+## ⚡ 성능 최적화 Quick Reference (Refactor 시 참조)
+
+> [100_Python_Performance_Guide.md](../100_Python_Performance_Guide.md) 발췌  
+> ⚠️ **주의**: 수치는 상대 비교용이며, **본인 환경에서 측정 후 적용** 권장
+
+| 패턴          | 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%↓   | 동적속성/weakref/상속 제약 확인        |
+| 딕셔너리 접근 | `try: d[k]`      | `d.get(k, default)` | 상황별        | 키 존재 비율에 따라 다름               |
+| 비동기 선택   | 무조건 async     | I/O 바운드만        | 오버헤드 방지 | CPU 바운드는 동기로                    |
+| 직렬화        | json             | pickle              | ~2배↑         | 🔴 **신뢰된 내부 데이터만!** 보안 위험 |
+
+---
+
+## 🔗 관련 문서
+
+- [PRD 문서](./path/to/prd.md) - 기획설계 문서
+- [99_TDD_plan.md](../99_TDD_plan.md) - TDD 방법론 가이드
+- [100_Python_Performance_Guide.md](../100_Python_Performance_Guide.md) - 파이썬
+  성능 가이드 (Refactor 참조)
+- [template.md](./working_history/{버전}/template.md) - 작업 결과서 템플릿
+
+---
+
+## 📅 예상 일정
+
+| Phase     | 예상 소요 | 시작일     | 완료일 | 비고   |
+| --------- | --------- | ---------- | ------ | ------ |
+| Phase 1   | 1~2일     | YYYY-MM-DD | -      | [비고] |
+| Phase 2   | 1~2일     | -          | -      | [비고] |
+| Phase N   | 1~2일     | -          | -      | [비고] |
+| **Total** | **X일**   | -          | -      | -      |
+
+---
+
+**작성일**: YYYY-MM-DD  
+**작성자**: [작성자]  
+**최종 수정일**: YYYY-MM-DD  
+**상태**: ⬜ 작성 중 / 🔄 검토 대기 / ✅ 승인됨

package/dist/docs/00_project/ai_adapter/template/02_code_review_template.md

@@ -0,0 +1,248 @@
+# 코드 리뷰 체크리스트 📋
+
+## PR 정보
+
+- **PR 제목**: [변경 내용을 간단히 설명]
+- **작업 유형**: `feat` / `fix` / `refactor` / `docs` / `test`
+- **관련 이슈**: #[이슈 번호]
+- **리뷰어**: @[리뷰어 이름]
+
+---
+
+## 🔍 코드 품질 검증
+
+### 타입 힌트 & 문서화
+
+- [ ] 모든 함수/메서드에 타입 힌트 적용
+- [ ] 공개 함수/클래스에 적절한 docstring 작성
+- [ ] Pydantic 모델의 모든 필드에 description 작성
+- [ ] 복잡한 로직에 인라인 주석 추가
+
+### 로깅 & 에러 처리
+
+- [ ] 적절한 로그 레벨 사용 (DEBUG, INFO, WARNING, ERROR, CRITICAL)
+- [ ] 로깅 이모지 패턴 적용 (✅, ⚠️, ❌, 💥)
+- [ ] 예외 상황에 대한 적절한 에러 처리
+- [ ] 사용자 친화적 에러 메시지 제공
+- [ ] 민감한 정보 로깅 방지
+
+### 코드 구조
+
+- [ ] Import 순서 준수 (표준 → 서드파티 → 로컬)
+- [ ] 클래스 구조 순서 준수 (상수 → 생성자 → 프로퍼티 → 공개 → 비공개)
+- [ ] 함수/메서드의 단일 책임 원칙 준수
+- [ ] 적절한 추상화 레벨 유지
+
+---
+
+## 🏗️ 아키텍처 & 패턴
+
+### 비동기 처리
+
+- [ ] async/await 올바른 사용
+- [ ] 비동기 컨텍스트에서 동기 코드 실행 방지
+- [ ] 적절한 예외 처리 (asyncio.gather 등)
+- [ ] 데드락 가능성 검토
+
+### 디자인 패턴
+
+- [ ] 기존 프로젝트 패턴과 일관성 유지
+- [ ] 의존성 주입 패턴 적용
+- [ ] Repository 패턴 준수 (Service ↔ Repository)
+- [ ] DTO 패턴 적절한 활용
+
+### 데이터베이스
+
+- [ ] SQLAlchemy 2.0 스타일 쿼리 사용
+- [ ] N+1 쿼리 문제 방지
+- [ ] 적절한 트랜잭션 관리
+- [ ] 데이터베이스 연결 리소스 정리
+
+---
+
+## 🚀 성능 & 보안
+
+### 성능 최적화
+
+- [ ] 불필요한 데이터베이스 쿼리 제거
+- [ ] 적절한 캐싱 전략 적용
+- [ ] 메모리 누수 가능성 검토
+- [ ] 대용량 데이터 처리 시 배치 처리 적용
+
+### 보안 검증
+
+- [ ] 하드코딩된 시크릿/패스워드 없음
+- [ ] SQL 인젝션 방지 (ORM 사용)
+- [ ] XSS 방지 (입력값 검증)
+- [ ] 인증/인가 로직 적절히 적용
+- [ ] 민감한 정보 응답에서 제외
+
+### 입력 검증
+
+- [ ] Pydantic 모델을 통한 입력 검증
+- [ ] 적절한 제약 조건 설정 (길이, 범위 등)
+- [ ] 악의적 입력에 대한 방어 코드
+
+---
+
+## 📋 API 설계 (API 변경이 있는 경우)
+
+### RESTful 원칙
+
+- [ ] 적절한 HTTP 메서드 사용 (GET, POST, PUT, DELETE)
+- [ ] 의미있는 상태 코드 반환
+- [ ] 일관된 URL 구조 (복수형 명사, 계층 구조)
+- [ ] 적절한 응답 형식 (JSON, 에러 응답)
+
+### API 문서화
+
+- [ ] `response_model` 정의
+- [ ] `summary`, `description` 작성
+- [ ] 에러 응답 케이스 문서화
+- [ ] 예제 요청/응답 제공
+
+### 버전 관리
+
+- [ ] API 버전 경로 준수 (/api/v1/)
+- [ ] 하위 호환성 유지
+- [ ] 변경사항이 기존 클라이언트에 미치는 영향 검토
+
+---
+
+## ✅ 테스트 검증
+
+### 테스트 커버리지
+
+- [ ] 새로 추가된 코드에 대한 단위 테스트 작성
+- [ ] 핵심 비즈니스 로직 테스트 커버리지 80% 이상
+- [ ] 엣지 케이스 및 에러 케이스 테스트
+- [ ] API 엔드포인트 통합 테스트
+
+### 테스트 품질
+
+- [ ] 테스트 케이스 명명 규칙 준수
+- [ ] Given-When-Then 패턴 적용
+- [ ] 테스트 간 독립성 보장
+- [ ] Mock 객체 적절한 사용
+
+### 테스트 실행
+
+- [ ] 모든 기존 테스트 통과 확인
+- [ ] 새로 추가된 테스트 통과 확인
+- [ ] 테스트 실행 시간 적절함
+
+---
+
+## 📚 문서화 & 변경사항
+
+### 코드 문서화
+
+- [ ] README.md 업데이트 (필요시)
+- [ ] API 문서 업데이트
+- [ ] 변경된 설정 파일 문서화
+- [ ] 마이그레이션 가이드 작성 (호환성 변경시)
+
+### 변경 로그
+
+- [ ] 주요 변경사항 기록
+- [ ] 브레이킹 체인지 명시
+- [ ] 설정 변경 사항 안내
+- [ ] 업그레이드 가이드 제공
+
+---
+
+## 🔧 환경 & 배포
+
+### 환경 설정
+
+- [ ] 새로운 환경 변수 추가 시 문서화
+- [ ] 개발/스테이징/프로덕션 환경 검증
+- [ ] Docker 설정 업데이트 (필요시)
+- [ ] 의존성 변경 사항 확인
+
+### 데이터베이스 변경
+
+- [ ] 마이그레이션 스크립트 검토
+- [ ] 데이터 손실 가능성 검토
+- [ ] 롤백 계획 수립
+- [ ] 인덱스 성능 영향 검토
+
+---
+
+## 🎯 최종 검증
+
+### 자동화 도구 실행
+
+```bash
+# 코드 품질 검사
+uv run black --check app/ tests/
+uv run isort --check-only app/ tests/
+uv run flake8 app/ tests/
+uv run mypy app/
+uv run bandit -r app/
+
+# 테스트 실행
+uv run pytest tests/ -v --cov=app
+
+# Phase 14 품질 검증
+uv run python scripts/validate_phase14.py
+```
+
+### 수동 검증
+
+- [ ] 로컬 환경에서 정상 동작 확인
+- [ ] API 엔드포인트 Swagger UI에서 테스트
+- [ ] 데이터베이스 마이그레이션 테스트
+- [ ] 로그 출력 및 에러 처리 확인
+
+---
+
+## 💬 리뷰어 체크리스트
+
+### 코드 리뷰
+
+- [ ] 비즈니스 로직의 정확성 검증
+- [ ] 코딩 표준 준수 확인
+- [ ] 성능 및 보안 관점 검토
+- [ ] 확장성 및 유지보수성 검토
+
+### 커뮤니케이션
+
+- [ ] 명확하고 건설적인 피드백 제공
+- [ ] 칭찬할 부분은 칭찬
+- [ ] 개선이 필요한 부분은 구체적 제안
+- [ ] 학습 기회 제공 (리소스, 레퍼런스 공유)
+
+---
+
+## 📝 리뷰 완료 체크리스트
+
+### 승인 전 최종 확인
+
+- [ ] 모든 피드백이 적절히 반영됨
+- [ ] CI/CD 파이프라인 모든 체크 통과
+- [ ] 브랜치가 최신 develop/main과 동기화됨
+- [ ] 스쿼시 머지 또는 리베이스 필요성 검토
+
+### 승인 후 액션
+
+- [ ] 머지 전 최종 테스트 실행
+- [ ] 배포 영향도 재검토
+- [ ] 모니터링 계획 수립
+- [ ] 롤백 계획 확인
+
+---
+
+**⚡ 빠른 승인을 위한 팁**
+
+- 작은 단위로 PR 생성
+- 자체 코드 리뷰 먼저 수행
+- 명확한 PR 설명 작성
+- 테스트와 문서화 함께 제출
+
+**🚀 긴급 수정의 경우**
+
+- 핫픽스 브랜치 사용
+- 최소한의 변경으로 문제 해결
+- 즉시 테스트 실행
+- 사후 정식 리팩토링 계획 수립