Day3 Clarify

# Block 0: Clarify 개념 + AskUserQuestion

## EXPLAIN

### 왜 Clarify가 필요한가

#### Garbage In, Garbage Out

프로그래밍에서 가장 오래된 격언 중 하나다: **쓰레기가 들어가면, 쓰레기가 나온다.**

Claude Code도 마찬가지다. 아무리 똑똑한 AI라도 모호한 입력을 받으면 모호한 결과를 낸다.

```
사용자: "로고 만들어줘"
Claude: (어떤 브랜드? 어떤 스타일? 어디에 쓸 건지? 색상은?)
        → 아무것도 모르니까 아무거나 만든다
        → 결과물이 마음에 안 든다
        → "아니 그게 아니라..."
        → 3번 반복
```

이게 바로 **모호한 요구사항의 함정**이다. 머릿속에는 그림이 있는데, Claude에게 전달한 건 단어 3개뿐.

#### Plan은 해결책이 아니다

"그러면 Plan 모드를 쓰면 되지 않나?"

Plan은 **토큰을 본격적으로 써서 내용을 불리는 단계**다. 코드를 탐색하고, 파일 구조를 분석하고, 작업을 분해한다. 여기서 비로소 "어떻게 만들지"를 설계한다.

문제는 — Plan이 **"뭘 만들지"를 추출해주지 않는다는 것**이다.

```
❌ 모호한 채로 Plan에 들어가면:
   "로고 만들어줘" → Plan → "로고를 만드는 계획을 세웠습니다"
   → 뭘 만드는 건지 여전히 모호
   → 계획이 방향을 잡아주지 못함
   → 토큰만 낭비

✅ Clarify를 거치면:
   "로고 만들어줘" → Clarify → "미니멀, 남색+흰색, 앱 아이콘" → Plan
   → 명확한 목표로 계획을 세움
   → 토큰이 의미 있는 곳에 쓰임
```

**Clarify는 Plan보다 앞선 단계다.** 내 의도를 먼저 추출해야, Plan이 올바른 방향으로 토큰을 쓸 수 있다.

#### CC Workflow: 코딩의 4단계

실제로 Claude Code를 제대로 쓰려면 **최소 4단계**가 필요하다. 이건 1기 캠퍼분들도 쓰고 있는 실전 워크플로우다:

```
┌─────────────────────────────────────────────────────────────────────────┐
│                        CC Workflow 101 전체 흐름                         │
└─────────────────────────────────────────────────────────────────────────┘

  사용자 요청
       │
       ▼
┌─────────────┐     ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  clarify    │────▶│    plan     │────▶│  implement  │────▶│    wrap     │
│             │     │             │     │             │     │             │
│ 뭘 만들지   │     │ 어떻게      │     │ 만든다      │     │ 마무리      │
│ 명확화      │     │ 만들지 계획 │     │             │     │ 커밋/PR     │
└─────────────┘     └─────────────┘     └─────────────┘     └─────────────┘

  ════════════════════════════════════════════════════════════════════════
  필수 흐름:  clarify ──▶ plan ──▶ implement ──▶ wrap
  ════════════════════════════════════════════════════════════════════════
```

| 단계 | 역할 | 핵심 질문 |
|------|------|----------|
| **Clarify** | 의도 추출 | "뭘 만들지?" |
| **Plan** | 계획 수립 | "어떻게 만들지?" |
| **Implement** | 실행 | "만든다" |
| **Wrap** | 마무리 | "잘 됐나? 커밋하자" |

**오늘 배우는 Clarify는 이 4단계의 첫 번째다.** 여기서 의도를 명확히 하지 않으면, 나머지 3단계가 전부 잘못된 방향으로 간다.

#### Clarify가 하는 일

Clarify는 이 간극을 메운다:

```
모호한 요구사항          Clarify           구체적인 스펙
"로고 만들어줘"  ──────▶  질문 5개  ──────▶  "미니멀 스타일, 남색+흰색,
                         ▲                    앱 아이콘용, 심볼 마크,
                         │                    PNG 512x512"
                    AskUserQuestion
                    (가설 기반 선택지)
```

### AskUserQuestion이란

Claude Code에는 사용자에게 **구조화된 질문**을 할 수 있는 도구가 있다. 그게 `AskUserQuestion`이다.

핵심은 **Hypothesis-as-Options (가설을 선택지로)** 원칙:

```
❌ BAD (열린 질문):
   "어떤 스타일로 만들까요?"
   → 사용자: "음... 그냥 예쁘게?"  (답변 불가)

✅ GOOD (가설 기반 선택지):
   "어떤 스타일로 만들까요?"
   - 미니멀 (선과 여백 중심)
   - 일러스트 (캐릭터/아이콘 중심)
   - 타이포그래피 (글자 중심)
   → 사용자: "미니멀!"  (즉시 결정)
```

#### 왜 선택지가 나올까? — AI가 토큰을 더 쓰는 것이다

AskUserQuestion은 **question(질문)과 option(선택지)을 동시에 제공**하는 도구다.

이게 뭘 의미하냐면 — Claude가 단순히 "뭘 원해요?"라고 물어보는 게 아니라, **더 많은 토큰을 사용해서** 여러분의 상황을 분석하고, 그럴듯한 선택지까지 만들어서 제안하는 것이다.

```
일반 질문:     "어떤 스타일로 만들까요?"          ← 토큰 적게 사용, 사용자에게 부담 전가
AskUserQuestion: "어떤 스타일?" + [미니멀/일러스트/타이포]  ← 토큰 더 사용, AI가 먼저 고민
```

즉, **AI가 먼저 생각하고, 사용자는 고르기만 하면 된다.** 토큰을 아끼려고 열린 질문을 하면, 결국 모호한 답변 → 재질문 → 더 많은 토큰 낭비로 이어진다. 선택지를 제시하는 게 오히려 효율적이다.

#### 실제 도구 구조

AskUserQuestion은 이런 구조로 되어 있다:

```json
{
  "questions": [
    {
      "question": "어떤 스타일로 만들까요?",
      "header": "스타일",
      "options": [
        {"label": "미니멀", "description": "선과 여백 중심의 깔끔한 디자인"},
        {"label": "일러스트", "description": "캐릭터나 아이콘 중심"},
        {"label": "타이포그래피", "description": "글자 자체가 로고"}
      ],
      "multiSelect": false
    }
  ]
}
```

| 필드 | 역할 | 설명 |
|------|------|------|
| `question` | 질문 | 사용자에게 보여줄 질문 텍스트 |
| `header` | 태그 | 짧은 라벨 (최대 12자). 질문 위에 칩으로 표시 |
| `options` | 선택지 | 2~4개의 가설. 각각 `label`(제목)과 `description`(설명) |
| `multiSelect` | 복수 선택 | `false`면 하나만, `true`면 여러 개 선택 가능 |

한 번에 **최대 4개 질문**을 묶어서 보낼 수 있다