BMAD Method 튜토리얼 4편: 아이디어를 PRD로 바꾸는 BMAD 기획 흐름

요약#

참고 자료#

• BMAD Method - Getting Started - Analysis, Planning, Solutioning 전체 흐름
• BMAD Method - Workflow Map - 각 문서가 다음 단계의 컨텍스트가 되는 구조
• BMAD Method - Brainstorming - brainstorming workflow의 목적
• BMAD Method - Agents - Analyst, PM, UX Designer 역할

바로 써먹는 템플릿#

4편부터는 문서를 두 가지 방식으로 만들 수 있다고 보면 됩니다.

• agent를 먼저 불러서 메뉴 안에서 진행하는 방법
• 필요한 skill을 바로 실행하는 방법

공식 문서 기준으로 둘 다 가능한 흐름입니다.
처음에는 agent 방식이 덜 헷갈리고, 익숙해지면 bmad-create-prd 같은 skill을 바로 실행하는 편이 더 빠릅니다.
공식 skill/agent 이름은 bmad-create-prd처럼 하이픈(-)이 들어가지만, 사용하는 AI 도구에 따라 bmad create prd처럼 띄어쓰기로 입력하는 편이 더 잘 인식될 수도 있습니다.

4편의 기획 흐름은 아래 표처럼 보면 됩니다.

참고로 공식 docs 안에서도 agent 표기가 일부 섞여 있습니다.
이 글에서는 reference/agents와 reference/commands에 맞춰 bmad-analyst, bmad-pm, bmad-ux-designer 표기를 기준으로 씁니다.

아이디어가 아직 흐리고 방향부터 넓게 보고 싶다면 두 가지 방식이 있습니다.

Analyst agent로 브레인스토밍을 시작하는 예시

여기서 BP는 Brainstorm Project의 약자입니다.

1
bmad-analyst
2

3
BP

skill로 브레인스토밍을 바로 실행하는 예시

1
bmad-brainstorming
2

3
우리 팀이 내부적으로 쓸 일정 관리 도구 아이디어를 같이 정리하고 싶어.
4
지금은 기능보다도 어떤 문제를 먼저 풀어야 하는지,
5
누가 가장 자주 쓰게 될지,
6
비슷한 도구와 다르게 가져갈 포인트가 무엇인지부터 넓게 생각해보고 싶어.

리서치가 필요하다면 이 단계도 agent나 skill 둘 다 가능합니다.
중요한 점은 RS가 특정한 한 종류의 조사만 뜻하는 것이 아니라, 상황에 따라 시장 조사, 도메인 조사, 기술 조사를 모두 포함하는 일반적인 Research라는 점입니다.

Analyst agent로 리서치를 시작하는 예시

여기서 RS는 Research의 약자입니다.

1
bmad-analyst
2

3
RS

skill로 시장 조사를 바로 실행하는 예시

1
bmad-market-research
2

3
우리 팀이 만들려는 내부 일정 관리 도구와 비슷한 서비스들이
4
보통 어떤 기능을 먼저 제공하는지 정리해줘.
5
캘린더 공유, 반복 일정, 알림, 권한 관리 쪽에서
6
사용자가 중요하게 느끼는 기준이 무엇인지도 같이 보고 싶어.

브레인스토밍과 리서치로 방향이 어느 정도 잡혔다면 이제 brief 문서로 정리하면 됩니다.

Analyst agent에서 brief를 만드는 예시

여기서 CB는 Create Brief의 약자입니다.

1
bmad-analyst
2

3
CB

skill로 Product Brief를 바로 만드는 예시

1
bmad-create-product-brief
2

3
앞서 정리한 브레인스토밍 내용과 리서치 메모를 바탕으로
4
우리 팀이 내부적으로 쓸 일정 관리 도구에 대한 product brief를 만들어줘.
5
누가 왜 써야 하는지,
6
어떤 문제를 먼저 해결해야 하는지,
7
이번 범위에 무엇을 넣고 무엇을 빼야 하는지,
8
성공 기준이 무엇인지가 드러나게 정리해줘.

아이디어가 어느 정도 정리됐다면 PRD는 PM 단계로 넘기면 됩니다.

PM agent에서 PRD를 만드는 예시

여기서 CP는 Create PRD의 약자입니다.

1
bmad-pm
2

3
CP

skill로 PRD를 바로 만드는 예시

1
bmad-create-prd
2

3
방금 정리한 product brief를 바탕으로 PRD를 만들어줘.
4
기능 요구사항과 비기능 요구사항이 구분되게 작성하고,
5
나중에 architecture와 stories로 이어질 수 있게 범위와 제약도 분명히 적어줘.

화면이 중요한 제품이라면 UX도 같은 방식으로 이어갈 수 있습니다.

UX Designer agent에서 UX 문서를 만드는 예시

여기서 CU는 Create UX Design의 약자입니다.

1
bmad-ux-designer
2

3
CU

skill로 UX 문서를 바로 만드는 예시

1
bmad-create-ux-design
2

3
지금까지 정리한 brief와 PRD를 바탕으로 UX 문서를 만들어줘.
4
핵심 화면, 주요 사용자 흐름, 중요한 상태 변화가 드러나게 정리해줘.

Quick Flow로 끝나지 않는 순간이 옵니다#

3편에서 본 Quick Flow는 정말 유용합니다.
버그 수정이나 작은 리팩터링처럼 범위가 좁은 작업에서는, 짧은 기준 문서만 있어도 바로 구현으로 들어갈 수 있습니다.

하지만 어떤 작업은 금방 그 선을 넘습니다.
요구사항이 여러 개로 갈라지고, 누가 왜 써야 하는지부터 정리해야 하고, 화면 흐름과 역할 구분까지 생각해야 한다면 더 이상 Quick Flow의 영역이 아닙니다.

이때 필요한 것이 BMAD의 Analysis와 Planning입니다.
공식 문서도 Quick Flow는 작은 변화용 경로이고, 제품이나 플랫폼, 큰 기능은 BMad Method 트랙으로 들어가라고 설명합니다.

즉 4편의 출발점은 단순합니다.
“이제는 구현보다 먼저 기획 문서가 필요한 크기인가?”를 판단하는 것입니다.

4편부터는 문서와 agent를 같이 보는 편이 더 쉽습니다#

공식 문서를 보면 이 단계에서는 문서 이름만 외우는 것보다, 어떤 agent가 어떤 문서를 맡는지 같이 보는 편이 이해가 쉽습니다.

• Analyst: 브레인스토밍, 리서치, Product Brief
• PM: PRD
• UX Designer: UX 문서

즉 4편부터는 “문서를 만든다”와 “누가 그 문서를 만든다”를 같이 붙여서 기억하는 편이 낫습니다.
직접 skill을 바로 실행해도 되지만, 처음에는 agent를 먼저 열고 메뉴 안에서 움직이는 방식이 덜 헷갈립니다.

실전 예시: 브레인스토밍에서 PRD까지 이어 가는 흐름#

예를 들어 팀 내부용 일정 관리 도구를 만든다고 해보겠습니다.
캘린더 공유, 반복 일정, 알림, 권한 관리가 얽혀 있고, 누가 왜 써야 하는지부터 아직 더 정리해야 하는 상태입니다.
이럴 때는 바로 구현 얘기로 들어가기보다 아래 순서로 문서를 쌓아 가는 편이 훨씬 안정적입니다.

1
bmad-brainstorming
2

3
우리 팀이 내부적으로 쓸 일정 관리 도구 아이디어를 같이 정리하고 싶어.
4
지금은 기능 목록보다도,
5
어떤 문제를 먼저 풀어야 하는지,
6
누가 가장 자주 쓰게 될지,
7
기존 방식의 불편이 무엇인지부터 정리하고 싶어.

1
bmad-market-research
2

3
팀 일정 관리 도구와 비슷한 서비스들이
4
보통 어떤 기능을 먼저 제공하는지 정리해줘.
5
캘린더 공유, 반복 일정, 알림, 권한 관리 쪽에서
6
사용자가 중요하게 느끼는 기준도 같이 알고 싶어.

1
bmad-create-product-brief
2

3
앞서 정리한 브레인스토밍 내용과 리서치 메모를 바탕으로
4
우리 팀이 내부적으로 쓸 일정 관리 도구에 대한 product brief를 만들어줘.
5
누가 왜 써야 하는지,
6
어떤 문제를 먼저 해결해야 하는지,
7
이번 범위에 무엇을 넣고 무엇을 빼야 하는지,
8
성공 기준이 무엇인지가 드러나게 정리해줘.

1
bmad-create-prd
2

3
방금 정리한 product brief를 바탕으로 PRD를 만들어줘.
4
기능 요구사항과 비기능 요구사항이 구분되게 작성하고,
5
나중에 architecture와 stories로 이어질 수 있게
6
범위와 제약도 분명히 적어줘.

1
bmad-create-ux-design
2

3
지금까지 정리한 brief와 PRD를 바탕으로 UX 문서를 만들어줘.
4
핵심 화면, 주요 사용자 흐름, 중요한 상태 변화가 드러나게 정리해줘.

BMAD에서 기획은 한 번에 끝나지 않습니다#

BMAD의 좋은 점은 아이디어를 바로 PRD로 밀어 넣지 않는다는 점입니다.
공식 Workflow Map을 보면 Analysis와 Planning이 분리되어 있습니다.

• Analysis: 문제와 방향을 탐색하는 단계
• Planning: 실제로 무엇을 만들지 요구사항으로 정리하는 단계

이 구분이 중요한 이유는 분명합니다.
아이디어가 아직 흐린 상태에서 PRD를 쓰면, 요구사항 문서가 아니라 추측 문서가 되기 쉽기 때문입니다.

반대로 Analysis를 통해 문제, 사용자, 목표, 범위를 먼저 정리하면, Planning 단계의 PRD가 훨씬 선명해집니다.
즉 BMAD는 문서를 많이 만들기 위해 단계를 나누는 것이 아니라, 각 문서가 서로 다른 질문에 답하게 만들기 위해 단계를 나눕니다.

Analysis 단계에서는 무엇을 할까요?#

공식 Getting Started와 Workflow Map 기준으로 Analysis는 선택 단계입니다.
즉 항상 모든 문서를 다 만들 필요는 없습니다.

여기서 주로 쓰는 흐름은 세 가지입니다.

Product Brief가 중요한 이유#

많은 사람이 PRD부터 쓰고 싶어 합니다.
하지만 product brief를 먼저 거치면 PRD가 훨씬 좋아집니다.

이유는 간단합니다.
PRD는 요구사항 문서이고, product brief는 방향 문서이기 때문입니다.

product brief가 없으면 PRD는 기능 목록으로 흐르기 쉽습니다.
반대로 brief가 있으면 PRD는 아래 질문에 더 잘 답하게 됩니다.

• 이 기능이 왜 필요한가
• 누가 주 사용자인가
• 이번 범위에 포함되는 것과 빠지는 것은 무엇인가
• 성공 기준은 무엇인가

즉 brief는 짧지만, 이후 문서 전체의 중심을 잡아줍니다.
Quick Flow에서 quick-spec이 경계선 역할을 하듯, BMad 정식 플로우에서는 product-brief가 방향 역할을 합니다.

Planning 단계부터는 PRD가 중심이 됩니다#

공식 문서는 Planning을 required 단계로 설명합니다.
여기서 중심이 되는 문서는 PRD.md입니다.

이 단계에서는 보통 PM agent를 불러 bmad-create-prd를 실행합니다.
핵심은 이제부터 문서가 “아이디어 설명”이 아니라 “요구사항 명세”로 바뀐다는 점입니다.

PRD에서 적어도 정리돼야 하는 것은 이런 것들입니다.

• 어떤 사용자 문제를 해결하는가
• 반드시 들어가야 할 기능은 무엇인가
• 비기능 요구사항은 무엇인가
• 범위 밖의 항목은 무엇인가
• 이후 architecture 단계에서 중요해질 제약은 무엇인가

공식 Workflow Map도 bmad-create-prd의 목적을 FRs⁶와 NFRs⁷를 정리하는 일로 설명합니다.
즉 PRD는 “하고 싶은 것”을 적는 문서가 아니라, 기능 요구사항과 비기능 요구사항을 구조적으로 정리하는 문서입니다.

PRD는 구현 문서가 아니라 다음 단계를 위한 문서입니다#

이 부분이 중요합니다.
PRD를 읽을 사람은 지금 당장의 개발자만이 아닙니다.
그 다음 단계의 architect와 PM, 그리고 이후 story를 만드는 agent까지 모두 이 문서를 기반으로 움직입니다.

그래서 PRD는 구현 세부 코드보다 아래 질문에 강해야 합니다.

• 무엇이 필수이고 무엇이 선택인가
• 어떤 제약이 절대 깨지면 안 되는가
• 어떤 사용자 흐름이 핵심인가
• 어떤 품질 기준이 필요한가

즉 PRD는 코드를 바로 쓰기 위한 문서가 아니라, architecture와 stories가 흔들리지 않도록 중심을 잡아주는 문서입니다.
이 점을 이해하면 “왜 BMAD가 PRD를 먼저 만들까?”가 훨씬 자연스럽게 보입니다.

UX 문서는 언제 추가하면 될까요?#

공식 문서는 UX를 optional로 둡니다.
즉 모든 프로젝트에 반드시 필요한 것은 아닙니다.

하지만 아래 경우라면 UX 문서를 붙이는 편이 좋습니다.

• 화면이 여러 개입니다
• 사용자 흐름이 중요합니다
• 상태 변화가 많습니다
• 관리자/일반 사용자처럼 역할이 나뉩니다
• 나중에 architecture와 stories가 화면 흐름에 크게 영향을 받습니다

예를 들어 내부 관리 도구라도 화면이 많고 권한이 복잡하다면 UX 문서가 큰 도움이 됩니다.
반대로 API 중심 서비스나 백엔드 배치 작업이라면 UX는 생략해도 됩니다.

중요한 것은 UX 문서를 무조건 만드는 것이 아니라, 화면과 사용자 흐름이 중요한 제품에서 이를 PRD 옆에 나란히 두는 것입니다.
그래야 다음 단계에서 architecture와 stories가 더 현실적으로 나옵니다.

실제로는 이런 순서로 가면 됩니다#

작은 작업을 넘는 프로젝트라면, 4편 기준으로는 아래 순서가 가장 자연스럽습니다.

이 단계에서 너무 오래 머물 필요는 없습니다#

기획 문서를 만든다고 해서 몇 날 며칠을 문서만 붙잡고 있을 필요는 없습니다.
BMAD의 목적은 문서 자체가 아니라, 다음 단계의 AI가 덜 흔들리게 만드는 것입니다.

즉 4편에서 중요한 것은 “문서를 많이 만들자”가 아닙니다.
“필요한 문서만 만들고, 다음 단계가 혼동하지 않을 정도로만 분명하게 만들자”에 가깝습니다.

이 기준을 놓치면 Analysis와 Planning도 쉽게 과해집니다.
작은 프로젝트를 거대한 문서 작업으로 만들기 시작하면 BMAD는 금방 무거워집니다.
그래서 3편의 Quick Flow와 4편의 BMad 정식 플로우 사이 경계를 계속 의식해야 합니다.

4편의 핵심은 아이디어를 문서 흐름으로 바꾸는 법입니다#

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

• 아이디어가 아직 흐리면 brainstorming부터 시작합니다
• product brief는 PRD보다 가볍지만 방향을 잡는 데 중요합니다
• Planning 단계의 중심 문서는 PRD입니다
• UI가 중요하면 UX 문서를 붙여 다음 단계의 혼란을 줄입니다

3편이 “작은 작업은 가장 작은 안전 경로로 처리하자”는 글이었다면, 4편은 “작은 작업을 넘는 순간부터는 문서가 필요하다”는 글입니다.
다음 글에서는 이 문서들이 왜 구현 전에 architecture로 이어져야 하는지, 그리고 왜 BMAD가 solutioning을 그렇게 강조하는지를 본격적으로 다루겠습니다.