BMAD 무인 개발, 실행에 넘길 요구사항과 완료를 판단하는 검수 기준

BMAD 무인 개발을 시작하기 전에 정할 것은 세 가지입니다. 무엇을 구현할지, 수락하려면 어떤 증거가 필요한지, 완료를 누가 승인할지예요. 자동 실행이 끝났다고 해서 요구사항이 충족됐다고 확정할 수는 없기 때문에, 이 셋이 빠진 채로 돌리면 무엇이 끝났는지 판단할 기준이 없습니다.

bmad-build-auto는 한 번에 작업 하나를 계획하고 구현하고 리뷰합니다. 다음에 어떤 작업을 할지는 외부 오케스트레이터가 고릅니다. 여기서 많이 헷갈리는 부분이 상태 이름이에요. built는 실행이 끝났다는 뜻이고, done은 사용자나 오케스트레이터가 수락했다는 뜻입니다. Build Auto는 스스로 완료 처리를 하지 않으니 채팅에 뜨는 완료 메시지보다 계획 파일의 상태와 결과 기록을 먼저 확인하시길 권합니다. 실행 범위와 상태 정의는 공식 무인 개발 문서에 정리돼 있습니다.

요구사항에는 무엇을 적어야 할까

가장 먼저 볼 것은 구현이 실제로 읽어 가는 이니셔티브·에픽·스토리 파일입니다. PRD는 제품의 기능과 목적을 합의하는 문서여서, PRD를 다 썼다고 구현 입력까지 갖춰지지는 않아요. 제품 차원의 의도가 작업마다 판정할 수 있는 조건으로 내려왔는지를 따로 봐야 합니다.

공식 요구사항 문서는 요구사항마다 안정적인 R<n> 식별자와 기대 동작, 충족 증거, 상위 요구사항과의 연결을 남기라고 설명합니다. 제약은 Constraints에, 제외 범위는 Boundaries에, 아직 답이 없는 질문은 Notes에 나눠 두세요. 그래야 구현자가 직접 결정해도 되는 범위와 먼저 답을 받아야 하는 부분이 갈립니다.

가상의 요구사항 하나로 예를 들어 볼게요. “중복 요청 처리”라고만 쓰면 무엇을 확인해야 할지 알 수 없습니다. 이를 “R1: 같은 요청 식별자로 재시도하면 기존 결과를 반환하고 추가 레코드를 만들지 않습니다”로 바꾸면 관찰할 동작이 보이죠. 충족 증거로는 재시도 전후의 응답과 레코드 수를 비교한 검증 결과를 적으면 됩니다. 같은 식별자가 얼마 동안 유효한지 정해지지 않았다면 미해결 질문으로 남겨 두고 정책부터 확정해야 합니다.

기능 이름이 그럴듯한지보다, 그 문장으로 성공과 실패를 가를 수 있는지를 먼저 보세요.

작업 단위와 에픽 단위 검수는 무엇이 다를까

작업 검수는 요구사항 충족을, 에픽 검수는 통합 동작을 봅니다. 어느 쪽이든 출발점은 요구사항이에요. 변경량이 많다거나 테스트가 통과했다는 사실에 판단이 쏠리기 쉬워서, 결과 기록은 아래 순서로 읽기를 권합니다.

1. 요구사항별 기대 동작을 입증하는 증거를 확인합니다.
2. 변경 파일에서 필요한 변경과 범위 밖 변경을 구분합니다.
3. 테스트가 다룬 조건과 빠진 조건을 요구사항에 대조합니다.
4. 리뷰 지적의 수정·이월·기각 근거를 읽습니다.
5. 잔여 위험을 확인하고 수락 여부를 결정합니다.

리뷰 지적은 몇 개였는지보다 어떻게 처리됐는지가 중요합니다. 이번 변경이 만든 문제를 원래 있던 문제처럼 이월하지 않았는지, 기각했다면 이유가 남아 있는지 보세요. Build Auto의 기본 리뷰는 리뷰어 하나만 쓰는 quick 모드입니다. 운영 환경에 영향을 주는 변경이라면 심층 리뷰가 필요한지도 판단해 두는 게 좋습니다.

테스트 통과를 그대로 믿기 어려운 이유도 있어요. 기본 QA는 이미 구현된 코드를 보고 API·E2E 테스트를 생성합니다. 그래서 구현에서 빠진 동작은 테스트에서도 같이 빠질 수 있고, 통과했다는 사실만으로 요구사항의 모든 조건을 확인했다고 보기는 어렵습니다.

에픽 단위에서는 전체 요구사항과 여러 작업이 맞물려 돌아가는지를 확인합니다. bmad-retrospective는 계획과 변경 내역, 커밋 등을 검토하고, 실행 동작이 바뀌었다면 그 흐름을 실제로 구동해 보라고 안내합니다. 판정은 수락(accepted), 미결 항목을 남긴 수락(accepted-with-open-items), 거부(rejected) 중 하나로 기록해요. 미결 항목을 안고 수락할 때는 남은 내용을 분명히 적어 두세요. 그래야 다음 작업에서 어디까지 끝났는지 오해하지 않습니다. 절차는 에픽 완료 문서를 기준으로 삼으면 됩니다.

돌리기 전에 권한과 중단·승인 절차부터

실행 환경에는 하위 에이전트를 띄우는 기능이 있어야 합니다. 버전 관리를 쓴다면 작업 트리가 깨끗한지, 저장소 메타데이터에 쓸 권한이 있는지도 미리 봐 두세요. Build Auto는 로컬 커밋까지만 하고 푸시는 하지 않으니, 결과를 어떻게 전달할지도 그에 맞춰 정해 둬야 합니다.

blocked 상태에서는 같은 명령을 다시 불러도 바로 중단됩니다. 재시도 횟수를 늘리는 쪽으로 손이 가기 쉬운데, 그보다 중단 사유를 먼저 읽는 게 순서예요. 요구 의도가 빠졌거나 검증이 실패한 것처럼 차단 원인을 해결한 다음에는 어느 상태에서 재개할지를 지정해야 합니다.

승인 필드를 작성하는 것과 승인을 실제로 집행하는 것도 다른 일입니다. 계획 승인과 완료 승인 필드는 오케스트레이터가 처리해야 하고, Build Auto가 이 필드를 직접 읽어 실행을 통제하지는 않아요. 기본 QA에도 시나리오 확인이나 테스트 환경 도입 승인 같은 대화형 단계가 남아 있습니다. 명령을 이어 붙일 때 이 단계들을 어떻게 처리할지 미리 정해 두세요.

이 글의 내용은 2026-11-03 기준입니다. 적용하기 전에 설치한 버전과 공식 문서의 명령·상태 정의가 일치하는지 확인하세요. 실제 명령 실행과 상태 전이는 환경마다 검증이 필요하니, 권한과 차단 후 재개, 완료 승인까지 확인한 다음에 무인 실행에 연결하는 편이 안전합니다.