BMAD Method 튜토리얼 5편: 왜 설계가 먼저일까? 구현 전에 구조를 잡는 이유

요약#

참고 자료#

• BMAD Method - Why Solutioning Matters - Solutioning이 필요한 이유
• BMAD Method - Preventing Agent Conflicts - architecture 문서가 충돌을 막는 방식
• BMAD Method - Workflow Map - Phase 3의 위치와 산출물
• BMAD Method - Getting Started - architecture, epics/stories, readiness 순서
• BMAD Method - Agents - Architect, PM 역할 구분
• BMAD Method - Skills - 관련 workflow skill 이름

바로 써먹는 템플릿#

5편에서는 agent 이름보다 workflow skill 기준으로 이해하는 편이 덜 헷갈립니다.
공식 docs도 Phase 3의 핵심 흐름을 아래 세 개로 정리합니다.
공식 skill 이름은 bmad-create-prd처럼 하이픈(-)이 들어가지만, 사용하는 AI 도구에 따라 bmad create prd처럼 띄어쓰기로 입력하는 편이 더 잘 인식될 수도 있습니다.

5편의 Solutioning 흐름은 아래 표처럼 이해하면 됩니다.

여기서 만드는 stories는 구현 순서를 정리한 story 구조입니다.
6편의 bmad-create-story는 이 구조 안에서 다음에 구현할 story 하나를 구현용 story 파일로 뽑아내는 단계입니다.

설계 문서부터 만들고 싶다면 이렇게 시작하면 됩니다.

Architecture 문서를 만드는 질문

1
bmad-create-architecture
2

3
지금까지 만든 PRD를 바탕으로 architecture 문서를 만들어줘.
4
인증 방식, API 방식, 데이터 구조, 상태 관리, 디렉터리 구조처럼
5
구현 전에 먼저 정해야 하는 기술 결정을 중심으로 정리해줘.

설계가 정리된 뒤에는 작업 단위 분해를 이렇게 넘기면 됩니다.

Epics와 Stories를 만드는 질문

1
bmad-create-epics-and-stories
2

3
방금 만든 PRD와 architecture 문서를 바탕으로
4
구현 가능한 epic과 story로 나눠줘.
5
각 story는 서로 섞이지 않게 경계를 분명히 잡아줘.

구현 전에 문서들이 잘 맞는지 점검하고 싶다면 이렇게 물어보면 됩니다.

구현 준비 점검을 요청하는 질문

1
bmad-check-implementation-readiness
2

3
현재 PRD, architecture, epics, stories가 서로 잘 맞는지 점검해줘.
4
빠진 문서가 있는지, 충돌하는 결정이 있는지,
5
바로 구현으로 들어가도 되는지도 같이 알려줘.

PRD까지 만들었는데 왜 바로 구현하면 안 될까요?#

여기서 많은 분이 한 번 멈춥니다.
“PRD도 만들었고 요구사항도 적었는데, 왜 바로 구현하면 안 되지?”라는 질문이 자연스럽습니다.

BMAD 공식 문서는 이 지점에서 Planning과 Solutioning을 분리합니다.
이유는 단순합니다.

PRD는 무엇을 만들지와 왜 만드는지를 잘 정리해 줍니다.
하지만 어떻게 만들지까지는 아직 충분히 정해 주지 않습니다.

이 차이를 무시하면 구현 단계에서 문제가 생깁니다.
같은 PRD를 읽고도 구현마다 다른 기술 결정을 내릴 수 있기 때문입니다.

공식 문서가 드는 대표적인 예시는 이런 식입니다.

• 한 구현은 REST 스타일 API를 쓰고
• 다른 구현은 GraphQL 스타일을 쓰고
• 결과적으로 통합 단계에서 충돌이 납니다

즉 PRD만으로는 방향은 맞춰도 구현 방식은 아직 갈라질 수 있습니다.
그래서 BMAD는 구현 전에 한 번 더 구조를 고정하는 단계를 둡니다.
그 단계가 바로 Solutioning입니다.

즉 5편은 아직 구현을 시작하는 단계가 아닙니다.
이 글에서 만드는 것은 구현용 story 파일이 아니라, 나중에 구현 단계에서 꺼내 쓸 epic과 story 구조입니다.

Solutioning은 무엇을 하는 단계일까요?#

공식 Why Solutioning Matters 문서는 Solutioning을 아주 명확하게 설명합니다.

• Planning: 무엇을, 왜 만들까
• Solutioning: 어떻게 만들까, 그리고 어떤 작업 단위로 나눌까

Workflow Map 기준으로 Phase 3에서 하는 일은 세 가지입니다.

• bmad-create-architecture
• bmad-create-epics-and-stories
• bmad-check-implementation-readiness

즉 Solutioning은 설계 문서 하나만 만드는 단계가 아닙니다.
기술 결정을 문서로 고정하고, 그 결정을 바탕으로 구현 단위를 나누고, 마지막으로 바로 구현해도 되는지까지 점검하는 단계입니다.

4편이 아이디어를 PRD로 바꾸는 글이었다면, 5편은 PRD를 실제 구현 가능한 구조로 바꾸는 글입니다.

왜 architecture 문서가 먼저일까요?#

공식 Getting Started 문서는 V6에서 중요한 변화 하나를 강조합니다.
epics와 stories를 architecture 뒤에 만든다는 점입니다.

이 순서가 중요한 이유는 분명합니다.
작업 단위를 어떻게 나눌지, 즉 story 구조를 어떻게 짤지는 기술 결정에 직접 영향을 받기 때문입니다.

예를 들어 아래 같은 결정은 story 구조를 나누는 기준을 바꿉니다.

• API를 어떤 방식으로 만들지
• 인증과 권한을 어디서 처리할지
• 데이터 구조를 어떻게 잡을지
• 상태 관리를 어떤 방식으로 할지
• 테스트를 어떤 조합으로 돌릴지

이런 결정이 없는 상태에서 stories 구조를 먼저 만들면, 나중에 설계가 정해졌을 때 story를 다시 쪼개거나 합쳐야 할 수 있습니다.
즉 architecture가 먼저라는 것은 순서 취향이 아니라, 재작업을 줄이기 위한 구조입니다.

architecture 문서는 무엇을 고정할까요?#

공식 Preventing Agent Conflicts 문서는 architecture 문서가 구현 사이 충돌을 막는 공통 기준이라고 설명합니다.
핵심은 중요한 기술 결정을 명시적으로 적어 둔다는 점입니다.

문서에서 예로 드는 충돌은 이런 것들입니다.

• API 방식 충돌
• 데이터베이스 설계 충돌
• 상태 관리 방식 충돌
• 이름 규칙 충돌
• 보안 접근 방식 충돌

즉 architecture 문서는 멋진 다이어그램을 그리기 위한 문서가 아닙니다.
여러 구현이 제각각 움직이지 않도록, 미리 같은 기준을 읽게 만드는 문서입니다.

공식 문서는 특히 ADR⁷ 스타일을 강조합니다.
중요한 기술 결정마다 아래가 남아야 한다는 뜻입니다.

• 왜 이 결정이 중요한지
• 어떤 선택지가 있었는지
• 무엇을 고른 것인지
• 왜 그렇게 골랐는지
• 어떤 대가를 감수하는지

이 정도까지만 잡혀도 이후 story 구현 품질이 크게 달라집니다.

실전 예시: 일정 관리 도구를 Solutioning으로 넘기는 흐름#

4편에서 예시로 들었던 내부 일정 관리 도구를 그대로 이어 가보겠습니다.
이제는 Product Brief와 PRD가 만들어진 상태입니다.
하지만 아직 아래 같은 결정은 남아 있습니다.

• 인증을 어떻게 처리할지
• 권한을 어떤 구조로 나눌지
• 일정 데이터 구조를 어떻게 잡을지
• 알림 방식을 어떻게 연결할지

이 상태에서 바로 stories 구조를 만들면 경계가 흔들릴 수 있습니다.
그래서 보통은 아래 순서로 갑니다.

1
bmad-create-architecture
2

3
지금까지 만든 PRD와 UX 문서를 바탕으로 architecture 문서를 만들어줘.
4
인증 방식, 권한 구조, API 방식, 일정 데이터 구조,
5
알림 처리 방식, 화면 상태 관리처럼
6
구현 전에 먼저 정해야 하는 기술 결정을 중심으로 정리해줘.

1
bmad-create-epics-and-stories
2

3
방금 만든 PRD와 architecture 문서를 바탕으로
4
구현 가능한 epic과 story 구조로 나눠줘.
5
인증, 일정 조회, 일정 생성/수정, 알림, 관리자 설정처럼
6
서로 경계가 섞이지 않게 나눠줘.

1
bmad-check-implementation-readiness
2

3
현재 PRD, architecture, epics, stories가 서로 잘 맞는지 점검해줘.
4
빠진 결정이 있는지, story 경계가 흔들리는 부분이 있는지,
5
바로 구현 단계로 넘어가도 되는지도 같이 알려줘.

epics와 stories는 왜 architecture 뒤에 올까요?#

이제 감이 잡힙니다.
story는 구현 단위입니다.
다만 5편에서 하는 일은 story 하나를 구현용 파일로 만드는 것이 아니라, story 구조를 먼저 잘 나누는 일입니다.

예를 들어 인증 방식을 아직 못 정했는데 아래처럼 story 구조를 나누면 위험합니다.

• 로그인 화면 만들기
• 세션 저장하기
• 권한 체크 넣기

나중에 인증 방식이 바뀌면 story 경계도 같이 흔들릴 수 있습니다.
반대로 architecture에서 인증 방식과 API 방향이 먼저 정리돼 있으면, story 구조를 훨씬 더 안정적으로 나눌 수 있습니다.

공식 Getting Started 문서가 architecture 이후에 epics와 stories를 만들면, 설계 결정이 반영된 더 현실적인 story 구조가 나온다고 설명하는 이유도 여기에 있습니다.

구현 준비 점검은 왜 필요한가요?#

여기서 많은 분이 또 한 번 “이건 없어도 되지 않나?”라고 생각합니다.
하지만 implementation readiness는 생각보다 중요합니다.

이 단계는 대단한 추가 문서를 만드는 것이 아닙니다.
지금까지 만든 문서들이 서로 잘 맞는지 확인하는 점검 단계입니다.

공식 Workflow Map은 이 단계를 PASS, CONCERNS, FAIL 같은 판단으로 설명합니다.
즉 아래를 확인하는 게 핵심입니다.

• PRD와 architecture가 서로 충돌하지 않는가
• epics와 stories 구조가 설계와 맞게 나뉘었는가
• 빠진 문서나 빠진 결정은 없는가
• 바로 구현으로 넘어가도 되는가

이 점검이 필요한 이유는 분명합니다.
문서를 여러 개 만들었더라도, 서로 안 맞으면 구현 단계에서 다시 흔들리기 때문입니다.
구현 전에 한 번 맞춰 보는 것이, 구현 중간에 충돌을 발견하는 것보다 훨씬 싸게 먹힙니다.

어떤 프로젝트에서 Solutioning이 꼭 필요할까요?#

공식 Why Solutioning Matters 문서는 대략적인 기준도 줍니다.
여러 epic이 있고, 서로 다른 에이전트가 다른 부분을 구현할 수 있다면 Solutioning이 필요하다는 기준입니다.

이걸 한국어로 더 풀면 이렇습니다.

• 기능이 여러 묶음으로 나뉩니다
• 화면, API, 데이터가 함께 얽힙니다
• 구현 담당이 여러 갈래로 갈 수 있습니다
• 한쪽 결정이 다른 쪽 구현에도 영향을 줍니다

이런 프로젝트라면 architecture를 건너뛰면 안 됩니다.
반대로 한 파일 안에서 끝나는 작은 변경이라면 3편의 Quick Flow가 더 맞습니다.

즉 5편의 메시지는 단순합니다.
작업이 여러 갈래로 퍼질수록, 구현 전에 구조를 먼저 잡아야 합니다.

Solutioning을 건너뛰면 어떤 일이 생길까요?#

공식 문서는 비용도 분명하게 말합니다.
정렬 문제를 Solutioning에서 잡는 것이, 구현 중간에 발견하는 것보다 훨씬 빠르다고 설명합니다.

실제로 생기는 문제도 현실적입니다.

• 구현 중간에 통합 이슈가 터집니다
• 서로 다른 방식으로 만든 코드 때문에 재작업이 생깁니다
• 일정이 길어지고 기술 부채가 쌓입니다
• 나중에 story를 다시 쪼개거나 합쳐야 합니다

즉 Solutioning을 생략하는 것은 속도를 얻는 것이 아니라, 뒤에서 더 큰 비용을 미루는 경우가 많습니다.
이 단계가 길어 보일 수는 있어도, 여러 에이전트가 들어가는 프로젝트에서는 오히려 시간을 아껴 줍니다.

5편의 핵심은 설계가 구현을 덜 흔들리게 만든다는 점입니다#

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

• PRD는 무엇을 만들지 정리하지만, 어떻게 만들지는 아직 충분히 정하지 않습니다
• Solutioning은 architecture와 epics/stories 구조로 구현 기준을 고정하는 단계입니다
• architecture 문서는 여러 구현이 같은 방향으로 움직이게 만드는 공통 기준입니다
• 구현 전 readiness 점검까지 해야 문서들이 실제로 맞물립니다

4편이 아이디어를 PRD로 바꾸는 글이었다면, 5편은 PRD를 구현 가능한 구조와 작업 단위의 뼈대로 바꾸는 글입니다.
다음 글에서는 여기서 정리한 story 구조 중 다음 항목 하나를 실제 story 파일로 만들고 구현하는 흐름을 다루겠습니다.