Brainstorm ing

Brainstorm-ing

전체 워크스루 예시 → references/example.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 > 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 > 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 > 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 > 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 > Part 2 Step 3

---

Step 4: 검토

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

검토 항목

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

유저 선택지

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