A2A vs MCP: 에이전트 통신을 위한 올바른 프로토콜 선택

대부분의 프로덕션 에이전트 시스템은 하나가 아닌 두 개의 프로토콜이 필요합니다. Model Context Protocol (MCP)은 에이전트에게 도구와 데이터 소스에 대한 액세스를 제공합니다 — NetSuite 레코드, HubSpot 연락처, 공급업체 카탈로그, Redshift 쿼리. Agent2Agent Protocol (A2A)은 에이전트가 다른 에이전트에게 작업을 위임하는 방법을 제공합니다 — 견적 에이전트가 카탈로그 에이전트에게 대체 부품을 요청, 구매 에이전트가 컴플라이언스 에이전트에게 GMP 인증 검증을 요청. 이 둘을 혼동하면 취약한 아키텍처로 이어집니다: 데이터베이스를 호출하기 위해 A2A를 사용하거나, 두 개의 독립적인 에이전트를 조정하기 위해 MCP를 사용하면 자체 프로토콜 설계와 충돌하는 시스템이 생성됩니다.

2026년 8월 1일, OpenAI는 Astra를 확인했습니다 — 장기 실행 멀티 에이전트 작업을 위해 명시적으로 설계된 차세대 주요 모델 패밀리입니다. 내부 버전은 수학과 이론 컴퓨터 과학의 열 개의 이전에 미해결 개방 문제를 해결했으며, 총 토큰 비용은 약 $2,000였습니다. Astra는 확장된 기간 동안 여러 에이전트를 조정하며, 이는 A2A(에이전트 간 위임)와 MCP(에이전트-도구 간 액세스)가 함께 작동해야 하는 정확한 패턴입니다. 모델 레이어는 이제 이중 프로토콜 패턴을 위해 구축되고 있습니다.

이 글은 A2A와 MCP 중에서 선택하거나, 더 일반적으로 멀티 에이전트 시스템에서 각각을 어디에 배치할지 결정하는 팀을 위한 의사결정 프레임워크입니다. 각 프로토콜의 기본 사항을 이해하고 있다고 가정합니다. 통합 워크스루가 필요한 경우, A2A Hermes Agent 브리지와 MCP + A2A 프로토콜 스택 개요가 구현 측면을 다룹니다.

한 줄 구분

MCP는 에이전트를 도구에 연결합니다. A2A는 에이전트를 에이전트에 연결합니다. MCP는 도구 호출 프로토콜입니다 — 에이전트가 리소스를 요청하거나 함수를 호출하면, 서버가 구조화된 데이터로 응답합니다. A2A는 작업 위임 프로토콜입니다 — 에이전트가 다른 에이전트에게 작업 단위를 보내고, 스트리밍 출력을 받으며, 상태 머신을 통해 작업을 추적합니다. 150개 이상의 A2A 조직과 10,000개 이상의 MCP 서버에서 확인된 프로덕션 패턴은: 에이전트 간에는 A2A, 에이전트와 도구 간에는 MCP입니다.

각 프로토콜이 적용되는 위치

차원	MCP	A2A
연결 대상	에이전트 → 도구, 데이터 소스, API	에이전트 → 에이전트
작업 단위	도구 호출 (요청/응답)	작업 (상태 저장 수명 주기)
프로토콜 주체	Anthropic (개방 사양, 2026-07-28 최종)	Google (개방 사양, Linux Foundation, 150개 이상 조직)
전송	STDIO, Streamable HTTP (SSE 사용 중단, 12개월 Sunset)	JSON-RPC 2.0 over HTTP, SSE 스트리밍
발견	서버가 도구 등록; 클라이언트가 발견	/.well-known/agent-card.json의 Agent Card
상태	무상태 (2026-07-28 사양); 상태는 클라이언트에 존재	상태 저장 작업 머신: submitted → working → input-required → completed/failed/canceled
스트리밍	도구 결과는 단일 응답	message/stream으로 실시간 토큰 및 아티팩트 전달
인간 개입	일급 개념 아님	INPUT_REQUIRED는 일급 작업 상태
인증	서버별; 사양에서 OAuth 2.1, 실제에서는 베어러 토큰	에이전트별; Agent Card가 인증 체계 선언, 게이트웨이가 시행 처리
채택	10,000개 이상 서버, 4개 Tier 1 SDK (TypeScript, Python, Go, C#)	150개 이상 조직, Linux Foundation 거버넌스

이 표는 대부분의 팀이 처음 묻는 질문에 답합니다: 귀하의 통합이 "에이전트가 고객 레코드를 위해 NetSuite를 쿼리해야 하는" 경우, 그것은 MCP입니다. 귀하의 통합이 "구매 에이전트가 가격 에이전트에게 세 개의 공급업체 견적을 평가하고 권장 사항을 반환하도록 요청하는" 경우, 그것은 A2A입니다. 구분은 상대방이 자체 추론을 가지고 있는지, 아니면 구조화된 쿼리에 응답하는 데이터 소스인지입니다.

분담을 결정하는 5가지 질문

1. 상대방이 추론합니까, 응답합니까?

NetSuite MCP 서버는 추론하지 않습니다. 도구 호출(get_customer, search_items)을 받고, API를 쿼리하고, 구조화된 JSON을 반환합니다. 호출한 에이전트가 추론을 수행합니다. A2A 가격 에이전트는 추론합니다 — 작업("이 세 가지 견적을 과거 가격 책정 및 공급업체 신뢰성에 대해 평가하십시오")을 받고, 자체 모델 추론을 실행하고, 자체 MCP 도구를 호출할 수 있으며, 추론이 첨부된 권장 사항을 반환합니다.

상대방이 데이터 소스나 API인 경우, MCP를 사용하십시오. 상대방이 자체 모델, 자체 도구, 자체 의사결정을 가진 자율 에이전트인 경우, A2A를 사용하십시오. 실용적인 테스트: 호출하는 대상에 자체 프롬프트가 있습니까? 있으면 A2A. 없으면 MCP.

2. 스트리밍 출력이 필요합니까?

MCP 도구 호출은 요청/응답입니다. 서버는 요청을 처리하고 단일 결과를 반환합니다. 중간 상태, 토큰별 스트리밍, 부분 아티팩트가 없습니다. 데이터베이스 쿼리나 레코드 가져오기에는 문제없습니다 — 단편의 스트림이 아닌 완전한 결과를 원합니다.

A2A는 토큰 델타와 아티팩트가 생성될 때 전달하는 message/stream을 지원합니다. 세 개의 견적을 평가하는 데 30초가 걸리는 가격 에이전트는 작업하는 동안 추론을 스트리밍할 수 있어, 호출하는 에이전트(그리고 관찰하는 인간)가 진행 상황을 보고, 오류를 조기에 감지하고, 추론이 잘못되면 취소할 수 있습니다. 워크플로우가 시간 경과에 따라 출력을 생성하고 부분 결과에 대해 조치해야 하는 경우, A2A가 이를 기본적으로 지원하는 프로토콜입니다.

3. 인간 승인 게이트가 있습니까?

MCP에는 인간 개입의 일급 개념이 없습니다. MCP 도구를 호출하는 에이전트에 승인 로직을 구축할 수 있습니다 — 에이전트가 일시 정지하고, 인간에게 물어본 다음 계속합니다 — 하지만 프로토콜 자체는 이를 인코딩하지 않습니다. 승인 상태는 프로토콜이 아닌 애플리케이션 코드에 존재합니다.

A2A는 INPUT_REQUIRED를 일급 작업 상태로 정의합니다. 에이전트가 인간 승인이 필요한 결정 — 구매 승인, 견적 승인, 데이터 액세스 결정 — 에 도달하면, 작업을 INPUT_REQUIRED로 전환합니다. 호출하는 에이전트(또는 그 뒤의 인간 운영자)는 프레임워크별 세부 사항이 아닌 표준 프로토콜 상태를 봅니다. 인간이 응답하면 작업이 재개됩니다. 워크플로우에 에이전트 경계를 가로지르는 승인 게이트가 포함된 경우, A2A는 이러한 게이트를 투명하게 전달합니다. Hermes Agent A2A 브리지는 Hermes의 네이티브 승인 요청을 A2A의 INPUT_REQUIRED 상태로 매핑하므로, 각 에이전트가 어떤 프레임워크에서 실행되든 에이전트 위임 체인에 인간 체크포인트를 포함할 수 있습니다.

4. 작업에 얼마나 시간이 걸립니까?

MCP 도구 호출은 짧고 동기적인 작업을 위해 설계되었습니다 — API 쿼리, 레코드 가져오기, 계산 실행. 2026-07-28 사양은 MCP를 명시적으로 무상태로 만들었습니다. 즉, 서버는 호출 간의 대화 컨텍스트를 유지하지 않습니다. 상태는 서버가 아닌 클라이언트(에이전트)에 존재합니다. 이것은 도구에 대한 올바른 설계입니다: NetSuite 서버는 5분 전에 고객을 쿼리했다는 것을 기억해서는 안 됩니다.

A2A 작업은 명시적 수명 주기 관리를伴는 장기 실행 작업을 위해 설계되었습니다. 작업은 submitted → working → completed(또는 failed, canceled, input-required)를 거칩니다. 상태 머신은 프로토콜의 일부입니다. 2분이 걸리는 가격 평가, 1시간이 걸리는 컴플라이언스 검사, 하루가 걸리는 멀티 에이전트 연구 작업 — 이러한 것들은 A2A의 작업 모델에 적합합니다. OpenAI의 Astra는 8월 1일에 확인되었으며, 시간 또는 일 단위로 작업하는 작업을 위해 구축되었습니다. Astra의 멀티 에이전트 조정 패턴은 MCP의 무상태 도구 호출 모델이 아닌 A2A의 작업 수명 주기에 직접 매핑됩니다.

5. 하나의 시스템을 호출합니까, 여러 에이전트를 조정합니까?

에이전트가 NetSuite, HubSpot, BigCommerce와 통신해야 하는 경우, 그것은 세 개의 MCP 서버입니다. 각 서버는 도구를 노출하고, 에이전트는 필요에 따라 호출합니다. 에이전트가 조정을 수행합니다 — 어떤 도구를, 언제, 어떤 순서로 호출할지 결정합니다. MCP 서버는 서로에 대해 알지 못합니다.

카탈로그 에이전트, 가격 에이전트, 컴플라이언스 에이전트에 위임해야 하는 구매 에이전트가 있는 경우 — 각각 자체 모델과 도구를 가짐 — 그것은 세 개의 A2A 엔드포인트입니다. 구매 에이전트는 작업을 보내고, 스트리밍 결과를 받으며, 위임 체인을 조정합니다. 카탈로그, 가격, 컴플라이언스 에이전트는 각각 MCP를 사용하여 자체 데이터 소스에 액세스할 수 있습니다. 두 프로토콜은 다른 레이어에서 작동합니다: A2A는 에이전트 간 위임을 처리하고, MCP는 각 에이전트 내의 에이전트-도구 간 액세스를 처리합니다.

둘 다 사용하는 경우: 프로덕션 패턴

tyk.io 엔터프라이즈 가이드에서 확인되고 150개 이상의 A2A 조직에서 볼 수 있는 프로덕션 패턴은 2계층 아키텍처입니다:

각 전문 에이전트는 A2A 엔드포인트입니다(Agent Card를 노출하고, 작업을 수락하고, 결과를 스트리밍). 각 전문 에이전트는 또한 MCP를 사용하여 자체 데이터 소스에 연결합니다. 오케스트레이터 에이전트는 NetSuite에 직접 통신하지 않습니다 — 가격 에이전트에게 위임하고, 가격 에이전트는 MCP를 사용하여 NetSuite를 쿼리합니다. 이 분리는 각 에이전트의 도구 서피스가 거버넌스되고 감사 가능하게 유지하면서, A2A 레이어가 에이전트 간 조정을 처리합니다.

Hermes Agent A2A 브리지 참조 구현은 이 패턴을 보여줍니다: 게이트웨이가 A2A 프로토콜 서피스(Agent Card, JSON-RPC 디스패치, SSE 스트리밍, 작업 상태 머신)를 처리하고, 플러그 가능한 핸들러가 A2A 작업 의미론을 각 프레임워크의 네이티브 API로 변환합니다. 새 에이전트 프레임워크 추가는 하나의 핸들러 클래스 작성을 의미합니다 — 프로토콜, 게이트웨이, 상태 머신은 공유 인프라입니다. 동일한 게이트웨이는 A2A 클라이언트 서피스를 변경하지 않고 Hermes Agent, OpenClaw 또는 향후 핸들러로 라우팅할 수 있습니다.

단일 에이전트로 충분한 경우

모든 시스템이 A2A를 필요로 하는 것은 아닙니다. Princeton NLP 연구에 따르면 단일 에이전트가 64%의 벤치마크 작업에서 멀티 에이전트 시스템과 동등하거나 우수했습니다 — 멀티 에이전트 구성은 2배 비용. 워크플로우가 NetSuite를 쿼리하고, 견적을 작성하고, 승인을 위해 제출하는 단일 에이전트인 경우, MCP(NetSuite 연결용)와 애플리케이션 수준 승인 게이트가 필요합니다. A2A는 필요하지 않습니다.

다른 모델, 다른 도구 서피스 또는 조정이 필요한 다른 소유권 경계를 가진 에이전트가 있는 경우 A2A가 필요해집니다. 구매 팀의 소싱 에이전트와 재무 팀의 컴플라이언스 에이전트는 다른 그룹이 소유하고, 다른 인프라에서 실행될 수 있으며, 다른 모델 선택을 가질 수 있습니다. A2A는 코드베이스나 배포를 공유하지 않고 작업을 위임하고 추적할 수 있는 프로토콜을 제공합니다. 모든 에이전트가 동일한 소유자의 동일한 인프라에서 동일한 모델인 경우, MCP 도구를 갖춘 단일 에이전트가 더 간단하고 저렴합니다.

MCP 2026-07-28 사양 최종版: 이 결정에서 변경된 것

MCP 사양은 2026년 7월 28일 최종版으로 게시되었습니다. 4개 Tier 1 SDK(TypeScript, Python, Go, C#)가 모두 2026-07-28을 지원합니다. 사양은 MCP를 명시적으로 무상태로 만들었습니다 — 서버는 호출 간의 세션 상태를 유지하지 않습니다. 12개월 SSE 사용 중단 정책이 활성화되었습니다: Streamable HTTP 전송이 SSE를 대체하며, 기존 SSE 배포는 2027년 7월까지 마이그레이션해야 합니다.

A2A vs MCP 결정에 대해, 사양 최종版은 계층화를 확인합니다: MCP는 무상태 도구 프로토콜입니다. MCP 세션을 사용하여 에이전트 대화 상태를 유지하고 있었다면, 사양은 이를 중지하라고 말합니다 — 상태는 서버가 아닌 에이전트(MCP 클라이언트)에 속합니다. 이것은 A2A 레이어를 더 명확하게 필요하게 만듭니다: 에이전트 간의 장기 실행, 상태 저장 조정은 MCP가 설계된 것이 아닙니다. A2A의 작업 상태 머신이 이 간극을 채웁니다.

전송 중복에 대한 참고

두 프로토콜 모두 HTTP와 SSE를 사용하므로 경쟁하는지에 대한 혼란이 발생할 수 있습니다. 경쟁하지 않습니다 — 전송 중복은 표면적입니다. MCP는 도구 호출(요청 → 응답)에 HTTP를 사용하고, 서버 시작 알림을 위해 SSE에서 Streamable HTTP로 마이그레이션하고 있습니다. A2A는 작업 디스패치에 JSON-RPC 2.0 over HTTP를 사용하고, 스트리밍 작업 출력에 SSE를 사용합니다. 전송은 배관이며, 프로토콜 의미론은 다릅니다. MCP는 도구 호출을 전달합니다. A2A는 작업 수명 주기를 전달합니다. 둘을 동일한 게이트웨이에서 실행할 수 있습니다 — 참조 구현이 정확히 이렇게 하며, 게이트웨이가 두 프로토콜의 HTTP와 SSE를 처리하는 동안 브리지 레이어가 각 프레임워크의 네이티브 API로 변환합니다.

귀하의 아키텍처에 대한 의미

B2B 에이전트 시스템을 구축하는 경우 — RFQ 자동화, 구매 워크플로우, 지식 그래프를 갖춘 고객 지원, 데이터 파이프라인 오케스트레이션 — 프로토콜 결정은 워크플로우 형태를 따릅니다:

• 단일 에이전트, 다중 데이터 소스 → MCP만. 에이전트는 MCP 모듈을 사용하여 NetSuite, HubSpot, BigCommerce, 공급업체 카탈로그에 연결합니다. A2A 불필요.
• 다중 에이전트, 동일 소유자, 동일 인프라 → 도구에 MCP, 에이전트 간 작업에 애플리케이션 수준 조정. 조정 로직이 프로토콜 수준 상태 머신으로 단순화될 만큼 복잡해지면 A2A를 고려.
• 다중 에이전트, 다른 소유자 또는 다른 인프라 → 에이전트 간 위임에 A2A, 각 에이전트의 도구 액세스에 MCP. 이것이 분산 에이전트 시스템의 프로덕션 패턴입니다.
• 인간 승인 게이트가 있는 장기 실행 작업 → 작업 수명 주기와 INPUT_REQUIRED 상태에 A2A, 각 작업 내의 도구 호출에 MCP. 승인 게이트는 커스텀 애플리케이션 코드가 아닌 A2A 상태 전환으로 에이전트 경계를 가로지릅니다.

8월 1일 OpenAI의 Astra 확인은 장기 실행 멀티 에이전트 패턴을 프론티어 모델 설계 방향으로 만듭니다. Astra는 시간 또는 일 단위로 작업하는 작업을 위해 구축되었으며, 확장된 기간 동안 여러 에이전트를 조정합니다. 이 패턴을 지원하는 프로토콜 스택은 조정에 A2A, 도구 액세스에 MCP입니다 — 이 글이 설명하는 이중 프로토콜 아키텍처입니다.

---

중견 유통업체는 카탈로그 에이전트와 통신하는 견적 에이전트와 컴플라이언스 에이전트와 통신하는 카탈로그 에이전트가 필요합니다 — 각각 다른 모델로 지원되고, 각각 다른 팀이 소유하며, 각각 MCP 모듈을 통해 다른 시스템에 연결됩니다. A2A는 이러한 에이전트에게 위임과 스트리밍을 위한 공유 프로토콜을 제공합니다. MCP는 각 에이전트에게 데이터 소스에 대한 거버넌스된 액세스를 제공합니다. 브리지 패턴은 Hermes Agent, OpenClaw 및 기타 프레임워크가 내부를 다시 작성하지 않고 A2A 네트워크에 참여할 수 있게 합니다.

스코프가 정의된 구축 요청

일주일 발견. 시스템 인벤토리, 워크플로우 맵, 고정 스코프를 얻을 수 있습니다 — 당사와 구축하든 아니든.