BMAD Method 튜토리얼 8편: 결과물 품질을 높이는 BMAD 고급 활용법

요약#

참고 자료#

• BMAD Method - Core Tools - 기본 제공 core tools 전체 목록
• BMAD Method - Adversarial Review - 강제 문제 찾기 검토 방식
• BMAD Method - Advanced Elicitation - 구조화된 재검토 방식
• BMAD Method - Party Mode - 다중 에이전트 토론 방식

바로 써먹는 템플릿#

8편에서 다루는 도구들은 대부분 agent를 먼저 여는 방식보다 direct skill로 바로 실행하는 편이 더 자연스럽습니다.
공식 skill 이름은 bmad-create-prd처럼 하이픈(-)이 들어가지만, 사용하는 AI 도구에 따라 bmad create prd처럼 띄어쓰기로 입력하는 편이 더 잘 인식될 수도 있습니다.

고급 활용에서 자주 쓰는 흐름은 아래처럼 보면 됩니다.

큰 결정을 여러 관점에서 토론하고 싶다면 이렇게 시작하면 됩니다.

Party Mode로 다중 관점 토론을 시작하는 예시

1
bmad-party-mode
2

3
우리 일정 관리 도구에 승인 기능을 넣으려고 해.
4
PM, Architect, Dev, UX 관점에서
5
어떤 점이 가장 위험한지 먼저 토론해줘.

이미 나온 문서를 한 번 더 깊게 다듬고 싶다면 이렇게 시작할 수 있습니다.

Advanced Elicitation으로 문서를 다시 생각하게 하는 예시

1
bmad-advanced-elicitation
2

3
방금 만든 architecture 문서를 대상으로
4
pre-mortem 관점에서 다시 검토해줘.
5
이 설계가 이미 실패했다고 가정했을 때
6
어디서 먼저 무너질지 찾아줘.

일부러 문제를 찾는 비판적 리뷰는 이렇게 넣을 수 있습니다.

Adversarial Review를 실행하는 예시

1
bmad-review-adversarial-general
2

3
방금 만든 PRD를 냉정하게 검토해줘.
4
빠진 요구사항, 모순, 구현 단계에서 위험할 부분을 중심으로 찾아줘.

분기와 예외 처리가 빠졌는지 보고 싶다면 이렇게 쓰면 됩니다.

Edge Case Hunter를 실행하는 예시

1
bmad-review-edge-case-hunter
2

3
이번 로그인 처리 코드 변경에서
4
빠진 분기와 경계 조건만 골라서 찾아줘.
5
이미 처리된 경우는 빼고,
6
정말 빠진 경우만 알려줘.

8편부터는 phase보다 도구를 봐야 합니다#

1편부터 7편까지는 BMAD의 큰 흐름을 따라왔습니다.
어떤 문서를 만들고, 어떤 단계에서 어떤 workflow를 쓰는지 중심으로 설명했습니다.

8편은 결이 조금 다릅니다.
이번에는 특정 phase에 묶이지 않는 core tools를 봅니다.

공식 Core Tools 문서가 강조하는 핵심은 단순합니다.
이 도구들은 특정 모듈을 더 설치하지 않아도, BMAD를 설치하면 기본으로 쓸 수 있는 작업 도구라는 점입니다.

즉 8편은 “다음 단계로 가기 위한 workflow”보다
“지금 만든 결과물을 더 낫게 만들기 위한 보조 도구”를 다루는 글이라고 보면 됩니다.

왜 이런 도구가 필요할까요?#

BMAD 기본 흐름만 따라도 결과물은 나옵니다.
하지만 실제 작업에서는 늘 이런 순간이 생깁니다.

• 문서는 나왔는데 뭔가 얕아 보입니다
• 설계는 그럴듯한데 허점이 숨어 있을 것 같습니다
• 한 사람 시각만으로는 중요한 결정을 내리기 어렵습니다
• 코드는 돌아가는데 빠진 예외 처리가 걱정됩니다

이럴 때 필요한 것이 8편의 도구들입니다.
즉 core tools는 BMAD의 기본 흐름을 대체하는 것이 아니라, 그 결과물을 더 깊고 단단하게 만드는 보강 장치입니다.

Party Mode는 언제 가장 강할까요?#

공식 Party Mode 문서는 이 도구를 “여러 에이전트를 한 대화 안에서 토론시키는 방식”으로 설명합니다.
핵심은 한 agent에게 정답을 바로 묻는 것이 아니라, 서로 다른 역할의 시각을 한 자리에서 부딪치게 만드는 것입니다.

이 도구가 잘 맞는 상황은 비교적 분명합니다.

• 의사결정에 trade-off가 큽니다
• 한 가지 시각으로 답을 내리기 어렵습니다
• 회고나 큰 브레인스토밍처럼 여러 관점이 필요합니다
• PM, Architect, Dev, UX가 서로 다른 우선순위를 가질 수 있습니다

예를 들어 “이 기능을 지금 넣어야 하나?” 같은 질문은 한 사람 답보다 토론이 더 낫습니다.
Party Mode는 바로 그 지점에서 힘을 냅니다.

공식 문서 예시도 비슷합니다.
망한 sprint 회고, 아키텍처 비판, 온보딩 개선 같은 문제는 한 역할보다 여러 역할이 섞일수록 더 좋은 논의가 나옵니다.

즉 Party Mode는 정답을 빨리 뽑는 도구라기보다,
한 방향으로 성급하게 결론 내리지 않게 해 주는 도구입니다.

Advanced Elicitation은 “다시 써봐”와 다릅니다#

이 도구는 이름이 어려워 보이지만, 실제로는 아주 실용적입니다.
공식 문서 표현대로 하면 “LLM이 방금 만든 결과물을 특정 사고법으로 다시 보게 만드는 방식”입니다.

여기서 중요한 점은 그냥 다시 써줘와는 다르다는 점입니다.

• 막연한 재요청: 그냥 한 번 더 써 보라고 하는 수준입니다
• 사고법을 지정한 재검토: 특정한 관점으로 다시 생각하게 만듭니다

이 차이가 큽니다.
공식 문서도 “막연한 재시도는 막연한 수정만 만든다”고 설명합니다.

예를 들어 같은 architecture 문서라도 아래처럼 전혀 다른 방식으로 다시 볼 수 있습니다.

• Pre-mortem Analysis: 이미 실패했다고 가정하고 원인을 거꾸로 찾기
• First Principles Thinking: 당연하게 여긴 가정을 모두 벗겨 보기
• Inversion: 어떻게 하면 반드시 실패할지를 먼저 생각하기
• Stakeholder Mapping: 역할별로 손해를 보는 지점 찾기

즉 Advanced Elicitation은 “한 번 더 써 봐”가 아니라
“이번에는 이 렌즈로 다시 생각해 봐”에 가깝습니다.

그래서 문서가 얕아 보일 때, 혹은 설계가 너무 매끈해서 오히려 불안할 때 특히 유용합니다.

Adversarial Review는 일부러 문제를 찾게 만듭니다#

공식 Adversarial Review 문서는 핵심 규칙을 아주 강하게 잡습니다.

문제를 반드시 찾아야 한다.

이 방식이 중요한 이유는 단순합니다.
보통의 리뷰는 “대충 봤는데 큰 문제 없어 보이네”로 끝나기 쉽습니다.
하지만 이 도구는 애초에 reviewer에게 문제를 반드시 찾으라고 강제합니다.

이렇게 하면 리뷰 관점이 달라집니다.

• 지금 있는 것이 맞는가?
• 무엇이 빠졌는가?
• 왜 이건 문서에 없는가?
• 구현 단계에서 어디가 먼저 깨질까?

즉 Adversarial Review는 부정적인 태도를 흉내 내는 것이 아니라,
대충 넘어가는 검토를 막기 위한 강제 장치입니다.

다만 공식 문서도 아주 분명하게 한계를 말합니다.
이 도구는 문제를 찾도록 강제되기 때문에, 실제보다 과하게 문제를 만들어 낼 수도 있습니다.

• 사소한 취향 차이를 큰 문제처럼 말할 수 있습니다
• 의도를 오해한 뒤 잘못된 지적을 할 수 있습니다
• 없는 문제를 그럴듯하게 꾸밀 수도 있습니다

그래서 이 도구의 핵심 원칙은 하나입니다.

사람이 반드시 걸러야 한다.

즉 findings를 그대로 믿는 것이 아니라,
무엇이 진짜 문제이고 무엇이 잡음인지를 사람이 판단해야 합니다.

Edge Case Hunter는 Adversarial Review와 다르게 봅니다#

8편에서 이 도구를 같이 소개하는 이유는 분명합니다.
공식 Core Tools 문서는 Adversarial Review와 Edge Case Hunter가 서로 다른 성격이라고 설명합니다.

• Adversarial Review: 냉소적인 시각으로 문제를 찾음
• Edge Case Hunter: 분기, 경계값, 예외 처리만 기계적으로 추적함

즉 둘은 겹치지 않습니다.

Adversarial Review가 “이 문서에 빠진 요구사항이 있지 않나?”를 잘 잡는다면,
Edge Case Hunter는 “이 if/else에서 빠진 경우가 있지 않나?”를 잘 잡습니다.

그래서 코드나 로직 리뷰에서는 둘을 같이 쓰는 편이 좋습니다.

• 하나는 전체적인 허점
• 하나는 빠진 분기와 경계 조건

공식 문서가 둘을 complementary하다고 설명하는 이유도 바로 이 조합 때문입니다.

실전 예시: 승인 기능 설계를 고급 도구로 다듬는 흐름#

이번 시리즈에서 계속 써 온 일정 관리 도구 예시를 그대로 이어 가보겠습니다.
이번에는 “관리자 승인 기능”을 넣으려는 상황이라고 가정하겠습니다.

PRD와 architecture는 이미 만들어 둔 상태입니다.
그런데 바로 구현으로 들어가기 전에, 이번 변경이 정말 안전한지 한 번 더 보고 싶습니다.

이럴 때는 보통 이렇게 갑니다.

이 도구들은 phase를 몰라도 쓸 수 있습니다#

8편 도구들의 또 다른 장점은 특정 phase에 갇히지 않는다는 점입니다.

• PRD를 만든 뒤 Adversarial Review
• architecture를 만든 뒤 Advanced Elicitation
• sprint 회고에서 Party Mode
• 코드 리뷰 뒤 Edge Case Hunter

즉 “지금 어느 단계인가”보다
“지금 부족한 것이 깊이인가, 비판적 검토인가, 예외 처리 점검인가”를 기준으로 도구를 꺼내면 됩니다.

그래서 core tools는 BMAD를 오래 쓸수록 더 가치가 커집니다.
기본 흐름을 이미 아는 사람에게는, 이 도구들이 품질 차이를 만드는 부분이기 때문입니다.

너무 많이 돌리면 오히려 피곤해질 수도 있습니다#

이 글은 고급 활용법이지만, 무조건 많이 쓰는 게 정답은 아닙니다.

예를 들어 이런 식은 과할 수 있습니다.

• 문서 하나 만들 때마다 Party Mode
• 모든 산출물마다 Advanced Elicitation 3번
• 모든 코드 조각마다 Adversarial Review

이렇게 하면 생산성보다 피로가 더 커집니다.

좋은 기준은 이렇습니다.

• 큰 의사결정이면 Party Mode
• 뭔가 얕아 보이면 Advanced Elicitation
• 중요한 문서나 설계면 Adversarial Review
• 코드의 분기와 예외가 불안하면 Edge Case Hunter

즉 고급 도구는 “항상 쓰는 기본기”보다 “필요할 때 꺼내 쓰는 강화 장비”에 가깝습니다.

8편의 핵심은 기본 흐름 위에 품질 도구를 얹는 법입니다#

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

• core tools는 특정 phase에 묶이지 않는 built-in 도구입니다
• Party Mode는 큰 의사결정에서 여러 관점을 모으는 데 강합니다
• Advanced Elicitation은 단순 재시도보다 훨씬 구조적으로 결과물을 다듬습니다
• Adversarial Review는 일부러 문제를 찾게 만들지만, 반드시 사람이 걸러야 합니다
• Edge Case Hunter는 빠진 분기와 경계 조건을 찾는 데 특히 강합니다

7편이 기존 프로젝트에서 BMAD를 어떻게 붙일지 설명하는 글이었다면, 8편은 이미 BMAD를 쓰고 있는 사람이 결과물 품질을 한 단계 더 끌어올리는 방법을 설명하는 글입니다.
다음 글에서는 마지막으로 BMAD를 우리 팀 방식에 맞게 어떻게 바꾸고 확장할지, 그리고 공식 모듈과 roadmap은 어떻게 보면 좋은지를 정리하겠습니다.