AI 에이전트는 새로운 마이크로서비스이며, A2A는 그들의 HTTP(s)이다

서론

기업들이 생성형 AI 앱/에이전트(Apps/Agents)를 배포하기 위해 경쟁함에 따라, 가장 어려운 질문은 "어떤 파운데이션 모델(foundation model)을 사용할 것인가?"가 아니라 "그들이 어떻게 안전하게 서로 통신할 것인가?"입니다.

만약 당신이 2010년대에 분산 시스템(distributed systems)을 구축하며 시간을 보냈다면, 기업용 AI를 위해 등장하는 아키텍처 설계도는 묘하게 익숙하게 느껴질 것입니다. 경계 컨텍스트(Bounded contexts), 서비스 레지스트리(service registries), 비동기 메시지 큐(async message queues), 그리고 분산 트레이싱(distributed tracing)이 모두 다시 돌아왔습니다. 우리의 "서비스"가 이제 결정론적(deterministic)인 결과 대신 자연어로 추론하고, 도구(tools)를 호출하며, 확률적이고 문맥을 인식하는(probabilistic, context-aware) 출력을 생성한다는 점을 제외하면 어휘는 거의 동일합니다.

에이전트 간(Agent-to-Agent, A2A) 프로토콜은 이러한 아키텍처 비유를 구체화하는 개방형 표준 전송 및 인터페이스 계층입니다. 그리고 이 프로토콜은 현재 Salesforce, Microsoft, SAP, Workday, PayPal, LangChain을 포함한 150개 이상의 조직으로부터 지원을 받고 있습니다.

HTTP/REST가 마이크로서비스(Microservice) 통신의 공용어(lingua franca)가 되었던 것처럼, (현재 Linux Foundation 산하에 호스팅되는) A2A는 자율 에이전트가 기능을 발견하고, 작업을 위임하며, 보안 경계를 유지하는 방식을 표준화합니다.

생태계 정의: A2A vs. MCP

기업용 멀티 에이전트 메시(multi agent mesh)를 설계하려면, 먼저 에이전트 오케스트레이션(orchestration)과 도구 실행(tool execution)을 분리해야 합니다. 흔히 발생하는 아키텍처 안티 패턴(anti pattern)은 단일 프로토콜로 이 두 가지를 모두 처리하려고 시도하는 것입니다.

모델 컨텍스트 프로토콜(Model Context Protocol, MCP): 이는 에이전트-도구(Agent-to-Tool) 계층을 담당합니다. 이는 단일 에이전트가 로컬 데이터베이스에서 안전하게 데이터를 읽거나, 기업용 스토리지에 연결하거나, 개발 환경에 액세스하는 방식을 표준화합니다.

에이전트 간 프로토콜 (Agent-to-Agent Protocol, A2A): 이는 **에이전트 간 계층 (Agent-to-Agent layer)**을 처리합니다. 이는 서로 다른 프레임워크와 사업 부문에 걸쳐, 독립적이고 주권적인 지능형 시스템들이 각자의 자연스러운 시맨틱 양식(semantic modalities)(작업 협상, 대화 상태 전달 또는 워크플로 인계 등)을 통해 서로 통신하는 방식을 표준화합니다.

핵심적인 차이점: MCP는 에이전트를 도구에 연결합니다 (수직적 통합, vertical integration). A2A는 에이전트들을 서로 연결합니다 (수평적 통합, horizontal integration). 이들은 경쟁 관계가 아니라 상호 보완되도록 명시적으로 설계되었습니다. 이 둘은 함께 현대적인 멀티 에이전트 시스템 (multi-agent systems)을 위한 2계층 상호운용성 스택 (interoperability stack)을 형성합니다.

내부 구조: A2A는 실제로 어떻게 작동하는가

통신 스타일을 깊이 파고들기 전에, A2A가 구축된 기술적 토대를 이해하는 것이 도움이 됩니다. 왜냐하면 A2A는 의도적으로 바퀴를 새로 발명하지 않았기 때문입니다.

A2A는 잘 확립된 웹 기술들을 활용합니다.

• HTTP/HTTPS — 주요 전송 계층 (production 배포 시 현대적인 TLS를 포함한 HTTPS가 필요함)
• JSON-RPC 2.0 — 모든 요청과 응답을 위한 구조화된 데이터 교환 형식
• Server-Sent Events (SSE) — 에이전트에서 클라이언트로의 실시간 단방향 업데이트 스트리밍

모든 A2A 에이전트는 **에이전트 카드 (Agent Card)**라고 불리는 작은 JSON 문서를 게시하며, 이는 일반적으로 /.well-known/agent.json에서 제공됩니다. 이 파일은 에이전트의 신원, 기술, 엔드포인트 URL 및 인증 요구 사항을 나열하여, 별도의 독점적인 레지스트리(registry)나 조정 계층(coordination layer) 없이도 에이전트 간의 설정 없는 발견 (zero-configuration discovery)을 가능하게 합니다.

보안은 처음부터 내장되어 있습니다. A2A는 OAuth 2.0 및 HTTP 헤더를 통해 전달되는 API 키 지원을 포함하여, OpenAPI 보안 스키마와 일치하는 엔터프라이즈급 인증 및 인가 메커니즘을 통합합니다.

네 가지 A2A 통신 스타일

A2A 표준은 분산 시스템 엔지니어들이 수십 년 동안 의존해 온 구조적 통신 패턴을 반영하는 명확한 실행 모드(execution modes)를 정의합니다.

1. 동기 (Synchronous, Blocking)

한 에이전트가 작업을 전송하고, 응답하는 에이전트가 최종 결과물(artifact)을 반환할 때까지 자신의 실행 컨텍스트(execution context)를 차단(block)합니다.

마이크로서비스 비유: 표준 REST 호출 (GET /resource).

AI 사용 사례: 오케스트레이터(Orchestrator) 에이전트가 고객 응답을 구성하기 전에 실시간 리스크 컴플라이언스 점수를 요청하는 것과 같이, 빠르고 임계 경로(critical path) 의존성이 있는 쿼리.

2. 비동기 (Asynchronous, Non-Blocking)

한 에이전트가 작업 객체(task object)를 발송하고 즉시 다른 프로세스로 복귀합니다. 원격 에이전트는 해당 작업을 큐(queue)에 쌓고 백그라운드에서 처리합니다.

마이크로서비스 비유: 메시지 큐(Message queues) 또는 이벤트 스트림 (Kafka, RabbitMQ).

AI 사용 사례: 법률 에이전트(Legal Agent)가 400페이지 분량의 기업 인수 계약서를 읽거나, 데이터 에이전트(Data Agent)가 복잡한 배치 분류(batch classification)를 실행하는 것과 같은 장시간 소요되는 인지 작업.

3. 스트리밍 (Streaming)

단일 완료 페이로드(payload)를 기다리는 대신, 연속적인 데이터 토큰(tokens) 또는 부분적인 상태(partial states)가 에이전트 간에 실시간으로 동적으로 흐릅니다.

마이크로서비스 비유: gRPC 스트리밍 또는 서버 전송 이벤트 (SSE, Server-Sent Events).

AI 사용 사례: 실시간 음성 전사(transcription) 에이전트가 분석 에이전트에게 데이터를 공급하거나, 사용자 경험(UX) 측면에서 즉각적인 토큰 전달이 필요한 대화형 멀티 에이전트 채팅 인터페이스.

4. 푸시 알림 (Push Notifications, Event-Driven)

에이전트는 웹 콜백(web callback) 또는 구독(subscription)을 등록하여, 특정 상위 이벤트(upstream event)나 상태 변화가 발생할 때만 선제적인 알림을 받습니다. 완료(completed), 실패(failed), 또는 **입력 필요(input-required)**와 같이 중요한 작업 상태 변화가 발생하면, 서버는 클라이언트가 제공한 **웹훅(web hook)**으로 비동기 HTTP POST 알림을 보냅니다. 이를 위해서는 서버가 자신의 에이전트 카드(Agent Card)에 푸시 알림(push notification) 기능을 명시해야 합니다.

마이크로서비스 비유: 웹훅(Web hooks) 또는 이벤트 버스(Event Bus).

AI 활용 사례: 이벤트 기반 거버넌스(Event-driven governance). 예를 들어, 계정 에이전트(Account Agent)가 100만 달러를 초과하는 계약서를 초안할 때만 자동화된 컴플라이언스 에이전트(Compliance Agent)가 깨어나 거래를 감사하는 방식입니다.

핵심 아키텍처 통찰: 성숙한 멀티 에이전트 엔터프라이즈 시스템은 결코 단일 상호작용 패턴을 강요하지 않습니다. 대신 내부 API 게이트웨이 평면(API gateway plane)을 활용하여 트래픽을 관리하고, 작업을 라우팅하며, 폴백(fallback) 전략을 처리함으로써 네 가지 패턴을 모두 결합한 메시(mesh)를 구축합니다.

결정론적 인터페이스에서 의미론적 인터페이스로의 결정적 전환

전통적인 마이크로서비스에서 API 계약(contract)은 엄격하게 **결정론적(deterministic)**입니다. 즉, 정확히 이 바이트를 보내면, 정확히 저 바이트를 받습니다.

멀티 에이전트 네트워크에서 인터페이스는 **의미론적(semantic)**입니다. 즉, 의도(intent)를 보내면, 추론된 응답을 받습니다.

모든 초정밀 쿼리 변형에 대해 취약한 엔드포인트(endpoint)를 유지하는 대신, 에이전트는 자신의 에이전트 카드(Agent Card)를 사용하여 전반적인 "기술(Skills)"과 예상되는 구조적 입출력 스키마(schemas)를 광고합니다. 3분기 잔여 인원 예산을 계산할 수 있는 금융(Finance) 에이전트는 비즈니스 사용자가 요청의 뉘앙스를 약간 변경하더라도 새로운 API 엔드포인트를 배포할 필요가 없습니다. 에이전트는 A2A 작업 수명 주기(task lifecycle)를 통해 의도를 해석하기 때문입니다.

이 수명 주기(lifecycle)의 **"심장 박동(beating heart)"**은 작업의 입력 필요(input-required) 상태입니다. 이를 통해 에이전트는 작업 중간에 실행을 일시 중단하고 클라이언트나 다른 에이전트로부터 추가 정보를 요청할 수 있으며, 이는 기존의 REST API가 설계 단계부터 결코 수행할 수 없었던 기능입니다. 덕분에 에이전트 간의 대화는 정적인 마이크로서비스 (Microservice) 계약(contract)과는 달리 상태 유지(stateful)가 가능하며 적응형(adaptive)으로 동작합니다.

결론

2010년대의 마이크로서비스 (microservices) 혁명과 오늘날의 멀티 에이전트 (multi-agent) AI 생태계 사이의 유사점은 단순히 외형적인 것에 그치지 않습니다. 서비스 검색 (service discovery), 보안 경계 (security boundaries), 비동기 통신 (async communication), 그리고 조합 가능한 아키텍처 (composable architecture)에 대해 어렵게 얻은 동일한 교훈들이 A2A 및 MCP와 같은 개방형 표준 (open standards)에 다시 학습되고 인코딩되고 있습니다.

A2A는 AI 에이전트가 서로 다른 프레임워크, 벤더, 플랫폼을 넘어 서로를 발견하고, 통신하며, 거래할 수 있도록 지원하는 개방형 표준입니다. MCP는 이러한 각 에이전트가 자신의 도구(tools)에 연결되는 방식을 처리합니다. 이 둘은 결합되어 아키텍트들에게 모듈식(modular)이고, 상호 운용(interoperable) 가능하며, 프로덕션 준비가 된 (production-ready) AI 시스템을 구축하기 위한 원칙적인 2계층 모델을 제공합니다.

A2A의 파트너사가 1년도 채 되지 않아 50개에서 150개 이상의 조직으로 늘어난 추진력은 단순한 사실 하나를 강조합니다. 즉, AI 에이전트 생태계의 파편화 (fragmentation)는 업계가 공동으로 해결하기로 선택한 문제라는 점입니다. 오늘날 이 분야에서 활동하는 엔지니어들에게 질문은 더 이상 이러한 프로토콜이 중요한가 하는 것이 아닙니다. 이미 이 프로토콜을 사용하고 있는 주변 시스템들에 당신의 아키텍처가 준비되어 있는가 하는 것입니다.

감사합니다
Sreeni Ramadorai