BMAD Method 튜토리얼 3편: 작은 작업을 빠르게 끝내는 BMAD 사용법

요약#

참고 자료#

• BMAD Method - Quick Flow - Quick Flow의 철학과 경계
• BMAD Method - Quick Dev - Quick Dev의 설계 의도
• BMAD Method - Quick Fixes - 작은 변경을 처리하는 실전 가이드
• BMAD Method - Getting Started - Quick Flow와 full method 구분
• BMAD Method - Workflow Map - Quick Flow가 전체 흐름에서 차지하는 위치
• BMAD Method - Skills - bmad-quick-spec, bmad-quick-dev 같은 skill 이름
• BMAD Method - How to Get Answers About BMad - Quick Flow로 가는 가장 빠른 질문 방식

바로 써먹는 템플릿#

공식 BMAD docs 기준으로 3편의 Quick Flow는 bmad-quick-spec, bmad-quick-dev 같은 direct workflow skill과, 더 작은 수정에 바로 들어가는 bmad-dev agent를 함께 이해하는 편이 가장 안전합니다.
공식 skill 이름은 bmad-create-prd처럼 하이픈(-)이 들어가지만, 사용하는 AI 도구에 따라 bmad create prd처럼 띄어쓰기로 입력하는 편이 더 잘 인식될 수도 있습니다.

작은 작업에서는 아래 표처럼 이해하면 가장 빠릅니다.

여기서 bmad-dev는 direct workflow skill이 아니라 DEV agent를 여는 skill입니다.
즉 아주 작은 수정은 direct workflow 하나로 처리한다기보다, DEV agent를 바로 열어 처리하는 쪽에 가깝습니다.

작은 작업인지 애매할 때는 먼저 이렇게 물어보면 됩니다.

작업 크기부터 판단받는 질문

1
bmad-help
2

3
이 작업이 Quick Flow로 끝낼 수 있는 수준인지 판단해줘.
4
범위가 작다면 바로 어떤 방식으로 시작하면 되는지도 알려줘.
5

6
작업 내용:
7
로그인 폼에서 비밀번호가 비어 있어도 제출되는 버그를 고치고 싶어.
8
변경 범위는 인증 관련 파일 안으로 최대한 제한하고 싶어.

작은 작업인데도 먼저 기준을 짧게 정리하고 싶다면 이렇게 시작하면 됩니다.

Quick Spec부터 만드는 질문

1
bmad-quick-spec
2

3
사용자 프로필 페이지에서 닉네임 수정 후 저장 버튼이 비활성화된 채로 남는 버그를 고치고 싶어.
4
변경 범위는 프로필 화면과 관련 상태 처리까지로 제한해줘.
5
테스트가 있다면 같이 손보는 방향으로 quick-spec을 만들어줘.

기준이 정리됐다면 bmad-quick-dev에 만들어진 문서를 넘겨 구현하면 됩니다.

Quick Dev로 구현 요청하는 질문

1
bmad-quick-dev "quick-spec에서 만들어진 문서.md"

작은 작업이라고 다 같은 것은 아닙니다#

BMAD를 처음 쓰면 이런 생각이 들기 쉽습니다.
“작은 작업도 일단 BMAD로 처리하면 되는 것 아닌가?”

맞는 말이지만, 그 안에서도 경로를 나눠야 합니다.
공식 문서는 작은 작업용 경로를 하나만 두지 않습니다.
아주 작은 수정은 DEV agent로 바로 들어가고, 조금 더 큰 작은 작업은 Quick Flow로 처리하라고 설명합니다.

즉 BMAD의 핵심은 무조건 문서를 많이 만드는 것이 아닙니다.
작업 크기에 맞는 가장 작은 안전 경로를 고르는 데 있습니다.

BMAD에서 가장 빠른 길은 두 가지입니다#

작은 작업을 처리할 때는 크게 두 갈래로 보면 이해가 쉽습니다.

이 구분이 중요합니다.
많은 분이 “작은 작업이니까 그냥 빨리 구현하자”라고 생각하지만, 실제로는 작은 작업도 두 종류가 있습니다.

• 바로 고쳐도 되는 작은 작업
• 작지만 기준을 한 번 정리하고 들어가야 하는 작업

BMAD는 이 둘을 섞지 않게 해줍니다.

실전 예시 1: bmad-dev로 바로 끝내는 작은 버그 수정#

예를 들어 로그인 폼에서 비밀번호를 비워 둬도 제출되는 버그가 있다고 해보겠습니다.
원인도 비교적 선명하고, 인증 관련 파일 몇 개만 보면 될 가능성이 높습니다.
이럴 때는 굳이 quick-spec까지 만들지 않고 DEV agent를 직접 열어 바로 들어가는 편이 더 빠릅니다.

아주 작은 버그를 바로 고치는 요청

1
bmad-dev
2

3
로그인 폼에서 비밀번호 입력값이 비어 있어도 제출되는 버그를 고쳐줘.
4
변경 범위는 로그인 폼과 제출 검증 로직으로 최대한 제한하고,
5
기존 테스트가 있다면 같이 맞춰줘.
6
끝나면 어떤 파일이 바뀌었는지와 테스트 결과를 같이 알려줘.

이 예시가 bmad-dev에 맞는 이유는 분명합니다.

• 문제 원인이 비교적 선명합니다
• 변경 범위가 넓지 않습니다
• 별도의 기획 문서 없이도 바로 구현해도 흔들릴 가능성이 작습니다

Quick Flow는 무엇을 생략할까요?#

Quick Flow의 핵심은 이름 그대로 절차를 줄인다는 데 있습니다.
공식 문서는 Quick Flow가 Product Brief, PRD, Architecture, Epic/Story 분해를 건너뛴다고 설명합니다.

대신 이 모든 것을 tech-spec⁴ 하나로 압축합니다.
즉 문서를 아예 없애는 것이 아니라, 작은 작업에 맞는 최소 문서 하나로 줄이는 것입니다.

이 방식이 가능한 이유도 공식 문서가 분명하게 설명합니다.

• 제품 방향은 이미 정해져 있습니다
• 큰 아키텍처 결정은 이미 끝나 있습니다
• 한 사람이 전체 범위를 이해할 수 있습니다
• 요구사항이 한 대화 안에 들어올 정도로 작습니다

이 조건이 맞을 때는 PRD와 architecture를 다시 만드는 것이 오히려 과합니다.
Quick Flow는 바로 그 지점을 노립니다.

실전 예시 2: quick-spec을 거쳐 처리하는 작은 화면 수정#

반대로 프로필 화면에서 닉네임을 수정한 뒤에도 저장 버튼이 계속 비활성화된 채로 남는 버그는 조금 다를 수 있습니다.
화면 상태, 폼 로직, 저장 완료 후 처리까지 함께 볼 가능성이 있어서, 짧게라도 기준을 먼저 고정하는 편이 안전합니다.

이럴 때는 보통 아래 순서로 갑니다.

1
bmad-quick-spec
2

3
프로필 페이지에서 닉네임을 수정하고 저장한 뒤에도
4
저장 버튼이 비활성화된 상태로 남는 문제를 고치고 싶어.
5
변경 범위는 프로필 화면과 관련 상태 처리까지로 제한하고,
6
기존 동작을 크게 바꾸지 않는 선에서 quick-spec을 만들어줘.

1
bmad-quick-dev "quick-spec에서 만들어진 문서.md"

Quick Flow가 잘 맞는 작업#

공식 문서들을 합쳐 보면 Quick Flow나 Quick Fixes가 잘 맞는 작업은 꽤 분명합니다.

• 원인이 비교적 선명한 버그 수정
• 몇 개 파일 안에서 끝나는 작은 리팩터링
• 설정 변경이나 의존성 업데이트
• 범위가 분명한 작은 기능 추가
• 짧게 검증해 보는 실험성 작업

Getting Started 문서는 Quick Flow를 대략 1~15 stories 수준의 범위가 분명한 작업으로 설명합니다.
즉 “작다”는 말이 단순히 코드 줄 수를 뜻하는 것은 아닙니다.
한 사람이 범위를 붙잡고 끝까지 갈 수 있는가가 더 중요합니다.

Quick Flow에서도 먼저 기준을 잡는 이유#

이 대목이 핵심입니다.
Quick Flow는 문서를 줄이지만, 기준을 아예 없애지는 않습니다.

공식 Quick Dev 문서는 먼저 사용자의 intent⁵, 즉 이번 작업의 핵심 의도를 짧고 분명하게 정리한다고 설명합니다.
사용자의 요청이 아직 거칠고 불완전해도, 실행 전에 “이번에 정확히 무엇을 바꾸려는가”를 한 문장으로 붙잡아야 한다는 뜻입니다.

그래서 Quick Flow에서도 quick-spec이 중요합니다.
이 문서는 거대한 설계 문서가 아닙니다.
하지만 “이번 변경은 정확히 무엇을 어디까지 바꾸는가”를 고정하는 경계선 역할을 합니다.

이 경계선이 없으면 작은 작업도 쉽게 커집니다.
버그 하나를 고치려다 인증 전체를 건드리고, 화면 버튼 하나를 손보려다 상태 관리 구조를 뜯게 되는 식입니다.
Quick Flow는 그 미끄러짐을 줄이기 위해 아주 짧은 문서를 먼저 둡니다.

실제 흐름은 이렇게 움직입니다#

Quick Flow나 Quick Fixes 문서를 보면 실제 흐름은 생각보다 단순합니다.

이럴 때는 바로 BMad 정식 플로우로 올라가세요#

Quick Flow가 편하다고 해서 모든 작업을 여기로 밀어 넣으면 안 됩니다.
공식 Quick Flow 문서는 작업 범위를 판단하고, 필요하면 BMad 정식 플로우로 올리는 기준을 분명하게 넣어 둡니다.

아래 상황이면 BMad 정식 플로우로 올리는 편이 맞습니다.

• 여러 시스템이나 여러 컴포넌트를 함께 건드립니다
• 요구사항이 아직 애매해서 질문이 길어집니다
• 데이터 구조나 API 형태를 먼저 정해야 하는 아키텍처 결정이 필요합니다
• 팀 문서로 남겨야 할 결정이 많습니다
• 작업이 진행될수록 계속 커집니다

Quick Flow의 장점은 빠름입니다.
하지만 빠름은 경계가 분명할 때만 장점이 됩니다.
경계가 흐려지는 순간부터는 BMad 정식 플로우가 오히려 더 빠르고 덜 위험합니다.

3편의 핵심은 가장 작은 안전 경로를 고르는 법입니다#

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

• 원인이 명확한 아주 작은 변경은 bmad-dev로 바로 갈 수 있습니다
• 작지만 기준을 짧게 정리해야 하는 작업은 Quick Flow가 더 잘 맞습니다
• 조금이라도 여러 시스템과 설계 판단이 걸리면 BMad 정식 플로우로 올려야 합니다

BMAD를 무겁게 느끼는 가장 큰 이유는 모든 작업을 같은 방식으로 처리하려고 할 때입니다.
반대로 작업 크기에 맞는 경로를 고르면 BMAD는 훨씬 현실적인 도구가 됩니다.

다음 글에서는 여기서 한 단계 더 올라가서, Quick Flow를 넘는 순간 어떤 문서가 필요해지는지, 그리고 아이디어를 어떻게 PRD로 바꾸는지를 다루겠습니다.