3단계: 설계

3단계: 설계

이전 단계 산출물

•0단계 문제 정의: !cat docs/work/$(cat docs/work/.current 2>/dev/null)/0-problem-definition.md 2>/dev/null || echo "NO_FILE"
•1단계 목표: !cat docs/work/$(cat docs/work/.current 2>/dev/null)/1-goals.md 2>/dev/null || echo "NO_FILE"
•2단계 요구사항: !cat docs/work/$(cat docs/work/.current 2>/dev/null)/2-requirements.md 2>/dev/null || echo "NO_FILE"

기존 산출물 확인

•기존 파일: !cat docs/work/$(cat docs/work/.current 2>/dev/null)/3-design.md 2>/dev/null || echo "NO_FILE"

지시사항

이 단계의 목적은 구현 전에 큰 그림을 그리고, 기술 선택의 근거를 명확히 하고, 불확실한 부분을 식별하는 것이다.

전제 조건

•0~2단계 산출물이 없으면 해당 단계를 먼저 실행하라고 안내하고 중단한다.

진행 방식

•스킬 시작 즉시 현재 버전 디렉토리의 3-design.md 파일을 산출물 파일 형식 템플릿으로 생성한다. 기존 파일이 있으면 이어서 진행한다.

3-1. 큰 구조

•
2단계 Must 요구사항을 기반으로 전체 구조를 제안한다:
- •입력 → 처리 → 출력 흐름
- •컴포넌트 경계
- •상태 소유 주체
- •예상 병목 지점
•
필요하면 기존 코드베이스를 탐색한다 (Glob, Grep, Read 사용).
•
구조를 사용자에게 보여주고 합의를 구한다.

3-2. 기술 선택 근거

•
주요 기술 선택에 대해 사용자와 논의한다:
- •왜 이 기술인가?
- •대안은 무엇이었고 왜 배제했는가?
- •감당 가능한 복잡도인가?
•
합의된 근거를 기록한다.

3-3. 불확실한 부분 식별

•
"이게 가능한가?"가 의심되는 부분을 식별한다.
•
사용자에게 "이 중에서 가장 불확실한 부분이 어디인가요?" 라고 질문한다.
•
식별된 불확실성은 5단계(MVP)에서 최우선으로 검증할 것임을 명시한다.
•
각 소주제(3-1, 3-2, 3-3)의 합의가 이루어질 때마다 즉시 파일을 업데이트한다.

산출물 파일 형식

markdown

# 3단계: 설계

## 3-1. 구조

### 전체 흐름
(입력 → 처리 → 출력 다이어그램 또는 설명)

### 컴포넌트
| 컴포넌트 | 역할 | 소유하는 상태 |
|----------|------|--------------|
| ... | ... | ... |

### 예상 병목
- ...

## 3-2. 기술 선택

| 선택 | 이유 | 배제한 대안 | 배제 이유 |
|------|------|------------|----------|
| ... | ... | ... | ... |

## 3-3. 불확실한 부분 (5단계에서 우선 검증)
1. ...
2. ...

주의사항

•설계 제안은 하되, 결정은 사용자가 한다.
•기존 코드베이스의 패턴을 존중한다. 새로운 패턴을 도입하려면 반드시 사용자 동의를 구한다.
•다이어그램은 ASCII art 또는 간단한 텍스트로 충분하다.
•각 소주제(3-1, 3-2, 3-3)를 파일에 기록한 후, 기록 내용을 사용자에게 보여주고 확인을 받는다. 확인 전에 다음 소주제로 넘어가지 않는다.
•이 단계가 완료되면 "다음 단계: /tf:4로 작업을 분해하세요." 라고 안내한다.