에이전트 간의 새로운 대화 방식, A2A란?
최근 구글이 주도하여 오픈소스로 공개한 A2A(Agent-to-Agent) 프로토콜이 주목받고 있습니다. 다양한 AI 에이전트들이 표준화된 방식으로 서로 대화하고 협력할 수 있도록 설계된 이 프로토콜은, 복잡한 멀티에이전트 통신의 허들을 크게 낮춰줍니다. 이번 글에서는 A2A가 무엇인지, 왜 중요한지, 그리고 어떤 방식으로 복잡함을 단순화했는지를 살펴봅니다.
A2A 개념
A2A는 "Agent to Agent"의 약자로, 서로 다른 AI 에이전트 간의 직접적인 상호작용을 가능하게 하는 표준 통신 방식입니다. 기존에는 각각의 에이전트가 제각기 다른 인터페이스, 포맷, 인증 방식 등을 사용해 통신을 위해 많은 사전 설정과 커스텀 개발이 필요했습니다. A2A는 이 모든 걸 표준화된 하나의 틀로 묶어, "어떤 에이전트든 A2A만 지키면 누구와도 대화할 수 있는 세상"을 지향합니다.
왜 A2A가 필요한가?
- 멀티에이전트 시대의 도래: LLM과 에이전트 오케스트레이션이 급속히 확산되며, 하나의 시스템 내에서 다양한 역할의 에이전트들이 동시에 동작하고 있습니다.
- 엔터프라이즈 연동의 표준화 필요성: 기업 내부 시스템 또는 파트너 기업의 AI 서비스와도 연결되어야 할 일이 많아졌습니다.
- 기존의 한계: 기존에는 에이전트 간 통신마다 맞춤형 API, 커스텀 인증, 복잡한 메시지 포맷이 필요했지만, 이는 확장성과 유지보수 측면에서 큰 부담이었습니다.
A2A의 주요 특징
- 표준화된 Task 기반 통신 구조
모든 통신은 "Task" 객체를 중심으로 이루어지며, 이 객체는 입력, 출력, 상태(submitted → working → completed) 등의 필드를 갖습니다. - RESTful HTTP 통신
에이전트 간의 상호작용은 HTTP 기반의 단일 엔드포인트(/tasks)를 통해 이루어지며, 구현이 간단하고 범용적입니다. - 확장성과 유연성
입력/출력 구조나 인증 방식이 명확하게 정의되어 있으면서도 자유롭게 확장 가능하여 다양한 도메인에 적용할 수 있습니다. - 자동화와 오케스트레이션에 최적화
에이전트 간 상태 추적이 가능하고, 메시지 기반으로 이어지는 작업 흐름을 손쉽게 구성할 수 있습니다. - 높은 상호 운용성
서로 다른 언어나 프레임워크로 작성된 에이전트라도 A2A 스펙만 따르면 문제없이 협력할 수 있습니다.
A2A의 핵심 구성 요소
핵심 컴포넌트 - Agent Card
A2A에서 가장 중요한 구성 요소 중 하나는 Agent Card입니다. Agent Card는 해당 에이전트가 어떤 역할을 하고 어떤 작업을 수행할 수 있는지를 설명하는 JSON 기반의 메타데이터 파일입니다. 이 파일을 통해 에이전트를 사전 통합 없이도 쉽게 탐색하고 호출할 수 있습니다.
주요 필드
- name: 에이전트 이름
- description: 에이전트 기능 요약
- input_schema: 입력 데이터 포맷 (예: JSON 구조)
- output_schema: 출력 데이터 포맷
- endpoints: REST 엔드포인트 정보 (예: POST /tasks)
- authentication: 필요한 인증 방식 (예: API Key, OAuth 등)
Agent Card Json 예시
{
"name": "Google Maps Agent",
"description": "An agent that helps with map-related tasks",
"url": "https://maps-agent.example.com",
"provider": {
"name": "Google",
"url": "https://google.com"
},
"capabilities": [
{
"type": "route_planning",
"description": "Plan routes between locations"
},
{
"type": "custom_map",
"description": "Create custom maps with points of interest"
}
]
}Agent Card는 사람뿐만 아니라 다른 에이전트가 파싱해서 사용할 수 있도록 설계되어 있어, 에이전트 간의 자동 협업, 자동 탐색, 자동 호출을 가능하게 합니다.
핵심 컴포넌트 - Agent Discovery
에이전트들이 협업을 하려면, 먼저 서로를 찾아야(discover) 합니다. A2A는 이를 위한 여러 가지 discovery 메커니즘을 지원합니다.
1. DNS 기반 Discovery
- 에이전트는 도메인 이름을 통해 발견됩니다.
- 예: https://agent.example.com/agent.json와 같은 위치에 Agent Card를 호스팅
- 클라이언트는 DNS로 해당 URL을 조회하여 정보를 자동 수집할 수 있습니다.
2. Registry 기반 Discovery
- 조직 또는 플랫폼 내에 신뢰된 에이전트 목록을 관리하는 레지스트리를 사용합니다.
- 레지스트리는 에이전트의 Agent Card를 미리 인덱싱하고 제공하여 빠른 탐색을 가능하게 합니다.
3. Private Discovery
- 에이전트의 endpoint를 수동으로 직접 설정하여 사용합니다.
- 가장 단순하고 보안 제어가 명확한 방식으로, 테스트 환경이나 제한된 협업 환경에서 주로 활용됩니다.
이러한 다양한 discovery 방법을 통해 A2A는 개방형 생태계뿐 아니라 폐쇄형 엔터프라이즈 환경에서도 유연하게 적용될 수 있습니다.
핵심 컴포넌트 - Task Processing Flow
A2A 통신은 "Task"라는 단위를 중심으로 이루어집니다. 각 Task는 다음과 같은 단계로 처리됩니다:
- submitted: 클라이언트(또는 다른 에이전트)가 Task를 생성하고 대상 에이전트에게 전송합니다.
- working: 에이전트가 작업을 수락하고 처리 중 상태로 전환됩니다.
- completed / failed: 작업이 완료되거나 오류가 발생했을 경우 해당 상태로 전환됩니다.
각 상태는 API를 통해 명시적으로 업데이트되며, 클라이언트는 상태를 주기적으로 폴링하거나 웹훅 등의 방식으로 결과를 전달받을 수 있습니다. 이처럼 명확한 상태 기반 처리 방식은 분산 환경에서의 신뢰성과 추적 가능성을 확보하는 데 매우 유리합니다.
또한, Task에는 입력(input), 출력(output), 상태(state), 작업 히스토리 등 다양한 메타데이터가 함께 포함되어 있어, 협업 및 재사용이 용이합니다.
핵심 컴포넌트 - 표준 HTTP 인터페이스 (Communication Protocol)
A2A는 다양한 통신 요구를 충족시키기 위해 다음과 같은 프로토콜과 데이터 포맷을 지원합니다:
- HTTP/HTTPS
가장 기본적인 요청-응답 방식의 통신에 사용됩니다. 대부분의 RESTful API와 동일한 방식으로 동작하며, 에이전트 간 상호작용을 쉽게 구성할 수 있습니다. - JSON-RPC
메서드 호출 기반 통신이 필요한 경우에 사용되며, 구조화된 요청과 응답을 처리할 수 있습니다. 복잡한 함수형 인터페이스 정의에 적합합니다. - Server-Sent Events (SSE)
스트리밍 응답이 필요한 상황에 적합하며, 에이전트가 작업 진행 중에 중간 결과를 실시간으로 전달할 수 있도록 합니다. - JSON
A2A의 표준 데이터 교환 포맷으로, 에이전트 간 주고받는 모든 메시지 구조는 JSON으로 표현됩니다.
이러한 통신 프로토콜 덕분에 A2A는 다양한 유형의 에이전트 환경(싱글턴, 스트리밍, 동기/비동기)에 유연하게 대응할 수 있으며, 기존 웹 표준과도 자연스럽게 통합됩니다.
핵심 컴포넌트 - 고급 기능
A2A는 강력하고 실용적인 상호작용을 위해 다음과 같은 고급 기능도 제공합니다
- 멀티모달 커뮤니케이션(Multimodal Communication)
단순 텍스트뿐 아니라 이미지, 오디오 등 다양한 데이터 형식을 처리할 수 있어, 시각/청각 기반의 복합 에이전트 구현이 가능합니다. - 스트리밍 지원(Streaming)
장시간 수행되는 작업이나 실시간 피드백이 필요한 경우, SSE 기반 스트리밍 응답으로 점진적 결과 전달이 가능합니다. - 표준화된 에러 처리(Error Handling)
에이전트 간 통신 오류를 일관성 있게 처리하기 위해, 오류 형식이 표준화되어 있어 디버깅이 용이합니다. - 명확성 요청(Clarification Requests)
작업 수행 도중 추가적인 정보가 필요할 경우, 에이전트가 상대방에게 추가 질문을 할 수 있는 기능을 지원합니다.
이러한 고급 기능들은 에이전트 간의 상호작용을 더욱 풍부하고 안정적으로 만들어주며, 현실적인 서비스 시나리오에 적합한 유연성을 제공합니다.
A2A는 어떻게 복잡함을 단순화했나?
- N:N 통신 → 1:N 메시지 구조
각 에이전트는 A2A 스펙만 따르면 되므로, 새로운 에이전트 추가 시 다른 모든 에이전트와 따로 설정할 필요 없음. - 프롬프트 기반/LLM 기반 에이전트도 쉽게 통합 가능
- 상태 기반(task lifecycle) 처리로 복잡한 분산 로직도 추적 가능
- 보안, 인증, 입출력 정의 모두 표준화로 협업이 쉬움
A2A vs MCP
A2A와 비교되는 개념으로는 MCP(Model Context Protocol)가 있습니다. 두 프로토콜은 모두 언어 모델 기반 시스템의 상호작용을 다루지만, 적용 범위와 목적이 다릅니다.
| 구분 | MCP | A2A |
| 초점 | LLM과 도구(API, DB 등)의 연결 | 완전한 에이전트(LLM+도구) 간 통신 |
| 역할 비유 | 정비사가 사용하는 공구와의 관계 | 정비사 ↔ 고객/부품업체와의 대화 |
| 목적 | LLM이 외부 기능을 활용하기 위한 인터페이스 정의 | 에이전트 간 협력/조율을 위한 통신 체계 정의 |
| 구조 | 단일 LLM 내부의 컨텍스트 확장 | 여러 에이전트 간 작업 분담 및 메시지 전달 |
| 예시 | LLM이 DB에서 정보 조회하거나 API를 호출할 수 있도록 설정 | 에이전트 A가 에이전트 B에 작업 위임하거나 결과 요청 |
따라서 MCP는 LLM이 "도구를 어떻게 사용할지"에 초점을 맞추고, A2A는 에이전트들이 "서로 어떻게 협업할지"에 중점을 둡니다. 둘은 경쟁 관계가 아니라, 함께 사용될 때 시너지를 내는 구조입니다.
마무리하며
A2A는 단순한 기술 스펙을 넘어, "AI 에이전트들이 함께 일할 수 있는 언어"입니다. 다양한 AI 프레임워크와 LLM 에이전트들이 등장하는 지금, A2A는 이들을 하나의 거대한 팀으로 엮어줄 연결고리가 되어가고 있습니다. 앞으로 더 많은 서비스와 제품들이 A2A를 기반으로 통합되는 미래를 기대해봅니다.
