구현 계획 검토

04-planning에서 수립한 계획의 아키텍처 정합성, 가이드라인 준수, 완전성, 리스크를 코딩 시작 전에 검증한다. 코드를 쓴 뒤에 발견하면 되돌리는 비용이 커진다.

실행 워크플로우

Step 1: 아키텍처 정합성 검증

01-architecture-check를 기준으로 확인한다. 프로젝트마다 항목이 다르므로, 그 문서에 적힌 정책을 하나씩 계획과 대조한다.

• 레이어 역할 준수: 각 레이어가 자기 역할을 넘지 않는지 (진입점에 비즈니스 로직, 저장소에서 외부 API 호출, 도메인 로직이 요청/응답 객체를 직접 참조 등)
• 인증 방식 매칭: 새 엔드포인트가 올바른 인증 유형을 쓰는지
• 에러 처리 패턴: 프로젝트의 에러 클래스 체계와 응답 규약을 따르는지 — 표준과 다른 규약이 있는 프로젝트에서 특히 자주 어긋난다
• 캐싱 전략: 기존 캐시 패턴(무효화 책임, 키 프리픽스 규칙)을 따르는지

Step 2: 가이드라인 준수 검증

02-guidelines를 기준으로 확인한다.

• 파일명·네이밍: 규칙 준수
• API URL: 버전·리소스 명명 규칙
• 코드 패턴: 각 레이어 패턴이 기존과 일치하는지
• 모듈 시스템·언어 스타일
• 커밋 메시지: 형식 준수

Step 3: 완전성 검증

여기서 잡히는 것이 실제로 가장 많다. "안 한 것"은 계획서에 안 보이기 때문이다.

• 레이어 누락: 한 레이어만 수정하고 그와 짝을 이루는 레이어 변경이 빠지지 않았는지
• 캐시 무효화 누락: 데이터 변경 시 캐시 삭제 로직 포함 여부
• 트랜잭션 누락: 여러 테이블·집계를 함께 바꾸는데 원자성 보장이 빠지지 않았는지
• 테스트 누락: 새 엔드포인트, 비즈니스 로직, 보안 로직, 복잡한 계산 로직에 대한 테스트
• 변환 레이어 누락: 외부 포맷 변환이 필요한데 그 단계가 빠지지 않았는지

Step 4: 리스크 재평가

• 하위 호환성: 기존 호출자에 미치는 영향 (내부 API·외부 공개 API 각각)
• 데이터 마이그레이션: 기존 데이터에 영향을 주는 스키마 변경 여부
• 분기 누락: 프로젝트에 분기 축이 있다면 전 분기 처리 여부
• 비동기 영향: 이벤트 발행·알림·배치에 미치는 영향

검토 결과 출력

## 플랜 검토 결과

### 아키텍처 정합성: PASS / WARN / FAIL
(상세 사항)

### 가이드라인 준수: PASS / WARN / FAIL
(상세 사항)

### 완전성: PASS / WARN / FAIL
(누락 사항)

### 리스크
- (식별된 리스크 목록)

### 최종 판정
- PASS: 계획대로 코딩 진행
- WARN: 코딩 가능하지만 아래 사항 주의 (경고 목록)
- FAIL: 아래 사항을 수정 후 재검토 필요 (수정 목록)

주의사항

• FAIL 판정 시 4단계(플랜)로 돌아가 계획을 수정한다.
• PASS 또는 WARN 판정 시 6단계(코딩)로 진행한다.
• 단순 수정(한두 파일, 명확한 변경)은 검토를 간략히 처리한다 — 절차가 변경보다 비싸지면 파이프라인이 우회당한다.