Google Vertex AI Agent Builder와 A2A (Agent-to-Agent) 프로토콜

Agent-to-Agent (A2A) 프로토콜은 서로 다른 AI 에이전트들이 공통된 언어로 상호 작용할 수 있도록 정의된 오픈 표준 통신 규약입니다cloud.google.com. 기존에는 각 에이전트를 연동하려면 커스텀 API를 만들어 포인트투포인트 통합을 해야 했지만, A2A는 이러한 비효율을 해결하고자 등장했습니다. 예를 들어, 한 사용자가 메인 AI 비서에게 해외 여행 계획을 문의하면, 항공권 예약, 호텔 예약, 현지 투어 추천, 환전 및 여행 주의사항 등 전문화된 여러 에이전트가 협업해야 할 수 있습니다google.github.io. A2A 없이는 이러한 다중 에이전트 협업을 구현하기 어렵지만, A2A 프로토콜은 프레임워크나 벤더에 상관없이 각 에이전트가 자신의 기능과 인터페이스를 공개하고 표준 방식으로 요청/응답을 처리하도록 함으로써 이 문제를 해결합니다cloud.google.com. 요약하면 A2A의 목적은 에이전트 간 상호운용성을 높여 복잡한 작업을 분담하고 협력하도록 돕는 것입니다cloud.google.com. 이를 통해 하나의 에이전트로 불가능한 복잡한 워크플로도 여러 에이전트가 팀처럼 협력하여 수행할 수 있게 됩니다. 또한 각 에이전트는 내부 로직이나 데이터를 공개하지 않고도 협업할 수 있어 보안과 지적 재산을 보호하면서 상호 작용할 수 있습니다google.github.iogoogle.github.io.

 

Vertex AI Agent Builder에서의 A2A 활용

Vertex AI Agent Builder(에이전트 빌더)는 여러 에이전트를 조합한 멀티 에이전트 시스템을 쉽게 구축할 수 있는 도구로, A2A 프로토콜을 핵심 통신 방식으로 채택하고 있습니다. Agent Builder 내에서 A2A는 다음과 같은 방식으로 활용됩니다:

• 에이전트 간 메시징 구조: A2A는 통신 전송방식으로 HTTP(S) 기반 JSON-RPC 2.0을 사용하며, 모든 메시지를 표준화된 JSON으로 주고받습니다google.github.io. 따라서 각 에이전트는 JSON-RPC 메서드 호출 형태로 서로에게 작업을 요청합니다. 예를 들어 “tasks/send”와 같은 메서드로 특정 작업(Task)을 보내면, 원격 에이전트가 이를 처리한 후 결과를 응답하는 구조입니다. 이러한 Task 기반 통신에는 작업 ID, 세션 ID, 요청 내용 등이 포함되어 있어, 다중 요청도 식별하고 상태를 추적할 수 있습니다.
• 외부 에이전트 연동: A2A 프로토콜을 통해 외부 프레임워크로 만들어진 에이전트까지 손쉽게 연결할 수 있습니다. Vertex AI의 에이전트는 LangChain, LangGraph, Crew.ai 등 오픈소스 에이전트와도 A2A 인터페이스로 통신할 수 있으며cloud.google.com, 실제로 Google의 예시에서는 ADK로 만든 구매 비서 에이전트가 LangGraph로 구현된 피자 주문 에이전트, CrewAI로 구현된 버거 주문 에이전트와 통신합니다codelabs.developers.google.com. 각 외부 에이전트는 Agent Card라는 자기소개 카드(JSON 문서)로 자신의 기능과 엔드포인트를 공개하고, Agent Builder는 이 정보를 읽어와 원격 연결 객체를 생성합니다. 이를 통해 이기종 에이전트 생태계를 하나의 워크플로에 통합할 수 있습니다.
• 권한 관리 및 보안: A2A 프로토콜은 엔터프라이즈급 보안을 고려하여 설계되었습니다google.github.io. 각 에이전트는 Agent Card에 인증 방식(예: Bearer 토큰, OAuth2 등)을 명시할 수 있으며google.github.io, 통신 시 표준 HTTP 인증 헤더나 mTLS 등을 통해 상호 인증을 수행합니다. 또한 에이전트 카드를 검색(.well-known 경로 등)할 때에도 필요에 따라 인증이 요구될 수 있어, 민감한 정보가 무분별하게 노출되지 않도록 합니다google.github.io. A2A는 표준 웹 보안 관행에 맞춰 인증/인가, 트레이싱, 모니터링을 포함한 기능을 제공하여 기업 환경에서도 안전하게 에이전트를 연동할 수 있게 합니다google.github.io.
• 도구 공유 및 투명성: A2A의 핵심 설계 원칙 중 하나는 **Opaque Execution(불투명 실행)**으로, 에이전트들이 **자신의 내부 메모리나 툴(도구)**을 직접 노출하거나 공유하지 않고도 협업하도록 합니다google.github.io. 즉, 한 에이전트가 가진 데이터베이스나 외부 API 툴에 다른 에이전트가 직접 접근하는 것이 아니라, 필요한 작업을 그 에이전트에게 요청함으로써 간접적으로 활용합니다. 이렇게 하면 각 에이전트의 내부 로직이나 프롬프트, 프라이빗한 도구는 보호되고, 에이전트 간에는 선언된 기능과 컨텍스트만 교환합니다google.github.io. 따라서 개발자는 보안이나 IP 침해 우려 없이 에이전트 간 기능 활용이 가능합니다.
• A2A 통신 흐름: Agent Builder 환경에서 A2A 통신은 클라이언트-서버 모델로 동작합니다. ① 먼저 한 에이전트(클라이언트 역할)가 상대 에이전트의 Agent Card를 발견하고(예: 정해진 URL이나 레지스트리 조회) 연결 설정을 합니다codelabs.developers.google.com. ② 그런 다음 필요한 순간에 tasks/send 요청으로 작업(Task)을 원격 에이전트(서버 역할)에게 보냅니다. 요청 시 대화 또는 작업에 관한 컨텍스트를 함께 전달하며, 원격 에이전트가 작업을 수행하게 됩니다. 이때 클라이언트가 콜백 URL을 제공하면 원격 에이전트는 작업 진행 상태를 푸시 알림으로 전송할 수도 있습니다codelabs.developers.google.com. ③ 최종적으로 작업이 완료되면 원격 에이전트는 **결과물(artifact)**을 응답으로 돌려주며, 클라이언트는 이를 받아 사용자에게 전달하거나 다음 논리에 활용합니다codelabs.developers.google.com. 이러한 흐름은 동기/비동기 모드를 모두 지원하며, 실시간 스트리밍이 필요한 경우 **Server-Sent Events (SSE)**로 스트림을 열어 결과를 부분 전송하고, 그렇지 않은 경우 푸시 알림이나 폴링으로 완료 시점을 관리할 수 있습니다. 전체 통신이 JSON-RPC로 표준화되어 있으므로, 서로 다른 플랫폼의 에이전트들도 이 일련의 흐름을 동일한 방식으로 구현하게 됩니다.

A2A 개발을 위한 구성 요소 및 코드 구조

A2A 프로토콜을 활용하여 에이전트를 개발하려면 몇 가지 핵심 구성 요소를 이해하고 구현해야 합니다. Google이 제공하는 **Agent Development Kit (ADK)**을 쓰면 이러한 작업이 간소화되지만, 원리를 파악하기 위해 구성 요소 중심으로 설명하겠습니다.

 

• Agent Card 정의: 각 A2A 서버 에이전트는 자신을 나타내는 Agent Card(JSON 문서)를 제공해야 합니다. 이 카드에는 에이전트의 식별 정보(이름, 설명, 버전, 제공자 등), 서비스 엔드포인트 URL, 지원하는 A2A 프로토콜 기능(예: 스트리밍 가능 여부, 푸시 알림 지원 등), 요구 인증 방식(예: “Bearer”, “OAuth2” 등), 그리고 **에이전트의 기능 목록(스킬)**이 기술됩니다google.github.io. 스킬(AgentSkill)은 에이전트가 수행할 수 있는 개별 작업의 목록으로, 각 스킬마다 고유 ID와 이름, 설명, 입력/출력 형식(inputModes/outputModes), 사용 예시 등이 포함됩니다google.github.io. 개발자는 에이전트 서버를 만들 때 이러한 Agent Card를 코드로 구성해야 합니다. 예를 들어, Python ADK에서는 AgentCard 클래스 인스턴스를 생성하여 name, url, authentication, capabilities, skills 목록 등을 채워넣습니다codelabs.developers.google.comcodelabs.developers.google.com. 아래는 간략한 예시입니다:
• python
  CopyEdit
  skill = AgentSkill(id="create_order", name="Order Creation", description="Create an order", ...) agent_card = AgentCard( name="pizza_agent", description="Pizza ordering agent", url="https://pizza.example.com/", # A2A 서비스 URL version="1.0.0", authentication=AgentAuthentication(schemes=["Bearer"]), # 인증 방식 capabilities=AgentCapabilities(streaming=True, pushNotifications=True), skills=[skill] )
• 에이전트 서버 및 Task 처리: A2A 서버 에이전트는 JSON-RPC 기반의 HTTP 서버로 동작하며, 주요 RPC 메서드들을 처리하는 로직이 필요합니다. 대표적으로 tasks/send (새 작업 요청), tasks/get (작업 상태 조회), tasks/cancel (작업 취소), tasks/sendSubscribe (스트리밍 구독 방식 요청) 등이 표준으로 정의되어 있습니다codelabs.developers.google.comcodelabs.developers.google.com. 개발자는 이러한 메서드를 처리할 핸들러를 구현해야 하는데, 보통 Task Manager 역할의 모듈이 이를 담당합니다. 예를 들어, ADK에서는 A2AServer를 초기화할 때 개발자가 작성한 에이전트 비즈니스 로직 객체와 TaskManager를 전달합니다codelabs.developers.google.com. TaskManager는 on_send_task 등의 메서드를 통해 들어온 작업 요청을 해당 에이전트의 실제 기능(예: LLM 프롬프트 실행 또는 외부 API 호출 등)에 전달하고, 그 결과를 SendTaskResponse로 반환합니다. 또한 멀티턴 대화를 지원하기 위해 세션별 대화 기록이나 상태를 관리하고, 필요한 경우 사용자 확인을 요구하는 중간 질문도 처리합니다. 핵심은 에이전트 내부적으로 작업 수행을 하고 결과를 JSON-RPC 응답으로 돌려주는 흐름을 구현하는 것입니다.
• 클라이언트 에이전트 구성: 한편 A2A 클라이언트 역할을 하는 에이전트(주로 사용자와 직접 상호작용하는 오케스트레이션 에이전트)는 원격 에이전트와 통신하기 위한 연결 설정 코드가 필요합니다. 개발자는 우선 원격 에이전트들의 Agent Card를 발견해야 합니다. 이때 사용 가능한 방법으로, 원격 호스트의 /.well-known/agent.json 위치에 호스팅된 Agent Card를 HTTP GET으로 가져오는 방식(공개 에이전트의 경우)이나, 사전에 에이전트 레지스트리에 등록된 정보를 조회하거나, 혹은 구성 파일에 직접 Agent Card 정보를 넣어두는 방법이 있습니다google.github.iogoogle.github.io. ADK에서는 A2ACardResolver 등 유틸리티를 통해 URL만 주면 Agent Card를 가져오는 기능을 제공하며, 개발자는 이렇게 수집된 Agent Card들을 사용해 RemoteAgentConnection 또는 JSON-RPC 클라이언트를 생성합니다codelabs.developers.google.comcodelabs.developers.google.com.
• 작업 요청 전송 (send_task) 구현: 클라이언트 에이전트는 원격 에이전트의 스킬을 사용해야 할 시점에, 해당 에이전트에게 작업을 위임합니다. 코드 상에서는 원격 연결 객체를 통해 앞서 정의된 JSON-RPC 메서드(tasks/send)를 호출하게 되는데, ADK에서는 이러한 호출을 좀 더 쉽게 해주는 래퍼 함수(send_task)를 정의할 수 있습니다codelabs.developers.google.comcodelabs.developers.google.com. send_task(에이전트명, 작업내용, 컨텍스트) 형태로 호출하면, 내부적으로 Task ID와 세션 ID를 생성하고 필요한 **메타데이터(대화 ID, 메시지 ID 등)**를 붙여 원격 에이전트의 /tasks/send 엔드포인트로 HTTP 요청을 보냅니다codelabs.developers.google.comcodelabs.developers.google.com. 이때 요청의 params에는 TaskSendParams라는 표준 구조체가 담기는데, 여기에는 작업 ID, 세션 ID, 그리고 Message 객체(실제 지시하거나 문의할 내용)가 포함됩니다codelabs.developers.google.com. 원격 에이전트는 이 요청을 받아 자신의 로직을 수행한 뒤 결과를 응답하며, 클라이언트 측에서는 해당 응답(JSON 객체 형태)을 받아 처리합니다.
• 응답 및 멀티턴 처리: 원격 에이전트의 응답은 작업 완료 결과(예: 생성된 텍스트, 파일 링크 등)를 artifact로서 담아 보내옵니다codelabs.developers.google.com. 클라이언트 에이전트는 이 결과를 사용자의 질문에 대한 답변에 반영하거나 후속 작업을 이어갑니다. 만약 원격 에이전트가 추가 정보를 요구하거나 멀티턴 대화가 필요한 경우(예: “이 주문을 확정해도 될까요?” 같은 질문), A2A 프로토콜은 이를 처리할 수 있도록 설계되어 있습니다. 원격 에이전트는 진행 도중 **중간 응답(partial response)**이나 추가 메시지를 보낼 수 있고 클라이언트 에이전트는 이를 사용자에게 전달하거나 필요한 정보를 채워 다시 tasks/send로 답변을 보낼 수 있습니다 (마치 에이전트가 사용자인 것처럼 대리 응답). 이러한 과정을 통해 에이전트들 간 왕복 대화가 가능해지며, 개발자는 이를 대화 흐름에 녹여내야 합니다. 예를 들어 구매 비서 에이전트는 피자 주문 에이전트가 “토핑을 무엇으로 할까요?”라고 물으면 사용자의 응답을 받아 다시 피자 에이전트에 전달하는 식으로 다단계 상호작용을 코딩하게 됩니다.

대표적인 사용 예시와 권장 아키텍처

A2A 프로토콜의 활용 예시로는 앞서 언급한 여행 계획 시나리오를 비롯해 다양한 케이스가 존재합니다. 예를 들어, 한 기업이 종합 상담 AI를 구축한다고 할 때, 메인 상담 에이전트가 법률 자문 에이전트, 기술 지원 에이전트, 재무 상담 에이전트 등 여러 전문 에이전트에게 질의를 위임하여 최종 사용자의 복잡한 질문에 답변하게 할 수 있습니다. 또 다른 예로, 전자상거래 도메인에서는 개인 쇼핑 비서 에이전트가 상품 추천, 재고 확인, 주문 처리 등의 역할을 각각 담당하는 에이전트들과 연동하여 사용자의 요청을 완결시키는 구조를 만들 수 있습니다. Google의 공식 데모에서도 **“Purchasing Concierge”**라는 메인 에이전트가 피자 주문 에이전트와 버거 주문 에이전트에 A2A로 작업을 보내 주문을 처리하는 예제가 소개되었습니다codelabs.developers.google.com.

그림: A2A를 활용한 멀티 에이전트 아키텍처 예시. 사용자(좌측)가 Vertex AI ADK로 구현된 Purchasing Concierge 에이전트와 대화하면, 이 에이전트(A2A 클라이언트 역할)가 Burger Agent(CrewAI 기반)와 Pizza Agent(LangGraph 기반)라는 두 A2A 서버 에이전트에게 작업을 위임합니다. 각 에이전트는 서로 다른 프레임워크로 구현되었지만 A2A 프로토콜로 능력을 공개하고 있으므로, 에이전트 간 공통 규약으로 원활히 통신하고 협업할 수 있습니다.

이처럼 권장 아키텍처는 오케스트레이션(중앙 조율) 에이전트 + 다수의 전문 에이전트 패턴입니다. 사용자는 단일 엔드포인트(메인 에이전트)와만 상호작용하고, 이 메인 에이전트가 A2A를 통해 적절한 다른 에이전트들에게 하위 작업을 분배합니다. 이러한 구조의 이점은 확장성과 모듈성입니다. 새로운 전문 에이전트를 추가하려면 해당 에이전트를 A2A 규약에 맞게 구현하고 Agent Card를 등록하기만 하면, 메인 에이전트가 이를 발견하여 활용할 수 있습니다. 또한 각 에이전트는 마이크로서비스처럼 독립적으로 배포/스케일링되며, 한 에이전트의 변경이 다른 에이전트에 직접적인 영향을 주지 않습니다.

권장 아키텍처에서 주의사항 및 베스트 프랙티스로는 다음이 있습니다:

• 명확한 책임 분리: 에이전트마다 맡는 기능 범위를 명확히 정의하고 Agent Card의 스킬로 문서화하세요. 이렇게 하면 메인 에이전트가 언제 어떤 에이전트를 호출할지 결정 로직을 작성하기 쉬워집니다. 예를 들어 “flight_booking” 스킬은 항공권 에이전트에만 존재하고, 메인 에이전트는 사용자의 요청을 분석해 항공권 관련이면 해당 에이전트에만 send_task를 보냅니다.
• 보안과 신뢰: 서로 다른 에이전트 간에는 인증 토큰 교환이나 접근 제어를 적절히 구성하세요. 특히 사내 시스템과 통합된 에이전트라면 네트워크 격리나 mTLS로 신뢰할 수 있는 환경에서만 통신하도록 하고, Agent Card에 불필요한 내부 정보를 노출하지 않는 것이 중요합니다google.github.iogoogle.github.io. A2A 프로토콜은 인증/인가 체계를 지원하므로, 이를 활용해 각 에이전트 간 신뢰 관계를 설정합니다.
• 에이전트 발견 및 카탈로그화: 에이전트가 많아지면 **Agent Card 레지스트리(카탈로그)**를 운영하는 것이 좋습니다google.github.iogoogle.github.io. 중앙 레지스트리를 두면 메인 에이전트가 필요한 에이전트를 검색 질의로 찾을 수 있고, 조직 내 사용 권한에 따라 어떤 에이전트를 노출할지 제어할 수도 있습니다. Vertex AI Agent Builder의 Agentspace나 파트너 솔루션들이 이러한 에이전트 카탈로그 역할을 지원하며, 이를 활용하면 대규모 에이전트 환경을 관리하기 수월합니다.
• 프로토콜 표준 준수: 마지막으로, A2A는 계속 진화 중인 개방형 표준이므로 최신 사양에 맞게 구현을 유지하는 것이 중요합니다codelabs.developers.google.com. Google을 비롯한 50여 개 파트너들이 A2A 표준을 발전시키고 있으므로cloud.google.com, 정기적으로 SDK나 문서를 확인하여 호환성을 확보하세요. 다행히 A2A는 HTTP, JSON 등의 검증된 표준 위에 구축되어 변화가 크지 않고google.github.io, 또한 MCP 등 다른 표준과 상호보완적으로 동작하도록 설계되었으므로google.github.iogoogle.github.io, 이러한 점들을 고려한 아키텍처를 설계하면 미래에도 견고한 멀티 에이전트 시스템을 유지할 수 있을 것입니다.

참고로, A2A 프로토콜은 **“API의 에이전트 버전”**이라고 불릴 만큼 개념적으로 API 통합과 유사한 방식으로 에이전트 통합을 이뤄냅니다cloud.google.com. 따라서 개발자는 기존 웹 서비스 구성원리(REST/JSON, 인증, 비동기 처리 등)를 응용하여 비교적 쉽게 멀티 에이전트 시스템을 구축할 수 있습니다. Vertex AI Agent Builder를 활용하면 이러한 A2A 기반 멀티 에이전트 환경을 코드 몇 줄로 설정하고(예: ADK로 A2A 서버/클라이언트 초기화) 관리할 수 있으므로, 자연어 에이전트를 조합한 새로운 애플리케이션을 개발하고자 한다면 A2A 프로토콜과 Agent Builder가 강력한 토대가 되어 줄 것입니다.