A2A 프로토콜 핵심 5가지, 에이전트 상호운용 실전 가이드

2026년 08월 03일 12 Min Read

{
“topic”: “A2A 프로토콜의 개념, 핵심 구성 요소, MCP와의 차이, 5가지 핵심 메커니즘, 실전 구현 예시와 도입 전략”,
“title”: “A2A 프로토콜 핵심 5가지, 에이전트 상호운용 실전 가이드”,
“content”: “

AI 에이전트가 빠르게 보급되면서 하나의 중요한 문제가 부각되고 있습니다. 각기 다른 프레임워크와 벤더에서 만들어진 에이전트들이 서로 소통하고 협업하려면 어떻게 해야 할까요? A2A 프로토콜(Agent-to-Agent Protocol)은 바로 이 문제를 해결하기 위해 Google이 주도하여 만든 오픈 표준입니다. 웹이 HTTP라는 공통 규약 덕분에 폭발적으로 성장했듯, 에이전트 생태계 역시 공통 통신 언어가 있어야 진정한 상호운용이 가능합니다.

2025년 4월 발표 이후 Salesforce, SAP, Atlassian, MongoDB 등 50개 이상의 기업과 조직이 지지를 선언했고, 2026년 여름 현재 에이전트 간 연동의 사실상 표준으로 빠르게 자리잡고 있습니다. 이 글에서는 A2A 프로토콜의 핵심 개념을 체계적으로 살펴보고, 이전 글에서 다룬 MCP와의 차이를 명확히 정리한 뒤, 5가지 핵심 메커니즘과 실전 구현까지 단계별로 안내합니다.

A2A 프로토콜이란 — 에이전트 시대의 공통 언어

A2A는 ‘Agent-to-Agent’의 약자로, 서로 다른 프레임워크·벤더·언어로 구축된 AI 에이전트들이 표준화된 방식으로 소통할 수 있게 해 주는 오픈 프로토콜입니다. Google이 공개한 A2A 사양은 HTTP와 JSON-RPC 2.0이라는 검증된 웹 표준 위에 구축되어 있어, 기존 인프라와의 호환성이 뛰어납니다.

왜 A2A가 필요한가

현실에서 기업의 AI 에이전트 환경은 단일하지 않습니다. 마케팅 팀은 LangGraph로 만든 콘텐츠 에이전트를 쓰고, 영업 팀은 Salesforce의 Agentforce를 사용하며, 개발 팀은 자체 구축한 코딩 에이전트를 운영하는 식입니다. 이런 에이전트들이 각각 사일로로 작동하면 결국 사람이 중간에서 복사-붙여넣기를 하는 수작업 허브가 되어 버립니다.

A2A는 이 사일로 문제를 세 가지 핵심 원칙으로 해결합니다.

에이전트 발견(Discovery) — 다른 에이전트가 무엇을 할 수 있는지 자동으로 알아낼 수 있어야 합니다.
능력 공개(Capability Exposure) — 각 에이전트가 자신의 기능과 제약을 표준 포맷으로 공개해야 합니다.
안전한 통신(Secure Communication) — 인증, 권한 부여, 암호화가 프로토콜 수준에서 보장되어야 합니다.

설계 철학 — 불투명한 협업

A2A의 핵심 설계 철학은 불투명성(Opaqueness)입니다. 요청을 보내는 클라이언트 에이전트는 상대방 에이전트의 내부 구현을 전혀 알 필요가 없습니다. 상대가 LLM 기반인지, 규칙 기반인지, 어떤 도구를 사용하는지는 중요하지 않습니다. 오직 ‘무엇을 할 수 있는지’와 ‘결과가 무엇인지’만 표준 인터페이스를 통해 주고받습니다. 이 덕분에 에이전트를 내부적으로 자유롭게 교체하거나 업그레이드해도 외부 연동이 깨지지 않습니다.

또한 A2A는 에이전트가 단순히 도구로서 호출되는 것이 아니라, 독립적인 행위자(actor)로서 자율적으로 판단하고 작업을 수행하는 모델을 전제합니다. 에이전트는 작업 도중 추가 정보가 필요하면 스스로 되물을 수 있고, 중간 진행 상황을 실시간으로 보고할 수도 있습니다. 이것이 단순한 API 호출과 A2A를 구분하는 가장 큰 차이입니다.

A2A 프로토콜의 핵심 구성 요소

A2A를 이해하려면 다섯 가지 핵심 개념을 먼저 파악해야 합니다. 이 요소들이 서로 어떻게 맞물리는지를 알면 전체 프로토콜의 작동 방식이 자연스럽게 보입니다.

1. Agent Card — 에이전트의 명함

Agent Card는 에이전트의 정체성과 능력을 선언하는 JSON 문서입니다. 사람으로 치면 명함이자 이력서에 해당합니다. 표준 경로인 /.well-known/agent.json에 호스팅하며, 클라이언트가 이 경로로 GET 요청을 보내 에이전트의 정보를 조회합니다.

Agent Card에 포함되는 주요 필드는 다음과 같습니다.

name — 에이전트의 표시 이름
description — 에이전트가 하는 일에 대한 설명
url — 에이전트의 A2A 엔드포인트 URL
skills — 수행 가능한 작업 목록. 각 스킬은 id, name, description, inputModes, outputModes를 포함합니다.
capabilities — 스트리밍 지원 여부, 푸시 알림 지원 여부 등 기능적 능력
authentication — 지원하는 인증 방식(OAuth2, API 키, Bearer 토큰 등)

예를 들어 번역 에이전트의 Agent Card는 이렇게 생겼습니다.

{\n  \"name\": \"TranslatorAgent\",\n  \"description\": \"다국어 번역을 수행하는 에이전트\",\n  \"url\": \"https://translator.example.com/a2a\",\n  \"version\": \"1.0.0\",\n  \"capabilities\": {\n    \"streaming\": true,\n    \"pushNotifications\": false\n  },\n  \"skills\": [\n    {\n      \"id\": \"translate-text\",\n      \"name\": \"텍스트 번역\",\n      \"description\": \"입력 텍스트를 지정 언어로 번역합니다\",\n      \"inputModes\": [\"text/plain\"],\n      \"outputModes\": [\"text/plain\"]\n    }\n  ],\n  \"authentication\": {\n    \"schemes\": [\"bearer\"]\n  }\n}

2. Task — 작업의 단위

Task는 에이전트에게 위임하는 작업 단위입니다. 고유 ID와 세션 ID를 갖고, 수명 주기(lifecycle) 동안 여러 상태를 거칩니다. 하나의 Task에는 여러 Message가 누적되고, 완료 시 하나 이상의 Artifact가 산출됩니다.

Task의 상태는 총 여섯 가지입니다.

submitted — 태스크가 접수됨
working — 에이전트가 작업 중
input-required — 추가 정보가 필요하여 대기 중
completed — 작업 완료
failed — 작업 실패
canceled — 사용자 또는 시스템에 의해 취소됨

이 상태 전이 모델은 에이전트의 작업이 단순한 요청-응답이 아니라, 복잡한 다단계 프로세스일 수 있음을 반영합니다.

3. Message — 대화의 최소 단위

Message는 클라이언트 에이전트와 서버 에이전트 사이의 대화를 구성하는 개별 메시지입니다. 각 메시지에는 역할(role)이 있습니다. user는 요청하는 측(클라이언트 에이전트), agent는 수행하는 측(서버 에이전트)을 의미합니다. 메시지 하나에는 여러 Part가 포함될 수 있어 텍스트, 파일, 구조화 데이터를 함께 보낼 수 있습니다.

4. Artifact — 작업의 산출물

Artifact는 에이전트가 Task를 수행한 결과물입니다. 이름, 설명, 그리고 실제 콘텐츠를 담은 Part들로 구성됩니다. 번역 에이전트라면 번역된 텍스트가 Artifact이고, 이미지 생성 에이전트라면 생성된 이미지 파일이 Artifact가 됩니다. 하나의 Task가 여러 Artifact를 산출할 수도 있습니다.

5. Part — 콘텐츠의 조각

Part는 Message와 Artifact에 담기는 콘텐츠의 최소 단위입니다. 세 가지 종류가 있습니다.

TextPart — 일반 텍스트. 가장 기본적인 형태입니다.
FilePart — 파일 데이터. Base64 인코딩된 인라인 데이터 또는 URI 참조로 전달합니다.
DataPart — JSON 형태의 구조화 데이터. 폼 입력 결과나 메타데이터 전달에 씁니다.

이 다섯 가지 구성 요소가 유기적으로 연결됩니다. 클라이언트가 Agent Card로 상대 에이전트를 발견하고, Task를 생성하여 Message를 보내면, 서버 에이전트가 작업을 수행하고 결과를 Artifact로 반환합니다. 각 Message와 Artifact의 내용물은 Part로 표현됩니다.

A2A와 MCP, 어떻게 다르고 어떻게 함께 쓰는가

이전 글에서 다룬 MCP(Model Context Protocol)를 이미 알고 계신 분이라면, A2A와의 관계가 궁금하실 겁니다. 결론부터 말하면, 이 둘은 경쟁 관계가 아니라 상호보완 관계입니다.

핵심 차이 — 수직 vs 수평

MCP는 AI 모델(또는 에이전트)이 외부 도구와 데이터 소스에 접근하는 표준입니다. 에이전트와 도구 사이의 수직적 통합이라 할 수 있습니다. 에이전트가 데이터베이스를 조회하거나, 파일 시스템을 탐색하거나, 웹 API를 호출할 때 MCP를 사용합니다.

A2A는 에이전트와 에이전트 사이의 통신 표준입니다. 동등한 위치의 에이전트들이 서로 작업을 위임하고 결과를 교환하는 수평적 통합입니다. 에이전트가 다른 에이전트에게 번역을 요청하거나, 분석 결과를 요청할 때 A2A를 사용합니다.

비유하자면, MCP는 요리사의 조리 도구(칼, 불, 오븐)에 해당하고, A2A는 주방 내 요리사들 사이의 주문서 시스템에 해당합니다. 전채 요리사가 메인 요리사에게 \”소스 준비됐으니 타이밍 맞춰 달라\”고 소통하는 것이 A2A라면, 각 요리사가 칼로 재료를 써는 것은 MCP입니다.

한눈에 보는 비교

목적 — MCP: 에이전트가 도구·데이터에 접근 / A2A: 에이전트 간 작업 위임과 협업
관계 구조 — MCP: 모델(호스트) → 도구(서버), 수직 / A2A: 에이전트 ↔ 에이전트, 수평
상대방 역할 — MCP: 도구는 수동적(호출당함) / A2A: 에이전트는 능동적(판단·질문·거부 가능)
통신 모델 — MCP: 함수 호출과 결과 반환 / A2A: 태스크 위임, 다중 턴 대화, 스트리밍
기반 기술 — MCP: JSON-RPC + stdio/SSE / A2A: JSON-RPC 2.0 + HTTP + SSE
발견 방식 — MCP: 설정 파일에 서버 등록 / A2A: /.well-known/agent.json 자동 발견

함께 사용하는 실전 시나리오

실무에서는 두 프로토콜을 함께 사용할 때 가장 강력합니다. 예를 들어 고객 지원 시스템을 생각해 봅시다. 프론트 에이전트가 고객의 문의를 받으면, A2A로 주문 조회 에이전트에게 주문 상태 확인을 위임합니다. 주문 조회 에이전트는 MCP를 통해 주문 데이터베이스에 접근하여 정보를 가져오고, 그 결과를 A2A 응답으로 프론트 에이전트에게 돌려줍니다. 프론트 에이전트는 이 정보를 바탕으로 고객에게 안내합니다.

이 구조에서 각 에이전트는 독립적으로 개발·배포·업데이트될 수 있고, MCP와 A2A라는 표준 인터페이스만 지키면 전체 시스템이 매끄럽게 작동합니다.

A2A 프로토콜의 5가지 핵심 메커니즘

A2A 프로토콜이 실제로 작동하는 방식은 다섯 가지 핵심 메커니즘으로 설명할 수 있습니다. 각 메커니즘이 어떤 문제를 해결하며, 실전에서 어떻게 활용되는지 하나씩 살펴보겠습니다.

메커니즘 1 — 에이전트 발견(Agent Discovery)

에이전트 간 협업의 첫 단계는 상대방을 찾는 것입니다. A2A에서는 각 에이전트가 자신의 Agent Card를 /.well-known/agent.json 경로에 호스팅합니다. 이는 웹사이트의 robots.txt나 .well-known/openid-configuration과 같은 패턴으로, 표준 경로를 통해 자동 발견이 가능합니다.

클라이언트 에이전트는 서버 에이전트의 도메인만 알면 Agent Card를 조회할 수 있고, 여기서 상대의 이름, 설명, 스킬 목록, 지원하는 입출력 형식, 인증 방식을 모두 파악합니다. 대규모 조직에서는 에이전트 레지스트리(Agent Registry)를 두어 여러 에이전트의 Agent Card를 중앙에서 색인하고 검색할 수도 있습니다.

능력 기반 검색도 중요한 사용 패턴입니다. 예를 들어 \”이미지 생성이 가능한 에이전트\”를 찾을 때, 레지스트리에 등록된 Agent Card들의 skills를 검색하여 적합한 에이전트를 자동으로 매칭할 수 있습니다. 이를 통해 에이전트가 다른 에이전트를 동적으로 발견하고 활용하는 자율적 생태계가 형성됩니다.

메커니즘 2 — 태스크 관리(Task Lifecycle)

A2A의 모든 작업은 Task 단위로 관리됩니다. JSON-RPC 2.0 사양에 따라 세 가지 메서드가 정의되어 있습니다.

tasks/send — 새로운 태스크를 생성하거나 기존 태스크에 메시지를 추가합니다. 이 메서드 하나로 태스크 생성과 후속 대화를 모두 처리합니다.
tasks/get — 특정 태스크의 현재 상태와 히스토리를 조회합니다. 비동기 패턴에서 폴링 용도로 사용합니다.
tasks/cancel — 진행 중인 태스크를 취소합니다.

태스크의 상태 전이는 명확하게 정의되어 있습니다. 클라이언트가 tasks/send로 요청을 보내면 submitted 상태가 되고, 에이전트가 처리를 시작하면 working으로 전환됩니다. 작업이 성공적으로 끝나면 completed, 실패하면 failed가 됩니다. 여기서 특별한 것은 input-required 상태입니다. 에이전트가 작업 도중 추가 정보가 필요하면 이 상태로 전환하여 클라이언트에게 되묻습니다.

이 상태 모델 덕분에 에이전트의 작업을 추적하고, 장시간 작업의 진행 상황을 모니터링하며, 필요할 때 중단시키는 것이 모두 가능합니다.

메커니즘 3 — 다중 턴 협업(Multi-turn Collaboration)

실제 업무에서 작업 요청이 한 번의 메시지로 끝나는 경우는 드뭅니다. 번역 에이전트에게 \”이 문서를 번역해 줘\”라고 요청했는데, 에이전트가 \”대상 언어가 무엇인가요?\”라고 되묻는 상황이 자연스럽게 발생합니다.

A2A는 이런 다중 턴 대화를 기본적으로 지원합니다. 서버 에이전트가 태스크를 input-required 상태로 전환하면서 질문 메시지를 보내고, 클라이언트 에이전트가 같은 태스크 ID로 tasks/send를 다시 호출하여 추가 정보를 제공합니다. 이 대화는 태스크가 최종 상태(completed/failed/canceled)에 도달할 때까지 계속될 수 있습니다.

이 메커니즘은 에이전트가 단순한 함수 호출이 아니라 독립적인 판단 주체임을 보여줍니다. 에이전트는 모호한 요청을 받으면 추측하지 않고 명확히 물을 수 있고, 여러 옵션 중 선택이 필요하면 제안과 함께 선택을 요청할 수 있습니다.

메커니즘 4 — 실시간 스트리밍(SSE Streaming)

긴 작업의 진행 상황을 실시간으로 확인하고 싶을 때는 스트리밍을 사용합니다. A2A에서는 tasks/sendSubscribe 메서드를 통해 Server-Sent Events(SSE) 스트림을 열 수 있습니다.

스트리밍이 활성화되면 서버 에이전트는 두 가지 종류의 이벤트를 실시간으로 보냅니다.

TaskStatusUpdateEvent — 태스크의 상태가 변경될 때 발생합니다. working에서 completed로 전환되거나, 중간에 input-required로 바뀔 때마다 이벤트가 전송됩니다.
TaskArtifactUpdateEvent — 새로운 Artifact가 생성되거나 기존 Artifact가 업데이트될 때 발생합니다. 텍스트 생성 에이전트라면 문장이 완성될 때마다 이 이벤트로 중간 결과를 전송할 수 있습니다.

스트리밍은 선택적 기능이며, Agent Card의 capabilities.streaming 필드에서 지원 여부를 확인할 수 있습니다. 지원하지 않는 에이전트에게 tasks/sendSubscribe를 호출하면 에러가 반환됩니다.

메커니즘 5 — 비동기 푸시 알림(Push Notifications)

스트리밍은 연결을 계속 유지해야 하므로, 수 시간 또는 수일이 걸리는 장기 작업에는 적합하지 않습니다. 이럴 때는 푸시 알림을 사용합니다.

클라이언트 에이전트가 tasks/pushNotification/set 메서드로 알림 받을 웹훅 URL을 등록해 두면, 서버 에이전트가 작업 상태 변경이나 결과 완료 시 해당 URL로 HTTP POST를 보냅니다. 클라이언트는 연결을 끊고 다른 작업을 하다가 알림이 오면 tasks/get으로 결과를 가져가면 됩니다.

푸시 알림은 보안 강화를 위해 JSON Web Token(JWT) 기반 인증을 지원합니다. 알림을 등록할 때 인증 정보를 함께 설정할 수 있어, 서버가 보내는 알림이 진짜 해당 에이전트로부터 온 것인지 검증할 수 있습니다.

이 다섯 가지 메커니즘을 조합하면 다양한 통신 패턴을 구현할 수 있습니다. 간단한 작업은 tasks/send 한 번으로 끝나고, 복잡한 대화형 작업은 multi-turn으로 진행하며, UX가 중요한 작업은 스트리밍으로 실시간 피드백을 제공하고, 배치 작업은 푸시 알림으로 비동기 처리합니다.

실전 구현 — A2A 에이전트 만들어 보기

개념을 이해했으니 이제 직접 만들어 봅시다. Python과 FastAPI를 사용해 간단한 A2A 서버 에이전트와 클라이언트를 구현하는 과정을 단계별로 살펴보겠습니다.

1단계 — Agent Card 작성

가장 먼저 에이전트의 Agent Card를 정의합니다. 요약(summarization) 에이전트를 만든다고 가정하겠습니다.

{\n  \"name\": \"SummaryAgent\",\n  \"description\": \"긴 텍스트를 핵심 요약으로 압축합니다\",\n  \"url\": \"http://localhost:9000/a2a\",\n  \"version\": \"0.1.0\",\n  \"capabilities\": {\n    \"streaming\": false,\n    \"pushNotifications\": false\n  },\n  \"skills\": [\n    {\n      \"id\": \"summarize\",\n      \"name\": \"텍스트 요약\",\n      \"description\": \"입력된 텍스트의 핵심을 3~5문장으로 요약합니다\",\n      \"inputModes\": [\"text/plain\"],\n      \"outputModes\": [\"text/plain\"]\n    }\n  ]\n}

이 JSON을 /.well-known/agent.json 경로에서 서빙하면 다른 에이전트가 자동으로 발견할 수 있습니다.

2단계 — A2A 서버 구현

A2A 서버는 크게 세 가지를 처리해야 합니다. Agent Card 서빙, JSON-RPC 요청 라우팅, 그리고 실제 태스크 처리입니다.

# 핵심 구조만 보여주는 의사 코드\nfrom fastapi import FastAPI, Request\nfrom fastapi.responses import JSONResponse\nimport uuid\n\napp = FastAPI()\ntasks_store = {}  # 태스크 저장소\n\[email protected](\"/.well-known/agent.json\")\nasync def agent_card():\n    return {\"name\": \"SummaryAgent\", ...}  # Agent Card 반환\n\[email protected](\"/a2a\")\nasync def handle_jsonrpc(request: Request):\n    body = await request.json()\n    method = body.get(\"method\")\n\n    if method == \"tasks/send\":\n        return await handle_tasks_send(body)\n    elif method == \"tasks/get\":\n        return await handle_tasks_get(body)\n    elif method == \"tasks/cancel\":\n        return await handle_tasks_cancel(body)\n    else:\n        return jsonrpc_error(-32601, \"Method not found\")\n\nasync def handle_tasks_send(body):\n    params = body[\"params\"]\n    task_id = params.get(\"id\", str(uuid.uuid4()))\n    message = params[\"message\"]\n    input_text = message[\"parts\"][0][\"text\"]\n\n    # 여기서 실제 요약 로직 수행\n    summary = await summarize(input_text)\n\n    task = {\n        \"id\": task_id,\n        \"status\": {\"state\": \"completed\"},\n        \"artifacts\": [{\n            \"name\": \"summary\",\n            \"parts\": [{\"type\": \"text\", \"text\": summary}]\n        }]\n    }\n    tasks_store[task_id] = task\n\n    return jsonrpc_result(body[\"id\"], task)

이 구조에서 중요한 점은 JSON-RPC 2.0 스펙을 정확히 따르는 것입니다. 요청에는 jsonrpc, method, params, id 필드가 있고, 응답에는 jsonrpc, result(또는 error), id 필드가 있어야 합니다. 이 포맷을 지키면 어떤 A2A 클라이언트와도 호환됩니다.

3단계 — A2A 클라이언트 구현

다른 에이전트(또는 오케스트레이터)에서 위 에이전트를 호출하는 클라이언트 코드입니다.

import httpx\n\nasync def call_summary_agent(text: str) -> str:\n    # 1. Agent Card 조회로 에이전트 발견\n    async with httpx.AsyncClient() as client:\n        card = await client.get(\n            \"http://localhost:9000/.well-known/agent.json\"\n        )\n        agent_url = card.json()[\"url\"]\n\n        # 2. tasks/send로 태스크 생성\n        response = await client.post(agent_url, json={\n            \"jsonrpc\": \"2.0\",\n            \"id\": \"req-001\",\n            \"method\": \"tasks/send\",\n            \"params\": {\n                \"id\": \"task-001\",\n                \"message\": {\n                    \"role\": \"user\",\n                    \"parts\": [{\"type\": \"text\", \"text\": text}]\n                }\n            }\n        })\n\n        result = response.json()[\"result\"]\n        if result[\"status\"][\"state\"] == \"completed\":\n            return result[\"artifacts\"][0][\"parts\"][0][\"text\"]\n        elif result[\"status\"][\"state\"] == \"input-required\":\n            # 추가 정보 요청 처리\n            pass

클라이언트 측에서 주의할 점은 에이전트가 input-required 상태를 반환할 수 있다는 것입니다. 단순한 API 호출과 달리, 에이전트의 응답이 항상 최종 결과가 아닐 수 있으므로 상태를 확인하고 적절히 대응하는 로직이 필요합니다.

4단계 — multi-turn 대화 처리

에이전트가 추가 정보를 요청하는 시나리오를 처리해 봅시다. 서버 측에서 요약 길이에 대한 선호를 묻는 경우입니다.

# 서버 측 — 요약 길이 미지정 시 되묻기\nasync def handle_tasks_send(body):\n    params = body[\"params\"]\n    message = params[\"message\"]\n    input_text = message[\"parts\"][0][\"text\"]\n\n    # 기존 태스크에 대한 후속 메시지인지 확인\n    task_id = params.get(\"id\")\n    existing = tasks_store.get(task_id)\n\n    if existing and existing[\"status\"][\"state\"] == \"input-required\":\n        # 클라이언트가 추가 정보를 보낸 것\n        length_pref = input_text  # \"3줄\" 등\n        original = existing[\"original_text\"]\n        summary = await summarize(original, length=length_pref)\n        existing[\"status\"] = {\"state\": \"completed\"}\n        existing[\"artifacts\"] = [{...}]\n        return jsonrpc_result(body[\"id\"], existing)\n\n    # 새 태스크 — 요약 길이 선호 확인\n    task = {\n        \"id\": task_id,\n        \"status\": {\n            \"state\": \"input-required\",\n            \"message\": {\n                \"role\": \"agent\",\n                \"parts\": [{\"type\": \"text\",\n                    \"text\": \"몇 줄 정도로 요약할까요? (1줄/3줄/5줄)\"}]\n            }\n        },\n        \"original_text\": input_text\n    }\n    tasks_store[task_id] = task\n    return jsonrpc_result(body[\"id\"], task)

이처럼 에이전트가 대화의 주도권을 가져갈 수 있다는 점이 A2A의 큰 특징입니다. 단순히 시키는 대로 실행하는 함수가 아니라, 상황을 판단하고 필요한 정보를 능동적으로 수집하는 자율적 행위자로서 동작합니다.

도입 전략 — A2A를 우리 시스템에 적용하려면

A2A를 실제 시스템에 도입할 때는 점진적으로 접근하는 것이 좋습니다. 한 번에 모든 에이전트를 A2A로 전환하려 하면 복잡도가 급격히 올라갑니다.

단계별 도입 로드맵

1단계 — Agent Card부터 시작하세요. 이미 운영 중인 에이전트가 있다면, Agent Card를 작성하여 /.well-known/agent.json에 배포하는 것만으로도 A2A 생태계의 일원이 됩니다. 이 단계에서는 기존 에이전트의 코드를 전혀 수정할 필요가 없습니다. 에이전트의 능력을 표준 포맷으로 선언하는 것만으로도 발견 가능성과 문서화 효과를 얻습니다.

2단계 — 하나의 에이전트를 A2A 서버로 래핑하세요. 가장 단순하고 독립적인 에이전트 하나를 골라 A2A 엔드포인트를 추가합니다. 기존 기능을 tasks/send 핸들러 안에서 호출하는 얇은 어댑터 레이어를 만드는 것입니다. 이 단계에서 JSON-RPC 처리, 태스크 상태 관리, 에러 핸들링의 기본 패턴을 확립합니다.

3단계 — 에이전트 간 연동 시나리오를 구현하세요. 두 번째 에이전트를 A2A로 래핑하고, 첫 번째 에이전트가 두 번째 에이전트를 A2A로 호출하는 시나리오를 구현합니다. 이 과정에서 에이전트 발견, 태스크 위임, 결과 수집의 전체 흐름을 경험합니다.

4단계 — 보안과 운영을 강화하세요. 인증(OAuth2/API 키), 속도 제한, 로깅, 모니터링을 추가합니다. 프로덕션 환경에서는 에이전트 간 통신에도 TLS를 적용하고, Agent Card의 authentication 필드를 적절히 설정해야 합니다.

도입 시 주의사항

책임 범위를 명확히 하세요. 에이전트 A가 에이전트 B에게 작업을 위임했을 때, 결과의 정확성은 누가 책임지는지를 미리 정해야 합니다. 특히 에이전트 체인이 길어지면 에러의 근원을 추적하기 어려워집니다.
에러 처리를 꼼꼼히 설계하세요. 네트워크 타임아웃, 에이전트 다운, 비정상 응답 등 다양한 실패 시나리오를 대비해야 합니다. 재시도 정책, 폴백 에이전트, 서킷 브레이커 패턴을 적용하는 것을 권장합니다.
멱등성을 확보하세요. 같은 태스크 ID로 tasks/send를 두 번 보냈을 때 부작용 없이 동일한 결과가 반환되어야 합니다. 네트워크 재시도 상황에서의 안정성을 위해 필수입니다.
관찰 가능성을 확보하세요. 분산 추적(distributed tracing)을 도입하여 에이전트 간 호출 체인을 시각화하고, 각 에이전트의 응답 시간과 성공률을 모니터링하세요. OpenTelemetry와 같은 표준을 활용하면 좋습니다.

에코시스템 현황

2026년 여름 현재, A2A 생태계는 빠르게 성장하고 있습니다. Google의 Agent Development Kit(ADK)는 A2A를 기본 지원하며, LangChain/LangGraph, CrewAI, Microsoft Semantic Kernel 등 주요 에이전트 프레임워크들도 A2A 어댑터를 제공하거나 개발 중입니다. Salesforce Agentforce, SAP Joule 등 엔터프라이즈 AI 플랫폼도 A2A 통합을 발표했습니다.

아직 사양이 진화 중이므로 버전 호환성에 주의해야 하지만, 핵심 개념(Agent Card, Task, Message)은 안정화된 상태입니다. 지금 도입을 시작해도 기본 구조가 크게 바뀔 가능성은 낮습니다.

마무리 — 에이전트 생태계의 HTTP가 될 수 있을까

A2A 프로토콜은 AI 에이전트 생태계에 빠져 있던 마지막 퍼즐 조각입니다. MCP가 에이전트와 도구의 연결을 표준화했다면, A2A는 에이전트와 에이전트의 연결을 표준화합니다. 두 프로토콜이 함께 작동하면, 이론상 어떤 에이전트든 어떤 도구와 어떤 다른 에이전트와도 소통할 수 있는 범용 통신 레이어가 완성됩니다.

물론 아직 갈 길이 있습니다. 보안 모델의 성숙, 대규모 에이전트 발견 메커니즘의 확립, 사양의 안정화가 필요합니다. 하지만 웹 초창기에 HTTP가 그랬듯, 충분히 실용적이고 단순한 표준은 빠르게 채택됩니다.

시작은 어렵지 않습니다. 기존 에이전트에 Agent Card 하나를 작성하는 것이 A2A 세계로의 첫 걸음입니다. 이 작은 JSON 파일 하나가 여러분의 에이전트를 고립된 섬에서 연결된 대륙으로 바꾸어 줄 것입니다. 이번 여름, 직접 Agent Card를 만들어 보면서 에이전트 상호운용의 미래를 경험해 보시기 바랍니다.

“,
“excerpt”: “A2A 프로토콜의 핵심 구성 요소와 5가지 메커니즘, MCP와의 차이, 실전 구현 예시까지 에이전트 상호운용 표준을 완벽 정리합니다.”,
“tags”: [“A2A 프로토콜”, “AI 에이전트”, “에이전트 상호운용”, “MCP”, “멀티에이전트”]
}

자주 묻는 질문

A2A 프로토콜과 MCP의 차이점은 무엇인가요?

MCP는 에이전트가 외부 도구나 데이터 소스를 호출하는 데 초점을 맞춘 프로토콜인 반면, A2A는 독립적인 AI 에이전트들이 서로 대등한 행위자로서 소통하고 협업하기 위한 표준입니다. A2A에서는 상대 에이전트의 내부 구현을 알 필요 없이 표준 인터페이스만으로 작업을 요청하고 결과를 받을 수 있으며, 작업 도중 추가 정보를 되묻거나 중간 진행 상황을 실시간으로 보고하는 것도 가능합니다.

A2A 프로토콜에서 Agent Card란 무엇이고 어떻게 사용되나요?

Agent Card는 에이전트의 정체성과 능력을 선언하는 JSON 문서로, 사람의 명함이자 이력서에 해당합니다. 표준 경로인 /.well-known/agent.json에 호스팅되며, 클라이언트 에이전트가 이 경로로 GET 요청을 보내 상대 에이전트가 무엇을 할 수 있는지 자동으로 조회할 수 있습니다.

A2A 프로토콜은 어떤 기술 표준 위에 구축되어 있나요?

A2A 프로토콜은 HTTP와 JSON-RPC 2.0이라는 검증된 웹 표준 위에 구축되어 있어 기존 인프라와의 호환성이 뛰어납니다. Google이 주도하여 만든 오픈 표준으로, 2025년 4월 발표 이후 Salesforce, SAP, Atlassian, MongoDB 등 50개 이상의 기업과 조직이 지지를 선언하며 에이전트 간 연동의 사실상 표준으로 자리잡고 있습니다.

🔗 함께 보면 좋은 글

참고 자료

Google A2A Protocol 공식 문서 — A2A 프로토콜의 사양, 설계 원칙, 구현 가이드를 제공하는 공식 레퍼런스
Google A2A GitHub 저장소 — A2A 프로토콜 스펙과 샘플 구현 코드가 포함된 공식 오픈소스 저장소

Tags:

에이전트 일상 정보