A2A — 에이전트 간 프로토콜(Agent-to-Agent Protocol)

구글(Google)은 2025년 4월 A2A를 발표했고, 2026년 4월 기준 스펙은 https://a2a-protocol.org/latest/specification/ 에 공개되어 있으며 150개 이상의 조직이 이를 지지합니다. A2A는 MCP(Lesson 13)의 수평적 보완재입니다. MCP가 수직 구조(agent ↔ tools)라면, A2A는 피어 투 피어(peer-to-peer), 즉 agent ↔ agent 구조입니다. A2A는 에이전트 카드(Agent Cards)를 통한 발견(discovery), 산출물(artifacts)을 갖는 태스크(tasks), 불투명한 태스크 생명주기(opaque task lifecycles), 인증(auth)을 정의합니다. 프로덕션 시스템에서는 MCP와 A2A를 함께 사용하는 경우가 점점 늘고 있습니다. 구글 클라우드(Google Cloud)는 2025~2026년 사이에 버텍스 AI 에이전트 빌더(Vertex AI Agent Builder)에 A2A 지원을 포함했습니다.

유형: Learn + Build 언어: Python (stdlib, http.server, json) 선수 지식: Phase 16 · 04 (멀티 에이전트 기본 모델) 예상 시간: 약 75분

문제

내 에이전트가 다른 시스템에 있는 또 다른 에이전트를 호출해야 한다고 해봅시다. 어떻게 해야 할까요? HTTP 엔드포인트(endpoint)를 열어두고, 우리만의 JSON 스키마(schema)를 정의한 뒤, 상대편이 그 형식을 알아서 맞춰 주기를 기대할 수 있습니다. 하지만 이렇게 하면 에이전트 쌍이 늘어날 때마다 매번 별도의 맞춤 연동(custom integration)을 새로 만들게 됩니다.

A2A는 바로 그 호출을 위한 보편 통신 프로토콜(wire protocol)입니다. 표준화된 발견(discovery), 표준 태스크 모델(task model), 표준 전송(transport), 표준 산출물(artifact) 규약을 함께 제공합니다. 비유하자면 HTTP+REST와 비슷하지만, 에이전트(agent)를 일등 시민(first-class citizen)으로 다루는 형태라고 볼 수 있습니다.

개념

네 가지 요소

에이전트 카드(Agent Card). /.well-known/agent.json 경로에 위치한 JSON 문서입니다. 에이전트의 이름, 스킬(skill), 엔드포인트(endpoint), 지원하는 양식(modality), 인증(auth) 요구사항을 설명합니다. 발견(discovery)은 이 카드를 읽는 방식으로 이루어집니다.

GET https://agent.example.com/.well-known/agent.json
→ {
    "name": "code-review-agent",
    "skills": ["review-python", "review-typescript"],
    "endpoints": {
      "tasks": "https://agent.example.com/tasks"
    },
    "auth": {"type": "bearer"},
    "modalities": ["text", "structured"]
  }

태스크(Task). 작업의 단위입니다. 비동기(async)이면서 상태를 갖는 객체이고, submitted → working → completed / failed / canceled로 이어지는 생명주기(lifecycle)를 따릅니다. 클라이언트(client)는 태스크를 제출한 뒤, 업데이트를 주기적으로 조회(polling)하거나 이벤트를 구독(subscribe)합니다.

산출물(Artifact). 태스크가 만들어 내는 결과의 타입입니다. 텍스트, 구조화된 JSON(structured JSON), 이미지, 비디오, 오디오 등이 될 수 있습니다. 산출물에는 타입이 붙기 때문에 서로 다른 양식(modality)을 일등 시민으로 다룰 수 있습니다.

불투명한 생명주기(Opaque lifecycle). A2A는 원격 에이전트가 태스크를 어떻게 해결할지에 대해서는 규정하지 않습니다. 클라이언트는 상태 전이와 산출물만 볼 수 있고, 구현 측에서는 어떤 프레임워크를 사용해도 자유롭습니다.

MCP와 A2A의 분리

• MCP (Lesson 13): agent ↔ tool. 에이전트는 JSON-RPC를 통해 도구 서버(tool server)를 읽고 씁니다. 기본적으로 무상태(stateless)입니다.
• A2A: agent ↔ agent. 피어 프로토콜(peer protocol)입니다. 양쪽 모두 자체적인 추론(reasoning) 능력을 갖춘 에이전트입니다.

프로덕션 멀티 에이전트 시스템에서는 둘을 함께 사용합니다. A2A 피어는 내부적으로 자신의 MCP 도구를 호출합니다. 이렇게 두 가지를 분리해두면 서로 다른 관심사가 깔끔하게 나뉩니다.

발견(Discovery) 흐름

Client                     Agent server
  ├──GET /.well-known/agent.json──>
  <──Agent Card JSON─────────────
  ├──POST /tasks {skill, input}──>
  <──201 task_id, state=submitted
  ├──GET /tasks/{id}──────────────>
  <──state=working, 42% done──────
  ├──GET /tasks/{id}──────────────>
  <──state=completed, artifacts──

또는 스트리밍(streaming) 방식을 쓸 수도 있습니다. 이 경우에는 /tasks/{id}/events 경로에 SSE(Server-Sent Events) 구독을 걸어두고 푸시 형태(push)로 업데이트를 받습니다.

인증(Auth)

A2A는 흔히 쓰이는 세 가지 패턴을 지원합니다.

• 베어러 토큰(Bearer token) — OAuth2 토큰이거나 불투명한(opaque) 토큰입니다.
• mTLS — 상호 TLS(mutual TLS)입니다. 양쪽 조직이 서로에게 신원(identity)을 증명합니다.
• 서명된 요청(Signed requests) — 페이로드(payload)에 대한 HMAC 서명입니다.

어떤 인증 방식을 쓸지는 에이전트 카드(Agent Card)에 선언해둡니다. 클라이언트는 카드를 발견한 뒤 그 요구사항을 따라 호출합니다.

2026년 4월 기준 150개 이상의 조직

엔터프라이즈 도입이 A2A의 규모를 키웠습니다. 핵심은 A2A가 엔터프라이즈 에이전트 시스템(enterprise agent system)이 신뢰 경계(trust boundary)를 넘나드는 표준 방식으로 자리 잡았다는 점입니다. 구글 클라우드(Google Cloud)는 버텍스 AI 에이전트 빌더(Vertex AI Agent Builder)에 A2A 지원을 출시했고, 마이크로소프트 에이전트 프레임워크(Microsoft Agent Framework)도 이를 지원합니다. 주요 프레임워크(LangGraph, CrewAI, AutoGen) 대부분은 A2A 어댑터(adapter)를 함께 제공합니다.

A2A가 강한 곳

• 조직 간 호출. 회사 A의 에이전트가 회사 B의 에이전트를 호출하는 상황입니다. A2A가 없다면 모든 에이전트 쌍이 별도의 맞춤 계약(bespoke contract)으로 묶이게 됩니다.
• 이질적인 프레임워크. LangGraph 기반 에이전트가 CrewAI 기반 에이전트를 호출하고, 그 에이전트가 다시 직접 만든 Python 에이전트를 호출할 수 있습니다. A2A는 이런 호출을 표준화합니다.
• 타입이 있는 산출물. 비디오 결과, 구조화된 JSON, 오디오 모두를 일등 시민으로 다룹니다.
• 오래 걸리는 태스크. 불투명한 생명주기와 주기적 조회(polling) 덕분에 몇 시간씩 걸리는 태스크도 단순하게 다룰 수 있습니다.

A2A가 어려워지는 곳

• 지연 시간에 민감한 마이크로 호출(micro-call). A2A의 생명주기는 비동기 구조입니다. 1밀리초 미만(sub-millisecond)의 에이전트 간 호출에는 맞지 않으므로, 이런 경우에는 직접 RPC를 사용합니다.
• 강하게 결합된 같은 프로세스 내(in-process) 에이전트. 두 에이전트가 같은 Python 프로세스 안에서 실행된다면 A2A의 HTTP 왕복(round-trip)은 과한 비용입니다.
• 작은 팀. 스펙 자체가 가져오는 부담(overhead)도 실제로 존재합니다. 내부 전용 에이전트에는 이 정도의 형식성이 필요 없을 수 있습니다.

A2A와 ACP, ANP, NLIP 비교

2024~2026년 사이에 관련 스펙이 여럿 등장했습니다.

• ACP (IBM/Linux Foundation) — A2A의 이전 세대(predecessor)에 해당하며 다루는 범위가 더 좁습니다.
• ANP (Agent Network Protocol) — 피어 발견(peer discovery)을 중시하고 분산 우선(decentralized-first) 성격이 강합니다.
• NLIP (Ecma Natural Language Interaction Protocol, 2025년 12월 표준화) — 자연어 형태의 콘텐츠 타입(content type)에 초점을 둡니다.

A2A는 2026년 4월 기준 가장 널리 채택된 피어 프로토콜입니다. 더 자세한 비교는 Liu et al.의 "A Survey of Agent Interoperability Protocols"(arXiv:2505.02279)를 참고하면 좋습니다.

직접 만들기

code/main.py는 http.server와 JSON만 사용해 최소 형태의 A2A 서버와 클라이언트를 구현합니다. 서버는 다음을 수행합니다.

• /.well-known/agent.json을 노출합니다.
• POST /tasks 요청을 받습니다.
• 태스크 상태를 관리합니다.
• GET /tasks/{id}로 산출물을 반환합니다.

클라이언트는 다음을 수행합니다.

• 에이전트 카드를 가져옵니다.
• 태스크를 제출합니다.
• 완료될 때까지 주기적으로 조회(polling)합니다.
• 산출물을 읽습니다.

실행 방법은 다음과 같습니다.

python3 code/main.py

스크립트는 백그라운드 스레드(background thread)에서 서버를 띄운 뒤, 그 서버를 대상으로 클라이언트를 실행합니다. 발견(discovery), 제출(submit), 조회(poll), 산출물(artifact)까지 이어지는 전체 흐름을 한 번에 확인할 수 있습니다.

사용해보기

outputs/skill-a2a-integrator.md는 A2A 연동(integration)을 설계하는 스킬입니다. 에이전트 카드의 내용, 태스크 스키마(task schema), 어떤 인증을 선택할지, 스트리밍과 주기적 조회 중 어느 쪽을 쓸지 등을 정리합니다.

배포 전 확인

체크리스트:

• 스펙 버전 고정(Pin the spec version). A2A는 아직 진화하는 중입니다. 에이전트 카드에 프로토콜 버전(protocol version)을 명시해 두어야 합니다.
• 멱등적인 태스크 생성(Idempotent task creation). 네트워크 재시도로 인해 중복 제출이 발생하더라도 태스크는 단 하나만 만들어져야 합니다.
• 산출물 스키마(Artifact schemas). 에이전트가 어떤 형태의 결과를 반환하는지 선언해 두고, 소비자(consumer) 쪽에서 이를 검증할 수 있도록 합니다.
• 속도 제한과 인증(Rate limits + auth). A2A는 외부에 공개되는(public-facing) 경우가 많습니다. 표준적인 웹 보안(web security)을 그대로 적용합니다.
• 실패 태스크용 데드 레터(Dead-letter for failed tasks). 시간이 흐르며 반복되는 실패 유형(failure type)을 추적할 수 있도록 실패한 태스크를 별도로 모아 살펴봅니다.

연습문제

1. code/main.py를 실행합니다. 클라이언트가 서버를 발견(discovery)하고 올바른 산출물을 받는지 확인합니다.
2. 서버에 두 번째 스킬을 추가합니다. 예: "summarize". 에이전트 카드를 갱신하고, 태스크 유형에 따라 스킬을 골라 호출하는 클라이언트를 작성합니다.
3. SSE 스트리밍 엔드포인트(/tasks/{id}/events)를 구현하여 상태 변경을 방출(emit)하도록 합니다. 이때 클라이언트는 어떤 부분을 다르게 작성해야 할까요?
4. A2A 스펙(https://a2a-protocol.org/latest/specification/)을 읽어봅니다. 이 데모가 구현하지 않은 스펙상의 의무사항 세 가지를 찾아보세요.
5. A2A(에이전트 카드 기반 발견)와 MCP(listTools를 통한 서버 측 능력 나열, server-side capability listing)를 비교해 봅니다. 자기 자신을 기술하는 에이전트(self-describing agent)와 능력 탐사(capability-probing) 방식 사이에는 어떤 트레이드오프(trade-off)가 있을까요?

핵심 용어

더 읽을거리

• A2A specification — A2A의 공식 정본 스펙입니다.
• Google Developers Blog — A2A announcement — 2025년 4월의 출시 발표 글입니다.
• A2A GitHub repo — 레퍼런스 구현과 SDK를 확인할 수 있는 공식 저장소입니다.
• Liu et al. — A Survey of Agent Interoperability Protocols — MCP, ACP, A2A, ANP를 한자리에 모아 비교한 서베이 논문입니다.