@didim365/agent-cli-core 0.1.1 → 0.1.3

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

@@ -1,400 +0,0 @@
-# [프로젝트명] 작업 계획서
-
-> **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.0 (TDD + Performance)
-
----
-
-## 📋 작업 개요
-
-| 항목            | 내용                                         |
-| --------------- | -------------------------------------------- |
-| 프로젝트        | [프로젝트 설명]                              |
-| 영향 범위       | [영향받는 파일/모듈 목록]                    |
-| 위험 수준       | 🔴 Critical / 🟠 High / 🟡 Medium / 🟢 Low   |
-| **성능 민감도** | 🔴 High (대용량/실시간) / 🟠 Medium / 🟢 Low |
-| 참고 PRD        | [PRD 문서 링크](./path/to/prd.md)            |
-| 작업 브랜치     | `FEAT/[브랜치명]`                            |
-
----
-
-## 🚨 핵심 리스크 요약
-
-| 리스크                        | 영향      | 대응 방안                | 상태 |
-| ----------------------------- | --------- | ------------------------ | ---- |
-| [리스크 1]                    | 🔴 High   | [대응 방안]              | ⬜   |
-| [리스크 2]                    | 🟠 Medium | [대응 방안]              | ⬜   |
-| **[성능] 대용량 데이터 처리** | 🟠 Medium | Refactor 단계에서 최적화 | ⬜   |
-
----
-
-## 🔄 Phase 1: [Phase 제목]
-
-> 📄 **상세 참고**: [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]** 현재 코드/설정 분석
-  - 파일: `[분석 대상 파일]`
-  - 확인 내용: [분석할 내용]
-  - 예상 데이터 규모: [항목 수, 빈도] _(성능 민감 시)_
-
-- [ ] **[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 제목]
-
-> 📄 **상세 참고**: [detail_prd/step02_xxx.md](./detail_prd/step02_xxx.md) (있는
-> 경우)
-
-### 2.1 사전 작업
-
-- [ ] **[REVIEW]** 이전 Phase 작업 결과서 검토
-  - 파일: `./working_history/{버전}/Phase1_{이전타이틀}_{작업일자}.md`
-  - 확인: 체크리스트 완료, 미해결 이슈, **성능 개선 결과**
-
-- [ ] **[CONTEXT]** Phase 2 작업 목적 확인
-
-- [ ] **[ANALYSIS]** [분석 대상] 확인
-
-### 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 제목]
-
-_(필요한 만큼 Phase 추가 - 동일 구조)_
-
-### N.1 사전 작업
-
-### N.2 🔴 RED Phase
-
-### N.3 🟢 GREEN Phase
-
-### N.4 🔵 REFACTOR Phase
-
-### N.5 사후 작업
-
----
-
-## ✅ 최종 체크리스트
-
-### TDD 사이클 완료
-
-- [ ] 모든 Phase의 Red → Green → Refactor 사이클 완료
-- [ ] 전체 테스트 통과 (`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   | 🔴 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. **커밋 단위**: Phase 단위로 커밋하여 롤백 용이하게 관리
-10. **린터 통과**: 커밋 전 반드시 린터 검사 통과
-
----
-
-## ⚡ 성능 최적화 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   | X일       | YYYY-MM-DD | -      | [비고] |
-| Phase 2   | X일       | -          | -      | [비고] |
-| Phase N   | X일       | -          | -      | [비고] |
-| **Total** | **X일**   | -          | -      | -      |
-
----
-
-**작성일**: YYYY-MM-DD  
-**작성자**: [작성자]  
-**최종 수정일**: YYYY-MM-DD  
-**상태**: ⬜ 작성 중 / 🔄 검토 대기 / ✅ 승인됨

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

@@ -1,248 +0,0 @@
-# 코드 리뷰 체크리스트 📋
-
-## 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 설명 작성
-- 테스트와 문서화 함께 제출
-
-**🚀 긴급 수정의 경우**
-
-- 핫픽스 브랜치 사용
-- 최소한의 변경으로 문제 해결
-- 즉시 테스트 실행
-- 사후 정식 리팩토링 계획 수립