팀에 사람이 늘어난다고 일이 잘 되는 건 아니듯, AI 에이전트도 구조 없이 늘리면 혼선만 커집니다. Anthropic이 멀티 에이전트 시스템의 5가지 조율 패턴과, 각 패턴이 언제 효과적이고 언제 무너지는지를 정리한 글을 발표했습니다. 핵심은 하나입니다. “가장 정교해 보이는 패턴이 아닌, 문제 구조에 맞는 패턴을 골라야 한다.”
출처: Multi-agent coordination patterns: Five approaches and when to use them – Anthropic
가장 단순한 패턴부터: Generator-Verifier
첫 번째 패턴은 이름 그대로입니다. 하나의 에이전트가 결과물을 만들고(Generator), 다른 에이전트가 그것을 검증합니다(Verifier). 검증에 실패하면 피드백과 함께 Generator로 돌아가고, 다시 시도합니다.
고객 지원 이메일 자동 작성 시스템을 예로 들면, Generator가 티켓 내용을 바탕으로 초안을 쓰고, Verifier는 제품 정보와의 일치 여부, 브랜드 톤 적합성, 티켓의 모든 문제가 다뤄졌는지를 체크합니다. 코드 생성(한쪽이 코드 작성, 다른 쪽이 테스트 실행), 팩트 체킹, 컴플라이언스 검증 등에 잘 맞습니다.
다만 Verifier의 품질이 기준의 구체성에 달려 있다는 점이 함정입니다. “결과가 좋은지 확인해”처럼 모호한 기준을 주면 Verifier는 그냥 통과시켜 버립니다. 또, 두 에이전트가 계속 의견이 맞지 않으면 루프에서 빠져나오지 못합니다. 반드시 최대 반복 횟수와 탈출 조건을 설정해야 합니다.
위계가 필요한 작업: Orchestrator-Subagent
하나의 리드 에이전트(Orchestrator)가 작업을 계획하고 분배하면, 각 서브에이전트가 맡은 역할을 완료하고 결과를 돌려주는 패턴입니다. Claude Code가 이 구조로 작동합니다. 메인 에이전트가 직접 코드를 작성하면서, 대규모 코드베이스 탐색처럼 병렬로 처리할 작업은 서브에이전트에게 위임합니다.
PR이 들어오면 보안 취약점 검사, 테스트 커버리지 확인, 코드 스타일 평가, 아키텍처 일관성 검토를 각각의 서브에이전트에게 맡기고, Orchestrator가 결과를 종합하는 코드 리뷰 시스템이 좋은 예시입니다.
단점은 Orchestrator가 정보 병목이 된다는 점입니다. 보안 서브에이전트가 발견한 취약점이 아키텍처 서브에이전트의 분석에도 영향을 준다면, 그 정보는 Orchestrator를 거쳐 전달되어야 합니다. 이 과정에서 중요한 맥락이 누락되기 쉽습니다.
오래 달리는 작업에는: Agent Teams
Orchestrator-Subagent와 비슷해 보이지만 결정적 차이가 있습니다. 서브에이전트는 한 번의 작업을 마치면 종료되지만, Agent Teams의 팀원(teammate)은 여러 작업에 걸쳐 살아있습니다. 맡은 도메인에 대한 맥락을 축적하면서 성능이 개선됩니다.
대규모 코드베이스를 새 프레임워크로 전환하는 작업이 전형적인 사례입니다. 각 서비스를 팀원 에이전트에게 하나씩 배정하면, 각 팀원은 자신이 담당한 서비스의 의존성, 테스트 패턴, 배포 설정에 익숙해지면서 전체 마이그레이션을 진행합니다.
독립성이 핵심 전제입니다. 팀원들이 서로의 작업에 영향을 받는 상황이 생기면 이 패턴은 무너집니다. 여러 팀원이 같은 파일을 동시에 수정하거나, 한쪽의 변경이 다른쪽 작업을 무효화하는 충돌 상황에 대비한 파티셔닝과 충돌 해소 메커니즘이 필요합니다.
규모가 커질 때: Message Bus
에이전트 수가 늘고 상호작용이 복잡해지면, 직접 조율은 한계에 부딪힙니다. Message Bus는 공유 통신 레이어를 두고, 에이전트들이 이벤트를 발행(publish)하거나 구독(subscribe)하는 방식으로 연결됩니다.
보안 운영 자동화 시스템이 대표적입니다. 여러 소스에서 알림이 들어오면 분류 에이전트가 심각도와 유형을 판단해 네트워크 조사 에이전트나 신원 분석 에이전트로 라우팅하고, 각 조사 결과는 다시 대응 조율 에이전트로 흘러갑니다. 새로운 위협 유형이 생겨도 새 에이전트를 추가하면 그만이라 확장성이 뛰어납니다.
반면 추적이 어렵습니다. 하나의 알림이 다섯 에이전트를 거치는 연쇄를 추적하려면 꼼꼼한 로깅과 상관관계 분석이 필요합니다. 라우터가 이벤트를 잘못 분류하거나 누락시키면 조용히 실패합니다. 아무것도 처리되지 않았는데 시스템은 멀쩡하게 작동 중인 것처럼 보이는 상황이 생깁니다.
에이전트들이 서로 배워야 할 때: Shared State
앞의 네 패턴에는 모두 중앙에서 정보 흐름을 관리하는 주체가 있습니다. Shared State는 그 중간 관리자를 없앱니다. 모든 에이전트가 공유 저장소(데이터베이스, 파일 시스템, 문서)를 직접 읽고 씁니다.
복잡한 질문을 여러 각도에서 동시에 조사하는 연구 종합 시스템에 적합합니다. 학술 문헌 에이전트가 발견한 핵심 연구자 정보를 산업 보고서 에이전트가 즉시 볼 수 있고, 방향을 조정할 수 있습니다. 중앙 코디네이터를 거치지 않으니 발견이 실시간으로 공유됩니다.
이 패턴의 까다로운 실패 모드는 ‘반응 루프’입니다. A가 발견을 기록하면 B가 읽고 후속 내용을 쓰고, A가 다시 반응하는 구조에서 시스템이 계속 토큰을 태우며 수렴하지 못하는 상황이 생깁니다. 시간 예산, 수렴 임계값(N번의 사이클 동안 새 발견이 없으면 종료), 혹은 종료 판단을 전담하는 에이전트가 반드시 필요합니다.
어떤 패턴을 골라야 하나
Anthropic은 패턴 선택을 위한 구조적 질문 몇 가지로 정리합니다.
- 서브태스크가 짧고 명확한 결과를 내는가 → Orchestrator-Subagent / 여러 사이클에 걸쳐 맥락을 쌓아야 하는가 → Agent Teams
- 워크플로가 미리 정해져 있는가 → Orchestrator-Subagent / 이벤트에 따라 흐름이 달라지는가 → Message Bus
- 에이전트들이 서로 독립적으로 작동하는가 → Agent Teams / 실시간으로 서로의 발견을 공유해야 하는가 → Shared State
대부분의 경우 Orchestrator-Subagent에서 시작해 어디서 막히는지 확인한 뒤, 필요에 따라 진화시키는 게 Anthropic의 권장 방식입니다. 실제 프로덕션에서는 패턴을 혼합해서 씁니다. 전체 워크플로는 Orchestrator-Subagent로, 협업이 많은 서브태스크는 Shared State로 처리하는 식입니다.
원문에는 각 패턴 간 전환 시점을 판단하는 비교 다이어그램과, 패턴별 선택 요약 테이블도 포함되어 있습니다.
참고자료: Building multi-agent systems: when and how to use them – Anthropic
답글 남기기