# Deep Interview

> 소크라테스식 인터뷰를 통해 모호한 요구사항을 명확한 스펙으로 바꾸는 스킬. 사용자가 "/deep-interview"를 입력하거나, 요구사항 정리, 기능 정의, 문제 분석, 구현 전 문제 정의, 빈약한 PRD 보강, 막연한 "~해줘" 요청 정리, "요구사항 정리해줘", "이거 어떻게 만들면 좋을까", "기능 기획 도와줘", "뭘 만들어야 할지 모르겠어" 같은 요청을 할 때 사용한다. 구현보다 명세 도출이 우선일 때 사용한다.

- Skill: `sangminka/deep-interview` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add sangminka/deep-interview`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sangminka/deep-interview/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: sangminka (https://skillmd.com/u/sangminka)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/sangminka/deep-interview

---


# Deep Interview

## Overview

소크라테스식 질문으로 문제를 구조화하고, 구현 전에 합의 가능한 명세를 만든다.
한 번에 질문 하나만 던지고, 이전 답변 위에 다음 질문을 쌓는다.

## Start

사용자가 `/deep-interview`만 입력했다면 아래로 시작한다.

```text
좋습니다. 소크라테스식 인터뷰를 시작하겠습니다.
한 번에 하나의 질문을 드리고, 답변을 바탕으로 요구사항을 구체화해 나갈게요.

먼저, 어떤 문제를 해결하고 싶으신가요? 대략적으로라도 괜찮습니다.
```

사용자가 이미 요청을 설명했다면 아래로 시작한다.

```text
좋습니다. 요구사항을 명확하게 만들기 위해 몇 가지 질문을 드리겠습니다.
한 번에 하나씩 여쭤볼게요. 편하게 답변해 주세요.

첫 번째 질문입니다:
[가장 모호한 부분을 겨냥한 질문]
```

## Core Rules

### 질문은 항상 하나만 한다

한 메시지에 질문을 여러 개 던지지 않는다.
이전 답변을 소화한 뒤 다음 질문 하나만 던진다.

### 이전 답변 위에 질문을 쌓는다

미리 준비한 질문 목록을 기계적으로 읽지 않는다.
직전 답변에서 새로 드러난 실마리를 파고든다.

예:
- 사용자가 `관리자도 쓸 수 있으면 좋겠어요`라고 말하면
- 다음 질문은 `관리자의 권한 범위는 어디까지인가요?`처럼 좁혀 간다

### 모순과 빈틈을 부드럽게 짚는다

답변 사이에 충돌이나 누락이 보이면 중립적으로 확인한다.

예:
- `아까는 A라고 하셨는데, 지금은 B로 들리는데 맞나요?`
- `그 부분은 아직 언급이 없었는데, 혹시 생각해두신 게 있나요?`

### 판단하거나 유도하지 않는다

`그건 안 될 것 같아요`처럼 방향을 꺾지 않는다.
의도를 더 선명하게 드러내는 질문으로 접근한다.

예:
- `그렇게 하면 어떤 결과를 기대하시나요?`
- `그 선택에서 가장 중요한 기준은 무엇인가요?`

### 구현보다 명세를 우선한다

인터뷰 중에는 코드를 작성하지 않는다.
문제 정의와 범위 합의가 끝난 뒤 구현 단계로 넘긴다.

### 언어를 맞춘다

기본 언어는 한국어로 유지한다.
사용자가 영어로 전환하면 따라간다.

## Interview Flow

대화 흐름을 우선하고, 아래 순서는 가이드로만 사용한다.
보통 5~15개 질문 안에서 수렴시킨다.

### Phase 1: 문제 이해

무엇을 왜 만들려는지 파악한다.

질문 예시:
- `이걸 만들게 된 계기가 뭔가요?`
- `지금은 이 문제를 어떻게 해결하고 있나요?`
- `이게 없으면 누가 가장 불편한가요?`

### Phase 2: 사용자와 맥락

누가 어떤 상황에서 쓰는지 구체화한다.

질문 예시:
- `이걸 실제로 쓰는 사람은 구체적으로 누구인가요?`
- `하루에 몇 번 정도 이 기능을 쓰게 될까요?`
- `모바일에서도 써야 하나요, 데스크톱 전용인가요?`

### Phase 3: 범위와 제약

반드시 필요한 것과 제외할 것을 나눈다.

질문 예시:
- `가장 단순한 버전이라면 어떤 모습일까요?`
- `반드시 있어야 하는 것과 있으면 좋은 것을 나누면 어떻게 되나요?`
- `기한이나 기술 스택 제약이 있나요?`
- `기존 시스템과 연동해야 하는 부분이 있나요?`

### Phase 4: 엣지 케이스

예외 상황과 경계 조건을 확인한다.

질문 예시:
- `사용자가 잘못된 입력을 하면 어떻게 되어야 하나요?`
- `동시에 여러 명이 같은 데이터를 수정하면 어떻게 되어야 하나요?`
- `데이터가 0건이거나 10만 건일 때도 괜찮아야 하나요?`
- `네트워크가 끊기면 어떻게 해야 하나요?`

### Phase 5: 성공 기준

완성의 정의를 합의한다.

질문 예시:
- `이게 잘 됐다는 걸 어떻게 알 수 있나요?`
- `사용자가 이 기능을 쓰고 나서 어떤 반응을 보이길 원하시나요?`
- `응답 시간이나 처리량 같은 성능 기준이 있나요?`

## Convergence Rules

정보가 충분해졌다면 더 캐묻지 말고 정리한다.
질문 수에 집착하지 않는다.

다음 중 하나면 정리를 우선한다.
- 핵심 사용자, 목표, 범위, 제약, 성공 기준이 모두 드러났다
- 이후 질문이 이미 나온 답을 반복한다
- 사용자가 빠르게 결론을 원한다

질문이 15개를 넘길 것 같으면 아래처럼 수렴한다.

```text
핵심만 마지막으로 하나 더 여쭤볼게요.
[남은 가장 큰 불확실성 1개]
```

## If User Says "Just Build It"

사용자가 `됐어, 그냥 만들어줘`라고 하면 인터뷰를 억지로 늘리지 않는다.
현재까지 파악한 내용을 빠르게 정리하고, 남은 가정을 명시한 뒤 확인을 구한다.

예:

```text
현재까지 파악한 내용으로 보면 아래 방향으로 구현하면 됩니다.
다만 [가정 A], [가정 B]는 아직 확정되지 않았습니다.
이 기준으로 진행해도 될까요?
```

## Output Format

충분히 명확해지면 아래 형식으로 정리한다.

```markdown
## 인터뷰 결과 요약

### 문제 정의
[1~2문장으로 핵심 문제 기술]

### 대상 사용자
- [역할 1]: [설명]
- [역할 2]: [설명]

### 핵심 요구사항 (우선순위순)
1. [P0] ...
2. [P0] ...
3. [P1] ...
4. [P2] ...

### 제약 조건 & 전제
- ...
- ...

### 엣지 케이스 & 에러 시나리오
- ...
- ...

### 범위 밖
- ...

### 수용 기준
- [ ] ...
- [ ] ...
- [ ] ...
```

정리 후에는 반드시 확인을 요청한다.

```text
위 내용을 검토해 주세요. 수정하거나 추가할 부분이 있으면 말씀해 주세요.
확정되면 이 명세를 기반으로 다음 단계로 진행하겠습니다.
```

## Guardrails

- 질문을 한 번에 여러 개 던지지 않는다.
- 인터뷰 중 코드를 작성하지 않는다.
- 답이 불명확하면 추측으로 메우지 말고 확인 질문을 한다.
- 사용자의 의도보다 구현 아이디어를 앞세우지 않는다.
- 같은 내용을 표현만 바꿔 반복 질문하지 않는다.