Brainstorm-ing

# Brainstorm-ing

전체 워크스루 예시 → [references/example.md](references/example.md)
에이전트 프롬프트 템플릿 → [references/teams-guide.md](references/teams-guide.md)

## 용어 규칙

- 영어 전문용어를 억지로 한글 번역하지 않는다. 원어 그대로 쓰거나, 쉬운 말로 풀어 쓴다.
- 추상적 설명 대신 구체적 예시를 넣는다.
- 한 문장으로 이해 안 되면 예시를 붙인다.

---

## Verbalized Sampling (모든 아이디어 생성에 적용)

아이디어를 생성하는 모든 단계(Step 3, 4, 5)에서, 에이전트는 각 아이디어에 **생성 확률**을 함께 표시한다.

LLM은 가장 가능성 높은(mode) 답변만 내놓으려는 경향이 있다 (mode collapse). 확률 분포를 명시하게 하면 이 편향이 깨지면서 다양성이 **1.6-2.1배** 증가한다.

### 에이전트 프롬프트에 포함할 지시

```
아이디어를 생성할 때, 각 아이디어 옆에 "이 아이디어가 나올 확률"을 %로 표시하세요.
높은 확률(>20%)의 아이디어는 뻔한 답일 가능성이 높습니다.
낮은 확률(<5%)의 아이디어를 의도적으로 더 많이 포함하세요.
```

### 예시

```
1. [35%] 대시보드에 프로그레스 바 추가 ← 뻔한 답
2. [12%] 온보딩을 게임 퀘스트처럼 설계
3. [3%] 유저가 온보딩을 직접 만들게 한다 ← 낮은 확률 = 더 독창적
4. [1%] 온보딩 자체를 제품의 핵심 기능으로 전환
```

근거: Verbalized Sampling (arxiv 2510.01171, 2025)

---

## Step 1: 문제정의

유저가 문제를 자유롭게 설명하면, 5가지로 정리한다.

| 요소 | 질문 | 왜 묻나 |
|---|---|---|
| 현상 | 뭐가 문제인가? | 문제가 어디서 어디까지인지 범위를 잡는다 |
| 이해관계 | 왜 이게 중요한가? | 이걸 안 풀면 뭐가 안 되는지. 급한지 느긋한지 |
| 목표 상태 | 어떤 상태가 되면 해결인가? | "여기까지 하면 됐다"의 기준 |
| 불변 제약 | 못 바꾸는 건 뭔가? | 이건 절대 건드릴 수 없다는 벽 |
| 열린 공간 | 바꿔도 되는 건? | 자유롭게 바꿀 수 있는 영역 |

불변 제약과 열린 공간이 핵심. 이 둘이 아이디어의 자유도를 결정한다.

### 흐름

1. 유저가 문제 설명
2. 위 5가지로 정리해서 보여준다
3. 빠진 것만 물어본다 (보통 불변 제약 + 열린 공간은 유저가 안 말함)
4. 유저가 확인하면 → 문제 v1 완성

---

## Step 2: 페르소나 선정

문제에 맞는 전문가 3명을 고른다. Claude가 직접 선정.

### 3축으로 다양성 확보

| 뭘 다르게 하나 | 예시 |
|---|---|
| **인지 스타일** — 어떻게 생각하는 사람인가 | 데이터로 증명하는 사람 / 원리에서 연역하는 사람 / 일단 해보는 사람 / 직감을 따르는 사람 |
| **지식 영역** — 뭘 아는 사람인가 | UX 전문가 / 게임 디자이너 / 행동경제학자 / 엔지니어 |
| **관점** — 뭘 최적화하는 사람인가 | 사용자 편의 / 비용 절감 / 심미성 / 확장성 |

### 3명을 삼각형으로 배치

- **A**: 이 문제에 딱 맞는 전문가
- **B**: A와 정반대 입장의 전문가
- **C**: A, B와 완전히 다른 분야에서 온 사람 (A-B의 중간이 아님)

예: 온보딩 문제라면 → A: UX 심리학자, B: "UI를 최소화하라"는 미니멀리스트, C: 게임 레벨 디자이너

---

## Step 3: 독립 발산

3명이 각자 따로, 동시에 아이디어를 낸다. 서로 안 본다. 판단 안 한다.

### 4단계로 끝까지 짜낸다 (1명당)

**1단계 — 자유 생성**: 떠오르는 대로 5개

**2단계 — 반대 방향**: 위 5개와 완전히 다른 방향으로 5개 더

**3단계 — 7개 기법으로 강제 확장**: 1-2에서 만든 10개에 아래 기법을 전부 적용

| 기법 | 하는 것 | 예시 |
|---|---|---|
| SCAMPER | 대체/결합/적용/변형/전용/제거/역전 | "이 기능을 제거하면?" "두 기능을 합치면?" |
| 조합 분해 | 문제를 부품으로 쪼개고 조합을 바꿔본다 | 입력방식 × 피드백방식 × 타이밍 → 새 조합 |
| TRIZ | "A를 좋게 하면 B가 나빠지는" 모순을 찾고, 모순 자체를 깬다 | "빠르게 하면 정확도가 떨어진다" → 둘 다 되는 방법은? |
| Provocation | 말도 안 되는 전제에서 시작해서 쓸 만한 걸 뽑아낸다 | "고객이 돈을 안 낸다면?" → 어떤 모델이 가능? |
| Assumption Reversal | 당연하다고 생각한 가정을 뒤집어본다 | "유저가 화면을 본다" → 안 본다면? → 음성 UI |
| Worst Possible Idea | 일부러 최악의 답을 만들고, 뒤집어서 통찰을 얻는다 | 최악: "모든 버튼을 숨긴다" → 통찰: 핵심 1개만 보이면? |
| Exaptation | 원래 용도와 완전히 다르게 쓸 수 있는지 본다 | 레이더 부품 → 전자레인지. 검색 기능 → 추천 엔진 |

**4단계 — 메타 생성**: 1-3에서 나온 전부를 보고, 영감받은 아이디어 5개 + 완전히 다른 아이디어 5개

### 결과

1명당 ~30-40개, 3명 합산 **90-120개** 아이디어.

### 구현

Step 3은 독립 Task 3개를 병렬로 돌린다 (Teams 아님):
```
Task(prompt="페르소나 A + 문제 + 발산 지시")  ─┐
Task(prompt="페르소나 B + 문제 + 발산 지시")  ─┼─ 동시에
Task(prompt="페르소나 C + 문제 + 발산 지시")  ─┘
```

상세 프롬프트 템플릿 → [references/teams-guide.md](references/teams-guide.md) > Step 3

---

## Step 3.5: 클러스터링

Claude가 직접 처리한다 (에이전트 아님).

1. 90-120개 아이디어를 주제별로 묶는다
2. 서로 모순되는 아이디어 쌍을 찾는다

예: "온보딩 단계를 늘려라" vs "온보딩을 없애라" → 정반대지만, 이 모순이 교차 수분의 씨앗이 된다.

이건 평가가 아니라 정리다. 좋다/나쁘다를 판단하지 않는다.

---

## Step 4: 교차 수분 (Teams)

3명이 서로의 아이디어를 보고 조합하고 발전시킨다.

### 입력

각 에이전트가 받는 것:
- 전체 90-120개 아이디어
- 클러스터 결과
- 모순 쌍 목록

### 에이전트가 하는 것

- **교차 조합**: 남의 아이디어 + 내 전문성 → 새 아이디어
  - 예: B의 "UI 제거" + A의 "프로그레스 바" → "대시보드가 프로그레스 바 역할"
- **비판적 빌드업**: "이건 좋은데 X가 약하다. 내 분야에서는 Y로 보완 가능"
  - 까는 게 아니라 보완하는 것
- **연쇄 반응**: SendMessage로 주고받으며 아이디어가 진화
  - A가 보내면 → B가 발전시키고 → C가 거기에 더한다

모순 쌍이 교차의 방향타. "아무거나 반응해라"보다 "이 모순을 풀어봐라"가 훨씬 날카롭다.

### 종료

새 아이디어가 안 나오면 각자 완료 보고.

### 구현

```
TeamCreate(team_name="bs-{키워드}")

Task(name="A", team_name="bs-{키워드}", prompt="페르소나 A + 전체 아이디어 + 클러스터 + 모순 쌍 + 교차 지시")
Task(name="B", team_name="bs-{키워드}", prompt="페르소나 B + ...")
Task(name="C", team_name="bs-{키워드}", prompt="페르소나 C + ...")

→ SendMessage로 서로 반응
→ 완료 → shutdown_request → TeamDelete
```

Step 3의 에이전트는 끝나면 사라진다. Step 4에서 같은 페르소나로 새로 만들되, 이번엔 전체 아이디어를 받고 Teams 안에서 서로 대화한다.

상세 프롬프트 템플릿 → [references/teams-guide.md](references/teams-guide.md) > Step 4

---

## Step 5: 개인 통합 (독립 Task 병렬)

교차 수분에서 남의 아이디어를 본 뒤, 다시 혼자서 소화하는 단계.

Step 3과 다르다. Step 3은 **처음부터 넓게 뿌리기**, Step 5는 **배운 걸 깊이 소화하기**.

### 입력

각 에이전트가 받는 것:
- 자기 원래 아이디어 (Step 3)
- 교차 수분에서 나온 모든 아이디어와 대화 내용 (Step 4)

### 에이전트가 하는 것

1. **통합**: 교차 수분에서 본 남의 아이디어와 내 전문성을 합쳐 새 솔루션을 만든다
   - 예: 교차에서 "안개 맵 온보딩" 컨셉이 나왔다 → 내 UX 전문성으로 구체적 인터랙션을 설계한다
2. **빈 곳 채우기**: 전체 아이디어를 보고 아직 아무도 안 건드린 영역을 찾아서 아이디어를 낸다
3. **마지막 발산**: 전부 다 본 상태에서 완전히 새로운 아이디어를 시도한다

### 구현

독립 Task 3개 병렬 (Teams 아님):
```
Task(prompt="페르소나 A + 자기 원래 아이디어 + Step 4 전체 결과 + 통합 지시")  ─┐
Task(prompt="페르소나 B + 자기 원래 아이디어 + Step 4 전체 결과 + 통합 지시")  ─┼─ 동시에
Task(prompt="페르소나 C + 자기 원래 아이디어 + Step 4 전체 결과 + 통합 지시")  ─┘
```

상세 프롬프트 템플릿 → [references/teams-guide.md](references/teams-guide.md) > Step 5

---

## Step 6: 수렴 — 평가 + 유저 선택

여기서 처음으로 평가가 들어온다. 그 전까지는 전부 생성 모드.

### 6-1. 클러스터링 (Claude 직접)

Steps 3+4+5의 모든 아이디어를 **3-5개 방향**으로 묶는다.

각 방향마다:
- 핵심이 뭔지 한 줄
- 대표 아이디어 2-3개
- 강점
- 리스크

### 6-2. 독립 평가 (Task 3개 병렬)

3명의 에이전트가 각 방향을 **독립적으로** 평가한다 (서로 안 봄).

| 평가 기준 | 뭘 보나 |
|---|---|
| 문제 적합성 | Step 1의 목표 상태에 얼마나 맞나 |
| 독창성 | 기존에 없던 접근인가 |
| 실현 가능성 | Step 1의 불변 제약 안에서 가능한가 |
| 확장성 | 이 방향이 다른 문제에도 쓸 수 있나 |

전문성이 다르니까 같은 방향도 다르게 본다.
예: UX 전문가는 사용성을, 엔지니어는 실현 가능성을 더 높이 친다.

```
Task(prompt="페르소나 A + 방향 목록 + 평가 기준 + 독립 평가 지시")  ─┐
Task(prompt="페르소나 B + 방향 목록 + 평가 기준 + 독립 평가 지시")  ─┼─ 동시에
Task(prompt="페르소나 C + 방향 목록 + 평가 기준 + 독립 평가 지시")  ─┘
```

상세 프롬프트 템플릿 → [references/teams-guide.md](references/teams-guide.md) > Step 6

### 6-3. 종합 + 유저 선택

Claude가 3명의 평가를 종합해서 유저에게 보여준다:
- 방향별 종합 점수
- 전문가별 의견 차이 (의견이 갈리는 방향이 오히려 흥미로울 수 있다)

유저 선택지:
- **실행** → Part 2로 (솔루션 구현)
- **더 깊이** → 선택한 방향을 씨앗으로, Step 2부터 다시
- **넓게** → 새 페르소나로, Step 2부터 다시

---

# Part 2: 실행

## Step 1: 산출물 정의

선택한 방향을 구체적으로 "뭘 만들지" 정의한다. Part 1 Step 1이 문제를 정의했듯이, 여기선 산출물을 정의한다.

| 요소 | 질문 | 왜 묻나 |
|---|---|---|
| 산출물 | 뭘 만드나? | 코드? 문서? 디자인? 구체적 형태를 확정 |
| 핵심 메커니즘 | 이게 문제를 어떻게 푸나? | 선택한 방향이 문제와 연결되는 고리 |
| 완성 기준 | 어디까지 만들면 끝? | "여기까지 하면 됐다"의 기준 |
| 제약 | 기술/시간/리소스 한계는? | 구현에서 절대 넘을 수 없는 벽 |
| 자유도 | 구현에서 자유로운 부분은? | 마음대로 정할 수 있는 영역 |

### 흐름

1. Claude가 선택된 방향을 바탕으로 5요소 초안 작성
2. 유저에게 보여주고 빠진 것만 질문
3. 유저 확인 → 산출물 정의 v1 완성

---

## Step 2: 협력자 정의

산출물을 만들 에이전트 팀을 구성한다. Part 1 Step 2가 "어떤 관점으로 생각할 사람"을 골랐다면, 여기선 "어떤 역할로 만들 사람"을 고른다.

Claude가 산출물 정의를 보고 **최소 3명** 초안을 선정한다. 유저에게 보여주고 확인받는다. 유저가 역할을 추가하거나 바꿀 수 있다.

### 역할 배분 기준

산출물에 필요한 전문성을 보고 역할을 나눈다.

예: 퀘스트 기반 온보딩 컴포넌트를 만든다면:
- **A**: 프론트엔드 개발 — React 컴포넌트 구현
- **B**: 게임 디자이너 — 퀘스트 구조, 난이도 곡선, 보상 설계
- **C**: UX 리서처 — 유저 흐름, 이탈 포인트, 접근성

예: 비즈니스 전략 문서를 만든다면:
- **A**: 시장 분석가 — 경쟁사, 시장 규모, 포지셔닝
- **B**: 재무 모델러 — 수익 모델, 비용 구조, BEP
- **C**: 고객 전문가 — 페르소나, 구매 여정, 채널

---

## Step 3: 개발 (Teams)

협력자들이 Teams 안에서 실제로 산출물을 만든다.

### 흐름

1. 각 에이전트가 자기 역할의 초안을 만든다
2. SendMessage로 서로 공유하고 피드백
3. 피드백 반영해서 수정
4. 전체가 하나로 합쳐질 때까지 반복

### 구현

```
TeamCreate(team_name="build-{키워드}")

Task(name="A", team_name="build-{키워드}", prompt="역할 A + 산출물 정의 + 개발 지시")
Task(name="B", team_name="build-{키워드}", prompt="역할 B + 산출물 정의 + 개발 지시")
Task(name="C", team_name="build-{키워드}", prompt="역할 C + 산출물 정의 + 개발 지시")

→ SendMessage로 협업
→ 완료 → shutdown_request → TeamDelete
```

상세 프롬프트 템플릿 → [references/teams-guide.md](references/teams-guide.md) > Part 2 Step 3

---

## Step 4: 검토

Claude가 산출물을 산출물 정의(Step 1)의 완성 기준과 대조해서 검토한다.

### 검토 항목

- 완성 기준을 충족하는가?
- 핵심 메커니즘이 의도대로 작동하는가?
- 제약을 위반하지 않았는가?
- 빠진 부분이 있는가?

### 유저 선택지

- **완료** → 최종 산출물 전달
- **수정** → 피드백과 함께 Step 2로 (팀 재구성 또는 같은 팀으로 재개발)