AI 아키텍트가 반드시 알아야할 멀티 에이전트 아키텍처 TOP5

2026.03.27 / 동준상.넥스트플랫폼
(AWS SAA, AWS AIF, GCP GenAI Leader)

핵심 정리: AI 시대 속, 아키텍트의 의미 변화

Multi-agent Architecture Pattern Top Five -infographic by NextPlatform

하나의 거대한 모델이 모든 문제를 해결할 수 있다는 믿음은 위험한 환상입니다. 단일 에이전트에게 모든 기능을 몰아넣는 방식은 유지보수를 불가능하게 만들고, 환각 현상(Hallucination)을 부추기며, 결정적으로 확장이 불가능합니다. 현대 기업에 필요한 것은 고독한 ‘솔로 아티스트’가 아니라, 유기적으로 협업하는 ‘생태계’입니다.

오늘날의 아키텍트는 단순히 코드를 짜는 개발자를 넘어, 특정 분야에 특화된 여러 ‘기능 요소(Familiars)’를 소환하고 지휘하는 **’소환사(Summoner)’**가 되어야 합니다.

이번 포스트에서는 구글의 최신 AI 시스템에 적용 중인 ADK(Agent Development Kit), MCP(Model Context Protocol), 그리고 Gemini를 활용하여 어떻게 회복탄력성 있는 멀티 에이전트 시스템의 설계 방법에 대해 알아봅니다.

Multi-agent Architecture Pattern Top Five -slide1 by NextPlatform

멀티 에이전트 아키텍처 패턴 및 주요 기능

구성 요소 이름	아키텍처 패턴/유형	주요 기능 및 역할
Summoner Agent (Orchestrator)	계층적 라우팅(Hierarchical Routing) / 마이크로서비스	요청에 따라 적절한 에이전트로 작업을 라우팅하는 전략가 역할 수행
Imperative MCP Server (Arcane Forge 포함)	명령형(Imperative) 패턴 / 유틸리티 도구	외부 API 서비스 연결, 복잡한 수학적 계산 및 커스텀 로직 수행
Librarium (Database MCP Toolbox)	선언적(Declarative) 패턴	외부 데이터베이스 연결 및 데이터 조회 수행
fire_familiar	순차적(Sequential) 워크플로우	DB 조회 후 계산과 같이 선형적 의존성을 가진 작업 수행
water_familiar	병렬(Parallel) 워크플로우 (Fan-out/Fan-in)	여러 API 또는 도구를 동시에 호출하고 결과를 하나로 합성
earth_familiar	루프(Loop) 워크플로우	특정 조건이 충족될 때까지 작업을 반복적으로 수행
Cooldown Callback/Plugin	인터셉터(Interceptor) 패턴	거버넌스 준수 및 속도 제한 등 비즈니스 규칙 강제
Session Memory (State Management)	단기 상태(Short-term State) 관리	이전 실행 상태를 기억하여 중복 작업을 방지하고 지능적 대화 지원

Multi-agent Architecture Pattern Top Five -mindmap1 by NextPlatform

멀티 에이전트 아키텍처 패턴 TOP5

[Takeaway 1] 도구와 에이전트의 ‘결합’을 끊어라: MCP의 마법

에이전트의 내부 스크립트에 도구(Tool)를 직접 빌드하는 방식은 이른바 “No bueno(좋지 않은)” 방식입니다. 도구와 에이전트가 강력하게 결합되어 있으면, 데이터베이스 스키마나 API가 변경될 때마다 모든 에이전트의 코드를 수정해야 하는 재앙이 발생합니다.

이를 해결하는 비결이 바로 **MCP(Model Context Protocol)**입니다. MCP는 에이전트가 외부 도구를 발견하고 사용할 수 있게 해주는 표준 규격입니다. 도구를 독립적인 서버로 분리(Decoupling)하면 다음과 같은 이점을 얻습니다.

유지보수 용이성: 외부 API가 변경되어도 해당 MCP 서버만 업데이트하면 됩니다.
병렬 개발: 여러 팀이 에이전트와 도구를 동시에 독립적으로 개발할 수 있습니다.
재사용성: 한 번 구축된 도구 서버는 생태계 내 모든 에이전트가 공유할 수 있습니다.

특히, 복잡한 계산을 수행하는 **’아케인 포지(Arcane Forge)’**와 같은 유틸리티 서버는 명령형(Imperative) 패턴으로, Cloud SQL 데이터베이스인 **’리브라리움(Librarium)’**은 선언형(Declarative) 패턴으로 구축하십시오. 특히 선언형 패턴을 사용하면 YAML 설정만으로 데이터베이스를 연결할 수 있어, 아키텍트는 단 한 줄의 연결 코드 없이도 강력한 지식의 도서관을 구축할 수 있습니다.

“도구 서버가 운영되면 여러 에이전트가 연결해 사용할 수 있습니다. 에이전트 간에 코드를 복사해서 붙여넣는 지저분한 작업(copy/paste slop)은 더 이상 필요 없습니다.”

Multi-agent Architecture Pattern Top Five -slide2 by NextPlatform

[Takeaway 2] 목적에 맞는 ‘전투 대형’을 갖춰라: ADK 워크플로우

모든 에이전트를 동일하게 만드는 대신, 문제의 성격에 맞는 아키텍처 패턴을 주입해야 합니다. ADK를 통해 구현 가능한 네 가지 핵심 대형은 다음과 같습니다.

Sequential(순차적): 정밀한 선형 의존성 처리에 적합합니다. ‘리브라리움’에서 스펠(데이터)을 찾은 뒤, 그 결과를 받아 위력을 강화하는 선행 단계의 출력이 다음의 입력이 되는 구조입니다.
Parallel(병렬): 속도와 효율성을 위한 팬아웃/팬인(Fan-out/Fan-in) 패턴입니다. 여러 API를 동시에 조회하거나 다양한 문서를 동시 검토하여 결과를 합성할 때 최적입니다.
Loop(루프): 조건이 충족될 때까지 반복하는 끈기 있는 작업에 적합합니다. 에너지가 충분히 모일 때까지 반복해서 충전하는 작업이 그 예입니다.
Hierarchical Routing(계층적 라우팅): 이는 소환사의 전람회장(Locus) 입구에서 안내 데스크 역할을 하는 확률적 워크플로우입니다. 요청의 의도를 분석하여 최적의 에이전트에게 경로를 배정하는 지능형 지휘 체계입니다.

[Takeaway 3] 에이전트를 ‘마이크로서비스’로 승격시켜라: A2A 프로토콜

Multi-agent Architecture Pattern Top Five -slide3 by NextPlatform

로컬 스크립트에 머물러 있는 에이전트는 진정한 생태계의 일원이 될 수 없습니다. A2A(Agent-to-Agent) 프로토콜은 에이전트를 네트워크에서 검색 가능한 마이크로서비스로 변환합니다.

여기서 마법의 핵심은 **’에이전트 카드(Agent Card)’**입니다. 이는 에이전트의 이름, 능력, 엔드포인트가 적힌 명함과 같습니다. 지휘자 역할을 하는 오케스트레이터(Orchestrator)는 서비스 발견(Service Discovery) 메커니즘을 통해 이 카드의 메타데이터를 읽고, 해당 에이전트를 사용 가능한 도구로 동적으로 등록합니다.

이 구조 덕분에 오케스트레이터는 개별 에이전트의 내부 코드나 프롬프트를 몰라도 협업할 수 있습니다. 특정 에이전트의 로직을 수정하고 재배포하더라도, 오케스트레이터는 업데이트된 에이전트 카드를 통해 즉시 새로운 능력을 파악하고 명령을 내립니다.

[Takeaway 4] 마법에도 법도가 필요하다: 거버넌스 코드(Governance as Code)

자유롭게 사고하는 에이전트라도 비즈니스 규칙이라는 ‘법도’를 따라야 합니다. 에이전트의 사고 과정을 가로채 규칙을 강제하는 **’가로채기 패턴(Interceptor pattern)’**은 비용 관리와 시스템 보호의 핵심입니다.

콜백(Callback): 특정 에이전트에게 귀속되는 규칙으로, 빠른 수정과 디버깅에 유리합니다.
플러그인(Plugin): 시스템 전체에 글로벌하게 적용되는 재사용 가능한 거버넌스 클래스입니다.

예를 들어 **”CoolDownPlugin”**을 적용하면, 에이전트가 실행되기 전(before_agent_callback)에 마지막 호출 시간을 확인합니다. 쿨다운 시간이 지나지 않았다면 플러그인이 즉시 실행을 차단합니다. LLM이 ‘깨어나기’ 전에 차단하므로, 불필요한 토큰 낭비와 API 비용을 원천 봉쇄할 수 있습니다. 이것이 바로 아키텍트가 설계해야 할 ‘거버넌스 코드’의 위력입니다.

[Takeaway 5] 똑똑한 소환사는 ‘중복’을 허용하지 않는다: 에이전트의 기억력

지능적인 오케스트레이터는 과거의 행동, 즉 ‘전투의 메아리(Echoes of Battle)’를 기억해야 합니다. 에이전트에게 세션 상태(Short-term state)를 부여하면 단순한 도구 호출기에서 지능적인 대화 파트너로 진화합니다.

아키텍트는 **after_tool_callback**을 사용하여 마지막으로 소환된 패밀리어가 누구인지 세션 상태에 기록합니다. 이는 마치 오케스트레이터의 책상 위에 **’포스트잇’**을 붙여두는 것과 같습니다. 다음 호출 시, 오케스트레이터는 이 메모를 확인하고 시스템 프롬프트의 지시문(Directive)을 동적으로 업데이트합니다. “방금 화염 에이전트를 소환했으니, 이번에는 중복되지 않게 수해나 대지 에이전트를 선택하라”고 스스로 판단하게 만드는 것입니다.

결론: AI 시대의 아키텍트 역량 – 멀티 에이전트 설계 및 구성 능력

Multi-agent Architecture Pattern Top Five -slide4 by NextPlatform

우리는 단순히 기능을 구현하는 ‘개발자’를 넘어, MCP로 도구를 분리하고, ADK로 전투 대형을 설계하며, A2A로 에이전트 사회를 구축하는 법을 살펴보았습니다. 또한 콜백과 기억력을 통해 이 마법 같은 시스템에 질서와 지능을 부여했습니다.

이제 개별 스크립트를 짜는 단계에서 벗어나, 전체 시스템의 명령 중심지(Locus of Command)를 설계하는 아키텍트로서 거듭나십시오. 스스로에게 질문해 보십시오. “당신이 구축하고 있는 시스템은 단순한 챗봇입니까, 아니면 스스로 협업하고 성장하는 회복탄력성 있는 에이전트 사회입니까?”

모범적인 멀티 에이전트 시스템 설계를 위한 FAQ

Q1: 단일 에이전트 대신 멀티 에이전트 시스템을 구축해야 하는 이유는 무엇인가요?

A1: 모든 것을 단일 에이전트가 처리하도록 만드는 것은 유지보수가 불가능하고, 환각(hallucination)을 유발하며, 시스템 확장이 어렵기 때문입니다. 단일 모델이 감당할 수 없는 복잡한 문제를 해결하려면, 여러 전문화된 에이전트들이 서로 협업하는 분산형 생태계를 설계해야 합니다. 단일 LLM에게 복잡한 다단계 프로세스를 모두 알아내라고 요구하는 것은 흔한 실수입니다.

Q2: 에이전트와 외부 도구를 어떻게 분리(Decoupling)하며, 그 이점은 무엇인가요?

A2: 모델 컨텍스트 프로토콜(MCP, Model Context Protocol) 서버를 사용하여 도구와 에이전트를 분리할 수 있습니다. 이렇게 하면 외부 API나 데이터베이스 스키마가 변경되더라도 에이전트의 코드를 수정할 필요 없이 MCP 서버만 업데이트하면 됩니다. 또한 여러 팀이 병렬로 개발할 수 있어 에이전트 개발 속도가 향상되며, 한 번 구축된 MCP 서버는 여러 다른 에이전트가 쉽게 재사용할 수 있습니다.

Q3: 복잡한 작업을 처리하기 위해 에이전트 워크플로우는 어떤 패턴으로 설계해야 하나요?

A3: ADK(Agent Development Kit)를 사용하여 아키텍처 패턴을 에이전트의 워크플로우에 직접 통합할 수 있으며, 목적에 따라 세 가지 주요 에이전트를 구축할 수 있습니다.

순차적(Sequential) 에이전트: 선형적인 종속성이 있는 작업에서 이전 단계의 출력을 다음 단계의 입력으로 사용하여 정확성을 높일 때 사용합니다.
병렬(Parallel) 에이전트: 여러 API를 쿼리하는 등 독립적인 작업을 동시에 실행하고 결과를 병합(팬아웃/팬인)하여 작업 속도를 높일 때 사용합니다.
루프(Loop) 에이전트: 특정 조건이 충족되거나 최대 반복 횟수에 도달할 때까지 반복 작업을 수행하여 지속성을 확보할 때 사용합니다.

Q4: 분산된 여러 에이전트를 효과적으로 지휘(Orchestrate)하려면 어떻게 해야 하나요?

A4: 비즈니스 로직을 직접 수행하지 않고 전략가 역할을 하는 **지능형 오케스트레이터(소환사 에이전트)**를 구축해야 합니다. A2A(Agent-to-Agent) 프로토콜을 사용하여 개별 로컬 에이전트들을 네트워크상에서 검색 가능한 마이크로서비스로 변환합니다. 오케스트레이터는 하위 에이전트들의 코드나 프롬프트를 몰라도, 에이전트의 이름과 기술, URL이 적힌 ‘에이전트 카드(Agent Card)’를 읽고 서비스 검색(Service discovery)을 수행하여 들어오는 요청을 동적으로 라우팅할 수 있습니다.

Q5: 시스템 자원을 보호하고 속도 제한이나 재사용 대기 시간(Cooldowns) 등의 비즈니스 규칙을 어떻게 강제할 수 있나요?

A5: 에이전트의 핵심 코드를 변경하지 않고도 실행 흐름을 가로채어 사용자 정의 로직을 실행하는 인터셉터(Interceptor) 패턴을 코드로 구현하여 거버넌스를 강제할 수 있습니다.

콜백(Callbacks): 단일 에이전트에 부착되는 함수로, 특정 에이전트를 수정하거나 프로토타이핑할 때 유용합니다.
플러그인(Plugins): ADK 런타임에 부착되는 강력하고 재사용 가능한 클래스로, 오케스트레이터가 하위 에이전트를 호출하려 할 때 요청을 가로채어 확인하는 등 시스템에서 실행되는 모든 에이전트에 전역적으로 비즈니스 규칙을 적용할 수 있습니다. 이를 통해 API의 속도 제한을 보호하고 불필요한 비용 발생을 방지합니다.