ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity

docs(ko-kr): sync v6.9 documentation updates

This commit is contained in:
yeomin4242 2026-06-23 13:14:30 +09:00
parent 2d1aa2dff5
commit f76b410ed1
No known key found for this signature in database
GPG Key ID: 0DFD808CE1AC5196
7 changed files with 297 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

76
docs/ko-kr/explanation/forge-idea.md Normal file
View File

@ -0,0 +1,76 @@
---
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 요약은 가치 있다'가 아닙니다. 둘은 다른 아이디어입니다. 어느 쪽을 단련할까요?"
:::
첫 아이디어는 기능이었습니다. 질문 두 개 뒤에 실제 아이디어는 모델 없이도 일반 이메일로 테스트할 수 있는 리텐션 가설이 됩니다.

143
docs/ko-kr/explanation/party-mode.md
View File

@ -1,59 +1,150 @@
---
title: "파티 모드"
description: 다중 에이전트 협업 - 모든 AI 에이전트를 하나의 대화에 모읍니다
description: AI 에이전트를 하나의 대화에 모아 실행하고, 직접 출연진을 만들고, 얼마나 독립적으로 사고할지 선택합니다
sidebar:
order: 11
---
모든 AI 에이전트를 하나의 대화에 모으세요.
파티 모드는 AI 에이전트를 한 방에 모아 서로, 그리고 사용자와 대화하게 합니다. 이 문서는 파티가 무엇인지, 파티를 실행하는 네 가지 방식, 설치된 에이전트 대신 직접 페르소나 출연진을 만드는 방법, 그리고 파티가 세션 사이에 사용자를 기억하는 방식을 설명합니다.
## 파티 모드란?
`bmad-party-mode`를 실행하면 PM, 아키텍트, 개발자, UX 디자이너 등 필요한 AI 팀 전체가 한 대화방에 모입니다. 파티 모드가 논의를 조율하고 메시지마다 설치된 에이전트 중 적합한 에이전트를 선택합니다. 에이전트들은 각 페르소나에 맞게 답하고, 동의하거나 반대하며, 서로의 아이디어를 이어받아 발전시킵니다.
`bmad-party-mode`를 실행하면 이미 설치된 BMad 에이전트들이 한 대화에 모입니다. PM, 아키텍트, 개발자, UX 디자이너, 그리고 선택한 모듈이 제공하는 다른 에이전트들이 함께 들어옵니다. 설치된 이 명단이 기본 파티이며 별도 설정 없이 바로 사용할 수 있습니다. 이들은 각자 캐릭터에 맞게 답하고, 동의하거나 반대하며, 서로의 생각을 이어갑니다. 사용자는 방을 조종합니다. 후속 질문을 하고, 반박하고, 한 목소리를 앞으로 끌어내거나, 주제를 바꿀 수 있습니다. 대화는 사용자가 끝낼 때까지 계속됩니다.
대화는 원하는 만큼 계속됩니다. 후속 질문을 묻고, 답에 반박하고, 토론 방향을 바꿀 수 있습니다. 끝날 때까지 에이전트들과 실제 주고받는 대화를 합니다.
이 방식이 작동하는 이유는 페르소나마다 우선순위가 다르기 때문입니다. 아키텍트는 설계를 지키고, PM은 범위를 지키고, 개발자는 실제로 만들 수 있는지를 지킵니다. 이들을 같은 방에 넣으면 절충점이 스프린트 3주 차가 아니라 지금 대화 안에서 드러납니다.
**잘 맞는 경우:**
- 절충이 필요한 큰 결정
- 브레인스토밍 세션
- 문제가 생겼을 때의 사후 분석
- 스프린트 회고와 계획
- 실제 절충이 필요한 결정
- 브레인스토밍과 "무엇을 놓쳤나?" 점검
- 사후 분석과 회고
- 실행 전에 계획을 압박 검증하기
## 예시
파티 모드는 페르소나들이 의견을 갖고 충돌하기 때문에 빠르고 꽤 재미있는 브레인스토밍 방법이기도 합니다. 다른 어떤 워크플로 안에서도 파티를 시작할 수 있습니다. 브레인스토밍 중, PRD 작성 중, 코딩 중, 영업 각도를 잡는 중, 창작물을 다듬는 중에도 가능합니다. 눈앞의 것에 대해 더 많은 관점이 필요할 때, 하던 일을 내려놓지 않고 방을 불러오세요.
### 나쁜 아키텍처 지적하기
:::note[예시]
**사용자:** MVP에는 모놀리스가 좋을까요, 마이크로서비스가 좋을까요?
**사용자:** "좋아요 팀, 지난 스프린트는 엉망이었어요. 인증 서비스가 세 번이나 내려갔습니다. 어디서 문제가 생겼나요?"
**아키텍트:** 모놀리스로 시작하세요. 사용자 1,000명 규모에서는 마이크로서비스가 필요 없는 운영 비용을 더합니다.
**아키텍트:** "설계 자체는 건전했습니다. 분산 인증과 적절한 대체 경로가 있었죠. 구현이 사양에서 벗어났다면..."
**PM:** 동의합니다. 아직 증명하지 못한 확장성보다 출시 속도가 더 중요합니다.
**개발자:** "저는 아키텍처 문서를 그대로 따랐습니다. 사양이 동시 세션 무효화 경쟁 조건을 다루지 않았어요."
**개발자:** 모놀리스가 좋습니다. 다만 나중에 서비스 하나를 분리해도 재작성하지 않도록 명확한 모듈 경계를 둡시다.
:::
**PM:** "두 분 모두 더 큰 이슈를 놓쳤습니다. PRD에서 세션 관리 요구사항을 검증하지 않았어요. 그걸 잡지 못한 건 제 책임입니다."
## 파티 시작하기
**TEA:** "통합 테스트에서 제가 잡았어야 했습니다. 테스트 시나리오가 동시 무효화를 다루지 않았어요."
스킬을 호출하고 원하는 것을 말하세요. 스킬이 사용자가 파티를 실행하려는지, 새로 만들려는지 판단합니다.
### 창의적 브레인스토밍
| 목표 | 입력 |
| --- | --- |
| 기본 모드로 파티 시작 | `/bmad-party-mode` |
| 특정 모드로 시작 | `/bmad-party-mode --mode auto` (`session`, `subagent`, `agent-team`도 가능) |
| 저장된 파티 열기 | `/bmad-party-mode --party code-review-crew` |
| 즉석에서 출연진 만들기 | "엔터프라이즈호 브리지 크루로 파티 모드" |
| 파티 생성 또는 추가 | "파티 모드, 새 파티 만들어줘" |
| 기존 파티 편집 | "파티 모드, writers' room 편집해줘" |
| 스킬 커스터마이즈 | `/bmad-customize bmad-party-mode` |
**사용자:** "온보딩이 지루하지 않고 특별하게 느껴지게 하려면 어떻게 해야 할까요?"
## 파티 실행 방식
**UX 디자이너:** "점진적 공개부터 시작하세요. 기능을 튜토리얼에서 한꺼번에 보여주지 말고, 사용자가 필요로 할 때 드러내는 겁니다."
파티는 네 가지 모드로 실행할 수 있습니다. 세션당 하나의 모드가 활성화되며, 그 모드는 누가 사고하는지를 결정합니다. 하나의 모델이 모두의 목소리를 내는지, 별도 에이전트들이 각자 추론하는지가 달라집니다.
**스토리텔러:** "온보딩이 하나의 이야기라면 어떨까요? 각 단계가 캐릭터의 여정을 드러내고, 사용자가 바로 그 주인공이 되는 겁니다."
| 모드 | 하는 일 | 사용 시점 |
| --- | --- | --- |
| `session` | 기본값입니다. 하나의 모델이 모든 페르소나를 인라인으로 연기합니다. 빠르고 대화가 자연스럽습니다. | 대부분의 대화. 농담, 브레인스토밍, 빠른 주고받기. |
| `auto` | 가벼운 라운드는 인라인으로 진행하고, 독립성이 답을 바꾸는 경우에만 독립 에이전트를 생성합니다. | 대부분은 속도를 원하지만 어려운 라운드에서는 실제 독립성이 필요할 때. |
| `subagent` | 의미 있는 라운드마다 페르소나별 별도 에이전트를 생성합니다. 한 생각이 모두를 물들이지 않습니다. | 정직한 리뷰와 포커스 그룹처럼 목소리가 섞이면 안 될 때. |
| `agent-team` | 페르소나를 지속 팀으로 세워 서로 직접 대화하게 합니다. Claude Code 전용입니다. | 에이전트들이 서로 말하는 실시간 원탁 토론을 손 놓고 지켜보고 싶을 때. |
**게임 디자이너:** "그 아이디어를 이어가 보죠. 첫 번째 '퀘스트'가 실제 사용자 문제를 해결하는 일이라면 어떨까요? 사용자는 가치 있는 일을 해내며 배웁니다."
이 선택은 중요합니다. 하나의 모델이 다섯 페르소나를 연기하면 조용히 수렴할 수 있습니다. 결국 같은 마음을 공유하기 때문입니다. 실제 에이전트를 생성하면 추론이 분리되고, 리뷰 패널이나 포커스 그룹에서 중요한 독립성을 지킬 수 있습니다. `session`은 가장 저렴하고 유연합니다. 생성 모드는 비용이 더 들지만 독립성을 보호하고, `auto`는 필요한 라운드에만 생성해 둘 사이를 노립니다.
### 기술 결정
`session`이 기본값입니다. 다른 모드를 실행할 수 없는 환경에서는 순서대로 되돌아갑니다. `agent-team`은 `subagent`로, 다시 `session`으로 내려갑니다. 설정된 기본값은 커스터마이징에 저장되고, 실행 시점의 override가 해당 세션에서 우선합니다.
**사용자:** "MVP에는 모놀리스가 좋을까요, 마이크로서비스가 좋을까요?"
:::tip[한 세션만 override]
`--mode subagent` 또는 `auto`, `agent-team`, `session`으로 파티를 시작하면 설정된 기본값을 그 실행에서만 바꿀 수 있습니다.
:::
**아키텍트:** "모놀리스로 시작하세요. 사용자 1,000명 규모에서는 마이크로서비스가 필요 없는 복잡성을 더합니다."
## 커스텀 파티
**PM:** "동의합니다. 이론적인 확장성보다 출시 속도가 더 중요합니다."
기본적으로 파티는 설치된 BMad 에이전트를 사용합니다. 더 큰 쓰임은 설명할 수 있는 어떤 페르소나 집합이든 직접 출연진으로 만들고, 저장해 재사용하는 것입니다. 파티 작성도 같은 스킬로 합니다. 스킬은 사용자가 파티를 실행하려는지 만들려는지 감지하고, 결과를 [bmad-customize](../how-to/customize-bmad.md)를 통해 오버라이드에 씁니다.
**개발자:** "명확한 모듈 경계를 둔 모놀리스가 좋겠습니다. 필요해지면 나중에 서비스를 분리할 수 있습니다."
파티 모드는 다른 BMad 스킬처럼 커스터마이즈할 수 있습니다. `/bmad-customize bmad-party-mode`를 실행해 기본값을 직접 설정하세요. 만든 그룹을 기본 파티로 고정해 플래그 없이 로드되게 할 수 있고, 시작 모드를 고를 수 있으며, 방 전체가 세션 내내 지킬 규칙도 설정할 수 있습니다.
두 가지 개념이 대부분의 일을 합니다.
**페르소나**는 멤버를 알아볼 수 있게 만드는 요소입니다. 말하는 방식, 중요하게 여기는 것, 논쟁 방식, 집착하는 문제, blind spot이 여기에 들어갑니다. "회의적인 CFO"는 placeholder입니다. "18개월 안에 회수 계획이 없으면 승인하지 않고, 그 말을 첫 30초 안에 꺼내는 사람"은 페르소나입니다. 그 정도의 구체성이 있어야 이름표를 가려도 알아볼 수 있는 목소리가 됩니다.
**장면**은 무대를 설정합니다. 장면은 한 줄의 자유 형식 문장입니다. 배경, 벌어지는 일, 누가 누구에게 적대적인지, 누가 가장 세게 밀어붙이는지를 적습니다. 같은 멤버도 장면마다 다르게 움직입니다. 한 사람을 한 번 정의해 두고, 임무 중인 브리지 크루, 근무 후 라운지의 같은 크루, 적대적인 구매자 패널에 넣을 수 있습니다. 멤버들은 이름 있는 그룹으로 묶이고, 그룹 하나를 기본 방으로 고정할 수 있습니다.
### 파티의 형태
| 형태 | 의미 |
| --- | --- |
| 테마 출연진 | 유명 투자자, TV 앙상블처럼 특정 주제 주변에 모인 구분되는 목소리. |
| 일회성 페르소나 | 그룹 없이도 pool에 추가한 하나 또는 두 페르소나. |
| 데이터 기반 포커스 그룹 | 고객 또는 설문 데이터를 주면 행동 동인을 기준으로 군집화하고 대표 페르소나를 만듭니다. 고객들이 독립적으로 반응하도록 `subagent` 모드와 함께 쓰세요. |
| 리뷰 패널 | 중요한 것을 두고 논쟁하도록 설계된 비판 렌즈들입니다. 함께 제공되는 Code Review Crew가 예입니다. |
| 열린 출연진 방 | 고정 명단이 없습니다. 장면이 세계관을 정하고, 주제가 바뀔 때마다 방이 즉석 캐스팅됩니다. |
가장 큰 효과가 나는 경우는 포커스 그룹입니다. 실제 프로필을 넣으면 대표 고객 패널이 만들어지고, 제품을 만들기 전에 아이디어를 시험할 수 있습니다. 각 고객은 마지막 목소리에 동의하는 대신 자신의 목표와 예산에서 반응합니다.
## 만들 수 있는 파티
파티는 페르소나와 장면뿐이므로 범위가 넓고, 새 스킬이나 모듈이 필요하지 않습니다.
- 스타트업 아이디어를 스트레스 테스트하는 창업자 팀.
- 감사 전에 구멍을 찾는 컴플라이언스 팀.
- 소프트웨어 개념을 두고 토론하는 애자일 선언문 작성자들.
- 글쓰기 파트너 그룹으로서의 코미디언 방.
- 철학적 질문을 풀거나 어려운 문제를 해체하는 과거의 위대한 사상가들.
- 분기 계획을 세우는 비즈니스 경영진.
이는 출발점일 뿐입니다. 설명할 수 있는 어떤 목소리 집합이든 파티가 됩니다. 페르소나를 쓰고, 방에 장면을 주면 됩니다.
## Code Review Crew
기본 파티는 설치된 모듈이 제공하는 에이전트입니다. Code Review Crew는 그 기본 파티와 함께 제공되는 커스텀 파티입니다. 직접 파티를 만들기 전에 참고할 수 있는 작동 템플릿이지 기본값을 대체하지 않습니다. 이는 리뷰 패널입니다. 다섯 가지 렌즈가 변경을 서로 다른 각도에서 공격하고, 형식적인 승인 대신 실제로 중요한 것이 무엇인지 논쟁합니다.
| 멤버 | 렌즈 |
| --- | --- |
| Vex | 보안. 모든 것을 threat model로 보고 구체적인 악용 경로를 말합니다. |
| Grumbal | 적대자. 코드는 깨졌다고 가정하고 그것을 증명하려고 합니다. |
| Boundary | 엣지 케이스. 모든 분기, null, race, oversized input, 이상한 timezone을 봅니다. |
| Yui | 장인. 단순성, 이름, 불필요한 영리함이나 중복 제거를 봅니다. |
| Dana | 실용주의자. 완벽주의자들에게 반박하고 실제 문제와 사소한 지적을 구분합니다. |
이 crew는 정의되어 있지만 비활성 상태로 제공됩니다. 멤버들은 pool에 있고 그룹을 소환하기 전까지 비용을 만들지 않으며, 기본 방을 어지럽히지 않습니다. 다섯 렌즈가 각자 검토한 뒤 발견 사항을 두고 충돌하도록 `subagent` 모드로 실행하세요.
## 대화 조종하기
사용자는 내내 방을 조종합니다.
- 누군가를 들이기: "UX 디자이너를 불러와."
- 한 목소리를 깊게 파기: "Winston, 저걸 해체해 봐." 직접 요청하면 한 페르소나가 길게 펼칠 신호가 됩니다.
- 세션 중 방 바꾸기: "writers' room으로 전환해." 활성 그룹을 바꾸고 대화 맥락은 이어갑니다.
- 현재 방에 없는 커스텀 멤버라도 이름으로 소환하기.
어떤 모드로 실행 중이든 오케스트레이터는 결과를 별도 답변 더미가 아니라 하나의 대화로 제시합니다. 페르소나를 캐릭터 안에 유지하며, 메커니즘을 설명하려고 제4의 벽을 깨지 않습니다.
:::tip[둘 이상의 방 섞기]
한 그룹에 제한되지 않습니다. 여러 파티의 멤버를 같은 대화로 끌어오거나, 그 자리에서 출연진을 지명해 섞을 수 있습니다. 예를 들어 Golden Girls를 Martin Fowler, Linus Torvalds와 함께 아키텍처 리뷰에 던져 넣고 변경 요청을 두고 논쟁하게 할 수 있습니다. 어떤 일이 벌어질지 상상할 수 있을 겁니다.
:::
## 방은 기억합니다
파티에 메모리를 주면 중단했던 지점에서 이어갑니다. 파티는 지난 세션의 자체 기록을 유지합니다. 멤버 사이에 쌓인 역학, 열어 둔 실마리, 이전 대화가 어디에 도착했는지를 기억합니다. 일주일 뒤 다시 열어도 그 이력은 남아 있습니다. 지난번에 충돌했던 두 멤버는 조금 차갑게 시작하고, 예전 세션의 날카로운 한 줄이 자연스러운 callback으로 다시 나타날 수 있습니다.
이는 transcript가 아니라 memory입니다. 방은 모든 말을 기록하지 않고, 기억할 가치가 있는 몇 가지만 가져갑니다. 그래서 다음 대화가 이어지는 느낌을 주면서도 과거 전체를 끌고 오지 않습니다. 이 과정은 백그라운드에서 자동으로 일어납니다. 따로 저장할 것이 없고, 방은 캐릭터를 깨고 memory를 설명하지 않습니다.
즉석에서 등장한 캐릭터도 기억될 수 있습니다. 열린 출연진 장면의 walk-on이거나, 대화 중 추가한 사람일 수 있습니다. 세션 끝에서 방은 새로 온 인물을 유지할지 제안하고, 유지하면 파티에 접어 넣어 다음에도 다시 올 수 있게 합니다.
메모리는 파티별로 설정됩니다. 파티를 만들거나 저장할 때 기억할지 묻습니다. 기본 설치 에이전트 방은 끄지 않는 한 기억합니다. 이 설정은 `/bmad-customize bmad-party-mode`에서 바꿀 수 있습니다.
## 세션 기념본
마무리할 때 오케스트레이터는 기념본을 제안합니다. 보관하거나 공유할 수 있는 독립 HTML 문서 하나입니다. 원시 transcript를 덤프하는 대신 페르소나별로 대화를 배치합니다. 거절하면 파티는 그대로 끝납니다.
:::tip[더 나은 결정]
다양한 관점을 통해 더 나은 결정을 내립니다. 파티 모드에 오신 것을 환영합니다.
파티의 가치는 의견 차이에 있습니다. 한 방의 다양한 관점은 한 줄의 사고가 놓치는 것을 잡아냅니다.
:::

14
docs/ko-kr/how-to/customize-bmad.md
View File

@ -22,7 +22,7 @@ sidebar:
:::note[필수 조건]
- 프로젝트에 BMad 설치([BMad 설치 방법](./install-bmad.md) 참고)
- PATH의 Python 3.11+(병합 스크립트용, stdlib `tomllib`만 사용하며 `pip install`, `uv`, virtualenv 불필요)
- resolver 스크립트를 실행할 방법. BMad는 `uv run` 표준으로 이동 중이며, `uv`가 Python을 준비해 줍니다. 전환 기간에는 PATH의 일반 `python3` 3.11+도 작동합니다. 스크립트는 stdlib `tomllib`만 사용하므로 `pip install`할 것은 없습니다
- TOML 파일을 편집할 텍스트 에디터
:::
@ -198,15 +198,15 @@ persistent_facts = [
## 해석이 작동하는 방식
활성화 시 에이전트의 SKILL.md가 공유 Python 스크립트를 실행해 3계층 병합을 수행하고 해석된 블록을 JSON으로 반환합니다. 스크립트는 Python 표준 라이브러리의 `tomllib`만 사용하므로 기본 `python3`이면 충분합니다.
활성화 시 에이전트의 SKILL.md가 공유 Python 스크립트를 실행해 3계층 병합을 수행하고 해석된 블록을 JSON으로 반환합니다. 스크립트는 Python 표준 라이브러리의 `tomllib`만 사용합니다. BMad는 이 스크립트를 `uv run`으로 호출하는 방향으로 표준화하고 있습니다. `uv`가 적절한 Python을 준비해 주며, 전환 기간에는 일반 `python3`도 작동합니다.
```bash
python3 {project-root}/_bmad/scripts/resolve_customization.py \
uv run {project-root}/_bmad/scripts/resolve_customization.py \
--skill {skill-root} \
--key agent
```
**요구사항**: Python 3.11+(이전 버전에는 `tomllib`이 없습니다). `pip install`, `uv`, virtualenv는 필요 없습니다. `python3 --version`으로 확인하세요. Homebrew 없는 macOS나 Ubuntu 22.04 같은 플랫폼은 기본 `python3`이 3.10 이하일 수 있으므로 3.11+를 별도 설치해야 할 수 있습니다.
**요구사항**: Python 3.11+(이전 버전에는 `tomllib`이 없습니다). `pip install`할 것은 없습니다. 앞으로의 표준은 `uv run`입니다. `uv`가 적절한 인터프리터를 해결해 줍니다. 전환 기간에 `python3`로 직접 실행한다면 `python3 --version`으로 버전을 확인하세요. Homebrew 없는 macOS나 Ubuntu 22.04 같은 플랫폼은 기본 `python3`이 3.10 이하일 수 있으므로 3.11+를 별도 설치해야 할 수 있습니다.
`--skill`은 스킬이 설치된 디렉터리(`customize.toml`이 있는 위치)를 가리킵니다. 스킬 이름은 디렉터리의 basename에서 파생되며, 스크립트는 `_bmad/custom/{skill-name}.toml`과 `{skill-name}.user.toml`을 자동으로 찾습니다.
@ -214,17 +214,17 @@ python3 {project-root}/_bmad/scripts/resolve_customization.py \
```bash
# 전체 에이전트 블록 해석
python3 {project-root}/_bmad/scripts/resolve_customization.py \
uv run {project-root}/_bmad/scripts/resolve_customization.py \
--skill /abs/path/to/bmad-agent-pm \
--key agent
# 단일 필드 해석
python3 {project-root}/_bmad/scripts/resolve_customization.py \
uv run {project-root}/_bmad/scripts/resolve_customization.py \
--skill /abs/path/to/bmad-agent-pm \
--key agent.icon
# 전체 덤프
python3 {project-root}/_bmad/scripts/resolve_customization.py \
uv run {project-root}/_bmad/scripts/resolve_customization.py \
--skill /abs/path/to/bmad-agent-pm
```

55
docs/ko-kr/how-to/pressure-test-an-idea.md Normal file
View File

@ -0,0 +1,55 @@
---
title: "아이디어 압박 검증하기"
description: bmad-forge-idea 스킬로 투자 전에 아이디어를 단단하게 만들고, 입증하거나, 폐기합니다
sidebar:
order: 12
---
`bmad-forge-idea` 스킬을 사용해 반쯤 형성된 아이디어를 적대적 질문 아래에 두세요. 아이디어는 충분히 검증된 확신으로 살아남거나, 저렴하게 죽습니다.
## 사용 시점
- 시간이나 돈을 쓰기 전에 아이디어를 스트레스 테스트하고 싶습니다
- 격려가 아니라 죽일지 말지에 대한 정직한 판단이 필요합니다
- 결정의 여러 갈래 중 하나를 선택해야 하며 각 갈래를 해결해야 합니다
- 아이디어가 기존 프로젝트 안에 있고 이미 있는 것과 대조해야 합니다
## 건너뛸 시점
- 아직 아이디어가 없고 선택지를 생성해야 합니다. `bmad-brainstorming`을 사용하세요
- 제품을 추진하기로 정했고 고객 우선 관점에서 입증하고 싶습니다. `bmad-prfaq`를 사용하세요
- 에이전트들이 함께 결정을 토론하길 원합니다. `bmad-party-mode`를 사용하세요
:::note[필수 조건]
없습니다. 단련 과정은 일반 대화에서 실행됩니다. 설치된 에이전트와 설정된 페르소나 명단이 있으면 세션이 더 풍부해지지만, 없어도 작동합니다.
:::
## 세션 실행하기
### 1. 스킬 호출하기
IDE에서 `bmad-forge-idea`를 입력하거나, "아이디어를 단련해줘" 또는 "이걸 압박 검증해줘"라고 말하세요. 같은 메시지에 아이디어를 적어도 되고, 첫 질문을 기다려도 됩니다.
### 2. 목표 말하기
원하는 것을 말하세요. 아이디어를 단단하게 만들고 싶은지, 입증하거나 죽이고 싶은지, 아니면 그저 끝까지 생각해 보고 싶은지 알려줍니다. 목표는 질문 방향을 정합니다. 입증은 가장 중요한 주장부터 공격하고, 단련은 각 갈래를 해결된 답으로 밀어붙입니다.
### 3. 한 갈래씩 사고 방어하기
질문자는 한 번에 하나의 질문을 던지고, 사용자가 반박할 수 있도록 자신의 권장 답을 함께 내놓습니다. 솔직하게 답하세요. 흐릿한 용어나 프로젝트 현실과 맞지 않는 주장을 지적하면, 다음으로 넘어가기 전에 먼저 정리하세요.
### 4. 방 조종하기
모든 갈래는 두 목소리와 함께 옵니다. 하나는 사용자 명단에서, 하나는 주제가 즉석에서 불러낸 인물입니다. 특정 페르소나를 이름으로 부르거나, 저장된 파티를 소환하거나, "adversarial on this"라고 말해 한 주장을 공격하게 하고 직접 방어하세요.
### 5. 종료 지점에 도착하기
아이디어가 단련되거나, 폐기되거나, 단순히 더 명확해질 때까지 각 갈래를 해결된 답으로 밀고 가세요. 끝났다고 말해도 되고, forge가 종료를 판단하게 둬도 됩니다.
## 얻는 결과
Forge는 모든 실행마다 결과에 맞는 표시가 붙은 독립적인 `forge-report.html`을 작성합니다. 단련된 아이디어는 잠긴 결정과 폐기한 것 및 그 이유를 담은 `forged-idea.md`로도 정제됩니다. 제품 개념이라면 이 파일을 `bmad-spec`, `bmad-prd`, `bmad-prfaq`의 입력으로 사용할 수 있습니다. 폐기되거나 명확해진 세션에는 별도 산출물이 필요하지 않습니다. 보고서 자체로 충분합니다.
:::tip[아이디어가 죽게 두세요]
아이디어가 버티지 못한다는 사실을 싸게 알아내는 것이 이득입니다. 세션을 "예"로 유도하지 마세요.
:::

29
docs/ko-kr/reference/core-tools.md
View File

@ -18,6 +18,7 @@ IDE에서 스킬 이름(예: `bmad-help`)을 입력해 어떤 핵심 도구든
| [`bmad-help`](#bmad-help) | 작업 | 다음에 무엇을 해야 할지 상황에 맞게 안내 |
| [`bmad-brainstorming`](#bmad-brainstorming) | 워크플로 | 대화형 브레인스토밍 세션 진행 |
| [`bmad-party-mode`](#bmad-party-mode) | 워크플로 | 다중 에이전트 그룹 토론 조율 |
| [`bmad-forge-idea`](#bmad-forge-idea) | 워크플로 | 아이디어를 단련하고, 입증하거나, 저렴하게 폐기할 때까지 압박 검증 |
| [`bmad-spec`](#bmad-spec) | 워크플로 | 모든 의도 입력을 후속 작업의 표준 계약인 SPEC 커널과 동반 파일로 정제 |
| [`bmad-advanced-elicitation`](#bmad-advanced-elicitation) | 작업 | LLM 출력을 반복 개선 방식으로 끌어올림 |
| [`bmad-review-adversarial-general`](#bmad-review-adversarial-general) | 작업 | 빠진 것과 틀린 것을 찾는 비판적 리뷰 |
@ -70,7 +71,7 @@ IDE에서 스킬 이름(예: `bmad-help`)을 입력해 어떤 핵심 도구든
**입력:** 브레인스토밍 주제 또는 문제 설명, 선택 사항 컨텍스트 파일
**출력:** 생성된 모든 아이디어가 담긴 `brainstorming-session-{date}.md`
**출력:** 세션 기념본인 독립 `brainstorm.html`, 후속 스킬용 선택적 `brainstorm-intent.md`, 그리고 `.memlog.md` 세션 기록
:::note[수량 목표]
핵심은 아이디어 50-100개 지점에서 나옵니다. 이 워크플로는 정리 전에 100개 이상의 아이디어 생성을 권장합니다.
@ -98,6 +99,28 @@ IDE에서 스킬 이름(예: `bmad-help`)을 입력해 어떤 핵심 도구든
**출력:** 에이전트 페르소나가 유지되는 실시간 다중 에이전트 대화
## bmad-forge-idea
**아이디어를 단련하고, 입증하거나, 저렴하게 폐기할 때까지 압박 검증합니다.** 적대적인 질문자가 반쯤 형성된 아이디어를 한 번에 하나의 질문으로 몰아붙입니다. 각 갈래마다 두 인물을 데려오며, 살아남은 것이 확신을 갖고 행동할 수 있는 것이 될 때까지 진행합니다.
**사용 시점:**
- 투자하기 전에 아이디어를 스트레스 테스트하고 싶습니다
- 아이디어를 죽일지 말지에 대한 정직한 판단이 필요합니다
- 동의만 하는 상대가 아니라 반박하는 사고 파트너가 필요합니다
**작동 방식:**
1. 먼저 목표를 정하고 그 목표에 맞춰 질문 방향을 조정합니다
2. 의존성 순서에 따라 한 번에 하나의 질문을 다루며, 사용자가 반박할 수 있도록 권장 답을 제시합니다
3. 각 갈래마다 두 목소리를 데려옵니다. 하나는 설치된 명단에서, 하나는 주제가 즉석에서 불러낸 인물입니다
4. 흐릿한 용어를 공격하고 기존 프로젝트 자료와 주장을 대조합니다
5. 단련됨, 폐기됨, 명확해짐 중 하나로 도착하며, 보관 가능한 독립 보고서를 남깁니다
**입력:** 기능, 비즈니스 모델, 연구 가설, 개인적 결정 등 어떤 도메인의 아이디어든 가능
**출력:** 아이디어가 단련되면 선택적으로 `forged-idea.md` 정제본, 모든 실행마다 `forge-report.html` 기념본
## bmad-spec
**모든 의도 입력을 후속 작업의 표준 SPEC 계약으로 정제합니다.** 간단한 아이디어, PRD, GDD, RFC, 브레인 덤프, 회의록, UX 폴더, 여러 소스가 섞인 입력을 받아 다섯 필드 커널(Why, Capabilities, Constraints, Non-goals, Success signal)을 담은 `SPEC.md`와 커널에 들어가지 않는 핵심 내용을 위한 동반 파일을 만듭니다.
@ -113,7 +136,7 @@ IDE에서 스킬 이름(예: `bmad-help`)을 입력해 어떤 핵심 도구든
1. 입력과 연결된 보조 자료를 읽습니다.
2. 설정 가능한 템플릿으로 다섯 필드 커널을 정제하고, 넘치는 내용은 적절한 이름의 동반 파일로 보냅니다.
3. 두 단계 자체 검증을 실행합니다. 먼저 일관성 규칙을 확인하고, 다음으로 모든 핵심 소스 주장이 보존됐는지 확인합니다.
4. `{output_folder}/specs/spec-{slug}/` 아래에 `SPEC.md`, 동반 파일, `.decision-log.md`를 씁니다.
4. `{output_folder}/specs/spec-{slug}/` 아래에 `SPEC.md`, 동반 파일, `.memlog.md`를 씁니다.
Spec Law는 여덟 가지 규칙을 강제합니다. capabilities는 의도와 성공 기준을 모두 담고, intents는 HOW가 아니라 WHAT이며, constraints는 실제 의사결정에 영향을 주고, non-goals는 명시적이며, success signals는 구체적이고, capability ID는 안정적이며, 모든 핵심 소스 주장은 보존되고, 문장은 간결해야 합니다.
@ -123,7 +146,7 @@ Spec Law는 여덟 가지 규칙을 강제합니다. capabilities는 의도와
- `slug`(선택 사항) - 입력이 빈약하고 소스 파일명에서 slug를 만들 수 없을 때만 필요합니다.
- `target_spec_path`(선택 사항) - 새 spec을 만드는 대신 기존 spec을 업데이트할 때 설정합니다.
**출력:** `SPEC.md`, 동반 파일, `.decision-log.md`가 들어 있는 spec 폴더. Headless 호출자는 결과 상태와 작성 또는 수정된 파일 목록을 담은 JSON 응답을 받습니다.
**출력:** `SPEC.md`, 동반 파일, `.memlog.md`가 들어 있는 spec 폴더. Headless 호출자는 결과 상태와 작성 또는 수정된 파일 목록을 담은 JSON 응답을 받습니다.
:::note[변경 계약]
`bmad-spec`은 `SPEC.md`와 spec이 작성한 동반 파일을 쓸 수 있는 유일한 도구입니다. 다른 스킬은 자체 네이티브 산출물을 만들고, 의도를 표준 계약으로 표현하거나 업데이트를 제안해야 할 때 headless 모드로 `bmad-spec`을 호출합니다.

17
docs/ko-kr/reference/workflow-map.md
View File

@ -25,10 +25,11 @@ BMad Method(BMM)는 BMad 생태계의 모듈이며 컨텍스트 엔지니어링
| 워크플로 | 목적 | 산출물 |
| --- | --- | --- |
| `bmad-brainstorming` | 브레인스토밍 코치의 안내를 받아 프로젝트 아이디어를 발산합니다 | `brainstorming-report.md` |
| `bmad-brainstorming` | 브레인스토밍 코치의 안내를 받아 프로젝트 아이디어를 발산합니다 | `brainstorm.html` 기념본과 선택적 `brainstorm-intent.md` |
| `bmad-forge-idea` | 아이디어를 단련하고, 입증하거나, 저렴하게 폐기할 때까지 압박 검증합니다 | 매 실행마다 `forge-report.html`; 아이디어가 단련되면 `forged-idea.md` |
| `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | 시장, 기술, 도메인 가정을 검증합니다 | 연구 발견 사항 |
| `bmad-product-brief` | 전략적 비전을 포착합니다. 개념이 명확할 때 가장 좋습니다 | `product-brief.md` |
| `bmad-prfaq` | 워킹 백워드 방식으로 제품 개념을 스트레스 테스트하고 다듬습니다 | `prfaq-{project}.md` |
| `bmad-product-brief` | 전략적 비전을 포착합니다. 개념이 명확할 때 가장 좋습니다 | `brief.md` + `addendum.md`, 필요한 HTML 또는 프레젠테이션 출력 |
| `bmad-prfaq` | 워킹 백워드 방식으로 제품 개념을 고객 우선 관점에서 스트레스 테스트합니다 | `prfaq-{project}.md` |
## 단계 2: 계획
@ -36,13 +37,13 @@ BMad Method(BMM)는 BMad 생태계의 모듈이며 컨텍스트 엔지니어링
| 워크플로 | 목적 | 산출물 |
| --- | --- | --- |
| `bmad-prd` | PRD를 생성, 업데이트, 검증합니다. 안내형 발견 과정과 세 가지 의도를 하나의 스킬에 담았습니다 | 생성/업데이트: `prd.md`, `addendum.md`, `decision-log.md`; 검증: `validation-report.html` + `.md` |
| `bmad-ux` | UX가 중요할 때 사용자 경험을 설계합니다. DESIGN.md(시각)와 EXPERIENCE.md(동작)라는 두 핵심 문서를 만듭니다 | `DESIGN.md`, `EXPERIENCE.md`, `.decision-log.md` |
| `bmad-prd` | PRD를 생성, 업데이트, 검증합니다. 안내형 발견 과정과 세 가지 의도를 하나의 스킬에 담았습니다 | 생성/업데이트: `prd.md`, `addendum.md`, `.memlog.md`; 검증: `validation-report.html` + `.md` |
| `bmad-ux` | UX가 중요할 때 사용자 경험을 설계합니다. DESIGN.md(시각)와 EXPERIENCE.md(동작)라는 두 핵심 문서를 만듭니다 | `DESIGN.md`, `EXPERIENCE.md`, `.memlog.md` |
:::tip[하나의 스킬 안에 세 의도]
`bmad-prd`는 전체 PRD 수명주기를 처리합니다. 호출할 때 의도를 말하거나 스킬이 물어보게 하세요.
- **생성** - 안내형 발견 과정을 통해 처음부터 새 PRD를 만듭니다. `prd.md`, `addendum.md`, `decision-log.md`를 생성합니다
- **생성** - 안내형 발견 과정을 통해 처음부터 새 PRD를 만듭니다. `prd.md`, `addendum.md`, `.memlog.md`를 생성합니다
- **업데이트** - 기존 PRD와 변경 신호를 조정하고, 변경을 적용하기 전에 충돌을 식별합니다
- **검증** - 설정 가능한 체크리스트로 PRD를 비판적으로 검토하고 구조화된 HTML 발견 사항 보고서를 생성합니다
:::
@ -57,13 +58,13 @@ BMad Method(BMM)는 BMad 생태계의 모듈이며 컨텍스트 엔지니어링
| 워크플로 | 목적 | 산출물 |
| --- | --- | --- |
| `bmad-create-architecture` | 기술적 결정을 명시적으로 만듭니다 | ADR이 있는 `architecture.md` |
| `bmad-architecture` | 기술적 결정을 명시적으로 만듭니다 | 기본 핵심 문서는 `ARCHITECTURE-SPINE.md`이며, 원하는 출력이나 프레젠테이션 요구에 맞게 확장할 수 있습니다 |
| `bmad-create-epics-and-stories` | 요구사항을 구현 가능한 작업으로 나눕니다 | 스토리가 있는 에픽 파일 |
| `bmad-check-implementation-readiness` | 구현 전 관문 점검 | 통과/우려/실패 결정 |
## 단계 4: 구현
스토리 하나씩 구현합니다. 전체 4단계 자동화는 곧 제공됩니다.
스토리 하나씩 구현합니다. 4단계 에픽 및 스토리 자동화도 이제 사용할 수 있습니다. 사용자는 흐름에 어떻게 참여할지 선택할 수 있습니다. 전체 흐름을 사용할 수도 있고, 빠른 흐름으로 바로 갈 수도 있습니다.
| 워크플로 | 목적 | 산출물 |
| --- | --- | --- |

13
docs/ko-kr/tutorials/getting-started.md
View File

@ -69,10 +69,10 @@ BMad는 전문 AI 에이전트가 있는 안내형 워크플로를 통해 소프
| 단계 | 이름 | 일어나는 일 |
| --- | --- | --- |
| 1 | 분석 | 브레인스토밍, 리서치, 제품 개요 또는 PRFAQ *(선택)* |
| 2 | 계획 | 요구사항 작성(PRD 또는 사양) |
| 3 | 솔루션 설계 | 아키텍처 설계 *(BMad Method/엔터프라이즈 전용)* |
| 4 | 구현 | 에픽별, 스토리별 구현 |
| 1 | 분석 | 브레인스토밍, 리서치, 아이디어 단련, 제품 개요 또는 PRFAQ *(선택)* |
| 2 | 계획 | PRD, UX, SPEC으로 요구사항과 설계를 작성 |
| 3 | 솔루션 설계 | 아키텍처 핵심 문서 또는 상세 프로젝트/시스템 아키텍처 설계 |
| 4 | 구현 | 빠른 개발 또는 자동화된 에픽 전달로 에픽별, 스토리별 구현 |
단계, 워크플로, 컨텍스트 관리를 살펴보려면 **[워크플로 맵 열기](../reference/workflow-map.md)**를 확인하세요.
@ -138,16 +138,17 @@ BMad 도움말이 완료된 작업을 감지하고 정확한 다음 단계를
이 단계의 모든 워크플로는 선택 사항입니다. [**무엇을 써야 할지 모르겠나요?**](../explanation/analysis-phase.md)
- **브레인스토밍**(`bmad-brainstorming`) - 안내형 아이디어 발산
- **아이디어 단련**(`bmad-forge-idea`) - 아이디어가 단단해지거나 저렴하게 죽을 때까지 압박 검증
- **리서치**(`bmad-market-research` / `bmad-domain-research` / `bmad-technical-research`) - 시장, 도메인, 기술 리서치
- **제품 개요**(`bmad-product-brief`) - 개념이 명확할 때 권장되는 기초 문서
- **PRFAQ**(`bmad-prfaq`) - 제품 개념을 압박하고 다듬는 워킹 백워드 챌린지
- **PRFAQ**(`bmad-prfaq`) - 제품 개념을 고객 우선 관점에서 스트레스 테스트하는 워킹 백워드 챌린지
### 2단계: 계획(필수)
**BMad Method 및 엔터프라이즈 트랙:**
1. 새 채팅에서 `bmad-prd`를 실행합니다. 의도(생성, 업데이트, 검증)를 직접 말하거나 스킬이 묻게 둡니다
2. 출력: `prd.md`, `addendum.md`, `decision-log.md`
2. 출력: `prd.md`, `addendum.md`, `.memlog.md`
:::note[`bmad-prd` 의도]
- **생성** - 처음부터 코칭형 발견 과정을 진행합니다. 스킬이 워크스페이스 폴더 이름을 정하고 만족할 만한 PRD까지 안내합니다