Merge 3970ace793 into 6ac4c26b69

docs/ko-kr/explanation/forge-idea.md

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

docs/ko-kr/explanation/party-mode.md

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

docs/ko-kr/how-to/customize-bmad.md

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

docs/ko-kr/how-to/pressure-test-an-idea.md

@@ -1,55 +0,0 @@
----
-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[아이디어가 폐기되게 두세요]
-아이디어가 버티지 못한다는 사실을 적은 비용으로 알아내는 것이 이득입니다. 세션을 "예"로 유도하지 마세요.
-:::

docs/ko-kr/reference/core-tools.md

@@ -18,7 +18,6 @@ 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) | 작업 | 빠진 것과 틀린 것을 찾는 비판적 리뷰 |
@@ -71,7 +70,7 @@ IDE에서 스킬 이름(예: `bmad-help`)을 입력해 어떤 핵심 도구든
 
 **입력:** 브레인스토밍 주제 또는 문제 설명, 선택 사항 컨텍스트 파일
 
-**출력:** 세션 보관용 독립 `brainstorm.html`, 후속 스킬용 선택적 `brainstorm-intent.md`, 그리고 `.memlog.md` 세션 기록
+**출력:** 생성된 모든 아이디어가 담긴 `brainstorming-session-{date}.md`
 
 :::note[수량 목표]
 핵심은 아이디어 50-100개 지점에서 나옵니다. 이 워크플로는 정리 전에 100개 이상의 아이디어 생성을 권장합니다.
@@ -99,28 +98,6 @@ 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`와 커널에 들어가지 않는 핵심 내용을 위한 동반 파일을 만듭니다.
@@ -136,17 +113,17 @@ IDE에서 스킬 이름(예: `bmad-help`)을 입력해 어떤 핵심 도구든
 1. 입력과 연결된 보조 자료를 읽습니다.
 2. 설정 가능한 템플릿으로 다섯 필드 커널을 정제하고, 넘치는 내용은 적절한 이름의 동반 파일로 보냅니다.
 3. 두 단계 자체 검증을 실행합니다. 먼저 일관성 규칙을 확인하고, 다음으로 모든 핵심 소스 주장이 보존됐는지 확인합니다.
-4. `{output_folder}/specs/spec-{slug}/` 아래에 `SPEC.md`, 동반 파일, `.memlog.md`를 씁니다.
+4. `{output_folder}/specs/spec-{slug}/` 아래에 `SPEC.md`, 동반 파일, `.decision-log.md`를 씁니다.
 
 Spec Law는 여덟 가지 규칙을 강제합니다. capabilities는 의도와 성공 기준을 모두 담고, intents는 HOW가 아니라 WHAT이며, constraints는 실제 의사결정에 영향을 주고, non-goals는 명시적이며, success signals는 구체적이고, capability ID는 안정적이며, 모든 핵심 소스 주장은 보존되고, 문장은 간결해야 합니다.
 
 **입력:**
 
-- `input`(필수) - 경로 또는 인라인 텍스트. 모호한 아이디어, 브레인 덤프, PRD, GDD, RFC, 제품 브리프, 대화록, 목업 폴더, 여러 소스 조합.
+- `input`(필수) - 경로 또는 인라인 텍스트. 모호한 아이디어, 브레인 덤프, PRD, GDD, RFC, brief, transcript, mockup 폴더, 여러 소스 조합.
 - `slug`(선택 사항) - 입력이 빈약하고 소스 파일명에서 slug를 만들 수 없을 때만 필요합니다.
 - `target_spec_path`(선택 사항) - 새 spec을 만드는 대신 기존 spec을 업데이트할 때 설정합니다.
 
-**출력:** `SPEC.md`, 동반 파일, `.memlog.md`가 들어 있는 spec 폴더. Headless 호출자는 결과 상태와 작성 또는 수정된 파일 목록을 담은 JSON 응답을 받습니다.
+**출력:** `SPEC.md`, 동반 파일, `.decision-log.md`가 들어 있는 spec 폴더. Headless 호출자는 결과 상태와 작성 또는 수정된 파일 목록을 담은 JSON 응답을 받습니다.
 
 :::note[변경 계약]
 `bmad-spec`은 `SPEC.md`와 spec이 작성한 동반 파일을 쓸 수 있는 유일한 도구입니다. 다른 스킬은 자체 네이티브 산출물을 만들고, 의도를 표준 계약으로 표현하거나 업데이트를 제안해야 할 때 headless 모드로 `bmad-spec`을 호출합니다.
@@ -263,7 +240,7 @@ Spec Law는 여덟 가지 규칙을 강제합니다. capabilities는 의도와
 
 **작동 방식:**
 
-1. 5개 구조 모델(튜토리얼, 참조, 설명, 프롬프트, 전략)로 문서를 분석합니다
+1. 5개 구조 모델(튜토리얼, 참조, 설명, 프롬프트, 전략)에 대해 문서를 분석합니다
 2. 중복, 범위 위반, 묻힌 정보를 식별합니다
 3. 우선순위 권장 사항을 생성합니다: `CUT`, `MERGE`, `MOVE`, `CONDENSE`, `QUESTION`, `PRESERVE`
 4. 총 단어 감소량과 감소율을 추정합니다

docs/ko-kr/reference/workflow-map.md

@@ -11,7 +11,7 @@ BMad Method(BMM)는 BMad 생태계의 모듈이며 컨텍스트 엔지니어링
 
 언제든 무엇을 해야 할지 확실하지 않다면 `bmad-help` 스킬이 흐름을 잡아 주고 다음 단계를 알려줍니다. 이 문서를 참조로 사용할 수도 있지만, 이미 BMad Method를 설치했다면 `bmad-help`가 더 대화형이고 훨씬 빠릅니다. 또한 BMad Method를 확장한 다른 모듈이나 함께 쓰는 보완 모듈을 사용한다면 `bmad-help`도 사용 가능한 항목을 모두 파악해 현재 상황에 가장 적절한 조언을 제공합니다.
 
-마지막으로 중요한 점: 아래 모든 워크플로는 스킬로 직접 실행해도 되고, 먼저 에이전트를 로드한 뒤 에이전트 메뉴 항목을 사용해 원하는 도구에서 실행해도 됩니다.
+마지막으로 중요한 점: 아래 모든 워크플로는 스킬로 직접 실행하거나, 먼저 에이전트를 로드한 뒤 에이전트 메뉴 항목을 사용해 원하는 도구에서 실행할 수 있습니다.
 
 <iframe src="/workflow-map-diagram-ko.html" title="BMad Method 워크플로 맵 다이어그램" width="100%" height="100%" style="border-radius: 8px; border: 1px solid #334155; min-height: 900px;"></iframe>
 
@@ -25,11 +25,10 @@ BMad Method(BMM)는 BMad 생태계의 모듈이며 컨텍스트 엔지니어링
 
 | 워크플로 | 목적 | 산출물 |
 | --- | --- | --- |
-| `bmad-brainstorming` | 브레인스토밍 코치의 안내를 받아 프로젝트 아이디어를 발산합니다 | `brainstorm.html` 보관본과 선택적 `brainstorm-intent.md` |
+| `bmad-brainstorming` | 브레인스토밍 코치의 안내를 받아 프로젝트 아이디어를 발산합니다 | `brainstorming-report.md` |
-| `bmad-forge-idea` | 아이디어를 단련하고, 입증하거나, 적은 비용으로 폐기할 때까지 압박 검증합니다 | 매 실행마다 `forge-report.html`; 아이디어가 단련되면 `forged-idea.md` |
 | `bmad-domain-research`, `bmad-market-research`, `bmad-technical-research` | 시장, 기술, 도메인 가정을 검증합니다 | 연구 발견 사항 |
-| `bmad-product-brief` | 전략적 비전을 포착합니다. 개념이 명확할 때 가장 좋습니다 | `brief.md` + `addendum.md`, 필요한 HTML 또는 프레젠테이션 출력 |
+| `bmad-product-brief` | 전략적 비전을 포착합니다. 개념이 명확할 때 가장 좋습니다 | `product-brief.md` |
-| `bmad-prfaq` | 워킹 백워드 방식으로 제품 개념을 고객 우선 관점에서 스트레스 테스트합니다 | `prfaq-{project}.md` |
+| `bmad-prfaq` | 워킹 백워드 방식으로 제품 개념을 스트레스 테스트하고 다듬습니다 | `prfaq-{project}.md` |
 
 ## 단계 2: 계획
 
@@ -37,13 +36,13 @@ BMad Method(BMM)는 BMad 생태계의 모듈이며 컨텍스트 엔지니어링
 
 | 워크플로 | 목적 | 산출물 |
 | --- | --- | --- |
-| `bmad-prd` | PRD를 생성, 업데이트, 검증합니다. 안내형 발견 과정과 세 가지 의도를 하나의 스킬에 담았습니다 | 생성/업데이트: `prd.md`, `addendum.md`, `.memlog.md`; 검증: `validation-report.html` + `.md` |
+| `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`, `.memlog.md` |
+| `bmad-ux` | UX가 중요할 때 사용자 경험을 설계합니다. DESIGN.md(시각)와 EXPERIENCE.md(동작)라는 두 핵심 문서를 만듭니다 | `DESIGN.md`, `EXPERIENCE.md`, `.decision-log.md` |
 
 :::tip[하나의 스킬 안에 세 의도]
 `bmad-prd`는 전체 PRD 수명주기를 처리합니다. 호출할 때 의도를 말하거나 스킬이 물어보게 하세요.
 
-- **생성** - 안내형 발견 과정으로 처음부터 새 PRD를 만듭니다. `prd.md`, `addendum.md`, `.memlog.md`를 생성합니다
+- **생성** - 안내형 발견 과정을 통해 처음부터 새 PRD를 만듭니다. `prd.md`, `addendum.md`, `decision-log.md`를 생성합니다
 - **업데이트** - 기존 PRD와 변경 신호를 조정하고, 변경을 적용하기 전에 충돌을 식별합니다
 - **검증** - 설정 가능한 체크리스트로 PRD를 비판적으로 검토하고 구조화된 HTML 발견 사항 보고서를 생성합니다
 :::
@@ -58,13 +57,13 @@ BMad Method(BMM)는 BMad 생태계의 모듈이며 컨텍스트 엔지니어링
 
 | 워크플로 | 목적 | 산출물 |
 | --- | --- | --- |
-| `bmad-architecture` | 기술적 결정을 명시적으로 만듭니다 | 기본 핵심 문서는 `ARCHITECTURE-SPINE.md`이며, 필요한 출력이나 프레젠테이션 형태로 확장해 씁니다 |
+| `bmad-create-architecture` | 기술적 결정을 명시적으로 만듭니다 | ADR이 있는 `architecture.md` |
 | `bmad-create-epics-and-stories` | 요구사항을 구현 가능한 작업으로 나눕니다 | 스토리가 있는 에픽 파일 |
 | `bmad-check-implementation-readiness` | 구현 전 관문 점검 | 통과/우려/실패 결정 |
 
 ## 단계 4: 구현
 
-스토리 하나씩 구현합니다. 4단계 에픽 및 스토리 자동화도 이제 지원합니다. 사용자는 흐름에 얼마나 개입할지 고르면 됩니다. 전체 흐름을 타도 되고, 빠른 흐름으로 바로 넘어가도 됩니다.
+스토리 하나씩 구현합니다. 전체 4단계 자동화는 곧 제공됩니다.
 
 | 워크플로 | 목적 | 산출물 |
 | --- | --- | --- |

docs/ko-kr/tutorials/getting-started.md

@@ -69,10 +69,10 @@ BMad는 전문 AI 에이전트가 있는 안내형 워크플로를 통해 소프
 
 | 단계 | 이름 | 일어나는 일 |
 | --- | --- | --- |
-| 1 | 분석 | 브레인스토밍, 리서치, 아이디어 단련, 제품 개요 또는 PRFAQ *(선택)* |
+| 1 | 분석 | 브레인스토밍, 리서치, 제품 개요 또는 PRFAQ *(선택)* |
-| 2 | 계획 | PRD, UX, SPEC으로 요구사항과 설계를 작성 |
+| 2 | 계획 | 요구사항 작성(PRD 또는 사양) |
-| 3 | 솔루션 설계 | 아키텍처 핵심 문서 또는 상세 프로젝트/시스템 아키텍처 설계 |
+| 3 | 솔루션 설계 | 아키텍처 설계 *(BMad Method/엔터프라이즈 전용)* |
-| 4 | 구현 | 빠른 개발 또는 자동화된 에픽 전달로 에픽별, 스토리별 구현 |
+| 4 | 구현 | 에픽별, 스토리별 구현 |
 
 단계, 워크플로, 컨텍스트 관리를 살펴보려면 **[워크플로 맵 열기](../reference/workflow-map.md)**를 확인하세요.
 
@@ -138,17 +138,16 @@ 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`, `.memlog.md`
+2. 출력: `prd.md`, `addendum.md`, `decision-log.md`
 
 :::note[`bmad-prd` 의도]
 - **생성** - 처음부터 코칭형 발견 과정을 진행합니다. 스킬이 워크스페이스 폴더 이름을 정하고 만족할 만한 PRD까지 안내합니다