멀티 에이전트 AI 시스템이 부상함에 따라, MCP (Model Context Protocol), Fast-Agent, Agent2Agent (A2A) 세 가지 툴/프로토콜이 주목받고 있습니다. 각 툴은 서로 다른 측면에서 에이전트 간 협업과 통합을 돕는데, 모두 개방형 표준을 지향한다는 공통점이 있습니다. Anthropic이 개발한 MCP는 LLM과 외부 도구·데이터를 연결하는 표준 프로토콜로, 모델과 외부 시스템 간의 안전한 양방향 연결을 가능케 합니다 . Fast-Agent는 MCP 생태계를 기반으로 한 파이썬 에이전트 프레임워크로, 간결한 선언형 문법으로 에이전트와 워크플로를 구축할 수 있고 Anthropic 및 OpenAI 등 다양한 모델의 멀티모달 입력을 지원합니다 . 한편 Google이 2025년 4월 발표한 A2A(Agent2Agent)는 50여 개 기술 파트너 (Atlassian, Box, LangChain 등)의 지지와 함께 출범한 에이전트 간 통신 프로토콜로, 서로 다른 프레임워크로 구축된 에이전트들이 공통 언어로 소통하고 안전하게 정보 교환 및 작업 조율을 할 수 있도록 하는 것을 목표로 합니다 . 이번 포스트에서는 이 세 가지를 다음 기준으로 비교합니다: 아키텍처 상 포지셔닝, 겹치는 영역과 철학, 기능 및 사용성, 통합 활용 방안, 그리고 활용 시나리오 예시를 살펴보겠습니다.
아키텍처에서의 역할 및 포지셔닝
AI 에이전트 생태계에서는 크게 두 가지 표준화 계층이 필요합니다 . 첫째는 도구 및 데이터 통합 층으로, 에이전트(또는 LLM)가 외부 데이터 소스나 툴에 접근하는 표준 방법입니다. 둘째는 에이전트 간 통신 층으로, 서로 독립적으로 동작하는 여러 에이전트들이 상호작용하는 표준 방식입니다 . 이 중 MCP는 전자(도구·데이터 통합)에 집중한 프로토콜이고, A2A는 후자(에이전트 상호작용)에 초점을 맞춘 프로토콜입니다. 두 프로토콜은 각각 상호보완적 역할을 하며, 경쟁이라기보다 에이전트 생태계의 서로 다른 문제를 해결하는 것으로 자리매김하고 있습니다 . 한편 Fast-Agent는 이러한 프로토콜 위에서 동작하는 에이전트 개발 프레임워크로, MCP를 활용해 에이전트의 도구 사용을 간소화하고 여러 에이전트의 워크플로를 한 곳에서 구성하는 역할을 합니다. 요컨대, MCP가 도구 연결을 표준화하고 A2A가 에이전트 간 대화를 표준화한다면, Fast-Agent는 그 환경에서 실제 에이전트를 구현하고 운영하는 데 초점을 맞추고 있습니다.
Figure: MCP 아키텍처 개념도 – LLM 호스트(클라이언트)가 여러 MCP 서버에 연결하여 로컬/원격 데이터 소스를 활용한다. MCP에서는 LLM이나 챗봇 애플리케이션이 클라이언트(호스트) 역할을 하며, 필요한 기능별로 여러 MCP 서버에 1:1 연결을 맺어 도구와 컨텍스트를 제공합니다 . 각 MCP 서버는 파일시스템, 데이터베이스, API 등 특정 외부 자원에 대한 인터페이스를 노출하고, 클라이언트는 JSON-RPC 기반 프로토콜을 통해 해당 서버와 요청/응답을 주고받습니다 . 이러한 구조를 통해 하나의 AI 에이전트가 표준화된 방식(MCP)으로 다양한 출처의 정보를 안전하게 가져와 활용할 수 있습니다. 실제로 Anthropic은 MCP를 “AI 분야의 USB-C”에 비유하는데, 각기 다른 도구와 데이터를 AI 모델이 손쉽게 연결할 수 있는 범용 인터페이스를 제공한다는 의미입니다 .
Figure: A2A 프로토콜 개념도 – 두 에이전트(A와 B)가 표준화된 A2A 인터페이스로 상호 통신하는 모습. A2A에서는 각 에이전트가 Agent Card라는 공개 메타데이터(JSON)를 통하여 자신의 기능과 주소를 광고하고, HTTP 기반의 표준 API(A2A 프로토콜 스펙 준수)를 구현하여 외부 요청을 처리합니다 . 이를 통해 클라이언트 에이전트(A)가 원격 에이전트(B)의 엔드포인트로 작업 요청(tasks/send)을 보내면, B는 해당 작업을 수행하면서 메시지 스트림이나 폴링 방식으로 진행 상황 및 결과를 전달합니다 . A2A의 통신 단위는 Task(작업)이며, 각 Task 내에서 주고받는 Message들은 사용자 역할(user)과 에이전트 역할(agent)의 대화 턴으로 표현됩니다 . 메시지에는 텍스트, 파일, 구조화 데이터(JSON) 등 다양한 파트(Parts) 형태의 콘텐츠를 담을 수 있어 복잡한 상호작용도 표현 가능합니다 . 요약하면, A2A는 분산된 에이전트들이 HTTP/JSON을 매개로 서로 요청을 주고받는 상위 통신 레이어라고 볼 수 있습니다.
한편, Fast-Agent는 MCP 클라이언트로 기능하면서 필요 시 MCP 서버로도 동작할 수 있는 독특한 위치에 있습니다 . 개발자는 Fast-Agent를 이용해 하나의 프로세스 안에서 여러 에이전트 인스턴스와 툴 사용 단계를 정의하고 실행할 수 있습니다. 예를 들어 Fast-Agent를 통해 두 개 이상의 에이전트를 체이닝(chaining)하거나 병렬로 배치해, 특정 순서로 협업하게 만들 수 있습니다 . 이때 Fast-Agent 내부에서는 MCP 프로토콜을 활용해 필요한 외부 도구에 접근하고 각 에이전트의 프롬프트와 행동을 제어합니다. Fast-Agent로 구현된 에이전트 시스템은 하나의 응용 프로그램 안에서 멀티 에이전트 워크플로를 구성하는 것이며, A2A처럼 완전히 독립 프로세스 간의 네트워크 통신은 아니지만, 필요하면 Fast-Agent로 만든 에이전트를 MCP 서버로 외부에 공개해 다른 호스트(또는 A2A 네트워크)에서 활용하도록 할 수도 있습니다 . 이런 점에서 Fast-Agent는 멀티 에이전트 아키텍처의 중간 계층으로서, 개발 편의성과 MCP 표준 준수를 동시에 충족시키는 포지셔닝을 갖습니다.
겹치는 부분과 철학 비교
세 툴 모두 AI 에이전트 생태계의 개방성과 표준화를 지향한다는 철학을 공유합니다. MCP와 A2A는 각자 다루는 영역은 다르지만 호환성과 상호운용성(interoperability)을 최우선 가치로 삼고 있습니다. Anthropic의 MCP 철학은 “모든 LLM 어시스턴트가 각기 다른 도구나 데이터 소스마다 별도 구현을 하지 않도록, 단일 표준으로 연결하자”는 것입니다 . 이를 통해 AI 개발자들은 USB-C 케이블 꽂듯이 간편하게 모델을 여러 서비스에 연결하고, 컨텍스트(맥락) 정보를 주입할 수 있게 됩니다. Google의 A2A 철학 역시 유사하게, 기업들이 여러 벤더의 에이전트를 함께 활용할 수 있도록 에이전트 간의 공통 언어를 만들겠다는 것입니다 . A2A 발표 시에도 “기반이나 벤더에 상관없이 모든 에이전트가 소통할 수 있는 보편적 프로토콜이 중요하다”고 강조했는데 , 이는 AI 에이전트의 사일로(Silo) 현상을 타파하고자 하는 방향성입니다. 두 프로토콜 모두 개방형 표준으로 커뮤니티 및 기업 파트너들의 참여를 장려하며, 특정 플랫폼에 종속되지 않는 중립적인 생태계를 지향합니다.
그러나 MCP와 A2A의 지향점에는 차이도 존재합니다. MCP는 LLM 중심의 철학을 갖고 있습니다. 즉, LLM에게 필요한 맥락(Context)을 공급하고 행동 범위를 확장시키는 도구 모듈화에 집중합니다 . Anthropic은 특히 AI 모델의 안전한 도구 사용을 중요시하여, MCP를 통해 권한이 통제된 환경에서 모델이 외부 작업을 수행하게 하는 철학을 담았습니다. 반면 A2A는 에이전트 시스템 전체의 협업에 초점을 둡니다. Google은 대규모 기업 환경에서 수많은 에이전트가 생겨날 것을 예상하고, 이들이 동적으로 협상하고 계획을 분담할 수 있는 커뮤니케이션 레이어를 만든 것입니다 . 예를 들어 A2A는 에이전트들이 상호 간에 인터페이스 방식(텍스트 채팅, 폼 입력, 음성 대화 등)까지도 조율할 수 있게 설계되었는데, 이는 인간 팀원들끼리 일하는 방식에 가깝게 에이전트 협업을 높이려는 철학입니다 . 요약하면 MCP는 도구와 AI의 접점을 표준화해서 AI가 더 똑똑해지도록 하는 철학이고, A2A는 에이전트 간 소통을 표준화해서 여러 AI가 함께 일을 잘하게 하려는 철학이라 볼 수 있습니다.
Fast-Agent의 철학은 앞선 두 프로토콜을 실용적으로 접목하는 데 있습니다. Fast-Agent는 Anthropic의 MCP 비전에 동참하여, 개발자가 복잡한 멀티 에이전트 워크플로를 손쉽게 구현하도록 돕습니다. “Building Effective Agents”라는 Anthropic의 에이전트 설계 원칙을 그대로 내장해 제공하는 점 에서도, Fast-Agent가 모범 사례(best practice)를 빠르게 실현하려는 철학을 읽을 수 있습니다. 또한 Fast-Agent는 개발자 경험(DX)을 중시하여, 대화형 UI와 시뮬레이터를 제공함으로써 에이전트 개발을 실험하고 반복 개선하기 쉽게 합니다. 이는 프로토콜 그 자체보다는 프로토콜의 활용을 극대화하는 철학으로, MCP/A2A와 동일선상에서 생태계 확장에 기여하는 방향입니다. 결국 세 툴 모두 표준화된 멀티 에이전트 미래를 지향하지만, MCP는 도구 접근 표준, A2A는 에이전트 대화 표준, Fast-Agent는 표준의 실천적 구현이라는 각자의 역할에 맞는 철학과 방향성을 갖추고 있습니다.
기능 및 사용성 비교
이제 각각의 구체적인 기능(feature)과 사용성(usability)을 살펴보겠습니다. 설정 방법의 난이도, 성능 및 통신 방식, API 구조, 유연성 측면에서 세 가지를 비교하면 다음과 같습니다.
- MCP – 통합 도구 인터페이스: MCP를 도입하면, 개발자는 다양한 외부 기능을 플러그인처럼 연결할 수 있습니다. Anthropic과 커뮤니티에서 이미 Slack, GitHub, 구글 드라이브 등 수십 가지 MCP 서버 구현체를 공개하여 누구나 활용할 수 있습니다 . 예를 들어 간단한 설정으로 LLM이 파일 시스템을 읽거나 웹 검색을 수행하게 만들 수 있으며, 추가 개발 없이도 DB 조회, 버전관리 툴 조작 등의 기능을 덧붙일 수 있습니다. MCP 서버/클라이언트 SDK가 Python, TypeScript 등 여러 언어로 제공되므로(자바, C# 등도 지원), 기존 애플리케이션에 MCP를 통합하거나 새로운 MCP 서버를 구축하는 것도 비교적 수월합니다. 설치 및 설정은 통상 ① 원하는 MCP 서버 실행 (예: 터미널에서 mcp-server-slack 가동) ② LLM 호스트 애플리케이션에 해당 서버 연결을 설정 하는 순서로 이루어집니다. 성능 면에서 MCP는 경량 JSON 메시지 기반이라 오버헤드가 작고 실시간성이 높습니다. 로컬 MCP 서버의 경우 Stdio 전송을 통해 통신할 수 있어 IPC 수준의 속도를 낼 수 있고, 원격 서버도 HTTP+SSE(streaming)를 사용해 스트림 응답을 처리하므로 대화형 작업에 적합합니다 . API 구조는 JSON-RPC 2.0 규격을 따르며, 요청(request)과 알림(notification)의 형태로 이루어진다 . 각 MCP 서버가 제공하는 메서드(툴) 목록 및 입력/출력 스키마가 정의되어 있어, 클라이언트(LMM 애플리케이션)는 이를 참조해 필요한 작업을 호출합니다. 유연성 측면에서 MCP만큼 다양한 기능 확장성을 보여주는 프로토콜은 드뭅니다. 필요한 기능이 없다면 직접 MCP 서버를 구현하여 LLM에 연결할 수도 있고, 기존 MCP 서버에 권한 제어나 리소스 제한 같은 정책을 설정해 안전하게 운영할 수도 있습니다. 현재 Claude AI, Cursor IDE, VS Code 확장, Emacs 등 다양한 툴이 MCP 인터페이스를 지원하고 있어 활용 범위가 빠르게 넓어지고 있습니다 . 다만 MCP는 어디까지나 LLM ↔︎ 툴 간 통신 규격이기 때문에, 복잡한 에이전트 간 협업 로직은 애플리케이션 레벨에서 개발자가 직접 구성해야 합니다.
- A2A – 에이전트 간 상호작용 표준: A2A를 활용하면, 이기종 에이전트들을 느슨하게 결합한 시스템을 구축할 수 있습니다. 설정을 위해서는 각 에이전트가 HTTP 서버로 동작하며 A2A 프로토콜에 정의된 엔드포인트(예: tasks/send)들을 구현해야 합니다 . 또한 Agent Card라는 JSON 메타데이터 파일(.well-known/agent.json)을 호스팅해 두어, 다른 에이전트들이 해당 에이전트의 능력(스킬)과 주소를 발견(discover)할 수 있게 합니다 . 현재 A2A 스펙은 JSON 기반 표준으로 GitHub에 공개되어 있으며, Google 및 여러 파트너사가 공개한 레퍼런스 구현이나 가이드가 등장하고 있습니다. 예를 들어 Google Cloud Vertex AI에서는 자사 에이전트 프레임워크(ADK 등)에 A2A를 적용하여 멀티-시스템 에이전트 오케스트레이션을 지원하기 시작했습니다 . A2A 통신의 성능은 일반적인 REST API와 유사하며, 작업 성격에 따라 3가지 모드를 지원합니다: 짧은 작업은 동기식 요청/응답 혹은 SSE 스트리밍으로 처리하고, 장시간 걸리는 작업은 푸시 알림으로 완료 시 결과를 통지하는 방식입니다 . 이는 클라이언트 에이전트가 지속적으로 폴링하거나 긴 연결을 유지하지 않아도 되어 리소스 효율성을 높입니다. API 구조를 보면 A2A는 tasks 자원 아래에 여러 메서드를 정의합니다. 예를 들어 tasks/send로 작업을 보내고, tasks/status로 진행 상태를 조회하며, tasks/cancel로 취소할 수 있습니다 (참고: tasks/sendSubscribe를 통해 SSE로 상태 업데이트를 구독하는 방식도 있음). A2A 메시지 포맷은 각 메시지에 role(user/agent)와 parts 배열이 있어 대화형으로 주고받으며, 파일 업로드나 양식(Form) 데이터도 parts로 주고받는 일관된 형식을 취합니다 . 유연성 측면에서 A2A의 가장 큰 강점은 이종 플랫폼 간 협업입니다. 언어와 프레임워크가 다른 에이전트들도 HTTP 표준만 따르면 되므로, 예컨대 파이썬 에이전트가 자바 기반 에이전트와, 혹은 온프레미스 에이전트가 클라우드 에이전트와 서로 쉽게 통신할 수 있습니다. 또한 A2A는 에이전트 간 보안을 고려하여, Agent Card에 인증 방식(예: API 키, OAuth) 정보를 명시하고 통신 시 표준 auth 헤더를 사용하도록 규정하고 있어 기업 환경에서 안전한 협업을 도모합니다 . 그러나 A2A만으로는 각 에이전트 내부의 구체적 능력을 창출하지는 않습니다. 다시 말해 A2A는 소통 채널일 뿐, 실제 업무(코딩, 문서요약, 데이터분석 등)를 수행하려면 개별 에이전트가 그 능력을 갖추고 있어야 하며, 보통 MCP 같은 도구 통합이나 자체 기능 구현이 병행됩니다. 현재 A2A는 갓 발표된 신생 프로토콜로, MCP에 비해 성숙도는 낮지만 업계의 큰 지지를 받고 있어 빠르게 생태계가 갖춰질 전망입니다.
- Fast-Agent – 멀티에이전트 구현 프레임워크: Fast-Agent는 사용성 측면에서 개발자에게 많은 이점을 제공합니다. 파이썬 패키지로 배포되어 pip install fast-agent 후 간단한 설정으로 시작할 수 있으며, CLI 도구와 웹 UI를 통해 에이전트를 테스트하고 디버깅할 수 있는 인터랙티브 환경을 제공합니다 . 사용자는 YAML이나 파이썬 코드로 에이전트의 프롬프트, 툴 사용, 워크플로 등을 선언적으로 정의할 수 있는데, 예를 들어 하나의 에이전트가 어떤 MCP 툴을 사용할지, 여러 에이전트를 어떤 순서로 체이닝할지를 손쉽게 명시할 수 있습니다 . 성능은 주로 백엔드 LLM API 호출에 좌우되므로 Fast-Agent 자체 오버헤드는 크지 않습니다. 동시에 이름에서 드러나듯 빠른 개발 사이클에 초점을 맞춰 불필요한 지연을 최소화하고자 설계되었습니다. 예를 들어 “패스스루(passthrough)” 모드로 실제 LLM 호출 없이도 프롬프트 흐름을 점검한다든지, 과거 대화 시뮬레이션을 재생(playback)하며 디버깅할 수 있는 기능은 개발 효율을 높여줍니다 . Fast-Agent의 API 구조는 내부적으로 MCP 프로토콜을 구현하고 있어, Fast-Agent로 만든 에이전트는 필요하면 MCP 서버로 바로 배포할 수 있습니다 . 이는 개발한 에이전트를 독립 실행하여 다른 MCP 클라이언트(예: 다른 사용자의 LLM 앱)가 그 에이전트를 하나의 툴처럼 활용할 수 있게 함을 의미합니다. 반대로 Fast-Agent는 자체가 MCP 클라이언트이기도 해서, 여러 MCP 서버에 동시 연결하여 하나의 LLM에게 다수의 툴셋을 제공하거나, 멀티 에이전트 체계를 구성하는 것도 가능합니다 . 유연성 측면에서 Fast-Agent는 멀티모달 입력/출력을 지원하는 점이 돋보입니다. 이미지나 PDF를 MCP의 네이티브 타입으로 처리하여 시각 정보까지 에이전트에게 제공할 수 있고 , 이를 활용한 시나리오(예: 이미지 속 텍스트 읽고 분석 등)도 쉽게 구현합니다. 또한 Anthropic의 제안에 따라 에이전트 설계 시 유용한 몇 가지 워크플로 패턴(예: Reflect, Debate, Chain 등)을 라이브러리에 내장하여, 개발자가 일일이 프롬프트 엔지니어링을 하지 않아도 검증된 에이전트 패턴을 적용할 수 있게 했습니다 . 전반적으로 Fast-Agent는 프로토콜 그 자체보다 그 위에서의 생산성을 극대화하는 도구로서, 코드 한두 줄로도 복잡한 멀티에이전트 흐름을 실험해볼 수 있게 하는 등 사용성 면에서 높은 평가를 받고 있습니다.
통합 활용 방안 제안
앞서 살펴본 것처럼 MCP와 A2A는 각기 다른 층을 담당하므로 동시에 조합하여 활용할 수 있습니다. 실제로 Google은 A2A 문서에서 Anthropc의 MCP와 함께 쓰일 수 있는 예시를 소개하며 두 프로토콜의 보완 관계를 강조했습니다 . 예를 들어 자동차 수리점 시나리오에서, 차량 정비를 담당하는 여러 AI 에이전트들이 있다고 가정해봅시다 . 이때 타이어 교체 로봇, 엔진 진단기 등의 현장 장비 제어에는 MCP를 적용하여 각 장비를 다루는 에이전트를 구현합니다 (예: MCP를 통해 “리프트를 2미터 올리기”나 “렌치 4mm 회전” 같은 구체적 작업 명령을 제어). 한편 고객이나 다른 에이전트와의 전반적인 의사소통과 플랜 협의는 A2A로 처리합니다 . 즉, 정비소의 에이전트 직원들이 A2A 프로토콜로 고객의 설명을 듣고 (“차에서 이상한 소리가 납니다”), 상황에 맞게 작업 계획을 세우며 (“좌측 바퀴 사진을 보내주세요”, “오일 누유가 보입니다. 얼마나 됐나요?”) 대화를 이어가는 식입니다 . 또한 정비소 에이전트가 자체적으로 해결 못 하는 부분은 부품 공급업체 에이전트에게 A2A로 요청을 보내 협력할 수도 있습니다. 이 예시에서 보듯, MCP는 에이전트와 도구(장비) 간의 낮은 수준 작업을 맡고, A2A는 사람과 에이전트 또는 에이전트 상호 간의 높은 수준 교류를 맡아, 전체 시스템이 유기적으로 돌아가게 합니다.
이러한 MCP+A2A 결합 구조는 다양한 분야에 응용될 수 있습니다. 예를 들어 기업 환경에서, 한 에이전트가 MCP를 통해 사내 데이터베이스나 API에 접근해 정보를 수집하고, 그 정보를 바탕으로 다른 전문 에이전트들과 A2A 대화를 하며 해결책을 도출하는 식의 협업이 가능합니다. 개발 실무 관점에서는, Fast-Agent 같은 프레임워크를 활용해 개별 에이전트들을 구현한 뒤, 각 에이전트에 A2A 인터페이스(엔드포인트와 Agent Card)를 부여하여 서비스화할 수 있습니다. Fast-Agent로 구축된 에이전트는 곧바로 MCP 서버로 동작할 수 있으므로, 필요한 MCP 툴 접근을 포함한 로직을 모두 갖춘 후 이를 A2A 네트워크에 참여시키면 됩니다 . 한편 중앙 오케스트레이팅 에이전트를 두어 멀티에이전트 풀(Pool)을 관리하게 하고, 사용자 요청에 따라 적절한 에이전트를 A2A로 호출하거나 결과를 취합해 응답하게 할 수도 있습니다. 이때 중앙 에이전트 자체도 Fast-Agent로 구현하여 MCP 툴(예: 로그 모니터링, 보안 스캔 등)을 활용하며 메타-에이전트 역할을 수행하게 하면 더욱 강력한 구성도 가능할 것입니다. 요컨대, MCP로 각 에이전트의 손과 발을 만들어주고 A2A로 서로 대화시킴으로써, 개별적으로는 단순한 에이전트들이 모여 복잡하고 고차원적인 문제를 협력 해결하는 에이전트 생태계를 설계할 수 있습니다.
활용 시나리오 예시: AI 비서 서비스
마지막으로, 위의 툴들을 조합하여 AI 비서를 구현하는 가상의 시나리오를 살펴보겠습니다. 이 예시는 MCP, Fast-Agent, A2A의 역할이 어떻게 분담되고 협력되는지 단계별로 보여줍니다.
- 사용자 요청: 한 스타트업의 직원이 AI 비서에게 “다음주 팀 회의를 일정 잡고 출장 준비도 해줘”라고 요청합니다. 이 비서는 멀티 에이전트로 구성된 시스템으로, 자연어로 온 사용자 요청을 중앙 오케스트레이터 에이전트가 먼저 받아들입니다.
- 요청 분석 및 에이전트 할당: 중앙 에이전트는 요청 내용을 분석하여 두 가지 작업이 필요함을 파악합니다: (a) 회의 가능 일정 조율, (b) 출장 여행 예약. 중앙 에이전트는 각 작업을 전문으로 하는 별도 에이전트에게 A2A 프로토콜로 작업을 할당합니다. 이를 위해 사전에 구축된 캘린더 에이전트와 여행 에이전트의 Agent Card를 참고하여 각각의 엔드포인트를 확인합니다.
- 캘린더 에이전트(MCP): 중앙 에이전트는 A2A를 통해 캘린더 에이전트에 팀원의 일정 조율을 요청합니다. 캘린더 에이전트는 Fast-Agent로 구현되어 있어 구글 캘린더 MCP 서버와 연동되어 있습니다 (예시로, 팀원들의 캘린더에서 공통 빈 시간을 조회하는 MCP 툴 사용). 캘린더 에이전트는 MCP를 통해 각 팀원의 일정을 조회하고 가장 적합한 회의 시간을 계산한 뒤, 그 결과(예: “수요일 오후 3시 가능”)를 A2A 응답으로 중앙 에이전트에 전달합니다.
- 여행 에이전트(MCP): 동시에 중앙 에이전트는 여행 에이전트에도 출장을 위한 교통편 및 호텔 예약을 요청합니다. 여행 에이전트 역시 Fast-Agent 기반으로 구현되어 항공권/호텔 예약 API에 연결된 MCP 서버들을 활용합니다. 예컨대 항공권 검색 MCP 툴로 사용자 출발지에서 목적지까지 회의 전날 도착하는 최적의 항공편을 찾고, 호텔 예약 MCP 툴로 회의 장소 근처 호텔을 조회합니다. 여러 옵션 중 조건에 맞는 결과를 선별한 후, 여행 에이전트는 중앙 에이전트에게 예약 가능한 항공편/호텔 목록을 A2A 메시지로 보내옵니다.
- 사용자 확인 (옵션): 중앙 에이전트는 사용자에게 회의 일정과 추천된 여행 옵션을 알려주고 확인을 요청할 수 있습니다. 예를 들어 “팀 회의는 수요일 3시에 진행하고, 화요일 오후 5시 비행편과 XX호텔 1박을 예약할까요?“라는 메시지를 생성하여 사용자에게 보여줍니다. 사용자는 확인이나 수정 요청을 할 수 있습니다.
- 조율 및 추가대화: 사용자가 “비행편은 화요일 저녁 7시 이후 것으로 찾아줘”라고 응답하면, 중앙 에이전트는 즉시 여행 에이전트에 A2A로 수정된 조건을 전달합니다. 여행 에이전트는 MCP 항공권 툴로 조건에 맞는 다른 편을 다시 조회하고 업데이트된 결과를 보냅니다. 이런 식으로 중앙 에이전트 ↔︎ 여행 에이전트 간에 몇 차례 A2A 상호작용을 거쳐 최종 일정을 확정합니다.
- 최종 실행: 모든 세부사항이 확정되면, 중앙 에이전트는 캘린더 에이전트에게 확정 일정을 팀원들에게 초대장 형태로 등록하도록 최종 명령을 내리고 (MCP를 통해 구글 캘린더에 이벤트 생성), 여행 에이전트에게는 선택된 항공편과 호텔을 실제로 예약하라고 지시합니다 (MCP를 통해 예약 API 호출). 각 에이전트는 해당 작업을 수행하고 완료 결과를 회신합니다.
- 결과 응답: 중앙 에이전트는 사용자에게 “회의 일정은 수요일 3시로 확정하고, 출장 예약을 완료했습니다. (항공편 정보 및 호텔 예약 정보)“라는 최종 답변을 제공합니다. 필요하다면 이메일이나 메시지로 확인 링크도 전달합니다.
이 시나리오에서 볼 수 있듯이, MCP, A2A, Fast-Agent가 결합되어 실제 사람처럼 일하는 AI 비서를 구현할 수 있습니다. Fast-Agent는 각 전문 에이전트의 내부 로직 구현과 MCP 연동을 쉽게 해주었고, MCP는 외부 서비스 이용을 표준화하여 (캘린더 조회, 항공권 검색 등) 개별 에이전트의 손발 역할을 했습니다. 그리고 A2A는 에이전트들 간의 의사소통과 협업을 책임져, 중앙 에이전트가 여러 전문 에이전트의 능력을 하나로 모아 사용자에게 서비스를 제공할 수 있었습니다. 이러한 아키텍처는 확장성이 뛰어나, 필요에 따라 새로운 전문 에이전트(예: 경비 처리 에이전트, 번역 에이전트 등)를 추가하고 A2A로 연동하기만 하면 AI 비서의 기능을 계속 확장해나갈 수도 있습니다. 멀티 에이전트 시대에 MCP와 A2A를 적절히 활용하면 이처럼 복잡한 업무도 자동화하는 강력한 에이전트 시스템을 구축할 수 있을 것입니다.
