A2A 프로토콜 철저 해설: 에이전트 간 통신의 표준 규격이 가져올 'AI 에이전트의 인터넷'

LangGraph로 작성한 에이전트와 CrewAI로 작성한 에이전트가 협조 동작할 때, 혹은 고객 지원 에이전트가 청구 관련 문제를 서드파티 재무 에이전트에게 위탁할 때, 이들 사이에서 "어떻게 대화하고, 어떻게 태스크를 분담하며, 어떻게 실시간으로 진행 상황을 동기화할 것인가"를 결정하는 공통 규격이 있을까요?

Google과 50개 이상의 기업·단체가 2025년 4월에 발표한, 이 질문에 대한 표준화의 해답이 **"A2A (Agent2Agent) 프로토콜"**입니다.

공개 후 불과 2개월 만에 Linux Foundation에 기증되었고, 1주년을 맞이한 2026년 4월에는 GitHub 스타 수가 22,000개를 넘어섰으며, 150개 이상의 기업이나 프로덕션 조직에서 도입이 진행되고 있습니다. 본 기사에서는 A2A 프로토콜의 기본 설계 사상, 3가지 주요 역할(Role), 5가지 핵심 데이터 구조, 그리고 기업용 시스템에서의 구현 패턴에 대해 체계적으로 해설합니다.

2024년부터 2025년에 걸쳐, LLM (대규모 언어 모델)을 구사한 AI 에이전트는 단일 자율 동작에서 "여러 에이전트에 의한 클러스터형 협조 동작"으로 진화했습니다. 하지만 개발자들은 곧바로 **"서로 다른 프레임워크나 플랫폼에서 구축된 에이전트끼리 대화하기 위한 공통 프로토콜이 존재하지 않는다"**라는 벽에 부딪혔습니다.

예를 들어, LangGraph로 작성한 "지원 창구 에이전트"가 CrewAI로 구동되는 "재무 분석 에이전트"를 호출하고, 나아가 서드파티 SaaS가 제공하는 "CRM 에이전트"와 연계하는 상황을 상정해 봅시다.

A2A가 등장하기 전에는 재무 에이전트를 억지로 "도구 (Tool)"로서 캡슐화하여 지원 에이전트에게 제공할 수밖에 없었습니다. 하지만 이 방식으로는 에이전트가 단순한 **"스테이트리스 (Stateless) 함수 호출"**로 격하되어, 에이전트 본래의 강점인 자율적인 추론, 멀티턴 (Multi-turn) 협상, 장기적인 태스크 관리 능력이 모두 상실됩니다.

이 과제는 "바벨탑의 딜레마"라고 불리고 있습니다.

과제	구체적인 현상
발견 메커니즘의 결여	에이전트 A는 에이전트 B가 무엇을 실행할 수 있는지, 어떻게 호출해야 하는지 알 방법이 없다.
프로토콜의 파편화	LangChain 기반의 에이전트와 AutoGen 기반의 에이전트가 네이티브하게 통신할 수 없다.
보안 경계의 모호함	조직을 넘나드는 에이전트 호출에 있어, 통일된 아이덴티티 인증이나 인가 모델이 없다.
상태 관리의 혼란	장시간 실행되는 태스크 (Long-running tasks)의 중간 상태를 표준화된 포맷으로 전달할 수 없다.
인간-기계 협업 (Human-in-the-Loop)의 결여	에이전트가 처리를 일시 중단하고 인간의 승인(확인)을 기다려야 하는 타이밍을 표준적으로 합의할 수 없다.

💡

핵심적인 통찰

이는 2000년대 초반의 웹 서비스가 혼란스러웠던 상황 (SOAP나 XML-RPC의 군웅할거)과 매우 흡사합니다. 이후 HTTP + REST가 사실상의 표준이 되어 오늘날의 인터넷이 성립된 것처럼, **A2A는 "AI 에이전트 시대의 HTTP"**를 목표로 설계되었습니다.

"A2A와 MCP (Model Context Protocol)는 어떻게 다른가? 어느 쪽을 선택해야 하는가?"라는 의문을 갖는 분들이 많을 것입니다.

결론부터 말하자면, **"둘 다 채택해야 하며, 이들은 서로 다른 레이어의 과제를 해결하는 것"**입니다.

비교 축	A2A (Agent2Agent)	MCP (Model Context Protocol)
연결 대상	에이전트 ↔ 에이전트	에이전트 ↔ 도구 / 리소스 (DB, 파일 등)
인터랙션	멀티턴, 스테이트풀 (Stateful), 협조·협상형	단발 호출, 스테이트리스 (Stateless), 구조화 데이터
전형적인 시나리오	고객 지원 에이전트가 결제 에이전트에게 환불 처리를 위탁한다	에이전트가 데이터베이스의 주문 이력을 검색한다
설계 사상	에이전트는 자율적인 "협조 파트너"이다	도구는 호출될 뿐인 "능력의 최소 단위"이다

요약하자면, **MCP는 「에이전트가 도구와 데이터를 어떻게 사용하는가」**를 해결하고, **A2A는 「에이전트가 다른 에이전트와 어떻게 협업하는가」**를 해결합니다. 하나의 에이전트가 MCP를 사용하여 로컬 도구를 호출하면서, 동시에 A2A를 사용하여 원격 에이전트와 팀을 이루는 것이 표준적인 시스템 구성입니다.

⚠️

주의: 안티 패턴 (Anti-pattern)

MCP 도입을 건너뛰고 A2A만 도입하려고 하면, 「서로 대화는 할 수 있지만, 배후에 있는 데이터나 도구에는 전혀 접근할 수 없는 에이전트 무리」가 만들어지고 맙니다.

A2A 아키텍처는 매우 단순하며, 다음의 세 가지 역할로 구성됩니다.

User (엔드 유저: 인간 또는 자동화된 서비스)
│
▼ 요청 발신
...

여기서 가장 중요한 원칙이 **「캡슐화 (불투명성: Opaque)」**입니다.
A2A Client는 원격 A2A Server (에이전트)의 내부 구현, 프롬프트 구성, 기억 상태, 또는 어떤 도구 세트(Tool set)를 가지고 있는지 알지 못하며, 알 필요도 없습니다. Client가 알아야 할 것은 **「해당 에이전트에게 어떤 일을 맡길 수 있는가 (능력)」와 「어떻게 호출하는가」**뿐입니다.

이 설계의 훌륭한 점은 에이전트 제공자의 지적 재산(에이전트의 내부 로직)을 완전히 보호하면서, C/S (클라이언트/서버) 방식의 안전한 보안 경계(Security boundary)를 확립할 수 있다는 데 있습니다. 이는 REST API로 외부 결제 서비스를 호출할 때, 결제 시스템 내부의 데이터베이스 설계를 알 필요가 없는 것과 같습니다.

A2A의 모든 통신은 다음의 5가지 핵심 데이터 구조를 중심으로 구성되어 있습니다.

A2A를 지원하는 각 에이전트는 https://{domain}/.well-known/agent.json이라는 경로에 JSON 형식의 사양서(Specification)를 공개해야 합니다. 클라이언트는 이 파일을 읽고 「이 에이전트에게 의뢰해야 할지」를 판단합니다.

{
"name": "재무 분석 에이전트",
"description": "전문적인 재무 데이터 분석, 결산서 분석, 리스크 평가 지원",
...

⚠️

설계의 팁

Agent Card에 기재하는 스킬(skills)은 **필요 최소한으로 유지할 것 (최소 스킬 선언의 원칙)**을 권장합니다. 무엇이든 다 할 수 있는 것처럼 작성하면, 클라이언트 에이전트 측의 라우팅(Routing) 판단에서 오콜(Miscall)이 빈번하게 발생하는 원인이 됩니다.

Task는 A2A의 핵심 컨셉입니다. 추적이 필요한 하나의 「업무」를 가리키며, 라이프사이클 전체에 걸쳐 엄격한 상태 전이(State transition)를 가집니다.

상태의 종류: PENDING -> RUNNING -> COMPLETED / FAILED / CANCELED

Task의 불변성 (Immutability): Task가 일단 종료 상태(Completed 등)에 진입하면 재개할 수 없습니다. 결과를 변경하고 싶다면, 동일한 세션 하에서 원래의 Task ID를 참조하는 새로운 Task를 생성합니다.

에이전트 간에 이루어지는 일련의 대화는 모두 Message로서 관리됩니다. 각 Message는 발신 역할(user 또는 agent), 고유 ID, 그리고 내용을 나타내는 Parts의 리스트로 구성됩니다.

A2A가 다양한 미디어(텍스트, 이미지, 코드)를 처리할 수 있는 것은 이 Part라는 데이터 모델 덕분입니다.

타입	설명	주요 유스케이스
text	평문 텍스트	자연어를 통한 대화
file	바이너리 파일 (Base64 / URL)	PDF 결산 자료, 분석용 이미지 등
data	구조화된 JSON 객체	DB 추출 데이터, 구조화된 보고서 등
url	외부 리소스의 URI	대용량 파일이나 외부 링크 참조

{
"role": "user",
"parts": [
...

Message와 Artifact의 결정적인 차이는, **Message는 「논의의 프로세스」이며, Artifact는 「공식적인 결과물」**이라는 점입니다. 에이전트가 태스크를 완료했을 때 생성되는 최종 보고서, 소스 코드, 데이터 시트 등은 모두 Artifact로서 출력됩니다.

태스크의 특성에 따라 A2A는 세 가지 통신 패턴을 제공합니다.

가장 단순한 통신입니다. Client가 tasks/send를 호출하면, Server가 즉시 응답합니다. 시간이 걸리는 처리의 경우, Client는 tasks/getTask를 정기적으로 폴링(Polling)하여 상태를 확인합니다.

권장: 처리 시간이 5초 미만인, 즉시 완료되는 심플한 태스크.

tasks/stream을 호출하면, Server는 **Server-Sent Events (SSE)**를 통해 실시간으로 진행 상황을 푸시(Push)합니다.

수 분에서 수 시간에 이르는 초장기 태스크용입니다. Client는 요청 시 Webhook URL을 지정하며, Server는 태스크의 상태가 변경되었을 때 해당 URL로 푸시 전송을 수행합니다.

⚠️

보안 주의 사항

Push 알림을 설계할 때, Server 측은 **SSRF (Server-Side Request Forgery)**를 방지하기 위해 Webhook URL 검증(Verification)을 수행해야 합니다. 반면, Client 측은 요청이 실제 에이전트로부터 온 것인지 검증하기 위해, **JWT 서명 + 타임스탬프 + Nonce (재전송 공격 방지)**를 조합한 검증을 필수로 도입해야 합니다.

시스템 요구사항에 따라 적절한 발견(Discovery) 방법을 선택할 수 있습니다.

방식	경로·접근 방식	적용 시나리오
Well-Known URI	https://domain/.well-known/agent.json	퍼블릭 에이전트, 도메인 내 자율 발견
레지스트리 (카탈로그)	중앙 집중식 Catalog 서비스	기업 내 에이전트 거버넌스 및 통제 관리
직접 구성	하드코드 / 환경 변수	개발 테스트 단계, 또는 특정 비공개 에이전트

💡

운영 환경 권장 구성

퍼블릭 에이전트에는 'Well-Known URI를 통한 자율 발견'을 채택하고, 사내 프라이빗 에이전트에는 '중앙 카탈로그 레지스트리'를 통한 일원 관리를 수행하는 것이 현재 주류인 베스트 프랙티스(Best Practice)입니다.

설계 과정에서 논의가 되기 쉬운, A2A의 특징적인 기술적 결정 사항들을 소개합니다.

의사결정 ①: Task ID를 Client 측에서 생성한다-
이유: 네트워크 에러로 인한 재시도(Retry) 시, Server 측에서 확실하게 멱등성 (Idempotency)을 보장하기 위해서입니다. 동일한 Task ID로 재전송될 경우, Server는 태스크를 중복 실행하지 않습니다. 대신, Client는 UUID v4와 같은 글로벌 유니크 ID를 발행할 책임을 집니다.

의사결정 ②: Artifacts와 Messages의 분리-
이유: 대화 이력 (Messages)과 생성된 결과물 (Artifacts)은 라이프사이클이 다릅니다. Messages는 인간을 위해 순차적으로 표시되는 반면, Artifacts는 시스템 간의 재사용이나 다운로드 대상이 됩니다. 분리함으로써 Artifact만의 증량 스트리밍 (lastChunk: false) 등을 용이하게 할 수 있습니다.

의사결정 ③: REST가 아닌 JSON-RPC 2.0 채택-
이유: REST의 HTTP 메서드 (GET/POST/DELETE) 시맨틱(Semantics)은 복잡한 에이전트의 동작 (태스크 취소나 일시 중지 등)을 표현하기에는 모호해지기 쉽습니다. JSON-RPC를 사용하면 메서드 명 (cancelTask 등)으로 명확하게 지시할 수 있으며, id 필드를 이용한 비동기 메시징 처리가 용이해집니다.

A2A는 공식적으로 Python/JavaScript/Java/Go/.NET SDK를 제공합니다. 다음은 Python SDK를 사용한 가장 심플한 구축 예시입니다.

from google.adk.a2a import to_a2a
from your_agent_module import root_agent
# 자체 제작한 에이전트를 A2A 대응 서비스로 래핑(Wrap)
...

from google.adk.a2a import RemoteA2aAgent
# Agent Card의 URL을 지정하여 원격 에이전트에 접속
billing_agent = RemoteA2aAgent(
...

A2A는 처음부터 엔터프라이즈 상용 환경을 상정하여, 보안 및 모니터링 기능을 사양에 포함하고 있습니다.

• 보안 통신 (Secure Communication): 운영 환경에서는 HTTPS 연결을 강제함 (TLS 1.2 이상 권장).
• 인증 스킴 (Authentication Scheme): API Key, OAuth 2.0, OpenID Connect, mTLS 지원.
• 세밀한 인가 (Fine-grained AuthZ): 에이전트가 보유한 '스킬 단위'로 액세스 제어 가능.
• 가시성 (Observability): OpenTelemetry와 원활하게 통합. 모든 태스크 메시지에 taskId와 contextId가 부여되어, 시스템을 넘나드는 트레이스 추적 (Trace Tracking)이 가능함.

2025년 4월 Google이 Google Cloud Next에서 처음 제안한 이후 약 1년 만에, A2A는 폭발적인 성장을 이루었습니다.

2025년 6월: Linux Foundation에 기증. AWS, Microsoft, Cisco, Salesforce, SAP 등이 창설 멤버로 참여.
2026년 3월: v1.0 안정 버전 출시. v1.2에서 '서명된 에이전트 카드 (Signed Agent Card)' 사양이 도입되어, 부정 에이전트의 사칭을 방지.
현재: Microsoft Copilot Studio / Azure AI Foundry, AWS Bedrock AgentCore 등 주요 클라우드 서비스에서 네이티브 지원.

나아가 Google은 A2A의 상위 규격으로서 Mastercard, PayPal, American Express 등과 제휴한 **"AP2 (Agent Payments Protocol)"**를 전개하고 있으며, 승인된 예산 범위 내에서 에이전트끼리 자율적으로 결제를 수행하는 단계에 진입했습니다.

A2A 프로토콜은 단순한 새로운 기술 표준이 아니라, '에이전트 중심의 새로운 네트워크 사회'를 구축하기 위한 인프라입니다.

에이전트는 '자율적인 파트너'이며, 도구가 아니다. 그렇기에 상태를 가진 Task, Message, Parts가 설계되어 있다.
느슨한 결합 (Loosely Coupled)의 협업이 긴밀한 결합 (Tightly Coupled)의 연계보다 우수하다. 내부 구현을 은닉하고, Agent Card를 통해 능력 기반으로 대화한다.
엔터프라이즈 대응이 표준에 포함되어 있다. 보안이나 OpenTelemetry를 통한 추적이 처음부터 구현되어 있다.

앞으로 멀티 에이전트 시스템 (Multi-Agent System) 개발에 임한다면, 우선 MCP를 사용하여 에이전트가 사내 데이터나 도구를 조작하게 하고, 그다음 A2A를 도입하여 타 시스템이나 타 조직의 에이전트와 팀을 이루게 하는 접근 방식을 권장합니다. 사내에 있는 독자적인 API 호출이나 수작업으로 중계하고 있는 에이전트 간 프로세스가 있다면, 그것이야말로 A2A 도입의 제1 후보입니다.

"HTTP가 오늘날의 인터넷을 만들었듯이, A2A가 에이전트의 인터넷을 만들 것인가" —— 그 미래에 주목해야 합니다.