BMAD Method 튜토리얼 1편: AI 코딩을 더 체계적으로 만드는 BMAD란?

요약#

참고 자료#

• BMAD Method - Welcome - BMAD 전체 개요
• BMAD Method - Getting Started - 입문 순서와 track 설명
• BMAD Method - Workflow Map - 단계별 흐름과 문서 연결 구조
• BMAD Method - How to Get Answers About BMad - bmad-help 사용법

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

Codex나 Claude Code를 오래 써보면 공통된 문제가 보입니다.
한두 번에 끝나는 작업은 빠르게 처리하지만, 프로젝트가 길어질수록 처음 정한 기준과 나중 구현이 점점 멀어집니다.

요구사항은 대화 초반에만 선명하고, 중간부터는 눈앞의 코드 변경이 더 중요해집니다.
구현은 빨라지지만, 왜 이런 구조를 택했는지와 다음에 무엇을 해야 하는지는 흐려집니다.

이럴 때 많은 사람이 프롬프트를 더 길게 쓰거나, 대화 하나에 더 많은 맥락을 밀어 넣으려고 합니다.
하지만 BMAD 공식 문서는 반대로 접근합니다.
한 대화에 모든 것을 우겨 넣기보다, 필요한 문서를 만들고 다음 단계에 넘기라고 설명합니다.

BMAD는 정확히 무엇일까요?#

BMAD Method는 AI 코딩을 위한 단순 prompt¹⁰ 묶음이 아닙니다.
공식 문서를 읽어보면, BMAD는 분석부터 구현까지의 흐름을 역할과 문서 중심으로 나눈 개발 프레임워크에 가깝습니다.

핵심은 문서가 다음 단계의 컨텍스트가 된다는 점입니다.
아이디어는 brief로 정리되고, brief는 PRD로 이어지고, PRD는 architecture와 stories로 이어집니다.
즉, 앞 단계의 결과물이 다음 단계의 판단 기준이 됩니다.

이 구조 때문에 BMAD는 “좋은 프롬프트 한 번 쓰기”보다 “좋은 흐름 만들기”에 가깝습니다.
많은 사람이 BMAD를 workflow라고 부르는 이유도 여기에 있습니다.

BMAD는 일을 4단계로 나눕니다#

BMAD 공식 문서는 전체 흐름을 4 phases로 설명합니다.
이 네 단계만 먼저 이해해도, BMAD 문서 전체가 훨씬 덜 낯설게 보입니다.

BMAD는 시작 경로도 나눠 둡니다#

BMAD는 모든 작업을 같은 무게로 다루지 않습니다.
공식 Getting Started 문서는 시작 경로를 3 tracks로 나눕니다.

왜 bmad-help부터 시작할까요?#

BMAD를 처음 쓰는 사람에게 가장 중요한 명령은 복잡한 workflow 이름이 아닙니다.
가장 중요한 출발점은 bmad-help입니다.

쉽게 말하면, bmad-help는 BMAD의 길 안내 기능입니다.
지금 내가 어디쯤 와 있는지, 다음에 무엇을 해야 하는지, 어느 track으로 가야 하는지를 먼저 잡아줍니다.

공식 문서도 bmad-help를 허브처럼 다룹니다.
지금 어떤 phase에 있는지, 어떤 track이 맞는지, 다음 workflow가 무엇인지 헷갈릴 때마다 여기로 돌아오면 됩니다.

이 점이 초심자에게 특히 중요합니다.
BMAD는 문서도 많고 기능도 많아서, 처음부터 모든 agent와 workflow를 외우려 하면 바로 부담이 커집니다.
반대로 bmad-help를 출발점으로 잡으면 “지금 내 상태에서 다음 한 걸음”만 결정하면 됩니다.

즉 BMAD의 진입 장벽을 낮추는 진짜 기능은 설치 명령보다 bmad-help라고 보는 편이 맞습니다.

왜 새 대화와 설계 단계가 중요할까요?#

BMAD 문서에서 자주 보이는 표현이 fresh chat입니다.
이름은 조금 낯설지만, 뜻은 단순합니다.
긴 대화 하나로 모든 단계를 해결하려 하지 말라는 뜻입니다.

분석 단계에서 만든 문서를 들고 새 대화로 넘어가고, 계획 문서를 다시 다음 단계로 넘기는 방식이 BMAD의 기본 원리입니다.
즉 기억을 대화에 맡기지 않고 문서에 맡깁니다.

여기서 solutioning도 매우 중요합니다.
이 용어도 처음에는 어려워 보이지만, 결국 “구현 전에 구조를 먼저 정리하자”는 뜻에 가깝습니다.
많은 사람이 PRD까지만 만들고 곧바로 구현하고 싶어 하지만, BMAD는 그 사이에 architecture와 stories를 두라고 말합니다.
공식 문서가 왜 solutioning을 강조하는지 다시 보면 이유가 분명합니다.
구현 전에 구조를 잡아 두지 않으면, 여러 agent가 각자 다른 방향으로 움직이기 쉽기 때문입니다.

즉 BMAD는 느리게 만들기 위해 설계를 넣는 것이 아닙니다.
나중에 더 크게 흔들리지 않게 하려고 설계를 먼저 넣습니다.

이 시리즈를 어떻게 읽으면 좋을까요?#

이 시리즈는 BMAD 공식 문서 목차를 그대로 번역하지 않습니다.
처음 접하는 사람이 실제로 이해하고 따라갈 수 있는 순서로 다시 정리합니다.

• 설치와 첫 사용이 궁금하다면 2편으로 바로 이어가면 됩니다
• 작은 수정과 빠른 작업이 목표라면 3편이 가장 먼저 도움이 됩니다
• BMAD의 진짜 본체를 이해하려면 4편과 5편이 중요합니다
• 기존 프로젝트에 붙이려면 7편을 반드시 함께 봐야 합니다

1편의 목표는 단 하나입니다.
BMAD를 “프롬프트 모음”으로 오해하지 않게 만드는 것입니다.
이 기준만 잡히면, 이후 회차의 설치와 실전 흐름도 훨씬 자연스럽게 들어옵니다.