A2A — 에이전트 간 프로토콜

MCP는 에이전트와 도구를 잇는(agent-to-tool) 프로토콜입니다. A2A(Agent2Agent)는 에이전트와 에이전트를 잇는(agent-to-agent) 프로토콜로, 서로 다른 프레임워크에서 만들어진 불투명한 에이전트들이 협업하도록 하는 개방형 프로토콜입니다. Google이 2025년 4월에 공개했고, 2025년 6월 리눅스 재단(Linux Foundation)에 기증했으며, 2026년 4월 v1.0에 도달했습니다. AWS, Cisco, Microsoft, Salesforce, SAP, ServiceNow를 포함한 150개 이상의 지지 조직이 있습니다. A2A는 IBM의 ACP를 흡수했고 AP2 결제 확장(payments extension)을 추가했습니다. 이 강의(lesson)에서는 에이전트 카드(Agent Card), 작업 생명주기(Task lifecycle), 두 가지 전송 바인딩(transport binding)을 살펴봅니다.

유형: Build
언어: Python (표준 라이브러리, 에이전트 카드(Agent Card) + 작업(Task) 하네스)
선수 학습: Phase 13 · 06 (MCP 기초), Phase 13 · 08 (MCP 클라이언트)
소요 시간: 약 75분

학습 목표

• 에이전트-도구(agent-to-tool; MCP)와 에이전트-에이전트(agent-to-agent; A2A) 사용 사례를 구분합니다.
• /.well-known/agent.json에 스킬(skill)과 엔드포인트(endpoint) 메타데이터가 포함된 에이전트 카드(Agent Card)를 게시합니다.
• 작업 생명주기(Task lifecycle)를 따라갑니다. submitted → working → input-required → completed / failed / canceled / rejected입니다.
• 텍스트(text), 파일(file), 데이터(data) 파트(Part)를 가진 메시지(Message)와 출력으로서의 산출물(Artifact)을 사용합니다.

문제

고객 서비스 에이전트가 보고서 작성을 전문 작성 에이전트(writer agent)에 위임해야 한다고 해봅시다. A2A 이전의 선택지는 다음과 같았습니다.

• 맞춤형 REST API(Custom REST API). 동작은 하지만 모든 짝짓기가 일회성으로 끝납니다.
• 공유 코드베이스(shared codebase). 두 에이전트가 같은 프레임워크에서 실행되어야 합니다.
• MCP. 맞지 않습니다. MCP는 도구 호출을 위한 프로토콜이지, 각 에이전트의 불투명한 내부 추론을 보존하면서 두 에이전트가 협업하도록 하는 프로토콜이 아닙니다.

A2A는 이 공백을 채웁니다. 한 에이전트가 다른 에이전트에게 작업(Task)을 보내는 상호작용으로 모델링하며, 생명주기, 메시지, 산출물(Artifact)을 갖습니다. 호출된 에이전트의 내부 상태는 불투명하게 유지되며, 호출자는 작업 상태 전이와 최종 출력만 보게 됩니다.

A2A는 "서로 다른 프레임워크의 에이전트들이 대화하게 하는" 프로토콜입니다. MCP를 대체하지 않으며, 둘은 상호 보완적인 관계입니다.

개념

에이전트 카드(Agent Card)

A2A를 준수하는 모든 에이전트는 /.well-known/agent.json에 카드를 게시합니다.

{
  "schemaVersion": "1.0",
  "name": "research-agent",
  "description": "Summarizes academic papers and drafts citations.",
  "url": "https://research.example.com/a2a",
  "version": "1.2.0",
  "skills": [
    {
      "id": "summarize_paper",
      "name": "Summarize a paper",
      "description": "Read a paper PDF and produce a 3-paragraph summary.",
      "inputModes": ["text", "file"],
      "outputModes": ["text", "artifact"]
    }
  ],
  "capabilities": {"streaming": true, "pushNotifications": true}
}

발견(discovery)은 URL 기반입니다. 카드를 가져온 뒤 A2A 엔드포인트의 URL을 확인하고, 사용 가능한 스킬(skill)을 열거하는 방식입니다.

서명된 에이전트 카드(Signed Agent Cards; AP2)

AP2 확장(2025년 9월)은 에이전트 카드에 암호학적 서명을 추가합니다. 게시자는 JWT로 자신의 카드에 서명하고, 소비자는 이를 검증합니다. 이 서명은 위장(impersonation)을 방지합니다.

작업 생명주기(Task lifecycle)

submitted -> working -> completed | failed | canceled | rejected
             -> input_required -> working (메시지를 통한 루프)

클라이언트는 tasks/send로 시작합니다. 호출된 에이전트는 상태를 전이하고, 클라이언트는 SSE를 통해 상태 업데이트를 구독하거나 주기적으로 폴링(polling)해 확인합니다.

메시지(Message)와 파트(Part)

하나의 메시지는 하나 이상의 파트를 담습니다.

• text — 일반 텍스트 콘텐츠입니다.
• file — mimeType을 가진 base64 인코딩된 바이너리(blob)입니다.
• data — 타입이 있는 JSON 페이로드(payload)로, 호출된 에이전트에 전달되는 구조화 입력입니다.

예시:

{
  "role": "user",
  "parts": [
    {"type": "text", "text": "Summarize this paper."},
    {"type": "file", "file": {"name": "paper.pdf", "mimeType": "application/pdf", "bytes": "..."}},
    {"type": "data", "data": {"targetLength": "3 paragraphs"}}
  ]
}

산출물(Artifacts)

출력은 원시 문자열이 아니라 산출물(Artifact)입니다. 산출물은 이름과 타입이 있는 출력입니다.

{
  "name": "summary",
  "parts": [{"type": "text", "text": "..."}],
  "mimeType": "text/markdown"
}

산출물은 청크(chunk) 단위로 스트리밍될 수 있고, 호출자는 이를 누적합니다.

두 가지 전송 바인딩(transport bindings)

1. HTTP 위의 JSON-RPC. /a2a 엔드포인트(endpoint)를 사용하고, 요청에는 POST, 스트리밍에는 선택적으로 SSE를 사용합니다. 기본 바인딩입니다.
2. gRPC. gRPC가 자연스러운 엔터프라이즈 환경에서 사용합니다.

두 바인딩은 같은 논리 메시지 형태를 전달합니다.

불투명성(opacity) 보존

핵심 설계 원칙은 호출된 에이전트의 내부 상태가 불투명하다는 것입니다. 호출자는 작업 상태와 산출물만 볼 수 있고, 호출된 에이전트의 사고 사슬(chain-of-thought), 도구 호출, 하위 에이전트(sub-agent) 위임 같은 내부 동작은 모두 보이지 않습니다. 이 점이 도구 호출이 투명하게 노출되는 MCP와의 결정적인 차이입니다.

이유는 명확합니다. A2A는 경쟁 관계의 조직들도 내부를 공개하지 않은 채 협업할 수 있게 합니다. 즉, 호출자는 그 에이전트가 서비스를 어떻게 구현하는지 알 필요 없이 "이 고객 서비스 에이전트(customer-service agent)를 호출해"라고 요청만 하면 됩니다.

타임라인

• 2025-04-09. Google이 A2A를 발표합니다.
• 2025-06-23. 리눅스 재단(Linux Foundation)에 기증됩니다.
• 2025-08. IBM의 ACP를 흡수합니다.
• 2025-09. AP2 확장(Agent Payments)이 배포됩니다.
• 2026-04. 150개 이상의 지지 조직과 함께 v1.0이 출시됩니다.

MCP와의 관계

특정 도구를 호출하고 싶다면 MCP를 사용합니다. 전체 작업을 다른 에이전트에게 위임하고 싶다면 A2A를 사용합니다. 많은 프로덕션 시스템은 둘을 함께 사용합니다. 에이전트가 도구 계층에서는 MCP를 쓰고, 협업 계층에서는 A2A를 쓰는 식입니다.

사용해 보기

code/main.py는 최소한의 A2A 하네스(harness)를 구현합니다. 조사 에이전트(research agent)는 자신의 카드를 게시하고, 작성 에이전트(writer agent)는 PDF와 텍스트 지시가 포함된 파트(Part)를 가진 tasks/send를 받습니다. 이 작업은 working → input_required → working → completed로 전이한 뒤 텍스트 산출물(text artifact)을 반환합니다. 전부 표준 라이브러리만 사용하며, 메시지 형태에 집중하기 위해 프로세스 내부 전송을 씁니다.

살펴볼 지점은 다음과 같습니다.

• 에이전트 카드(Agent Card) JSON의 구조
• 작업(Task) ID 할당과 상태 전이
• 혼합 타입 파트를 가진 메시지(Message)
• 작업 중간의 input-required 분기
• 완료 시 반환되는 산출물(Artifact)

산출물 만들기

이 강의는 outputs/skill-a2a-agent-spec.md를 만듭니다. 다른 에이전트가 호출할 수 있어야 하는 새 에이전트가 주어지면, 이 스킬(skill)은 에이전트 카드(Agent Card) JSON, 스킬 스키마(skills schema), 엔드포인트 청사진(endpoint blueprint)을 생성합니다.

연습문제

1. code/main.py를 실행합니다. 호출된 에이전트가 명확화를 요청하는 input-required 일시 정지(pause)를 포함해 전체 작업(Task) 생명주기를 추적합니다.

2. 서명된 에이전트 카드를 추가합니다. 카드의 정규화된(canonical) JSON에 대해 HMAC으로 서명합니다. 검증기(verifier)를 작성하고 카드가 변조되면 검증이 실패하는지 확인합니다.

3. 작업 스트리밍(task streaming)을 구현합니다. 작성 에이전트(writer agent)가 SSE를 통해 세 개의 점진적 산출물 청크(incremental artifact chunk)를 내보내고, 호출자가 이를 누적하게 합니다.

4. MCP 서버를 감싸는 A2A 에이전트를 설계합니다. 각 MCP 도구를 A2A 스킬(skill)에 매핑합니다. 이때 발생하는 트레이드오프(trade-off)를 메모합니다. 어떤 불투명성이 사라질까요?

5. A2A v1.0 발표를 읽고 2026년 4월 기준 어떤 프레임워크도 아직 구현하지 않은 기능 하나를 찾습니다. 힌트: 다중 홉 작업 위임(multi-hop task delegation)과 관련 있습니다.

핵심 용어

더 읽을거리

• a2a-protocol.org — 표준 A2A 스펙
• a2aproject/A2A — GitHub — 참조 구현과 SDK
• Linux Foundation — A2A launch press release — 2025년 6월 거버넌스 이전
• Google Cloud — A2A protocol upgrade — 로드맵과 파트너 모멘텀(momentum)
• Google Dev — A2A 1.0 milestone — v1.0 릴리스 노트와 하위 호환 가이드