BMAD Method Deep Dive

바이브 코딩(Vibe Coding)이라는 용어가 있다. LLM에게 자연어로 지시하고, 생성된 코드를 그대로 가져다 쓰는 방식이다. 프로토타이핑에는 효과적이지만, 프로젝트가 복잡해질수록 LLM이 맥락을 잃어버리는 문제가 발생한다. 대화 턴이 쌓이면서 컨텍스트 윈도우가 불필요한 정보로 채워지고, 모델이 핵심 비즈니스 로직이나 기술 제약을 "잊는" 현상이다. 이것을 Context Collapse라 부른다.

BMAD Method(Breakthrough Method for Agile AI-Driven Development)는 이 문제를 정면으로 해결하려는 프레임워크다.

핵심 철학: 문서가 Single Source of Truth

BMAD에서 가장 중요한 개념은 소스 코드가 아닌 문서가 단일 진실 원천(Single Source of Truth)이라는 점이다. PRD, 아키텍처 설계, 유저 스토리 같은 명세 문서가 프로젝트의 중심이고, 코드는 이 명세의 하위 산출물이다.

전통적인 개발에서는 코드가 진실이었다. 문서는 코드를 따라가지 못하고 낡아갔다. 하지만 AI와 협업하는 환경에서는 상황이 다르다. AI 모델은 명확한 컨텍스트를 줄수록 정확한 출력을 만든다. 그 컨텍스트를 가장 효과적으로 전달하는 방법이 구조화된 문서다. 사람 간 협업에서 구두 지시보다 명세서가 정확하듯, AI와의 협업에서도 같은 원리가 적용된다.

2단계 프로세스

BMAD는 크게 두 단계로 나뉜다.

Phase 1 — Agentic Planning

Analyst, Product Manager, Architect 같은 전문 AI 에이전트가 가상 팀원으로 참여한다. 각 에이전트는 자신의 역할에 맞는 산출물을 생성한다. Analyst가 요구사항을 분석하고, PM이 PRD를 작성하고, Architect가 기술 아키텍처를 설계한다. 사람은 각 단계에서 결과물을 검토하고 피드백을 주는 Human-in-the-Loop 역할을 한다.

Phase 2 — Context-Engineered Development

Phase 1에서 완성된 PRD를 Epic 단위로 분해(Sharding)한다. 각 Epic은 자기 완결적인 개발 단위가 되어, AI가 해당 Epic을 구현할 때 필요한 모든 맥락을 포함한다. 이 단계에서 Scrum Master, Developer, QA 에이전트가 스토리 파일을 통해 협업한다.

핵심은 Sharding이다. 전체 PRD를 한 번에 AI에게 넘기면 Context Collapse가 발생한다. Epic 단위로 분해하면 각 개발 단위가 컨텍스트 윈도우 안에 충분히 들어가는 크기가 되고, AI는 해당 범위 내에서 일관성 있는 코드를 생성할 수 있다.

에이전트 역할

BMAD는 소프트웨어 개발 라이프사이클의 각 역할을 AI 에이전트로 정의한다.

Planning 에이전트: Analyst(요구사항 분석), Product Manager(PRD 생성), Architect(기술 설계)

Implementation 에이전트: Scrum Master(스토리 생성/관리), Developer(구현), QA(검증)

각 에이전트는 .md 파일로 정의되며, 에이전트의 페르소나, 역할, 사용 가능한 명령어가 포함된다. 이 정의 파일을 IDE의 컨텍스트에 로드하면 LLM이 해당 역할로 동작한다. 본질적으로는 구조화된 프롬프트 엔지니어링이다.

설치와 실행

npx bmad-method install

설치 후 프로젝트 루트에 .bmad 폴더가 생성된다. Claude Code, Cursor, Windsurf 같은 AI IDE에서 사용 가능하다.

시작점은 /bmad-help다. 현재 프로젝트 상태에 따라 다음에 무엇을 해야 하는지 안내해준다. 규모와 복잡도에 따라 워크플로우가 자동으로 조정되는 Scale-Adaptive 특성이 있어서, 버그 수정 같은 작은 작업부터 엔터프라이즈 시스템까지 동일한 프레임워크로 대응 가능하다.

간단한 작업은 /quick-spec 명령 하나로 코드베이스를 분석하고 스토리가 포함된 기술 명세를 생성할 수 있다.

Brownfield 프로젝트 지원

BMAD의 실용적 가치는 기존 프로젝트(Brownfield)에서 드러난다.

기존 프로젝트에 BMAD를 적용하려면 먼저 document-project 워크플로우로 project-context.md를 생성한다. 이 파일은 코드베이스의 현재 상태와 모든 구현 워크플로우가 따라야 할 규칙을 정의한다. 이후 신규 기능은 기존 아키텍처 문서를 참조하면서 Brownfield 전용 PRD와 아키텍처를 작성하는 흐름으로 진행된다.

QA 에이전트의 역할도 중요하다. 개발 전 리스크 평가(@qa *risk {story}), 개발 후 회귀 테스트 검증(@qa *trace {story}), 비기능 요구사항 체크(@qa *nfr {story})를 통해 새로운 변경이 기존 기능을 불안정하게 만들지 않도록 보장한다.

왜 문서 기반 개발이 중요한가

BMAD가 제시하는 방향은 단순히 하나의 도구를 넘어선다. AI와 협업하는 시대에서 문서 기반 개발(Spec-Driven Development)은 구조적으로 필요해지고 있다.

AI 모델의 근본적 동작 방식 때문이다. 컨텍스트가 명확할수록 출력이 정확하다. 프로젝트가 커질수록 이 컨텍스트를 체계적으로 관리하는 구조가 필수다. "대화 맥락에 의존하는 바이브 코딩"에서 "문서화된 명세에 기반한 체계적 개발"로의 전환은, 도구가 BMAD이든 다른 것이든 AI 시대 소프트웨어 개발의 기본 전제가 될 가능성이 높다.

다만 현실적인 고려도 있다. LLM의 컨텍스트 윈도우가 계속 커지고 있어서 Context Collapse 문제가 모델 발전만으로 완화될 가능성도 있고, BMAD 자체도 아직 v6 Alpha 단계로 안정성이 완전히 검증되지는 않았다. 또한 Claude 3.5 Sonnet이나 GPT-4o 이상의 모델을 권장하며, 그보다 약한 모델에서는 긴 PRD 처리 시 로직 붕괴나 지시 망각이 발생할 수 있다.