에픽 분석 명령
사용자 입력
text
$ARGUMENTS
사용자 입력이 비어있지 않다면 반드시 고려해야 합니다.
개요
- •
사용자 입력 파싱:
- •$ARGUMENTS에서 프로젝트 설명 추출
- •프로젝트명 생성 (2-4 단어, 영문, 하이픈 구분)
- •
전체 파악:
- •프로젝트 목표를 1-2문장으로 정의
- •경계 식별: 포함 범위, 명시적 제외 범위
- •현재 상태 파악 (기존 코드, 인프라, 제약사항)
- •
하위 작업 식별:
- •프로젝트를 최소 개수의 독립적 작업 단위로 분해
- •각 하위 작업은 단일 워크플로우 사이클(analyze → plan → execute)로 완료 가능해야 함
- •각 하위 작업명 생성 (2-4 단어, 영문, 하이픈 구분)
- •
의존관계 분석:
- •선행 관계 매핑
- •병렬 진행 가능한 작업 식별
- •크리티컬 패스 파악
- •
리스크 평가:
- •사전 검증이 필요한 기술적 불확실성 (
/workflow-validate) - •외부 의존성 또는 미지수
- •분해 자체가 불확실한 영역
- •사전 검증이 필요한 기술적 불확실성 (
- •
ADR 평가:
- •분해 완료 후, 프로젝트 수준 결정이 ADR 기준(PRICE)에 해당하는지 평가
- •에픽 수준 결정은 해당하는 경우가 많음: 기술 선택, 아키텍처 패턴, 횡단 관심사
- •PRICE 기준 하나라도 해당 시, 문서에 ADR 평가 섹션 추가
- •
분해 확신도 평가:
- •판단 솔직성 규칙 적용 (workflow-analyze와 동일 원칙)
- •확신: 경계가 명확하고 도메인을 잘 이해함
- •잠정적: 초기 작업 수행 후 일부 경계가 바뀔 수 있음
- •
문서 작성:
- •
docs/epic/{프로젝트명}/analysis.md생성 (한글)
- •
핵심 규칙
📝 문서 작성 언어
중요: 모든 문서는 한글로 작성해야 합니다.
📝 사고 순서
전체를 먼저 이해하고, 분해는 그 다음. 전체 이해 없이 성급하게 분해하면 잘못된 경계가 만들어진다.
🎯 분해 원칙 (매우 중요)
- •최소 분할: 전체 범위를 커버하는 최소 개수의 하위 작업. 항상 같이 변경되는 두 작업은 하나의 작업이다.
- •세션 독립적: 각 하위 작업은 별도 Claude Code 세션에서 자체 컨텍스트(analysis.md, plan.md)만으로 실행 가능해야 함 — "이전 세션이 알고 있던 것"에 암묵적으로 의존하면 안 됨.
- •수직 분할: 레이어별 분할(DB → API → UI) 금지. 기능 또는 도메인 경계로 분할.
- •크기 기준:
- •각 하위 작업 =
/workflow-plan으로 계획 시 1-5 커밋 - •1 커밋 수준 → 너무 작음, 인접 작업과 합칠 것
- •10+ 커밋 수준 → 추가 분할 필요
- •각 하위 작업 =
- •워크플로우 입력 가능: 각 하위 작업 설명이
/workflow-analyze {작업명}입력으로 충분해야 함
🎭 객관성 원칙 (매우 중요)
핵심: 분해 자체를 오버엔지니어링하지 말 것. 목표는 명확함이지 완벽함이 아니다.
- •
과잉 분해 편향
- •AI는 "안전하게"라며 지나치게 쪼개는 경향이 있음
- •자문: "이 두 작업을 합치면 의미 있는 것을 잃는가?"
- •답이 아니오면 → 합칠 것
- •
범위 팽창 편향
- •AI는 원래 요청에 없는 "있으면 좋은" 하위 작업을 추가하는 경향이 있음
- •모든 하위 작업은 사용자의 명시된 목표에서 추적 가능해야 함
- •추적 불가 → 제외하거나 "향후 고려"로 명시
- •
완벽주의 편향
- •AI는 불필요한 "셋업"이나 "정리" 작업을 추가하는 경향이 있음
- •인프라/도구 작업은 다른 작업을 언블록할 때만 유효
- •팀이 이미 알고 있는 것에 대해 하위 작업을 만들지 말 것
- •
대칭 편향
- •AI는 모든 하위 작업을 비슷한 크기로 맞추려는 경향이 있음
- •크기가 불균형해도 자연스러움 — 억지로 균등하게 맞추지 말 것
- •
판단 솔직성 (workflow-analyze와 동일 원칙)
- •확신: 도메인을 잘 이해하고 경계가 명확 → 확정적으로 기술
- •잠정적: 일부 경계가 변할 수 있음 → 불확실 영역 표시, Phase 1 후 재검토 권장
- •기본값은 "잠정적"이다. "확신"은 도메인 이해 + 명확한 경계를 요구한다.
✅ 해야 할 것
- •프로젝트 목표 1-2문장
- •최소 개수의 하위 작업 (적고 큰 작업 선호)
- •명확한 의존관계 그래프
- •각 하위 작업에
/workflow-analyze입력으로 충분한 이름과 설명 - •상대적 크기(S/M/L) 추정
- •
/workflow-validate필요 항목 식별 - •불확실한 경계 명시적 표시
❌ 하지 말아야 할 것
- •자명한 셋업에 하위 작업 생성 (프로젝트 초기화, 린터 설정 등) — 진짜 복잡한 경우만
- •기술 레이어별 분할 (타입 → 로직 → 테스트 → UI)
- •원래 범위에 없는 작업 추가 — 명시적 표시 없이
- •시간/일수 추정 (상대적 크기만 사용)
- •구현 세부사항 과도 명시 (그건 workflow-analyze의 역할)
문서 템플릿
생성할 파일: docs/epic/{프로젝트명}/analysis.md (한글)
markdown
# [프로젝트명] - 에픽 분석
## 개요
**프로젝트 목표**: [1-2문장 — 완료 시 달성하는 것]
**배경**: [왜 지금? 이 프로젝트를 시작하게 된 계기]
---
## 범위
**포함**:
- [범위에 포함되는 것]
**제외**:
- [명시적으로 제외 — 이유 포함]
**현재 상태**: [현재 무엇이 존재하는지 간략 설명]
---
## 하위 작업 분해
<!-- 확신: 이 형식 사용 -->
**분해 확신도**: 확신 (경계가 명확함)
<!-- 잠정적: 이 형식 사용 -->
**분해 확신도**: 잠정적 (경계가 변할 수 있음)
**불확실 영역**: [어떤 하위 작업 경계가 변할 수 있고 왜]
**재검토 시점**: [어떤 작업 완료 후 재평가할지]
### 작업 1: [이름] (크기: S/M/L)
**목표**: [1문장 — 이 작업이 독립적으로 달성하는 것]
**분리 이유**: [왜 다른 작업의 일부가 아닌지]
**워크플로우 입력**: [`/workflow-analyze {이름}` 실행 시 핵심 컨텍스트 — 2-3문장]
### 작업 2: [이름] (크기: S/M/L)
[동일 구조]
### 작업 N: [이름] (크기: S/M/L)
[동일 구조]
---
## 의존관계
작업 1 ──→ 작업 3 ──→ 작업 5 작업 2 ──→ 작업 4 ──┘
code
**크리티컬 패스**: 작업 1 → 작업 3 → 작업 5
**병렬 가능**: 작업 1과 작업 2는 동시 진행 가능
---
## 리스크 및 사전 검증
**`/workflow-validate` 필요**:
- [기술적 불확실성 1]: [무엇을 왜 검증해야 하는지]
**외부 의존성**:
- [의존성]: [불가 시 영향]
---
## 권장 실행 순서
**Phase 1**: [작업명 — 기반]
**Phase 2**: [작업명 — 핵심 기능]
**Phase 3**: [작업명 — 통합/마무리]
> 시작: `/workflow-analyze {작업-1-이름}`
---
## ADR 평가
<!-- 프로젝트 수준 결정이 PRICE 기준에 해당할 때만 이 섹션 포함 -->
<!-- 해당 없으면 섹션 자체를 생략 -->
**ADR 필요 결정**:
- [결정 1]: PRICE 기준 [R, I] — [간략한 이유]
- [결정 2]: PRICE 기준 [P] — [간략한 이유]
**권장**: 하위 작업 실행 전 ADR 작성
**권장 시점**: 에픽 분석 승인 후, 첫 `/workflow-analyze` 실행 전
> 생성하려면: `/adr [주제]`
---
## 자체 점검
- [ ] 최소 개수의 하위 작업 (어떤 두 작업도 합칠 수 없음)
- [ ] 모든 하위 작업이 명시된 프로젝트 목표에서 추적 가능
- [ ] "있으면 좋은" 작업이 몰래 들어가지 않았음
- [ ] 각 하위 작업이 세션 독립적 (암묵적 컨텍스트 의존 없음)
- [ ] 수직 분할 (각 작업이 완전한 기능 제공)
- [ ] 분해 확신도를 솔직하게 평가
실행
이제 위 지침에 따라 작업을 시작하세요.