A2A(Agent2Agent) 프로토콜이란?
서로 다른 환경이나 프레임워크에서 개발된 AI 에이전트들이 원활하게 소통하고 협업할 수 있도록 설계된 개방형 통신 표준입니다.
2025년 4월 구글(Google)이 50여 개의 파트너사와 함께 처음 발표했으며, 현재는 리눅스 파운데이션(Linux Foundation) 산하에서 오픈소스 프로젝트로 관리되고 있습니다. 기존에는 여러 AI 에이전트를 연결하려면 각 벤더사(OpenAI, 구글, MS 등)의 규격에 맞춘 복잡한 맞춤형 연동 작업이 필요했지만, A2A는 에이전트 생태계의 '공용어' 혹은 '범용 번역기' 역할을 하여 이러한 벤더 종속성을 없애줍니다.
1. MCP와 A2A의 차이점
A2A를 이해할 때 가장 자주 비교되는 것이 앤스로픽(Anthropic)이 주도한 MCP(Model Context Protocol)입니다. 이 둘은 경쟁 관계가 아닌, 상호 보완적인 역할을 수행합니다.
- MCP (Agent ↔ Tool/Data): AI 에이전트가 데이터베이스, 로컬 파일시스템, 외부 API 등 '도구와 데이터'에 연결하기 위한 표준입니다.
- A2A (Agent ↔ Agent): AI 에이전트가 다른 AI 에이전트와 '대화하고 작업을 위임'하기 위한 표준입니다.
예를 들면 사용자의 요청을 받은 '메인 에이전트'가 A2A를 통해 원격에 있는 '재고 관리 에이전트'에게 상황을 묻습니다. 호출을 받은 재고 관리 에이전트는 MCP를 사용해 사내 DB를 조회한 뒤, 다시 A2A를 통해 메인 에이전트에게 분석 결과를 전달합니다.
2. A2A 핵심 아키텍처
A2A는 이미 개발자들에게 친숙한 웹 표준(HTTP, JSON-RPC 2.0, SSE)을 기반으로 동작하며, 다음 4가지 핵심 요소로 구성됩니다.
- A2A Client (클라이언트 에이전트) 사용자를 대신하거나 다른 프로세스의 일환으로, 원격에 있는 다른 에이전트에게 작업을 할당하거나 정보를 요청하는 주체
- A2A Server (원격 에이전트) 클라이언트의 요청을 수신하고, 작업을 처리하여 결과물을 반환하거나 진행 상태를 업데이트하는 에이전트. HTTP 엔드포인트를 노출하여 통신을 대기
- Agent Card (에이전트 카드) 에이전트의 '명함'이자 'API 명세서' 역할을 하는 JSON 문서(일반적으로 .well-known/agent.json 경로에 위치)
- 에이전트의 이름, 설명, 엔드포인트 URL, 지원 기능(Capabilities), 입출력 방식 등의 메타데이터가 담겨 있습니다.
- 이를 통해 에이전트들은 중앙 통제 없이도 서로의 능력을 자동으로 '발견(Discovery)'하고 즉각적인 팀플레이를 할 수 있습니다.
- Task (작업) 클라이언트가 서버(에이전트)에 요청하는 단위 업무입니다. 상태값(submitted, working, completed 등), 결과물(artifacts), 메시지 이력(history) 등을 포함하는 객체 형태이며, 장기간 실행되는 비동기 작업의 상태 동기화도 지원합니다.
3. A2A 적용 시 장점
- 진정한 플러그앤플레이(Plug & Play) 확장성: 새로운 AI 에이전트를 시스템에 추가할 때마다 복잡한 미들웨어나 코드를 짤 필요 없이, 에이전트 카드만 등록하면 기존 에이전트들이 이를 인식하고 즉시 협업을 시작할 수 있습니다.
- 유연한 멀티 에이전트 오케스트레이션: 하나의 거대한 AI 모델에 모든 것을 의존하는 대신, 각자의 전문성(코드 리뷰, 보안 검수, 데이터 분석 등)을 가진 작은 에이전트들을 조립하여 복잡한 비즈니스 파이프라인을 효율적으로 구축할 수 있습니다.
- 낮은 진입 장벽: HTTP, JSON 기반의 아키텍처를 채택하여, 기존의 웹 인프라와 개발 스택을 그대로 활용해 AI 시스템을 확장할 수 있습니다.
4. A2A에서 이미지 or 문서 처리 방법
A2A(Agent2Agent) 프로토콜은 기본적으로 HTTP와 JSON을 기반으로 텍스트 데이터를 주고받는 아키텍처를 가지고 있습니다. 따라서 이미지나 문서 같은 바이너리(Binary) 첨부파일을 통신할 때는 메일 시스템처럼 파일을 통째로 욱여넣기보다는 데이터의 크기와 환경에 따라 구조화된 방식을 사용합니다.
대표적으로 다음 3가지 방식을 통해 첨부파일을 주고받습니다.
① URL/URI 기반 참조
대용량 파일이나 여러 개의 문서를 전달할 때 에이전트 간의 네트워크 부하를 줄이기 위해 사용하는 방식입니다. 파일을 메시지에 직접 첨부하지 않고, 파일이 저장된 '위치(링크)'만 전달합니다.
- 동작 방식:
- 클라이언트 에이전트가 첨부파일을 클라우드 스토리지(AWS S3, Google Cloud Storage 등)나 내부 파일 서버에 업로드합니다.
- 생성된 다운로드 링크(주로 보안이 적용된 Presigned URL)를 A2A JSON 페이로드에 담아 대상 에이전트에게 보냅니다.
- 대상 에이전트는 해당 URL에 접근해 파일을 다운로드하고 작업을 수행합니다.
- 장점: 페이로드 크기가 매우 작게 유지되며, 대용량 파일 처리에 적합합니다.
② Base64 인코딩 (작은 파일 단위)
아이콘, 작은 썸네일 이미지, 짧은 텍스트 문서 등 용량이 작은 파일의 경우, 파일을 문자열 형태로 변환(Base64 인코딩)하여 JSON 데이터 안에 직접 끼워 넣습니다.
- 동작 방식: 바이너리 파일을 iVBORw0KGgo... 같은 긴 텍스트 문자열로 변환한 뒤, data 필드에 직접 삽입하여 전송합니다.
- 단점: 파일 크기가 커질수록 텍스트 길이가 기하급수적으로 늘어나 통신 지연이나 메모리 초과(OOM) 에러를 유발할 수 있어 제한적으로 사용됩니다.
③ A2A Artifacts (결과물/첨부물) 객체 활용
A2A 프로토콜 스펙에는 파일 입출력을 규격화하기 위해 artifacts라는 전용 스키마(구조)가 존재합니다. 에이전트는 이 배열(Array) 안에 첨부파일의 메타데이터와 파일 데이터(혹은 링크)를 명시하여 소통합니다.
실제 A2A 통신 시 주고받는 JSON 페이로드 예시:
{
"task_id": "task-9876",
"action": "analyze_receipt",
"input": {
"message": "첨부된 영수증 이미지 2장의 총 결제 금액을 계산해줘."
},
"artifacts": [
{
"artifact_id": "art-01",
"file_name": "receipt_lunch.jpg",
"mime_type": "image/jpeg",
"url": "https://secure-storage.com/files/receipt_lunch.jpg?token=abc"
},
{
"artifact_id": "art-02",
"file_name": "summary_note.txt",
"mime_type": "text/plain",
"data": "base64_encoded_string_here..." // 용량이 작은 경우 직접 포함
}
]
}
5. 참고 자료
- https://github.com/a2aproject/A2A
- https://a2a-protocol.org/latest/
- https://codelabs.developers.google.com/intro-a2a-purchasing-concierge
- https://www.ibm.com/think/topics/agent2agent-protocol
- https://blog.logto.io/ko/a2a-mcp
댓글