하나는 에이전트를 도구에 연결합니다. 다른 하나는 에이전트들을 서로 연결합니다. 이 둘을 혼동하는 것은 당신을 방해하는 아키텍처를 구축하는 가장 빠른 방법입니다.

MCP (Model Context Protocol)는 단일 AI 에이전트를 도구, 데이터, 그리고 컨텍스트 (Context)에 연결합니다. 이는 다음과 같은 질문에 답합니다: 내 에이전트가 리소스를 어떻게 사용하는가 — 파일을 읽고, 데이터베이스를 쿼리하고, API를 호출하는 방법 말입니다.

A2A (Agent2Agent)는 에이전트를 다른 에이전트와 연결합니다. 이는 다음과 같은 질문에 답합니다: 내 에이전트가 어떻게 다른 에이전트에게 작업을 위임하고 결과를 다시 받아오는가?

MCP는 수직적입니다 — 에이전트가 자신의 기능(Capabilities)을 향해 아래로 뻗어 나가는 것입니다. A2A는 수평적입니다 — 에이전트가 동료(Peers)를 향해 옆으로 뻗어 나가는 것입니다. 이들은 경쟁하는 것이 아니라 상호 보완적입니다. 둘 다 Linux Foundation이 관리하는 개방형 표준이며, 대부분의 프로덕션 (Production) 시스템은 두 가지를 모두 실행합니다.

이 질문이 계속해서 나오는 이유

주변에 물어보면 사람들은 마치 A2A와 MCP가 라이벌인 것처럼, 즉 하나를 선택하는 것이 승자가 정해진 전략적 결정인 것처럼 이야기하는 것을 듣게 될 것입니다. 그렇지 않습니다. 두 프로토콜은 중복되지 않습니다. 사람들이 중복된다고 생각하는 이유는 두 프로토콜이 비슷한 시기에 등장했고, 둘 다 에이전트를 '무언가'에 연결하는 것에 관한 것이며, 둘 다 거물급 이름들이 뒤를 받치고 있는 개방형 표준이기 때문입니다.

하지만 각 연결의 반대편에 무엇이 있는지 알게 되면, 혼란은 영구적으로 사라집니다. 이 글이 바로 그 역할을 하기 위해 작성되었습니다.

MCP란 무엇인가?

MCP — Model Context Protocol —는 AI 에이전트를 도구, 데이터 소스, 그리고 컨텍스트 (Context)에 연결하기 위한 개방형 표준입니다. 에이전트가 파일을 읽거나, 데이터베이스를 쿼리하거나, API를 호출하거나, 문서를 가져와야 할 때, MCP는 맞춤형 통합 (Bespoke integration) 대신 표준화된 방식으로 이를 가능하게 하는 계층 (Layer)입니다.

MCP 이전에는 모든 에이전트 프레임워크 (Framework)가 자신만의 '도구 (Tool)' 개념을 가지고 있었으며, 에이전트를 데이터 소스에 연결하려면 양쪽 모두에 특화된 어댑터 (Adapter)를 작성해야 했습니다. MCP는 그 연결을 프로토콜 (Protocol)로 만들었기 때문에, 한 번 노출된 도구는 이를 지원하는 어떤 에이전트와도 작동합니다.

MCP는 개별 에이전트에게 그 능력을 부여하는 것입니다. MCP (또는 그와 유사한 것)가 없는 에이전트는 생각할 수는 있지만, 그 무엇에도 도달할 수 없습니다.

A2A란 무엇인가?

A2A — Agent2Agent — 는 에이전트 간 통신을 위한 개방형 프로토콜 (open protocol)입니다. 이 프로토콜은 어떤 프레임워크나 벤더(vendor)에 의해 구축되었는지와 관계없이, 독립적인 에이전트들이 서로를 발견하고, 작업을 위임하며, 결과를 안전하게 교환할 수 있도록 합니다.

A2A는 2025년 4월 Google에 의해 도입되었으며, Linux Foundation에 기여되어 현재는 벤더 중립적인 표준 (vendor-neutral standard)으로서 관리되고 있습니다. 이후 핵심 데이터 모델 (data models)이 확정된 안정적인 1.0 버전이 출시되었습니다. 공식 SDK는 Python, JavaScript, Java, Go, .NET용으로 제공되며, Microsoft Copilot Studio, Azure AI Foundry, Amazon Bedrock AgentCore, Google ADK 내에서 이 프로토콜을 지원합니다.

내부 구조는 의도적으로 화려함을 지양합니다. 전송을 위한 HTTP, 구조화된 요청을 위한 JSON-RPC 2.0, 스트리밍 업데이트를 위한 Server-Sent Events (SSE), 그리고 인증을 위한 JWT 기반의 OAuth 2.0을 사용합니다. 특별히 이색적인 것은 없지만, 바로 그 점 때문에 채택이 빠르게 이루어졌습니다.

A2A를 구성하는 다섯 가지 요소

• 에이전트 카드 (Agent Card) — 에이전트의 정체성, 엔드포인트 (endpoint), 인증, 기술을 설명하는 JSON 문서로, 다른 에이전트가 발견할 수 있도록 /.well-known/agent-card.json에 게시됩니다.
• 작업 (Task) — 제출부터 완료까지 생명주기 (lifecycle)를 추적할 수 있는 중앙 집중식의 상태 유지 (stateful) 작업 단위입니다.
• 메시지 (Message) — 두 에이전트 간의 단일 통신 턴 (turn)입니다.
• 파트 (Parts) — 메시지 내부의 타입화된 콘텐츠로, 텍스트, 파일 또는 구조화된 데이터가 포함됩니다.
• 아티팩트 (Artifact) — 완료된 작업이 생성하는 영구적인 출력물입니다.

클라이언트는 카드를 통해 에이전트를 발견하고, 작업을 시작하기 위해 메시지를 보내며, 해당 작업의 상태를 추적하고, 작업이 완료되면 아티팩트를 수집합니다. 다섯 개의 명사, 하나의 흐름 — 이것이 프로토콜의 대부분입니다.

A2A vs MCP: 비교

MCP는 에이전트에게 손을 부여합니다. A2A는 에이전트에게 동료를 부여합니다.

실제 시스템에서 이들이 계층화되는 방식

두 가지 평면(plane)으로 구성된 시장 보고서 시스템을 상상해 보십시오.

수평적으로 (Horizontally), A2A를 통해: 사용자가 오케스트레이터 에이전트 (orchestrator agent)에게 보고서를 요청합니다. 오케스트레이터는 데이터 수집은 리서치 에이전트 (research agent)에게, 차트 생성은 시각화 에이전트 (visualization agent)에게 위임합니다. 이 과정에서 각 에이전트를 에이전트 카드 (Agent Card)를 통해 발견하고, 범위가 제한된 토큰 (scoped token)으로 인증하며, 각 태스크 (Task)를 완료될 때까지 스트리밍합니다.

수직적으로 (Vertically), MCP를 통해: 리서치 에이전트는 실시간 데이터 소스에 쿼리를 날리고, 시각화 에이전트는 렌더링 도구 (rendering tool)를 호출합니다. 각 에이전트는 자신에게 필요한 기능 (capabilities)을 하위 계층으로 요청하고 있습니다.

결과는 아티팩트 (Artifacts) 형태로 다시 상위로 흐르며, 오케스트레이터가 보고서를 조립합니다. 두 개의 평면(plane)이 각각 하나의 작업을 수행하며, 어느 하나가 단독으로는 할 수 없는 무언가로 결합됩니다. A2A는 에이전트 간에 작업을 이동시켰고, MCP는 각 에이전트에게 필요한 컨텍스트 (context)를 제공했습니다.

언제 둘 다 필요할까요?

• MCP만 사용하십시오: 에이전트가 도구 (tools)를 사용하지만 다른 에이전트에게 위임하지 않는 경우입니다. 데이터베이스 접근 권한을 가진 단일 역량 있는 어시스턴트에게는 A2A가 필요하지 않습니다.
• A2A만 사용하십시오: 에이전트 간에 태스크를 전달하기만 하고 자체적인 도구를 보유하지 않은 순수 라우터 (router)의 경우입니다. 드물지만 실제로 존재합니다.
• 둘 다 사용하십시오: 에이전트가 리소스 (resources)에 대해 동작해야 함과 동시에 동료들과 협업해야 할 때입니다. 이는 본질적으로 야심 찬 모든 멀티 에이전트 시스템 (multi-agent system)의 모습입니다.

목표는 문제가 허용하는 한 시스템을 최대한 단순하게 유지하는 것입니다. 멀티 에이전트라는 말이 멋있게 들린다고 해서 무작정 A2A를 선택하지 마십시오. 모든 위임은 네트워크 홉 (network hop)을 추가하며, 대개 또 다른 모델 호출 (model call)을 수반합니다. 전문화 (specialization)나 규모 (scale)가 실제로 그 오버헤드 (overhead)를 정당화할 때 A2A를 도입하십시오.

왜 이 조합이 지속 가능한 선택인가

표준 (standards)은 서로 결합될 때 승리합니다. HTTP가 반드시 HTML일 필요는 없었습니다. 각자가 하나의 작업을 수행했고, 함께 웹을 지탱했습니다. A2A와 MCP도 동일한 논리를 따르며, 이것이 바로 이 쌍(pair)에 투자하는 것이 단일 프레임워크 (framework)에 투자하는 것보다 더 안전한 이유입니다.

내면화할 가치가 있는 부분은 다음과 같습니다: A2A를 사용하는 에이전트는 자신의 카드(card)와 기술(skills)만을 노출합니다. 그 표면 뒤의 모든 것은 비공개입니다. 즉, 어떤 모델을 호출하는지, 어떤 프레임워크 (framework)에서 실행되는지, MCP를 통해 어떤 도구 (tools)에 접근하는지, 로직이 어떻게 작성되었는지 등은 숨겨집니다. 이 중 어떤 것을 교체하더라도 호출자에게는 아무런 영향을 미치지 않는데, 왜냐하면 호출자는 그 중 그 어느 것에도 의존하지 않았기 때문입니다.

모델은 개선될 것입니다. 프레임워크는 교체될 것입니다. 하지만 개방형 프로토콜 (open protocol)을 사용하는 잘 설명된 에이전트들의 카탈로그는 이 모든 과정 속에서도 계속 호출 가능한 상태로 유지됩니다. 프로토콜은 안정적인 인터페이스 (interface)이며, 그 아래의 모든 것은 자유롭게 진화할 수 있습니다.

흔한 실수들

• 데이터베이스에 접근하기 위해 A2A를 사용하는 것. 상대측이 리소스 (resource)라면, 그것은 MCP입니다. 상대측에 무엇이 있는지 물어보십시오. 그러면 매번 정답을 얻을 수 있습니다.
• 두 에이전트를 연결하기 위해 MCP를 사용하는 것. 에이전트를 "도구 (tool)"로 래핑 (wrapping)하는 방식은, 해당 에이전트가 명확한 질문을 던져야 하거나, 10분 동안 실행되어야 하거나, 진행 상황을 보고해야 하는 상황이 오기 전까지만 유효합니다. 태스크 (tasks)가 존재하는 데에는 이유가 있습니다.
• A2A를 함수 호출 (function call)처럼 취급하는 것. A2A는 상태 유지 (stateful), 장기 실행 (long-running), 상호 신뢰 협업 (cross-trust collaboration)을 위한 프로토콜입니다. 이를 염두에 두고 설계하면 대부분의 문제는 사라집니다.
• 기본적으로 피어 (peers)를 신뢰하는 것. A2A를 사용하는 에이전트라고 해서 자동으로 안전한 것은 아닙니다. 모든 요청을 인증 (authenticate)하고, 권한을 좁게 부여 (authorize narrowly)하며, 모든 입력을 검증 (validate)하고, 속도 제한 (rate-limit)을 설정하십시오.

자주 묻는 질문 (FAQ)

A2A와 MCP의 차이점은 무엇인가요?
MCP는 단일 에이전트를 도구, 데이터, 컨텍스트 (context)에 연결합니다. 즉, 에이전트가 리소스를 어떻게 사용하는지에 대한 답을 제공합니다. A2A는 에이전트를 다른 에이전트에 연결합니다. 즉, 한 에이전트가 다른 에이전트에게 어떻게 업무를 위임 (delegate)하는지에 대한 답을 제공합니다. MCP는 수직적 (vertical)이며, A2A는 수평적 (horizontal)입니다. 이들은 상호 보완적이며, 대부분의 프로덕션 시스템 (production systems)은 두 가지를 모두 사용합니다.

A2A가 MCP를 대체하나요?
아니요. 이들은 서로 다른 문제를 해결하며 공존하도록 설계되었습니다. 이들은 결코 중복되지 않는데, 왜냐하면 에이전트 지점에서 만나기 때문입니다. 에이전트는 외부의 피어 (peers)에게는 A2A로 말하고, 자신의 도구 (tools)에게는 MCP로 말합니다. 두 프로토콜 모두 Linux Foundation의 관리하에 있습니다.

A2A는 프로덕션 환경에 적용할 준비가 되었나요?
네. A2A는 핵심 데이터 모델 (data models)이 확정된 안정적인 1.0 버전에 도달했습니다. 또한 벤더 중립적 표준으로서 Linux Foundation의 관리하에 있으며, 5개 언어에 대한 공식 SDK를 제공합니다. 아울러 Microsoft Copilot Studio, Azure AI Foundry, Amazon Bedrock AgentCore, 그리고 Google ADK 내에서도 지원됩니다.

A2A를 채택하기 위해 기존 에이전트를 다시 작성해야 하나요?
아니요. A2A는 프레임워크 (framework)가 아니라, 에이전트 간의 메시징 계층 (messaging layer)입니다. 기존의 스택 (stack)을 그대로 유지할 수 있습니다. 채택한다는 것은 에이전트에게 에이전트 카드 (Agent Card)와 A2A 엔드포인트 (endpoint)를 부여하는 것을 의미하며, 에이전트의 내부 구조는 그대로 유지됩니다.

어떤 것을 먼저 배워야 할까요?
단일 에이전트에서 시작한다면 MCP를 먼저 배우세요. 동료를 만들어주기 전에 먼저 손 (도구 사용 능력)을 만들어주어야 합니다. 만약 이미 유능한 에이전트들을 보유하고 있지만 서로 통신할 수 없는 상황이라면 A2A를 배우세요. 그것이 바로 당신이 마주한 장벽이기 때문입니다.

이 시리즈의 다른 글들

• A2A란 무엇인가? — Agent2Agent 프로토콜이란 무엇인가? A2A에 대한 완전한 입문서
• 에이전트 카드 (The Agent Card) — 에이전트 카드: AI 에이전트가 서로를 발견하는 방법
• 태스크 라이프사이클 (The Task Lifecycle) — A2A 태스크 라이프사이클 이해하기 (그리고 모든 클라이언트를 멈추게 하는 버그)

더 깊이 알고 싶으신가요?

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

A2A Quick-Start — 무료, 6페이지. 15분 만에 배우는 Agent2Agent 프로토콜: 정의, 5가지 구성 요소, 태스크 라이프사이클, 그리고 MCP의 위치.

A2A: The Complete Guide — 42페이지. 15개의 장과 5개의 부록으로 구성되었습니다. 발견 (Discovery), 보안 (security), SDK를 이용한 첫 에이전트 구축, 오케스트레이션 패턴 (orchestration patterns), 확장 및 AP2, 프로덕션 및 스케일링 (scaling) — 여기에 두 에이전트가 대화하는 전체 실습 예제와 30일간의 채택 경로가 포함되어 있습니다.