onejaejae/spec-interview

Spec Interview

기획팀용 역질문 인터뷰. 비구조화된 아이디어를 비즈니스 언어로 질문하여 구조화된 요구사항 문서로 정리한다.

When to Use

• 기획팀이 기능 아이디어를 구조화하고 싶을 때
• 회의록/구두 설명을 요구사항 문서로 변환하고 싶을 때
• 개발 전 요구사항을 명확히 하고 싶을 때 (비개발자 대상)
• User says "기획 인터뷰", "요구사항 정리해줘", "기능 정리해줘", "spec interview"

Do NOT use when:

• 이미 구조화된 기획서가 있고, 리뷰만 필요한 경우 → spec-reviewer 사용
• 개발자가 기술 스펙을 정리하고 싶은 경우 → interview Skill 사용
• 요구사항이 이미 명확하고 기획서 문서만 생성하면 되는 경우 → spec-generator 사용

CRITICAL: AskUserQuestion 턴 분리 규칙

AskUserQuestion은 이 스킬이 로드된 턴(같은 assistant turn)에서 절대 호출하지 마세요.

Skill tool로 이 스킬이 로드되면, 같은 턴에서 AskUserQuestion을 호출할 경우 사용자에게 질문 UI가 표시되지 않고 빈 응답으로 자동 처리됩니다 (Claude Code 플랫폼 제약).

필수 절차:

1. Phase 1 (도메인 컨텍스트 파악)을 수행한다
2. 스캔 결과와 소요 시간 안내를 텍스트로 출력한다
3. 반드시 STOP하고 사용자 응답을 기다린다
4. 사용자가 응답한 다음 턴에서 AskUserQuestion을 사용하여 Phase 2를 시작한다

이 규칙을 어기면 사용자가 질문을 볼 수 없고, 인터뷰가 진행되지 않습니다.

Quick Reference

| Phase | Action | Key Rule | |-------|--------|----------| | 1. 도메인 컨텍스트 파악 | specs/ 스캔 + input 분석 + 주제 분류 | 도메인 문서 스캔. 코드 스캔 아님 | | 2. 스토리 기반 탐색 (OPEN) | 개방형 질문으로 맥락과 문제 파악 | 넓게 시작, 프레이밍 금지 | | 3. 시나리오 구체화 (PROBE) | 정상흐름 → 예외 도출 → 상태 발견 | 구체 예시로 모호성 제거 | | 4. 빈틈 채우기 (FOCUS) | 누락 항목 기반 타겟 질문 | 빠진 차원만 선별 | | 5. 범위 확정 + 완료 검증 | 범위/성공기준 확정 | 완료 기준 충족 시에만 종료 | | 6. 요구사항 출력 | specs/{feature}-requirements.md | 항상 이 경로 |

핵심 원칙

1. 비기술 언어만 사용한다. 기획팀이 주 사용자이다. 기술 용어를 절대 쓰지 않는다.

| 기술 용어 (사용 금지) | 비즈니스 질문 (이렇게 질문) | |---|---| | 상태 전이 다이어그램 | "이 데이터가 어떤 단계를 거치나요?" | | 소프트 삭제 / 하드 삭제 | "삭제하면 완전히 사라지나요, 복구할 수 있나요?" | | 페이지네이션 | "목록이 길면 어떻게 나누나요?" | | API 계약 | "이 기능이 다른 시스템과 주고받는 정보는?" | | 인가/인증 | "누가 이걸 쓸 수 있고, 누가 못 쓰나요?" | | 비기능 요구사항 | "동시에 몇 명이 쓸 수 있어야 하나요?" | | 데이터 모델 | "어떤 정보를 저장하고 보여줘야 하나요?" |

2. 개방형 → 탐침 → 구체적 순서로 질문한다 (Funnel). 구체적 질문으로 시작하면 응답자를 프레이밍에 가둔다. 반드시 넓게 열고 좁혀간다.

3. 가상이 아닌 실제 경험을 묻는다. "~하면 어떨 것 같아요?"는 신뢰할 수 없다. "마지막으로 ~했을 때 어떻게 하셨나요?"로 실제 경험에서 요구사항을 추출한다.

Protocol

Phase 1: 도메인 컨텍스트 파악

기존 interview Skill과 다르게, 코드를 스캔하지 않는다. 대신:

1. specs/ 폴더를 Glob/Read로 스캔하여 관련 기존 요구사항/기획서 확인
2. 사용자가 제공한 input (텍스트, 파일 경로) 분석
3. 주제를 카테고리로 분류하고, 카테고리에 따라 Phase 3-4 질문 우선순위를 조정한다:
   • 신규 기능 → Phase 3: 시나리오·예외·상태에 집중. Phase 4: #5 데이터 제약, #6 권한 우선 확인
   • 기능 개선 → Phase 2: 현재 동작과 불편함 먼저 파악. Phase 3: 변경 전후 차이와 영향 범위 집중. Phase 4: #1 암묵적 지식 우선 (기존 규칙 중 바뀌는 것)
   • 정책/프로세스 변경 → Phase 3: 규칙·조건·예외에 집중. Phase 4: #9 범위 경계 우선 (정책 변경의 적용 범위)
   • 마이그레이션/전환 → Phase 2: 이전 시스템과의 차이 먼저 파악. Phase 3: 전환 기간·병행 운영·데이터 이관 집중. Phase 4: #7 연동 우선 (구/신 시스템 공존 시나리오)

기존 specs/에 관련 문서가 없으면 빠르게 넘기고 Phase 2로 진행한다.

4. 소요 시간 안내: Phase 2 시작 전에 사용자에게 예상 소요를 알린다: "약 5-10분 정도 걸리고, 3-5라운드의 질문을 드립니다."

Phase 2: 스토리 기반 탐색 (OPEN — 넓게)

AskUserQuestion으로 2-3개 질문/라운드. 반드시 개방형으로 시작한다.

질문 구조 (순서대로):

1. 스토리 개방: 현재 상황과 맥락을 파악한다.

   • "현재 이 업무를 어떻게 처리하고 계세요?"
   • "마지막으로 이 상황이 발생했을 때를 말씀해주세요"
   • "이 기능이 필요하게 된 계기가 뭔가요?"

2. 스토리 발굴: 답변을 파고든다.

   • "그 다음엔 어떻게 했나요?"
   • "왜 그런 방식으로 했나요?"
   • "그때 뭘 보고 판단했나요?"

3. 문제 탐색: 핵심 문제를 찾는다.

   • "어떤 부분이 가장 번거로운가요?"
   • "그 문제가 발생하면 다른 일에도 영향을 주나요?"

4. 가치 확인: 해결의 가치를 확인한다.

   • "그 부분이 해결되면 무엇이 가능해지나요?"

라운드 조절:

• 명확한 요구사항 (사용자가 흐름까지 설명함): 1라운드 → Phase 3로 이동
• 방향은 있지만 흐름 미정 (목표만 언급, 구체 프로세스 없음): 2라운드
• 모호한 아이디어 (초기 구상, "~같은 거 하고 싶어요" 수준): 2-3라운드

금지 사항:

• "~기능이 필요하신가요?" → Feature Fishing. 해답을 제시하며 질문하지 않는다.
• "~하면 좋지 않을까요?" → Leading Question. 동의를 유도하지 않는다.
• "만약 ~하면 어떠실 것 같아요?" → 가상적 질문. 사람은 가상 행동을 예측 못한다.

Phase 3: 시나리오 구체화 (PROBE — 파고들기)

Phase 2에서 파악한 맥락을 기반으로 구체적 시나리오를 정의한다. AskUserQuestion 2-3개/라운드.

Step 1 — 정상 흐름 정의:

• "사용자가 이 기능을 처음부터 끝까지 사용하는 순서를 알려주세요"
• "각 단계에서 사용자가 보는 화면과 하는 행동은?"

Step 2 — 예외 도출: 정상 흐름의 각 단계를 변형하여 예외를 끌어낸다:

• "방금 말씀하신 [X 단계]에서 실패하면 어떻게 되나요?"
• "[데이터]가 없는 경우에는? 중복인 경우에는?"
• "두 사람이 동시에 이걸 하면?"
• "새로 온 사람이 이 과정에서 가장 자주 실수하는 건 뭔가요?"
• "이 규칙의 예외가 있나요? 예외를 누가 판단하나요?"

Step 3 — 상태 발견 (파이프라인 역할: 상태를 발견한다. 구조화는 spec-generator, 완전성 검증은 spec-reviewer가 담당): 데이터의 생명주기를 질문하여 상태 전이를 발견한다:

• "이 데이터의 일생을 말씀해주세요. 만들어져서 없어질 때까지 어떤 단계를 거치나요?"
• "각 단계로 넘어가는 조건은? 자동인가요, 누군가가 결정하나요?"
• "뒤로 돌아갈 수 있나요? 어떤 경우에?"
• "각 단계가 바뀔 때 자동으로 일어나야 하는 일이 있나요? (알림, 연동 등)"
• "시간 제한이 있는 단계가 있나요? 기한이 지나면 어떻게 되나요?"

라운드 조절: 정상 흐름이 단순하면 1라운드, 복잡하면 2-3라운드.

Phase 4: 빈틈 채우기 (FOCUS — 좁히기)

Phase 2-3에서 자연스럽게 커버된 항목은 건너뛴다. 빠진 차원만 선별하여 질문한다.

10개 누락 항목 체크리스트:

| # | 항목 | 질문 예시 | 건너뛰는 조건 | |---|------|----------|-------------| | 1 | 암묵적 지식 | "앞서 말씀하신 [구체 프로세스]에서, 당연해서 따로 말 안 한 규칙이 있나요? 예: 순서 제약, 금액 한도, 시간 제한 등" | Phase 2에서 프로세스가 충분히 설명됨 | | 2 | 에러/실패 | "잘못될 수 있는 3가지는?" | Phase 3 Step 2에서 예외가 충분히 나옴 | | 3 | 상태 전이 | "[A상태]에서 [B이벤트] 발생 시?" | Phase 3 Step 3에서 상태가 명확히 정의됨 | | 4 | 비기능 요구 | "동시 사용자 수? 반응 속도? 개인정보?" | 항상 질문 (자연스럽게 안 나오는 영역) | | 5 | 데이터 제약 | "수정/삭제 가능? 최대 길이?" | Phase 3에서 데이터가 상세히 논의됨 | | 6 | 권한 | "누가 쓸 수 있고, 못 쓰나요?" | Phase 3에서 역할이 명확히 나옴 | | 7 | 연동 | "다른 시스템과 연결? 그 시스템 안 되면?" | Phase 2에서 연동이 이미 논의됨 | | 8 | 목록 동작 | "비어있으면? 수천 개면? 정렬/검색?" | 목록 UI가 없는 기능이면 건너뜀 | | 9 | 입력 유효성 | "잘못 입력하면 바로 알려주나요?" | 입력 폼이 없는 기능이면 건너뜀 | | 10 | 범위 경계 | "이번에 안 하는 것 5가지는?" | Phase 5에서 반드시 커버 |

질문 방식: 빠진 항목을 AskUserQuestion 2-3개로 묶어서 한 번에 질문한다.

주의: #4 비기능 요구는 반드시 질문한다. 동시 사용자 수, 반응 속도, 개인정보 여부는 인터뷰에서 자연스럽게 나오지 않는 영역이다. Phase 2-3에서 이미 나왔더라도 구체적 수치가 없으면 다시 확인한다.

미결 사항 상한: "모르겠어요" / "아직 안 정해졌어요"가 5개를 초과하면, 추가 질문을 중단하고 Phase 5로 즉시 이동한다. 더 물어도 답이 나오지 않는 상태이므로, 현재까지의 정보로 요구사항을 정리하는 것이 효과적이다.

Phase 5: 범위 확정 + 완료 검증

범위 확정 (반드시 질문):

• "이번에 반드시 해야 하는 것과, 안 해도 되는 것을 구분해주세요"
• "이게 되면 완성이라고 할 수 있는 건 뭔가요?"

마감 질문 (반드시 질문):

• "제가 못 물어본 것 중 중요한 게 있을까요?"

완료 판정 기준 — End ONLY when ALL are true:

• 핵심 시나리오 (정상 흐름 + 주요 예외)가 구체적으로 정의됨
• 상태 변화가 식별됨 (해당하는 경우)
• 권한과 범위가 명시됨
• 사용자가 "더 없다"고 확인함

완료 신호 판별:

| 신호 | 판정 | |------|------| | 같은 답변이 반복됨 | 충분 — 해당 차원 종료 | | 핵심 5개 차원 (시나리오, 예외, 상태, 권한, 범위) 커버 | 완료 가능 | | "아직 안 정해졌어요"가 3개 이상 | 미결 사항으로 기록하고 계속 | | 새 카테고리가 계속 나옴 | 부족 — 더 탐색 | | 마감 질문에 "없어요" | 완료 |

Don't stop early — "충분히 이해한 것 같다"는 완료 기준이 아니다. Don't drag on — 명확한 기능은 2-3라운드면 충분하다.

Phase 6: 요구사항 출력

Write to specs/{feature-slug}-requirements.md. Always this path.

slug 규칙: 영문 소문자, 하이픈 구분. 예: user-like, payment-migration, notification-settings

# {기능명} — 요구사항

## 배경
왜 이 기능이 필요한가. 현재 어떤 문제가 있는가.

## 사용자와 목표
누가 쓰는가. 무엇을 달성하려 하는가.

## 핵심 시나리오

### 정상 흐름
1. 사용자가 ~ 한다
2. 시스템이 ~ 한다
3. 결과로 ~ 가 보인다

### 예외 상황
| 상황 | 사용자에게 보이는 것 | 시스템 동작 |
|------|---------------------|------------|

## 데이터
| 항목 | 설명 | 필수 여부 | 제약 |
|------|------|----------|------|

## 상태 변화
| 현재 상태 | 이벤트 | 다음 상태 | 부수 효과 |
|----------|--------|----------|----------|

(해당하지 않으면 "상태 변화 없음" 명시)

## 연동 범위
| 시스템 | 연동 내용 | 방향 |
|--------|----------|------|

(해당하지 않으면 "외부 연동 없음" 명시)

## 권한
| 역할 | 할 수 있는 것 | 할 수 없는 것 |
|------|-------------|--------------|

## 이번 범위
### 하는 것
- ...

### 안 하는 것
- ...

## 성공 기준
- ...

## 비기능 요구사항
- 동시 사용자 수:
- 기대 반응 속도:
- 보안/개인정보:

(해당하지 않으면 "비기능 요구사항 없음" 명시)

## 미결 사항
- ...

(없으면 "미결 사항 없음" 명시)

Tell the user the file path after writing.

"모르겠어요" 대응 전략

| 상황 | 대응 | |------|------| | 결정 권한이 없는 사안 | "미결 사항으로 기록하겠습니다. 누가 결정할 수 있나요?" | | 추상적이라 답하기 어려움 | 구체적 시나리오로 전환: "예를 들어 ~한 상황이면 어떻게 하나요?" | | 진짜 아직 안 정해진 것 | "미결 사항으로 남겨놓겠습니다" | | 침묵 | 기다린다. 대부분 추가 정보를 준다 | | 기술 용어로 답변 | 비즈니스 언어로 번역하여 확인: "~라는 말씀이시죠?" |

Handling Mid-Interview Pivots

If the user changes topic mid-interview:

1. Save current progress — write partial requirements for the original topic
2. Start fresh Phase 1 for the new topic
3. Don't carry over assumptions from the previous topic

Common Mistakes

| Mistake | Fix | |---------|-----| | 기술 용어로 질문 | 비즈니스 언어만 — 용어 변환 표 참고 | | 구체적 질문으로 시작 | Phase 2는 개방형으로 시작. OPEN → PROBE → FOCUS 순서 | | "~기능 필요하세요?"로 유도 | Feature Fishing 금지. 문제를 묻고, 해결책은 사용자가 말하게 | | "만약 ~하면 어떨까요?"로 가상 질문 | 실제 경험 기반: "마지막으로 ~했을 때?" | | 예외를 직접 물음 | 구체 시나리오를 변형하여 예외를 끌어냄 | | Phase 2-3에서 이미 나온 걸 Phase 4에서 재질문 | Phase 4는 빠진 것만 질문 | | 완료 기준 전에 멈춤 | Don't stop early — 5개 차원 커버 확인 | | 너무 오래 끌기 | 명확한 기능은 2-3라운드. Don't drag on | | 미결 사항을 억지로 해결 | 모르면 미결로 기록. 결정 권한자 확인 | | "빨리 시작해줘" 요청에 STOP 생략 | 플랫폼 제약은 우회 불가 — 급해도 로드 턴에서 AskUserQuestion 호출 금지 |

Red Flags — STOP and Reassess

• Phase 1을 건너뛰고 바로 질문 시작
• 기술 용어(API, DB, 스키마, 인증)로 질문
• 한 라운드에 4개 이상 질문
• 사용자 답변을 무시하고 미리 정한 질문만 진행
• "빨리 끝내자"며 핵심 차원 건너뜀
• 코드 구현 얘기를 시작
• specs/ 이외 경로에 파일 작성