/cc-product:plan-technical-review — 기획서 기술 사전점검

빌드 착수 전 PRD/기술 명세를 3명이 동시 검토해 실현 가능성·리스크·범위 분할 판정과 최종 PASS/NEEDS_ATTENTION/BLOCKED 를 냅니다 — 분할 권고 시 part 분할 계획 파일까지 제안합니다.

/cc-product:plan-technical-review — 기획서 기술 사전점검#

항목	내용
실행 명령	`/cc-product:plan-technical-review`
분류	워크플로우
난이도	●●○ 보통

한마디로#

집을 짓기 전에 설계도를 들고 "이대로 진짜 지을 수 있나, 위험한 부분은 없나, 한 번에 다 짓기엔 너무 큰 건 아닌가" 를 미리 따져보는 단계입니다. 기획서(PRD)나 기술 명세서를 개발에 들어가기 직전에 3명의 전문가가 동시에 검토해 줍니다.

누가·언제 쓰나요#

기획(Planning)이 끝나고 본격 설계(Design)로 넘어가기 직전, 기술적으로 무리가 없는지 확인하고 싶을 때
기획서에 숨어 있는 기술 리스크(보안·호환성·데이터 등)를 미리 짚어보고 싶을 때
이 작업이 PR(코드 묶음) 하나로 처리하기에 적당한 크기인지, 너무 커서 나눠야 하는지 판단하고 싶을 때

무엇을 해주나요#

세 가지 관점의 점검 결과를 한 화면으로 정리해 최종 판정을 내려줍니다.

실현 가능성(Feasibility) — 지금 기술로 만들 수 있나: FEASIBLE / FEASIBLE_WITH_RISKS / NOT_FEASIBLE
리스크(Risk) — 보안·의존성·마이그레이션 등 위험도: LOW / MEDIUM / HIGH + 대응 방안
범위(Scope) — 한 번에 처리할지 나눌지: NO_SPLIT / CONSIDER_SPLIT / RECOMMEND_SPLIT
최종 판정 — PASS(통과) / NEEDS_ATTENTION(확인 후 진행) / BLOCKED(수정 후 재검토)
나눠야 한다고 판단되면 .bmad/prd-{이름}-part-1.md, .bmad/prd-{이름}-part-2.md 같은 분할 계획 파일까지 제안합니다.

어떻게 쓰나요#

# 최근 plan 문서 자동 탐색 (최근 7일 내 문서를 알아서 찾음)
/cc-product:plan-technical-review

# 특정 문서 지정
/cc-product:plan-technical-review .bmad/prd-community.md

# Tech Spec 리뷰
/cc-product:plan-technical-review .bmad/tech-spec-community.md

소규모 변경이라 범위 분석이 불필요하면 --skip-scope, 상세 결과를 다 보고 싶으면 --verbose를 덧붙이세요.

안에서 무슨 일이 벌어지나요#

문서 찾기·읽기 — .bmad/에서 최근 기획서/명세서를 찾아 제목·요구사항·기술 고려사항·의존성을 뽑아냅니다. 없으면 /cc-product:plan을 먼저 하라고 안내합니다.
3명 동시 검토 — 실현 가능성·리스크·범위를 담당하는 리뷰어가 각자 관점에서 동시에 분석합니다. (기존 코드를 실제로 뒤져 비슷한 기능이 있는지까지 확인)
결과 통합·판정 — 세 결과를 합쳐 PASS / NEEDS_ATTENTION / BLOCKED 중 하나로 최종 판정하고 핵심 발견·권고를 한 박스로 보여줍니다.
다음 단계 안내 — 설계로 넘어갈지, 기획을 보완할지, 분할 파일을 만들지 선택지를 제시합니다. (확인만 필요한 경우는 막지 않고, 정말 막아야 할 BLOCKED만 차단)

⚙️ 상세 옵션·실행 명세 (개발자 / AI 에이전트용)

Triggers#

Planning 스테이지 완료 후 Design 진행 전 기술 검증이 필요할 때
PRD/Tech Spec의 기술적 리스크를 사전에 평가하고 싶을 때
Plan이 단일 PR로 적절한지 범위를 검증하고 싶을 때

Usage#

# 최근 plan 문서 자동 탐색
/cc-product:plan-technical-review

# 특정 문서 지정
/cc-product:plan-technical-review .bmad/prd-community.md

# Tech Spec 리뷰
/cc-product:plan-technical-review .bmad/tech-spec-community.md

Parameters#

Parameter	Required	Description	Example
`plan_path`	⚠️	Plan 문서 경로 (없으면 최근 7일 내 문서 자동 탐색)	`.bmad/prd-community.md`

Options#

Option	Default	Description
`--skip-scope`	false	Scope 분석 건너뛰기 (소규모 변경 시)
`--verbose`	false	상세 분석 결과 출력

Execution Flow#

Phase 1: Plan Document Loading#

문서 탐색: .bmad/prd-*.md 또는 .bmad/tech-spec-*.md 중 최근 7일 내 파일 검색
- 1개 매치: 자동 사용
- 복수 매치: 사용자 선택 요청
- 0개 매치: /cc-product:plan 먼저 실행 안내
문서 파싱: 제목, 요구사항, 기술 고려사항, AC, 의존성 추출

Phase 2: Parallel Review (3 Reviewers)#

3개 리뷰어가 동시에 실행되어 각각의 관점에서 plan을 분석한다.

Reviewer 1: Feasibility (기술적 실현 가능성)

검증 항목:
- [ ] 기술 스택 호환성: 현재 프로젝트의 패키지/프레임워크로 구현 가능한가?
- [ ] API 의존성: 외부 API가 필요한 경우 사용 가능한가? 비용은?
- [ ] 데이터 모델: 기존 DB 스키마와 충돌 없이 확장 가능한가?
- [ ] 성능 영향: 예상 사용량에서 성능 저하 없는가?
- [ ] 기존 코드 재사용: 유사 기능이 이미 존재하는가? (Grep 기반 탐색)

Output: FEASIBLE / FEASIBLE_WITH_RISKS / NOT_FEASIBLE

Reviewer 2: Risk (리스크 분석)

검증 항목:
- [ ] 보안 리스크: 인증/인가, 데이터 노출, 입력 검증 이슈
- [ ] 의존성 리스크: 외부 라이브러리 버전 충돌, deprecated API 사용
- [ ] 마이그레이션 리스크: 기존 데이터/스키마 변경 필요성
- [ ] 통합 리스크: 다른 모듈/서비스와의 통합 포인트
- [ ] 롤백 리스크: 배포 후 문제 시 롤백 가능한가?

Output per risk: HIGH / MEDIUM / LOW + 대응 방안

Reviewer 3: Scope (범위 분석)

검증 항목:
- [ ] 예상 변경 파일 수: 단일 PR 적합 범위인가? (guideline: ≤30 files)
- [ ] 레이어 수: 몇 개 레이어를 건드리는가? (Data, Domain, Presentation, Backend)
- [ ] 기능 분리 가능성: 논리적으로 독립 배포 가능한 단위가 있는가?
- [ ] 의존성 순서: 선행 작업이 필요한 부분이 있는가?

Split 판단 기준:

조건	결과
≤30 files, ≤2 layers	NO_SPLIT — 단일 PR 적합
30-60 files 또는 3 layers	CONSIDER_SPLIT — 분할 검토
>60 files 또는 4+ layers 또는 독립 기능 존재	RECOMMEND_SPLIT — 분할 권장

Split 권장 시 출력:

## Recommended Split

### Part 1: {title} (foundation)
- Files: {estimated count}
- Scope: {description}
- Dependencies: none

### Part 2: {title} (depends on Part 1)
- Files: {estimated count}
- Scope: {description}
- Dependencies: Part 1

Plan 파일명: .bmad/prd-{slug}-part-1.md, .bmad/prd-{slug}-part-2.md

Phase 3: Consolidation#

3개 리뷰 결과를 통합하여 최종 판정:

╔════════════════════════════════════════════════════════════════╗
║  Plan Technical Review: {PASS | NEEDS_ATTENTION | BLOCKED}    ║
╠════════════════════════════════════════════════════════════════╣
║                                                                ║
║  Feasibility:  {FEASIBLE | WITH_RISKS | NOT_FEASIBLE}         ║
║  Risk Level:   {LOW | MEDIUM | HIGH}                          ║
║  Scope:        {NO_SPLIT | CONSIDER_SPLIT | RECOMMEND_SPLIT}  ║
║                                                                ║
║  Key Findings:                                                 ║
║    {finding 1}                                                 ║
║    {finding 2}                                                 ║
║                                                                ║
║  Recommendations:                                              ║
║    {recommendation 1}                                          ║
║    {recommendation 2}                                          ║
║                                                                ║
╚════════════════════════════════════════════════════════════════╝

최종 판정 기준:

조건	판정
Feasible + Low Risk + No Split	PASS
With Risks 또는 Medium Risk 또는 Consider Split	NEEDS_ATTENTION — 사용자 확인 후 진행
Not Feasible 또는 High Risk	BLOCKED — 수정 후 재검토 필요

Phase 4: Handoff#

리뷰 완료 후 옵션 제시:

1. Clear context and build → /clear 후 /cc-product:design
2. Start design → /cc-product:design 바로 실행
3. Refine plan → 지적사항 반영 후 plan 수정
4. Split plan → 분할된 plan 파일 생성
5. Done → 리뷰 결과만 확인, 추가 작업 없음

Key Rules#

Non-blocking by default: NEEDS_ATTENTION은 사용자 확인 후 진행 가능 (BLOCKED만 차단)
Evidence-based: Grep/Glob으로 기존 코드를 실제 확인하여 판단
No false positives: 불확실한 리스크는 MEDIUM으로 분류, HIGH는 명확한 근거 필요
Scope > 분할 강제 금지: 무리한 분할보다 큰 단일 PR이 나을 수 있음. 의심스러우면 NO_SPLIT
독립 실행 가능: 파이프라인 없이도 독립적으로 /cc-product:plan-technical-review 호출 가능

/cc-product:plan — Plan 문서 생성
/cc-product:design — 다음 스테이지 (Design)
/cc-product:review --persona architect — 아키텍처 단독 리뷰
/cc-spec:evaluate — 스펙 평가 (Specification 단계)