멀티에이전트 설계 패턴과 A2A·ADK 아키텍처 선택 가이드

단일 에이전트가 병목이 되는 지점

단일 LLM 에이전트에 복잡한 업무를 몰아주면 문맥 창(context window)의 한계, 단일 장애 지점(Single Point of Failure), 도메인 전문성 부족이라는 세 가지 구조적 제약이 드러난다. 한 개체가 판단과 실행을 모두 떠안으면서 성능이 떨어지고, 문제가 생겼을 때 어느 단계에서 잘못됐는지 추적하기도 어려워진다.

Google의 공식 가이드는 “복잡하고 확장 가능한 에이전틱 애플리케이션을 구축하려면 다른 소프트웨어 시스템에 사용되는 것과 동일한 규율 있는 접근법이 필요하다”고 명시한다. 멀티에이전트 설계는 단순히 에이전트 수를 늘리는 방식이 아니라, 기존 분산 시스템처럼 책임과 통신 경계를 명시하는 작업에 가깝다.

역할을 분리하면 각 에이전트를 독립적으로 유지보수하고 테스트할 수 있어 모듈성이 높아진다. 도메인별 전문 에이전트를 배치하면 전문화가 가능하고, 서로 의존하지 않는 태스크는 병렬로 실행할 수 있다. 한 에이전트가 감당하기 어려운 정보량을 나눠 처리한다는 점에서는 문맥 관리 수단이기도 하다. 모듈성, 전문화, 병렬 처리, 문맥 관리가 멀티에이전트 시스템의 네 가지 핵심 이점이다.

협업 구조에 따라 달라지는 설계 패턴

Google이 제시한 8가지 패턴은 실행 순서와 제어권을 어디에 두는지에 따라 구분된다. 같은 업무라도 결과가 이전 단계에 의존하는지, 동시에 처리할 수 있는지, 중앙 조정자가 필요한지에 따라 적합한 구조가 달라진다.

순차 파이프라인

에이전트 A의 출력이 에이전트 B의 입력으로 이어지는 조립 라인형 구조다. 실행 흐름이 선형적이고 결정론적이어서 데이터 처리 파이프라인처럼 단계 사이의 의존성이 명확한 업무에 맞는다. 흐름을 따라가며 오류 지점을 찾기 쉬운 것도 장점이다.

ADK에서는 SequentialAgent가 이 구조를 구현한다. 각 단계는 output_key를 이용해 결과를 공유 세션 상태에 기록하고, 다음 에이전트가 그 값을 이어받는다.

라우터와 디스패처

라우터는 사용자 요청의 의도를 읽고 어떤 전문 에이전트가 처리할지 결정한다. 요청 내용이나 중간 결과에 따라 실행 경로가 달라져야 할 때 유용하다.

LLM 기반 라우터를 두면 중앙 인텔리전트 에이전트가 입력을 분류한 뒤 가장 적합한 에이전트로 요청을 넘긴다. 라우터의 책임은 태스크 전체를 직접 수행하는 것이 아니라 처리 주체를 선택하는 데 있다.

오케스트레이터와 서브에이전트

오케스트레이터는 요청을 받아 태스크를 분해하고, 서브에이전트에 일을 위임한 뒤 결과를 모아 최종 응답을 만든다. 여러 단계와 역할이 얽힌 작업에서 전체 진행을 통제해야 할 때 선택하는 구조다.

ADK에서는 LlmAgent가 서브에이전트를 AgentTool로 등록하고 필요에 따라 동적으로 호출한다. 라우터가 적절한 경로를 고르는 데 초점을 둔다면, 오케스트레이터는 분해부터 위임과 집계까지 워크플로우 전체를 관리한다.

병렬 팬아웃

서로 독립적인 태스크를 여러 에이전트에 동시에 배정한 뒤 결과를 취합한다. 관리자가 여러 직원에게 업무를 동시에 나눠주는 방식과 같다. 실행 순서에 의존성이 없는 일을 함께 처리해 전체 처리 시간을 줄여야 할 때 적합하다.

ADK의 ParallelAgent가 이 패턴을 구현하며, 개별 실행 결과는 후속 취합 단계에서 병합된다.

반복 개선 루프

평가 결과가 종료 조건을 만족할 때까지 작업을 반복한다. 평가와 수정이 번갈아 일어나는 흐름, 자기 수정(self-correction), 품질 임계치 달성이 필요한 작업에 사용할 수 있다.

ADK의 LoopAgent가 담당하는 구조로, 프로그래밍의 while 루프에 대응한다. 반복 횟수 자체보다 평가 기준과 종료 조건을 어떻게 정의하는지가 설계의 중심이다.

계층형 멀티에이전트

최상위 오케스트레이터가 중간 오케스트레이터를 관리하고, 중간 오케스트레이터가 다시 리프(leaf) 에이전트를 관리하는 트리 구조다. 대규모 엔터프라이즈 워크플로우를 한 계층에서 모두 제어하기 어려울 때 복잡도를 단계별로 나눌 수 있다.

기본 통신 방식은 부모에서 자식으로 이어지는 위임(parent-to-child delegation)이다. 각 계층은 자신이 맡은 범위 안에서 하위 작업을 조정한다.

피어 간 직접 협업

동일한 계층의 에이전트들이 중앙 조정자를 거치지 않고 서로 통신한다. 분산 시스템의 수평 확장과 잘 맞으며, A2A 프로토콜은 에이전트 카드(Agent Card)를 이용한 디스커버리로 이 구조를 지원한다.

중앙 오케스트레이터에 모든 연결을 집중시키지 않으므로 각 에이전트가 상대의 능력과 접속 정보를 발견할 수 있는 체계가 필요하다.

인간 검토를 포함한 흐름

휴먼-인-더-루프(Human-in-the-Loop)는 워크플로우의 특정 체크포인트에 사람의 검토, 승인, 개입을 넣는 패턴이다. 고위험 의사결정이나 규정 준수(compliance), 윤리적 판단이 필요한 지점에서 자동 실행을 멈추고 인간 감독을 연결한다.

완전 자동화 여부를 시스템 전체에 일괄 적용하는 대신, 판단 위험이 높은 단계에만 승인 경계를 배치할 수 있다.

A2A가 연결하는 에이전트 경계

A2A(Agent-to-Agent) 프로토콜은 2026년 멀티에이전트 표준 스택의 핵심 구성 요소다. 이 구조에서 MCP(Model Context Protocol)는 툴 호출과 데이터 검색을 담당하고, A2A는 에이전트 간 통신과 위임을 맡는다. ADK는 로컬 및 클라우드 오케스트레이션을 담당한다. MCP-A2A-ADK로 이어지는 3-레이어 구조가 업계 표준으로 자리 잡고 있다.

A2A에서 상대 에이전트를 찾는 기준은 에이전트 카드다. 이 카드는 에이전트의 능력을 표현하며 이름, 설명, 지원 태스크 유형, 입출력 스키마, 엔드포인트 URL을 담는다. 피어 에이전트는 내부 구현이 아니라 카드에 공개된 능력과 인터페이스를 기준으로 상호작용한다.

태스크 위임은 HTTP와 서버-전송 이벤트(SSE)를 이용한 비동기 이벤트 드리븐 통신으로 이뤄진다. ADK 에이전트는 A2A의 표준화된 태스크 인터페이스를 통해 LangGraph나 CrewAI로 만든 에이전트를 발견하고 호출할 수 있다.

상호운용의 전제는 내부 코드를 공유하지 않는 것이다. 사용하는 프레임워크와 언어, 배포 위치가 달라도 동일한 통신 규약을 따르면 연결할 수 있다. Google ADK, LangGraph, CrewAI, LlamaIndex Agents, Semantic Kernel, AutoGen에는 A2A 네이티브 지원이 통합되어 있다.

분산 실행 중 생기는 실패도 공통 형식으로 다룬다. A2A는 표준화된 오류 코드와 재시도 메커니즘을 제공하고, 에이전트 사이에 상태 컨텍스트를 전달할 수 있도록 세션 기반 메시지 포맷을 정의한다.

오케스트레이터와 A2A를 함께 배치하는 구조

오케스트레이터는 요청을 분석하고 라우터의 판단에 따라 서로 다른 프레임워크의 서브에이전트로 태스크를 보낸다. 에이전트 카드는 연결 가능한 능력을 찾는 데 쓰이고, 반환된 결과는 집계기를 거친다. 인간 검토가 필요한지 판단하는 체크포인트는 최종 응답 직전에 놓인다.

⤢✕

프레임워크마다 같은 패턴을 표현하는 법

ADK, LangGraph, CrewAI는 같은 협업 구조를 서로 다른 추상화로 구현한다. 프레임워크를 비교할 때는 기능 이름보다 실행 흐름과 상태 전달 방식이 어떤 패턴에 대응하는지 보는 편이 정확하다.

패턴	ADK	LangGraph	CrewAI
순차 파이프라인	`SequentialAgent`	`StateGraph` 노드 체인	`Process.sequential`
병렬 처리	`ParallelAgent`	조건부 분기 + 병렬 노드	`Process.parallel`
루프-제어	`LoopAgent`	사이클 그래프	반복 태스크 설정
오케스트레이터	`LlmAgent` + `AgentTool`	슈퍼바이저 노드	매니저 에이전트
라우터	LLM 기반 동적 라우팅	조건부 엣지 함수	태스크 위임 체인
P2P 협업	A2A 프로토콜	멀티-노드 메시지 패싱	에이전트 간 협업
계층형	중첩 `LlmAgent`	계층적 서브그래프	계층적 크루 설정
휴먼-인-더-루프	인터럽트 핸들러	`interrupt()` 노드	휴먼 입력 태스크

ADK 1.0의 핵심 설계 목표 중 하나는 시맨틱 드리프트(semantic drift)를 없애는 것이다. 파이썬으로 프로토타이핑한 에이전트를 Java 기반 엔터프라이즈 백엔드로 옮길 때 로직을 바꾸지 않고 이식할 수 있도록 네 가지 런타임을 정렬한다.

전통적인 소프트웨어 아키텍처와 겹쳐 읽기

멀티에이전트 패턴은 완전히 새로운 설계 언어라기보다 기존 소프트웨어 아키텍처 원리가 에이전트의 역할과 통신 방식으로 옮겨온 형태다.

파이프-필터 아키텍처에서는 각 필터 컴포넌트가 입력을 처리한 뒤 다음 단계로 넘긴다. 에이전트가 필터 역할을 맡으면 순차 파이프라인 패턴과 직접 대응한다.

브로커 아키텍처의 중앙 브로커는 서비스 요청을 적절한 서버로 보낸다. 이는 입력을 분류해 전문 에이전트로 전달하는 라우터 패턴과 같은 책임 구조다.

레이어드 아키텍처의 상위 계층이 하위 계층을 호출하는 단방향 의존성은 계층형 멀티에이전트와 오케스트레이터-서브에이전트 구조에서 나타난다.

마이크로서비스 아키텍처의 서비스 디스커버리와 API 게이트웨이는 A2A의 에이전트 카드 레지스트리와 A2A 엔드포인트에 대응한다. 이 관점에서는 P2P 협업이 독립적으로 배포된 서비스 사이의 연결 문제를 에이전트 수준에서 다루는 방식으로 읽힌다.

표준화 이후에는 운영 기준이 패턴을 가른다

Google Cloud Next 2026을 기점으로 AI 에이전트 아키텍처의 표준화가 빨라지고 있다. MCP-A2A-ADK 3-레이어 스택은 사실상의 표준(de facto standard)으로 자리 잡고 있으며, 엔터프라이즈에서는 거버넌스와 감사 추적(audit trail), 보안 격리가 패턴 선택의 주요 기준이 된다.

Databricks on Google Cloud 문서도 에이전트 시스템 설계 패턴을 공식 아키텍처 가이드로 채택하고 금융·의료·제조 등 규제 산업의 적용 기준을 제시한다. 멀티에이전트 구조가 기술 실험을 넘어 엔터프라이즈 아키텍처의 설계 대상으로 이동하고 있음을 보여주는 사례다.

코드랩으로 구현 경계를 확인하기

Google은 패턴과 프로토콜을 실제 구성으로 연결하는 코드랩을 제공한다.

CrewAI, LangGraph, A2A, ADK 활용 에이전트 확장은 Google Cloud Next 26에서 공개된 실습이다. 네 프레임워크를 조합해 프로덕션 수준의 에이전트 팀을 구축하는 과정을 다룬다.
A2A 구매 컨시어지는 Cloud Run과 Agent Engine 위에서 구매 에이전트와 판매 에이전트가 A2A로 통신하는 엔드-투-엔드 실습이다.
ADK + A2A + MCP on Google Cloud는 InstaVibe 예제로 세 레이어의 통합 방식을 보여준다.

패턴을 선택할 때는 에이전트 수보다 의존성과 제어권을 먼저 봐야 한다. 선형 의존성이 강하면 순차 파이프라인, 독립 작업이 많으면 병렬 처리, 요청별 경로가 달라지면 라우터가 맞는다. 복잡한 태스크 분해와 결과 집계에는 오케스트레이터가 필요하고, 조직 규모의 책임 분리는 계층형 구조로 이어진다. 프레임워크와 배포 경계를 넘는 협업이 필요하다면 A2A가 그 사이의 통신 계약을 맡는다.