바이브코딩으로 며칠 붙잡고 있던 프로젝트, 세션 새로 열었더니 Claude가 지난번에 뭘 결정했는지 까먹고 완전히 다른 방향으로 다시 짜기 시작한 경험 있으실 거예요. 혼자 "기획자 겸 개발자 겸 QA"를 다 하다 보면 맥락이 자꾸 새는 게 당연합니다.
BMAD-METHOD는 이걸 역할극으로 풉니다. 애널리스트, PM, 아키텍트, 개발자, QA 같은 페르소나를 순서대로 거치게 하면서, 각 단계의 결정을 문서(PRD, 아키텍처 문서, 스토리 파일)로 남겨요. 그 문서들이 다음 세션, 다음 에이전트로 그대로 이어지는 "기억 장치" 역할을 합니다. 깃허브 스타 4만 3천 개 넘는, 꽤 오래 검증된 프레임워크입니다.
뭘 해결하나
예를 들어 "장바구니에 쿠폰 적용 기능 추가"라는 요청이 들어오면, BMAD는 바로 코드부터 안 짭니다. 먼저 애널리스트 역할로 요구사항을 정리하고, PM 역할로 우선순위와 범위를 확정하고, 아키텍트가 기존 정산 로직과 충돌 여부를 점검한 뒤에야 개발 스토리가 만들어지고 실제 구현이 들어갑니다. 이 과정에서 나온 문서는 프로젝트에 파일로 남기 때문에, 다음 주에 다시 열어도 "우리가 왜 이렇게 하기로 했더라"를 Claude가 문서 보고 바로 복기합니다.
작은 수정 건은 이 전체 절차를 다 안 거치고 간단하게 처리하도록 설계돼 있어서, 매번 무겁게 PRD부터 써야 하는 건 아니에요.
어떻게 시작하나
npx skills add bmad-code-org/BMAD-METHOD
설치 후 bmad setup으로 프로젝트에 맞게 구성하고, 이후엔 Claude Code 안에서 bmad 스킬을 불러 다음 단계를 안내받거나 bmad-build로 실제 작업을 시킵니다. 업데이트는 bmad update, 뭔가 꼬였을 땐 bmad doctor로 복구합니다.
언제 쓰고 언제 쓰지 마라
몇 주씩 이어가는 사이드 프로젝트, 혼자 여러 역할을 다 떠안아야 하는 1인 개발, 나중에 팀원이 합류했을 때 "그동안 뭘 결정했는지" 물려줘야 하는 상황에 특히 잘 맞습니다.
이 사이트에 이미 올라온 Superpowers(/post/35)나 spec-kit(/post/564)과 결이 겹치는데, 차이를 짚자면 Superpowers는 TDD·디버깅 같은 "스킬 모음"에 가깝고, spec-kit은 스펙 문서 하나로 가볍게 시작하는 쪽이고, BMAD는 그보다 훨씬 무겁게 역할 기반 전체 파이프라인(기획→설계→개발→QA)을 강제합니다. 하루 만에 끝낼 토이 프로젝트나 프로토타입 찍어보는 용도로는 과합니다 — 역할극 세팅하는 데 드는 시간이 실제 코딩 시간보다 길어질 수 있어요.
한계
uv, 그리고 스킬을 지원하는 AI 코딩 툴이 필요해서 진입장벽이 있고, 러닝커브도 있습니다. 프레임워크 자체도 계속 업데이트되기 때문에 bmad update를 주기적으로 챙겨야 버전 꼬임을 피할 수 있어요.
출처: https://github.com/bmad-code-org/BMAD-METHOD · https://www.bmadcode.com/
댓글 0
첫 댓글을 남겨보세요!