A2A 프로토콜, MCP가 있어도 필요한 이유가 있습니다

“MCP를 쓰면 A2A는 필요 없는 거 아닌가요?” — 직접 공식 문서를 열어보고 나서야 이 질문이 얼마나 틀렸는지 알았습니다. A2A 없이 MCP만 쓰면 에이전트끼리 아무리 통신해도 실제 작업은 하나도 안 됩니다. 반대로 A2A만으로는 외부 도구에 손조차 못 뻗습니다. 두 프로토콜은 설계부터 역할이 달랐습니다.

MCP와 A2A, 5개월 간격으로 나온 두 프로토콜의 정체

MCP(Model Context Protocol)는 Anthropic이 2024년 11월에 공개한 오픈 표준입니다. AI 에이전트가 외부 도구, API, 데이터 소스에 연결하는 방식을 통일하기 위해 만들었습니다. (출처: Anthropic 공식 발표, 2024.11)

A2A(Agent2Agent Protocol)는 Google이 2025년 4월 9일 Google Cloud Next에서 공개했습니다. Salesforce, SAP, Workday, PayPal, Atlassian 등 50개 이상의 기술 파트너와 Deloitte, McKinsey 등 컨설팅사가 참여해 만든 에이전트 간 통신 표준입니다. (출처: Google Developers Blog, 2025.04.09) 현재 두 프로토콜 모두 리눅스 재단(Linux Foundation)에 이관되어 특정 기업 소유 없이 운영됩니다.

결론부터 말씀드리면, 이 둘은 겹치지 않습니다. MCP는 에이전트와 도구 사이의 연결을 표준화했고, A2A는 에이전트와 에이전트 사이의 연결을 표준화했습니다. 설계 의도가 처음부터 달랐습니다.

▲ 목차로 돌아가기

에이전트에게 손을 주는 MCP, 목소리를 주는 A2A

A2A 공식 문서(a2a-protocol.org)에 딱 이렇게 나옵니다. “MCP는 에이전트가 도구를 쓸 수 있게 해주고, A2A는 에이전트끼리 통신하게 해준다. 둘 다 필요하다.” MCP가 없으면 에이전트는 생각은 할 수 있지만 아무것도 건드릴 수 없고, A2A가 없으면 에이전트들은 각자 고립된 채 일합니다.

A2A의 핵심 작동 방식은 세 단계입니다. ① 디스커버리(발견): 모든 A2A 에이전트는 /.well-known/agent.json 경로에 에이전트 카드(Agent Card)라는 JSON 파일을 공개합니다. 이름, 기능, API 엔드포인트, 인증 방식이 담긴 공개 명함입니다. ② 인증: OpenAPI 스펙에 맞는 API 키, OAuth 2.0, OpenID Connect를 지원합니다. ③ 통신: HTTPS 위에서 JSON-RPC 2.0 형식으로 태스크(Task)를 주고받습니다. 최근 v0.3 업데이트에서 gRPC 전송도 추가됐습니다.

A2A가 MCP와 결정적으로 다른 부분은 장기 실행 태스크(Long-Running Operation)를 기본 지원한다는 점입니다. 에이전트가 몇 시간, 혹은 며칠이 걸리는 작업을 처리할 때도 SSE 스트리밍과 푸시 알림(webhook)으로 진행 상황을 계속 받을 수 있습니다. MCP는 이런 기능이 2025년 11월에야 일부 추가됐습니다.

▲ 목차로 돌아가기

A2A 없이 MCP만으로 버틸 수 있을까? 현실적인 답변

실제로 에이전트 하나만 운영한다면 MCP만으로 충분합니다. 외부 DB에 접속하고, 웹 검색을 하고, 파일을 읽고 쓰는 모든 작업을 MCP 서버와 연결해 처리할 수 있습니다. 문제는 에이전트가 여러 개일 때입니다. 채용 에이전트, 일정 예약 에이전트, 배경조사 에이전트가 협업해야 한다고 가정해봅니다. MCP로는 이 에이전트들이 서로를 발견하거나 태스크를 위임할 방법이 없습니다.

반대로 A2A만 쓰면 어떻게 될까요? A2A 공식 문서는 이 질문에 직접 답합니다. “A2A는 에이전트 간 통신을 다룬다. 에이전트가 실제로 일을 하려면 MCP 같은 도구 접근 프로토콜이 여전히 필요하다.” A2A만으로 서로 완벽하게 통신하는 에이전트들이 있어도, 외부 데이터베이스를 못 읽고, API를 못 부르고, 파일을 못 씁니다. 인터콤은 완벽하지만 각 부서에 장비가 아예 없는 건물과 같습니다.

정리하면, 에이전트 하나가 외부 툴을 쓸 때는 MCP, 에이전트 여러 개가 협업할 때는 A2A+MCP를 같이 씁니다. 선택이 아니라 레이어의 문제입니다.

▲ 목차로 돌아가기

공식 발표문과 실제 채택 속도 사이에 벌어진 격차

MCP는 2024년 11월 출시 후 14개월 만에 Claude, ChatGPT, Copilot, Gemini 모두 네이티브 지원을 시작했습니다. 2025년 3월 OpenAI가 합류한 것이 사실상 변곡점이었습니다. 커뮤니티가 만든 MCP 서버 수는 수천 개에 달합니다. (출처: a2a-protocol.org 공식 문서에서 MCP 생태계 규모 언급)

반면 A2A는 기업 파트너 100개 이상을 확보했지만 개발자 개인 단위의 채택 속도는 MCP보다 느립니다. 이유는 단순합니다. 대부분의 팀이 아직 “여러 에이전트가 서로를 발견하고 위임해야 하는” 단계에 도달하지 않았기 때문입니다. 단일 에이전트 혹은 한 코드베이스 안에서 돌아가는 멀티에이전트라면 A2A가 현재 크리티컬 패스에 있지 않습니다.

Tyson Foods 공급망 자동화, SAP Joule 연동 같은 실제 엔터프라이즈 사례에서는 A2A가 작동합니다. 규모가 진짜 문제가 된 팀에게는 A2A가 대기 중입니다. 지금 당장 필요하지 않아도 알아둬야 하는 이유가 바로 여기에 있습니다.

▲ 목차로 돌아가기

A2A 보안이 탄탄하다는 말, 절반만 맞습니다

A2A는 설계 원칙 중 하나로 “Secure by default(보안 기본값)”을 내세웁니다. HTTPS 기반 통신, OpenAPI 인증 호환, 에이전트 카드 서명(v0.3부터)이 포함됩니다. 그런데 막상 보안 연구자들의 분석을 보면 얘기가 달라집니다.

실제로 확인된 주요 위협 3가지

이 세 가지 위협은 A2A가 나쁜 프로토콜이라는 뜻이 아닙니다. 표준 자체가 해결하지 않고 구현체에 맡긴 영역이 생각보다 넓다는 뜻입니다. 에이전트 카드를 신뢰할 때는 서명 검증을 직접 구현해야 하고, 수신 태스크는 웹 애플리케이션 입력처럼 항상 의심하고 검증해야 합니다.

▲ 목차로 돌아가기

ACP·ANP까지 등장, 2026년 에이전트 프로토콜 지형도

지금 프로덕션에서 선택해야 한다면 MCP와 A2A 두 가지만 고려하면 됩니다. ACP는 구 아키텍처 문서에서 마주칠 수 있는 레거시 참고 항목으로 이해하면 충분합니다. ANP는 탈중앙화 방향이라 매력적이지만 아직 쌓인 사례가 없습니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며

MCP vs A2A 논쟁은 사실 논쟁이 아닙니다. 둘은 다른 레이어를 다루고, 둘 다 필요합니다. 지금 당장 A2A가 필요하지 않은 팀이 많다는 것도 사실입니다. 단일 에이전트나 한 코드베이스 멀티에이전트라면 MCP부터 제대로 쌓는 게 맞습니다.

그러나 분명한 건 있습니다. AI 에이전트 시스템이 기업 플랫폼을 넘나들며 협업해야 하는 시대가 오고 있고, 그때 A2A는 선택이 아닌 기반 인프라가 됩니다. 지금 채택 속도가 느린 건 팀들이 아직 그 단계에 도달하지 않았기 때문이지, A2A가 틀렸기 때문이 아닙니다. 막상 필요해졌을 때 처음 보는 것과 미리 아는 것은 속도에서 차이가 납니다.

그리고 보안 부분은 꼭 기억해두세요. 프로토콜 자체의 설계가 어떻든, 에이전트 카드 검증과 수신 태스크 필터링은 직접 구현해야 합니다. “Secure by default”가 “알아서 다 막아준다”는 뜻이 아닙니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. Google Developers Blog — “A new era of Agent Interoperability” (2025.04.09)
2. A2A Protocol 공식 문서 (a2a-protocol.org)
3. IBM Think — “What is the Agent2Agent (A2A) protocol?”
4. Cloud Security Alliance — “Threat Modeling Google’s A2A Protocol with the MAESTRO Framework” (2025.04.30)
5. Anthropic — Model Context Protocol 공식 발표 (2024.11)