A2A protocol

이 문서는 자라는 중인 질문입니다. 아직 증거를 모으고 있으며, 내용이 바뀔 수 있습니다.

A2A protocol은 에이전트가 많아질수록 생기는 아주 현실적인 문제를 건드려. 한 회사가 만든 에이전트가 다른 회사가 만든 에이전트에게 일을 맡기고, 진행 상태를 묻고, 결과물을 받아야 한다면 둘 사이에 공통 언어가 필요해. A2A는 그 공통 언어를 만들려는 시도야.

중요한 점은 “에이전트를 더 똑똑하게 만드는 기술”이 아니라는 거야. A2A는 모델의 추론 방식이나 도구 호출 전략을 정하지 않아. 대신 서로 다른 프레임워크와 플랫폼 위에 있는 에이전트들이 상대를 발견하고, 요청을 보내고, 긴 작업의 상태를 따라가고, 결과물을 주고받는 통신층에 가까워.

한 줄로 말하면

A2A protocol은 독립적으로 만들어진 AI 에이전트들이 서로를 발견하고, 작업을 위임하고, 상태와 결과를 주고받기 위한 공개 agent-to-agent 통신 표준이야.

무엇인가

A2A 공식 문서는 이 프로토콜을 서로 다른 프레임워크와 벤더가 만든 AI 에이전트 사이의 통신과 협업을 위한 open standard로 설명해. Google이 2025년 4월 발표했고, 현재 공식 사이트는 Linux Foundation 저작권과 Agent2Agent project 문서를 중심으로 운영돼.¹²

구조를 아주 단순하게 보면 세 주체가 있어. 사용자가 목표를 내고, A2A client가 그 목표를 들고 다른 에이전트에게 요청을 보내. A2A server는 HTTP endpoint를 열어 둔 remote agent나 agentic system이고, 내부 memory·tool·구현을 그대로 드러내지 않은 채 요청을 처리해.³

그 사이를 이어 주는 핵심 물건이 Agent Card, Task, Message, Part, Artifact야. Agent Card는 에이전트의 신원, 기능, endpoint, 인증 요구사항을 담은 JSON metadata야. Task는 상태를 가진 작업 단위고, Message는 한 번의 대화나 지시야. Part는 text, file, structured data 같은 내용을 담는 작은 단위고, Artifact는 remote agent가 만든 실제 산출물이야.³

왜 계속 등장하는가

에이전트 생태계는 이미 한 회사 안에서도 여러 층으로 갈라져. LangGraph 같은 runtime이 있고, OpenAI Agents SDK나 Claude Agent SDK 같은 framework가 있고, Microsoft Foundry 같은 기업용 실행·거버넌스 계층이 있어. 이들이 전부 자기 방식으로만 말하면 multi-agent collaboration은 플랫폼별 섬으로 쪼개져.

A2A가 반복해서 등장하는 이유는 이 섬을 잇는 문제를 겨냥하기 때문이야. 공식 문서는 A2A가 LangGraph, CrewAI, Semantic Kernel, custom solution처럼 서로 다른 플랫폼의 에이전트를 연결해 composite AI system을 만들 수 있게 한다고 설명해.¹

여기서 Model Context Protocol과의 차이가 중요해. MCP는 agent가 tool, API, resource에 접근하는 방법을 표준화하는 쪽이야. A2A는 agent와 agent 사이에서 discovery, task delegation, result sharing을 다루는 쪽이야. 그래서 둘은 경쟁 관계라기보다, 하나는 agent-to-tool edge, 다른 하나는 agent-to-agent edge를 맡는 관계에 가까워.⁴

이 대상을 볼 때의 핵심 축

첫 번째 축은 발견 가능성이야. 에이전트가 무엇을 할 수 있고 어디로 요청해야 하는지 알 수 있어야 협업이 시작돼. Agent Card가 중요한 이유가 여기에 있어.

두 번째 축은 작업 상태야. 실제 업무는 한 번의 응답으로 끝나지 않을 수 있어. A2A는 Task를 상태 있는 작업 단위로 두고, polling, Server-Sent Events streaming, webhook 기반 notification 같은 방식으로 긴 작업의 진행을 따라갈 수 있게 설계돼.³

세 번째 축은 내부 불투명성이야. remote agent는 자기 memory, tool, proprietary logic을 다 공개하지 않아도 돼. 이 점은 기업 간 협업에서는 장점이지만, 동시에 상대 에이전트의 능력과 신뢰도를 어떻게 확인할지라는 문제를 남겨.

네 번째 축은 보안과 권한이야. A2A 메시지 자체만 보면 통신 형식이지만, 실제 배포에서는 누가 어떤 에이전트에 요청할 수 있는지, 인증 토큰이 어디서 오가는지, 긴 작업 중 추가 권한 요청을 어떻게 처리하는지가 핵심이 돼. 공식 core concepts 문서는 인증 요구사항을 Agent Card에 선언하고, credentials는 보통 HTTP header를 통해 전달한다고 설명해.³

flowchart TD
    A["사용자 목표"] --> B["A2A Client"]
    B --> C["Agent Card 발견"]
    C --> D["Remote Agent 선택"]
    D --> E["Task 요청"]
    E --> F{"작업 진행"}
    F -->|"상태 갱신"| B
    F -->|"추가 입력 필요"| A
    F -->|"완료"| G["Artifact 또는 Message"]
    G --> B

최근 관찰된 신호

A2A는 2025년 4월 Google 발표 때부터 enterprise multi-agent workflow를 전면에 세웠어. 발표문은 50개가 넘는 technology partner와 service provider를 언급했고, A2A가 HTTP, SSE, JSON-RPC 같은 기존 표준 위에 올라가며 long-running task와 다양한 modality를 고려한다고 설명했어.²

2026년 현재 공식 문서는 v1.0 specification, SDK, tutorial, extension governance, partner 목록까지 갖춘 형태로 정리돼 있어. 이건 단순한 블로그 제안에서 개발자가 따라 구현할 수 있는 표준 문서 체계로 이동했다는 신호야.¹⁵

다만 실제 채택 강도는 아직 따로 봐야 해. 파트너 로고와 지원 의사만으로는 부족해. 어떤 제품이 A2A endpoint를 열었는지, Agent Card가 실제 discovery에 쓰이는지, 인증과 감사 로그가 기업 환경에서 어떻게 붙는지를 확인해야 해.

헷갈리지 말아야 할 점

A2A는 agent framework가 아니야. LangGraph처럼 실행 그래프를 짜거나, 특정 SDK처럼 tool call과 handoff를 구현하는 개발 도구가 아니야. 공식 문서도 A2A가 agent development kit도, sub-agent나 tool-call protocol도 아니라고 선을 그어.¹

또 MCP의 대체물도 아니야. MCP는 agent가 tool과 data source에 접근하는 길이고, A2A는 독립 agent들이 서로 일을 주고받는 길이야. 한 agent가 MCP로 GitHub나 database에 접근하고, A2A로 다른 전문 agent에게 일을 위임하는 식으로 같이 놓일 수 있어.

마지막으로, 공통 프로토콜이 곧 신뢰를 보장하지는 않아. Agent Card가 능력을 설명한다고 해서 그 능력이 항상 정확하다는 뜻은 아니야. 앞으로 A2A를 읽을 때는 “연결이 되는가”와 “연결된 상대를 믿을 수 있는가”를 나눠 봐야 해.

이어서 읽기

에이전트가 업무 흐름 안에서 어디까지 움직일 수 있는지 큰 그림을 보려면 agentic workflow를 먼저 보면 돼. 여러 에이전트가 역할을 나눠 일하는 구조는 multi-agent collaboration에서 이어서 볼 수 있어.

A2A와 자주 같이 언급되는 tool 접근 표준은 Model Context Protocol이야. 에이전트 실행 상태와 graph runtime 쪽은 LangGraph가 좋은 비교점이 돼.

남은 질문들

• A2A v1.0 이후 breaking change와 version negotiation은 실제 배포에서 어떻게 관리될까?
• Agent Card는 공개 discovery 문서로 충분할까, 아니면 enterprise registry와 서명·검증 계층이 사실상 필요해질까?
• Microsoft, AWS, Salesforce, SAP, ServiceNow 같은 파트너는 A2A를 제품 어디에 어느 수준으로 붙이고 있을까?
• A2A로 연결된 remote agent의 품질, 권한, 감사 기록은 누가 책임질까?

각주

1. Agent2Agent project, 「A2A Protocol」(2026-07-13 확인) 공식 문서 ↩︎ ↩︎² ↩︎³ ↩︎⁴

2. Google Developers Blog, 「Announcing the Agent2Agent Protocol (A2A)」(2025-04-09) 공식 발표 ↩︎ ↩︎²

3. Agent2Agent project, 「Core Concepts and Components in A2A」(2026-07-13 확인) 공식 문서 ↩︎ ↩︎² ↩︎³ ↩︎⁴

4. Agent2Agent project, 「A2A and MCP」(2026-07-13 확인) 공식 문서 ↩︎

5. Agent2Agent project, 「A2A Protocol Specification」(2026-07-13 확인) 공식 specification ↩︎