| name | design-review |
| description | 외부 전문가가 plan_docs/N월_[기능]_plan.md 로 작성한 설계를 Codex가 검증하는 3단계 워크플로우. 1) 외부 설계 문서 + 관련 MD 분석 → 2) 타당성 검증 및 수정(이유 명시) → 3) 백엔드/프론트 구현 가이드 작성. 유저가 설계·분석·아키텍처·검토 등을 요청할 때 반드시 사용. AGENT_GUIDE.md, docs/agent/pdca-templates.md, docs/agent/output-contract.md의 설계 검증·PLAN 파일 운영 규칙을 통합한 워크플로우.
|
| triggers | ["설계","아키텍처","분석","검토","design review","설계 검토","구조 분석","plan 검토","설계 방향"] |
외부설계 → Codex 검증 → 구현가이드 워크플로우
개요
시작 전 plan_docs/N월_[기능]_plan.md 존재 여부를 확인하고 경로를 분기한다.
[Path A] 외부 설계 파일 있음
→ [1단계] Codex: 설계 문서 + 관련 MD 파일 분석
→ [2단계] Codex: 타당성 검증 및 수정 (이유 명시)
→ [3단계] Codex: 구현 가이드 작성
[Path B] 외부 설계 파일 없음
→ plan_docs/ARCHITECT_GUIDE.md 읽기
→ 유저와 기능 논의 (No-Code Mandate: 소스 코드 수정 금지)
→ plan_docs/N월_[기능]_plan.md + 01/02/03 문서 작성
→ 유저 승인 후 구현 가이드 작성
Path B: 외부 설계 파일이 없는 경우
B-1. plan_docs/ARCHITECT_GUIDE.md 읽기
ARCHITECT_GUIDE.md의 01-05 표준과 핵심 원칙(Design-First, No-Code Mandate)을 확인한다.
B-2. 유저와 기능 논의
다음 항목을 유저와 순서대로 확인한다:
| 항목 | 확인 내용 |
|---|
| 기능 목적 | 무엇을 해결하는가, 누가 사용하는가 |
| 범위 | 백엔드 / 프론트 / Desktop 중 어디에 영향을 주는가 |
| 연관 기능 | 기존 기능과 어떻게 연결되는가 |
| 제약 조건 | 성능, 보안, 호환성 요구사항 |
B-3. 설계 문서 작성 (ARCHITECT_GUIDE.md 표준)
plan_docs/
N월_[기능]_plan.md ← 논의 결론, 유의점, 문서 맵핑
01-plan/ ← L1 System Context + L2 Data Model
02-design/ ← L3 API Interface + Sequence Diagram
03-implementation/ ← L4 수정 파일 목록, 알고리즘, Config 변경
유저 승인 후 Path A의 구현 가이드 작성 단계로 진행
Path A: 외부 설계 파일이 있는 경우
1단계: 설계 문서 + 관련 파일 분석
다음 파일을 모두 읽는다:
plan_docs/N월_[기능]_plan.md — 외부 전문가 설계 원본
AGENT_GUIDE.md — 프로젝트 개발 원칙 및 컨벤션
docs/springboot_backend.md — 백엔드 컨벤션
docs/nodejs_frontend.md — 프론트 컨벤션
- 관련 기존 plan 파일 (유사 기능이 있는 경우)
- 설계에서 언급된 기존 소스 파일 (필요 시)
분석 시 아래 항목을 확인한다:
| 확인 항목 | 세부 내용 |
|---|
| 목표 부합 | 설계가 프로젝트 목표(WebRTC, Spring Boot, jQuery 기반)와 맞는가 |
| 아키텍처 일관성 | 기존 컨트롤러·서비스·레이어 구조를 따르는가 |
| 컨벤션 준수 | springboot_backend.md / nodejs_frontend.md 기준 위반 없는가 |
| 엣지 케이스 | 누락된 예외 처리, 동시성, 경계값은 없는가 |
| 실현 가능성 | 현재 기술 스택으로 구현 가능한가 |
2단계: 타당성 검증 및 수정
응답 형식 (필수)
## 설계 검증 결과
### 분석한 파일 목록
- plan_docs/N월_[기능]_plan.md
- (분석한 파일들 열거)
### 타당성 평가
<설계 방향이 프로젝트 목표·구조와 부합하는지 종합 판단>
### 수정 사항
| # | 항목 | 수정 이유 | 수정 내용 |
|---|------|---------|---------|
| 1 | ... | ... | ... |
> 수정이 없을 경우: "수정 없음 — 설계가 프로젝트 구조와 일치함"
### 실무 레퍼런스 비교
<업계 기준 대비 장점 / 주의점>
### 개선 제안 (선택)
<필수가 아닌 품질 향상 제안>
### 리스크 / 주의사항
<확인된 리스크 목록>
3단계: 구현 가이드 작성
검증 완료 후 백엔드/프론트 구현 가이드를 별도 파일로 작성한다.
백엔드 구현 가이드: springboot-backend/plan_docs/[기능명].md
# [기능명] 백엔드 구현 가이드
> 원본 설계: plan_docs/N월_[기능]_plan.md
> 검증 완료: YYYY-MM-DD
## 구현 목록
- [ ] ...
## 파일 소유권
- **백엔드 전문가**: springboot-backend/src/main/
- **QA 전문가**: springboot-backend/src/test/
## API 설계
| Method | URL | 설명 |
|--------|-----|------|
| ... | ... | ... |
## 테스트 시나리오
- [ ] ...
## 코드 컨벤션
- [ ] backend-convention-checker 검증
- [ ] backend-test-convention-checker 검증 (테스트 코드)
프론트 구현 가이드: nodejs-frontend/plan_docs/[기능명].md
# [기능명] 프론트 구현 가이드
> 원본 설계: plan_docs/N월_[기능]_plan.md
> 검증 완료: YYYY-MM-DD
## 구현 목록
- [ ] ...
## 파일 소유권
- **프론트 전문가**: nodejs-frontend/
## 코드 컨벤션
- [ ] frontend-convention-checker 검증
행동 규칙
- 외부 설계 문서를 먼저 읽지 않고 검증을 시작하지 않는다
- 수정 시 반드시 이유를 명시한다. "수정 없음"도 명시한다
- 구현 가이드는 백엔드/프론트를 반드시 분리하여 작성한다
- commit / push 금지