에이전트끼리 대화하는 A2A, MCP와 한 재단에 모였지만 실사용은 아직

Agentic AI Foundation(AAIF)이 2026년 8월 17일 Agent2Agent(A2A) 프로토콜을 growth-stage 프로젝트로 받아들였다고 발표했습니다. A2A는 Google이 2025년 4월에 공개한 규격으로, 서로 다른 회사가 만든 AI 에이전트끼리 직접 말을 주고받게 해주는 약속입니다. 이번 발표로 A2A는 Anthropic이 만든 MCP, Block의 goose, OpenAI의 AGENTS.md와 같은 재단 아래 놓였습니다.

발표 자체는 짧습니다. A2A의 코드도, 사양도, 이미 돌고 있는 배포도 그대로입니다. 바뀐 것은 이 프로젝트를 누가 관리하느냐 한 줄입니다. 그런데 이 한 줄이 의미가 있는 이유와, 이 한 줄이 못 고치는 것을 나눠 볼 필요가 있습니다.

MCP는 도구를 붙이고 A2A는 에이전트를 붙입니다

두 프로토콜이 겹친다고 오해하기 쉬운데, 맡은 자리가 다릅니다. MCP는 에이전트 하나가 바깥의 도구와 데이터에 닿게 해주는 규격입니다. Claude가 Notion이나 GitHub를 읽는 그 통로가 MCP입니다. A2A는 에이전트가 다른 회사, 다른 프레임워크에서 돌고 있는 에이전트에게 일을 넘길 때 쓰는 규격입니다.

도식에서 세로선이 조직 또는 기술 경계입니다. 선 아래쪽 점선이 MCP이고, 선을 가로지르는 점선이 A2A입니다. 우리 팀 에이전트가 협력사 에이전트에게 "이 청구서 검증해줘"라고 넘기는 상황이 A2A가 겨냥하는 지점입니다.

A2A는 2026년 3월 12일에 v1.0.0 안정 사양에 도달했습니다. 데이터 모델은 AgentCard, AgentSkill, Task, Message, Part, Artifact, Extension으로 구성됩니다. Protocol Buffers로 명세한 뒤 JSON Schema 2020-12로 발행합니다. 전송은 일반 HTTP와 JSON-RPC 2.0 시맨틱이 기본입니다. 결과를 실시간으로 흘려보낼 때는 WebSocket과 Server-Sent Events를 씁니다. 여기서 AgentCard가 A2A의 출발점인데, 에이전트가 자기 이름과 할 수 있는 일, 접속 주소를 적어 공개하는 명함 같은 파일입니다. 상대 에이전트는 이 명함을 읽고 일을 맡길지 판단합니다.

재단은 옮겼는데 의사결정 구조는 그대로입니다

이번 이동을 "Google이 A2A를 내놓았다"로 읽으면 순서가 틀립니다. Google Cloud는 이미 2025년 6월 23일 Open Source Summit North America에서 A2A를 Linux Foundation에 기증했습니다. 그때부터 A2A는 Linux Foundation 소속이었습니다. 다만 재단 최상위 레벨에 그냥 놓여 있었을 뿐입니다. 반면 MCP는 2025년 12월 AAIF가 출범할 때 곧바로 AAIF 프로젝트가 됐습니다. 이번 발표는 새 기증이 아니라 같은 Linux Foundation 안에서 A2A를 MCP 옆자리로 옮긴 정리 작업입니다.

AAIF는 Governing Board가 전략과 예산, 멤버십 정책을 맡고 Technical Committee가 프로젝트 승인과 기술 검토를 맡는 2층 구조입니다. 재단 규모는 2025년 12월 출범 당시 40곳 미만에서 지금 250곳 이상으로 늘었습니다. Google, Microsoft, Amazon, Anthropic, OpenAI, Bloomberg, Shopify, Block, Cisco가 들어와 있습니다. AAIF CTO Manik Surtani는 발표문에서 "A2A는 AI 에이전트의 개방적이고 상호운용 가능한 미래를 향한 중요한 한 걸음"이라고 밝혔습니다.

다만 A2A 저장소의 거버넌스 문서를 직접 열어 보면 바뀐 것이 없습니다. GitHub a2aproject/A2A의 GOVERNANCE.md는 여전히 8석짜리 Technical Steering Committee 구조를 그대로 기술합니다. 의석은 Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP, IBM이 하나씩 나눠 갖습니다. 문서에 AAIF 언급은 아직 없습니다. 이 문서는 startup phase 동안 각 조직이 투표 멤버 1명을 지명한다고 적어 뒀습니다. "steady state" 구성은 출범 18개월 뒤 TSC가 정한 방식으로 결정합니다. 발표 시점 기준으로 A2A의 기술 결정권은 여전히 이 8곳에 있습니다. 재단 이름표가 바뀐 것과 누가 사양을 고칠지는 별개입니다.

AAIF는 MCP를 스테이트리스 구조로 개정한 2026-07-28 사양을 통과시킨 재단이기도 합니다. 앞으로 두 프로토콜의 개정안이 같은 Technical Committee를 거칩니다. 이것이 이번 이동의 실질적 결과입니다. 경쟁하던 기업들이 하나의 재단에 모인 배경은 따로 정리한 적이 있습니다.

지지 250곳과 프로덕션 사이의 거리

AAIF 발표문은 A2A의 실제 배포 사례를 몇 개 들었습니다. Huawei HarmonyOS가 A2A를 표준으로 채택했습니다. Tencent WeChat은 단말 제조사 어시스턴트와 연동하는 데 씁니다. Google Cloud와 Microsoft Azure, AWS Bedrock도 A2A 에이전트를 지원합니다. Linux Foundation 집계로 2026년 4월 9일에 지지 조직 150곳을 넘겼습니다.

그런데 이 숫자를 채택률로 읽으면 안 됩니다. "지원한다"는 로고를 올린 것부터 실제 프로덕션 운영까지 편차가 큽니다. MCP는 2026년 중반 기준 공개 서버가 수천 개이고 Claude Desktop, Cursor, Windsurf 같은 도구를 통해 개발자가 얼마나 쓰는지 셀 수 있습니다. A2A에는 지지 조직 수와 GitHub 스타가 있습니다. 몇 팀이 실제로 프로덕션에서 돌리는지를 셀 지표는 없습니다.

개발자 쪽 불만도 구체적입니다. A2A를 도입하면 프로토콜 두 개와 둘 사이 호환성, 그리고 A2A 전용 통신 계층까지 함께 관리해야 합니다. MCP는 Claude를 Notion, Jira, GitHub에 10분 안에 연결시켰지만 A2A는 에이전트 오케스트레이션 개념을 며칠 배운 뒤 통신 계층을 직접 만들어야 한다는 지적이 올해 내내 나왔습니다. MCP가 이미 장기 실행 작업, 상태 유지 통신, 기업급 보안, 에이전트 발견을 지원한다는 점도 A2A의 차별점을 좁혔습니다. "A2A 데모 상당수가 함수 호출 세 개면 되는 일을 에이전트 세 개로 한다"는 비판이 대표적입니다.

재단 합류는 이 격차를 직접 건드리지 않습니다. 중립 거버넌스는 특정 회사가 사양을 자기 제품에 유리하게 틀 위험을 줄여 주는 장치이지, 도입 비용을 낮춰 주는 장치가 아닙니다.

지금 쓸 수 있나

A2A는 조건이 거의 없습니다. 계정 승인이나 대기자 명단이 없고 가격도 없습니다.

로드맵에는 A2A Inspector와 Technology Compatibility Kit이 앞으로 3개월에서 6개월 사이 항목으로 올라 있습니다. 둘 다 내가 만든 에이전트가 사양을 제대로 지키는지 검사해 주는 도구입니다. 로드맵 문서 자체는 2026년 3월 10일 이후 갱신되지 않았습니다.

여러 프레임워크로 만든 에이전트를 실제로 연결해야 하는 팀이라면, 이번 주에 할 만한 일은 A2A 도입 여부를 결정하는 것이 아니라 지금 MCP만으로 안 되는 지점이 있는지 먼저 적어 보는 것입니다. 조직 경계를 넘어 다른 회사 에이전트에게 일을 넘기는 시나리오가 목록에 없다면 A2A는 아직 필요 없습니다. 목록에 있다면 a2a-sdk로 AgentCard 하나만 띄워 상대 쪽에서 읽히는지 확인해 보면 며칠짜리 학습 비용을 들이기 전에 판단이 섭니다. 재단 소속이 바뀐 것을 도입 신호로 읽을 필요는 없습니다. 다시 볼 시점은 TCK가 실제로 나오는 때입니다. 그때는 "지원한다"고 이름을 올린 150곳 중 몇 곳이 호환성 검사를 통과하는지 셀 수 있습니다.