본문으로 건너뛰기

개발 경로 선택하기

이 가이드에서는 소프트웨어 변경을 안전하게 처리할 수 있는 가장 간단한 BMad 경로를 선택하는 방법을 설명합니다.

BMad 루프에서는 막연한 생각은 구체화부터, 명확한 아이디어는 계획부터, 작은 변경은 구현부터 시작하며 학습 결과는 다시 계획에 반영됩니다.

모든 경로는 같은 전달 루프를 사용합니다. 큰 작업은 루프에 공동 컨텍스트를 더하고 구현 단위를 반복할 뿐, 별도의 전달 체계로 바뀌지 않습니다.

  • 변경을 시작하기 전에 어느 정도의 계획이 필요한지 확신이 없을 때
  • 하나의 요청이 단일 구현 세션을 넘어섰을 때
  • 직접 살펴볼 스토리와 무인으로 실행할 스토리를 나눌 때
  • 공동 제품 의도를 잃지 않으면서 여러 에픽을 조율할 때

선호하는 워크플로가 아니라 구현하려는 의도부터 살펴보세요. 하나의 구현 세션에서 변경을 이해하고 구현·검토해 끝낼 수 있는지 판단합니다.

작업 범위만으로 결정하지 마세요. 위험도가 높거나 요구사항이 불명확하거나 아키텍처 전반에 영향을 주는 작업, 여러 시스템에 걸친 작업, 사람이나 팀 간 조율이 필요한 작업에는 더 많은 계획이 필요합니다.

아래 세션 수는 요구사항이 아니라 참고 기준입니다. 작은 보안 변경이 훨씬 큰 일반 작업보다 더 체계적인 접근을 요구할 수도 있습니다.

경로사용 시점시작점
단순 작업편집 내용이 명확하고 위험도가 낮으며 체계적인 리뷰의 이점이 없을 때직접 편집
단일 세션 작업하나의 일관된 의도를 구현 세션 하나에서 처리할 수 있을 때bmad-build
에픽 규모 작업하나의 일관된 결과를 얻는 데 여러 구현 세션이 필요할 때bmad-spec, 이후 스토리 분해
프로젝트 규모 작업여러 에픽에 걸치거나 구현 세션이 약 20회 이상 필요할 가능성이 있을 때전체 BMad 흐름

네 가지 중첩 경로는 직접 편집, Build 한 번 실행, 에픽 안에서 Build 반복, 프로젝트 안에서 에픽 경로 반복이라는 같은 구현 단위를 재사용합니다.

작은 변경이라도 명시적인 계획과 리뷰가 도움이 된다면 직접 편집하는 대신 bmad-build를 사용하세요.

3. 단순 작업 또는 단일 세션 작업 시작

섹션 제목: “3. 단순 작업 또는 단일 세션 작업 시작”

단순 작업은 평소 개발 도구로 직접 변경하세요. 안전성이나 명확성을 높이지 못하는 워크플로 단계는 추가하지 않습니다.

단일 세션 작업은 원하는 결과를 Build에 바로 전달합니다.

/bmad-build diffsettings 명령에 JSON 출력을 추가하되 기존 형식은 바꾸지 마.

Build는 직접 작성한 의도, 이슈, 의도 파일, 기존 Build 사양 또는 계획된 스토리를 입력으로 받을 수 있습니다. 작업 단위를 명확히 하고 필요하면 계획한 뒤 구현하고 결과를 검토해 작업 기록을 남깁니다. 구현 모델은 변경 사항 구현하기를 참고하세요.

여러 Build 세션이 필요하지만 하나의 일관된 결과를 목표로 한다면 가벼운 에픽 경로를 사용하세요.

에픽 정의 및 분할

  1. 에픽 의도를 입력해 bmad-spec을 실행합니다.
  2. 스토리 분해(Story Breakdown)를 요청합니다. SPEC.md 옆에 순서가 지정된 stories.yaml이 생성됩니다.
  3. 제안된 순서를 검토하고 어느 스토리에 체크포인트가 필요한지 정합니다.

스토리 목록은 실행 계획이지 앞으로 아무것도 바뀌지 않는다는 약속이 아닙니다. 앞선 작업에서 누락된 제약, 더 나은 분할 방식 또는 스토리 간 충돌이 드러나면 사양을 수정하고 스토리 분해를 다시 실행하세요.

구현 패턴 확립

중요하거나 위험도가 높거나 기반이 되는 스토리는 bmad-build로 구현하세요. 초기 스토리는 아키텍처, 프로젝트의 초기 구조, 이후 작업에서 반복할 패턴을 정하는 경우가 많습니다. 이 결정에 사람이 주의를 기울인 뒤 반복 작업을 자동화하세요.

스토리마다 Build를 한 번 실행합니다. Build는 사양 폴더 아래에 해당 스토리의 구현 기록을 만들거나 기존 기록을 이어가며 상위 사양과의 연결을 유지합니다.

에픽 완료

각 스토리만 따로 확인하지 말고 모든 스토리가 함께 작동하는지 검증하세요. 그런 다음 사양 폴더를 지정해 bmad-retrospective를 실행합니다. Retrospective는 stories.yaml을 에픽 목록으로 읽고 상위 사양을 기준으로 전체 결과를 평가합니다.

새 제품을 만들거나 여러 에픽으로 구성된 이니셔티브를 진행하거나 구현 세션이 약 20회 이상 필요할 가능성이 있다면 전체 BMad 흐름을 사용하세요.

프로젝트에 실제로 필요한 계획을 준비합니다. 탐색, 제품 요구사항, UX, 아키텍처, 에픽, 준비도 확인, 스프린트 계획이 여기에 포함됩니다. 이 산출물은 구현을 둘러싼 공동 계약과 조율 기준을 만들지만 Build를 대신하지는 않습니다. 각 에픽은 여전히 세션 단위 작업의 연속으로 구현됩니다.

의존성과 통합 경계가 명확하다면 서로 독립적인 에픽 흐름을 병렬로 진행할 수 있습니다. 각 흐름에는 담당자가 있어야 하며 모든 흐름은 같은 제품 의도와 아키텍처를 따라야 합니다. 에픽 경계마다 통합 검사와 회고를 실행하세요.

6. 결정이 안정된 뒤 자동화 추가

섹션 제목: “6. 결정이 안정된 뒤 자동화 추가”

bmad-build-auto는 사람의 입력을 기다리지 않고 세션 하나에 들어오는 작업 단위 하나를 실행합니다. 다음 스토리를 선택하거나 백로그를 관리하지는 않습니다.

중요한 구현 결정이 안정된 뒤 사용하세요. AI 코딩 세션을 오케스트레이터로 삼아 스토리마다 Build Auto 작업자 하나를 실행하고 새 근거가 드러나면 이후 작업을 수정할 수 있습니다. 선택 사항인 bmad-loop 오케스트레이터는 순서가 지정된 stories.yaml을 결정론적으로 실행합니다.

bmad-loop는 목록에 적힌 순서를 따릅니다. 의존성 그래프를 추론하거나 프로젝트 수준의 병렬 조율을 제공하지 않습니다. 작업자 계약, 스토리 선택, 상태 기록은 자율 개발 루프를 참고하세요.

작업을 나누는 과정에서 정보가 사라질 수 있습니다. 요구사항이 약해지거나 제약이 빠지거나, 각각 올바르게 구현된 두 스토리가 함께 실행될 때 실패할 수도 있습니다. 큰 BMad 경로는 이런 위험을 줄이는 장치를 더합니다.

  • 제품, UX, 아키텍처, 에픽 산출물이 공동 결정을 보존합니다.
  • 각 구현 단위는 상위 계약까지 추적할 수 있습니다.
  • 스토리 기록이 구현 결정과 완료 상태를 다음 작업으로 전달합니다.
  • 이후 작업은 앞선 작업에서 얻은 근거를 반영할 수 있습니다.
  • 통합 검사로 결합된 동작을 평가합니다.
  • 새 근거가 생기면 이후 작업이나 상위 계획을 수정할 수 있습니다.
  • 회고에서 에픽 전체를 평가하고 얻은 교훈을 이후 작업에 반영합니다.

계획은 구현 중에도 계속됩니다. 변경 사항을 상위 의도와 다시 맞춘다면 작업 단위의 순서는 달라져도 됩니다.

작업 규모에 맞는 개발 경로를 얻게 됩니다. 가장 안전하고 단순한 변경은 직접 편집하고 세션 하나로 처리할 작업은 사람이 지켜보는 Build를 한 번 실행합니다. 에픽에는 공동 사양과 스토리 기록을 사용하고 여러 에픽으로 구성된 프로젝트에는 전체 프로젝트 계약과 조율 과정을 적용합니다.