브레인스토밍 — 아이디어 탐색 & 수요 검증

서브에이전트로 dispatch되어 특정 task를 실행 중이라면 본 skill 건너뜀. 본 skill은 pre-design 탐색 전용이다.

코드 작성 금지. 파일 생성·수정·삭제·commit 금지.

탐색 완료 후 구현은 /init-project → /start <기능> 으로 진입.

판정: 기계화 불가 (행위 금지형) — "코드를 쓰지 않았다" 는 부재의 증명이라 검사할 산출물이 없다. 본 skill 은 lifecycle 밖 선택 진입점이라 관문도 없다. 위반 시 후속 /start 의 spec 단계에서 드러나는 것이 현실적 안전망이다.

---

Phase 0: 모드 선택

AskUserQuestion으로 모드 선택:

어떤 목표로 아이디어를 탐색하나요?

선택지:

• [S] Startup / 사내 신규 사업 — 수요 검증, 시장 탐색, YC 기준 진단 (Phase 1A)
• [B] Builder / 사이드 프로젝트 — 창의 탐색, 가장 재미있는 버전 발굴, 해커톤/오픈소스/학습 (Phase 1B)

모드 매핑:

• 창업, SI 신규 제안, 사내 서비스 → Startup 모드
• 해커톤, 오픈소스, 개인 학습, 그냥 만들고 싶어서 → Builder 모드

---

Phase 1A: Startup 모드 — YC 제품 진단

운영 원칙

구체성만이 화폐다. 모호한 답변은 계속 밀어붙인다. "헬스케어 기업"은 고객이 아니다. 이름, 직함, 회사, 이유가 필요하다.

관심은 수요가 아니다. 대기자 명단, 가입, "흥미롭네요" — 이 중 어느 것도 수요가 아니다. 행동이 수요다. 돈이 수요다. 서비스가 중단됐을 때 패닉이 수요다.

현재 상태가 진짜 경쟁자다. 다른 스타트업도, 대기업도 아니다 — 사용자가 지금 쓰고 있는 스프레드시트+슬랙 조합이 경쟁자다.

좁을수록 좋다 (초기). 누군가 이번 주에 실제 돈을 낼 가장 작은 버전이, 풀 플랫폼 비전보다 가치 있다.

6개의 Forcing Questions

Q0 — 현재 상태 파악 (라우팅 기준)

Phase 1A 진입 직후 AskUserQuestion으로 먼저 묻는다:

"지금 아이디어의 현재 상태는 어디인가요?"

1. 아이디어만 있음 (아직 사용자 없음)
2. 실제 사용자/피드백 있음
3. 유료 고객 있음

라우팅 규칙:

• 답변 1 → Q1 → Q2 → Q3 (수요 증거·현재 상태·고객 인물)
• 답변 2 → Q2 → Q4 → Q5 (현재 상태·최소 버전·관찰)
• 답변 3 → Q4 → Q5 → Q6 (최소 버전·관찰·미래 적합성)

Q0 이후 라우팅에 따라 해당 질문 3개만 순서대로 진행한다.

각 질문은 AskUserQuestion으로 하나씩 물어본다. 답변이 구체적·증거 기반·불편할 때까지 밀어붙인다.

---

Q1: 수요 현실

질문: "누군가가 이것을 진심으로 원한다는 가장 강력한 증거는 무엇인가요? '관심 있다'거나 '대기자 명단에 등록했다'가 아니라, 내일 사라진다면 진짜 속상할 사람이 있다는 증거요."

여기까지 밀어붙인다: 구체적인 행동. 돈을 낸 사람. 사용을 늘리는 사람. 워크플로우를 이것 중심으로 바꾼 사람.

적신호: "사람들이 흥미롭다고 해요." "대기자 500명 모았어요." "VC들이 이 분야에 관심 있어요." — 이 중 어느 것도 수요가 아니다.

---

Q2: 현재 상태

질문: "사용자들이 지금 이 문제를 해결하기 위해 — 어설프게라도 — 무엇을 하고 있나요? 그 임시방편의 비용은 얼마인가요?"

여기까지 밀어붙인다: 구체적인 워크플로우. 낭비되는 시간. 낭비되는 돈. 억지로 이어붙인 도구들.

적신호: "없어요 — 솔루션이 없어서 기회가 큰 거예요." 진짜 아무것도 없다면 문제가 충분히 아프지 않다는 신호다.

---

Q3: 구체적인 고객 인물

질문: "이것이 가장 필요한 실제 사람을 지목해주세요. 직함은? 무엇이 그들을 승진시키나요? 무엇이 그들을 해고시키나요? 무엇이 그들을 밤에 잠 못 들게 하나요?"

여기까지 밀어붙인다: 이름. 역할. 문제가 해결되지 않으면 그들이 직면하는 구체적인 결과. 가급적 그 사람 입에서 직접 들은 것.

적신호: 카테고리 수준의 답변. "헬스케어 기업." "SMB." "마케팅 팀." 이것들은 필터지 사람이 아니다.

---

Q4: 가장 좁은 쐐기

질문: "플랫폼을 다 만들기 전에, 누군가 이번 주에 실제 돈을 낼 가장 작은 버전은 무엇인가요?"

여기까지 밀어붙인다: 기능 하나. 워크플로우 하나. 며칠 안에 출시할 수 있고 누군가 돈을 낼 것.

적신호: "풀 플랫폼을 만들기 전에는 누가 쓸 수가 없어요." — 아키텍처에 집착하는 신호다.

---

Q5: 관찰 & 놀라움

질문: "실제로 사람들이 이것을 사용하는 것을 직접 보셨나요 — 돕지 않고? 무엇이 놀라웠나요?"

여기까지 밀어붙인다: 구체적인 놀라움. 창업자의 가정을 뒤엎는 것. 아무것도 놀랍지 않다면 보고 있지 않거나 주의를 기울이지 않는 것.

적신호: "설문을 보냈어요." "데모 콜을 했어요." 설문은 거짓말한다. 데모는 연극이다.

---

Q6: 미래 적합성

질문: "3년 후 세상이 의미 있게 달라진다면 — 실제로 달라질 텐데 — 여러분의 제품이 더 필수적이 되나요, 덜 필수적이 되나요?"

여기까지 밀어붙인다: 사용자의 세상이 어떻게 바뀌고, 그 변화가 왜 이 제품을 더 가치 있게 만드는지에 대한 구체적인 주장.

적신호: "시장이 연 20% 성장하고 있어요." 성장률은 비전이 아니다.

---

STOP — 각 질문 후 반드시 멈추고 답변을 기다린다.

---

Phase 1B: Builder 모드 — 창의 탐색

운영 원칙

1. 감탄이 화폐다 — 무엇이 "와!"를 이끌어내나?
2. 보여줄 수 있는 것을 만들어라. 가장 좋은 버전은 존재하는 것이다.
3. 최고의 사이드 프로젝트는 자신의 문제를 해결한다.
4. 최적화 전에 탐색하라. 이상한 아이디어를 먼저 시도해봐라.

탐색 질문

각 질문은 AskUserQuestion으로 하나씩 물어본다. 심문이 아니라 브레인스토밍이 목표.

• 이것의 가장 멋진 버전은 무엇인가요? 진짜 즐거운 것이 되려면?
• 누구에게 보여줄 건가요? 무엇이 그들을 "와!"하게 만들 건가요?
• 실제로 사용하거나 공유할 수 있는 가장 빠른 경로는 무엇인가요?
• 이것에 가장 가까운 기존 것은 무엇이고, 여러분의 것은 어떻게 다른가요?
• 시간이 무제한이라면 무엇을 추가할 건가요? 10배 버전은?

STOP — 각 질문 후 반드시 멈추고 답변을 기다린다.

Builder → Startup 자동 전환 감지:

각 질문 답변에서 다음 신호 단어가 등장하면 즉시 전환:

• "수익", "유료", "돈", "고객이 낼", "팔", "투자", "VC", "시장", "경쟁사", "사업 모델"

전환 시 선언:

"좋네요 — 수익·시장 방향이 보이는군요. 좀 더 날카로운 질문으로 들어갈게요."

→ Builder 탐색 질문 중 남은 것은 건너뛰고 Startup Q2(현재 상태)부터 진행
→ Q0 응답은 "사용자 있음(2번)"으로 간주 → Q2 → Q4 → Q5 라우팅 적용

---

Phase 2: 전제 도전

솔루션 제안 전에 전제를 검증한다:

1. 올바른 문제인가? 다른 프레이밍이 더 간단하거나 임팩트 있는 솔루션을 만들 수 있나?
2. 아무것도 안 하면 어떻게 되나? 실제 아픔인가, 가상인가?
3. 기존 코드가 이미 부분적으로 해결하나? 재사용할 수 있는 패턴/유틸이 있나?

AskUserQuestion으로 전제 확인:

전제:
1. [진술] — 동의/비동의?
2. [진술] — 동의/비동의?

---

Phase 3: 대안 생성

모드별 적용: Builder 모드 = A/B/C 대안 필수 (창의 탐색이 목적 — 산출물 템플릿의 ## 대안 (A/B/C) 섹션에 기록). Startup 모드 = 선택 (검증이 목적이라 대안 발산은 부차 — 수행 시 산출물의 ## 열린 질문·## 다음 단계에 선택 방향만 1~2줄 기록, 별도 A/B/C 섹션 강제 안 함).

탐색된 방향 기반으로 3가지 대안을 병렬 제시:

• A. [가장 단순한 버전] — 며칠 안에 출시 가능
• B. [가장 임팩트 있는 버전] — 핵심 가치 최대화
• C. [가장 창의적인 버전] — 예상치 못한 접근

각 대안마다:

• 핵심 아이디어
• 주요 trade-off
• 예상 구현 난이도

AskUserQuestion으로 방향 선택 또는 조합.

---

Phase 4: 산출물 저장

탐색 완료 후 메모 저장:

mkdir -p .specops/memory
DATE=$(date +%Y%m%d)
TIME=$(date +%H%M%S)
# slug: 공통 헬퍼 사용 (국립국어원 로마자 표기법 — 한글 주제도 의미 있는 ASCII kebab).
#       자체 tr 파이프라인 금지 (한글 전부 제거 → dash 쓰레기). FID slug 관례와 일치.
SLUG=$(bash "${CLAUDE_PLUGIN_ROOT}"/scripts/slug.sh "<주제>" | cut -c1-30)
[ -z "$SLUG" ] && SLUG="idea"   # 빈 주제 방어 (파일명 trailing dash 방지)
OUTPUT=".specops/memory/brainstorming-${DATE}-${TIME}-${SLUG}.md"

산출물 파일 구조는 모드에 따라 분기한다:

[Startup 모드] 산출물:

라우팅 조건부: Q0 응답에 따라 질문된 3개 Q만 실제로 채운다 (답변1 → Q1·Q2·Q3, 답변2 → Q2·Q4·Q5, 답변3 → Q4·Q5·Q6). 미질문 Q 섹션은 생략한다 (빈 <답변> placeholder 를 그대로 남기지 말 것 — 라우팅상 묻지 않은 질문임).

# 브레인스토밍 — <주제>

**날짜**: YYYY-MM-DD
**모드**: Startup
**Q0 상태**: 아이디어만 있음 | 사용자 있음 | 유료 고객 있음

<!-- 아래 섹션 중 Q0 라우팅으로 질문된 3개에 해당하는 것만 포함 -->

## 고객 증거            <!-- Q1(수요 증거) / Q3(구체적 인물) 질문 시 -->
- Q1 진짜 수요 증거: <답변 요약>
- Q3 구체적 인물: <직함 / 회사 / 역할>

## 현재 상태 (경쟁자)   <!-- Q2 질문 시 -->
- Q2 현재 사용 중인 임시방편: <답변>
- 추정 비용/시간 낭비: <답변>

## 최소 버전 Spec       <!-- Q4 질문 시 -->
- Q4 이번 주 출시 가능한 버전: <답변>

## 관찰 & 놀라움        <!-- Q5 질문 시 -->
- Q5 직접 관찰한 것: <답변>

## 미래 적합성          <!-- Q6 질문 시 -->
- Q6 3년 후 더 필수적인가: <답변>

## 열린 질문
- [ ] ...

## 다음 단계
- [ ] /init-project <프로젝트명>

[Builder 모드] 산출물:

# 브레인스토밍 — <주제>

**날짜**: YYYY-MM-DD
**모드**: Builder

## 핵심 감탄 포인트
- 가장 멋진 버전: <답변>
- "와!"를 만드는 요소: <답변>

## 대안 (A/B/C)
- A. [가장 단순한 버전]: <설명>
- B. [가장 임팩트 있는 버전]: <설명>
- C. [가장 창의적인 버전]: <설명>

### 선택된 방향
<선택 + 이유>

## 검토했지만 배제한 방향
...

## 열린 질문
- [ ] ...

## 다음 단계
- [ ] /init-project <프로젝트명>

저장 전 자가 점검 — 자가점검은 실제로 질문된 것만 평가한다 (Startup 은 Q0 라우팅으로 3개만 질문하므로, 고정 Q 번호를 참조하면 성숙한 아이디어(유료고객 경로)가 항상 반려되는 역설이 생김 — 라우팅 상대적으로 판정).

[Startup 모드] — 4개 항목 중 3개 이상 충족 시 저장 진행:

#	기준
1	Q0 라우팅으로 질문된 첫째 Q 답변이 구체적·증거 기반 (모호·카테고리 수준 아님)
2	질문된 둘째 Q 답변이 구체적·증거 기반
3	질문된 셋째 Q 답변이 구체적·증거 기반
4	열린 질문 1개 이상

라우팅별 질문 집합: 답변1 → Q1·Q2·Q3 / 답변2 → Q2·Q4·Q5 / 답변3 → Q4·Q5·Q6. 어느 경로든 "질문된 3개 + 열린질문" 동일 기준으로 판정하므로 성숙도와 무관하게 공정.

[Builder 모드] — 5개 중 3개 이상 충족 시 저장 진행:

#	기준
1	가장 멋진 버전 서술
2	기존 것과의 차이점
3	출시 가능한 가장 빠른 경로
4	"와!" 포인트
5	열린 질문 1개 이상

미충족 시:

"아직 탐색이 부족합니다. [미충족 항목]에 대해 한 번 더 구체화해볼까요?"

→ 해당 항목 질문 후 재점검. 사용자가 "그냥 저장"을 명시하면 그대로 진행.

저장 후: "브레인스토밍 메모가 .specops/memory/brainstorming-<날짜>-<시간>-<슬러그>.md에 저장됐습니다."

---

다음 단계 (선택)

브레인스토밍 완료 후:

• /init-project — 프로젝트 구조 부트스트랩 (탐색 메모로 PRD 6필드 초안 합성 + Phase 11 LLM 보강이 13종 본문에 반영)
• /start <기능> — 프로젝트가 이미 초기화된 경우 바로 Lifecycle 진입

강제 chain 없음 — 탐색 결과로 방향 사용자 결정.

---

5원칙 주입 (specops-ko 고유)

원칙	본 skill 적용
1 투명성	모드 선택 + 질문 결과를 brainstorming-*.md 에 전문 저장
2 문지기	HARD GATE — 코드 작성·파일 생성·commit 금지 (탐색만)
3 깊이	구체성이 없는 답변은 계속 밀어붙임 (관심 ≠ 수요)
4 주권	강제 chain 없음 — 탐색 결과로 방향 사용자 결정
5 한계 고백	정적 질문 목록 — 도메인별 맞춤 질문 미지원

참조

• commands/brainstorming.md — 슬래시 진입점
• skills/using-specops-ko/SKILL.md — 메타 skill
• commands/init-project.md — 다음 단계 (부트스트랩)
• commands/start.md — Lifecycle 진입

다음 skill

탐색 완료 + 산출물 저장 후 사용자 선택에 따라:

• 프로젝트 초기화 필요 → /init-project 슬래시 커맨드 안내 (Skill 아님 — commands/init-project.md)
• 프로젝트 이미 초기화 → specops-ko:specifying-ko 호출

강제 chain 없음. 본 brainstorming-ko는 사용자가 명시적으로 선택하기 전까지 어떤 구현 스킬도 호출하지 않는다.

---

specops-ko v1.72.0 · 2026-07-09 · garrytan/gstack office-hours/SKILL.md 한국어 재창작