BMAD 방법: 민첩한 AI 기반 개발
Il BMAD 방법 (Agile AI 기반 개발을 위한 획기적인 방법) e 개발의 가장 중요한 문제 중 하나를 다루는 혁신적인 방법론 AI 지원 소프트웨어: AI의 능력을 뛰어넘는 복잡한 프로젝트를 관리하는 방법 단일 대화 세션? 그 답은 이렇게 간단한 개념에 있다 얼마나 강력한가: 문서 공유, 또는 조각화 사용에 최적화된 원자 덩어리의 프로젝트 문서화 AI 에이전트.
BMAD는 단순한 프롬프트 세트나 템플릿 모음이 아닙니다. 완전한 프레임워크 21명의 전문 에이전트, 50개 이상의 워크플로 포함 안내, 각 프로젝트 단계에 대한 템플릿 및 적응형 지능 시스템 프로젝트 규모에 따라 복잡성이 확장됩니다. 이 기사에서는 구체적인 사례를 통해 이론부터 실제까지 방법의 모든 측면을 살펴보겠습니다. 구현의.
무엇을 배울 것인가
- 컨텍스트 오버플로 문제와 BMAD가 이를 해결하는 방법을 이해합니다.
- 문서 샤딩의 개념과 그 중요성을 숙지하세요
- 21명의 전문 상담원과 그 역할에 대해 알아보세요.
- 프로젝트의 각 단계에 대해 50개 이상의 안내식 워크플로를 사용하세요.
- BMAD 규모 적응형 인텔리전스 적용
- Claude Code를 사용하여 프로젝트에서 BMAD 구성
- BMAD를 기존 방법론과 비교
- 일반적인 구현 실수 방지
시리즈 개요
| # | Articolo | 집중하다 |
|---|---|---|
| 1 | 기술 파트너로서의 클로드 | 설정 및 첫 번째 단계 |
| 2 | 프로젝트 컨텍스트 및 설정 | CLAUDE.md 및 구성 |
| 3 | 개념 및 요구사항 | MVP 및 사용자 페르소나 |
| 4 | 백엔드 및 프런트엔드 아키텍처 | 스프링 부트와 Angular |
| 5 | 코드의 구조 | 조직 및 협약 |
| 6 | 고급 엔지니어링 프롬프트 | 고급 기술 |
| 7 | 테스트 및 품질 | 전략 및 테스트 생성 |
| 8 | 전문 문서 | 읽어보기, API, ADR |
| 9 | 배포 및 DevOps | 도커, CI/CD, 모니터링 |
| 10 | 진화와 유지 | 리팩토링 및 확장성 |
| 11 | 실제 프로젝트 통합 | 클로드 코드 제작 중 |
| 12 | 고급 CLI 및 명령 | 명령줄의 숙달 |
| 13 | 사용자 정의 슬래시 명령 및 기술 | 클로드 코드 확장 |
| 14 | 하위 대리인 및 위임 | 전문 에이전트 오케스트레이션 |
| 15 | 후크: 이벤트 기반 자동화 | 이벤트 기반 자동화 |
| 16 | Ralph Wiggum: 자율 AI 루프 | 반복적인 자율 개발 |
| 17 | BMAD 방법: 민첩한 AI 개발(현재 위치) | 민첩한 AI 기반 방법론 |
| 18 | 다중 에이전트 오케스트레이션 | 상담원 팀 조정 |
| 19 | 협업과 코워킹 AI | 클로드와 함께 일하기 |
| 20 | 보안 및 권한 | 워크플로우를 보호하세요 |
| 21 | 모니터링 및 최적화 | 측정항목 및 성능 |
1. 컨텍스트 오버플로 문제
BMAD가 존재하는 이유를 이해하려면 BMAD가 해결하는 근본적인 문제를 이해해야 합니다. Claude와 같은 언어 모델에는 제한된 컨텍스트 창: 대화 중에 "기억"할 수 있는 최대 텍스트 양입니다. 200,000개의 토큰 창을 갖춘 가장 진보된 모델이라도 실질적인 한계가 있습니다. 복잡한 소프트웨어 프로젝트를 관리할 때 중요합니다.
일반적인 기업 프로젝트에는 수백 개의 소스 파일과 수십 개의 문서가 포함됩니다. 사양, 아키텍처, 테스트 계획, 배포 가이드 및 API 문서. 이 모든 것을 하나의 대화에 담는 것은 불가능합니다. 모델이 "희석"되어야 하기 때문에 중요한 부분이 답변의 품질을 저하시킵니다. 너무 많은 자료에 초점을 맞췄습니다.
숫자의 문제
| 요소 | 일반적인 크기 | % 컨텍스트 창(200K) |
|---|---|---|
| 완전한 요구사항 사양 | 20K-50K 토큰 | 10-25% |
| 아키텍처 문서 | 15K-30K 토큰 | 7-15% |
| 데이터베이스 스키마(테이블 20개) | 5K-10K 토큰 | 2-5% |
| API 문서 | 30K-80K 토큰 | 15-40% |
| 완전한 테스트 계획 | 10K-25K 토큰 | 5-12% |
| 기존 코드베이스(100개 파일) | 100K-500K 토큰 | 50-250% |
| 일반적인 평균 프로젝트 총계 | 200K-700K 토큰 | 100-350% |
보시다시피 중간 정도의 복잡성 프로젝트라도 더 많은 문서를 생성합니다. 단일 컨텍스트 창에 포함될 수 있는 것보다 솔루션 이 문제에 대한 전통적인 접근 방식은 만족스럽지 않습니다.
- 모두 요약하면 다음과 같습니다. 구현을 위한 중요한 세부 정보가 손실되었습니다.
- 별도의 세션: 프로젝트의 서로 다른 부분 간의 일관성이 손실됩니다.
- 선택적 복사-붙여넣기: 지속적이고 오류가 발생하기 쉬운 수동 관리 필요
- RAG(검색 증강 생성): 날카로운 질문에는 적합하지만 복잡한 구현 작업에는 부족합니다.
2. 문서 샤딩: 핵심 혁신
Il 문서 공유 BMAD의 핵심 개념이다. 아이디어는 간단하다 그러나 심오함: 모든 것을 설명하려고 시도하는 획일적인 문서를 만들기보다는 프로젝트를 긴 문서로 나누면 BMAD는 프로젝트의 각 측면을 다음과 같이 나눕니다. 독립적이고 상호 연결된 원자 조각 그들이 될 수 있다고 컨텍스트를 낭비하지 않고 필요할 때 정확하게 AI 에이전트에 제공됩니다.
문서 공유 원칙
- 원자성: 각 샤드는 단일 개념, 구성 요소 또는 결정을 설명합니다. 이것을 완전히 이해하기 위해 다른 샤드를 읽을 필요는 없습니다.
- 자가 봉쇄: 각 샤드에는 다음 작업에 필요한 모든 컨텍스트가 포함되어 있습니다. 그것의 사용. 샤드가 API 엔드포인트를 설명하는 경우 입력/출력 스키마가 포함됩니다. 유효성 검사, 가능한 오류 및 종속성.
- 상호 연결: 샤드에는 다른 샤드에 대한 명시적인 참조가 포함되어 있습니다. 관련되어 에이전트가 문서를 그래프로 탐색할 수 있습니다.
- 최적의 크기: 각 샤드는 한 부분을 차지할 수 있는 크기입니다. 컨텍스트 창의 관리 가능한 크기(일반적으로 2K-8K 토큰), 공간 확보 추론 및 코드 생성을 위해.
BMAD 디렉토리 구조
bmad-agent/
├── agents/ # 21 agenti specializzati
│ ├── pm-agent.md # Product Manager
│ ├── architect-agent.md # System Architect
│ ├── developer-agent.md # Developer
│ ├── ux-agent.md # UX Designer
│ ├── sm-agent.md # Scrum Master
│ ├── qa-agent.md # Quality Assurance
│ ├── devops-agent.md # DevOps Engineer
│ ├── data-agent.md # Data Engineer
│ ├── security-agent.md # Security Specialist
│ ├── tech-writer-agent.md # Technical Writer
│ ├── analyst-agent.md # Business Analyst
│ ├── design-agent.md # System Designer
│ ├── frontend-agent.md # Frontend Specialist
│ ├── backend-agent.md # Backend Specialist
│ ├── mobile-agent.md # Mobile Developer
│ ├── ml-agent.md # ML Engineer
│ ├── performance-agent.md # Performance Engineer
│ ├── migration-agent.md # Migration Specialist
│ ├── review-agent.md # Code Reviewer
│ ├── release-agent.md # Release Manager
│ └── orchestrator-agent.md # Agent Orchestrator
│
├── tasks/ # 50+ workflow guidati
│ ├── analysis/
│ │ ├── gather-requirements.md
│ │ ├── competitive-analysis.md
│ │ ├── user-persona-creation.md
│ │ └── risk-assessment.md
│ ├── planning/
│ │ ├── create-roadmap.md
│ │ ├── sprint-planning.md
│ │ ├── resource-allocation.md
│ │ └── milestone-definition.md
│ ├── architecture/
│ │ ├── system-design.md
│ │ ├── api-contract.md
│ │ ├── database-schema.md
│ │ └── integration-patterns.md
│ ├── implementation/
│ │ ├── feature-implementation.md
│ │ ├── code-generation.md
│ │ ├── refactoring-guide.md
│ │ └── testing-strategy.md
│ └── delivery/
│ ├── deployment-plan.md
│ ├── release-checklist.md
│ ├── monitoring-setup.md
│ └── post-mortem.md
│
├── templates/ # Template riutilizzabili
│ ├── prd-template.md # Product Requirements Document
│ ├── adr-template.md # Architecture Decision Record
│ ├── epic-template.md # Epic/Feature template
│ ├── story-template.md # User Story template
│ └── test-plan-template.md # Test Plan template
│
├── personas/ # Configurazioni persona
│ ├── startup-mode.md # Modalità startup lean
│ ├── enterprise-mode.md # Modalità enterprise rigorosa
│ └── solo-dev-mode.md # Modalità sviluppatore singolo
│
└── checklists/ # Checklist di qualità
├── code-review.md
├── security-audit.md
├── accessibility.md
└── performance.md샤드 예: API 엔드포인트
# API Shard: Crea Prenotazione
## Endpoint
POST /api/v1/bookings
## Descrizione
Crea una nuova prenotazione per un utente registrato.
## Autenticazione
Bearer JWT Token (ruoli: USER, ADMIN)
## Input Schema
{
"roomId": "string (UUID, obbligatorio)",
"checkIn": "string (ISO 8601, obbligatorio)",
"checkOut": "string (ISO 8601, obbligatorio)",
"guests": "number (1-10, obbligatorio)",
"notes": "string (max 500 char, opzionale)"
}
## Validazioni
1. checkOut deve essere successivo a checkIn
2. La durata minima è 1 notte
3. La durata massima è 30 notti
4. La room deve esistere e essere disponibile nel periodo
5. L'utente non deve avere prenotazioni sovrapposte
## Risposte
- 201 Created: prenotazione creata con successo
- 400 Bad Request: validazione fallita
- 401 Unauthorized: token mancante o invalido
- 404 Not Found: room non trovata
- 409 Conflict: room non disponibile nel periodo
## Dipendenze
- Shard: room-availability-service
- Shard: user-validation-middleware
- Shard: booking-entity-schema
## Test Richiesti
- Happy path con dati validi
- Validazione date (checkOut prima di checkIn)
- Room non disponibile (conflict)
- Utente non autenticato
- Prenotazione sovrapposta이 샤드에는 엔드포인트를 구현하는 데 필요한 모든 것(입력 스키마, 검증, 응답, 종속성 및 테스트가 필요합니다. 이를 수신하는 AI 에이전트 샤드는 필요 없이 완전한 구현을 생성하는 데 필요한 컨텍스트를 가지고 있습니다. 전체 프로젝트 문서를 읽으려면.
3. BMAD 전문요원 21명
BMAD의 운영 핵심은 다음과 같습니다. 21명의 전문 에이전트, 각각은 특정 기술, 시스템 프롬프트 및 워크플로우로 구성됩니다. 소프트웨어 개발의 한 측면. 이들 에이전트는 독립적인 개체는 아니지만 Claude Code의 구성 특정 전문 지식을 활성화하는 시스템 프롬프트 및 문서 조각에 대한 선택적 액세스를 통해.
프로젝트 단계별 에이전트 지도
| 단계 | 관련 에이전트 | 책임 |
|---|---|---|
| 복수 | PM 에이전트, 분석가, UX 에이전트 | 요구 사항, 페르소나, 경쟁 분석 |
| 계획 | SM 에이전트, PM 에이전트 | 로드맵, 스프린트 계획, 리소스 |
| 건축학 | 건축가, 디자이너, 보안 | 시스템 설계, API 계약, 보안 |
| 구현 | 개발자, 프런트엔드, 백엔드, 모바일, ML | 코드, 테스트, 통합 |
| 품질 | QA 상담원, 리뷰 상담원, 성과 | 테스트, 코드 검토, 성능 |
| 배달 | DevOps, 릴리스, 기술 작가 | 배포, 문서, 릴리스 노트 |
| 조정 | 오케스트레이터, 데이터 에이전트, 마이그레이션 | 오케스트레이션, 데이터, 마이그레이션 |
상담원 프로필: PM 상담원(제품 관리자)
Il PM 에이전트 요구사항을 수집하고 관리하는 역할을 담당합니다. 제품의. 대부분의 프로젝트에서 호출되는 첫 번째 에이전트입니다. 나머지 모든 개발을 추진하는 기본 아티팩트를 생성합니다.
# PM Agent - Product Manager
## Identita
Sei un Product Manager esperto con 15+ anni di esperienza in prodotti
software B2B e B2C. Eccelli nella raccolta dei requisiti, nell'analisi
dei bisogni degli stakeholder e nella definizione di roadmap strategiche.
## Competenze Specifiche
- Tecniche di elicitazione dei requisiti (interviste, workshop, survey)
- Framework di prioritizzazione (MoSCoW, RICE, Kano)
- Creazione di Product Requirements Document (PRD)
- Definizione di metriche di successo (KPI, OKR)
- Analisi competitiva e posizionamento
## Workflow Disponibili
1. gather-requirements: Raccolta strutturata dei requisiti
2. competitive-analysis: Analisi del panorama competitivo
3. user-persona-creation: Creazione di user personas dettagliate
4. prd-creation: Stesura del Product Requirements Document
5. roadmap-planning: Pianificazione della roadmap di prodotto
## Template
- prd-template.md: Template per il documento requisiti
- epic-template.md: Template per epic/feature
- story-template.md: Template per user stories
## Regole di Interazione
1. Fai sempre domande chiarificatrici prima di procedere
2. Quantifica i requisiti quando possibile (numeri, metriche, SLA)
3. Identifica e documenta i rischi per ogni requisito critico
4. Distingui sempre tra MUST, SHOULD, COULD e WON'T (MoSCoW)
5. Produci artefatti in formato shard per il consumo da parte di altri agenti에이전트 프로필: 건축가 에이전트
L'건축가 에이전트 PM 에이전트 요구사항을 의사결정으로 변환 콘크리트 건축. 구현을 촉진하는 아키텍처 샤드를 생성합니다. 기술, 패턴, 인터페이스 및 장단점을 정의합니다.
# Architect Agent - System Architect
## Identita
Sei un System Architect senior con esperienza in architetture distribuite,
microservizi, event-driven e serverless. Bilanci pragmatismo e rigore
tecnico nelle decisioni architetturali.
## Competenze Specifiche
- Design di architetture scalabili (verticale e orizzontale)
- Pattern architetturali (DDD, CQRS, Event Sourcing, Hexagonal)
- API Design (REST, GraphQL, gRPC)
- Database selection (SQL vs NoSQL vs NewSQL)
- Trade-off analysis (CAP theorem, performance vs consistency)
- Security by design
## Output Attesi
Per ogni decisione architetturale, produrre:
1. ADR (Architecture Decision Record) in formato shard
2. Diagramma componenti (descrizione testuale per mermaid)
3. API contract shard per ogni interfaccia
4. Database schema shard
5. Lista di vincoli e assunzioni
## Regole
1. Ogni decisione deve avere un ADR con alternative considerate
2. Preferire soluzioni semplici a soluzioni eleganti
3. Documentare i trade-off in modo esplicito
4. Definire interfacce prima delle implementazioni
5. Considerare sempre scalabilità, sicurezza e manutenibilità에이전트 프로필: 개발자 에이전트
Il 개발자 에이전트 실제 코드를 생성하는 것은 에이전트입니다. PM Agent, Architect Agent가 생성한 샤드를 소모하여 배포 기능을 제공하고, 테스트를 작성하고, 아키텍처 제약 조건을 준수하는 코드를 생성합니다.
# Developer Agent - Full-Stack Developer
## Identita
Sei uno sviluppatore full-stack esperto con padronanza di TypeScript,
Java, Python e Go. Scrivi codice pulito, testabile e manutenibile.
Segui le best practice della community e i principi SOLID.
## Competenze Specifiche
- TypeScript/JavaScript (Node.js, Angular, React, Next.js)
- Java (Spring Boot, Hibernate)
- Python (FastAPI, Django)
- Database (PostgreSQL, MongoDB, Redis)
- Testing (Jest, JUnit, pytest)
- Clean Code e Design Patterns
## Workflow
1. Leggi lo shard della feature/endpoint da implementare
2. Leggi lo shard dell'architettura rilevante
3. Implementa il codice seguendo le convenzioni del progetto
4. Scrivi test unitari con coverage > 80%
5. Esegui lint e type check
6. Aggiorna il STATUS.md del modulo
## Regole
1. Mai usare `any` in TypeScript senza commento giustificativo
2. Ogni funzione pubblica deve avere JSDoc/JavaDoc
3. Error handling esplicito, mai catch vuoti
4. Seguire il naming convention definito in CLAUDE.md
5. Rispettare le interfacce definite dall'Architect Agent상담원 프로필: QA 상담원
Il QA 대리인 테스트 전략을 담당하며 코드 품질 검증. Developer Agent와 병행하여 동작하며, 테스트 케이스 생성, 커버리지 분석 수행 및 격차 식별 구현의 품질.
에이전트 프로필: 스크럼 마스터 에이전트
Lo SM 에이전트 개발 프로세스를 조정하고 관리합니다. 스프린트 계획을 수립하고 회고를 촉진하며 장애물을 제거합니다. BMAD 컨텍스트에서는 백로그를 생성하고 유지하는 역할을 담당합니다. 샤드 및 작업 우선 순위.
다른 대리인
21개 에이전트에 대한 전체 개요
| # | 대리인 | 역할 | 메인 출력 |
|---|---|---|---|
| 1 | PM 에이전트 | 제품 관리자 | PRD, 사용자 스토리, 백로그 |
| 2 | 건축가 에이전트 | 시스템 설계자 | ADR, API 계약, 스키마 |
| 3 | 개발자 에이전트 | 풀스택 개발자 | 코드, 단위 테스트 |
| 4 | UX 에이전트 | UX 디자이너 | 와이어프레임, 사용자 흐름 |
| 5 | SM 에이전트 | 스크럼 마스터 | 스프린트 계획, 회고적 |
| 6 | QA 대리인 | 품질 보증 | 테스트 계획, 버그 보고서 |
| 7 | DevOps 에이전트 | DevOps 엔지니어 | 파이프라인, 인프라 |
| 8 | 데이터 에이전트 | 데이터 엔지니어 | 스키마, 마이그레이션, ETL |
| 9 | 보안요원 | 보안 전문가 | 위협 모델, 감사 |
| 10 | 기술 작가 에이전트 | 기술 작가 | 문서, API 가이드, README |
| 11 | 분석가 에이전트 | 비즈니스 분석가 | 분석, 지표, KPI |
| 12 | 디자이너 에이전트 | 시스템 디자이너 | 부품 디자인, 패턴 |
| 13 | 프런트엔드 에이전트 | 프론트엔드 전문가 | UI 구성요소, 상태 |
| 14 | 백엔드 에이전트 | 백엔드 전문가 | 서비스, API, DB |
| 15 | 모바일 에이전트 | 모바일 개발자 | 앱, 기본 기능 |
| 16 | ML 에이전트 | ML 엔지니어 | 모델, 파이프라인, 평가 |
| 17 | 성능 에이전트 | 성능 엔지니어 | 벤치마크, 최적화 |
| 18 | 마이그레이션 에이전트 | 마이그레이션 전문가 | 마이그레이션 계획, 스크립트 |
| 19 | 리뷰 에이전트 | 코드 검토자 | 검토 메모, 제안 |
| 20 | 이형제 | 릴리스 관리자 | 릴리스 노트, 변경 로그 |
| 21 | 오케스트레이터 에이전트 | 에이전트 코디네이터 | 작업 라우팅, 동기화 |
4. 50개 이상의 안내식 워크플로
각 BMAD 에이전트에는 사전 정의된 워크플로가 있습니다. 체계적이고 재현 가능한 방식으로 복잡한 작업을 통해 에이전트를 안내합니다. 워크플로는 모호성을 제거하고 작업의 모든 측면이 도착하도록 보장합니다. 복잡성에 관계없이 해결됩니다.
단계별 작업 흐름: 분석
분석 단계 워크플로우는 수집하고 구조화하도록 설계되었습니다. 설계 또는 구현 활동 전에 필요한 정보.
# Workflow: Raccolta Requisiti Strutturata
## Prerequisiti
- Accesso al cliente/stakeholder (o documento brief)
- Template PRD (prd-template.md)
- Checklist domande standard
## Passi
### Step 1: Comprensione del Contesto
- Qual è il problema che il prodotto risolve?
- Chi sono gli utenti target?
- Quali sono i vincoli di business (budget, timeline, compliance)?
- Esistono sistemi legacy da integrare?
### Step 2: Elicitazione Funzionale
Per ogni macro-funzionalità identificata:
1. Definisci il caso d'uso principale (happy path)
2. Identifica i casi limite (edge cases)
3. Definisci i criteri di accettazione (Given/When/Then)
4. Classifica la priorità (MoSCoW)
5. Stima la complessità relativa (S/M/L/XL)
### Step 3: Requisiti Non-Funzionali
- Performance: tempi di risposta attesi (p50, p95, p99)
- Scalabilità: utenti concorrenti previsti (ora, 6 mesi, 1 anno)
- Disponibilità: SLA target (99.9%? 99.99%?)
- Sicurezza: compliance requirements (GDPR, SOC2, PCI-DSS)
- Accessibilita: WCAG livello target (A, AA, AAA)
### Step 4: Produzione Artefatti
Genera i seguenti shard:
1. shard-prd-overview.md (panoramica progetto)
2. shard-personas.md (user personas)
3. shard-requirements-functional.md (requisiti funzionali)
4. shard-requirements-nonfunctional.md (requisiti non-funzionali)
5. shard-constraints.md (vincoli e assunzioni)
6. shard-risks.md (rischi identificati)
### Step 5: Validazione
- Rivedi ogni shard per completezza
- Verifica che ogni requisito sia testabile
- Conferma le priorità con lo stakeholder단계별 워크플로우: 아키텍처
# Workflow: System Design
## Input Richiesti
- shard-prd-overview.md
- shard-requirements-functional.md
- shard-requirements-nonfunctional.md
- shard-constraints.md
## Passi
### Step 1: Identificazione Componenti
Leggi i requisiti funzionali e identifica:
- Bounded contexts (DDD)
- Servizi principali
- Integrazioni esterne
- Layer di persistenza
### Step 2: Scelta Pattern Architetturale
Valuta e documenta in ADR:
- Monolith vs Microservizi vs Modular Monolith
- Sync vs Async communication
- SQL vs NoSQL per ogni bounded context
- Hosting: Cloud vs On-premise vs Hybrid
### Step 3: Design delle Interfacce
Per ogni servizio/modulo:
1. Definisci API contract (OpenAPI/Protobuf)
2. Definisci event schema (per comunicazione async)
3. Definisci database schema
4. Documenta in shard separati
### Step 4: Security Design
- Autenticazione: metodo e flusso
- Autorizzazione: modello (RBAC, ABAC, ReBAC)
- Encryption: at rest e in transit
- Threat model (STRIDE)
### Step 5: Produzione Shard Architetturali
1. shard-architecture-overview.md
2. shard-adr-{decisione}.md (uno per ogni decisione)
3. shard-api-{servizio}.md (uno per ogni API)
4. shard-db-{context}.md (schema per ogni bounded context)
5. shard-security-model.md단계별 워크플로우: 구현
# Workflow: Implementazione Feature
## Input Richiesti
- shard-api-{endpoint}.md (contract dell'endpoint)
- shard-db-{context}.md (schema database)
- shard-architecture-overview.md (vincoli architetturali)
## Passi
### Step 1: Analisi dello Shard
1. Leggi lo shard dell'endpoint/feature da implementare
2. Identifica dipendenze da altri shard
3. Verifica che tutte le interfacce siano definite
### Step 2: Scaffolding
1. Crea i file necessari seguendo la struttura del progetto
2. Definisci interfacce TypeScript/Java per i tipi
3. Crea stub per i metodi principali
### Step 3: Implementazione TDD
Per ogni funzionalità dello shard:
1. Scrivi il test che verifica il comportamento atteso
2. Implementa il codice minimo per far passare il test
3. Refactora mantenendo i test verdi
4. Ripeti per la prossima funzionalità
### Step 4: Integrazione
1. Verifica compatibilità con interfacce definite
2. Esegui test di integrazione
3. Verifica compliance con lo shard di architettura
### Step 5: qualità
1. Esegui linter e type checker
2. Verifica coverage > 80%
3. Documenta API con JSDoc/JavaDoc
4. Aggiorna STATUS.md5. 규모 적응형 지능
BMAD의 가장 중요한 혁신 중 하나는 규모 적응형 인텔리전스: 복잡성, 형식성 및 엄격함의 수준을 자동으로 조정하는 기능 프로젝트의 규모와 성격에 따라 프로세스를 결정합니다. 모든 프로젝트는 아닙니다. 21개의 에이전트와 50개의 워크플로가 필요합니다. 개인 사이드 프로젝트에는 엔터프라이즈 시스템과는 근본적으로 다른 접근 방식을 제공합니다.
BMAD 규모 수준
| 수준 | 프로젝트 유형 | 활성 물질 | 작업 흐름 | 형식 |
|---|---|---|---|---|
| 난쟁이 | 스크립트, 유틸리티, 단일 도구 | 1 (개발자) | 최소한의 | 공식 문서 없음 |
| 마이크로 | 사이드 프로젝트, 프로토타입, MVP | 3(PM, 개발, QA) | 필수적인 | 읽어보기 + 기본 테스트 |
| 작은 | 스타트업, 소규모 팀(2~5명) | 6명(PM, Arch, Dev, QA, DevOps, Writer) | 기준 | PRD + ADR + API 문서 |
| 중간 | 엔터프라이즈 제품, 중간 규모 팀(5-15) | 12 | 완벽한 | 전체 문서화 + 규정 준수 |
| 크기가 큰 | 기업, 대규모 팀(15세 이상) | 21일 모두 | 모두 + 맞춤 | 전체 공식 + 감사 추적 |
개발자 전용 모드
개별 개발자를 위해 BMAD는 다음 모드를 제공합니다. 개발자 전용 그 여러 상담원의 책임을 능률적이면서도 효과적인 워크플로로 압축합니다.
# BMAD Solo Developer Mode
## Agenti Attivi
1. PM Agent (leggero): solo user stories e criteri di accettazione
2. Developer Agent: implementazione + testing
3. DevOps Agent: solo deployment configuration
## Workflow Semplificato
1. Definisci il problema in 1 paragrafo
2. Lista le feature principali (max 10)
3. Per ogni feature, scrivi 1 user story con criteri di accettazione
4. Implementa con TDD
5. Deploy
## Shard Minimi
- overview.md: cosa fa il progetto, per chi, perchè
- features.md: lista feature con priorità
- tech-stack.md: tecnologie scelte con motivazione
- Per ogni feature: 1 shard con interface + test criteria
## Regole
- Niente ADR formali per decisioni ovvie
- Test unitari solo per logica di business complessa
- Documentazione inline (JSDoc) invece di documenti separati
- Deploy continuo senza release formali6. BMAD 작업 흐름의 4단계
프로젝트 규모에 관계없이 BMAD는 개발 프로세스를 구성합니다. 각 단계에는 목표, 책임 있는 에이전트 및 인공물이 포함된 4개의 개별 단계로 구성됩니다. 특정 출력의. 첫 번째 실행에서는 단계가 순차적이지만 프로젝트가 진행되면 반복됩니다.
1단계: 분석
분석 단계는 해결해야 할 문제에 대한 깊은 이해에 전념합니다. PM, 분석가 및 UX 에이전트는 협업하여 요구 사항을 수집하고 페르소나를 정의하며, 경쟁 환경을 분석하고 제약 조건과 위험을 식별합니다.
관련 에이전트: PM 에이전트, 분석 에이전트, UX 에이전트
생산된 유물: PRD(제품 요구 사항 문서), 사용자 페르소나, 아래의 경쟁 분석, 위험 평가, 기능적 및 비기능적 요구 사항 원자 조각의 형태.
분석 단계의 출력은 다음을 완전히 설명하는 샤드 세트입니다. 무엇 건설되어야 하며, 누구를 위해, 아직 정의하지 않은 상태 ~처럼. 이러한 분리는 성급한 결정을 피하기 위해 필수적입니다. 구현의.
2단계: 계획
계획 단계에서는 요구 사항을 구체적인 작업 계획으로 변환합니다. Scrum Master Agent와 PM Agent는 협력하여 로드맵을 정의하고 구성합니다. 백로그를 작성하고, 스프린트를 계획하고, 작업에 리소스(에이전트)를 할당합니다.
관련 에이전트: SM 에이전트, PM 에이전트
생산된 유물: 프로젝트 로드맵, 스프린트 백로그, 마일스톤 정의, 자원 할당 매트릭스. 백로그의 각 작업은 하나의 작업과 연결됩니다. 하나 이상의 요구 사항 샤드와 구현을 담당하는 하나 이상의 에이전트.
3단계: 아키텍처
아키텍처 단계에서는 다음을 정의합니다. ~처럼 시스템이 구축될 예정이다. 건축가 에이전트 및 디자이너 에이전트는 요구 사항을 분석하고 아키텍처 결정을 내립니다. 문서화된 API 계약, 데이터베이스 스키마 및 보안 모델.
관련 에이전트: 아키텍트 에이전트, 디자이너 에이전트, 보안 에이전트
생산된 유물: 아키텍처 개요, ADR(아키텍처 결정 기록), API 계약, 데이터베이스 스키마, 보안 모델, 통합 패턴. 각 결정은 고려된 대안과 그 이유와 함께 문서화됩니다. 선택하여 설계 결정에 대한 완전한 감사 추적을 생성합니다.
4단계: 구현
구현 단계에서는 코드가 작성됩니다. 개발자 에이전트( 프런트엔드, 백엔드, 모바일 변형)은 이전 단계에서 생성된 샤드를 소비합니다. 기능을 구현하고, 테스트를 작성하고, 배포할 준비가 된 코드를 생성합니다. 동시에 QA 에이전트는 품질을 검증하고 DevOps 에이전트는 인프라를 준비합니다.
관련 에이전트: 개발자 에이전트, 프런트엔드 에이전트, 백엔드 에이전트, QA 에이전트, DevOps 에이전트, 기술 작가 에이전트
생산된 유물: 소스 코드, 테스트 스위트, API 문서, CI/CD 파이프라인, 릴리스 노트, 사용자 가이드.
┌─────────────────────────────────────────────────────────────────┐
│ FASE 1: ANALISI │
│ PM Agent ──→ Analyst Agent ──→ UX Agent │
│ Output: PRD shards, Personas, Requirements, Risks │
└──────────────────────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ FASE 2: PIANIFICAZIONE │
│ SM Agent ──→ PM Agent │
│ Output: Roadmap, Sprint Backlog, Milestones │
└──────────────────────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ FASE 3: ARCHITETTURA │
│ Architect Agent ──→ Designer Agent ──→ Security Agent │
│ Output: ADR shards, API contracts, DB schemas, Security model │
└──────────────────────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ FASE 4: IMPLEMENTAZIONE │
│ Developer ──→ QA ──→ DevOps ──→ Tech Writer │
│ Output: Code, Tests, Pipeline, Documentation │
└──────────────────────────┬──────────────────────────────────────┘
│
▼
┌──────────────┐
│ DELIVERY │
│ Release + │
│ Monitoring │
└──────────────┘7. 기존 방법론과의 비교
BMAD는 진공 상태에서 탄생하지 않습니다. 애자일 방법론의 교차점에 위치합니다. AI 에이전트의 전통적 기능과 새로운 기능. 차이점을 이해하세요 확립된 접근법과의 보완성은 시기와 방법을 평가하는 데 도움이 됩니다. BMAD를 적용합니다.
BMAD와 기존 방법론
| 나는 기다린다 | 스크럼 | 칸반 | BMAD |
|---|---|---|---|
| 반복 | 고정 스프린트(2~4주) | 지속적인 흐름 | 적응형 루프(분-시간) |
| 역할 | 인간의 3가지 역할 | 고정된 역할 없음 | 21개의 구성 가능한 AI 에이전트 |
| 선적 서류 비치 | 사용자 스토리, 백로그 | 보드에 카드 | 상호 연결된 원자 조각 |
| 피드백 | 스프린트 종료(회고적) | 지속적(흐름 측정항목) | 각 반복(자동화된 테스트) |
| 확장성 | 대규모용 SAFe, LeSS | 기본적으로 확장 가능 | 규모 적응형 인텔리전스 |
| 인적 비용 | 전체 팀 필요 | 유연한 팀 | 연산자 1개 + API 비용 |
| 속도 | 기능당 주 | 기능당 일수 | 기능당 시간(루프 포함) |
BMAD가 애자일 방법론을 대체하는 것이 아니라 오히려 향상시키다. 스크럼을 사용하는 팀은 BMAD를 채택할 수 있습니다. 각 스프린트의 구현 단계를 가속화하고 행사를 유지합니다. 인간 조정을 위한 스크럼 및 실행을 위해 BMAD 에이전트 사용 개별 작업의.
8. 프로젝트에서 BMAD 구성
BMAD를 기존 프로젝트에 통합하려면 초기 설정이 필요합니다. 기본 디렉터리 구조, 구성 파일 및 샤드를 준비합니다. 프로세스는 점진적으로 설계되었습니다. 구성부터 시작할 수 있습니다. 프로젝트가 성장함에 따라 복잡성을 최소화하고 복잡성을 추가합니다.
1단계: 설치
# Clona il template BMAD
git clone https://github.com/bmad-method/bmad-agent.git .bmad
# Crea la struttura di base nel progetto
mkdir -p .bmad/{agents,tasks,templates,shards}
# Copia gli agenti necessari per il livello di scala scelto
# Esempio: livello "Small" (6 agenti)
cp .bmad/agents/{pm-agent,architect-agent,developer-agent,qa-agent,devops-agent,tech-writer-agent}.md \
.bmad/agents/
# Copia i workflow rilevanti
cp -r .bmad/tasks/{analysis,architecture,implementation} .bmad/tasks/
# Configura CLAUDE.md per integrare BMAD
cat >> CLAUDE.md << 'EOF'
## BMAD Configuration
- Agents directory: .bmad/agents/
- Tasks directory: .bmad/tasks/
- Shards directory: .bmad/shards/
- Active scale: Small (6 agents)
When starting a new task, always:
1. Check which shard is relevant in .bmad/shards/
2. Follow the appropriate workflow in .bmad/tasks/
3. Produce output as new shards when generating documentation
EOF2단계: 초기 샤드 생성
# .bmad/shards/project-overview.md
# Project Overview Shard
## Nome Progetto
BookingAPI - Sistema di Prenotazioni Online
## Problema
I piccoli hotel e B&B non hanno un sistema di prenotazione
moderno, economico e facile da integrare nei loro siti web.
## Soluzione
API REST + Widget embeddabile per la gestione prenotazioni
con calendario disponibilità, pagamenti e notifiche.
## Stack Tecnologico
- Backend: Node.js + Express + TypeScript
- Database: PostgreSQL
- Cache: Redis
- Auth: JWT + OAuth2
- Deploy: Docker + Railway
## Utenti Target
1. Proprietari di piccoli hotel/B&B (admin)
2. Ospiti che prenotano (utente finale)
3. Sviluppatori che integrano il widget (developer)
## Vincoli
- Budget: $0 infrastruttura (free tier)
- Timeline: MVP in 2 settimane
- Compliance: GDPR per dati utente
- Accessibility: WCAG 2.1 AA
## Shard Correlati
- shard-personas.md
- shard-requirements-functional.md
- shard-architecture-overview.md3단계: 에이전트 호출
일단 구성되면 Claude Code에 다음을 제공하여 BMAD 에이전트를 호출합니다. 에이전트 컨텍스트 및 관련 샤드:
# Metodo 1: Prompt diretto con contesto agente
claude "Leggi .bmad/agents/architect-agent.md per assumere il ruolo di architetto.
Poi leggi .bmad/shards/project-overview.md e .bmad/shards/requirements-functional.md.
Segui il workflow in .bmad/tasks/architecture/system-design.md per produrre
il design architetturale. Salva ogni output come shard separato in .bmad/shards/"
# Metodo 2: Slash command personalizzato
# In .claude/commands/bmad-architect.md:
# Assume the Architect Agent role from .bmad/agents/architect-agent.md
# Read relevant shards and produce architecture design shards
/bmad-architect "Design del sistema di prenotazioni"
# Metodo 3: Combinazione con Ralph Wiggum
# PROMPT.md con istruzioni BMAD + loop autonomo
cat PROMPT.md | claude --print --dangerously-skip-permissions9. 모범 사례 및 일반적인 실수
BMAD를 올바르게 적용하면 상당한 이점을 얻을 수 있습니다. 그러나 부적절하게 사용하면 불필요한 복잡성이 발생할 수 있습니다. 이 섹션에서는 커뮤니티에서 배운 교훈을 수집하고 패턴을 식별합니다. 성공과 피해야 할 안티 패턴.
모범 사례
- 작게 시작하세요: 마이크로 또는 소규모 수준에서 시작하여 추가 필요할 때만 복잡합니다. 에이전트와 워크플로를 추가하는 것이 훨씬 쉽습니다. 프로세스에 통합되면 제거하십시오.
- 먼저 샤드하고 코드는 나중에: 코드 작성에 대한 유혹에 저항하세요 명확한 파편을 갖기 전에. 구조화된 문서에 투자하면 성과를 거둘 수 있습니다. 구현 단계에서 엄청난 규모입니다.
- 하나의 샤드 = 하나의 개념: 샤드에 8,000개 이상의 토큰이 필요한 경우 그는 아마도 너무 많은 개념을 다루려고 노력하고 있는 것 같습니다. 여러 개의 샤드로 분할 작고 상호 연결되어 있습니다.
- 샤드 업데이트: 샤드는 정적 문서가 아닙니다. 언제 구현을 통해 가정이 잘못된 것으로 밝혀지면 샤드를 업데이트하세요. 일관성을 유지하는 데 해당합니다.
- Ralph Wiggum과 결합: 구현 단계에서는 페어링 BMAD + Ralph Wiggum은 매우 효과적입니다. BMAD는 구조와 샤드를 제공합니다. Ralph Wiggum은 반복적인 구현을 수행합니다.
일반적인 실수
안티 패턴 BMAD
| 안티 패턴 | 문제 | 해결책 |
|---|---|---|
| 과도한 엔지니어링 | 할 일 목록에 21개의 에이전트를 모두 사용하세요. | 적절한 규모 수준을 선택하세요 |
| 모놀리식 샤드 | 모든 것을 포함하는 20,000개 이상의 토큰 파편 | 2-8K 토큰의 원자 조각으로 분할 |
| 고아 조각 | 다른 샤드에 대한 참조가 없는 샤드 | 각 샤드에는 "관련 샤드" 섹션이 있어야 합니다. |
| 무한한 분석 | 배포하지 않고 샤드 생성 | 각 단계에 대한 시간 상자 정의 |
| 피드백을 무시하세요 | 구현이 다를 때 샤드를 업데이트하지 마세요 | 스프린트 종료 시 샤드 검토 및 업데이트 |
| 복사 붙여넣기 에이전트 | 프로젝트에 맞게 사용자 정의하지 않고 에이전트 사용 | 각 상담원의 프롬프트와 규칙을 상황에 맞게 조정하세요. |
10. Claude Code CLI와의 통합
BMAD는 여러 메커니즘을 통해 기본적으로 Claude Code와 통합됩니다. 지속적인 컨텍스트를 위한 CLAUDE.md, 호출을 위한 슬래시 명령 에이전트, 자동화를 위한 후크 및 병렬 실행을 위한 하위 에이전트.
CLAUDE.md를 BMAD 허브로 사용
# CLAUDE.md
## Progetto
BookingAPI - Sistema Prenotazioni Online
## BMAD Configuration
Scale: Small (6 agents active)
### Directory Structure
- `.bmad/agents/` - Agent configurations
- `.bmad/tasks/` - Guided workflows
- `.bmad/shards/` - Project documentation shards
- `.bmad/templates/` - Reusable templates
### Active Agents
1. PM Agent: requirements and product decisions
2. Architect Agent: system design and ADRs
3. Developer Agent: code implementation
4. QA Agent: testing strategy and execution
5. DevOps Agent: deployment and infrastructure
6. Tech Writer Agent: documentation
### Conventions
- Every new feature must start with a shard
- Every architecture decision needs an ADR shard
- Implementation follows TDD within BMAD workflows
- Shards are updated when implementation diverges
### Current Sprint
Read `.bmad/shards/sprint-current.md` for active tasks
## Comandi di Sviluppo
- `npm run dev` - Start development server
- `npm test` - Run test suite
- `npm run build` - Production build
- `npm run lint` - Lint checkBMAD 에이전트에 대한 슬래시 명령
# .claude/commands/bmad-pm.md
# Assume the PM Agent role from .bmad/agents/pm-agent.md
# Gather requirements and produce shards
Read .bmad/agents/pm-agent.md to understand your role.
Then follow the workflow in .bmad/tasks/analysis/gather-requirements.md.
Save all outputs as shards in .bmad/shards/.
Ask clarifying questions before proceeding.
---
# .claude/commands/bmad-architect.md
# Assume the Architect Agent role from .bmad/agents/architect-agent.md
# Design system architecture based on requirement shards
Read .bmad/agents/architect-agent.md to understand your role.
Read all shards in .bmad/shards/ that start with "requirements-".
Follow the workflow in .bmad/tasks/architecture/system-design.md.
Produce architecture shards and ADRs.
---
# .claude/commands/bmad-implement.md
# Assume the Developer Agent role from .bmad/agents/developer-agent.md
# Implement the next feature based on architecture shards
Read .bmad/agents/developer-agent.md to understand your role.
Read .bmad/shards/sprint-current.md to identify the next task.
Read the relevant API and architecture shards.
Follow the workflow in .bmad/tasks/implementation/feature-implementation.md.
Use TDD: write tests first, then implement.11. 실제 사례: 예약 API를 위한 BMAD
제시된 개념을 구체적으로 만들기 위해 BMAD가 어떻게 적용되는지 살펴보겠습니다. 분석 단계부터 진정한 호텔 예약 API 구축까지 첫 번째 끝점이 구현될 때까지.
분석 단계: PM 에이전트 출력
프로젝트 개요와 함께 PM Agent를 호출한 후 생성됩니다. 다음 요구 사항 샤드:
- 프로젝트-overview.md: 상황, 문제, 해결 방법 및 제약 조건
- 페르소나-호텔-owner.md: 호텔 소유자 프로필
- 페르소나-guest.md: 예약한 손님의 프로필
- 요구 사항-예약-crud.md: CRUD 예약 요구 사항
- 요구사항-availability.md: 가용성 계산 요구 사항
- 요구사항-auth.md: 인증/권한 부여 요구 사항
- 제약 조건-예산-timeline.md: 예산 및 시간 제약
아키텍처 단계: Architect Agent의 출력
Architect Agent는 요구 사항 샤드를 소비하고 아키텍처 결정을 내립니다.
- 아키텍처 개요.md: 모듈식 계층 아키텍처
- adr-001-modular-monolith.md: 모듈형 모노리스를 사용하기로 결정
- Adr-002-postgresql.md: PostgreSQL을 데이터베이스로 선택
- API-bookings.md: 예약 API 계약 완료
- db-스키마-bookings.md: 예약 모듈의 데이터베이스 스키마
- 보안 모델.md: 인증을 위한 JWT + RBAC
구현 단계: 작업 중인 개발자 에이전트
개발자 에이전트가 샤드를 받습니다. api-bookings.md 워크플로를 따릅니다.
첫 번째 끝점을 구현하는 TDD입니다. 출력은 테스트가 포함된 작업 코드입니다.
개발 루프를 통해 반복적으로 생성됩니다.
// src/bookings/booking.service.ts
// Generato dal Developer Agent seguendo lo shard api-bookings.md
import { Injectable, ConflictException, NotFoundException } from '@nestjs/common';
import { BookingRepository } from './booking.repository';
import { RoomService } from '../rooms/room.service';
import { CreateBookingDto, BookingResponse } from './booking.dto';
@Injectable()
export class BookingService {
constructor(
private readonly bookingRepo: BookingRepository,
private readonly roomService: RoomService,
) {}
/**
* Crea una nuova prenotazione verificando la disponibilità.
* @shard api-bookings.md - POST /api/v1/bookings
*/
async createBooking(
userId: string,
dto: CreateBookingDto,
): Promise<BookingResponse> {
// Verifica esistenza room
const room = await this.roomService.findById(dto.roomId);
if (!room) {
throw new NotFoundException('Room non trovata');
}
// Verifica disponibilità nel periodo
const isAvailable = await this.roomService.checkAvailability(
dto.roomId,
dto.checkIn,
dto.checkOut,
);
if (!isAvailable) {
throw new ConflictException('Room non disponibile nel periodo richiesto');
}
// Crea prenotazione
const booking = await this.bookingRepo.create({
userId,
roomId: dto.roomId,
checkIn: dto.checkIn,
checkOut: dto.checkOut,
guests: dto.guests,
notes: dto.notes,
status: 'CONFIRMED',
});
return this.toResponse(booking);
}
private toResponse(booking: any): BookingResponse {
return {
id: booking.id,
roomId: booking.roomId,
checkIn: booking.checkIn,
checkOut: booking.checkOut,
guests: booking.guests,
status: booking.status,
createdAt: booking.createdAt,
};
}
}결론
BMAD 방법은 소프트웨어 개발에 대한 성숙하고 체계적인 접근 방식을 나타냅니다. AI의 도움을 받습니다. Document Sharding을 통해 BMAD는 근본적인 문제를 해결합니다. 컨텍스트 오버플로를 방지하여 복잡하지 않은 프로젝트를 관리할 수 있습니다. 문서화 및 구현의 품질이나 일관성을 희생합니다.
BMAD의 진정한 강점은 적응성: 모드에서 21개의 에이전트가 모두 포함된 개인 측면 프로젝트부터 엔터프라이즈 구성까지만 개발, 프레임워크는 프로젝트의 요구에 따라 자연스럽게 확장됩니다. 기술과 결합 자체 배포를 위한 Ralph Wiggum 루프 및 자동화를 위한 후크와 같은 BMAD는 완전하고 효과적인 AI 기반 개발 시스템의 핵심이 됩니다.
핵심 사항
- 문서 샤딩은 컨텍스트 오버플로를 해결합니다. 원자적이고 독립적인 조각을 사용하면 복잡한 프로젝트를 관리할 수 있습니다.
- 21명의 에이전트가 전체 주기를 담당합니다. 요구 사항 분석부터 배포까지 모든 측면에 전담 에이전트가 있습니다.
- 50개 이상의 워크플로우로 모호함 제거: 구조화된 시퀀스는 완전성과 재현성을 보장합니다.
- 규모 적응형 인텔리전스: 프레임워크는 과도한 엔지니어링 없이 나노에서 대규모로 확장됩니다.
- 4개의 반복 단계: 지속적인 주기로 분석, 계획, 아키텍처 및 구현
- 애자일 방법론을 보완합니다. BMAD는 Scrum과 Kanban을 대체하는 것이 아니라 향상시킵니다.
- Claude Code와의 기본 통합: CLAUDE.md, 원활한 작업 흐름을 위한 슬래시 명령 및 후크
다음 기사에서는다중 에이전트 오케스트레이션: 여러 측면에서 동시에 작업하는 Claude Code의 여러 인스턴스를 조정하는 방법 프로젝트의 다양한 측면, 동기화 및 충돌 해결 관리 그리고 공통의 목표를 향한 융합.