#Agent2Agent (A2A) Protocol

A2A는 서로 다른 프레임워크·언어·회사로 만들어진 Agent들이 서로를 발견하고, 작업을 위임하고, 결과를 주고받게 하는 오픈 프로토콜입니다. 핵심은 상대 Agent의 내부(메모리, 프롬프트, 도구 구현)를 몰라도 협업할 수 있다는 점입니다. Agent를 블랙박스로 둔 채, 공개된 능력 명세와 표준 메시지로만 대화합니다.

한때 IBM의 ACP(Agent Communication Protocol)가 비슷한 목표로 경쟁했지만, 2025년 8월 ACP가 A2A에 합류하면서 Agent 간 통신 표준은 사실상 A2A 하나로 모였습니다.

#왜 필요한가

오늘날 Agent는 LangGraph, CrewAI, Google ADK, 사내 프레임워크 등 제각각의 기술로 만들어집니다. 이 파편화는 협업을 어렵게 합니다.

• 통합 장벽: 서로 다른 Agent를 연결하려면 매번 맞춤 연동 코드가 필요합니다.
• 중복 작업: 다른 팀이 이미 만든 기능을 연결할 수 없어 비슷한 Agent를 다시 만듭니다.
• 확장성 문제: Agent가 늘어날수록 1:1 연동의 수가 기하급수적으로 늘어납니다.
• 일관성 없는 개발 경험: 프레임워크마다 호출 방식, 상태 표현, 에러 처리가 다릅니다.

#사용 사례

#역사: ACP와 A2A

#합류 전 ACP의 특징

ACP는 A2A와 목표가 같았지만 설계 방향이 달랐습니다. 이 아이디어들은 A2A 발전에 반영되는 방향으로 합쳐졌습니다.

현재 A2A v1.0은 JSON-RPC 외에 HTTP+JSON(REST)와 gRPC 바인딩도 공식 지원하므로, "REST로 단순하게 호출하고 싶다"는 ACP의 장점도 A2A 안에서 쓸 수 있습니다. 기존 ACP 사용자는 BeeAI의 A2AServer 어댑터로 Agent를 A2A 호환으로 노출하는 방식으로 이전합니다.

⚠️ 함정: "ACP"라는 약어는 여러 프로토콜이 씁니다. 특히 Zed가 주도하는 Agent Client Protocol 은 에디터 ↔ 코딩 Agent 연결 표준으로, 여기서 말하는 IBM의 Agent Communication Protocol과 전혀 다른 현역 프로젝트입니다. 자료를 볼 때 어느 ACP인지 확인하세요.

#핵심 개념

Message는 소통용, Artifact는 결과물용입니다. 스펙은 작업 결과를 Message가 아니라 Task의 Artifact로 돌려주도록 권고합니다.

#Agent Card

Agent Card는 보통 https://{도메인}/.well-known/agent-card.json에 게시합니다. 이 밖에 레지스트리(카탈로그) 조회나 설정 파일에 직접 지정하는 방식으로도 발견할 수 있습니다. 스펙의 예시를 줄이면 다음과 같습니다.

{
  "name": "GeoSpatial Route Planner Agent",
  "description": "실시간 교통을 고려한 경로 계획과 지도 생성",
  "version": "1.2.0",
  "supportedInterfaces": [
    { "url": "https://georoute-agent.example.com/a2a/v1", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" },
    { "url": "https://georoute-agent.example.com/a2a/json", "protocolBinding": "HTTP+JSON", "protocolVersion": "1.0" }
  ],
  "provider": { "organization": "Example Geo Services Inc.", "url": "https://www.examplegeoservices.com" },
  "capabilities": { "streaming": true, "pushNotifications": true, "extendedAgentCard": true },
  "securitySchemes": {
    "google": {
      "openIdConnectSecurityScheme": {
        "openIdConnectUrl": "https://accounts.google.com/.well-known/openid-configuration"
      }
    }
  },
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json", "image/png"],
  "skills": [
    {
      "id": "route-optimizer-traffic",
      "name": "Traffic-Aware Route Optimizer",
      "description": "두 지점 이상의 최적 경로를 실시간 교통·통제 정보를 반영해 계산",
      "tags": ["maps", "routing", "traffic"],
      "examples": ["Mountain View에서 SFO까지 유료도로 피해서 경로 짜줘"]
    }
  ]
}

• supportedInterfaces는 선호 순서대로 나열하고, 클라이언트는 지원하는 첫 항목을 고릅니다.
• skills의 description과 examples는 도구 설명과 같은 역할을 합니다. 호출하는 쪽 LLM이 이것을 보고 위임 대상을 고르므로 구체적으로 써야 합니다.
• 공개 카드에 다 넣기 곤란한 정보는 인증된 클라이언트에게만 주는 확장 Agent Card(GetExtendedAgentCard)로 분리합니다.
• v1.0부터 카드에 서명(signatures) 을 넣어 위변조를 검증할 수 있습니다.

#Task 상태

실제 값은 TASK_STATE_SUBMITTED, TASK_STATE_WORKING처럼 접두어가 붙습니다. COMPLETED·FAILED·CANCELED·REJECTED는 종료 상태라 더 이상 메시지를 받지 않고, INPUT_REQUIRED·AUTH_REQUIRED는 중단 상태라 클라이언트의 응답을 기다립니다.

#동작 흐름

#상호작용 방식

#프로토콜 바인딩

같은 기능을 세 가지 방식으로 제공할 수 있습니다. Agent Card에 지원하는 바인딩을 선언합니다.

REST 바인딩으로 보낸 요청 예시입니다(스펙 예제).

POST /message:send HTTP/1.1
Host: agent.example.com
Content-Type: application/a2a+json
Authorization: Bearer token

{
  "message": {
    "role": "ROLE_USER",
    "parts": [{"text": "What is the weather today?"}],
    "messageId": "msg-uuid"
  }
}

{
  "task": {
    "id": "task-uuid",
    "contextId": "context-uuid",
    "status": {"state": "TASK_STATE_COMPLETED"},
    "artifacts": [{
      "artifactId": "artifact-uuid",
      "name": "Weather Report",
      "parts": [{"text": "Today will be sunny with a high of 75°F"}]
    }]
  }
}

⚠️ 함정: A2A 0.x 시절 자료는 message/send, tasks/get 같은 슬래시 형태 메서드 이름과 "kind": "text" 형태의 Part를 씁니다. v1.0에서는 SendMessage 같은 PascalCase 메서드, ROLE_USER·TASK_STATE_* 같은 enum 값으로 바뀌는 등 호환되지 않는 변경이 있었습니다. 예제를 참고할 때 버전을 확인하고, 직접 구현하기보다 공식 SDK를 쓰세요.

#MCP와 A2A

두 프로토콜은 경쟁이 아니라 층위가 다릅니다.

실무에서는 먼저 MCP로 도구 연결·권한·감사를 해결하고, 정말로 독립적인 Agent끼리 작업을 넘겨야 할 때 A2A를 도입하는 순서가 일반적입니다. 같은 조직, 같은 코드베이스 안의 서브 Agent라면 프레임워크의 handoff 기능으로 충분한 경우가 많습니다. → MCP와 A2A 선택, 멀티 Agent Handoff

#보안과 운영

• 전송 보안: 프로덕션에서는 HTTPS(gRPC는 TLS)가 필수입니다.
• 인증: Agent Card의 securitySchemes로 API Key, HTTP 인증(Bearer 등), OAuth 2.0, OpenID Connect, mTLS를 선언합니다. 자격증명은 별도 경로(OAuth 흐름 등)로 발급받아, 메시지 본문이 아니라 매 요청의 헤더(gRPC는 메타데이터)에 담아 보냅니다.
• 인가: 인증된 클라이언트라도 자기 권한 범위의 Task만 조회·취소할 수 있어야 합니다. ListTasks가 다른 사용자의 작업을 노출하지 않게 하세요.
• 원격 Agent 결과는 신뢰하지 않습니다. 다른 Agent가 준 Artifact는 외부 입력이므로 간접 프롬프트 인젝션의 통로가 될 수 있습니다. 결과로 권한 있는 행동을 하기 전에 검증하세요.
• 푸시 알림 webhook: 등록된 URL이 내부망을 가리키는 SSRF에 주의하고, 수신 측은 알림의 출처를 검증합니다.
• 관측성: 위임 체인이 길어지면 어느 Agent에서 실패했는지 추적이 어렵습니다. trace ID를 전파하고 Task ID를 업무 로그에 남기세요. → 프로덕션 Agent

#SDK

공식 SDK는 Python, JavaScript/TypeScript, Java, Go, .NET이 있습니다. Google ADK, LangGraph, CrewAI, BeeAI 같은 프레임워크도 A2A 서버 노출·원격 Agent 호출을 지원합니다.

#참고 자료

• A2A Protocol 공식 문서
• A2A Specification (GitHub)
• A2A — Agent Discovery
• A2A and MCP
• Google — Announcing the Agent2Agent Protocol
• Linux Foundation — A2A 프로젝트 출범
• Google Open Source Blog — A2A 1주년 (v1.0)
• LF AI & Data — ACP Joins Forces with A2A
• i-am-bee/acp (archived)