77 lines
7.0 KiB
Markdown
77 lines
7.0 KiB
Markdown
---
|
|
title: "아이디어 단련"
|
|
description: 페르소나 기반 질문으로 아이디어를 압박 검증해 단단하게 만들거나, 입증하거나, 적은 비용으로 폐기합니다
|
|
sidebar:
|
|
order: 14
|
|
---
|
|
|
|
아직 다듬어지지 않은 아이디어를 지금 대화 안에서 압박 검증하세요. 생각을 바꾸는 비용이 아직 0에 가까울 때 검증하는 것이 가장 비용이 적습니다.
|
|
|
|
## 아이디어 단련이란?
|
|
|
|
`bmad-forge-idea`를 실행하면 엄격한 질문자가 아이디어를 하나씩 파고듭니다. 살아남은 것이 실제로 행동할 수 있는 확신이 될 때까지 묻습니다. 이 스킬은 도메인을 가리지 않습니다. 소프트웨어 기능, 비즈니스 모델, 연구 가설, 계속 머릿속을 맴도는 개인적 결정에도 사용할 수 있습니다.
|
|
|
|
남는 것은 더 날카로운 사고입니다. 정제된 `forged-idea.md`는 가능한 종료 형태 중 하나일 뿐이며, 세션은 사용자를 "이제 만들까요?" 쪽으로 몰지 않습니다.
|
|
|
|
## 왜 일찍 압박 검증해야 하나요?
|
|
|
|
가장 위험한 적은 자기 아이디어 안에서 보지 못한 구멍입니다. 검토되지 않은 가정이나 해결되지 않은 갈래는 균열입니다. 지금 놓친 균열은 나중에 빌드나 출시 단계에서 훨씬 더 큰 비용으로 다시 나타납니다.
|
|
|
|
대화는 그것을 잡아내기에 비용이 가장 적게 드는 곳입니다. 여기서 생각을 바꾸는 데는 비용이 들지 않습니다. 단련 과정은 그 낮은 비용을 의도적으로 활용해, 아직 비용 없이 고칠 수 있는 약점을 공격합니다.
|
|
|
|
## 세션 진행 방식
|
|
|
|
질문자는 의존성 순서에 따라 한 번에 하나의 질문을 던지고, 매번 자신의 권장 답도 함께 내놓습니다. 열린 질문보다 반박할 기준이 있는 답이 논의를 더 멀리 밀고 갑니다. 사용자가 찾아오라고 보내는 대신, 찾을 수 있는 답은 스스로 찾습니다.
|
|
|
|
아이디어가 기존 프로젝트 안에 있다면 그 프로젝트 자료가 판단 기준이 됩니다. 질문자는 사용자의 주장을 이미 있는 자료와 대조하고 모순을 짚습니다. 용어도 같은 검토를 받습니다. 어떤 용어가 흐릿하거나 두 의미를 동시에 담고 있다면, 갈래를 해결하기 전에 정확한 선택을 강제합니다. 과부하된 단어 위에 세운 갈래는 거짓으로 해결되기 때문입니다.
|
|
|
|
## 대화 구성
|
|
|
|
단련 과정에는 참여자가 있습니다. 주제가 정해지면 각 갈래마다 얼굴 없는 하나의 어시스턴트가 아니라 두 인물이 함께 나섭니다. 하나는 설치된 명단에서 고릅니다. [파티 모드](./party-mode.md)와 [이름 있는 에이전트](./named-agents.md)의 같은 출연진에서 가져온, 사용자가 알아볼 에이전트나 페르소나입니다. 다른 하나는 주제에 맞춰 즉석에서 만든 인물입니다. 적대적인 경쟁자, 회의적인 CFO, 바로 이런 계획이 실패하는 것을 여러 번 본 도메인 전문가일 수 있습니다.
|
|
|
|
사용자는 언제든 대화를 조종할 수 있습니다. 특정 인물을 지명하거나, 저장된 파티를 부르거나, **adversarial on this** 기능을 호출해 한 주장을 끝까지 공격하게 하고 사용자가 방어할 수 있습니다.
|
|
|
|
## 기본 동의는 없습니다
|
|
|
|
반사적인 동의는 이 스킬이 거부하려고 만들어진 실패 유형입니다. 아이디어를 이해했다는 말은 그 아이디어를 지지한다는 뜻이 아닙니다. 단련 과정은 어떤 것도 검증을 통과하기 전에는 칭찬하지 않습니다. 약점을 공격하거나 강점을 더 밀어붙이고, 실제로 얻어낸 것에만 공을 줍니다.
|
|
|
|
이는 [적대적 리뷰](./adversarial-review.md)의 의도적인 반대편입니다. 적대적 리뷰에서는 리뷰어가 문제를 찾도록 지시받고, 사용자는 거짓 양성을 걸러냅니다. 여기서는 질문자가 공짜 동의를 하지 않습니다. 그래서 긴장감이 유지되고, 사용자는 그 압력 아래에서 더 깊게 생각합니다. 편안한 세션보다 좋은 아이디어를 남기는 쪽에 맞춥니다.
|
|
|
|
## 세션 종료 방식
|
|
|
|
세션은 생각이 정리된 지점에서 끝납니다. 모든 결말은 실제 결과입니다. 단련 과정은 결과를 표시한 독립 보고서를 작성합니다.
|
|
|
|
| 결과 | 의미 |
|
|
| --- | --- |
|
|
| **단련됨** | 아이디어가 살아남았습니다. 확정한 결정과 폐기된 것 및 그 이유를 `forged-idea.md`로 정제합니다. 제품 개념이라면 `bmad-spec`, `bmad-prd`, `bmad-prfaq`의 입력으로 사용할 수 있습니다. |
|
|
| **폐기됨** | 아이디어가 살아남지 못했습니다. 보고서는 폐기 이유를 기록합니다. 그것을 적은 비용으로 알아낸 것 자체가 이득입니다. |
|
|
| **명확해짐** | 이제 더 명확하게 생각할 수 있습니다. 별도 산출물이 필요하지 않으며, 세션 자체로 충분합니다. |
|
|
|
|
## 사용 시점
|
|
|
|
이미 아이디어가 있고, 그 아이디어에 투자하기 전에 단단하게 만들거나 폐기하고 싶을 때 사용하세요. 아직 선택지를 생성하는 중이거나 에이전트들의 집단 결정을 원한다면 건너뛰세요.
|
|
|
|
| 스킬 | 사용 시점 | 목소리 |
|
|
| --- | --- | --- |
|
|
| `bmad-forge-idea` | 아이디어가 있고 스트레스 테스트하거나 폐기하고 싶을 때 | 질문자와 두 인물이 참여하는 대화 |
|
|
| `bmad-prfaq` | 제품을 추진하기로 정했고 고객 우선 관점에서 입증하고 싶을 때 | Working Backwards 코치 |
|
|
| `bmad-brainstorming` | 아직 아이디어가 없고 선택지를 생성해야 할 때 | 퍼실리테이션 코치 |
|
|
| `bmad-party-mode` | 에이전트들이 함께 토론하거나 결정하길 원할 때 | 한 대화 안의 전체 명단 |
|
|
| `bmad-review-adversarial-general` | 산출물이 있고 결함을 찾아야 할 때 | 반드시 이슈를 찾아야 하는 리뷰어 |
|
|
|
|
## 예시
|
|
|
|
:::note[예시]
|
|
**사용자:** "앱에 AI 생성 주간 요약을 넣고 싶어요. 사용자에게 매주 월요일 요약 이메일을 보내는 겁니다."
|
|
|
|
**Forge:** "기능 전에, 누가 이걸 요청했나요? 제 권장 답은 아무도 요청하지 않았다는 것입니다. 지금은 'AI 요약은 가치 있어 보인다'에서 출발하고 있습니다. 실제 신호가 있다면 반박해 주세요."
|
|
|
|
**회의적인 CFO(즉석 생성):** "월요일 요약은 전체 활성 사용자 기반에 대해 반복 추론 비용을 영구적으로 발생시킵니다. 어떤 매출 항목이 그 비용을 지불하나요?"
|
|
|
|
**사용자:** "리텐션이요, 아마도요. 사람들이 다시 오는 걸 잊으니까요."
|
|
|
|
**Forge:** "그렇다면 핵심 주장은 '월요일 이메일이 이탈 직전 사용자를 되돌린다'이지, 'AI 요약은 가치 있다'가 아닙니다. 둘은 다른 아이디어입니다. 어느 쪽을 단련할까요?"
|
|
:::
|
|
|
|
첫 아이디어는 기능이었습니다. 질문 두 개 뒤에 실제 아이디어는 모델 없이도 일반 이메일로 테스트할 수 있는 리텐션 가설이 됩니다.
|