[AI] BMAD : 코드 한 줄이 아닌 프로젝트 전체를 맡기는 법

코드 한 줄이 아닌 프로젝트 전체를 맡기는 법

AI에게 작은 함수 하나, 컴포넌트 한 개를 만들어 달라고 부탁하는 일은 이제 너무 익숙해졌다. 그런데 막상 "업무 관리 도구를 처음부터 만들어 줘" 같은 요청을 던져 보면 결과물은 늘 어딘가 부족하다. 구조는 엉성하고, 기능 사이의 연결이 깨지고, 며칠 뒤 수정을 요청하면 AI는 자기가 뭘 만들었는지조차 잊어버린다.

이 글은 그 한계를 메우기 위해 등장한 BMAD(Breakthrough Method for Agile AI-Driven Development)라는 방법론을 소개하고, 실제로 업무 관리 툴 하나를 처음부터 만들 때 BMAD를 어떻게 적용하는지 보편적인 흐름으로 정리해 본다.

1. BMAD

BMAD는 AI 에이전트 기반 소프트웨어 개발 방법론이다.

AI를 활용해 소프트웨어를 체계적으로 설계 → 구현 → 검증 까지 이어주는 워크플로우 프레임워크

• 역할별 전문 에이전트가 각자의 책임만 진다. 한 명의 AI가 모든 걸 떠안지 않는다. 분석가, PM, UX 디자이너, 아키텍트, 스크럼 마스터, 개발자, QA가 각각 자기 영역만 본다.
• 모든 단계는 문서(Artifact)로 남고, 다음 단계는 그 문서를 읽어서 시작한다. AI는 문맥을 잃기 쉬운데, 문서가 매개체가 되어 다음 단계 에이전트에게 맥락을 전달한다.

설치는 간단하다. 설치하면 프로젝트 루트에 _bmad/ 디렉토리와 명령어들이 생기고, Claude Code · Cursor · GitHub Copilot 같은 AI IDE에서 슬래시 커맨드로 호출할 수 있게 된다.

npx bmad-method install

2. 왜 BMAD가 필요한가

기존 AI 사용 방식의 흐름은 단순하다.

프롬프트 → 코드 생성 → 끝

• 구조가 없다. 프로젝트가 커지면 AI는 매번 처음부터 컨텍스트를 다시 파악해야 한다. 토큰만 잡아먹고, 일관성은 떨어진다.
• 재현이 안 된다. 같은 프롬프트를 넣어도 매번 다른 답이 나온다.
• 개인의 프롬프트 실력에 결과 품질이 종속된다.

BMAD는 이 흐름을 다음처럼 바꾼다.

Intent → PRD → Architecture → Spec → Story → Code

• 단계별로 산출물(문서)을 남기면서 진행한다.
• AI는 그때그때 필요한 문서만 골라 읽는다 (컨텍스트 윈도우의 한계 극복).
• 각 단계마다 전용 Skill이 작업 프롬프트를 구체화하고 검증한다.

요약하자면, AI가 길을 잃지 않도록 문서가 가이드 레일 역할을 한다.

3. BMAD의 핵심 구성 요소

BMAD의 중심은 코드가 아니라 문서다. 단계별로 책임이 명확히 분리된다.

단계	산출물	답하는 질문
PRD (Product Requirements Document)	제품 요구사항	"무엇을, 왜 만드는가?"
Architecture	시스템 구조도	"어떤 구조로 만들 것인가?"
Tech Spec	기술 명세	"구현은 어떻게 할 것인가?"
Epic / Story / Task	실행 단위	"지금 당장 무엇을 코딩하는가?"

특히 마지막 실행 단위는 트리 구조로 잘게 쪼개진다. 이렇게 쪼개는 이유는 하나의 Story가 AI 컨텍스트 한도 안에서 완결되도록 하기 위해서다. Story 한 개가 너무 크면 AI는 절반쯤 가다 길을 잃는다.

Epic (큰 기능 단위)
├── Story 1 (AI가 한 번에 구현 가능한 단위)
│   ├── Task
│   └── Task
└── Story 2
    └── Task

각 단계는 7명의 전담 에이전트가 맡는다.

이름	역할
Mary (Analyst)	아이디어 구체화, 리서치
John (PM)	PRD 작성, 요구사항 정의
Sally (UX Designer)	사용자 경험 설계
Winston (Architect)	기술 아키텍처 설계
Bob (Scrum Master)	스프린트 계획, 스토리 준비
Amelia (Developer)	TDD 기반 코드 구현
Quinn (QA)	테스트 자동화

4. BMAD 표준 워크플로우

BMAD는 4단계 파이프라인으로 구성된다. 각 단계 끝에는 게이트(검증)가 있어서, 통과하지 못하면 다음 단계로 넘어갈 수 없다.

Phase 1. Analysis : 무엇을 만들지 정한다

이 단계의 결과물은 Product Brief 한 장이다. "누가, 왜, 무엇을, 어떤 기준으로 성공한다고 볼 것인가" 가 명확해야 다음 단계로 넘어간다.

/bmad-brainstorming        # 아이디어를 다양한 기법으로 발산
/bmad-create-product-brief # 제품 비전, 사용자, 메트릭, 범위 정의
/bmad-domain-research      # 도메인 조사
/bmad-market-research      # 시장/사용자 조사
/bmad-technical-research   # 기술 조사

Phase 2. Planning : PRD를 만든다

PRD는 BMAD에서 가장 중요한 문서다. 비전, 성공 기준, 사용자 여정, 기능 요구사항(FR), 비기능 요구사항(NFR)이 모두 들어간다. validate-prd가 PRD에 모호한 표현이 있는지, 측정 가능한지, 구현 누설(어떻게 만들지를 미리 적어버린 부분)이 있는지를 까다롭게 검증한다.

/bmad-create-prd      # 12단계로 PRD 작성
/bmad-validate-prd    # 13단계로 PRD 검증 (포맷, 측정가능성, 추적성 등)
/bmad-create-ux-design

Phase 3. Solutioning : 어떻게 만들지 설계한다

핵심은 마지막 명령이다. PRD, UX, Architecture, Epics가 서로 정합한지 6단계로 검증한다. 여기서 결함이 발견되면 앞 단계로 돌아가야 한다. "기획이 완전하지 않으면 구현으로 넘어갈 수 없다" — 이것이 BMAD가 강제하는 규율이다.

/bmad-create-architecture            # 시스템 아키텍처 설계
/bmad-create-epics-and-stories       # PRD를 에픽/스토리로 분해
/bmad-check-implementation-readiness # ⭐ 구현 준비도 검증

Phase 4. Implementation : 코드를 쓴다

AI 개발자(Amelia)는 항상 스토리 파일 한 개만 본다. PRD 전체를 매번 읽지 않는다. 그 스토리를 구현하기 위해 필요한 컨텍스트가 스토리 파일 안에 모두 들어 있어야 한다.

/bmad-sprint-planning   # 스프린트 계획 생성
/bmad-create-story      # 스토리 파일 생성 (구현에 필요한 모든 컨텍스트 포함)
/bmad-dev-story         # 스토리 파일 기반 코드 구현

5. 실전 활용 예시

이제 처음부터 업무 관리 툴 하나를 만든다고 가정하고, BMAD 명령어를 순서대로 짚어보자.

BMAD는 버전·환경에 따라 명령어 prefix가 다를 수 있다. 예를 들어 어떤 환경은 /bmad-create-story로, 다른 환경은 /create-story로 호출된다. 이 글은 /bmad- prefix 기준으로 작성했지만, 실제 실행 시 자동완성 목록에서 본인 환경의 정확한 명령어 이름을 확인하고 사용하면 된다.

Step 0. 막막할 땐 /bmad-help

설치 직후, 빈 폴더 앞에서 뭘 해야 할지 모르겠다면 가장 먼저 칠 명령어는 이거다. 현재 프로젝트 상태(설치된 모듈, 산출물 유무, 다음 추천 단계)를 분석해서 알려준다. 도중에 길을 잃었을 때마다 다시 부를 수 있어 가장 자주 쓰게 되는 명령어다.

/bmad-help

자연어 질문도 받는다.

/bmad-help 방금 PRD를 다 썼는데 다음에 뭘 해야 해?

Step 1. 아이디어를 다듬는다

머릿속에 아이디어가 흐릿하다면 브레인스토밍을 먼저 한다. SCAMPER, Six Hats 같은 발상 기법으로 인터랙티브하게 아이디어를 확장해 준다. 이미 "업무 관리 툴을 만든다"가 명확하다면 건너뛰어도 된다.

/bmad-brainstorming

다양한 관점이 필요할 때는 파티 모드도 유용하다. PM, 아키텍트, UX, QA가 한 자리에 모여 토론하는 모드다. "이 기획에 빠진 게 뭘까?" 같은 질문에 빛을 발한다.

/bmad-party-mode

Step 2. Product Brief : "왜 만드는가" 정리

본 작업의 시작점이다. 이 명령어를 치면 BMAD가 단계별로 묻는다:

/bmad-create-product-brief

• 누구를 위한 도구인가?
• 어떤 문제를 푸는가?
• 성공의 기준은 무엇인가?
• 범위(scope)는 어디까지인가?

업무 관리 툴이라면 이런 답을 채워나가게 된다.

• 사용자: 개인 또는 소규모 팀의 지식 노동자
• 문제: 업무가 흩어져 진행률이 한눈에 안 보인다
• 성공 기준: 업무 등록부터 대시보드 확인까지 5초 이내
• 범위: 단일 사용자, 로컬 실행. 팀 협업/실시간 알림은 제외

도메인이나 기술이 낯설다면 보조 명령어로 리서치를 돌린다. 세 가지를 모두 돌릴 필요는 없다. 막히는 곳에만 호출하자.

/bmad-domain-research      # 업무 관리 도메인 트렌드, 경쟁 도구 비교
/bmad-market-research      # 사용자 페인포인트, 기존 솔루션의 한계
/bmad-technical-research   # 기술 스택 옵션 (Electron vs 웹앱, 저장소 선택 등)

Step 3. PRD 작성과 검증

PRD/UX 같은 큰 단계는 새로운 컨텍스트 윈도우에서 시작하는 게 좋다. 토큰을 깨끗이 비운 상태에서 한 단계씩 진행해야 AI가 길을 잃지 않는다.

여기가 BMAD에서 시간을 가장 많이 쓰는 구간이다. 12단계 인터랙티브 인터뷰로 PRD를 만든다. 발견 → 비전 → 성공 지표 → 사용자 여정 → 기능 요구사항(FR) → 비기능 요구사항(NFR) 순서다.

/bmad-create-prd

업무 관리 툴이라면 이런 식의 FR이 정리된다.

FR-TM-01    카테고리에 업무를 등록할 수 있다
FR-TM-02    업무에 산정(예상 작업량)을 트리 구조로 입력할 수 있다
FR-TM-05    업무를 다른 카테고리로 드래그하여 이동할 수 있다
FR-TM-08    업무에 태그를 추가하고 태그로 필터링할 수 있다
FR-DB-01    대시보드에서 진행 중 업무 수와 평균 진행률을 요약 표시한다
NFR-PERF-01 데이터 변경 후 1초 이내 자동 저장된다

PRD 초안이 끝나면 곧바로 검증을 돌린다. 13단계 검증 체크리스트가 PRD를 훑는다.

• 측정 가능성: "빠르게 저장된다" → "1초 이내 저장된다"로 수정 요구
• 추적성: 각 FR이 어떤 사용자 여정과 연결되는가?
• 구현 누설: PRD에 "React 컴포넌트로 만든다" 같은 구현 디테일이 들어갔는가?
• SMART: 기준이 구체적·측정 가능·달성 가능·관련성 있고 시간 제한이 있는가?

/bmad-validate-prd

검증에서 지적이 나오면 곧바로 수정한다.

/bmad-edit-prd

이후 화면 설계도 함께 정리한다. 대시보드 레이아웃, 업무 카드 구조, 드래그앤드롭 인터랙션 같은 화면 단위 설계가 여기서 정해진다.

/bmad-create-ux-design

Step 4. Architecture : 어떻게 만들지 결정

PRD를 입력으로 받아 시스템 구조를 설계한다.

/bmad-create-architecture

업무 관리 툴이라면 이런 결정이 문서로 남는다.

• 프론트엔드 프레임워크 선택: 빌드 단계의 무게 vs 개발 속도
• 데이터 저장 방식: SQLite, JSON 파일, IndexedDB 중 무엇?
• 백엔드 필요성: 단일 사용자라면 백엔드 없이 가능한가?
• 상태 관리 패턴: Context API, Redux, 단순 상태 끌어올리기

핵심은 결정 자체가 아니라 트레이드오프를 함께 기록하는 것이다. "왜 SQLite 대신 JSON을 골랐는가?"의 답이 6개월 뒤에도 남아 있어야 한다.

Step 5. Epic / Story 분해

PRD의 FR들을 사용자 가치 단위로 묶고, AI가 한 번에 구현 가능한 크기로 쪼갠다.

/bmad-create-epics-and-stories

결과는 이런 트리가 된다. 각 Story는 "As a [사용자], I want [행동], so that [가치]" 형식이다.

Epic 1: 업무 등록과 분류
├── Story 1.1: 카테고리에 업무 카드를 생성한다
├── Story 1.2: 업무에 마감일과 태그를 설정한다
└── Story 1.3: 업무를 다른 카테고리로 드래그한다

Epic 2: 업무 진행 추적
├── Story 2.1: 업무에 트리 구조 산정을 입력한다
├── Story 2.2: 산정 항목을 작업으로 복사한다
└── Story 2.3: 작업의 완료 상태를 전환한다

Epic 3: 대시보드
├── Story 3.1: 진행 중 업무 수와 평균 진행률을 요약한다
├── Story 3.2: 마감 임박 업무를 알림으로 표시한다
└── Story 3.3: 카테고리별 작업량을 비교한다

Step 6. 게이트 : Implementation Readiness Check

이 단계가 BMAD의 마지노선이다. 6단계 검증을 통해 구현으로 진입할 준비가 됐는지 판정한다.

/bmad-check-implementation-readiness

• 문서 탐색: 모든 산출물이 갖춰졌는가?
• PRD 분석: 요구사항이 명확한가?
• 에픽 커버리지 검증: PRD의 모든 FR이 Story에 매핑되는가?
• UX 정합성 확인: UX 디자인과 Story가 일치하는가?
• 에픽 품질 리뷰: Story가 충분히 잘게 쪼개졌는가?
• 최종 판정: Pass / Fail

Fail이 나오면 앞 단계로 돌아간다. 이 게이트를 우회하지 말 것. 구현 중간에 "어? 이 기능 어떻게 한다고 했지?"가 터지는 걸 막아주는 마지막 안전망이다.

Step 7. 스프린트 계획과 구현 루프

여기부터는 같은 패턴의 반복이다.

/bmad-sprint-planning

다음 1~2주에 처리할 Story를 골라 스프린트로 묶는다. 그리고 Story마다 다음 두 명령어를 반복한다.

/bmad-create-story    # Story 한 개에 필요한 모든 컨텍스트를 담은 파일 생성
/bmad-dev-story       # 그 파일을 읽고 실제 코드 구현

/bmad-create-story가 만드는 파일에는 다음이 모두 들어간다. 그래서 /bmad-dev-story의 Dev 에이전트(Amelia)는 PRD 전체를 다시 읽지 않고 그 Story 파일 하나만 보고도 구현을 끝낼 수 있다. 컨텍스트 윈도우를 절약하는 핵심 메커니즘이다.

• Story의 사용자 가치 진술
• 관련 FR과 NFR
• 영향 받는 컴포넌트와 파일 경로
• 테스트 시나리오
• 완료 조건(Acceptance Criteria)

구현이 끝나면 코드 리뷰를 돌린다.

/bmad-code-review

에픽 한 개가 끝나면 회고를 한다.

/bmad-retrospective

다음 에픽으로 넘어가기 전에 무엇이 잘 됐고 무엇이 어긋났는지 정리한다. 다음 에픽의 Story 분해 품질이 올라간다.

자주 쓰게 되는 명령어

처음부터 끝까지 따라가다 보면 결국 손에 익는 명령어는 다음 다섯이다.

1	/bmad-help	길을 잃을 때마다 (가장 자주!)
2	/bmad-create-story	새 Story 시작할 때마다
3	/bmad-dev-story	코드 짤 때마다
4	/bmad-code-review	Story 구현 직후
5	/bmad-quick-dev	작은 기능 추가나 버그 수정 시

작은 수정용 빠른 흐름

이미 굴러가는 프로덕트에 간단한 기능을 추가하거나 버그를 잡을 때는 풀 파이프라인이 과하다.

/bmad-quick-spec    # 가벼운 기술 명세 한 장
/bmad-quick-dev     # 그걸 읽고 바로 구현

단, 이렇게 추가한 기능은 PRD/Story 문서에서 누락된다. 누적되면 문서와 코드가 어긋나기 시작한다. 정기적으로 다음 명령으로 동기화하자. 코드 변경사항을 PRD/에픽/스토리 문서에 역으로 반영해 준다.

/bmad-correct-course

6. BMAD를 잘 쓰는 팁

큰 프로젝트와 작은 수정의 흐름을 분리하라

BMAD는 신규 프로젝트나 큰 기능 단위에 강하지만, 버그 한 줄 수정에는 과하다. 작은 수정에는 별도 흐름이 있다. 단, 이렇게 만든 코드를 PRD/Story 문서에 다시 동기화해 두지 않으면 문서와 코드가 어긋난다. /bmad-correct-course 가 이걸 맞춰주긴 하지만, 너무 자주 쓰면 BMAD를 쓰는 의미가 옅어진다.

/bmad-quick-spec   # 가벼운 기술 명세
/bmad-quick-dev    # 빠른 구현

문서가 커지면 분할하고 연결하라

PRD나 Architecture가 한 파일에 다 들어가면 AI가 매번 거대한 문서를 읽느라 토큰을 낭비한다. 기능 단위로 분할하자. /bmad-shard-doc(분할), /bmad-distillator(압축) 같은 Skill이 이 작업을 도와준다.

/docs
  /prd
    prd-task.md
    prd-dashboard.md
    prd-search.md
  /architecture
    arch-overview.md
    arch-storage.md

검증 단계를 생략하지 마라

BMAD에는 다양한 검토 도구가 있다. 특히 Party Mode는 기획 초기에 빛을 발한다. 한 번에 PM, 아키텍트, QA의 시선을 받을 수 있다.

• /bmad-review-adversarial-general: 비판적 시각으로 약점 찾기 (최소 10개 허점을 찾을 때까지 멈추지 않는다)
• /bmad-review-edge-case-hunter: 엣지 케이스 탐색
• /bmad-code-review: 코드 품질 검토
• /bmad-party-mode: 여러 에이전트가 동시에 토론하며 다각도 검증

패턴이 보이면 Skill로 만들어라

같은 작업 흐름이 반복된다면 자체 Skill로 만들어 두자. 다음 작업부터는 그 Skill을 호출하기만 하면 된다.

7. BMAD를 써본 후의 평가

BMAD를 한 줄로 표현하면 이렇다.

기획이 완벽하지 않으면 코드를 쓸 수 없게 만드는 프로세스

AI가 코드를 잘 짜게 만드는 마법이 아니라, AI가 잘 짤 수 있도록 인간이 더 정확하게 요구사항을 정리하게 강제하는 프레임워크에 가깝다. 그래서 BMAD가 가장 빛나는 순간은 새 프로젝트를 시작하는 순간이다. 업무 관리 툴이든, 사이드 프로젝트든, 사내 도구든 빈 폴더 앞에서 막막할 때 /bmad-brainstorming 한 줄을 두드리면, AI가 단계별로 길을 깔아준다.

반대로, 이미 굴러가는 프로덕트에 작은 버그를 잡거나 기능 한두 개를 꽂는 작업이라면, BMAD는 오히려 무거울 수 있다. quick-dev / quick-spec과의 균형을 잡는 감각이 필요하다. AI 코딩의 다음 단계는 "더 똑똑한 AI"가 아니라, "AI가 똑똑하게 일하도록 만드는 우리의 방법론" 일지도 모른다. BMAD는 그 가능성을 보여주는 흥미로운 시도다.

장점

• 기획의 허점이 빠르게 드러난다. "유저별로 구분한다"는 기획에 로그인 기능이 빠져 있으면 PRD 단계에서 잡힌다.
• PRD가 촘촘해서 구현 결과물이 만족스럽다. 스토리 단위 구현이 흔들리지 않는다.
• AI가 길을 잃지 않는다. 컨텍스트가 비대해지는 걸 문서 분할이 막아준다.

단점

• PRD 만드는 데 시간이 꽤 든다. 간단한 프로그램에는 과한 투자다.
• 수정 한 번 하려면 PRD → Story → Dev 사이클을 다시 돌아야 한다. 이걸 회피하려고 quick-dev를 쓰면 문서와 코드가 어긋난다.
• 기존 프로젝트에 적용하려면 PRD를 거꾸로 만들어야 해서 부담이 크다.

참고

https://docs.bmad-method.org/

Welcome to the BMad Method

https://github.com/bmad-code-org/BMAD-METHOD

GitHub - bmad-code-org/BMAD-METHOD: Breakthrough Method for Agile Ai Driven Development