---
name: interview-me
description: "사용자가 원해야 한다고 생각하는 것이 아니라, 실제로 원하는 것을 끌어냅니다. 기저 의도에 약 95% 확신이 들 때까지 한 번에 질문 하나씩 인터뷰해서 이룹니다. 요청이 덜 명세되었을 때(\"for whom\"이나 \"why now\" 없이 \"build me X\"), 사용자가 명시적으로 호출할 때(\"interview me\", \"grill me\", \"are we sure?\", \"stress-test my thinking\"), 또는 계획, 스펙, 코드가 있기 전에 모호한 요구사항을 조용히 채워 넣고 있는 자신을 알아차릴 때 사용하세요."
---

# Interview Me

## 개요

사람들이 요청하는 것과 실제로 원하는 것은 다릅니다. "대시보드"를 달라고 하는 것은 대시보드가 문제를 풀어서가 아니라, 보통 그렇게 요청하기 때문입니다. 맞출 숫자 없이 "make it faster"(더 빠르게)라고 말합니다.

이 간극을 찾는 가장 싼 시점은 계획, 스펙, 코드가 생기기 전입니다. 만들기 시작하면 전환 비용은 실재하고, 사용자는 잘못된 것을 "이 정도면 됐다"로 합리화합니다. 맞지 않는 것이 그 자리에 고정됩니다.

이 스킬은 비용이 들기 전에 그 간극을 닫습니다. 다른 Define 단계 스킬은 원하는 것을 대략 이미 안다고 가정합니다. `idea-refine`는 아이디어에서 변형을 만들고, `spec-driven-development`는 요구사항을 적고, `doubt-driven-development`는 초안을 만든 뒤 계획을 스트레스 테스트합니다. Interview-me는 그 모든 것보다 앞입니다. 한 번에 질문 하나씩, 최선의 추정을 붙여, 사용자가 말하기 전에 무슨 말을 할지 예측할 수 있을 때까지 묻습니다.

## 언제 사용하나

다음일 때 이 스킬을 적용하세요.

- 요청에 다음 중 적어도 하나가 빠져 있다. 사용자가 **누구**인지, **왜** 그것을 원하는지, **성공**이 어떤 모습인지, 구속력 있는 **제약 조건**이 무엇인지
- 요청이 구체적이기보다 관습적이다("build me X", "make it faster"). 추측 없이는 그 관습을 풀 수 없다
- 드러내지 않은 가정으로 시작하고 싶은 유혹이 든다
- 합리적인 가치 둘이 긴장 관계인데(단순함과 유연성, 비용과 속도), 사용자가 어느 쪽을 최적화하는지 말하지 않았다
- 사용자가 명시적으로 호출한다. "interview me", "grill me", "before we start, are we sure?", "stress-test my thinking"

**사용하지 말아야 할 때:**

- 요청이 모호하지 않고 그 자체로 완결된다("rename this variable", "fix this typo")
- 사용자가 검증보다 속도를 명시적으로 요청했다
- 순수한 정보 요청이다("how does X work?", "what does this code do?")
- 기계적인 작업이다(이름 변경, 포맷, 파일 이동)
- 이미 확신도가 95% 이상이다. 아직 아니라고 가정하기 전에 아래 중단 조건을 다시 읽으세요

## 로딩 제약

이 스킬에는 살아 있고 응답하는 사용자가 필요합니다. CI 파이프라인, 예약 실행, `/loop`, autonomous-loop 같은 **비대화형 컨텍스트에서는 호출하지 마세요.** 그런 맥락에 있는데 요청이 덜 명세되었다면, 추측하지 말고 사용자에게 블로커라고 표시하세요.

## 절차

### 1단계: 확신도 숫자와 함께 가설을 세우기

무엇이든 묻기 전에, 사용자가 원하는 것에 대한 현재 최선의 파악을 **한 문장**으로 적고, 정직한 확신도 숫자(0-100%)를 붙이세요.

```
HYPOTHESIS: 스탠드업에서 "우리 잘하고 있나?"에 답할 방법이 필요하고, "대시보드"는 그때 떠오른 관습이었습니다.
CONFIDENCE: ~30%. 빠짐: 누구를 위한 것인지, 이 맥락에서 "지표"가 무엇인지, 성공이 어떤 모습인지
```

숫자가 정직함을 강제합니다. 높은 숫자를 적어 놓고도 다음에 물을 세 질문에 대한 사용자 반응을 실제로 예측할 수 없다면, 그 숫자는 틀린 것입니다. 방어할 수 있는 확신도에서 시작하세요.

확신도가 약 70% 아래이면, 같은 줄에 짧은 이유를 붙이세요. 아직 해결되지 않았거나 빠진 것이 무엇인지입니다. 이렇게 하면 인터뷰가 무엇을 드러내야 하는지 사용자에게 정확히 알려 주고, 숫자가 막연한 신호가 되는 것을 막습니다.

### 2단계: 한 번에 질문 하나씩, 각각에 추정을 붙여 묻기

형식:

```
Q: <초점 있는 질문 하나>
GUESS: <그 답에 대한 당신의 가설과, 그 가설을 만든 추론>
```

다음 질문을 하기 전에 사용자의 반응을 기다리세요.

**왜 한꺼번에가 아니라 한 번에 하나인가:**

- 목록 속에 묻어 두면 사용자가 당신의 가설에 반응할 수 없습니다
- 묶음은 훑어 읽기와 피상적인 답을 부추깁니다
- 세 번째 질문은 종종 첫 번째 답에 달려 있습니다. 한꺼번에 물으면 잘못된 프레이밍이 고정됩니다
- 사용자가 신중히 생각할 에너지는 유한합니다. 한 질문에 하나씩 쓰세요

**왜 추정을 붙이는가:**

- 사용자는 처음부터 답을 만들어 내는 것보다 틀린 추정에 더 빨리 반응합니다
- 눈에 보이게 틀릴 수 있는 가설에 당신을 묶습니다. 그래서 정직해집니다
- *당신의* 가정을 드러냅니다. 인터뷰가 드러내려는 것이 바로 그것입니다

여기서의 위험은 예의 바른 사용자가 맞춰 주려고 당신의 추정에 동의하는 것입니다. 틀릴 의지를 눈에 보이게 보여 완화하고, 가끔은 사용자가 되받아칠 방향이라고 예상하는 쪽으로 추정하세요.

### 3단계: "원하는 것 대 원해야 한다고 생각하는 것"을 듣기

가장 위험한 답은, 사용자가 실제로 원하는 것이 아니라 사려 깊은 답이 *어떻게 들리는지*를 말하는 경우입니다. 다음을 살펴보세요.

- 구체성 없이 모범 사례처럼 들리는 답("I want it to be scalable", "clean architecture")
- 관습에 미루는 답("the way most apps do it", "the standard approach")
- "I should probably…", "I think I'm supposed to…", "good engineering practice says…" 같은 말(아마 해야 할 것 같다, 그래야 하는 것 같다, 좋은 엔지니어링 관행이 그렇게 말한다)
- 목표가 된 유행어. "modern", "scalable", "robust"가 구체적인 결과 대신 답이 될 때

이런 말을 들으면 물을 질문은 이것입니다.

> *"누구에게도 정당화할 필요가 없다면, 실제로 무엇을 원하시나요?"*

그 질문 하나가 앞의 다섯 개보다 더 많은 일을 하는 경우가 많습니다.

### 4단계: 사용자의 말로 의도를 다시 말하기

확신도가 높으면, 지금 생각하기에 사용자가 원하는 것을 다시 적어 돌려주세요. 짧게(5-8줄) 유지하고, 가능하면 사용자의 말을 쓰며, 줄마다 확인하거나 고칠 수 있게 구조화하세요.

```
지금 생각하기에 당신이 원하는 것은 이것입니다.

- 결과: <한 줄>
- 사용자: <한 줄. 누가 이익을 얻나>
- 왜 지금: <한 줄. 무엇이 바뀌었나>
- 성공: <한 줄. 되었는지 어떻게 아나>
- 제약 조건: <한 줄. 구속력 있는 한계>
- 범위 밖: <한 줄. 명시적으로 하지 않는 것>

예 / 아니오 / 다듬기?
```

"범위 밖"을 넣는 것은 협상 대상이 아닙니다. 어긋남의 절반은, *만들지 않는* 것에 대한 조용한 불일치입니다.

### 5단계: 확인. 명시적인 예

관문은 명시적인 "예"입니다. 다음은 예가 **아닙니다**.

- "Whatever you think is best."(네가 좋다고 생각하는 대로 해.) 사용자는 위임하는 것이며, 그들도 95% 확신이 없다는 뜻입니다. 선택지로 제시한 구체적인 옵션 두 개로 다시 물어보세요.
- "Sounds good."(좋은 것 같아요.) 모호합니다. "다듬고 싶은 것이 있나요?"라고 물어보세요. 침묵은 확인이 아닙니다.
- "Sure, let's go."(그럼 가죠.) 종종 승인이 아니라 예의 바른 퇴장입니다. 같은 후속 질문을 하세요.
- 침묵 뒤에 "okay let's start."(좋아요, 시작하죠.) 사용자가 모인 것이 아니라 인터뷰를 포기한 것입니다. 멈추고, 놓친 것이 있는지 물어보세요.

사용자가 고치면 그 수정을 반영해 다시 말하세요. 명시적인 예가 나올 때까지 반복하세요.

### 6단계: 종료 턴과 중단 규칙 (중요)

사용자가 의도 진술을 명시적인 "예"로 확인하면:

1. **확인된 의도 진술을 전달하세요.**
2. **이후 경로를 제안하세요**(`docs/intent/[topic].md`에 저장할지, `spec-driven-development`로 스펙 초안을 쓸지, 스펙 다음에 작업 계획으로 넘어갈지 제안하세요).
3. **즉시 당신의 턴을 멈추세요.** 이 턴에서 도구를 호출하거나 이후 작업을 시작하지 마세요. 다음 단계를 고르도록 사용자에게 통제를 돌려주세요.

### 95% 확신에서 멈추기

다음에 예라고 답할 수 있으면 끝난 것입니다.

> *다음에 물을 세 질문에 대한 사용자의 반응을 예측할 수 있는가?*

예라면 이해가 공유된 것입니다. 인터뷰를 멈추고 다시 말하기로 넘어가세요. 아니라면 아직 끝나지 않았습니다. 다음 질문을 하세요.

이것은 감이 아니라 확인 가능한 시험입니다. 바닥도 있습니다. 여러 라운드를 지나도 예측할 수 없다면, 계속 밀어붙일 이유가 아니라 요청 자체에 대한 정보입니다. 멈추고 사용자에게 말하세요. "질문을 X개 했는데도 아직 반응을 예측할 수 없습니다. 근본적인 무언가가 빠져 있습니다. 한 걸음 물러날까요?"

## 출력

이 스킬의 출력은 **확인된 의도 진술**입니다. 4단계의 다시 말하기에, 5단계의 명시적인 예가 붙은 것입니다. 그것이 산출물입니다. 스펙, 계획, 작업 목록은 그 다음입니다. 이 스킬이 만든 의도를 받아 씁니다.

사용자가 의도를 남겨 두길 원하면(여러 세션에 걸친 프로젝트, 다른 협업자에게 넘기는 경우), `docs/intent/[topic].md`에 저장할지 제안하세요. 사용자가 확인한 경우에만 저장하세요.

## 예시

짧은 전과 후.

**`interview-me` 없이:**

```
사용자:  우리 지표용 대시보드를 만들어 주세요
에이전트: <차트 라이브러리와 레이아웃을 제안하기 시작함>
```

에이전트는 다음을 가정했습니다. 누구를 위한 것인지, 어떤 지표인지, "우리 팀용"이 무엇을 뜻하는지, 성공이 어떤 모습인지. 이 중 어느 것도 말해지지 않았습니다. 모든 가정은 나중에 사용자가 "그건 내가 말한 뜻이 아니에요"라고 할 수 있는 자리입니다.

**`interview-me`와 함께:**

```
사용자: 우리 지표용 대시보드를 만들어 주세요

에이전트:
HYPOTHESIS: 스탠드업에서 "우리 잘하고 있나?"에 답할 방법을 원하고, "대시보드"가 떠오른 것은 그것이 관습적인 답이기 때문입니다.
CONFIDENCE: ~30%. 빠짐: 누구를 위한 것인지, "지표"가 무엇인지, 성공이 어떤 모습인지

Q:     "우리 잘하고 있나?"라고 할 때 누가 묻나요? 당신 혼자인가요, 스탠드업의 엔지니어링 팀인가요, 아니면 윗선(예: 매니저, 임원, 이사회)인가요?
GUESS: 스탠드업의 엔지니어링 팀. "우리"는 보통 그 범위를 가리키고, 이 질문이 나오는 곳이 스탠드업이기 때문입니다. 임원용이면 지표와 프레이밍이 크게 바뀝니다.

사용자: 사실 나를 위한 거예요. 어떤 실험이 진행 중인지, 초기 신호가 어떤지 자꾸 놓칩니다.

에이전트:
갱신된 파악: 팀 대시보드가 전혀 아닙니다. 개인용 실험 추적기입니다. 확신도: ~60%. 아직 빠짐: "초기 신호"가 무엇을 뜻하는지, 완료가 어떤 모습인지.

Q:     간극은 어떤 실험이 있는지 모르는 것인가요, 아니면 결과를 한곳에서 볼 수 없는 것인가요?
GUESS: 두 번째입니다. 실험 목록은 어딘가에 있지만, 결과는 서로 다른 도구 다섯 곳에 있고, 손으로 맞추는 일에 지친 것입니다.

사용자: 사실 첫 번째예요. 목록 자체가 없습니다. 여러 문서에 흩어져 있어요.

에이전트: <계속>
```

질문 두 개 만에 에이전트는 실제 요청이 "대시보드"가 아님을 발견했습니다. "목록"입니다. 아티팩트도 다르고, 범위도 다르고, 일도 다릅니다. 대시보드는 틀린 답이 되었을 것입니다.

## 다른 스킬과의 관계

- **`idea-refine`**: 이후 단계입니다. 확인된 의도가 "X는 원하는데 범위를 어떻게 잡을지 모르겠다"이면, 이제 명시된 의도에 맞춰 변형을 만들도록 `idea-refine`에 넘기세요.
- **`spec-driven-development`**: 이후 단계입니다. 확인된 의도가 구체적이면("Y 사용자를 위한 X를, Z라는 성공 기준으로 원한다"), 그것을 적도록 `spec-driven-development`에 넘기세요.
- **`planning-and-task-breakdown`**: 이 스킬에서 두 단계 뒤입니다(스펙 다음).
- **`doubt-driven-development`**: 시간선의 반대편입니다. Interview-me는 결정 전의 의도 추출이고, doubt-driven은 결정 후의 아티팩트 리뷰입니다. 둘 다 어긋남을 잡지만, 시점이 다릅니다.
- **`source-driven-development`**: 직교합니다. Interview-me는 사용자가 원하는 것을 명확히 하고, SDD는 프레임워크에 대한 사실을 검증합니다. 둘은 경쟁하지 않습니다.

## 흔한 합리화

| 합리화 | 현실 |
|---|---|
| "요청은 충분히 명확하다" | 사용자가 원하는 결과를 지금 당장 한 문장으로 쓸 수 없다면, 요청은 명확하지 않습니다. 결정하기 전에 1단계를 실행하세요. |
| "질문을 너무 많이 하면 시간을 낭비한다" | 표적을 맞춘 질문 4-6개에 쓰는 시간은 작습니다. 잘못된 것을 만들어서 쓰는 시간은 막대하고, 그 비용을 지는 쪽은 사용자입니다. |
| "만들면서 알아내면 된다" | 코드가 생긴 뒤의 전환 비용은 지금의 10배입니다. 구현 중에 발견하는 것은 재작업입니다. |
| "'네가 알아서 해'라고 했으니 그냥 결정해야 한다" | "Whatever you think"는 결정이 아니라 위임입니다. 구체적인 옵션 두 개를 선택지로 다시 물어보세요. |
| "고를 수 있게 여러 옵션을 줘야 한다" | 옵션은 사용자가 원하는 것을 알고 트레이드오프 사이에서 고를 때 작동합니다. 그들은 아직 원하는 것을 모릅니다. 옵션을 나열하면 탐색이 넓어지고, 질문은 탐색을 좁힙니다. |
| "추정을 붙이면 사용자를 유도하는 것이다" | 유도하는 것이 핵심입니다. 반응은 처음부터 만들어 내는 것보다 빠릅니다. 위험은 유도가 아니라 아부입니다. 틀릴 의지를 눈에 보이게 보여 완화하세요. |
| "충분히 이야기했으니 알겠다" | 시험해 보세요. 다음 세 질문에 대한 반응을 예측할 수 있나요? 아니라면 아직 이해한 것이 아닙니다. |
| "사용자가 예라고 했으니 끝이다" | 그 예가 막연한 다시 말하기나, 열린 "sounds good" 뒤에 나왔다면 그 예는 비어 있습니다. 구체적으로 다시 말하고 다시 확인하세요. |

## 레드 플래그

- 한 메시지에 질문이 세 개 이상: 인터뷰가 아니라 묶어서 묻는 것입니다
- 가설이 붙지 않은 질문: 가설에 자신을 묶지 않는 설문입니다
- "Whatever you think is best"를 최종 답으로 받아들임
- 사용자가 다시 말하기를 명시적으로 확인하기 전에 스펙, 계획, 작업 목록을 만듦
- 의도 확인을 받자마자 턴을 멈추지 않고 도구를 호출하거나 이후 작업을 시작함
- "실제로 무엇을 원하시나요?" 대신 "모범 사례는 무엇인가요?"로 프레임된 질문
- 사용자가 전문적으로 보이게 하려는 답("scalable", "clean", "modern")을 주는데, 그것이 실제로 원하는 것인지 캐묻지 않고 받아들임
- 세 라운드 이상인데 확신도가 눈에 보이게 오르지 않음: 잘못된 질문을 하고 있습니다. 한 걸음 물러나 다시 프레임하세요
- 약 70% 아래의 확신도 숫자에 이유가 없음: 무엇이 빠졌는지 모르면 사용자가 간극을 닫도록 도울 수 없습니다
- 사용자가 확인하기 전에 의도 문서를 저장함(문서 자체가, 사용자가 주지 않은 예를 암시합니다)
- 다시 말하기에서 "범위 밖" 줄을 빼먹음(비목표에 대한 조용한 불일치가 어긋남의 절반입니다)

## 검증

interview-me를 적용한 뒤:

- [ ] 첫 턴에 확신도 숫자가 붙은 명시적 가설을 말했다
- [ ] 약 70% 아래의 확신도 숫자마다 한 줄 이유가 붙었다(아직 해결되지 않았거나 빠진 것)
- [ ] 질문을 한 번에 하나씩 물었고, 각각에 에이전트의 추정이 붙었다
- [ ] 사용자가 전문적으로 보이게 하려는 답이나 관습을 내세우는 답을 했을 때, "정당화할 필요가 없다면 실제로 무엇을 원하시나요?" 탐침을 최소 한 번 했다
- [ ] 구체적인 다시 말하기(결과 / 사용자 / 왜 지금 / 성공 / 제약 조건 / 범위 밖)를 사용자에게 다시 적었다
- [ ] 사용자가 다시 말하기를 명시적인 예로 확인했다("whatever you think"도, "sounds good"도, 침묵도 아니다)
- [ ] 중단 시점에, 에이전트가 다음에 물을 세 질문에 대한 반응을 예측할 수 있었다
- [ ] 명시적 확인을 받은 즉시, 도구를 호출하거나 이후 작업을 시작하지 않고 턴을 멈췄다
- [ ] 이후 스킬(`idea-refine`, `spec-driven-development`)로의 인계는 원래의 덜 명세된 요청이 아니라, 확인된 의도를 기준으로 프레임되었다