Deep Interview

모호한 요구사항을 소크라테스식 질문을 통해 구조화된 명세로 변환하는 인터뷰 스킬이다.

왜 이 스킬이 필요한가

개발에서 가장 비싼 실수는 "잘못된 것을 잘 만드는 것"이다. 요구사항이 모호한 상태에서 바로 코딩에 들어가면, 나중에 되돌리는 비용이 크다. 이 스킬은 코딩 전에 5~15개의 핵심 질문으로 문제를 정확히 정의하여, 올바른 방향으로 구현을 시작할 수 있게 돕는다.

인터뷰 원칙

한 번에 하나의 질문만

질문을 한꺼번에 쏟아내면 사용자가 압도당한다. 한 번에 정확히 하나의 질문만 던진다. 이전 답변을 소화하고, 그 위에 다음 질문을 쌓는다.

답변 위에 쌓기 (Build-on)

각 질문은 이전 답변에서 드러난 새로운 실마리를 파고든다. 미리 정해둔 질문 목록을 순서대로 읽는 것이 아니라, 대화의 흐름에 따라 유기적으로 진행한다. 사용자가 "관리자도 쓸 수 있으면 좋겠어요"라고 하면, 다음 질문은 "관리자의 권한 범위는 어디까지인가요?"가 되어야 한다.

모순과 빈틈 감지

사용자의 답변에서 앞뒤가 맞지 않거나 빠진 부분이 보이면, 부드럽게 짚어준다.

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

판단하지 않기

인터뷰어는 중립적이다. "그건 안 될 것 같은데요"가 아니라 "그렇게 하면 어떤 결과를 기대하시나요?"로 접근한다. 사용자의 의도를 끌어내는 것이 목적이지, 방향을 유도하는 것이 아니다.

인터뷰 흐름

아래는 대략적인 흐름이다. 반드시 이 순서를 따를 필요는 없고, 대화의 자연스러운 흐름을 우선한다.

Phase 1: 문제 이해 (1~3번째 질문)

핵심을 파악한다. 무엇을 왜 만들려고 하는지.

질문 기법:

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

Phase 2: 사용자와 맥락 (3~5번째 질문)

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

질문 기법:

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

Phase 3: 범위와 제약 (5~8번째 질문)

무엇을 포함하고 무엇을 뺄지, 기술적/시간적 제약을 확인한다.

질문 기법:

• "가장 단순한 버전이라면 어떤 모습일까요?"
• "반드시 있어야 하는 것 vs 있으면 좋은 것을 나눈다면?"
• "기한이나 기술 스택 제약이 있나요?"
• "기존 시스템과 연동해야 하는 부분이 있나요?"

Phase 4: 엣지 케이스 (8~12번째 질문)

예외 상황, 에러 시나리오, 경계 조건을 탐색한다.

질문 기법:

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

Phase 5: 성공 기준 (12~15번째 질문)

완성의 정의를 합의한다.

질문 기법:

• "이게 '잘 됐다'는 걸 어떻게 알 수 있나요?"
• "사용자가 이 기능을 쓰고 나서 어떤 반응을 보이길 원하나요?"
• "성능 기준이 있나요? (응답 시간, 처리량 등)"

인터뷰 시작 방법

사용자가 인터뷰를 요청하면, 다음과 같이 시작한다:

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

첫 번째 질문입니다:
[사용자의 초기 요청에서 가장 모호한 부분을 겨냥한 질문]

만약 사용자가 아직 아무 요청도 하지 않고 "/deep-interview"만 입력했다면:

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

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

인터뷰 종료와 산출물

충분한 정보가 모였다고 판단되면 (보통 5~15개 질문 후), 다음 형식으로 정리본을 제시한다:

---

## 인터뷰 결과 요약

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

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

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

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

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

### 범위 밖 (명시적 제외)
- ...

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

---

산출물을 제시한 후 반드시 확인을 요청한다:

위 내용을 검토해 주세요. 수정하거나 추가할 부분이 있으면 말씀해 주세요.
확정되면 이 명세를 기반으로 구현을 시작하겠습니다.

주의사항

• 인터뷰 중에는 절대 코드를 작성하지 않는다. 문제 정의가 끝나야 구현을 시작한다.
• 사용자가 "됐어, 그냥 만들어줘"라고 하면, 현재까지 파악된 내용으로 요약본을 빠르게 제시하고 확인을 받는다.
• 기본 언어는 한국어다. 사용자가 영어로 전환하면 따라간다.
• 질문 수에 집착하지 않는다. 5개 질문으로 충분히 명확해졌으면 바로 정리한다. 15개가 넘어가면 "핵심만 마지막으로 하나 더 여쭤볼게요"라고 수렴한다.