BMAD 방법·Claude 코드: 사양 기반 AI 개발로 프로젝트를 실제로 진행하는 방법

출처: Dev.to

Claude Code 프로젝트를 3개월 동안 즉흥적으로 코딩한 뒤에야 뭔가 잘못됐다는 걸 인정했습니다.
코드는 대체로 동작했지만, 같은 문제 때문에 시간을 계속 잃었습니다. Claude와 저는 세션 도중 원래 의도에서 벗어나고, 두 번째·세 번째 세션이 되면 우리 둘 다 코드베이스에서 절반 이상의 결정을 왜 내렸는지 기억하지 못하게 되었습니다.

v3에서 오케스트레이터 개념이 도입된 BMAD Method를 지켜봤지만, 필요 없는 오버헤드처럼 느껴졌습니다. 그러다 v4가 실제 아키텍처 전면 개편(NPM 배포, 모듈형 에이전트, 멀티‑IDE 지원)과 함께 등장했고, 저는 본격적으로 시도해 보았습니다. 거의 즉시 감이 잡혔습니다.

저는 PM, 아키텍트, 스크럼 마스터, QA 등과 함께 팀에서 수년간 일해왔습니다—SDLC 전체 캐스트 말이죠. BMAD는 같은 역할을 AI 에이전트에 매핑하므로 워크플로우가 낯설지 않고 친숙하게 느껴졌습니다. 새로운 프로세스를 배우는 것이 아니라, 이미 알고 있던 프로세스를 다른 팀원들과 함께 실행한 셈이었습니다. 그때가 대략 9개월 전이죠. 이제는 BMAD 없이는 작업하지 않습니다.

---

60초 안에 보는 BMAD

**BMAD (Breakthrough Method for Agile AI‑Driven Development)**는 AI‑보조 코딩을 다음과 같이 구조화하는 오픈‑소스 프레임워크입니다:

• 명세 – 유일한 진실의 출처.
• 역할 기반 에이전트 – PM, 아키텍트, 스크럼 마스터, 개발자, QA 등.
• 단계별 워크플로우 – 각 단계는 세션 간에 지속되는 산출물을 생성합니다.

v6 기준 프로젝트에 포함된 내용:

• 19개 이상의 특화된 에이전트 (PM, 아키텍트, 스크럼 마스터, 개발자, QA, …)
• 50개 이상의 명명된 워크플로우
• 스킬, 커맨드, 훅을 통해 Claude Code에 네이티브로 연결되는 모듈 시스템

GitHub 스타 40 000개를 넘어섰으며 여러 서드‑파티 Claude Code 플러그인을 탄생시켰습니다.

숫자는 별개로, 실제로 작업 방식에 변화를 주나요? 저에게는 크게 변했습니다.

---

설정 방법

저는 여러 진행 중인 프로젝트에 BMAD를 사용합니다:

다른 도메인, 같은 워크플로우.

---

CLAUDE.md에 관하여

많은 BMAD 가이드에서는 프로젝트와 함께 CLAUDE.md 파일을 만들 것을 권장합니다. 저는 굳이 만들지 않습니다:

• BMAD의 에이전트 설정, 스킬, 워크플로우 정의만으로도 충분한 컨텍스트를 제공합니다.
• 그 위에 CLAUDE.md를 추가하면 최선의 경우 중복이고, 최악의 경우 서로 충돌하는 지시가 생깁니다(파일은 한 가지를 말하고, BMAD 설정은 다른 것을 말할 수 있으며 Claude Code는 마지막에 본 것을 선택합니다).

프로젝트 수준 규칙(파일 명명, 디렉터리 구조, “비밀 커밋 금지” 규칙)은 모두 BMAD 자체 설정에 보관합니다—진실의 출처는 하나, 두 개가 아닙니다.

---

실제 워크플로우

기능은 네 단계를 거칩니다. 아래는 실제 예시로, 제 블로그 파이프라인을 위한 Dev.to 퍼블리싱 스킬을 만드는 과정입니다.

1. 명세 먼저

제가 원하는 것을 설명합니다. BMAD의 PM 에이전트가 PRD를 작성하고, 아키텍트 에이전트가 이를 검토해 기술 설계를 만든 뒤, 두 산출물은 docs/specs/에 마크다운 파일로 저장되어 세션 간에 지속됩니다.

I need a skill that publishes blog posts to Dev.to via their API,
handles draft mode, and manages front‑matter validation.

• PM 에이전트는 사용자 스토리, 수용 기준, 범위 경계를 생성합니다.
• 아키텍트는 이를 파일 구조, 의존성, 통합 지점으로 매핑합니다.