A2A가 MCP를 대체한다는 말이 왜 틀렸는가

Google A2A 프로토콜이 2025년 4월 공개된 직후부터 국내 커뮤니티에는 “MCP는 이제 끝났다”는 분위기가 돌았습니다.
그런데 구글 공식 개발자 블로그(2026.03.18 게시)에서는 두 프로토콜이 아예 다른 층에서 작동한다고 설명합니다.
공식 문서의 표현을 그대로 가져오면 이렇습니다.

“MCP connects agents to tools and data. A2A connects agents to other agents.”
(출처: Google Developers Blog, 2026.03.18 — 원문 링크)

한 줄로 정리하면, MCP는 AI가 도구를 쥐는 방법이고 A2A는 AI끼리 일을 나누는 방법입니다. 레이어 자체가 다릅니다.
실무에서 더 정확히 구분하면 이렇습니다.

SDK 월간 다운로드 수가 9,700만 건에 달한다는 뜻은, MCP는 이미 인프라 수준으로 자리 잡았다는 신호입니다.
A2A가 등장했다고 해서 이 인프라가 사라질 이유가 없습니다.

▲ 목차로 돌아가기

A2A v0.3.0, 실제로 무엇이 달라졌나

현재 안정 버전인 v0.3.0에서 가장 눈에 띄는 변화는 gRPC 옵션 추가입니다.
기존 HTTP + JSON 방식이 기본으로 유지되면서, 고성능 배포 환경에서는 gRPC를 선택할 수 있게 됐습니다.
(출처: Dev.to, 2026.03.10 — 원문 링크)

또 하나의 큰 변화는 IBM의 에이전트 커뮤니케이션 프로토콜(ACP)이 2025년 8월에 A2A로 흡수됐다는 점입니다.
경쟁 스펙이 통합된 것이니, A2A가 업계 단일 표준으로 굳어지는 속도가 예상보다 훨씬 빨라졌습니다.

Agent Card: 에이전트의 명함 역할

A2A의 핵심은 Agent Card입니다. /.well-known/agent.json 경로에 JSON 형태로 제공되며,
에이전트 이름·기능·인증 요구사항을 담습니다. 다른 에이전트는 이 URL만 알면 별도 설정 없이 상대의 기능을 자동으로 파악합니다.
구글 공식 문서는 이를 “AI 기능을 위한 robots.txt”라고 표현합니다. 발견(Discovery) 비용이 0에 가까워지는 구조입니다.

태스크 상태 머신: 비동기 작업의 표준화

태스크는 submitted → working → input-required → completed / failed / canceled 순으로 상태가 바뀝니다.
기존 REST API 방식에서는 개발팀마다 이 흐름을 직접 구현해야 했는데, A2A는 그것을 표준화했습니다.
수 시간이 걸리는 딥 리서치 작업에서도 실시간 상태 업데이트가 SSE로 전달되기 때문에, 클라이언트가 폴링할 필요가 없습니다.

▲ 목차로 돌아가기

에이전트 수가 늘면 생기는 N제곱 문제

A2A는 기본적으로 에이전트 간 직접 HTTP 연결을 사용합니다.
에이전트가 N개일 때 잠재적 연결 수는 최대 N×(N-1)/2로 늘어납니다.
에이전트 10개면 최대 45개의 직접 연결이 필요하고, 50개면 1,225개입니다. 실제 운영 환경에서 이 구조는 꽤 취약해집니다.
(출처: Medium — Chamuditha Kekulawala, 2025.05.22 — 원문 링크)

이 수치가 의미하는 건 간단합니다. 중소 규모까지는 A2A 단독으로 충분하지만, 에이전트 수십 개를 동시에 운영하는 대형 워크플로우에서는 Apache Kafka 같은 이벤트 메시 레이어가 별도로 필요해집니다.
공식 문서도 이 점을 명시하고 있습니다.

실제 아키텍처 패턴에서 본 권장 규모

막상 써보면 다릅니다. 튜토리얼 수준에서는 간단해 보여도, 생산 환경에서 에이전트 수가 늘어날수록 통신 관리 오버헤드가 생각보다 빠르게 증가합니다.

▲ 목차로 돌아가기

보안 기본 내장이라는 말이 맞는 조건

A2A 공식 스펙(v0.3.0)에 따르면, 프로토콜 자체는 특정 인증 메커니즘을 강제하지 않습니다.
Agent Card에 인증 요구사항을 선언할 수 있지만, 그것을 실제로 집행하는 건 각 구현체의 몫입니다.
(출처: A2A 공식 스펙 — a2a-protocol.org/latest/specification)

실제로 보고된 보안 취약 경로 3가지

Cloud Security Alliance(2025.04.30)와 Palo Alto Networks(2025.08.14)가 각각 정리한 A2A 위협 모델을 보면 세 가지 경로가 반복적으로 등장합니다.

1. 에이전트 사칭(Agent Impersonation) — Agent Card는 공개적으로 노출됩니다. 공격자가 정상 에이전트처럼 위장한 카드를 배포하면, 다른 에이전트가 그것을 신뢰하고 태스크를 위임할 수 있습니다. A2A 프로토콜 자체에는 Agent Card 진위 검증 메커니즘이 현재 없습니다.
2. 간접 공격 경로(Indirect Attack via MCP) — A2A 디스커버리로 에이전트를 찾은 뒤, 그 에이전트가 연결한 MCP 서버 취약점을 노리는 방식입니다. “툴 스쿼팅(Tool Squatting)”이라고 부르는 가짜 툴 등록 공격이 여기에 포함됩니다.
3. 연쇄 감염(Cascade Attack) — 하나의 에이전트가 악성 지시를 A2A를 통해 다른 에이전트로 전파할 수 있습니다. 멀티 에이전트 네트워크에서 하나가 뚫리면 옆으로 번질 수 있는 구조입니다.

이 세 가지 중 현재 A2A v0.3.0이 기본으로 방어하는 것은 없습니다. 생산 환경에서는 mTLS 적용, 에이전트별 최소 권한 설정, 감사 로그 의무화가 별도로 필요합니다.
공식 스펙이 권고만 하고 있을 뿐, 강제 조항은 아직 없다는 게 현실입니다.

▲ 목차로 돌아가기

MCP만 써도 충분한 경우 vs A2A가 필요한 경우

솔직히 말하면, 대부분의 개인 개발자나 소규모 팀은 MCP만으로 충분합니다.
A2A를 써야 할 분기점은 생각보다 명확합니다. 공식 문서가 제시하는 기준을 실무 관점으로 정리했습니다.

MCP만으로 충분한 경우

• 에이전트가 1개이고 데이터베이스·API·파일 시스템에 접근할 때 — 클로드 데스크톱, Cursor, Windsurf 같은 로컬 도구 대부분이 이 케이스
• 원격 시스템이 동일한 입력에 항상 같은 출력을 내는 경우 — “기능(function)”에 가까울수록 MCP 서버가 더 적합
• 팀이 작고 통합할 외부 에이전트가 없는 경우 — 멀티 에이전트 아키텍처는 디버깅 비용이 단일 에이전트보다 월등히 높음

A2A가 있어야 하는 경우

• 원격 시스템이 자체 AI 추론 능력을 가진 경우 — 상대가 단순 툴이 아니라 판단하는 에이전트일 때
• 태스크가 수 시간 이상 이어지고 중간 상태 업데이트가 필요한 경우 — A2A의 상태 머신과 SSE 스트리밍이 여기서 빛을 발함
• 다른 회사가 만든 에이전트와 연동해야 하는 경우 — Salesforce Agentforce, ServiceNow 에이전트 등 엔터프라이즈 생태계 연결이 목적일 때

실제 구현에서 두 가지가 겹치는 지점

자동화 PR 리뷰 파이프라인을 예로 들면, 오케스트레이터 에이전트가 보안 에이전트·성능 에이전트·스타일 에이전트에게 일을 나눠주는 건 A2A입니다.
각 전문 에이전트가 GitHub, SonarQube, ESLint에 접근하는 건 MCP입니다.
이 구조에서 오케스트레이터는 개별 툴을 몰라도 되고, 각 전문 에이전트는 서로를 몰라도 됩니다.
관심사 분리가 코드 변경 없이 이뤄집니다.
(출처: Dev.to MCP vs A2A 완전 가이드, 2026.03.04 — 원문 링크)

▲ 목차로 돌아가기

AAIF 거버넌스가 실무에 미치는 영향

2025년 12월, Linux Foundation이 Agentic AI Foundation(AAIF)을 출범시키면서 MCP와 A2A를 모두 여기에 넣었습니다.
공동 창립자가 OpenAI, Anthropic, Google, Microsoft, AWS, Block 6개사입니다.
어느 한 회사가 스펙을 독점하는 구조가 아닙니다.

이게 실무에서 의미하는 건 두 가지입니다. 첫째, 지금 A2A 기반으로 에이전트를 구현해도 특정 클라우드 벤더에 종속되지 않습니다.
Salesforce Agentforce에서 만든 에이전트와 Google Vertex AI에서 만든 에이전트가 A2A로 연결될 수 있는 이유가 여기에 있습니다.
둘째, 스펙 변경이 RFC 과정을 거치기 때문에 예고 없는 브레이킹 체인지 위험이 낮아집니다.

이 부분이 좀 아쉬웠습니다. AAIF 아래에 있다고 해서 하위 호환을 100% 보장하는 게 아닙니다.
A2A는 아직 v0.x 버전입니다. v1.0이 나오기 전까지는 스펙이 바뀔 여지가 있고, 그 사이에 쌓은 Agent Card 구현이 수정돼야 할 수도 있습니다.

공식 로드맵에서 확인된 다음 변경 예정 항목

• 에이전트 레지스트리 — 조직 간 에이전트 디렉터리. 현재 각 팀이 URL을 직접 관리하는 방식을 중앙화할 예정
• 계약 협상(Contract Negotiation) — 태스크 실행 전 SLA와 품질 기준을 에이전트끼리 합의하는 기능
• 엔터프라이즈 컴플라이언스 훅 — SOC2, GDPR, HIPAA 감사 추적 형식 표준화

▲ 목차로 돌아가기

자주 나오는 질문 5가지

▲ 목차로 돌아가기

마치며 — 총평

Google A2A 프로토콜은 MCP의 대안이 아닙니다. 공식 문서를 직접 확인해보면, 두 프로토콜은 같은 스택의 서로 다른 층에서 작동합니다.
MCP가 에이전트에게 손을 주는 도구라면, A2A는 에이전트끼리 팀을 꾸리게 해주는 규약입니다.

개인적인 판단으로는 지금 A2A를 도입할 팀과 아닌 팀이 꽤 명확하게 나뉩니다.
단일 에이전트로 충분한 경우라면 굳이 멀티 에이전트 아키텍처를 끌어올 이유가 없고, 디버깅 비용만 늘어납니다.
반대로 여러 회사의 에이전트를 연결하거나 수 시간짜리 복잡한 워크플로우를 자동화해야 한다면, A2A는 지금 당장 가장 현실적인 선택입니다.

한 가지 주의할 점은 보안입니다. “기본 내장”이라는 표현을 그대로 믿고 mTLS 없이 생산 환경에 올리면 문제가 생길 수 있습니다.
공식 스펙이 권고하는 수준이 아직 의무 수준이 아니기 때문에, 팀 차원에서 별도로 체크리스트를 만들어두는 게 좋습니다.

본 포스팅 참고 자료

1. Google Developers Blog — Developer’s Guide to AI Agent Protocols (2026.03.18)
   https://developers.googleblog.com/developers-guide-to-ai-agent-protocols/
2. Google Developers Blog — Announcing the Agent2Agent Protocol (A2A) (2025.04.09)
   https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/
3. A2A 공식 스펙 — a2a-protocol.org/latest/specification
   https://a2a-protocol.org/latest/specification/
4. Dev.to — MCP vs A2A: The Complete Guide to AI Agent Protocols in 2026 (2026.03.04)
   https://dev.to/pockit_tools/mcp-vs-a2a-the-complete-guide-to-ai-agent-protocols-in-2026-30li
5. Medium — Everything Wrong with Agent2Agent (A2A) Protocol (2025.05.22)
   https://medium.com/@ckekula/everything-wrong-with-agent2agent-a2a-protocol-7e5ae8d4ab2b
6. Cloud Security Alliance — Threat Modeling Google’s A2A Protocol (2025.04.30)
   https://cloudsecurityalliance.org/blog/2025/04/30/threat-modeling-google-s-a2a-protocol-with-the-maestro-framework