Google A2A 프로토콜: 에이전트 간 협업을 위한 새로운 표준

카테고리 없음

Google A2A 프로토콜: 에이전트 간 협업을 위한 새로운 표준

ch4u 2025. 4. 10. 13:13

A2A 프로토콜 개념과 필요성

Agent-to-Agent (A2A) 프로토콜은 구글이 공개한 AI 에이전트 상호운용성 표준으로, 서로 다른 AI 에이전트들이 공통 언어와 통신 채널을 통해 직접 대화하고 협력할 수 있게 해줍니다 . 이는 Anthropic의 **Model Context Protocol (MCP)**처럼 에이전트에 도구와 데이터를 제공하는 플러그인 체계와는 달리, 여러 에이전트들을 네트워크로 연결하여 지능을 공유하는 방식으로 볼 수 있습니다 .

오늘날 기업들은 Jira나 Salesforce와 같은 다양한 플랫폼에 각기 다른 AI 에이전트를 활용하지만, 이 에이전트들이 서로 다른 시스템의 벽에 가로막혀 협업하기 어려웠습니다 . 구글 A2A는 이러한 **사일로(silo)**를 허무는 것을 목표로 탄생했습니다. 구글은 대규모 멀티 에이전트 시스템을 고객사에 구축하며 발견한 문제들을 해결하기 위해 A2A를 설계했는데, 이를 통해 개발자는 프로토콜을 따르는 어떤 에이전트든 서로 연결되도록 만들 수 있고, 기업은 여러 클라우드와 플랫폼에 걸쳐 에이전트들을 표준화된 방법으로 관리할 수 있게 됩니다 . 궁극적으로 이처럼 보편적인 상호운용성이 확보될 때 AI 에이전트 협업의 잠재력을 완전히 실현할 수 있다는 것이 구글의 주장입니다 .

A2A의 구조와 기술 스택

A2A 프로토콜은 클라이언트 에이전트(요청을 formulates)와 원격 에이전트(실제 작업 수행) 간의 통신을 표준화합니다 . 클라이언트 에이전트는 사용자로부터 받은 작업(Task)을 정의하여 원격 에이전트에 전달하고, 원격 에이전트는 이를 수행한 뒤 진행 상황과 결과를 다시 클라이언트에게 응답합니다 . 이러한 결과물은 A2A 프로토콜 내에서 **“아티팩트(artifact)”**라는 형태로 기록됩니다 .

A2A 디자인 원칙에서는 다음과 같은 핵심 사항들을 강조합니다:

기존 표준 기반: A2A는 이미 널리 쓰이는 HTTP 통신을 바탕으로 하며, 응답 스트리밍을 위해 **Server-Sent Events (SSE)**를 활용하고, 데이터 교환에는 JSON-RPC와 같은 표준 포맷을 사용합니다 . 이를 통해 기존 IT 시스템과 쉽게 통합할 수 있고, 프록시나 로드밸런서 등 현업 인프라를 그대로 활용할 수 있습니다 . 또한 OpenAPI의 인증 체계를 참고하여 기업 수준의 인증/권한 부여를 기본 지원하도록 설계되었습니다 .
에이전트 특성 존중: 각 에이전트는 자체 내부 기억이나 도구를 공유하지 않더라도 자연스러운 방식으로 협업할 수 있어야 합니다 . A2A는 에이전트를 단순한 “툴”로 제한하지 않고, 독립적인 지능 주체들이 대화하듯 상호작용하도록 지원합니다. 예컨대 언어나 형식이 구조화되지 않은 일반 텍스트 대화부터, 파일, 이미지, 오디오/비디오 스트림까지 다양한 모달리티를 주고받을 수 있도록 모달리티에 구애받지 않는 설계를 채택했습니다 .
장기 작업 및 실시간 피드백: 단순 질의응답처럼 빠르게 완료되는 작업뿐 아니라, 여러 시간에 걸쳐 진행되는 복잡한 작업도 A2A로 처리할 수 있습니다 . 이러한 롱런(long-running) 작업의 경우, 원격 에이전트는 SSE 기반 실시간 스트리밍 이벤트를 통해 진행 상태 업데이트(TaskStatusUpdateEvent)나 중간 결과(TaskArtifactUpdateEvent)를 지속적으로 클라이언트에게 전달할 수 있습니다 . 또한 pushNotifications 기능을 지원하는 서버는 **웹훅(webhook)**을 통해 클라이언트에 푸시 알림을 보낼 수도 있어, 클라이언트가 폴링(polling)하지 않고도 작업 완료 등을 통보받을 수 있습니다 .
보안 및 신뢰성: 엔터프라이즈 환경에서의 사용을念두해, A2A는 기본적으로 보안을 우선합니다. 인증/인가 체계는 OAuth 등의 기존 표준을 활용하여 안전하게 통신 채널을 구축하고, 에이전트 간 권한 격리와 데이터 접근 제어를 가능하게 했습니다 . 이로써 서로 다른 조직이나 서비스에 속한 에이전트들도 신뢰할 수 있는 방식으로 협업할 수 있습니다.

A2A 통신 절차는 요약하면 다음과 같습니다 :

에이전트 발견(Discovery): 클라이언트 에이전트가 상대 원격 에이전트의 정보가 담긴 **“에이전트 카드(Agent Card)”**를 조회합니다. 에이전트 카드는 일반적으로 해당 서비스 도메인의 /.well-known/agent.json URL에 호스팅되는 JSON 메타데이터로, 에이전트의 능력, 지원 기능, API 엔드포인트 URL, 인증 방식 등을 기술합니다 .
작업 요청 발송(Initiation): 클라이언트는 원격 에이전트의 엔드포인트(URL)에 tasks/send (또는 스트리밍 모드로 tasks/sendSubscribe) 요청을 보내 작업을 시작합니다. 이 때 고유한 작업 ID를 부여하고, 초기 사용자 메시지를 함께 전달합니다 . 메시지는 JSON 객체로 표현되며, role (예: “user”)과 parts 필드로 구성됩니다 . 하나의 메시지는 여러 **파트(part)**로 이루어질 수 있는데, 텍스트 답변이면 TextPart, 이미지나 파일이면 FilePart (바이트 데이터나 URI 포함), 구조화된 JSON 데이터는 DataPart 등으로 명시되어 전송됩니다 .
작업 처리(Processing): 원격 에이전트는 받은 요청을 수행하며, 작업 상태를 관리합니다. 짧은 작업이라면 곧바로 최종 Task 객체(작업 ID 및 결과를 담은 객체)를 응답으로 반환할 수 있고, 복잡한 작업이라면 비동기 진행됩니다 . 스트리밍 모드인 경우 원격 에이전트는 SSE 채널을 통해 작업 진행 상황이나 부분 결과를 이벤트로 클라이언트에 지속 전송하고, 비스트리밍 모드인 경우 완료 시점에 한 번의 응답으로 결과를 돌려줍니다 . 작업 도중 원격 에이전트가 추가 입력이 필요하면 상태가 input-required로 전환되며, 이때 클라이언트는 동일한 작업 ID로 후속 메시지(tasks/send)를 보내 추가 지시를 내릴 수 있습니다 .
작업 완료(Completion): 최종적으로 작업이 완료되면, 원격 에이전트는 작업 상태를 completed로 표시하고 결과물을 제공합니다 . 작업이 실패하거나 취소되는 경우 상태값이 failed 또는 canceled로 끝나며, 이 역시 클라이언트에게 통보됩니다. 모든 작업 결과물(예: 생성된 코드 파일, 요약본 등)은 앞서 언급한 **아티팩트(Artifact)**로서 구조화되어 전달되고 저장될 수 있습니다 .

A2A 프로토콜에서 클라이언트 에이전트(오른쪽 파란 로봇)와 원격 에이전트(왼쪽 녹색 로봇)가 보안 채널로 소통하며, 능력 발견, 작업 상태 관리, 사용자 경험 협상 등의 기능을 수행한다 . 이 그림에서 원격 에이전트는 자신의 Agent Card를 통해 가능한 작업들을 노출하고(우측 상단 녹색 말풍선 아이콘들), 클라이언트 에이전트는 필요한 작업을 요청하여(하단 노란 연결선) 결과를 확인한다. A2A는 이러한 협업을 안전하게 중재하며, 각 단계에서 Capability Discovery(능력 발견), Task and State Management(작업 및 상태 관리), User Experience Negotiation(UX 협상), Secure Collaboration(안전한 협업)과 같은 기능적 요소들을 제공한다.

오픈소스 도구 및 SDK

A2A 프로토콜은 완전히 오픈 소스로 공개되어 누구나 참여하고 기여할 수 있습니다 . 구글은 GitHub에 A2A의 초안 스펙 문서와 참조 구현 코드 샘플을 공개하였고, 커뮤니티와 협업하여 표준을 발전시켜 나갈 계획입니다 . 현재 Python과 JavaScript용으로 제공된 예제 코드에서는 A2A 클라이언트/서버를 구현하고 여러 시나리오를 시험해볼 수 있습니다 . 예를 들어 CLI 상에서 에이전트와 대화하는 샘플, 여러 에이전트를 오케스트레이션하는 웹 데모, 다양한 AI 프레임워크로 작성된 샘플 에이전트들 등이 제공되어 개발자들이 A2A의 동작을 직접 실험해볼 수 있습니다 .

특히 구글은 파트너들과 함께 **ADK(Agent Development Kit)**라는 에이전트 개발 툴킷도 선보였는데 , 이를 통해 개발자들은 자신의 AI 에이전트를 A2A 표준에 손쉽게 연결할 수 있도록 지원받을 수 있습니다. ADK와 함께 에이전트 마켓플레이스도 공개되어, 호환되는 에이전트들을 모아두고 필요한 에이전트를 찾아 쓸 수 있는 생태계를 마련하려는 청사진도 공개되었습니다 . (ADK 및 마켓플레이스는 현재 예시 코드와 초기 버전이 제공된 상태이며, 향후 발전이 예상됩니다.)

A2A는 2025년 내에 Production-ready 버전(상용 환경에 투입 가능한 안정 버전)을 출시할 계획이며, 현재는 Draft 사양 단계이지만 빠르게 성숙하고 있습니다 . 이미 수많은 업체들이 오픈소스 프로젝트에 참여하여 피드백과 코드를 기여하고 있어, 개발자들은 초기 버전이라도 적극 활용해보고 개선점을 제안할 수 있는 상황입니다.

예제로 보는 A2A 통신 흐름

앞서 설명한 A2A의 통신 과정을 간단한 코드 예제로 살펴보겠습니다. 이번 예제에서는 Python을 사용하여, 에이전트 A(클라이언트)가 에이전트 B(원격 서버)에게 작업 요청을 보내고 결과를 받는 흐름을 구현합니다:

에이전트 카드 조회: 먼저 에이전트 B의 agent.json 메타데이터를 가져와, 제공하는 A2A 서비스의 엔드포인트 URL과 지원 기능을 알아냅니다. 이를 통해 클라이언트는 B에게 어떤 식으로 요청을 보내야 하는지(지원하는 메소드, 인증 방식 등)를 파악할 수 있습니다.
작업 요청 전송: 이제 A는 B의 엔드포인트로 HTTP POST 요청을 보내 작업을 의뢰합니다. 요청 본문에는 고유한 task_id와 함께 사용자 메시지(예: 사용자 질문이나 지시)가 포함됩니다. 메시지는 role: "user"로 표시하고, 내용은 parts 배열 안에 TextPart 형태로 넣었습니다.
응답 처리: B 에이전트가 요청을 받아 작업을 수행한 뒤 결과를 반환하면, A 에이전트는 이를 확인합니다. 아래 코드에서는 응답을 JSON으로 파싱하여 result로 출력합니다. (예제에선 단순 동기 응답으로 가정했지만, B가 스트리밍을 지원한다면 SSE 스트림을 받아 처리하는 로직이 추가될 수 있습니다.)

import requests

# 1. Agent B의 에이전트 카드 가져오기 (Discovery 단계)
agent_card_url = "https://agentB.example.com/.well-known/agent.json"
agent_card = requests.get(agent_card_url).json()
endpoint = agent_card["endpoint"]  # 원격 에이전트 B의 A2A 서버 엔드포인트 URL
print("Discovered Agent B endpoint:", endpoint)

# 2. 작업 요청 보내기 (Initiation 단계)
task_id = "task-12345"  # 고유한 작업 ID
task_request = {
    "task": {"id": task_id},
    "message": {
        "role": "user",
        "parts": [
            { "type": "TextPart", "text": "안녕하세요, 이 작업을 수행해 줄 수 있나요?" }
        ]
    }
}
response = requests.post(f"{endpoint}/tasks/send", json=task_request)
print("Response status:", response.status_code)

# 3. 결과 응답 받기 (Completion 단계)
result = response.json()
print("Task result artifact:", result.get("artifact", result))

위 코드에서 에이전트 B의 URL (agentB.example.com)과 인증 방식 등은 예시로 간주했습니다. 실제로는 사전에 해당 에이전트와 인증 토큰 교환을 해야 할 수도 있습니다(A2A는 OpenAPI와 유사한 인증 스킴을 따릅니다). 또한 tasks/send 대신 **tasks/sendSubscribe**를 사용하고 SSE 스트림을 수신하면 실시간 진행 상황을 받아볼 수 있고, 더 복잡한 대화 상황에서는 task_id를 유지한 채 추가 tasks/send 호출로 대화형 상호작용을 이어나갈 수도 있습니다 .

예를 들어, 에이전트 B가 작업 도중 사용자 승인이나 추가 정보를 요구하면(input-required 상태), A는 동일한 task_id를 참조하여 추가 메시지를 보낼 수 있습니다. 이렇게 하면 하나의 작업 컨텍스트 내에서 다단계 대화를 진행할 수 있으며, 모든 대화와 결과가 해당 작업의 상태 모델 안에서 관리됩니다 .

주요 파트너 및 실제 활용 사례

A2A 프로토콜은 발표 시점부터 이미 50여 개 이상의 파트너 기업들이 참여하여 함께 사양을 다듬고 있습니다 . 기술 플랫폼 파트너로는 Atlassian, Box, Cohere, Intuit, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, Workday 등이 있고, 컨설팅/통합 파트너로는 Accenture, BCG, Capgemini, Deloitte, KPMG, PwC 등 글로벌 기업들이 대거 협력하고 있습니다 . 이러한 폭넓은 참여는 A2A를 사실상 산업 표준으로 만들겠다는 구글의 전략을 보여줍니다.

실제 사례로, Atlassian은 자사의 AI 에이전트인 Rovo에 A2A 프로토콜을 도입할 계획입니다. Atlassian 측은 *“표준화된 프로토콜인 A2A를 통해 에이전트들이 서로를 성공적으로 발견하고 조율하며 추론할 수 있게 될 것”*이라며 기대감을 표시했습니다 . 한편 Salesforce도 Agentforce라는 자체 에이전트 플랫폼에 A2A 지원을 선도적으로 추가하고 있습니다. Salesforce는 *“A2A 표준 지원을 통해 Agentforce와 다른 에이전트들이 원활하게 함께 작업할 수 있게 될 것”*이라고 밝혔습니다 .

이처럼 업계 주요 플레이어들이 A2A에 주목하는 이유는 분명합니다. 예를 들어 한 대형 전자상거래 기업을 떠올려보겠습니다. 이 기업은 사내 협업에 Atlassian 제품을 쓰고, 파일 관리는 Box, 고객 관계 관리는 Salesforce, 인사 관리는 Workday를 사용한다고 가정합니다 . 과거에는 각 플랫폼의 AI 에이전트들이 따로 놀아서, 영업 팀의 Salesforce 에이전트가 확인한 고객 데이터를 업무 관리 툴(Jira)의 에이전트가 직접 활용하지 못했습니다. 그러나 A2A 도입 후에는 이질적인 플랫폼 간 에이전트들이 안전한 채널로 정보를 주고받으며 업무를 자동화할 수 있습니다 . 가령 주문 관리 에이전트가 A2A를 통해 물류 시스템의 에이전트에게 배송 추적 정보를 요청하고 실시간으로 받아오는 식입니다 . 이미 Atlassian, Salesforce를 비롯한 여러 기업이 이러한 크로스-플랫폼 에이전트 통합 시나리오를 현실화하기 위해 A2A를 시험 중입니다.

또 다른 예로, 구글이 소개한 소프트웨어 엔지니어 채용 시나리오를 들 수 있습니다. 한 곳에서 채용 담당자용 에이전트가 후보자의 이력 검색을 다른 플랫폼의 에이전트들에게 의뢰하고(예: LinkedIn 에이전트, 채용 포털 에이전트), 그 결과를 수합한 뒤 인터뷰 일정을 조율하는 작업을 달리 전문화된 에이전트에 맡기는 등, 여러 에이전트들이 협업하여 하나의 복합 업무를 처리하는 모습입니다 . 이 과정에서 A2A가 없다면 각 작업을 사람이 일일이 중개해야 하거나 개별 API 통합을 엄청나게 개발해야겠지만, A2A 표준을 따르면 統一된 방식으로 에이전트 오케스트레이션이 가능해집니다.

이렇듯 A2A는 다양한 비즈니스 분야에서 에이전트 협업 사례를 만들어내고 있습니다. 앞으로 파트너사들의 솔루션 (예: ServiceNow의 IT 업무 에이전트와 SAP의 재무 에이전트 연동 등)에 A2A가 적용되어 플랫폼 경계를 넘나드는 AI 업무자동화가 활발해질 것으로 기대됩니다.

MCP 등 다른 프로토콜과의 관계

최근 AI 에이전트 생태계가 주목받으면서 A2A 외에도 여러 상호운용 프로토콜이 제안되었습니다. 대표적으로 Anthropic의 **MCP (Model Context Protocol)**와 Cisco 주도의 AGNTCY가 있습니다 . 각각의 지향점과 A2A와의 관계를 살펴보면 다음과 같습니다:

Anthropic MCP: 2024년 말 공개된 MCP는 하나의 에이전트(LM)에 도구와 컨텍스트를 제공하는 표준으로, 예를 들어 프롬프트에 구조화된 함수 호출이나 외부 지식그래프 제공 등의 방식으로 에이전트의 능력을 확장합니다. 쉽게 말해, MCP는 에이전트 한 명을 똑똑하게 만들어주는 플러그인 시스템이라 할 수 있습니다 . 현재 Microsoft GitHub Copilot의 에이전트 모드나 AWS의 일부 AI 서비스 등에서 MCP를採用하며 생태계가 빠르게 형성되고 있습니다.
Cisco AGNTCY: 시스코를 비롯한 단체가 제안한 AGNTCY는 MCP와 유사하게 에이전트 상호운용을 표방하지만, 아직 정보가 제한적입니다 . AGNTCY 역시 여러 조직의 참여를 통해 표준화를 노리지만, 현재 업계 관심도와 파트너 폭에서 A2A가 한발 앞서있는 상황입니다.

이러한 가운데 구글 A2A의 역할은 위 두 프로토콜과 경쟁하기보다는 보완적인 관계로 볼 수 있습니다. 구글은 공식 블로그에서 *“A2A는 Anthropic의 MCP를 보완하는(open protocol that complements) 관계”*라고 명시했는데 , 즉 MCP로 개별 에이전트에게 도구를 쥐어주고, A2A로 여러 에이전트끼리 소통하게 함으로써 보다 강력한 에이전트 생태계를 구축할 수 있다는 것입니다. 실제로 하나의 시나리오에서, 어떤 에이전트는 MCP를 통해 데이터베이스 조회 툴을 활용하고, 그 결과를 A2A로 다른 에이전트에 전달하여 후속 작업을 수행하게 만드는 식의 결합 사용도 가능합니다.

결론적으로, A2A + MCP 조합이 업계에서 유력한 차세대 표준 스택으로 부상하고 있습니다 . OpenAI 역시 자사 플러그인 체계와 함수 호출 기능 등을 공개하며 이 흐름에 동참하고 있는데, 구글 A2A의 등장은 이러한 노력들을 하나의 개방형 표준으로 묶어줄 키 역할을 할 것으로 기대됩니다. 다양한 프로토콜들이 경쟁하면서도 협력하여, 마치 초창기 웹 표준이 정립되어 갔듯이, 궁극적으로 개발자들은 특정 벤더에 종속되지 않는 에이전트 통신 표준을 손에 넣게 될 것입니다.

맺음말

구글의 A2A 프로토콜은 AI 에이전트 생태계에서 “모두가 손잡고 함께 일하는” 새로운 장을 열고 있습니다. 개발자 관점에서 보면, 이제 서로 다른 AI 플랫폼을 위한 여러 SDK와 API를 일일이 연결하는 대신, 하나의 표준 프로토콜만 이해하면 다양한 에이전트를 조합한 애플리케이션을 설계할 수 있게 됩니다. 이는 마치 초기에 각기 달랐던 웹 서비스들이 REST API로 통합되고, 서로 다른 기기들이 TCP/IP로 통신하게 된 것에 비견할 만한 변화입니다.

A2A는 현재 오픈소스 커뮤니티의 참여 속에 빠르게 발전하고 있으며, 구글과 파트너사들은 연내에 더욱 완성도 높은 버전을 선보일 예정입니다 . AI 에이전트 분야에 종사하는 개발자라면 A2A의 개념과 사용법을 미리 학습하여, 다가올 멀티 에이전트 협업 시대를 준비하는 것이 좋겠습니다. A2A 공식 GitHub의 예제와 문서를 참고하면 단순한 Hello World 수준의 에이전트 상호작용부터 시작할 수 있으니 , 작은 실습으로 그 가능성을 체감해 보십시오. 앞으로 A2A를 기반으로 수많은 창의적인 에이전트 연동 시나리오가 등장할 것이며, 이는 결국 우리의 업무 방식과 애플리케이션 아키텍처에 큰 혁신을 가져올 것입니다. AI 에이전트 간 대화라는 흥미로운 미래를, 이제 개발자 여러분이 직접 구현해볼 차례입니다!