ideal

name	ideal
description	방향은 합의됐는데 "다 되면 어떤 모습인지"가 아직 추상적일 때, 이상적 결과를 구체적 산출물(코드·표·다이어그램·저니맵)로 시뮬레이션한다. "이상적으로는...", "결과물이 어떤 모습이어야", "다 되면 어떻게 생겼을까", "API가 어떻게 보여야", "사용자 경험이 어떨지", "/ideal" 등을 말할 때 사용. 추상적 합의("좋은 걸 만들자")를 "이게 맞나?"를 판단할 수 있는 구체 산출물로 바꾸는 것이 목적이다.

역할

"다 되면 어떤 모습인가?"에 대한 답이 추상적일 때, 도메인에 맞는 시뮬레이션을 함께 만들어서 구체화한다.

추상적 합의는 위험하다. "좋은 API를 만들자"에 모두가 동의하지만, "좋은"의 의미가 각자 다르다. 이 스킬은 구체적 산출물을 먼저 만들어서 "이게 맞나?"를 판단할 수 있게 한다. README-driven development, consumer-first API design, journey mapping 등의 기법을 상황에 맞게 적용한다.

Step 1: 도메인 감지

사용자의 맥락에서 도메인을 판별한다:

도메인	시그널	시뮬레이션 도구
개발	hook, API, SDK, 컴포넌트, 함수	Code Usage 시뮬레이션
경험	사용자 흐름, 온보딩, 워크플로우	저니맵
설계	아키텍처, 모듈, 레이어, 의존성	Mermaid 다이어그램
데이터	스키마, 타입, 필드, 모델	스키마 네이밍 + 샘플 데이터

도메인이 겹치면 (예: "SDK의 사용자 경험") 주 도메인 하나를 선택하고, 나머지는 보조로 활용한다. 판단이 모호하면 사용자에게 확인한다.

Step 2: 시뮬레이션 실행

개발: Code Usage 시뮬레이션

핵심 원칙: 구현이 아니라 소비를 먼저 쓴다.

사용자가 만들려는 것을 "쓰는 쪽"의 코드를 먼저 작성한다. 내부 구현이 아니라, 완성된 후 소비자가 작성할 코드의 모습을 상상한다.

1. 가장 흔한 사용 시나리오의 코드를 작성한다
2. "이 코드가 자연스러운가?" 판단한다
3. 엣지 케이스 시나리오 1~2개를 추가한다
4. 시나리오들에서 API 시그니처를 역추출한다

예시:

// ❌ 구현부터 생각하기
function useTreeView(options: TreeViewOptions) { ... }

// ✅ 사용부터 생각하기
// 시나리오 1: 파일 탐색기
const tree = useTreeView(fileData)
return <nav {...tree.containerProps}>
  {tree.items.map(item => <div {...item.props}>{item.label}</div>)}
</nav>

// 시나리오 2: 설정 메뉴 (깊이 제한)
const menu = useTreeView(settingsData, { maxDepth: 2 })

// → 역추출된 API: useTreeView(data, options?) → { containerProps, items }

작성한 usage 코드를 사용자에게 보여주고 "이 코드를 쓰고 싶은가?" 확인한다. 자연스럽지 않은 부분이 있으면 그게 곧 설계의 갭이다.

경험: 저니맵

사용자의 경험을 시간 순서대로 시뮬레이션한다.

| 단계 | 행동 | 생각/감정 | 터치포인트 | 문제점 |
|------|------|----------|-----------|--------|
| 1. 진입 | ... | ... | ... | ... |
| 2. 탐색 | ... | ... | ... | ... |
| 3. 핵심 행동 | ... | ... | ... | ... |
| 4. 완료 | ... | ... | ... | ... |

빈 표를 먼저 만들고, 단계를 사용자와 함께 채운다. "이 단계에서 사용자가 뭘 느끼는가?"가 핵심 질문이다.

설계: Mermaid 다이어그램

모듈 관계를 시각화한다.

1. 핵심 모듈 3~5개를 식별한다
2. 모듈 간 의존성/데이터 흐름을 Mermaid로 그린다
3. "이 화살표가 맞는가?" 확인한다
4. 빠진 모듈이나 잘못된 의존성을 발견한다

다이어그램은 현재 상태가 아니라 이상적 상태를 그린다. 현재 상태와의 차이가 곧 할 일 목록이 된다.

데이터: 스키마 네이밍 + 샘플 데이터

타입/스키마의 필드명과 구조를 구체화한다. 네이밍이 곧 설계이므로, 이름을 먼저 정하면 구조가 따라온다.

1. 핵심 타입의 필드를 나열한다 (이름 + 타입)
2. 샘플 데이터 2~3행을 채운다
3. "이 필드명이 자연스러운가?" 판단한다
4. 필드명에서 누락된 개념이나 중복을 발견한다

예시:

// 필드명 초안
type Section = {
  id: string
  title: string
  items: Item[]
  layout: 'grid' | 'list'  // ← 이 필드명이 맞나?
}

// 샘플 데이터로 검증
const sample: Section = {
  id: 'hero',
  title: '메인 배너',
  items: [{ ... }],
  layout: 'grid'  // ← "grid"가 레이아웃인가 표시 방식인가?
}
// → "layout"보다 "display"? "variant"? 네이밍 논의 시작점

샘플 데이터를 채우면 추상적이던 스키마에서 어색한 이름, 빠진 필드, 불필요한 필드가 드러난다.

Step 3: 갭 발견

시뮬레이션 결과에서 자연스럽게 갭이 드러난다:

• 개발: "이 usage가 되려면 내부에 X가 필요한데, 지금은 없다"
• 경험: "3단계에서 사용자가 막히는데, 안내가 없다"
• 설계: "A→B 화살표가 있는데, 실제로는 C를 거쳐야 한다"
• 데이터: "이 필드명이 어색하다" 또는 "이 타입에 X 필드가 빠졌다"

발견된 갭을 정리하여 사용자에게 보여준다.

Step 4: 완료 판정

다음 조건을 모두 만족하면 완료:

1. 구체적 산출물이 존재한다 — 코드, 표, 다이어그램 중 하나 이상
2. 사용자가 "이거다" 또는 "이 방향이다"라고 확인했다
3. 갭이 식별되었다 — 이상과 현실의 차이가 명시적

완료되면 산출물과 발견된 갭을 요약하여 제시한다. 결과는 이후 설계·명세·구현 단계의 입력으로 쓰일 수 있다.

매 턴 출력 형식

## 시뮬레이션: [도메인]

[산출물 — 코드/표/다이어그램]

### 발견된 갭
- 갭 1: ...
- 갭 2: ...

### 질문
제 판단: [판단]. 이유: [근거].
[구체화 질문]

산출물 활용

• 구체 산출물(코드·표·다이어그램·저니맵) — "이게 맞나?" 판정 기준
• 발견된 갭 — 이후 설계 과제 또는 제약 조건으로 이어짐

호출 경로

• 단독 호출 — /ideal 또는 "이상적으로는…", "다 되면 어떤 모습" 같은 신호로 바로 진입
• /discuss 드릴다운 — 상위 논의에서 "이상적 결과" 요소가 막힐 때(이해도 낮음) 이 스킬로 드릴다운하여 구체 산출물을 만들고, 결과·갭을 상위 논의의 해당 요소에 반영하여 복귀