멀티 에이전트 오케스트레이션 패턴: 실전 가이드

멀티 에이전트 파일럿의 40%가 실패합니다. 올바른 오케스트레이션 패턴을 선택하고, 실패로 이어지는 패턴을 피하는 방법에 대해 설명합니다.

Page content

2025년, 단일 에이전트 AI 시스템은 정점에 달했습니다 — LLM 하나에 프롬프트, 도구, 목표를 주면 제한된 범위 내의 작업에서 꽤 괜찮은 성과를 내ことができました.

2026년, 멀티 에이전트 시스템은 연구 데모 단계를 벗어나 실제 프로덕션 인프라로 자리 잡았습니다. 가트너(Gartner)에 따르면 2024년 1분기부터 2025년 2분기까지 멀티 에이전트 시스템 관련 문의가 1,445% 증가했으며, 세일즈포스(Salesforce)의 2026 연결성 벤치마크 보고서에 따르면 조직들은 평균 12개의 에이전트를 사용 중이며, 향후 2년 내 67%의 성장률이 전망됩니다. AI 시스템 클러스터는 이러한 시스템이 작동하는 전체 스택 — 추론과 메모리부터 라우팅 및 가시성까지 —을 다루고 있습니다.

여기서 설명하는 오케스트레이터-워커(Orchestrator-Worker)와 계층형(Hierarchical) 패턴을 기반으로 하는 구체적인 프로덕션 워크로드 중 하나는 딥 리서치(Deep Research)입니다. 코디네이터가 질문을 분해하고, 독립적인 서브 에이전트들이 그 조각들을 조사한 후 결과가 종합됩니다. 자체 호스팅 딥 리서치 시스템: 12가지 도구 비교는 DeerFlow, Open Deep Research 및 10개의 다른 시스템이 이 ‘플래너 + 서브 에이전트’ 구조(또는 이를 재귀적 또는 근거 공백 기반 대안으로 구현한 것)를 리서치에 적용하는 방식을 살펴봅니다.

프로덕션 AI 시스템을 위한 멀티 에이전트 오케스트레이션 패턴

하지만 덜 다뤄지는 사실이 있습니다. 프로덕션 배포 후 6개월 이내에 멀티 에이전트 파일럿의 40%가 실패한다는 것입니다. 실패의 원인은 멀티 에이전트 시스템이 작동하지 않는 것이 아닙니다. 문제는 팀이 자신의 문제에 맞는 오케스트레이션 패턴을 잘못 선택하거나, 혹은 올바른 패턴을 선택하더라도 그것이 어떻게 깨지는지 이해하지 못한 채 사용하는 것입니다.

이 가이드에서는 프로덕션에서 견고하게 작동하는 오케스트레이션 패턴, 각 패턴의 구체적 실패 방식, 그리고 올바른 아키텍처를 선택하기 위한 의사결정 프레임워크를 다룹니다.

핵심 문제: 조정(Coordination)은 어렵다

단일 AI 에이전트에서 여러 에이전트가 함께 일하는 환경으로 전환할 때, 첫 번째 엔지니어링 질문은 다음과 같습니다: 그들은 어떻게 조율할 것인가?

조정 모델, 즉 오케스트레이션 패턴은 시스템의 지연 시간(latency), 장애 허용성, 확장성의 한계, 디버깅 복잡도를 결정합니다. 이는 멀티 에이전트 설계에서 일관되게 가장 큰 영향을 미치는 아키텍처적 결정이며, 이후 모든 구현 선택을 제약합니다.

모든 프로덕션 멀티 에이전트 시스템은 6가지 정형화된 패턴 중 하나나 두 가지 이상의 하이브리드에 매핑됩니다. 이러한 패턴은 분산 시스템의 제약 조건 — 조정 비용, 장애 격리, 처리량 요구사항, 가시성 — 에서 파생됩니다.

패턴 1: 오케스트레이터-워커 (Orchestrator-Worker)

작동 방식

오케스트레이터-워커는 멀티 에이전트 조율의 중앙 집중식 허브-스포크(Hub-and-Spoke) 모델입니다. 단일 오케스트레이터 에이전트가 작업을 받아 하위 작업으로 분해하고, 각 하위 작업을 전문 워커 에이전트에 위임한 후 결과를 종합합니다. 워커 에이전트들은 서로 직접 소통하지 않으며 — 모든 조정은 전체 계획과 의사결정 권한을 가진 오케스트레이터를 통해 흐릅니다.

graph TD O[오케스트레이터
플래너] --> WA[워커 A] O --> WB[워커 B] O --> WC[워커 C]

사용 시점

  • 명확한 작업 분해가 가능한 크로스 Функ셔널 워크플로
  • 분류 및 라우팅 시나리오 (고객 지원, 사건 분류)
  • 단일 책임 주체가 필요한 워크로드
  • 오케스트레이터가 유능한 모델을 사용하면서 워커는 저렴하고 작업 특화적인 모델을 사용할 수 있는 작업

실제 사례: 세일즈포스 Agentforce 2.0은 오케스트레이터-워커 모델을 사용하여 고객 문의를 조사, 초안 작성, 검토 단계로 분해합니다.

실패 방식

단일 장애 지점(Single Point of Failure). 오케스트레이터는 병목이자 장애 지점입니다. 오케스트레이터의 LLM 호출에 3초가 걸리고 대기 중인 워커가 20개라면, 분해 처리량 상한선은 대략 초당 6.7개 작업입니다. 오케스트레이터가 작업을 잘못 분류하면, 잘못된 워커에게 작업이 전달됩니다 — 그리고 분류 오류율은 규모가 커질수록 누적됩니다.

컨텍스트 오버플로우. 오케스트레이터는 모든 워커에서 오는 컨텍스트를 누적합니다. 워커가 4개 이상이면, 오케스트레이터가 모든 워커 상호작용의 전체 대화 역사를 동시에 보유해야 하므로 컨텍스트 한계를 초과하는 경우가 빈번합니다.

비용 폭증. 테스트에서는 0.50달러였던 워크플로가 월 10만 회 실행 시 월 5만 달러에 달할 수 있습니다. 오케스트레이터는 모든 워커 호출 위에 분해와 종합을 위해 다수의 LLM 호출을 수행합니다. 대규모에서 오버헤드가 워커 비용을 압도합니다.

완화 전략

  • 오케스트레이터와 워커 사이에 명시적인 인터페이스 계약을 설정하세요
  • 워커에게 구조화된 출력(JSON 스키마, 타입 정의된 응답)을 요구하세요
  • 이탈(runaway) 비용을 방지하기 위해 하위 작업 예산(토큰 제한, 단계 제한)을 설정하세요
  • 워커 수가 5개를 초과할 경우 계층형 변형(패턴 4 참조)을 고려하세요

패턴 2: 순차적 파이프라인 (Sequential Pipeline)

작동 방식

순차적 파이프라인은 공유 상태를 가진 선형 체인으로, 결정론적인 순서가 있는 사전 정의된 에이전트 시퀀스입니다. 각 단계는 데이터를 변환하거나 보강하여 다음 단계로 전달합니다. 런타임 분기(branching)가 없으며 실행 순서는 설계 시점에 고정되어 있어 이 패턴은 매우 예측 가능하지만 유연성은 부족합니다.

graph LR I[입력] --> A1[에이전트 1
단계 A] A1 --> A2[에이전트 2
단계 B] A2 --> A3[에이전트 3
단계 C] A3 --> O[출력]

사용 시점

  • 문서 처리 워크플로 (입력 → 추출 → 검증 → 출력)
  • 콘텐츠 생성 파이프라인 (조사 → 초안 → 편집 → 발행)
  • 컴플라이언스 검증 (생성 → 체크 → 수정 → 승인)
  • 데이터 보강 및 ETL 워크플로

실제 사례: Microsoft Azure 법무법인 워크플로는 계약 생성에 순차적 파이프라인을 사용합니다: 초안 작성 → 검토 → 수정(Redline) → 최종 확정.

실패 방식

오류 전파. 단계 1의 잘못된 출력은 되돌릴 수 없이 하류로 전파됩니다. 조사 단계의 환각(Hallucination)이 flawed한 초안을 생성하고, 편집자는 이를 자신감 있지만 부정확한 최종 출력으로 다듬습니다.

조정 오버헤드. 4개 에이전트의 파이프라인은 처리 시간 500ms에 비해 약 950ms의 조정 오버헤드를 추가합니다. 전문화가 필요하지 않음에도 동일한 결과를 위해 3배의 비용을 지불하는 셈입니다. 토큰 소모도 누적됩니다: 동일한 작업을 수행하는 단일 에이전트 10,000 토큰에 비해 4개 에이전트 파이프라인은 29,000 토큰을 소비합니다.

조건 분기 부재. 파이프라인은 중간 결과에 기반하여 적응할 수 없습니다. 단계 2에서 입력이 잘못된 형식임을 발견하더라도, 단계 1에 재시도를 signaled하는 메커니즘이 없습니다 — 실패하거나 품질이 저하된 출력을 생성할 수밖에 없습니다.

완화 전략

  • 단계 사이에 품질 게이트(하류로 전달하기 전 출력을 체크하는 경량 검증 에이전트)를 삽입하세요
  • 재시도가 가능한 단계에 재처리 루프를 추가하세요 — Temporal과 같은 내구성 워크플로 엔진은 재시도 의미를 안정적으로 처리합니다 Temporal
  • 파이프라인을 최대 3~4단계로 유지하세요; 그 이상이라면 조건 분기를 위해 오케스트레이터-워커를 고려하세요

패턴 3: 팬아웃 / 팬인 (Fan-Out / Fan-In)

작동 방식

팬아웃 / 팬인은 집합(aggregation)을 동반한 병렬 실행입니다. 디스패처가 동시에 실행되는 여러 에이전트로 작업을 라우팅한 후, 컬렉터가 투표, 가중 병합, 또는 LLM 종합을 통해 그 결과를 통합합니다. 에이전트들은 실행 중 독립적으로 작동하며 서로 소통하지 않습니다 — 유일한 공유 경계는 컬렉터입니다.

graph TD D[디스패처] --> AA[에이전트 A] D --> AB[에이전트 B] D --> AC[에이전트 C] AA --> C[컬렉터
병합] AB --> C AC --> C

사용 시점

  • 다양한 관점이 가치 있는 다각적 분석
  • 동시 코드 리뷰 (여러 리뷰어가 병렬로 작업)
  • 사전에 분해할 수 있는 4개 이상의 독립적 작업
  • 토큰 효율성보다 월클락 시간(wall-clock time)이 중요한 워크로드

핵심 지표: 팬아웃은 순차적 실행 대비 월클락 시간을 75% 단축합니다. 4개의 에이전트가 병렬로 실행되면 하나의 에이전트가 걸리는 시간에 완료됩니다.

실패 방식

API 레이트 리밋. 개별 에이전트가 한도 내로 유지하더라도 집단 부하가 용량을 초과할 수 있습니다. 분당 10개 요청을 하는 5개의 에이전트는 단일 에이전트가 준수하는 40 RPM 제한을 초과할 수 있습니다.

이차적 경쟁 조건(Quadratic Race Conditions). 공유 상태 충돌은 N(N-1)/2로 증가합니다. 에이전트가 5개라면 잠재적 충돌은 10건입니다. 10개라면 45건입니다. 상태 관리가 지배적인 복잡도가 됩니다.

집합 환각(Aggregation Hallucination). LLM 종합은 합의점을 발명할 수 있습니다. 에이전트 A가 “예"라고 하고 에이전트 B가 “아니오"라고 할 때, 집합자는 어떤 에이전트도 제안하지 않은 환각된 중도 노선인 “그렇게 될지도 모른다"를 생성할 수 있습니다. 단순 요약이 아닌 명시적인 충돌 해결이 필요합니다.

완화 전략

  • 자유로운 종합 대신 명시적인 투표 메커니즘을 사용하세요
  • 디스패처 레벨에서 레이트 리미팅을 구현하세요
  • 워커별 별도 상태를 유지하고 컬렉터에서 병합하세요
  • 경쟁 조건을 관리 가능하게 유지하기 위해 최대 에이전트 수(5~8개)를 설정하세요

패턴 4: 계층형 (Hierarchical)

작동 방식

계층형은 여러 레벨을 가진 트리 구조 위임입니다. 상층부 매니저가 중간 레벨 슈퍼바이저에게 위임하고, 슈퍼바이저가 리프 레벨 워커에게 위임합니다. 각 레벨은 추상화 계층을 추가합니다: 상단에는 전략, 중간에는 전술, 리프에는 실행. 컨텍스트 윈도우는 각 레벨에서 독립적으로 관리되므로, 단일 에이전트가 전체 문제를 컨텍스트에 보유할 필요가 없습니다.

graph TD TM[상위 매니저] --> SA[슈퍼바이저 A] TM --> SB[슈퍼바이저 B] TM --> SC[슈퍼바이저 C] SA --> W1[워커 1] SB --> W2[워커 2] SC --> W3[워커 3]

사용 시점

  • 20개 이상의 에이전트가 필요한 복잡한 다중 도메인 엔터프라이즈 작업
  • 다른 모듈에 다른 전문가가 필요한 대규모 코드베이스 감사
  • 다중 범주에 걸친 수천 개의 문서 처리
  • 단일 에이전트의 컨텍스트 윈도우로 전체 문제를 감당할 수 없는 작업

핵심 장점: 계층형 시스템은 로그اری즘적으로 확장됩니다. 각 매니저는 제한된 수의 부하를 관리하므로, 워커를 추가해도 조정 오버헤드가 선형적으로 증가하지 않습니다.

실패 방식

지연 시간 누적. 각 레벨이 지연 시간을 추가합니다. 3단계 계층 구조는 최소 6~12초가 필요하며, 레벨별로 누적됩니다. 상위 매니저는 모든 슈퍼바이저를 기다리고, 슈퍼바이저는 모든 워커를 기다립니다.

정보 손실. 레벨 간의 요약은 손실(lossy)을 동반합니다. 슈퍼바이저는 상위 매니저를 위해 워커의 출력을 요약하지만, 최종 결정에 중요할 수 있는 세부 사항이 사라집니다.

분기 장애 격리. 한 분기에서의 장애는 다른 분기로 전파되지 않습니다 — 이는 장애 허용성에는 좋지만 일관성에는 나쁩니다. 상위 매니저가 해결할 수 없는 모순된 결론에 도달하는 서로 다른 분기가 생길 수 있습니다.

완화 전략

  • 각 레벨에 대해 명시적인 요약 요구사항을 설정하세요
  • 상위 매니저에서 분기 간 교차 검증을 구현하세요
  • 계층 깊이를 최대 2~3단계로 유지하세요
  • 정보 손실을 줄이기 위해 모든 레벨에서 구조화된 출력을 사용하세요

패턴 5: 스웜 (Swarm)

작동 방식

스웜은 중앙 권력이 없는 분산형 유기적(coordinating) 조정입니다. 자율적인 에이전트들이 오케스트레이터의 지시 없이 공유 상태(블랙보드)나 환경 신호를 기반으로 로컬 결정을 내립니다. 에이전트들은 이용 가능한 작업을 발견하고, 이를 점유하며, 결과를 공유 공간에 게시합니다. 조정은 유기적으로 발생하며, 중앙 코디네이터 없이 새로운 사택으로 이동하는 꿀벌처럼 시스템이 이용 가능한 작업을 중심으로 자가 조직화됩니다.

graph TB SB[공유 블랙보드
작업 · 결과 · 관찰] AA[에이전트 A] <--> SB AB[에이전트 B] <--> SB AC[에이전트 C] <--> SB AD[에이전트 D] <--> SB AE[에이전트 E] <--> SB AF[에이전트 F] <--> SB

사용 시점

  • 최적 검색 경로가未知的인 리서치 흐름
  • 여러 소스를 통한 경쟁 지능 수집 동적 대상 발견을 동반하는 대규모 웹 스크래핑
  • 과학적 또는 분석적 도메인에서의 병렬 가설 탐색

핵심 장점: 50개의 리서치 에이전트 스웜은 중앙 코디네이터가 탐색을 계획하지 않고도 50개의 가설을 병렬로 탐색할 수 있습니다. 시스템은 이용 가능한 작업을 중심으로 자가 조직화됩니다.

실패 방식

디버깅 악몽. 중앙 제어 흐름이 없으므로, 실패를 추적하려면 분산 트레이싱과 블랙보드 리플레이가 필요합니다. 단일 실행 경로를 따를 수 없으며 — 로그에서 유기적 행동을 재구성해야 합니다.

트랜잭션 보증 부재. 스웜 패턴은 엄격한 순서나 트랜잭션 일관성을 강제할 수 없습니다. 에이전트 A가 완료된 후 에이전트 B가 시작되도록 해야 한다면, 스웜은 잘못된 패턴입니다.

종료 조건. 스웜이 언제 멈춰야 하는지 어떻게 알까요? 명시적인 종료 기준이 없으면, 에이전트들은 무한정 계속되어 컴퓨팅 자원을 소비하고 감소하는 투자 대비 회수를 생성할 수 있습니다.

완화 전략

  • 명시적인 종료 조건(시간 기반, 결과 개수 기반, 또는 수렴 기반)을 구현하세요
  • 상태 변화를 추적하기 위해 버전 관리된 항목을 가진 블랙보드를 사용하세요
  • 스웜 행동을 관찰하고 개입할 수 있는 모니터링 에이전트를 추가하세요
  • 이탈 실행을 방지하기 위해 에이전트 레벨 예산(최대 단계, 최대 토큰)을 설정하세요 — 칸반 스타일 디스패처는 자체 호스팅 스웜 배포에 실용적인 레이트 리밋 및 동시성 패턴을 제공합니다

패턴 6: 메시 (Mesh)

작동 방식

메시는 영속적 연결을 가진 직접적인 피어-투-피어(P2P) 통신입니다 — 에이전트들은 중앙 허브를 통해而非 명시적이고 사전 정의된 채널을 통해 서로 소통합니다. 통신 그래프는 일반적으로 배포 시점에 정의되므로, 에이전트 A는 데이터베이스 쿼리에 에이전트 B가 필요하고 인증 로직에 에이전트 C가 필요함을 알고 있습니다. 이러한 피어들이 별도 서비스, 팀, 또는 벤더에 걸쳐 있다면 트랜스포트 레이어는 변경되며, 아래 에이전트가 경계를 횡단할 때 패턴 구현을 참조하세요.

graph LR A[에이전트 A] --- B[에이전트 B] A --- C[에이전트 C] B --- C

사용 시점

  • 에이전트가 중간 상태를 공유해야 하는 협동 추론
  • 멀티 에이전트 코딩 시스템 (플래너 ↔ 코더 ↔ 테스터 루프)
  • 여러 전문가가 기여하는 반복적 산출물 개선
  • 에이전트가 다른 이해관계자를 대표하는 협상 시나리오

핵심 장점: 반복적 개선에 이상적입니다. 에이전트들은 중앙 집합자 없이 부분 결과를 주고받으며 서로의 작업 위에 쌓아올릴 수 있습니다.

실패 방식

조합 폭발(Combinatorial Explosion). 연결 수는 N(N-1)/2로 확장됩니다. 에이전트가 3개라면 3개의 연결입니다. 8개라면 28개입니다. 3~8개의 긴밀하게 결합된 에이전트로 제한하는 것이 좋습니다.

순환 의존(Circular Dependencies). 에이전트 A가 에이전트 B를 호출하고, B는 C를, C는 다시 A를 호출합니다. 사이클 감지가 없으면, 메시 패턴은 무한 루프에 진입할 수 있습니다.

디버깅 복잡성. 비결정론적 라우팅으로 인해 실패 추적을 거의 불가능하게 만듭니다. 출력이 잘못되었을 때, 어떤 에이전트가 어떤 순서로 서로와 소통했는지 재구성해야 합니다.

완화 전략

  • 배포 시점(런타임이 아닌)에 통신 그래프를 정의하세요
  • 최대 홉(Hop) 제한을 가진 사이클 감지를 구현하세요
  • 명시적인 승인(acknowledgment)을 포함한 메시지 패싱을 사용하세요
  • N홉 후 통신 체인을 종료하는 서킷 브레이커를 추가하세요

에이전트가 경계를 횡단할 때 패턴 구현

오케스트레이션 토폴로지 선택과 에이전트 간 통신 방식 선택은 별개의 결정입니다. 위의 6가지 패턴은 작업이 흐르는 방식 — 누가 누구에게 위임하는지, 단계가 병렬로 실행되는지, 피어가 직접 대화하는지 —을 설명합니다. 하지만 그 에이전트들이 하나의 Python 프로세스, 하나의 Kubernetes 클러스터, 또는 세 개의 벤더 SaaS 제품 안에 존재하는지에 대해서는 규정하지 않습니다.

인-프로세스(In-process) 멀티 에이전트 시스템 — 단일 리포지토리의 LangGraph 그래프, CrewAI 크루, AutoGen 그룹 채팅 — 은 조정을 하나의 런타임 안에서 유지합니다. 메시지 패싱은 함수 호출 또는 공유 상태입니다. 빠른 반복, 단순한 디버깅, 그리고 보안해야 할 네트워크 경계 없음이라는 장점이 있습니다. 에이전트를 독립적으로 배포 가능한 서비스로 분리할 구체적인 이유가 있을 때까지 이것이 올바른 기본값입니다.

에이전트가 다른 팀에 의해 소유되거나, 다른 프레임워크에서 실행되거나, 호출자의 재배포 없이 발견되어야 할 때 경계에서 와이어 프로토콜이 필요합니다. 여기서 A2A vs MCP: AI 에이전트는 정말 두 프로토콜이 모두 필요한가?가 결정점이 됩니다: 메모리를 공유하지 않는 서비스 간에 표준화된 Agent Cards를 통한 발견, 작업 라이프사이클, 산출물 교환, 그리고 MCP만으로 인-프로세스에 머무르는 것 대비 이러한 오버헤드가 가치 있는 시점에 대한 프레임워크를 제공합니다.

패턴을 배포에 매핑하기

에이전트가 별도 서비스가 되더라도 선택한 토폴로지는 여전히 중요합니다. 모든 패턴이 경계를 넘는 A2A로 매끄럽게 매핑되는 것은 아니며, 일부는 본질적으로 내부에 머물러 있습니다.

패턴 동일 런타임 / 프레임워크 경계 횡단 (A2A)
오케스트레이터-워커 그래프 엣지를 통한 인-프로세스 위임 primary assistant가 전문가 Agent Cards로 위임
순차적 파이프라인 하나의 런타임 그래프에서 연결된 단계 드물다 — 지연 시간 위해 단계는 보통 동일 위치에 존재
팬아웃 / 팬인 단일 오케스트레이터 하의 병렬 워커 워커가 이미 별도 서비스가 아닌 한 드물다
계층형 하나의 프로세스에서 중첩된 그래프 상위 오케스트레이터 하의 부서 레벨 에이전트를 A2A 피어로
스웜 하나의 프로세스에서 공유 블랙보드 경계 횡단은 이례적 — 공유 상태 및 거버넌스가 더 어려움
메시 인-프로세스 커스텀 그래프 엣지 주요 A2A 사용 사례 — 팀, 벤더, 또는 프레임워크 간 피어

오케스트레이터-워커와 계층형은 프로덕션에서 가장 일반적인 경계 횡단 형태입니다: 사용자 대상 오케스트레이터가 전문가를 발견하고 위임된 작업을 추적합니다. 단일 허브가 라우팅을 소유해서는 안 되는 경우, 메시가 자연스러운 선택이 됩니다 — 예를 들어, 서로 다른 팀에 의해 소유된 테스트 에이전트와 보안 리뷰 에이전트와 직접 대화하는 코딩 에이전트.

소유권 경계를 넘는 메시

메시 참여자들이 소유권 경계를 넘나들 때, 인-프로세스 그래프 엣지는 A2A 작업 전송으로 변환됩니다. 각 피어는 자신의 스킬, 인증 요구사항, 엔드포인트를 설명하는 Agent Card를 게시합니다. 호출자는 애플리케이션 구성에 URL을 하드코딩하는 대신 런타임 또는 큐레이션된 레지스트리에서 기능을 발견합니다.

여기서 두 가지 배포 스타일이 경쟁합니다. 배포 시점에 사전 정의된 그래프는 메시를 예측 가능하게 유지합니다: 에이전트 A는 에이전트 B와 C를 호출하도록 구성되며, A2A가 와이어 형식과 작업 상태를 처리합니다. 런타임 발견은 오케스트레이터가 스킬이나 벤더가 변경될 때 레지스트리에서 전문가를 선택하게 해주며, 그 대가는 더 많은 움직임 부분과 더 엄격한 거버넌스입니다. 대부분의 팀은 사전 정의된 그래프로 시작하여 에이전트 카탈로그가 구성 파일로 관리할 수 있는 범위를 넘어설 때 발견 기능을 추가합니다.

A2A는 위의 섹션에서 언급한 메시 실패 모드를 제거하지 않습니다. 조합적 연결 성장, 순환 핸드오프, 불투명한 디버깅은 여전히 적용되며 — 단지 인메모리 큐 대신 HTTP 위에서 발생하는 것입니다. 오케스트레이터나 게이트웨이에서 사이클 감지와 최대 홉 제한을 유지하세요. 장기 실행 위임 작업은 각 홉을 차단하는 대신 작업 ID와 비동기 후속 처리를 사용해야 합니다; 장기 실행 에이전트 워크플로를 위한 A2A 스트리밍 및 비동기 작업는 해당 경계에서의 SSE, 푸시 웹훅, input_required 일시 정지를 다룹니다.

피어가 별도 서비스가 되면 인증, 범위 제한 권한, 감사 기록은 필수적이 됩니다. A2A 및 MCP 에이전트 보안: 인증, 위임, 감사 기록는 게이트웨이, 위임 토큰, 각 홉에서 무엇을 기록해야 하는지를 다룹니다.

경계 횡단 에이전트에 특화된 실패 모드

오케스트레이션 패턴이 프로세스 경계를 벗어날 때 자주 나타나는 세 가지 문제가 있습니다:

서비스 간 순환 위임. 1팀의 에이전트 A가 2팀의 에이전트 B에게 위임하고, B가 다시 A나 궁극적으로 A를 호출하는 세 번째 에이전트에게 위임합니다. 메시 섹션의 완화 전략 — 홉 제한, 사이클 감지, 서킷 브레이커 — 는 A2A가 구조화된 메시지를 제공한다고 해서 전제하지 말고 게이트웨이 또는 오케스트레이터에서 강제되어야 합니다.

위임 체인 간 숨겨진 비용 폭증. 각 A2A 홉은 LLM, 도구, 추가 하위 위임을 호출할 수 있습니다. 인-프로세스에서는 저렴해 보이던 토폴로지가 모든 전문가가 과금된 API 호출일 때 토큰 지출을 배증시킵니다. 작업 ID별 및 홉별 비용을 추적하세요; 비용 제어 섹션은 경계 횡단 체인에 직접 적용됩니다.

최종 답변에 대한 모호한 소유권. 두 벤더의 세 에이전트가 산출물에 기여할 때, 사용자와 감사자는 사용자가 보는 출력을 만든 에이전트(그리고 기본 모델 및 도구)를 알아야 합니다. 부모 작업 ID를 전파하고, 위임 체인을 기록하며, 산출물 출처를 사고가 났을 때의 사후 처리가 아닌 일급 가시성 필드로 취급하세요.

다음으로 갈 곳

이 섹션은 오케스트레이션 토폴로지를 프로토콜 선택으로 연결합니다. 각 레이어에 대한 심층적인 내용은 다음과 같습니다:

의사결정 프레임워크

문제를 해결하는 가장 단순한 패턴으로 시작하세요. 대부분의 팀은 단일 에이전트 접근법이 진정으로 고갈되기 전에 멀티 에이전트 토폴로지로 과도하게 아키텍처를 설계합니다.

단계 1: 문제 특성 파악

문제 특성 권장 패턴
알려진 작업 분해, 명확한 전문가 오케스트레이터-워커
고정 순서, 분기 불필요 순차적 파이프라인
독립적 하위 작업, 병렬성 필요 팬아웃 / 팬인
복잡한, 다중 도메인, 20+ 에이전트 계층형
탐색, 미지의 검색 공간 스웜
협동 개선, 피어 통신 메시

단계 2: 제약 조건 추정

제약 조건 피해야 할 패턴
낮은 지연 시간 (< 2초) 계층형, 메시
엄격한 순서 필요 스웜, 팬아웃
단일 책임 주체 스웜, 메시
높은 장애 허용성 필요 오케스트레이터-워커, 순차적
예산 제약 팬아웃 (병렬 = 더 많은 토큰)
복잡한 디버깅 필요 스웜, 메시

단계 3: 단일 에이전트부터 시작

정형화된 에이전트 루프 — 도구, 추론, 반복을 가진 단일 에이전트 — 는 여전히 범용 에이전트의 올바른 기본값입니다. AI 어시스턴트 아키텍처는 단일 에이전트 시스템이 구축되는 5층 기반을 다루며, 멀티 에이전트 조정을 겹치기 전에 이 기반을 마스터하는 것이 가치가 있습니다. 참고로 멀티 에이전트 시스템은 멀티 모델 라우팅과도 근본적으로 다릅니다; 후자의 경우, 모델 선택에 적용되는 순차적, 병렬, 앙상블 패턴을 다루는 멀티 모델 시스템 설계를 참조하세요.

측정이 요구할 때만 멀티 에이전트로 에스컬레이션하세요:

  • 단일 에이전트 컨텍스트 윈도우가 부족할 때
  • 작업이 진정한 병렬성(월클락 시간 중요)을 요구할 때
  • 전문화가 측정 가능한 품질 향상을 제공할 때
  • 단일 에이전트 접근법의 비용이 멀티 에이전트 오버헤드를 초과할 때

이 에스컬레이션의 경량 버전은 이미 개별 코딩 도구 안에 포함되어 있습니다: Claude Code 서브 에이전트는 하나의 도구 내에서 컨텍스트가 무거운 작업을 스코프된 서브 에이전트에 위임하여, 위의 패턴들이 가진 크로스 프로세스 조정 비용 없이 처리합니다 — 전체 오케스트레이션 프레임워크를 찾기 전에 고갈시켜 볼 가치가 있습니다.

백그라운드 및 능동적 에이전트 작업 — 스케줄링, 큐 기반 실행, 내구성 폴링 루프 — 에 대해서는, 멀티 에이전트 오케스트레이션 패턴을 그 아래에 있는 스케줄링 레이어와 보완하는 AI 어시스턴트의 폴링 에이전트: 11가지 구현 패턴을 참조하세요.

실패 모드: MAST 분류법

NeurIPS 2025의 연구(MAST — Multi-Agent System Failure Taxonomy)는 7개의 인기 있는 멀티 에이전트 프레임워크에서 1,600개 이상의 실행 트레이스를 분석했습니다. 실패는 세 가지 근본 범주로 분포됩니다:

1. 명세 모호성 (실패의 33%)

에이전트들의 명령이 underspecified(명세 부족)하여 역할을 오해하거나, 작업을 중복하거나, 검증을 건너뜁니다.

해결책: 명세 스키마를 사용하세요. 모든 에이전트에 대해 명시적인 역할 설명, 작업 경계, 출력 형식을 정의하세요. 구조화된 스키마(JSON, Pydantic 모델)가 자연어 명령보다 우수합니다.

2. 조정 붕괴 (실패의 33%)

에이전트들이 구조화되지 않은 프로토콜을 사용하여 소통하여, 메시지 손실, 경쟁 조건, 순환 핸드오프로 이어집니다.

해결책: 구조화된 조정 프로토콜을 구현하세요. 타입 정의된 메시지 패싱, 승인 메커니즘, 명시적인 종료 조건을 사용하세요.

3. 검증 공백 (실패의 33%)

에이전트 출력의 독립적 검증이 없습니다. 에이전트들은 검증 없이 서로의 출력을 신뢰하여 오류가 전파되도록 허용합니다.

해결책: 독립적 검증 에이전트를 추가하세요. 출력을 받아들이기 전에 출력을 검증하기 위해 별도 모델 또는 검증 단계를 사용하세요. 이것이 메이커-체커(Maker-Checker) 패턴입니다.

비용 제어: 숨겨진 승수

멀티 에이전트 시스템은 비선형적으로 확장되는 비용 구조를 가지고 있습니다:

패턴 비용 승수 (단일 에이전트 대비)
오케스트레이터-워커 2-3배 (오케스트레이터 + 워커)
순차적 파이프라인 3-4배 (각 단계가 전체 토큰 비용을 지불)
팬아웃 / 팬인 4-5배 (모든 에이전트가 완전히 실행)
계층형 3-5배 (깊이에 따라 다름)
스웜 2-10배 (수렴에 따라 다름)
메시 3-6배 (반복 횟수에 따라 다름)

비용 최적화 전략:

  1. 워커에 더 저렴한 모델 사용. 오케스트레이터는 추론 능력이 필요하지만, 워커는 더 작고 빠른 모델을 사용할 수 있습니다.
  2. 실행 예산 제한. 에이전트당 최대 토큰, 최대 단계, 최대 시간을 설정하세요.
  3. 조기 종료 구현. 명확히 실패하거나 성공한 에이전트를 중단하세요.
  4. 공유 컨텍스트 캐싱. 공유 시스템 프롬프트의 재계산을 피하기 위해 프릭스 캐싱(vLLM, SGLang RadixAttention)을 사용하세요.
  5. 에이전트별 비용 모니터링. 총 비용뿐만 아니라 에이전트별 토큰 소모를 추적하세요. 가장 비싼 에이전트를 식별하고 먼저 최적화하세요.

토큰 최적화 전략 — 프롬프트 압축, 캐싱, 배치, 스마트 모델 선택 — 에 대한 더 심층적인 내용은 LLM 비용 감소: 토큰 최적화 전략을 참조하세요. 이 기법은 멀티 에이전트 시스템 내 개별 에이전트 호출에도 동일하게 적용됩니다.

가시성: 블랙박스 내부 보기

멀티 에이전트 시스템은 전통적인 디버깅이 불충분하게 만드는 방식으로 실패합니다. 여러 에이전트가 조율할 때, 문제는 에이전트 경계를 넘나들며 전파되고, 실행 경로는 예측 불가능해지며, 근본 원인을 식별하려면 분산 워크플로에 대한 가시성이 필요합니다. LLM 시스템을 위한 가시성은 멀티 에이전트 시스템이 의존하는 프로덕션 가시성 스택 전체 — 지표, 분산 트레이싱, 로그, SLO, 도구 비교 — 를 다룹니다. vLLM과 llama.cpp 추론 엔드포인트에 Prometheus와 Grafana를 적용하는 것에 대해서는 프로덕션에서 LLM 추론 모니터링을 참조하세요.

필수 가시성 구성 요소

1. 분산 트레이싱

모든 에이전트 간 전체 상호작용 그래프를 캡처하세요. 전통적인 도구는 구성 요소가 실행 중인지 여부를 보여주지만, 멀티 에이전트 디버깅은 구성 요소가 어떻게 상호작용하고 조정이 어디서 깨지는지 이해하는 것을 요구합니다.

추적할 주요 스팬:

  • 오케스트레이터 분해 단계
  • 각 워커의 실행
  • 집합 단계
  • 에이전트 간 통신 (메시/스웜)

2. 블랙보드 리플레이

스웜과 메시 패턴의 경우, 리플레이할 수 있는 버전 관리된 블랙보드를 유지하세요. 이는 실패로 이어진 유기적 행동을 재구성할 수 있게 해줍니다.

3. 비용 귀속

에이전트별, 단계별 토큰 소모를 추적하세요. 불균형한 자원을 소비하는 에이전트를 식별하세요.

4. 수렴 모니터링

스웜과 메시 패턴의 경우, 시스템이 수렴하고 있는지 발산(diverging)하고 있는지를 모니터링하세요. 다음을 위한 경보를 설정하세요:

  • 예상 한계를 초과하는 에이전트 수
  • 임계값을 초과하는 반복 횟수
  • 시간이 지남에 따라 저하되는 출력 품질

프레임워크 지원 매트릭스

패턴 LangGraph AutoGen CrewAI OpenAI Agents SDK
오케스트레이터-워커 ✅ 네이티브 ✅ 네이티브 ✅ 네이티브 ✅ 네이티브
순차적 파이프라인 ✅ 그래프 엣지 ✅ 순차적 ✅ 에이전트 체인 ✅ 핸드오프
팬아웃 / 팬인 ✅ 슈퍼스텝 ✅ 그룹 채팅 ✅ 크루 ✅ 병렬
계층형 ✅ 중첩 그래프 ✅ 계층형 ❌ 제한적 ❌ 제한적
스웜 ❌ 제한적 ✅ 스웜 ❌ 없음 ❌ 없음
메시 ✅ 커스텀 그래프 ✅ 그룹 채팅 ❌ 없음 ❌ 없음

통합하기: 프로덕션 예시

실제 시스템은 단일 패턴에 명확하게 매핑되지 않는 경우가 많습니다 — 대부분의 프로덕션 배포는 두 가지 또는 세 가지 접근법을 결합하며, 각 워크플로의 부분 중 가장 적합하게 처리하는 역할을 맡습니다. AI/ML 오케스트레이션을 위한 Go 마이크로서비스와 같은 인프라 패턴은 이러한 하이브리드 아키텍처를 대규모로 뒷받침하는 서비스 레벨 안무(choreography)와 사가(Saga) 패턴을 설명합니다.

기술적 문의를 처리하는 고객 지원 시스템을 고려해 봅시다:

  1. 분류 (오케스트레이터-워커): 유입 티켓 → 오케스트레이터 분류 → 전문가로 라우팅
  2. 조사 (팬아웃): 전문가 에이전트가 병렬 쿼리 실행 (지식 베이스, 티켓 히스토리, 제품 문서)
  3. 초안 (순차적): 조사 → 응답 초안 → 품질 체크
  4. 에스컬레이션 (계층형): 품질 체크 실패 시, 시니어 에이전트로 에스컬레이션 → 인간 검토

이 하이브리드 접근법은 단일 패턴이 전체 워크플로를 최적적으로 처리하지 못하므로 4가지 패턴을 사용합니다. 핵심 통찰: 패턴을 조합하세요, 단일 패턴에 모든 것을 수행하도록 강요하지 마세요.

핵심 요약

  1. 단순하게 시작. 도구와 함께한 단일 에이전트가 기본값입니다. 측정이 요구할 때만 멀티 에이전트로 에스컬레이션하세요.
  2. 문제에 패턴을 맞추세요. 분해에는 오케스트레이터-워커, 고정 시퀀스에는 파이프라인, 병렬성에는 팬아웃, 규모에는 계층형, 탐색에는 스웜, 협업에는 메시.
  3. 실패 모드를 예상하세요. 모든 패턴은 특정한 방식으로 깨집니다. 배포 전에 완화 전략을 설계하세요.
  4. 비용은 비선형적으로 확장됩니다. 멀티 에이전트 시스템은 토큰 소모를 배증시킵니다. 단일 에이전트 비용의 2~5배를 예산으로 잡으세요.
  5. 가시성은 필수적입니다. 분산 트레이싱과 비용 귀속 없이는 멀티 에이전트 시스템을 디버깅하거나 최적화할 수 없습니다.
  6. 패턴을 조합하세요. 대부분의 프로덕션 시스템은 2~3가지 패턴을 결합하여 사용합니다. 모든 것을 단일 패턴으로 처리하도록 강요하지 마세요.

멀티 에이전트 지형도는 빠르게 성숙해지고 있습니다. 성공하는 팀은 트레이드오프를 이해하고, 패턴을 의도적으로 선택하며, 첫날부터 가시성을 구축하는 팀입니다.

자주 묻는 질문

멀티 에이전트 오케스트레이션이란 무엇인가? 멀티 에이전트 오케스트레이션은 여러 AI 에이전트가 작업을 함께 수행하는 방식을 지배하는 조정 모델입니다. 선택한 패턴 — 허브-스포크, 파이프라인, 팬아웃, 계층형, 스웜, 또는 메시 — 은 시스템의 지연 시간, 장애 허용성, 확장성 한계, 디버깅 복잡도를 결정합니다. 각 패턴은 다른 트레이드오프를 만들며 다른 방식으로 실패합니다.

프로덕션 AI 시스템에 가장 좋은 멀티 에이전트 패턴은 무엇인가? 대부분의 프로덕션 시스템은 오케스트레이터-워커로 시작합니다. 명확한 책임 소재, 디버깅 가능한 제어 흐름, 예측 가능한 비용을 제공합니다. 워커 수가 5~8개를 초과하면 계층형으로, 독립적인 병렬 작업이 워크로드를 지배하면 팬아웃으로 에스컬레이션하세요. 스웜과 메시는 여전히 탐색 워크플로와 긴밀한 피어 협력을 위해 각각 예약된 니치 패턴으로 남아 있습니다.

왜 멀티 에이전트 파일럿의 40%가 실패하는가? NeurIPS 2025의 MAST 분류법에 따르면, 세 가지 근본 원인은 명세 모호성(에이전트가 역할을 오해하거나 검증 단계를 건너뜀), 조정 붕괴(구조화되지 않은 메시징이 메시지 손실과 순환 핸드오프로 이어짐), 검증 공백(에이전트 출력의 독립적 검증 부재로 오류가 무분별하게 전파됨)입니다. 각 범주는 1,600개 이상 분석된 실행 트레이스에 걸쳐 모든 실패의 약 3분의 1을 차지합니다.

멀티 에이전트 시스템은 단일 에이전트보다 얼마나 비싼가? 패턴에 따라 토큰 비용이 2배에서 10배까지 예상하세요. 오케스트레이터-워커가 23배로 가장 저렴합니다. 에이전트가 병렬로 실행되고 각자가 독립적으로 전체 토큰 예산을 소비하므로 팬아웃과 스웜이 410배로 가장 비쌉니다. 이러한 승수는 대규모에서 누적됩니다 — 테스트에서 0.50달러였던 워크플로가 월 10만 회 실행 시 월 5만 달러에 달할 수 있습니다.

무언가 잘못되었을 때 멀티 에이전트 시스템을 어떻게 디버깅하는가? 분산 트레이싱으로 시작하세요 — 각 에이전트 호출, 도구 호출, 집합 단계에 대한 스팬을 가진 실행당 하나의 트레이스. 스웜과 메시 패턴의 경우, 블랙보드 리플레이를 구현하여 로그에서 유기적 행동을 재구성할 수 있게 하세요. 에이전트별 비용 귀속은 프로덕션 규모에 도달하기 전에 연쇄적 실패 또는 이탈 지출을 유발하는 에이전트를 식별하는 데 도움이 됩니다.

멀티 에이전트 패턴이 인-프로세스 오케스트레이션 대신 A2A가 필요한 경우는 언제인가? 모든 에이전트가 하나의 런타임, 리포지토리, 팀을 공유할 때 인-프로세스에 머물러 있어야 합니다. 전문가가 독립적으로 배포되거나, 다른 팀이나 벤더에 의해 소유되거나, Agent Cards를 통해 호출자를 재배포하지 않고 발견되어야 할 때 경계에서 A2A를 추가하세요. 오케스트레이터-워커와 메시가 가장 일반적인 경계 횡단 형태입니다; 전체 매핑 테이블은 에이전트가 경계를 횡단할 때 패턴 구현을 참조하세요.

구독하기

시스템, 인프라, AI 엔지니어링에 관한 새 글을 받아보세요.