BMAD Method 튜토리얼 6편: 할 일을 잘게 나누고 하나씩 구현하는 방법

요약#

참고 자료#

• BMAD Method - Getting Started - 구현 단계의 기본 build cycle
• BMAD Method - Workflow Map - Phase 4의 workflow와 산출물
• BMAD Method - Agents - SM, DEV, QA agent와 trigger
• BMAD Method - Skills - workflow skill과 agent menu trigger 차이
• BMAD Method - Testing Options - Quinn과 TEA의 역할 차이

바로 써먹는 템플릿#

6편부터는 agent 방식과 direct workflow skill 방식을 같이 이해하는 편이 좋습니다.

• agent 방식: agent를 먼저 연 뒤, 메뉴 trigger를 입력합니다
• direct skill 방식: 필요한 workflow를 바로 실행합니다

공식 skill 이름은 bmad-create-prd처럼 하이픈(-)이 들어가지만, 사용하는 AI 도구에 따라 bmad create prd처럼 띄어쓰기로 입력하는 편이 더 잘 인식될 수도 있습니다.

구현 단계에서 자주 쓰는 흐름은 아래처럼 보면 됩니다.

여기서 5편과 6편의 차이를 먼저 잡고 가면 덜 헷갈립니다.

• 5편: epics와 stories의 구조를 설계합니다
• 6편: 그 구조 중 다음에 구현할 story 하나를 story 파일로 만들어 구현합니다

참고로 agent 방식의 SP는 Sprint Planning, CS는 Create Story, DS는 Dev Story, CR는 Code Review, ER는 Epic Retrospective의 약자입니다.

먼저 sprint planning부터 시작합니다.

SM agent로 sprint planning을 시작하는 예시

1
bmad-sm
2

3
SP

skill로 sprint planning을 바로 실행하는 예시

1
bmad-sprint-planning
2

3
현재 epics를 기준으로 sprint-status.yaml을 만들어줘.
4
구현 순서와 의존성이 드러나게 정리해줘.

그다음 구현할 story를 하나 만듭니다.

SM agent로 다음 story를 만드는 예시

1
bmad-sm
2

3
CS

skill로 story를 바로 만드는 예시

1
bmad-create-story
2

3
sprint-status를 기준으로 다음 story 파일을 만들어줘.
4
이번 story만 구현 가능한 수준으로 경계를 분명하게 잡아줘.

이제 DEV가 story를 구현합니다.

DEV agent로 story 구현을 시작하는 예시

1
bmad-dev
2

3
DS

skill로 story 구현을 바로 실행하는 예시

1
bmad-dev-story
2

3
방금 만든 story 파일을 기준으로 구현해줘.

구현 뒤에는 story 단위로 코드 리뷰를 붙입니다.

DEV agent로 코드 리뷰를 실행하는 예시

1
bmad-dev
2

3
CR

skill로 코드 리뷰를 바로 실행하는 예시

1
bmad-code-review
2

3
방금 구현한 변경이 story 요구사항과 맞는지 리뷰해줘.
4
빠진 테스트나 위험한 변경이 있으면 같이 지적해줘.

epic이 끝났다면 그때 Quinn 테스트와 회고로 넘어갑니다.

QA agent로 테스트를 시작하는 예시

여기서 QA는 built-in QA agent인 Quinn의 테스트 자동화 trigger입니다.

1
bmad-qa
2

3
QA

skill로 Quinn 테스트를 바로 실행하는 예시

1
bmad-qa-generate-e2e-tests
2

3
이번 epic에서 완성된 기능 기준으로 핵심 사용자 흐름 테스트를 만들어줘.

SM agent로 epic 회고를 시작하는 예시

1
bmad-sm
2

3
ER

skill로 회고를 바로 실행하는 예시

1
bmad-retrospective
2

3
이번 epic 구현에서 잘된 점과 다음 epic에서 바꿔야 할 점을 정리해줘.

이제부터는 epic이 아니라 story 하나만 보면 됩니다#

5편까지 오면 PRD, architecture, epics와 stories가 이미 정리된 상태입니다.
즉 6편의 출발점은 더 이상 “무엇을 만들까?”가 아닙니다.
이제는 이미 정리된 story 구조 중에서 다음 항목 하나를 구현용 story 파일로 뽑아, 어떤 순서로 안전하게 구현할지를 다루게 됩니다.

즉 5편과 6편의 차이는 이렇게 보면 됩니다.

• 5편: story를 어떻게 나눌까
• 6편: 그중 다음 story 하나를 어떻게 구현할까

공식 Getting Started와 Workflow Map은 구현 단계를 아주 단순하게 설명합니다.

1. sprint planning으로 전체 흐름을 잡는다
2. 다음에 구현할 story 파일을 하나 만든다
3. DEV가 그 story를 구현한다
4. story 단위로 코드 리뷰를 한다
5. epic이 끝나면 테스트와 회고로 정리한다

즉 BMAD의 구현 단계는 큰 덩어리를 한 번에 끝내는 방식이 아니라, 작은 작업을 하나씩 끝내는 방식입니다.

왜 sprint planning이 먼저일까요?#

많은 분이 bmad-dev-story부터 바로 쓰고 싶어 합니다.
하지만 공식 문서는 그 전에 bmad-sprint-planning을 먼저 둡니다.

이 단계의 목적은 거창한 계획 문서를 또 만드는 데 있지 않습니다.
이미 만들어 둔 epics를 구현 순서로 정렬하고, 현재 상태를 한눈에 볼 수 있게 만드는 데 있습니다.

공식 문서 기준으로 이 workflow의 결과물은 sprint-status.yaml⁴입니다.
이 파일이 중요한 이유는 분명합니다.

• 지금 어떤 epic이 먼저인지 보입니다
• 다음에 어떤 story를 만들어야 하는지 보입니다
• 구현이 얼마나 진행됐는지 추적할 수 있습니다

즉 sprint planning은 구현을 늦추는 단계가 아니라, 구현 순서를 흔들리지 않게 고정하는 단계입니다.

왜 story 파일을 먼저 만들까요?#

이제 구현 단계니까 바로 코드를 쓰면 될 것 같지만, BMAD는 그 전에 bmad-create-story를 둡니다.

이 workflow의 목적은 단순합니다.
5편에서 이미 만들어 둔 story 구조 중 하나를 골라, 다음에 구현할 story 하나만 따로 떼어서 구현에 필요한 맥락을 그 파일 안에 모아 두는 것입니다.

공식 문서도 bmad-create-story의 산출물을 story-[slug].md라고 설명합니다.
즉 story 파일은 구현자가 바로 읽고 따라갈 수 있는 작업 지시서에 가깝습니다.

이 단계가 필요한 이유도 분명합니다.

• epic 전체를 들고 구현하지 않게 해줍니다
• 이번에 바꿔야 할 범위를 줄여 줍니다
• PRD와 architecture의 핵심 맥락을 story 수준으로 압축해 줍니다

즉 bmad-create-story는 5편에서 만든 story 구조를 실제 구현용 story 파일로 바꾸는 작업입니다.

DEV는 story 단위로 구현합니다#

공식 구현 사이클에서 개발자는 epic 전체를 구현하지 않습니다.
항상 story 하나를 구현합니다.

그래서 Phase 4의 핵심 workflow가 bmad-dev-story입니다.
이름 그대로 story 파일을 읽고, 그 story를 구현하는 데 집중하는 방식입니다.

이 방식이 좋은 이유는 단순합니다.

• 한 번에 바꾸는 범위가 작습니다
• 테스트와 리뷰 범위도 작아집니다
• 실패했을 때 어디서 흔들렸는지 찾기 쉽습니다

즉 BMAD는 구현 속도를 높이기 위해 story 단위를 쓰는 것이 아니라, 구현 품질과 일관성을 지키기 위해 story 단위를 씁니다.

코드 리뷰는 story마다 붙입니다#

공식 Getting Started는 구현 사이클 안에 bmad-code-review를 권장합니다.
이 점이 중요합니다.

많은 사람이 테스트만 있으면 충분하다고 생각하지만, story 단위의 구현은 테스트만으로 다 잡히지 않습니다.
요구사항 누락, 설계와의 불일치, 범위 이탈 같은 문제는 코드 리뷰에서 더 잘 드러나는 경우가 많습니다.

그래서 BMAD의 기본 사이클은 이렇게 읽으면 됩니다.

• story 하나를 만든다
• story 하나를 구현한다
• story 하나를 리뷰한다

이렇게 하면 문제가 커지기 전에 작은 단위에서 잡을 수 있습니다.

Quinn 테스트는 story마다가 아니라 epic마다입니다#

이 부분이 6편에서 특히 중요합니다.
공식 Testing Options 문서는 built-in QA agent인 Quinn을 구현 단계의 테스트 자동화 도구로 설명합니다.

그런데 위치가 중요합니다.
공식 문서 기준으로 Quinn의 자동화는 보통 story마다가 아니라 epic이 끝난 뒤 들어갑니다.

즉 구현 흐름은 이렇게 봐야 합니다.

1. 각 story는 DEV가 구현하고 코드 리뷰를 받습니다
2. epic 전체가 끝나면 Quinn으로 테스트를 만듭니다
3. 마지막으로 retrospective로 정리합니다

왜 이렇게 하느냐도 이해할 수 있습니다.
Quinn은 개별 함수 테스트만이 아니라 API 테스트와 E2E 테스트까지 빠르게 만들어 주는 역할입니다.
즉 한 story의 작은 수정만 보는 도구라기보다, epic 단위로 완성된 사용자 흐름을 점검하는 데 더 잘 맞습니다.

대부분의 프로젝트는 Quinn부터 시작하면 됩니다#

공식 Testing Options 문서는 테스트 경로를 두 가지로 설명합니다.

• Quinn: built-in QA agent
• TEA: 별도 설치하는 Test Architect 모듈

여기서 6편의 기본값은 Quinn입니다.
이유는 간단합니다.

• BMAD 기본 모듈에 포함되어 있습니다
• 빠르게 테스트를 만들 수 있습니다
• 소규모에서 중간 규모 프로젝트에는 대부분 충분합니다

반대로 규정 준수, 추적성, 위험 기반 우선순위 같은 것이 중요하면 TEA를 나중에 검토하면 됩니다.
즉 6편에서는 “대부분은 Quinn부터 시작한다” 정도만 기억하면 충분합니다.

실전 예시: 일정 관리 도구 epic 하나를 구현하는 흐름#

앞선 글에서 계속 예시로 든 내부 일정 관리 도구를 그대로 이어 가보겠습니다.
이미 PRD, architecture, epics/stories는 정리된 상태라고 가정하겠습니다.

이제 구현할 epic이 일정 조회와 생성이라고 해보겠습니다.
이 epic 안에는 예를 들어 아래 story들이 들어갈 수 있습니다.

• 팀 캘린더 목록 조회
• 일정 생성 폼 표시
• 일정 저장 API 연결
• 기본 권한 체크

이 상태에서 BMAD 구현 흐름은 보통 이렇게 갑니다.

구현 단계에서도 fresh chat는 계속 중요합니다#

공식 Getting Started는 구현 단계에서도 각 workflow를 새 대화에서 실행하라고 설명합니다.
이 원칙은 기획 단계에서만 중요한 것이 아닙니다.

story 구현도 마찬가지입니다.

• sprint planning은 sprint planning 대화
• story 생성은 story 생성 대화
• 구현은 구현 대화
• 리뷰는 리뷰 대화

이렇게 분리해야 story 하나의 맥락이 지나치게 커지지 않습니다.
특히 코드 리뷰와 테스트는 구현 대화와 분리돼야 더 냉정하게 볼 수 있습니다.

6편의 핵심은 story 단위 구현이 BMAD의 기본 운영 방식이라는 점입니다#

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

• 구현은 epic 전체가 아니라 story 하나씩 진행합니다
• 구현 전에 sprint-status.yaml과 story 파일로 순서와 범위를 고정합니다
• story마다 bmad-code-review를 붙여 품질을 확인합니다
• epic이 끝나면 Quinn으로 테스트를 만들고 회고로 정리합니다
• 구현 단계에서도 workflow마다 fresh chat를 쓰는 편이 안전합니다

5편이 “story 구조를 어떻게 설계할까”를 설명했다면, 6편은 “그 구조 중 다음 story 하나를 실제 story 파일로 만들고 구현하는 방법”을 설명하는 글입니다.
다음 글에서는 이 흐름을 새 프로젝트가 아니라 이미 존재하는 코드베이스에 붙일 때 무엇이 달라지는지, 그리고 project-context.md가 왜 더 중요해지는지를 다루겠습니다.