바이브코딩으로 뚝딱 만들었는데, 두 달 뒤에 다시 열어보니 왜 이렇게 짰는지 기억이 하나도 안 나서 처음부터 다시 뜯어고친 적 있죠? 그때그때 프롬프트로 밀어붙이면 속도는 빠른데, "왜 이 구조로 갔는지"에 대한 기록이 안 남는 게 문제입니다.
BMAD-METHOD(Breakthrough Method for Agile AI-Driven Development)는 이 문제를 "역할극"으로 풉니다. PM, 아키텍트, UX, 개발, QA 같은 역할을 가진 서브에이전트들이 순서대로 끼어들어서, 막연한 아이디어를 계획으로, 계획을 코드로, 코드를 검증으로 넘기는 루프를 돌립니다.
뭘 해결하나
`bmad-build`에게 원하는 기능을 설명하면, 곧바로 코드를 짜는 게 아니라 먼저 기획 관점에서 질문을 던지고, 그걸 아키텍처 문서로 정리한 다음에야 코드를 씁니다. 이 과정에서 나온 결정 사항들이 문서로 남기 때문에, 나중에 세션을 새로 열어도 "왜 이렇게 만들었는지"를 다시 읽어볼 수 있습니다.
일반 바이브코딩이 "일단 짜고 안 되면 고치자"라면, BMAD는 "짜기 전에 왜 이렇게 짤 건지부터 정리하자" 쪽에 가깝습니다.
어떻게 시작하나
```
agent marketplace add bmad-code-org/bmad-plugins
```
로 마켓플레이스를 추가하고 `bmad-method`를 설치합니다. 이후 프로젝트에서 `bmad` 스킬한테 `bmad setup` 실행을 요청하면 초기 설정이 끝납니다. Node.js, npm, Git, uv가 필요합니다.
언제 쓰고 언제 쓰지 마라
몇 주 이상 끌고 갈 코드베이스, 특히 사이드프로젝트를 "진짜 서비스"로 키워볼 생각이 있다면 잘 맞습니다. 스콥이 늘어날 걸 아는 프로젝트에서 결정 사항을 문서로 남겨두는 습관이 나중에 진짜 도움이 됩니다.
반대로 "이 버그 하나만 빨리 고쳐줘", "함수 하나 만들어줘" 같은 잔잔한 작업에는 계획 단계 자체가 오버킬입니다. 질문만 몇 번 왔다갔다 하다가 정작 작업은 코드 몇 줄인 경우가 생깁니다.
이 자리는 사실 Superpowers, GSD, gstack 같은 다른 프레임워크들과 겹치는 자리이기도 합니다(다 이 게시판에 있습니다). 다른 것들과 비교했을 때 BMAD의 확실한 차별점은 PM·아키텍트·QA 역할극에 유난히 방점을 찍었다는 점인데, 에이전트들끼리 질문을 주고받는 과정 자체를 장황하다고 느끼면 이 스타일은 안 맞을 수 있습니다. 이미 다른 프레임워크에 익숙하다면 굳이 하나 더 얹을 필요는 없습니다.
한계
README에 뚜렷한 제약사항이 적혀 있진 않지만, 작은 작업까지 이 계획 프로세스를 태우면 그 자체가 시간 낭비가 됩니다. 설정에 Node.js/npm/git/uv가 다 필요해서 처음 세팅이 살짝 번거롭습니다.
출처
댓글 0
첫 댓글을 남겨보세요!