BMad: 의도-전달 제어 평면 프로토콜
BMad는 한 가지 아이디어에 기반한 소프트웨어 전달 방법론입니다: 인간의 의도는 대화에서 즉흥적으로 처리하기보다는 점진적으로 명확히 하고, 기록하고, 검토하여 에이전트에 지속 가능한 컨텍스트로 전달되어야 합니다. 이 스킬은 해당 방법론을 모든 에이전트 하네스가 따를 수 있는 프로토콜로 변환합니다. 공식 BMad 설치 프로그램이 필요하지 않습니다.
루프: 분류 요청 → 압축 의도를 계약으로 → 라우팅 최소 안전 경로로 → 구현 하나의 제한된 단위 → 검토 트라이지 방식으로 → 실패 라우팅 모호성이 유입된 계층으로 → 자율성 게이트 관찰 가능한 수용에 따라 → 학습 완료된 작업으로부터.
이 스킬을 사용해야 하는 경우
변경 요청, 기능, 버그 보고서, 위임된 빌드 또는 다중 에이전트 에픽에 다음이 필요할 때 로드하세요:
- 구현 전 의도 포착 — 계약, 분위기가 아닌;
- 작업에 필요한 의례 수준에 대한 결정;
- 작업이 세션이나 에이전트 간에 재개 가능하도록 하는 내구성 있는 아티팩트;
- 노이즈를 나열하는 대신 발견 사항을 트라이지하는 검토;
- 경계가 안전하지 않을 때 안전하게 중단되는 자율성.
작업 분류 (최소 안전 경로)
| 분류 | 형태 | 프로세스 |
|---|---|---|
| 직접(Direct) | 명확한 목표, 로컬 변경, 확립된 패턴, 작은 영향 범위 | 최소한의 명확화 후 즉시 구현 |
| 제한적(Bounded) | 짧은 계약과 계획이 필요한 일관된 변경 | 의도 계약 → 계획 → 구현 → 검토 |
| 주도적(Initiative) | 구성 요소 간, 여러 스토리, 고위험 또는 전략적으로 불확실함 | 분석 → 계획 → 솔루션 구축 → 구현 → 학습 |
references/classification.md를 로드하여 결정 테이블, 한 질문 규칙 및 중단 조건을 확인하세요.
의도 계약 (5개 필드)
제한적 또는 주도적 작업의 경우 구현 전에 계약을 수립하세요:
- 이유(Why) — 결과와 그 중요성.
- 역량(Capabilities) — 시스템이 수행할 수 있어야 하는 것.
- 제약(Constraints) — 기술적, 운영적, 법적, 보안, 개인정보 보호, 시간, 비용, 조직 경계.
- 비목표(Non-goals) — 명시적으로 범위 외인 것.
- 성공 신호(Success signal) — 결과가 작동하고 수용 가능함을 어떻게 알 수 있는지.
필드가 실질적으로 모호한 경우, 하나의 영향력 높은 질문을 하고, 권장 답변을 제안하며, 결정을 기다리세요. 사소한 변경의 경우 계약은 대화 중 다섯 개의 불릿으로 충분합니다. 더 큰 작업의 경우 버전 관리된 명세 파일이 됩니다.
references/spec.md를 로드하여 SPEC 작성 및 상태 어휘를 확인하세요. 템플릿: templates/SPEC.md 및 templates/INTENT.md.
표준 루프
- 질문하기 전에 저장소와 사용 가능한 컨텍스트를 검사합니다.
- 작업을 분류하고 제안된 경로를 명시합니다.
- 의도 계약을 수립하거나 재개하고, 최대 하나의 실질적인 질문을 합니다.
- 중요하지 않은 작업의 경우 계획을 제시하고 승인 체크포인트에서 기다립니다.
- 가장 작은 일관된 변경을 구현하고, 먼저 집중된 테스트를 실행한 다음 더 넓은 검사를 수행합니다.
- 정확성, 범위, 보안, 회귀, 유지보수성을 검토합니다.
- 이 변경에 속하는 발견 사항을 수정하고, 관련 없는 발견 사항은 명시적으로 연기합니다.
- 의도, 동작, 파일, 위험, 검증, 발견 사항 처리 및 수락/재작업/조사 선택을 보고합니다.
SPEC 상태 어휘
재개 가능한 작업을 위한 기계 판독 가능 상태:
| 상태 | 의미 |
|---|---|
draft | SPEC이 존재하지만 준비되지 않음 |
ready-for-dev | 준비 완료됨, 구현 가능 |
in-progress | 구현 진행 중 |
in-review | 검토 또는 트라이지 진행 중 |
done | 워크플로우 성공적으로 완료됨 |
blocked | 안전하게 계속 진행할 수 없음 |
blocked는 라우팅 신호이지 실패가 아닙니다: 상위 수준 오케스트레이터, 다른 워크플로우 또는 사람이 인수합니다. scripts/check-spec.py로 SPEC을 결정론적으로 검증하세요.
실패 라우팅
문제가 있을 때, 실패가 유입된 계층을 진단하세요:
| 실패 | 라우팅 |
|---|---|
| 잘못된 결과 또는 잘못된 문제 | 의도 / 분석 |
| 누락되거나 모순된 요구 사항 | 계약 / 계획 |
| 충돌하는 기술적 접근 방식 | 아키텍처 |
| 부정확한 로컬 코드 | 구현 |
| 불충분한 테스트 또는 평가 | 검증 |
| 관련 없는 기존 문제 | 명시적으로 연기 |
| 안전하지 않은 모호성 | 차단 및 요청 |
명세가 실제 문제일 때 계속해서 코드를 패치하지 마세요.
자율성 게이트
자율적 실행은 다음 모든 조건이 충족될 때만 허용됩니다: 의도 계약이 일관되고, 수용이 관찰 가능하며, 경계가 명시적이고, 저장소를 안전하게 수정할 수 있으며, 테스트 또는 평가를 실행할 수 있고, 내구성 있는 상태를 기록할 수 있으며, 에스컬레이션이 정의되어 있습니다. 자율 작업 중: 한 번에 하나의 일관된 변경; 관련 없는 개선으로 범위를 절대 확장하지 않음; 승인 없이 병합, 배포 또는 외부 시스템을 변경하지 않음; 의도 차이, 누락된 역량, 파괴적 모호성, 검증 실패 또는 수렴하지 않는 수정 시 중단.
참조 파일
| 참조 | 로드해야 하는 경우 |
|---|---|
| references/protocol.md | 에이전트를 위한 전체 붙여넣기 준비 운영 프로토콜이 필요할 때 |
| references/classification.md | 요청 분류 또는 의례 깊이 선택 시 |
| references/spec.md | SPEC/의도 계약 작성 또는 재개 시 |
| references/lifecycle.md | 이니셔티브를 4단계를 통해 실행할 때 |
| references/project-context.md | 저장소 규칙 설정 또는 감사 시 (AGENTS.md) |
| references/review-and-failure-routing.md | 검토 실행 또는 실패 진단 시 |
| references/autonomy.md | 자율 작업 구성 또는 실행 시 (Build Auto) |
| references/party-mode.md | 숙고, 트레이드오프, 설계 논쟁, 사후 분석 시 |
| references/adoption.md | 프로토콜을 점진적으로 도입하거나 다크 팩토리에 매핑할 때 |
템플릿
| 템플릿 | 목적 |
|---|---|
| templates/SPEC.md | 제한적/주도적 작업을 위한 버전 관리된 기계 계약 |
| templates/INTENT.md | 제한적 작업을 위한 가벼운 5필드 계약 |
| templates/STORY.md | 하나의 제한적이고 디스패치 가능한 작업 단위 |
| templates/REVIEW.md | 최종 인간 체크포인트: 의도 → 동작 → 위험 → 검증 |
스크립트
| 스크립트 | 실행 시점 |
|---|---|
| scripts/check-spec.py | SPEC 작성 또는 편집 후: 5개 필드 + 상태 어휘 검증 (표준 라이브러리 전용, --json 출력) |
인접 스킬로 라우팅
- 상류 (BMad 이전):
product-discovery는 문제가 실제인지 검증합니다;product-shaping은 식욕을 설정하고 피치를 생성합니다;product-strategy및product-roadmapping-and-portfolio는 전략적 컨텍스트를 구성합니다. - 하류 (BMad 중):
spec-driven-development는 공식 명세/게이트 파이프라인용;implementation-planning은 의존성 인식 전달 계획용;adr-authoring은 아키텍처 결정용;software-architecture-analysis는 기존 코드베이스 역공학용. - 실행 및 게이트:
neckbeard는 이슈-투-PR 전달 흐름용;verification-methodology는 수용 증거용;qa-methodology는 테스트 전략용;agent-evals-and-observability는 독립 평가자용;agent-council는 파티 모드 스타일의 다중 에이전트 숙고용;release-engineering은 배포 게이트용;kanban-guru는 백로그 및 디스패치 정책용.
사용하지 말아야 하는 경우
- 문제 자체가 검증되지 않음 →
product-discovery. BMad는 의도를 압축합니다. 문제가 실제인지 확인하지 않습니다. - 작업의 가치에 대한 결정이 없음 → 먼저
product-shaping(식욕, 피치, 베팅). BMad는 배치된 의도에서 시작합니다. - 공식 명세 형식과 단계 게이트를 공장 파이프라인으로 사용해야 함 →
spec-driven-development가 SPEC 형식과 게이트 메커니즘을 소유합니다. BMad는 그 주변의 제어 평면 프로토콜을 제공합니다. - 자체 게이트가 있는 이슈-투-PR 전달 흐름을 실행 중 →
neckbeard. BMad는 이를 보완합니다. 두 개의 경쟁 전달 라이프사이클을 실행하지 마십시오. - 독립적 검토가 필요함 → 역할극은 독립성이 아닙니다.
agent-council, 별도 평가자 또는agent-evals-and-observability를 사용하세요. 페르소나 분리를 독립적 검토라고 주장하지 마십시오. - 공식 BMad 설치 프로그램/도구 사용 → 이 스킬은 방법을 에뮬레이션합니다. bmad-method npm 패키지를 설치하거나 운영하지 않습니다.
버전 변동 및 귀속
BMad는 활발히 진화 중입니다 (공식 저장소: bmadcode/bmad-method; BMAD™ 및 BMAD-METHOD™는 BMad Code, LLC의 상표입니다). 이전 기사는 이름 확장, 에이전트, 파일 이름 및 명령어에 대해 다릅니다. 공식 도구를 설치할 때는 공식 문서와 설치된 소스를 권위 있는 것으로 취급하십시오. 이 스킬은 방법론을 하네스 독립적 프로토콜로 독창적으로 정제한 것이며, 공식 설치 프로그램 콘텐츠를 복제하지 않습니다.