이슈 계획 명령
사용자 입력
text
$ARGUMENTS
예상 형식: /workflow-plan 작업명 [추가 요구사항]
예시:
- •
/workflow-plan REFACTORING 커밋 3개 이내로 - •
/workflow-plan API-REDESIGN 하위 호환성 유지
빈 값이 아니면 사용자 입력을 반드시 고려해야 합니다.
개요
- •
사용자 입력 파싱:
- •$ARGUMENTS의 첫 단어에서 작업명 추출 (예: "REFACTORING")
- •나머지 텍스트에서 추가 요구사항 추출 (예: "커밋 3개 이내로")
- •작업명이 없으면 오류: "작업명을 제공하세요: /workflow-plan 작업명"
- •
전제조건 확인:
- •
docs/work/{작업명}/analysis.md존재 확인 - •없으면 $ARGUMENTS를 요구사항 소스로 사용하여 진행
- •
- •
요구사항 로드:
- •analysis.md 있으면: 선택된 방안, 완료 조건 추출
- •없으면: 사용자 입력을 요구사항으로 해석 (설명, URL, 파일 경로 등)
- •
영향 범위 파악:
- •대략적인 클래스/모듈 나열 (구체적 파일명 X)
- •
커밋 분해 (수직 슬라이싱):
- •각 커밋이 독립 배포 가능하도록
- •사용자 입력의 추가 요구사항 고려 (예: 커밋 개수 제한, 특정 제약사항)
- •수평 슬라이싱 금지: 타입/로직/테스트/UI를 별도 커밋으로 분리 금지
- •수직 슬라이싱: 각 커밋이 타입+로직+테스트를 포함하여 완전한 기능 제공
- •순서: 설정 → 핵심 → 통합 → 마무리
- •각 커밋에 검증 방법 및 "독립 배포 가능" 여부 명시
- •테스트 분류: 각 커밋에 반드시 명시:
- •
TDD: 조건/계산 로직 → 테스트 먼저 작성 - •
TEST-AFTER: UI/연동/E2E → 구현 후 테스트 - •
NO-TEST: 설정/문서/타입only → 테스트 불필요
- •
- •
원칙 위반 검토:
- •코딩 원칙 위반 필요 시 복잡도 추적 테이블 작성
- •
문서 작성:
- •
docs/work/{name}/plan.md생성 (한글)
- •
핵심 규칙
📝 문서 작성 언어
중요: 모든 문서는 한글로 작성해야 합니다.
✅ 해야 할 것
- •체크리스트 중심
- •analysis.md 참조만 (반복 X)
- •수직 슬라이싱: 각 커밋 독립 배포 가능
- •코딩 원칙 반영
- •영향 범위는 대략적으로
❌ 하지 말아야 할 것
- •문제 재정의 (analysis.md에 있음)
- •구체적 파일 목록 나열
- •장황한 설명
🎯 수직 슬라이싱 원칙 (중요)
각 커밋이 만족해야 할 조건:
- •빌드 성공: 컴파일 에러 없음
- •기존 기능 보존: 기존 테스트 통과
- •독립 테스트 가능: 해당 커밋만으로 테스트 가능
- •의미 있는 가치: 사용자/개발자에게 실질적 가치 제공
❌ 수평 슬라이싱 금지:
- •타입만 → 로직만 → 테스트만 → UI만 분리 (X)
- •이런 분리는 각 커밋이 기능적으로 불완전함
✅ 수직 슬라이싱 예시:
- •커밋 1: 타입 + 로직 + 테스트 + 스키마 (수동 설정으로 사용 가능)
- •커밋 2: UI 통합 (완전한 사용자 경험)
🧪 테스트 분류 규칙
TDD 필수 (실패하는 테스트 먼저 작성):
- •조건분기가 있는 비즈니스 로직
- •계산, 검증, 파서
- •상태 변경, 데이터 변환
TEST-AFTER (구현 후 테스트):
- •시각적 출력이 있는 UI 컴포넌트
- •외부 API/DB 연동
NO-TEST (생략):
- •설정 파일 (JSON, YAML, env)
- •문서, 순수 타입, 이름 변경
📐 테스트 수준 선택
수준 (가장 낮은 유효 수준부터):
| 수준 | 사용 시점 |
|---|---|
UNIT | 순수 함수, 비즈니스 로직, 계산, 검증 |
INT | DB 쿼리, API 엔드포인트, 서비스 간 통신 |
COMP | UI 컴포넌트 (렌더링, 상호작용, 접근성) |
E2E | 핵심 사용자 여정만 (인증, 결제, 핵심 플로우) |
빠른 결정 참고:
- •조건 로직? → UNIT
- •DB 관련? → INT
- •UI 컴포넌트? → COMP
- •핵심 사용자 여정? → E2E (아래 기준 충족 시만)
혼합 수준: 기능에 둘 다 필요하면 UNIT + E2E 사용 (예: 할인 로직 + 결제 흐름)
E2E 정당화 필수: E2E는 작성은 쉽지만 실행/유지보수 비용이 높음. 다음 조건을 모두 충족할 때만 사용:
- •하위 수준 테스트 불가: 여러 서비스/페이지 걸침, 모킹하면 의미 없음
- •매출/신뢰 핵심: 인증, 결제, 핵심 전환 경로
- •과거 버그 이력: 프로덕션에서 깨진 적 있는 흐름
- •실패가 치명적: 규제, 보안, 비즈니스 크리티컬
안티패턴: UNIT + INT로 충분히 커버되는 시나리오에 E2E 작성.
문서 템플릿
생성할 파일: docs/work/{작업명}/plan.md (한글)
markdown
# [작업명] - 실행 계획 > **분석 결과**: `analysis.md` 참조 > **선택 방안**: [방안 N] ## 📁 영향 범위 (대략적) **주요 영역**: [상태바 관리자, 설정 관리자 등] --- ## 📝 커밋 계획 ### ✅ 커밋 1: [제목] **목표**: [1문장 - 이 커밋이 제공하는 완전한 가치 설명] **테스트 요구사항**: [TDD | TEST-AFTER | NO-TEST] **테스트 수준**: [UNIT | INT | COMP | E2E | UNIT + E2E] **작업 체크리스트**: - [ ] [구체적 작업 1] - [ ] [구체적 작업 2] - [ ] 테스트 ([수준]): [구체적 테스트 케이스] (TDD/TEST-AFTER인 경우) - [ ] 빌드 확인: [빌드 명령어] **검증 방법**: 1. [구체적 검증 방법] 2. [사용자 시나리오] **독립 배포 가능**: ✅ / ⚠️ [이유] --- ### ⬜ 커밋 2: [제목] **목표**: [1문장 - 이 커밋이 제공하는 완전한 가치 설명] **테스트 요구사항**: [TDD | TEST-AFTER | NO-TEST] **테스트 수준**: [UNIT | INT | COMP | E2E | UNIT + E2E] **작업 체크리스트**: - [ ] [구체적 작업 1] - [ ] [구체적 작업 2] - [ ] 테스트 ([수준]): [구체적 테스트 케이스] (TDD/TEST-AFTER인 경우) - [ ] 빌드 확인: [빌드 명령어] **검증 방법**: 1. [구체적 검증 방법] 2. [사용자 시나리오] **독립 배포 가능**: ✅ / ⚠️ [이유] --- ## ⚠️ 원칙 위반 정당화 (필요 시만) | 원칙 위반 | 왜 필요한가 | 단순한 대안 거부 이유 | | --------- | ----------------------- | ----------------------- | | any 사용 | VS Code API 타입 불완전 | @types 수정 비용 > 이득 | --- ## 📊 진행 상황 - [ ] 커밋 1 - [ ] 커밋 2
실행
이제 위 지침에 따라 작업을 시작하세요.