개방형 표준을 통해 어떤 프레임워크에서든 AI 에이전트들이 서로를 발견하고, 업무를 위임하며, 안전하게 협업할 수 있습니다. 이것이 무엇인지, 어떻게 작동하는지, 그리고 왜 중요한지에 대해 알아봅니다.

A2A (Agent2Agent)는 에이전트 간 통신을 위한 개방형 프로토콜입니다. 이는 독립적인 AI 에이전트들이 어떤 프레임워크나 벤더에 의해 구축되었는지에 관계없이 서로를 발견하고, 작업을 위임하며, 결과를 안전하게 교환할 수 있도록 합니다.

이 프로토콜은 2025년 4월 Google에 의해 도입되었으며, Linux Foundation에 기여되었고, 핵심 데이터 모델이 확정된 안정적인 1.0 릴리스에 도달했습니다. 공식 SDK는 Python, JavaScript, Java, Go, .NET용으로 제공됩니다.

내부적으로는 이미 알고 있는 표준들을 재사용합니다: 전송을 위한 HTTP, 요청을 위한 JSON-RPC 2.0, 스트리밍을 위한 Server-Sent Events, 그리고 인증을 위한 OAuth 2.0입니다. A2A는 프레임워크가 아닙니다. 에이전트 사이에서 메시징 레이어 (messaging layer) 역할을 수행하므로, 기존 스택을 그대로 유지할 수 있습니다.

이 프로토콜이 해결하고자 하는 문제

여러분은 아마도 한 가지 일을 잘 수행하는 AI 에이전트를 구축했거나 사용해 본 적이 있을 것입니다. 고객 서비스 에이전트는 질문에 답합니다. 리서치 에이전트는 자료를 수집합니다. 스케줄링 에이전트는 회의를 예약합니다. 각각은 단독으로 능력이 있지만, 각자의 플랫폼 안에 갇혀 있습니다.

리서치 에이전트는 글쓰기 에이전트에게 리서치가 완료되었다고 말할 수 없습니다. 지원 에이전트는 환불 처리를 결제 에이전트에게 넘길 수 없습니다. 에이전트들은 개별적으로는 똑똑하지만, 집단적으로는 침묵하고 있습니다.

이유는 간단합니다. 공유된 언어가 없었기 때문입니다. 모든 에이전트 프레임워크는 작업, 메시지, 결과를 표현하는 자신만의 방식을 만들어냈습니다. 서로 다른 프레임워크로 구축된 두 에이전트를 연결하려면 매 쌍마다 맞춤형 글루 코드 (glue code)를 작성해야 했으며, 이는 어느 한 쪽이 변경될 때마다 깨지는 취약한 통합 방식이었습니다.

이는 확장 가능하지 않습니다. 수십 개의 팀이 만든 수십 개의 에이전트로 이를 확장하면 통합 부담은 기하급수적으로 증가합니다. 병목 현상은 에이전트가 아니라, 에이전트 간의 연결입니다.

A2A가 웹에서 빌려온 교훈

우리는 이와 같은 형태의 문제를 이전에 해결한 적이 있습니다. 웹이 확장될 수 있었던 것은 모든 서버가 각자의 사적인 방언을 사용했기 때문이 아니라, HTTP가 모든 서버와 클라이언트에게 프레임워크에 구애받지 않는(framework-agnostic) 공통의 계약을 제공했기 때문입니다. 브라우저와 웹 서버 모두 구현(implementation)이 아닌 프로토콜(protocol)에 동의하기 때문에, 어떤 브라우저라도 어떤 웹 서버든 가리킬 수 있습니다.

A2A는 동일한 아이디어를 에이전트(agent)에 적용합니다. 즉, 어떤 프레임워크로 구축된 에이전트라도 자신의 내부 구조를 드러내지 않고 다른 프레임워크로 구축된 에이전트와 통신할 수 있도록 하는 얇고 공유된 프로토콜(thin, shared protocol)입니다.

A2A는 웹 서비스에 있어 HTTP가 그러하듯, AI 에이전트에게 있어 그러합니다. 공통의 구현이 아닌, 공통의 프로토콜입니다.

프로토콜이 실제로 표준화하는 것

A2A의 핵심은 한 에이전트(클라이언트, client)가 다른 에이전트(원격 에이전트, remote agent)에게 작업을 요청하는 방식과 결과가 어떻게 다시 돌아오는지(flow back)를 정의하는 것입니다. A2A는 모든 협업에 필요한 네 가지 요소를 표준화합니다:

• 발견 (Discovery) — 에이전트가 자신이 누구인지, 무엇을 할 수 있는지 광고하여 다른 에이전트가 이를 찾고 평가할 수 있게 하는 방법.
• 작업 위임 (Task delegation) — 클라이언트가 작업 단위를 제출하고, 완료될 때까지 그 진행 상황을 추적하는 방법.
• 통신 (Communication) — 작업 중에 두 에이전트가 메시지와 구조화된 결과(structured results)를 교환하는 방법.
• 보안 (Security) — 에이전트가 자격 증명(credentials)을 공유하지 않고 서로를 인증(authenticate)하고 접근 권한을 부여(authorize)하는 방법.

나중에 혼란을 방지하기 위한 한 가지 명확한 설명은 다음과 같습니다: 클라이언트와 원격 에이전트는 유형(type)이 아니라 역할(role)입니다. 동일한 에이전트라도 작업을 위임할 때는 클라이언트가 될 수 있고, 작업을 받을 때는 원격 에이전트가 될 수 있습니다. 멀티 에이전트 시스템(multi-agent system)에서 에이전트들은 누가 누구에게 요청하느냐에 따라 끊임없이 역할을 전환합니다.

다섯 가지 구성 요소

A2A의 거의 모든 것은 다섯 가지 개념으로부터 조립됩니다. 이 개념들을 이해하면 나머지 프로토콜은 마치 평이한 영어 문장처럼 읽힐 것입니다.

1. 에이전트 카드 (The Agent Card)

에이전트를 설명하는 JSON 문서입니다. 에이전트의 정체성, 접속 위치, 인증 방법, 그리고 가장 중요한 요소인 — 기술(skills) 목록으로 표현된 — 무엇을 할 수 있는지를 기술합니다. 관례적으로 이는 잘 알려진 경로(well-known path)에 위치하여 어떤 클라이언트라도 이를 찾을 수 있습니다:

curl https://agent.example.com/.well-known/agent-card.json

2. Task (태스크)

작업의 핵심 단위입니다. 클라이언트가 원격 에이전트(remote agent)에게 무언가를 요청하면, 그 요청은 고유한 식별자(identifier)와 시작부터 끝까지 추적 가능한 생명주기(lifecycle)를 가진 하나의 Task가 됩니다. Task는 상태를 가집니다(stateful). 즉, 정의된 상태들을 거치며, 오랜 시간 동안 실행될 수 있고, 진행 과정에서 업데이트를 스트리밍(stream)할 수 있습니다.

3. Message (메시지)

클라이언트와 원격 에이전트 사이의 단일 통신 차례(communication turn)를 의미합니다. 요청(request), 응답(reply), 확인 질문(clarifying question) 등이 이에 해당합니다. 각 Message는 역할(role)과 하나 이상의 Part(파트)를 포함합니다.

4. Parts (파트)

Message 내부의 타입이 지정된 콘텐츠(Typed content)입니다. 산문(prose)을 위한 text 파트, 문서나 이미지를 위한 file 파트, 구조화된 페이로드(structured payloads)를 위한 data 파트가 있습니다. 이러한 타입 지정 덕분에 에이전트들은 단순한 문자열 이상의 것을 교환할 수 있습니다.

5. Artifact (아티팩트)

완료된 Task가 생성하는 내구성이 있는 결과물(durable output)입니다. 보고서, 이미지, 데이터셋 등이 이에 해당합니다. Message가 대화라면, Artifact는 산출물(deliverables)입니다.

클라이언트는 에이전트의 카드(card)를 통해 에이전트를 발견하고, Task를 시작하기 위해 Message를 보내며, 작업이 진행됨에 따라 더 많은 Message를 교환하고, Task가 완료되면 Artifact를 받습니다. 다섯 개의 명사, 하나의 깔끔한 흐름입니다.

지루하지만 검증된 표준을 기반으로 구축됨

A2A는 내부적으로 의도적으로 화려함을 지양하며, 이는 하나의 특징(feature)입니다. A2A는 이미 인터넷을 구동하고 있는, 충분히 검증된(battle-tested) 표준들을 재사용합니다:

• 전송을 위한 HTTP(S).
• 구조화된 요청 및 에러를 위한 JSON-RPC 2.0.
• 실시간 Task 업데이트 스트리밍을 위한 Server-Sent Events (SSE).
• 인증을 위한 OAuth 2.0 및 JSON Web Tokens (JWT).

특별하거나 생소한 것은 없습니다. 웹 서비스(web service)를 구축해 본 경험이 있는 엔지니어라면 이미 이러한 기본 요소(primitives)를 알고 있으며, 그들이 이미 사용 중인 모든 디버깅 도구도 변경 없이 그대로 작동합니다. 이러한 보수적인 접근 방식은 이 프로토콜이 매우 빠르게 프로덕션 환경에 적용될 수 있었던 큰 이유 중 하나입니다.

누가 A2A를 관리하며, 그것이 왜 중요한가

A2A는 2025년 4월 Google에 의해 도입되었으며, 빠르게 특정 기업의 통제를 벗어났습니다. A2A는 Linux Foundation에 기여되었으며, 현재 Linux Foundation이 이를 벤더 중립적 표준 (vendor-neutral standard)으로 관리하고 있습니다.

이는 사소한 세부 사항이 아닙니다. 한 기업이 통제하는 프로토콜은 모든 경쟁사로 하여금 도입을 주저하게 만드는 이유가 되며, 생태계의 절반이 도입을 거부한다면 에이전트 상호운용성 (agent interoperability)은 가치가 없습니다. 중립적인 거버넌스 (governance)는 그러한 반대 의견을 제거했으며, 이것이 바로 현재 Microsoft Copilot Studio, Azure AI Foundry, Amazon Bedrock AgentCore, 그리고 Google ADK에서 동시에 A2A를 지원하는 이유입니다.

A2A는 핵심 데이터 모델 (data models)이 고정된 안정적인 1.0 버전으로 출시되었습니다. 새로운 기능은 파괴적 변경 (breaking changes)이 아닌 확장 기능 (extensions) 형태로 추가되므로, 여러분이 구축한 시스템은 그대로 유지됩니다.

A2A와 MCP의 관계

Model Context Protocol (MCP)을 알고 있다면, A2A를 그 옆에 배치하는 것이 가장 명확한 방법입니다. MCP는 에이전트를 도구 (tools), 데이터 (data), 그리고 컨텍스트 (context)에 연결합니다. 즉, "내 에이전트가 리소스를 어떻게 사용하는가?"라는 질문에 답합니다. 반면 A2A는 에이전트를 다른 에이전트에 연결합니다. 즉, "내 에이전트가 다른 에이전트와 어떻게 협업하는가?"라는 질문에 답합니다.

두 프로토콜은 경쟁 관계가 아닌 상호 보완적인 관계이며, 현재 모두 동일한 재단(foundation)의 관리하에 있습니다. 대부분의 진지한 시스템은 두 가지를 모두 사용합니다. 각 에이전트에게 능력을 부여하기 위해 MCP를 사용하고, 그 에이전트들이 협업할 수 있도록 A2A를 사용합니다.

MCP가 에이전트에게 손을 준다면, A2A는 동료를 줍니다.

A2A가 아닌 것

경계를 명확히 하는 것이 도움이 됩니다:

• 프레임워크 (framework)가 아닙. A2A는 LangGraph, CrewAI 또는 여러분이 사용하는 무엇인가를 대체하지 않습니다. A2A는 메시징 레이어 (messaging layer)로서 에이전트들 사이에 위치합니다.
• 모델 (model)이나 런타임 (runtime)이 아닙. A2A는 여러분의 에이전트가 어떻게 생각하는지 또는 무엇을 할 수 있는지를 결정하지 않습니다.
• MCP의 대체제가 아닙. 서로 다른 문제를 다루며, 공존하도록 설계되었습니다.
• 메시지 큐 (message queue)나 통합 버스 (integration bus)가 아닙. A2A는 한 에이전트가 다른 에이전트를 발견하고, 권한을 위임하며, 협업하기 위한 프로토콜로 엄격하게 정의됩니다.

A2A가 의도적으로 제외한 모든 것은 프레임워크, 모델, 또는 보조 프로토콜이 이미 더 잘 처리하고 있는 것들입니다. 그러한 절제가 A2A가 매우 깔끔하게 구성될 수 있는 이유입니다.

자주 묻는 질문 (Frequently asked questions)

Agent2Agent 프로토콜이란 무엇인가요?
A2A (Agent2Agent)는 에이전트 간 통신을 위한 개방형 프로토콜 (open protocol)입니다. 이를 통해 독립적인 AI 에이전트들이 어떤 프레임워크 (framework)나 벤더 (vendor)에 의해 구축되었는지와 관계없이, 서로를 발견하고, 작업을 위임하며, 결과를 안전하게 교환할 수 있습니다. 2025년 4월 Google에 의해 소개되었으며, Linux Foundation의 관리하에 안정적인 1.0 릴리스 (release)에 도달했습니다.

A2A는 누가 만들었으며 현재 누가 제어하나요?
Google이 2025년 4월에 A2A를 도입하였고 이를 Linux Foundation에 기여하였으며, 현재 Linux Foundation이 벤더 중립적인 개방형 표준 (open standard)으로서 이를 관리하고 있습니다. 단일 기업이 이를 제어하지 않습니다.

A2A는 프로덕션 환경에서 사용할 준비가 되었나요?
네. A2A는 핵심 데이터 모델 (data models)이 확정된 안정적인 1.0 릴리스에 도달했으며, Python, JavaScript, Java, Go, .NET용 공식 SDK를 제공합니다. 또한 Microsoft Copilot Studio, Azure AI Foundry, Amazon Bedrock AgentCore, Google ADK 내에서 지원됩니다.

A2A를 사용하기 위해 기존 에이전트를 다시 작성해야 하나요?
아니요. A2A는 프레임워크 (framework)가 아니라 에이전트 간의 메시징 레이어 (messaging layer)입니다. 도입한다는 것은 에이전트에게 에이전트 카드 (Agent Card)와 A2A 엔드포인트 (endpoint)를 부여하는 것을 의미합니다. 에이전트의 내부 구조, 모델 (model), 프레임워크 (framework)는 그대로 유지됩니다.

A2A와 MCP의 차이점은 무엇인가요?
MCP는 에이전트를 도구 (tools), 데이터 (data), 컨텍스트 (context)에 연결합니다. A2A는 에이전트들을 서로 연결합니다. MCP는 수직적 (vertical)이며, A2A는 수평적 (horizontal)입니다. 이들은 상호 보완적이며, 대부분의 프로덕션 시스템은 두 가지를 모두 사용합니다.

이 시리즈의 다른 글

• A2A vs MCP — A2A vs MCP: 모든 진지한 AI 에이전트 시스템 뒤에 있는 두 가지 프로토콜
• The Agent Card — 에이전트 카드 (The Agent Card): AI 에이전트가 서로를 발견하는 방법
• The Task Lifecycle — A2A 작업 생명주기 (Task Lifecycle) 이해하기 (그리고 모든 클라이언트를 멈추게 하는 버그)

더 깊이 알고 싶으신가요?

이 주제에 대해 두 가지 가이드를 작성했습니다.

A2A Quick-Start — 무료, 6페이지. 15분 만에 배우는 Agent2Agent 프로토콜: 정의, 5가지 구성 요소, 작업 생명주기 (task lifecycle), 그리고 MCP가 차지하는 위치.

A2A: 완전 가이드 — 42페이지. 15개의 장(chapters)과 5개의 부록(appendices)으로 구성되어 있습니다. 탐색(Discovery), 보안(security), SDK를 활용한 첫 번째 에이전트 구축, 오케스트레이션 패턴(orchestration patterns), 확장(extensions) 및 AP2, 프로덕션(production) 및 스케일링(scaling)을 다룹니다. 또한 두 에이전트가 대화하는 전체 실습 예제와 30일 도입 경로(30-day adoption path)가 포함되어 있습니다.