BMAD Method 튜토리얼 9편: 우리 팀 방식에 맞게 BMAD 바꾸고 확장하는 법

요약#

참고 자료#

• BMAD Method - How to Customize BMad - .customize.yaml을 통한 안전한 커스터마이징
• BMAD Method - Official Modules - 공식 확장 모듈 목록
• BMAD Method - Testing Options - Quinn과 TEA의 역할 차이
• BMAD Method - Non-Interactive Installation - 모듈 코드와 재설치 옵션

바로 써먹는 템플릿#

9편은 agent를 새로 쓰는 방법보다 설정을 어떻게 바꾸고 어떤 모듈을 붙일지가 핵심입니다.

확장할 때 자주 쓰는 흐름은 아래처럼 보면 됩니다.

예를 들어 Dev agent의 기억이나 말투를 바꾸고 싶다면 이렇게 시작합니다.

Dev agent customize 파일 예시

1
memories:
2
  - '이 프로젝트에서는 테스트가 통과하지 않으면 완료로 간주하지 않는다'
3
  - '새 API 호출은 반드시 apiClient를 통해서만 만든다'
4

5
critical_actions:
6
  - '작업 시작 전에 관련 story 파일과 project-context.md를 먼저 읽는다'

이런 변경을 적용했다면 다시 설치해서 반영합니다.

커스터마이징 적용 예시

1
npx bmad-method install

테스트 전략을 더 강화하고 싶다면 TEA 모듈도 고려할 수 있습니다.
이때는 같은 설치 명령을 다시 실행한 뒤, 이미 설치된 상태라면 Modify BMad Installation으로 들어가 tea 모듈을 추가하는 방식으로 이해하는 편이 정확합니다.

TEA를 추가하기 위해 설치를 다시 실행하는 예시

1
npx bmad-method install

설치 과정에서 기존 설치가 감지되면 전체 설치 흐름으로 들어가고, 그 안에서 모듈 선택 화면에서 tea를 추가하면 됩니다.

BMad Builder를 추가하는 예시

1
npx bmad-method install --modules bmm,bmb

이 예시는 공식 비대화형 설치 문서에 나온 모듈 코드 방식입니다.
처음부터 비대화형 설치를 쓸 필요는 없지만, 팀 단위로 반복 설치하거나 설정을 스크립트로 관리할 때는 이런 방식이 유용합니다.

왜 agent 파일을 직접 고치면 안 될까요?#

공식 How to Customize BMad 문서는 이 부분을 아주 분명하게 말합니다.
agent 파일을 직접 수정하지 말고, 반드시 .customize.yaml 파일을 사용하라고 안내합니다.

이유는 단순합니다.

• BMAD를 업데이트하면 기본 agent 파일은 다시 생성됩니다
• 직접 수정한 내용은 덮어써질 수 있습니다
• .customize.yaml은 업데이트 뒤에도 살아남도록 설계돼 있습니다

즉 커스터마이징의 핵심은 “어디를 고치느냐”입니다.
같은 수정이라도 올바른 위치에 해야 유지됩니다.

기본 위치는 공식 문서 기준으로 여기입니다.

1
_bmad/_config/agents/
2
├── core-bmad-master.customize.yaml
3
├── bmm-dev.customize.yaml
4
├── bmm-pm.customize.yaml
5
└── ...

즉 agent 하나당 .customize.yaml 파일 하나가 있다고 보면 됩니다.

.customize.yaml에서는 무엇을 바꿀 수 있을까요?#

공식 문서는 커스터마이징 가능한 영역을 꽤 명확하게 나눕니다.

• agent.metadata : agent 이름
• persona : 역할, 정체성, 말투, 원칙
• memories : 항상 기억해야 할 규칙
• menu : 커스텀 메뉴 항목
• critical_actions : 시작할 때 항상 해야 하는 행동
• prompts : 재사용 가능한 프롬프트

여기서 실무적으로 가장 많이 건드리게 되는 것은 보통 세 가지입니다.

적용은 결국 다시 설치해서 반영합니다#

커스터마이징은 파일만 고치고 끝나는 것이 아닙니다.
공식 문서는 변경 후 다시 설치해 반영하라고 설명합니다.

1
npx bmad-method install

이때 기존 설치가 이미 있으면 선택지가 나옵니다.

• Quick Update
• Modify BMad Installation

여기서 차이를 간단히 정리하면 이렇습니다.

• Quick Update: 현재 구성을 유지한 채 빠르게 반영
• Modify BMad Installation: 모듈을 추가하거나 제거하는 전체 흐름

즉 .customize.yaml만 바꿨다면 보통 Quick Update가 가장 빠릅니다.
반대로 새 모듈을 붙이거나 조합을 바꾸고 싶다면 전체 설치 흐름으로 들어가면 됩니다.

공식 모듈은 언제 붙이면 좋을까요?#

공식 Official Modules 문서를 보면 BMAD는 기본 BMM 위에 몇 가지 공식 확장 모듈을 얹을 수 있습니다.

대표적으로는 이렇습니다.

• BMad Builder (bmb)
• Creative Intelligence Suite (cis)
• Game Dev Studio (gds)
• Test Architect (tea)

중요한 건 “모듈이 많으니 다 설치하자”가 아닙니다.
지금 팀에 부족한 기능이 무엇인지 기준으로 붙여야 합니다.

실무적으로는 TEA를 먼저 검토하는 팀이 많습니다#

공식 문서는 모듈별 역할을 설명해 주지만, 어떤 모듈을 먼저 붙여야 하는지까지 정해 주지는 않습니다.
다만 실무적으로는 테스트 전략과 추적성이 가장 먼저 부족해지는 경우가 많아서, TEA를 먼저 검토하는 팀이 많습니다.

이유는 단순합니다.

• 기본 Quinn만으로는 부족한 프로젝트가 실제로 많습니다
• 요구사항 추적, 위험 기반 우선순위, release gate가 필요할 수 있습니다
• 테스트 전략이 중요해질수록 built-in QA만으로는 한계가 드러납니다

공식 Testing Options 문서도 기본값은 Quinn으로 두되,
더 강한 테스트 전략과 추적성이 필요하면 TEA를 붙이라고 설명합니다.

즉 이런 상황이면 tea가 후보입니다.

• 여러 feature를 동시에 굴립니다
• 릴리스 전에 명확한 품질 기준이 필요합니다
• 요구사항과 테스트의 연결을 남겨야 합니다
• 규정 준수나 감사 대응이 중요합니다

반대로 작은 팀, 빠른 제품 개발, 가벼운 테스트 자동화가 목표라면 기본 Quinn으로 충분할 수 있습니다.

공식 Testing Options 문서를 기준으로 보면, TEA를 붙였을 때 기대할 수 있는 기능은 비교적 분명합니다.

• Test Design: 요구사항과 연결된 테스트 전략 문서 만들기
• ATDD: 수용 기준 중심의 테스트 설계
• Automate: 더 고급 패턴으로 테스트 생성하기
• Test Review: 테스트 품질과 커버리지 검토
• Traceability: 요구사항과 테스트를 연결해 추적성 확보
• NFR Assessment: 성능, 보안, 안정성 같은 비기능 요구사항 점검
• CI Setup: 테스트 파이프라인 구성
• Framework Scaffolding: 테스트 구조와 기반 설정
• Release Gate: 지금 릴리스해도 되는지 판단

즉 TEA는 단순히 테스트 개수를 늘리는 모듈이 아니라, 테스트 전략 자체를 한 단계 올리는 모듈에 가깝습니다.

예를 들어 TEA를 붙인 뒤에는, 공식 TEA 문서의 Quick Install 예시처럼 먼저 bmad-tea로 agent/menu를 연 다음 workflow를 고르는 식으로 시작할 수 있습니다.

TEA로 테스트 전략을 요청하는 예시

1
bmad-tea
2
test-design
3

4
이번 승인 기능에 대해 테스트 전략을 만들어줘.
5
요구사항 기준으로 어떤 테스트가 꼭 필요한지 정리하고,
6
P0~P3 우선순위로 나눠서 API, E2E, 비기능 요구사항까지 구분해줘.

TEA로 요구사항 추적성을 요청하는 예시

1
bmad-tea
2
trace
3

4
이 PRD의 요구사항이 어떤 테스트와 연결되는지 매핑해줘.
5
빠진 테스트가 있다면 같이 표시하고,
6
감사 대응용으로 요구사항-테스트 연결표 형태로 정리해줘.

TEA로 릴리스 판단을 요청하는 예시

1
bmad-tea
2
trace
3

4
Phase 2 기준으로 release gate 판단을 진행해줘.
5
현재 테스트 결과와 남아 있는 위험을 기준으로
6
이번 릴리스를 진행해도 되는지 판단해줘.
7
진행 가능, 조건부 가능, 보류 중 하나로 정리하고 이유를 설명해줘.

BMad Builder는 “사용자”에서 “제작자”로 넘어가는 시점에 맞습니다#

BMad Builder는 이름 그대로 BMAD 자체를 확장하는 모듈입니다.
공식 문서도 이를 meta-module로 설명합니다.

이 모듈이 필요한 순간은 비교적 분명합니다.

• 우리 도메인 전용 agent를 만들고 싶을 때
• 우리 팀에 맞는 workflow를 따로 설계하고 싶을 때
• 모듈 형태로 배포 가능한 확장을 만들고 싶을 때

즉 BMad Builder는 “BMAD를 잘 쓰는 것” 다음 단계에 가깝습니다.
공식 문서가 “나중에 붙여라”라고 못 박는 것은 아니지만, 글의 관점에서는 기본 흐름이 익숙해진 뒤 검토하는 편이 더 자연스럽다고 보겠습니다.

공식 Official Modules 문서 기준으로 BMad Builder가 제공하는 핵심은 세 가지입니다.

• Agent Builder: 우리 도메인 전용 agent 만들기
• Workflow Builder: 팀에 맞는 절차형 workflow 만들기
• Module Builder: agent와 workflow를 모듈로 묶어 배포하기

즉 BMad Builder를 붙였을 때 할 수 있는 일은 “설정을 조금 고친다” 수준이 아니라, BMAD 위에 우리 팀 전용 확장을 한 층 더 올리는 일입니다.

예를 들어 BMad Builder 공식 문서 기준으로는 bmad-agent-builder와 bmad-workflow-builder 두 가지 core skill이 있고, 둘 다 BP(Build Process) capability로 시작합니다.
다만 이 예시는 bmb 모듈을 실제로 설치한 뒤에만 쓸 수 있습니다. 즉 아래 호출 방식은 “BMad Builder를 추가로 설치했다면”이라는 전제를 깔고 읽는 편이 정확합니다.

BMad Builder로 전용 agent를 구상하는 예시

1
bmad-agent-builder
2
BP
3

4
우리 팀은 승인 기능이 많은 서비스라서
5
권한과 감사 로그를 집중적으로 보는 전용 agent가 필요해.
6
이 agent의 역할, 항상 기억해야 할 규칙,
7
시작할 때 꼭 확인해야 하는 항목을 설계해줘.

BMad Builder로 전용 workflow를 구상하는 예시

1
bmad-workflow-builder
2
BP
3

4
새 기능이 들어올 때마다
5
권한 검토 → 감사 로그 검토 → 테스트 전략 점검 → 구현 준비 확인
6
순서로 움직이는 팀 전용 workflow를 만들고 싶어.
7
각 단계의 입력과 출력이 무엇인지 먼저 설계해줘.

BMad Builder로 모듈화를 구상하는 예시

1
bmad-workflow-builder
2
BP
3

4
우리 팀의 승인 도메인 전용 agent와 workflow를
5
다른 프로젝트에서도 재사용할 수 있게 모듈로 묶고 싶어.
6
어떤 구성으로 나누면 되는지와
7
배포 가능한 형태로 만들 때 필요한 요소를 정리해줘.

Creative Intelligence Suite와 Game Dev Studio는 목적이 분명할 때만 붙이면 됩니다#

이 둘은 흥미롭지만, 모든 팀의 기본값은 아닙니다.

실전 예시: 우리 팀 BMAD를 조금씩 팀 스타일에 맞추는 흐름#

예를 들어 일정 관리 도구를 계속 개발하는 팀이라고 가정해 보겠습니다.
이 팀은 이미 BMAD 기본 흐름에 익숙해졌고, 아래 같은 불편이 생기기 시작했습니다.

• Dev가 자꾸 테스트보다 구현을 먼저 끝내려 합니다
• story 구현 전에 project-context.md를 놓치기도 합니다
• 테스트 전략이 조금 더 강해졌으면 좋겠습니다

이 상황이라면 보통 이렇게 갑니다.

9편의 핵심은 BMAD를 버리지 않고 확장하는 법입니다#

이 글에서 꼭 기억할 것은 다섯 가지입니다.

• agent 파일을 직접 고치지 말고 .customize.yaml을 사용해야 합니다
• 커스터마이징은 memories와 critical_actions부터 시작하는 편이 가장 실용적입니다
• 변경 적용은 npx bmad-method install 뒤 Quick Update로 반영합니다
• TEA는 테스트 전략, 추적성, release gate가 필요할 때 붙이는 편이 좋습니다
• BMad Builder는 팀 전용 agent, workflow, 모듈을 만들고 싶을 때 붙이는 편이 좋습니다

1편부터 9편까지 오면 BMAD의 큰 그림은 한 번 끝납니다.
이제는 기본 흐름을 그대로 쓰는 단계를 넘어서, 우리 팀 방식에 맞게 안전하게 다듬고 확장하는 단계로 넘어가면 됩니다.