| 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) { ... }
const tree = useTreeView(fileData)
return <nav {...tree.containerProps}>
{tree.items.map(item => <div {...item.props}>{item.label}</div>)}
</nav>
const menu = useTreeView(settingsData, { maxDepth: 2 })
작성한 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'
}
샘플 데이터를 채우면 추상적이던 스키마에서 어색한 이름, 빠진 필드, 불필요한 필드가 드러난다.
Step 3: 갭 발견
시뮬레이션 결과에서 자연스럽게 갭이 드러난다:
- 개발: "이 usage가 되려면 내부에 X가 필요한데, 지금은 없다"
- 경험: "3단계에서 사용자가 막히는데, 안내가 없다"
- 설계: "A→B 화살표가 있는데, 실제로는 C를 거쳐야 한다"
- 데이터: "이 필드명이 어색하다" 또는 "이 타입에 X 필드가 빠졌다"
발견된 갭을 정리하여 사용자에게 보여준다.
Step 4: 완료 판정
다음 조건을 모두 만족하면 완료:
- 구체적 산출물이 존재한다 — 코드, 표, 다이어그램 중 하나 이상
- 사용자가 "이거다" 또는 "이 방향이다"라고 확인했다
- 갭이 식별되었다 — 이상과 현실의 차이가 명시적
완료되면 산출물과 발견된 갭을 요약하여 제시한다. 결과는 이후 설계·명세·구현 단계의 입력으로 쓰일 수 있다.
매 턴 출력 형식
## 시뮬레이션: [도메인]
[산출물 — 코드/표/다이어그램]
### 발견된 갭
- 갭 1: ...
- 갭 2: ...
### 질문
제 판단: [판단]. 이유: [근거].
[구체화 질문]
산출물 활용
- 구체 산출물(코드·표·다이어그램·저니맵) — "이게 맞나?" 판정 기준
- 발견된 갭 — 이후 설계 과제 또는 제약 조건으로 이어짐
호출 경로
- 단독 호출 —
/ideal 또는 "이상적으로는…", "다 되면 어떤 모습" 같은 신호로 바로 진입
/discuss 드릴다운 — 상위 논의에서 "이상적 결과" 요소가 막힐 때(이해도 낮음) 이 스킬로 드릴다운하여 구체 산출물을 만들고, 결과·갭을 상위 논의의 해당 요소에 반영하여 복귀
