에이전트를 여러 개 굴리는 것 자체는 어렵지 않다. 진짜 어려운 건 그 에이전트들이 서로 다른 역할로 일관성 있게 움직이게 만드는 것이다. BMAD(Breakthrough Method for Agile AI-Driven Development)는 그 문제를 정면으로 겨냥한 오픈소스 방법론이다. 핵심 전제는 단순하다. 한 에이전트에게 기획·설계·구현·테스트를 동시에 맡기는 건, 신입 한 명 뽑아놓고 PM·아키텍트·개발자·QA를 전부 시키는 것과 같다. 사람도 안 되고, 모델도 안 된다.
BMAD는 이 문제를 역할 분리로 푼다. Business Analyst가 요구사항을 먼저 문서화하고, Product Manager가 수용 기준을 구체화하고, Architect가 코드 한 줄 쓰기 전에 모듈 경계와 데이터 계약을 정의한다. Developer 에이전트는 이 모든 컨텍스트를 '고정된 입력값'으로 받아 구현만 담당한다. 각 에이전트는 자기 시스템 프롬프트 안에서만 움직인다. 이 구조가 낯설어 보이지만, 사실 소프트웨어 공학에서 오래된 개념인 Spec-Driven Development의 에이전트 버전이다. 중요한 건 방법론의 이름이 아니라, 코드 생성 전에 '무엇을 만들지'를 완전히 확정한다는 원칙이다.
그런데 이 방법론을 실제 팀에 도입하려는 순간, 현실적인 질문이 생긴다. 에이전트가 역할대로 움직이지 않으면 어떻게 되는가? 이 질문에 대한 가장 생생한 답이 최근 국내 연구실에서 나왔다. 팀원이 Claude Code를 통해 120B 양자화 모델을 테스트하려다, Claude가 어떤 이유에서인지 300B 모델 로딩 작업으로 해석해 실행해버린 사건이다. 128GB RAM 서버에서 300B 모델을 억지로 올리려 했으니 결과는 예정된 것이었다. 더 심각한 문제는 부팅 이후였다. vLLM이 시작 프로그램으로 자동 실행되도록 설정되어 있었고, 서버는 살아나자마자 스스로를 다시 죽이는 루프에 빠졌다. 결국 Docker 자동 시작을 비활성화해서야 루프가 끊겼다.
이 사건이 BMAD와 연결되는 지점이 정확히 있다. BMAD의 Architect 역할이 설계하는 것은 코드 구조만이 아니다. 에이전트가 실행할 수 있는 작업의 범위, 즉 허용 경계도 아키텍처 설계의 일부여야 한다. 위 사건에서 Claude는 아키텍처 결정권을 가진 에이전트가 아니었다. 팀원의 지시를 받아 스크립트를 실행하는 Developer 역할이었다. 그런데 작업 범위에 '서버에 직접 모델을 올리는 것'이 포함되어 있었고, 컨텍스트 오해 하나가 서버를 다운시켰다. BMAD 방법론이 아무리 역할을 잘 분리해도, 각 역할의 실행 권한과 취소 불가 작업의 범위를 사전에 정의해두지 않으면 에이전트 전문화는 오히려 사고의 책임 소재를 흐리게 만든다.
품질 측면의 리스크는 더 구조적이다. Veracode의 2025년 보고서에 따르면 AI 생성 코드 샘플의 45%가 OWASP Top 10 취약점을 포함하고, 86%가 XSS 방어에 실패한다. 스탠퍼드의 무작위 대조 실험은 AI 도구를 쓴 개발자들이 더 빠르게 코드를 출하하면서 보안에 더 높은 자신감을 보고했지만 실제 코드는 더 취약했다는 결과를 보여준다. 이 '자신감 격차'가 AI 생성 취약점이 프로덕션에 도달하는 핵심 경로다. BMAD의 Developer 에이전트가 아무리 명확한 스펙을 받아도, 그 출력물에 대한 보안 검증 레이어가 없으면 전문화된 에이전트는 전문화된 취약점 생성기가 될 수 있다.
그렇다면 BMAD를 도입할 때 실제로 먼저 설계해야 할 것은 무엇인가. 세 가지다.
첫째, 에이전트별 실행 권한 매트릭스. Business Analyst와 Product Manager 에이전트는 문서만 생성한다. Architect는 설계 문서만. Developer 에이전트만 코드를 생성하되, 인프라 변경 명령은 실행할 수 없도록 역할 경계를 시스템 프롬프트와 도구 접근 권한 양쪽에서 동시에 잠가야 한다. 프롬프트 수준의 역할 분리만으로는 부족하다.
둘째, 취소 불가 작업에 대한 인간 승인 게이트. 서버 설정 변경, 패키지 배포, 환경 변수 수정처럼 롤백 비용이 높은 작업은 에이전트가 실행 계획을 먼저 출력하고 사람이 확인한 뒤 실행되는 구조여야 한다. Claude Code 서버 사건은 이 게이트가 없었을 때 어떤 일이 일어나는지를 보여준다.
셋째, Developer 에이전트 출력물에 대한 자동화 보안 검증 파이프라인. BMAD가 스펙 먼저, 코드 나중이라는 순서를 지킨다면, 코드 생성 이후 단계에도 같은 논리가 적용되어야 한다. 생성 → 정적 분석 → 취약점 스캔 → 의존성 검증을 에이전트 워크플로우 안에 순차적으로 배치해야 한다.
BMAD의 구조는 실용적이고, 즉시 적용 가능하다. 역할 전문화가 컨텍스트 오염을 막고 모델의 집중력을 높인다는 전제는 실제로 작동한다. 하지만 에이전트 팀을 설계할 때 역할 분담표보다 먼저 그려야 하는 것이 있다. 각 역할이 실행할 수 있는 것과 없는 것의 경계, 그리고 그 경계를 넘으려 할 때 작동하는 제어 구조다. 방법론은 팀의 속도를 올려주지만, 안전 설계는 그 속도가 팀 바깥으로 튀어나가지 않게 막아준다. 두 가지는 함께 설계되어야 한다.