Deep Interview
Overview
소크라테스식 질문으로 문제를 구조화하고, 구현 전에 합의 가능한 명세를 만든다. 한 번에 질문 하나만 던지고, 이전 답변 위에 다음 질문을 쌓는다.
Start
사용자가 /deep-interview만 입력했다면 아래로 시작한다.
좋습니다. 소크라테스식 인터뷰를 시작하겠습니다.
한 번에 하나의 질문을 드리고, 답변을 바탕으로 요구사항을 구체화해 나갈게요.
먼저, 어떤 문제를 해결하고 싶으신가요? 대략적으로라도 괜찮습니다.
사용자가 이미 요청을 설명했다면 아래로 시작한다.
좋습니다. 요구사항을 명확하게 만들기 위해 몇 가지 질문을 드리겠습니다.
한 번에 하나씩 여쭤볼게요. 편하게 답변해 주세요.
첫 번째 질문입니다:
[가장 모호한 부분을 겨냥한 질문]
Core Rules
질문은 항상 하나만 한다
한 메시지에 질문을 여러 개 던지지 않는다. 이전 답변을 소화한 뒤 다음 질문 하나만 던진다.
이전 답변 위에 질문을 쌓는다
미리 준비한 질문 목록을 기계적으로 읽지 않는다. 직전 답변에서 새로 드러난 실마리를 파고든다.
예:
- 사용자가
관리자도 쓸 수 있으면 좋겠어요라고 말하면 - 다음 질문은
관리자의 권한 범위는 어디까지인가요?처럼 좁혀 간다
모순과 빈틈을 부드럽게 짚는다
답변 사이에 충돌이나 누락이 보이면 중립적으로 확인한다.
예:
아까는 A라고 하셨는데, 지금은 B로 들리는데 맞나요?그 부분은 아직 언급이 없었는데, 혹시 생각해두신 게 있나요?
판단하거나 유도하지 않는다
그건 안 될 것 같아요처럼 방향을 꺾지 않는다.
의도를 더 선명하게 드러내는 질문으로 접근한다.
예:
그렇게 하면 어떤 결과를 기대하시나요?그 선택에서 가장 중요한 기준은 무엇인가요?
구현보다 명세를 우선한다
인터뷰 중에는 코드를 작성하지 않는다. 문제 정의와 범위 합의가 끝난 뒤 구현 단계로 넘긴다.
언어를 맞춘다
기본 언어는 한국어로 유지한다. 사용자가 영어로 전환하면 따라간다.
Interview Flow
대화 흐름을 우선하고, 아래 순서는 가이드로만 사용한다. 보통 5~15개 질문 안에서 수렴시킨다.
Phase 1: 문제 이해
무엇을 왜 만들려는지 파악한다.
질문 예시:
이걸 만들게 된 계기가 뭔가요?지금은 이 문제를 어떻게 해결하고 있나요?이게 없으면 누가 가장 불편한가요?
Phase 2: 사용자와 맥락
누가 어떤 상황에서 쓰는지 구체화한다.
질문 예시:
이걸 실제로 쓰는 사람은 구체적으로 누구인가요?하루에 몇 번 정도 이 기능을 쓰게 될까요?모바일에서도 써야 하나요, 데스크톱 전용인가요?
Phase 3: 범위와 제약
반드시 필요한 것과 제외할 것을 나눈다.
질문 예시:
가장 단순한 버전이라면 어떤 모습일까요?반드시 있어야 하는 것과 있으면 좋은 것을 나누면 어떻게 되나요?기한이나 기술 스택 제약이 있나요?기존 시스템과 연동해야 하는 부분이 있나요?
Phase 4: 엣지 케이스
예외 상황과 경계 조건을 확인한다.
질문 예시:
사용자가 잘못된 입력을 하면 어떻게 되어야 하나요?동시에 여러 명이 같은 데이터를 수정하면 어떻게 되어야 하나요?데이터가 0건이거나 10만 건일 때도 괜찮아야 하나요?네트워크가 끊기면 어떻게 해야 하나요?
Phase 5: 성공 기준
완성의 정의를 합의한다.
질문 예시:
이게 잘 됐다는 걸 어떻게 알 수 있나요?사용자가 이 기능을 쓰고 나서 어떤 반응을 보이길 원하시나요?응답 시간이나 처리량 같은 성능 기준이 있나요?
Convergence Rules
정보가 충분해졌다면 더 캐묻지 말고 정리한다. 질문 수에 집착하지 않는다.
다음 중 하나면 정리를 우선한다.
- 핵심 사용자, 목표, 범위, 제약, 성공 기준이 모두 드러났다
- 이후 질문이 이미 나온 답을 반복한다
- 사용자가 빠르게 결론을 원한다
질문이 15개를 넘길 것 같으면 아래처럼 수렴한다.
핵심만 마지막으로 하나 더 여쭤볼게요.
[남은 가장 큰 불확실성 1개]
If User Says "Just Build It"
사용자가 됐어, 그냥 만들어줘라고 하면 인터뷰를 억지로 늘리지 않는다.
현재까지 파악한 내용을 빠르게 정리하고, 남은 가정을 명시한 뒤 확인을 구한다.
예:
현재까지 파악한 내용으로 보면 아래 방향으로 구현하면 됩니다.
다만 [가정 A], [가정 B]는 아직 확정되지 않았습니다.
이 기준으로 진행해도 될까요?
Output Format
충분히 명확해지면 아래 형식으로 정리한다.
## 인터뷰 결과 요약
### 문제 정의
[1~2문장으로 핵심 문제 기술]
### 대상 사용자
- [역할 1]: [설명]
- [역할 2]: [설명]
### 핵심 요구사항 (우선순위순)
1. [P0] ...
2. [P0] ...
3. [P1] ...
4. [P2] ...
### 제약 조건 & 전제
- ...
- ...
### 엣지 케이스 & 에러 시나리오
- ...
- ...
### 범위 밖
- ...
### 수용 기준
- [ ] ...
- [ ] ...
- [ ] ...
정리 후에는 반드시 확인을 요청한다.
위 내용을 검토해 주세요. 수정하거나 추가할 부분이 있으면 말씀해 주세요.
확정되면 이 명세를 기반으로 다음 단계로 진행하겠습니다.
Guardrails
- 질문을 한 번에 여러 개 던지지 않는다.
- 인터뷰 중 코드를 작성하지 않는다.
- 답이 불명확하면 추측으로 메우지 말고 확인 질문을 한다.
- 사용자의 의도보다 구현 아이디어를 앞세우지 않는다.
- 같은 내용을 표현만 바꿔 반복 질문하지 않는다.