하나의 에이전트가 다른 에이전트를 호출하는 것은 유용합니다. 진정한 힘은 여러 에이전트를 조합할 때 나타나며, 몇 가지 패턴이 어디에서나 반복됩니다.

A2A는 아키텍처를 규정하지 않지만, 이 분야는 소수의 오케스트레이션 (Orchestration) 패턴으로 수렴되었습니다.

가장 일반적인 것은 **오케스트레이터 패턴 (orchestrator pattern)**입니다. 하나의 에이전트가 요청을 받고 전문가들에게 하위 작업 (sub-tasks)을 위임한 다음, 그들의 결과를 취합합니다. 위임은 순차적 (sequential) (각 결과가 다음 단계로 전달됨) 방식이거나 병렬 (parallel) (독립적인 하위 작업을 동시에 수행) 방식일 수 있습니다.

항상 중심이 필요한 것은 아닙니다. 클라이언트 (client)와 원격 에이전트 (remote agent)는 단지 역할일 뿐이므로, 에이전트들은 병목 현상 없이 가장 적합한 에이전트에게 작업이 흐르도록 피어 투 피어 (peer-to-peer) 핸드오프를 할 수도 있습니다.

오케스트레이터 패턴 (The orchestrator pattern)

가장 일반적인 형태는 요청을 받고 전문화된 원격 에이전트들에게 하위 작업을 위임한 다음, 그들의 결과를 취합하는 단일 오케스트레이터 에이전트입니다. 오케스트레이터는 계획을 보유하고, 전문가들은 집중적인 작업을 수행합니다.

이는 A2A에 자연스럽게 매핑됩니다. 오케스트레이터는 각 전문가에게 클라이언트이며, 각 전문가는 자신의 기술을 노출하는 원격 에이전트입니다. 특별한 것이 필요하지 않습니다. 이는 의도적으로 사용되는 기본 프로토콜입니다.

순차적 vs 병렬 위임 (Sequential vs parallel delegation)

• 순차적 (Sequential) — 오케스트레이터가 단계별로 위임하며, 각 에이전트의 아티팩트 (Artifact)를 다음 에이전트에게 전달합니다. 후속 작업이 이전 결과에 의존할 때 사용합니다.
• 병렬 (Parallel) — 오케스트레이터가 독립적인 하위 작업을 동시에 위임하고 완료되는 대로 결과를 수집합니다. 하위 작업들이 서로 의존하지 않을 때, 속도를 위해 사용합니다.

실제 사례: 사용자가 시장 보고서를 요청합니다. 오케스트레이터는 데이터 수집을 리서치 에이전트에게, 차트 작성을 시각화 에이전트에게 위임합니다. 두 작업 모두 서로를 필요로 하지 않으므로 병렬로 진행됩니다. 두 작업 모두 완료될 때까지 스트리밍됩니다. 오케스트레이터는 두 개의 아티팩트 (Artifacts)를 수집하여 보고서를 작성합니다.

피어 위임 및 핸드오프 (Peer delegation and handoffs)

모든 시스템에 중앙 오케스트레이터 (Orchestrator)가 필요한 것은 아닙니다. 에이전트들은 피어 투 피어 (Peer-to-peer, P2P) 방식으로 위임할 수도 있습니다. 예를 들어, 지원 에이전트 (Support agent)가 결제 관련 질문을 결제 에이전트 (Billing agent)에게 직접 전달하고, 결제 에이전트는 다시 사기 탐지 에이전트 (Fraud agent)에게 문의할 수 있습니다.

"클라이언트 (Client)"와 "원격 에이전트 (Remote agent)"는 단일 상호작용 내에서의 역할일 뿐이므로, 어떤 에이전트든 자신이 발견할 수 있는 다른 어떤 에이전트에게도 위임할 수 있습니다. 이러한 방식의 핸드오프 (Handoffs)는 모든 작업을 하나의 병목 지점 (Bottleneck)을 통해 라우팅하지 않고도, 가장 적합한 에이전트에게 작업이 흐를 수 있도록 합니다.

형태 선택하기 (Choosing a shape)

단 하나의 정답인 아키텍처는 없으며, 오직 귀하의 우선순위에 부합하는 아키텍처가 있을 뿐입니다.

패턴을 당신이 두려워하는 실패 유형에 맞추십시오. 제어(Control)냐, 회복탄력성(Resilience)이냐 — 의도적으로 선택하십시오.

패턴의 조합 (Patterns compose)

실제 시스템에서 하나의 형태만을 고립되어 사용하는 경우는 드뭅니다. 최상위 오케스트레이터가 여러 전문가 에이전트에게 병렬로 작업을 분산(Fan out)할 수 있으며, 그중 하나는 내부적으로 자체적인 짧은 순차적 파이프라인 (Sequential pipeline)을 실행하고, 다른 하나는 런타임 (Runtime)에 발견한 에이전트에게 피어 투 피어 방식으로 핸드오프를 수행할 수도 있습니다.

이 패턴들이 조합될 수 있는 이유는 이들이 모두 클라이언트와 원격 에이전트 역할을 수행하는 에이전트일 뿐이기 때문입니다. 문제를 해결할 수 있는 가장 단순한 형태부터 시작하고, 속도, 회복탄력성, 또는 유연성과 같은 구체적인 필요성이 생길 때만 다른 레이어를 추가하십시오.

대규모 환경에서의 발견 (Discovery at scale)

에이전트의 수가 증가함에 따라, 엔드포인트 (Endpoints)를 하드코딩 (Hard-coding)하는 방식은 확장성을 유지할 수 없습니다. 여기서 에이전트 카드 (Agent Cards)의 가치가 발휘됩니다. 오케스트레이터는 고정된 주소를 아는 대신, 작업을 광고된 기술 (Skills)과 매칭함으로써 에이전트를 선택할 수 있습니다.

A2A (Agent-to-Agent) 에이전트의 레지스트리 (Registries)와 디렉토리 (Directories)는 이를 더욱 확장하여, 시스템이 역량 있는 에이전트를 동적으로 찾을 수 있게 합니다. 이는 마이크로서비스 (Microservices)에서의 서비스 디스커버리 (Service discovery)와 에이전트 측면에서 동일한 개념입니다.

이 작업을 제대로 수행했는지 확인하는 실질적인 테스트는 다음과 같습니다: 오케스트레이터를 수정하지 않고도 새로운 전문가 에이전트를 추가할 수 있는가? 만약 그렇다면, 당신은 기술에 기반하여 위임하고 있는 것입니다. 만약 그렇지 않다면, 당신은 하드코딩을 하고 있는 것입니다.

세 가지 안티 패턴 (Three anti-patterns)

• 전지전능한 오케스트레이터 (The god orchestrator) — 다른 모든 에이전트의 내부 구조를 알고 있는 단일 에이전트입니다. 이는 설계 의도에 어긋납니다. 하드코딩된 지식이 아니라, 공표된 기술 (advertised skill)에 따라 위임하십시오.
• 수다스러운 위임 (Chatty delegation) — 잘 구성된 하나의 작업으로 충분할 때 작은 메시지들을 계속해서 주고받는 방식입니다. 각 단계(hop)는 지연 시간 (latency)과 실패 가능성 (failure surface)을 증가시킵니다.
• 침묵하는 팬아웃 (Silent fan-out) — 집계 (aggregation)나 타임아웃 (timeout) 전략 없이 수많은 병렬 작업을 실행하는 것입니다. 이로 인해 하나의 느린 에이전트가 전체 결과의 흐름을 막을 수 있습니다.

비용과 지연 시간은 실재합니다

모든 위임은 네트워크 홉 (network hop)을 추가하며, 종종 또 다른 모델 호출 (model call)을 수반합니다. 여러 에이전트로 팬아웃 (fan-out)되는 워크플로우는 단일 에이전트 워크플로우보다 더 느리고 비용이 많이 들 수 있습니다.

이를 염두에 두고 설계하십시오. 독립적인 작업은 병렬화 (parallelize)하고, 잘 구성된 하나의 작업으로 충분한 곳에서 수다스러운 주고받기를 피하며, 특정 단계가 정말로 별도의 에이전트를 필요로 하는지 아니면 하나의 에이전트 내에서 도구 호출 (tool call)로 처리될 수 있는지 솔직하게 자문해 보십시오.

멀티 에이전트는 목적이 아니라 수단입니다. 멀티 에이전트가 인상적으로 들리기 때문이 아니라, 전문화 (specialization)나 규모 (scale)가 그 오버헤드 (overhead)를 정당화할 수 있을 때 도입하십시오.

오케스트레이션의 관찰 가능성 유지하기

오케스트레이션된 워크플로우는 그 흔적 (trail)만큼만 디버깅이 가능합니다. 단일 요청이 여러 에이전트를 통과할 수 있으므로, 최상단에서 상관관계 식별자 (correlation identifier)를 부착하고 모든 위임 과정에서 이를 유지하십시오.

해당 ID를 기준으로 각 작업의 시작, 상태 변경, 결과를 로그로 남기십시오. 세 번째 에이전트 단계에서 무언가 잘못되었을 때 — 그리고 결국에는 반드시 발생할 것입니다 — 이는 흔적을 읽는 것과 추측하는 것의 차이를 만듭니다.

자주 묻는 질문 (FAQ)

멀티 에이전트 시스템에서 오케스트레이터 패턴이란 무엇인가요?
하나의 에이전트가 요청을 받고 전문화된 원격 에이전트들에게 하위 작업 (sub-tasks)을 위임한 다음, 그 결과들을 조립하는 방식입니다. 오케스트레이터는 계획을 보유하고, 전문가(specialists)들은 집중된 작업을 수행합니다. A2A (Agent-to-Agent) 환경에서 오케스트레이터는 단순히 각 전문가에 대한 클라이언트 역할을 합니다.

병렬 위임과 순차적 위임 중 언제 무엇을 사용해야 하나요?
하위 작업들이 서로 의존하지 않는다면 병렬 위임이 더 빠릅니다. 후속 작업이 이전 작업의 결과가 필요하다면 순차적 위임을 사용하십시오. 대부분의 실제 워크플로우는 이 두 가지를 혼합하여 사용합니다.

항상 중앙 오케스트레이터(Central Orchestrator)가 필요한가요?
아니요. 클라이언트와 원격 에이전트(Remote Agent)는 고정된 유형이라기보다 역할(Role)에 가깝기 때문에, 에이전트 간 피어 투 피어 (Peer-to-Peer) 위임이 가능합니다. 피어 위임(Peer delegation)은 더 탄력적(Resilient)이고 병목 현상을 방지할 수 있지만, 엔드 투 엔드(End-to-end)로 추적하기는 더 어렵습니다.

오케스트레이터는 어떻게 적절한 에이전트를 찾나요?
고정된 엔드포인트(Endpoint)를 아는 대신, 에이전트 카드(Agent Cards)에 명시된 기술(Skills)과 작업을 매칭함으로써 찾습니다. 레지스트리(Registries)는 이를 더욱 확장합니다. 테스트 방법은 다음과 같습니다: 오케스트레이터를 수정하지 않고도 새로운 전문가를 추가할 수 있는가?

멀티 에이전트가 항상 단일 에이전트보다 나은가요?
아니요. 모든 위임은 네트워크 홉(Network hop)을 추가하고 보통 또 다른 모델 호출을 수반하므로, 멀티 에이전트 워크플로우는 더 느리고 비용이 많이 들 수 있습니다. 전문화(Specialization)나 규모(Scale)가 오버헤드(Overhead)를 감수할 만큼 진정으로 가치가 있을 때만 멀티 에이전트를 사용하십시오.

이 시리즈의 다른 글들

• A2A vs MCP — A2A vs MCP: 모든 진지한 AI 에이전트 시스템 뒤에 있는 두 가지 프로토콜
• What Is A2A? — Agent2Agent 프로토콜이란 무엇인가? A2A에 대한 완전한 입문서
• The Agent Card — 에이전트 카드: AI 에이전트가 서로를 발견하는 방법

더 깊이 알고 싶으신가요?

이 주제에 대해 두 가지 가이드를 작성했습니다.

A2A Quick-Start — 무료, 6페이지. 15분 만에 배우는 Agent2Agent 프로토콜: 정의, 5가지 구성 요소, 작업 생명주기(Task lifecycle), 그리고 MCP가 어디에 위치하는지에 대해 다룹니다.

A2A: The Complete Guide — 42페이지. 15개 장과 5개의 부록으로 구성되어 있습니다. 발견(Discovery), 보안(Security), SDK를 이용한 첫 번째 에이전트 구축, 오케스트레이션 패턴(Orchestration patterns), 확장(Extensions) 및 AP2, 프로덕션 및 스케일링(Scaling)을 다루며, 두 에이전트가 대화하는 전체 실습 예제와 30일 도입 경로가 포함되어 있습니다.