A2A: 에이전트 간 통신의 표준

TL;DR. A2A(Agent2Agent)는 에이전트 간 통신의 표준이다. MCP가 에이전트↔도구·데이터를 표준화했다면, A2A는 에이전트↔에이전트를 표준화한다 — 둘은 경쟁이 아니라 한 생태계의 두 축이다. Google이 2025년 4월 발표, 2025년 6월 23일 Linux Foundation으로 이관(AWS·Cisco·Microsoft·Salesforce·SAP·ServiceNow 공동, 100여 사 지지). 프레임워크가 다른 에이전트들이 서로를 발견하고 위임·협업하는 문제를, Agent Card·Task·Message·Artifact로 JSON-RPC 위에서 푼다.

A2A

A2A는 서로 다른 플랫폼·벤더·프레임워크 위에서 만들어진 AI 에이전트가 통신·협업하도록 표준화한 오픈 프로토콜이다. Google이 2025년 4월 발표했고, 2025년 6월 23일 Open Source Summit North America에서 Linux Foundation 산하 Agent2Agent 프로젝트로 이관됐다 — Google이 스펙·SDK·툴링을 통째로 기증하고, AWS·Cisco·Microsoft·Salesforce·SAP·ServiceNow가 창립 파트너로 들어갔다. 100여 사가 지지하며 벤더 중립으로 운영된다. MCP와 같은 길(Linux Foundation 거버넌스)을, 한 층 위(에이전트 간)에서 걷는다.

A2A가 해결하고자 하는 문제

MCP가 푼 문제가 에이전트↔도구의 M×N 폭증이었다면, A2A가 푸는 문제는 에이전트↔에이전트의 단절이다. LangGraph로 짠 에이전트, CrewAI로 짠 에이전트, Semantic Kernel로 짠 에이전트가 서로 일을 넘기려면 — 표준이 없으면 매번 둘 사이를 직접 붙여야 한다. 구체적으로 셋이 표준화되어 있지 않았다.

1. 발견(discovery) — 다른 에이전트가 무엇을 할 수 있는지·어디로 말을 거는지를 일관되게 알 방법이 없었다. 에이전트마다 자체 API를 직접 읽어야 했다.
2. 위임·장기 작업 — 한 에이전트가 다른 에이전트에 일을 맡기고 그 진행을 추적하는 표준 단위가 없었다. 즉답이 아니라 몇 분~몇 시간 걸리는 협업을 담을 그릇이 없었다.
3. 경계를 넘는 신뢰 — 서로 내부를 공유하지 않고도 안전하게 주고받는 인증·통신 규약이 조직·벤더 경계에서 표준화돼 있지 않았다.

구성 요소

A2A는 다음으로 이루어진다.

1. 행위자. *A2A Client(클라이언트 에이전트)*가 사용자를 대신해 통신을 개시하고, *A2A Server(원격 에이전트)*가 A2A를 구현한 HTTP 엔드포인트를 노출한다. 서버는 클라이언트에게 불투명한 블랙박스 — 내부 구현을 드러내지 않는다.

2. Agent Card. 에이전트의 디지털 명함인 JSON 메타데이터. 정체성·서비스 엔드포인트 URL·A2A 능력·인증 요구사항·스킬 목록을 담는다. 클라이언트는 이것만 보고 어디로·어떻게·어떤 인증으로 말을 걸지 정한다 — 발견의 입구다.

3. 작업 단위.

contextId가 여러 Task를 한 맥락으로 묶는다.

4. 전송. JSON-RPC 2.0 over HTTP(S). 세 가지 상호작용 — 요청/응답(폴링), *스트리밍(SSE)*으로 실시간 증분 수신, 그리고 매우 긴 작업엔 푸시 알림(클라이언트 웹훅). 인증은 표준 웹 보안 — 자격증명을 HTTP 헤더로 싣고 A2A 메시지 본문과 분리한다.

구성 요소가 어떻게 문제를 해결하는가

flowchart LR
    CA["클라이언트 에이전트<br/>(A2A Client)"]
    AC["Agent Card<br/>(발견·인증)"]
    RA["원격 에이전트<br/>(A2A Server · 블랙박스)"]

    CA -->|"① Agent Card 조회"| AC
    AC -->|"능력·엔드포인트·인증"| CA
    CA <-->|"② JSON-RPC 2.0<br/>Task · Message · Artifact"| RA

    classDef box fill:#161821,stroke:#2a2d38,color:#e7e9ec;
    class CA,AC,RA box;

• 발견 → Agent Card. 능력·엔드포인트·인증을 한 장의 표준 메타데이터로 노출한다. 클라이언트는 내부를 몰라도 무엇을 시킬 수 있는지를 읽는다. (MCP의 tools/list가 도구 카탈로그를 반환하는 그 자리를, A2A는 에이전트 카탈로그로 올린다.)
• 위임·장기 작업 → Task. 즉답이 아니라 상태 있는 Task로 응답하므로, 위임한 일이 몇 시간 걸려도 폴링·SSE·푸시로 추적된다. Artifact가 증분 스트리밍되어 결과를 흐름으로 받는다.
• 경계를 넘는 신뢰 → 블랙박스 + 분리된 인증. 서버가 불투명하다는 게 핵심 설계다 — 내부를 공유하지 않고 입력·출력만 주고받는다. 인증을 메시지 본문과 분리해 표준 웹 보안에 얹는다. 조직·벤더가 달라도 같은 규약으로 닿는다.

MCP와의 차이

MCP 글을 읽었다면 떠오를 질문 — A2A와 MCP는 경쟁인가? 아니다. 단위가 다르다. MCP는 에이전트가 도구·데이터에 닿게 하고, A2A는 에이전트가 다른 에이전트에 닿게 한다.

한 줄로 — MCP는 에이전트에게 손발을, A2A는 동료를 준다. 둘이 합쳐 도구를 쓰는 에이전트들이 서로 협업하는 생태계가 완성된다. agent-governance가 레지스트리에서 MCP 서버와 A2A AgentCard를 나란히 1급 레코드로 다루는 게 이 상보성의 운영 증거다.

설계상 어디서 부딪치는가

직접 운영해 본 관찰이 아니라, 스펙을 읽고 구조적으로 필연인 마찰만 짚는다.

1. Agent Card가 곧 신뢰의 근거다. 클라이언트가 능력·인증을 카드 한 장으로 판단하므로, 카드의 진위·발견 경로가 검증되지 않으면 스푸핑된 에이전트에 위임이 갈 수 있다 — 발견 표준이 곧 공격면이다.
2. 블랙박스는 내부 검증을 막는다. 원격 에이전트가 불투명하다는 장점(내부 비공개)이, 그 에이전트가 무엇을 했는지를 클라이언트가 들여다볼 수 없다는 한계와 같은 동전이다. 감사·디버깅은 Artifact·Task 상태라는 밖에서 보이는 것에 갇힌다.
3. 원격 응답이 곧 컨텍스트로 흐른다. 다른 에이전트의 Message·Artifact가 클라이언트 모델 컨텍스트로 들어오므로, MCP 도구 응답과 같은 인젝션 벡터가 에이전트 간에서도 그대로 선다 — 신뢰 경계를 툴콜 와이어에 둔 그 논리가 A2A 응답에도 필요하다.
4. 장기 Task의 상태 정합성. 폴링·SSE·푸시 세 경로가 같은 Task 상태를 보고하는데, 경로마다 도달·재시도 보장이 다르면 상태가 갈린다. 매우 긴 작업일수록 누락·중복이 누적된다.

종합

A2A는 MCP의 짝이다. MCP가 연결 가능성(에이전트↔도구)을 풀었듯, A2A는 상호운용성(에이전트↔에이전트)을 푼다 — 같은 Linux Foundation 트랙, 같은 JSON-RPC·메타데이터 발견 패턴. 프로토콜이 흔들릴 가능성은 양대 클라우드·모델사 동시 지지로 사실상 제거됐다. 남는 문제는 MCP와 동일 — 프로토콜이 아니라 그 위의 운영(신뢰·감사·인젝션 경계)이고, 그 운영은 agent-governance가 따로 다룬다.

참고

• a2a-protocol.org — 공식 스펙·Key Concepts
• Linux Foundation Launches the Agent2Agent Protocol Project (2025-06-23)
• Google Cloud donates A2A to Linux Foundation (Google Developers Blog)
• Google donates Agent2Agent Protocol to the Linux Foundation (SiliconANGLE, 2025-06-24)
• MCP: 에이전트 통신의 표준 — 짝이 되는 도구 연결 표준