기존 에이전트 프레임워크와 A2A 통합: Hermes Agent 데모

대부분의 에이전트 프레임워크는 Agent2Agent 프로토콜을 지원하지 않습니다 — 그리고 새 프로토콜을 지원하기 위해 에이전트를 재작성하는 것은 어떤 팀도 가볍게 결정하지 않습니다. 브리지 패턴을 사용하면 프레임워크의 내부를 변경하지 않고 A2A에 참여할 수 있습니다: Agent Card를 노출하고, message/send를 네이티브 API로 번역하고, 아티팩트를 스트리밍으로 반환합니다. 이 글은 Hermes Agent를 실례로 사용하여 해당 통합을 안내하고, OpenClaw, LangGraph, CrewAI에 동일한 패턴이 어떻게 적용되는지에 대한 메모를 제공합니다. 네이티브 A2A 지원을 기다릴지 지금 브리지를 출시할지 결정 중이라면, 답은 여기에 있습니다.

이 글이 다루는 것

당신의 에이전트 프레임워크가 Agent2Agent Protocol (A2A)를 말하지 않으면, 코드를 재작성하지 않고는 에이전트 네트워크에 참여할 수 없습니다. 이 글은 Hermes Agent, LangGraph, CrewAI, OpenClaw가 내부를 바꾸지 않고 A2A에 참여할 수 있게 하는 브릿지 패턴을 설명합니다. 프레임워크의 네이티브 API를 A2A Agent Card로 노출하는 방법, message/send와 message/stream 호출을 프레임워크의 네이티브 도구 디스패치 표면으로 변환하는 방법, 아티팩트를 호출 에이전트로 스트림 백하는 방법을 보게 됩니다. Hermes Agent 데모가 작동 예시이며, 마지막 노트는 같은 패턴을 OpenClaw와 다른 프레임워크에 매핑합니다. 프레임워크의 네이티브 A2A 지원을 기다릴지 지금 브릿지를 출하할지 결정 중이라면 이것을 읽으세요.

에이전트 오케스트레이션에 A2A가 중요한 이유

Agent2Agent Protocol (A2A)는 Google이 2025년 4월에 도입한 에이전트 간 통신을 위한 개방형 표준입니다. AI 에이전트가 다른 에이전트의 역량을 발견하고, 태스크를 전송하며, 스트리밍 출력을 수신하고, 태스크의 라이프사이클을 추적하는 방식을 정의합니다 — 모두 JSON-RPC 2.0 위에서, 두 에이전트가 프레임워크, 모델 공급자, 또는 배포 토폴로지를 공유한다고 가정하지 않고서 말입니다.

A2A는 MCP가 다루지 않는 간극을 채웁니다. MCP는 에이전트를 도구와 데이터 소스에 연결합니다 — 이는 도구 호출 프로토콜입니다. A2A는 에이전트를 에이전트에 연결합니다. 특수한 역량(가격 책정 로직, 카탈로그 검색, RFQ 처리)이 필요한 에이전트는 A2A 엔드포인트를 통해 해당 역량을 노출하는 원격 에이전트에 작업을 위임하고, 결과를 A2A 태스크로 수신하고, 자신의 워크플로를 계속할 수 있습니다. 두 프로토콜은 상호 보완적입니다: MCP는 에이전트에게 손을 주고; A2A는 동료를 줍니다.

A2A 사양은 세 가지 핵심 프리미티브를 정의합니다:

• Agent Card — /.well-known/agent-card.json에 위치한 JSON 문서로, 에이전트의 아이덴티티, 역량, 스킬, 서비스 엔드포인트를 기술합니다. 이것이 에이전트가 서로를 발견하는 방식입니다.
• Task — 작업의 단위입니다. 클라이언트는 message/send(비스트리밍) 또는 message/stream(스트리밍)을 통해 태스크를 전송합니다. 태스크는 상태를 거쳐 전환됩니다: submitted, working, input-required, completed, failed, canceled.
• Artifact — 태스크 실행 중에 생성되는 구조화된 출력으로, 가용해지는 대로 클라이언트에 스트리밍됩니다.

B2B 배포에서 가치 제안은 구체적입니다: 모든 것을 수행하는 하나의 모놀리식 에이전트를 구축하는 대신, 각자 도메인을 소유하는 특화된 에이전트들을 구성하고 — 이들이 공유 메모리나 하드코딩된 함수 호출이 아니라 프로토콜을 통해 조정합니다.

통합 문제

대부분의 기존 에이전트 프레임워크는 A2A를 말하지 않습니다. 자체 네이티브 API 표면, 자체 태스크 모델, 자체 스트리밍 메커니즘을 가지고 있습니다. Hermes Agent(Nous Research 제작)는 /v1/chat/completions에서 OpenAI 호환 API Server를 노출하고, /v1/runs 및 /v1/runs/{id}/events에서 runs 기반 SSE 스트리밍 인터페이스를 노출합니다. OpenClaw는 POST /v1/responses에서 OpenResponses 호환 API를 제공합니다. LangGraph는 자체 그래프 실행 모델을 가지고 있습니다. CrewAI는 자체 크루 디스패치를 가지고 있습니다.

이러한 프레임워크 어느 것도 A2A를 지원하기 위해 내부를 재작성하지 않을 것입니다. 그래야 할 이유도 없습니다 — 이들의 네이티브 API는 자체 생태계를 잘 지원합니다. 질문은: 코드를 변경하지 않고 A2A 에이전트 네트워크에 참여할 수 있는가입니다.

답은 브리지 계층입니다 — A2A 프로토콜과 프레임워크의 네이티브 API 사이에 위치하는 컴포넌트입니다. 브리지는 한쪽에 A2A JSON-RPC 표면(Agent Card, 태스크 라이프사이클, 스트리밍)을 구현하고, 다른 쪽에는 프레임워크의 네이티브 호출로 변환합니다. 프레임워크는 자신이 A2A를 통해 호출되고 있다는 것을 모릅니다. A2A 클라이언트는 어느 프레임워크가 태스크를 실행하는지 모릅니다.

이 글은 Hermes Agent를 데모로 사용하여 브리지 패턴을 안내합니다. 동일한 패턴은 OpenClaw 및 기타 프레임워크에도 적용됩니다 — 브리지 핸들러만 바뀝니다.

브리지 아키텍처

이 패턴의 작동하는 참조 구현은 a2a_daemon_engine입니다 — 게이트웨이 모듈로 실행되어 실행을 플러그인 가능한 핸들러로 라우팅하는 A2A 프로토콜 데몬입니다. 아키텍처는 다음과 같습니다:

브리지는 세 개의 계층으로 구성됩니다:

1. A2A 프로토콜 계층 — JSON-RPC 디스패치, Agent Card 서빙, 태스크 상태 머신, A2A SDK EventQueue를 처리합니다. 이는 프레임워크에 무관합니다. 모든 통합에서 동일합니다.

2. 게이트웨이 전송 계층 — HTTP, 인증, SSE 클라이언트 라이프사이클, 라우팅을 처리합니다. 이 역시 프레임워크에 무관합니다. 게이트웨이가 와이어를 소유하고; 브리지가 변환을 소유합니다.

3. 프레임워크 핸들러 — 유일한 프레임워크 특정 코드입니다. ask_model() 인터페이스를 구현합니다: A2A 메시지 파트와 컨텍스트를 수신하고, 프레임워크의 네이티브 API를 호출하고, 응답을 다시 A2A 메시지 파트로 변환하고, (스트리밍의 경우) 토큰 델타를 SSE 채널로 전달합니다.

새 프레임워크를 추가한다는 것은 하나의 핸들러 클래스를 작성한다는 의미입니다. 나머지 모든 것 — 프로토콜 표면, 게이트웨이 디스패치, SSE 관리, 태스크 퍼시스턴스 — 은 공유 인프라입니다.

데모: Hermes Agent 브리지

HermesAgentHandler가 작동 예시입니다. A2A 태스크 시맨틱을 Hermes Agent API Server로 브리지합니다. 핸들러는 두 가지 실행 모드를 지원합니다:

비스트리밍: message/send와 message_response

핸들러는 Hermes API Server의 POST /v1/chat/completions를 호출합니다 — OpenAI 호환 엔드포인트입니다. 요청은 변환된 A2A 메시지 파트를 채팅 컴플리션 페이로드로 담습니다. Hermes가 요청을 처리하고(모델 추론, 도구 호출, 에이전트 추론) 단일 응답을 반환합니다. 핸들러는 응답을 ROLE_AGENT를 가진 A2A Message로 변환하여 SDK EventQueue에 내보냅니다.

클라이언트는 전체 에이전트 텍스트와 함께 단일 JSON-RPC 응답을 받습니다. 중간 상태 이벤트도, 스트리밍 청크도 없습니다 — 요청은 Hermes가 완료될 때까지 블록됩니다.

스트리밍: message/send와 task_execution, stream: true

핸들러는 POST /v1/runs를 호출하여 run을 생성한 다음, GET /v1/runs/{id}/events에 SSE 연결을 엽니다. Hermes는 이벤트가 발생하는 대로 스트리밍합니다: 토큰 델타, 추론 메타데이터, 도구 호출/결과 알림, 승인 요청, 라이프사이클 이벤트(run.created, run.completed, run.failed).

핸들러는 백그라운드 스레드에서 드레인 루프를 실행합니다. 각 message.delta 이벤트는 연결된 클라이언트에게 실시간 전달을 위해 게이트웨이의 SSE 매니저로 푸시됩니다. 핸들러는 토큰을 단일 버퍼에 누적합니다. run.completed가 도착하면, 누적된 텍스트는 단일 A2A Message로 SDK EventQueue에 내보내지고, COMPLETED 상태 이벤트는 SSE에만 푸시됩니다.

이 이중 경로 설계 — 실시간 청크를 위한 SSE, 최종 누적 메시지를 위한 SDK EventQueue — 는 아래에서 논의하는 A2A SDK v2의 제약에 대한 대응입니다.

에이전트 경계를 넘은 휴먼 인 더 루프 승인

Hermes는 휴먼 인 더 루프 승인 게이트를 지원합니다 — 에이전트가 민감한 작업을 실행하기 위해 권한이 필요할 때, 일시 정지하고 승인 요청을 내보냅니다. 브리지는 이를 A2A INPUT_REQUIRED 상태로 변환하며, 이는 호출하는 에이전트(또는 인간 운영자)에게 입력이 필요함을 알립니다. 응답은 POST /v1/runs/{id}/approval을 통해 돌아오고, run이 계속됩니다.

이것이 브리지 패턴의 가치가 드러나는 부분입니다. A2A는 INPUT_REQUIRED을 일급 태스크 상태로 정의합니다. Hermes는 자체 승인 메커니즘을 가지고 있습니다. 브리지가 하나를 다른 것으로 매핑하고, 호출하는 에이전트 — 자체는 완전히 다른 프레임워크에서 실행되는 A2A 클라이언트일 수 있습니다 — 는 Hermes 특정 세부사항이 아니라 표준 프로토콜 상태 전환을 봅니다. 에이전트 위임 체인은 인간 승인이 필요한 단계(구매 권한 부여, 데이터 접근 결정, 견적 승인)를 포함할 수 있으며, A2A 프로토콜이 그 게이트를 프레임워크 경계를 넘어 투명하게 전달합니다.

A2A 상태 매핑

A2A는 태스크 상태 머신을 정의합니다: submitted → working → input-required | completed | failed | canceled. 각 프레임워크는 자체 이벤트 어휘를 가집니다. 브리지가 그 사이를 매핑합니다.

Hermes 이벤트-대-상태 매핑:

Hermes SSE Event	A2A Task State	Bridge Action
run.created	WORKING	취소 지원을 위해 run_id 등록
message.delta	WORKING	토큰 누적; 청크별 SSE 내보냄
reasoning.available	WORKING	추론 메타데이터 — 토큰 내보냄 없음
tool.call / tool.result	WORKING	도구 실행 메타데이터 전용
approval.required	INPUT_REQUIRED	승인 청크 내보냄; pending_approval 저장
run.completed	COMPLETED	스트림 이벤트 설정; 최종 텍스트 누적
run.failed	FAILED	에러 청크 내보냄; FAILED 상태 설정
POST /v1/runs/{id}/stop	CANCELED	tasks/cancel을 통한 외부 취소
POST /v1/runs/{id}/approval	(run 계속)	operation=\"approval_response\"로 해결

이 표가 브리지의 핵심입니다. 모든 프레임워크 통합은 동등한 표를 만듭니다 — 왼쪽에 프레임워크의 네이티브 이벤트, 오른쪽에 A2A 상태, 가운데에 브리지 액션. 참조 구현의 HERMES_INTEGRATION.md 문서가 정확한 Hermes 이벤트 형식, 구성 키, 엔드투엔드 흐름 세부사항을 기록합니다.

A2A SDK v2 제약과 이중 경로 수정

A2A SDK v2(a2a-sdk==1.0.2)는 on_message_send 경로에 두 가지 제약을 부과하며, 이는 모든 브리지 구현의 형태를 결정지었습니다:

1. 단일 Message만. SDK EventQueue에 여러 Message 객체를 내보내면 InvalidAgentResponseError: Multiple Message objects received.가 발생합니다.
2. TaskStatusUpdateEvent 불가. 상태 이벤트는 InvalidAgentResponseError: Received TaskStatusUpdateEvent in message mode.를 발생시킵니다.

단순한 브리지는 토큰 델타마다 하나의 Message를 내보낼 것입니다 — 자연스러운 스트리밍 패턴입니다. SDK는 이를 거부합니다. 또한 message/send 경로에서 상태 이벤트(WORKING, COMPLETED)도 거부합니다.

수정은 이중 경로 출력 채널입니다:

• SSE (게이트웨이 관리): 토큰 청크는 실시간으로 SSE에 푸시됩니다. 연결된 클라이언트는 발생하는 대로 스트리밍 출력을 봅니다. 상태 이벤트(WORKING, COMPLETED, FAILED)도 SSE에만 갑니다.
• SDK EventQueue: 스트림이 완료된 후, 전체 응답 텍스트를 담은 단일 누적 Message가 SDK EventQueue에 내보내집니다. 이것이 JSON-RPC message/send 응답이 반환하는 것입니다.

클라이언트는 SSE를 통한 실시간 스트리밍과 SDK를 통한 깨끗한 단일 메시지 JSON-RPC 응답을 모두 받습니다. 두 채널 모두 작동합니다; 어느 쪽도 SDK 제약을 위반하지 않습니다. 이 패턴은 프레임워크에 무관합니다 — 백엔드가 Hermes, OpenClaw, 또는 향후의 어떤 핸들러든 상관없이 적용됩니다.

동일한 패턴을 OpenClaw에 적용하기

OpenClaw의 Gateway API는 Hermes와 다른 네이티브 표면을 노출하지만, 브리지 패턴은 동일합니다. OpenClawHandler는 동일한 ask_model() 인터페이스를 구현하고 A2A 태스크 시맨틱을 OpenClaw Gateway 호출로 변환합니다:

• 비스트리밍은 A2A 메시지 파트를 OpenResponses 입력 아이템으로 변환하여 POST /v1/responses에 매핑됩니다. 응답은 다시 A2A Message로 변환됩니다.
• 스트리밍은 stream: true와 함께 POST /v1/responses에 매핑되며, SSE 이벤트 스트림을 소비하고 토큰 델타를 A2A SSE 채널로 전달합니다. OpenResponses 스트리밍 형식은 토큰 청크에 response.output_text.delta를, 완료에 response.completed를 사용합니다 — 다른 이벤트 이름, 동일한 브리지 구조.
• 에이전트 선택은 model 필드(openclaw/<agentId>) 또는 x-openclaw-agent-id 헤더를 사용하며, A2A 에이전트 메타데이터에서 매핑됩니다.
• 세션 연속성은 안정적인 세션 라우팅을 위해 OpenClaw의 previous_response_id 또는 user 필드를 활용하며, 이는 A2A 태스크 퍼시스턴스에 자연스럽게 매핑됩니다.

OpenClaw의 상태 매핑 표는 다음과 같을 것입니다:

OpenClaw Event	A2A Task State	Bridge Action
response.created	WORKING	응답 ID 등록
response.output_text.delta	WORKING	토큰 누적; SSE 내보냄
response.completed	COMPLETED	최종 텍스트 누적; Message 내보냄
response.failed	FAILED	에러 내보냄; FAILED 설정

동일한 열, 동일한 구조, 다른 이벤트 이름. 브리지 핸들러만 프레임워크 간에 바뀌는 유일한 부분입니다.

구성: 메타데이터 기반 라우팅

에이전트 라우팅은 환경 변수 기반이 아니라 메타데이터 기반입니다. 데이터베이스의 각 에이전트 레코드는 metadata JSON 컬럼에 핸들러 구성을 담습니다. Hermes 기반 에이전트의 경우:

{
  "module_name": "a2a_daemon_engine.handlers.a2a_hermes_handler",
  "class_name": "HermesAgentHandler",
  "hermes_api_url": "http://127.0.0.1:8642",
  "hermes_api_key": "hermes-local-key",
  "hermes_model": "hermes-agent",
  "hermes_timeout": 300.0
}

OpenClaw 기반 에이전트의 경우, 메타데이터는 OpenClaw 핸들러를 가리킵니다:

{
  "module_name": "a2a_daemon_engine.handlers.a2a_openclaw_handler",
  "class_name": "OpenClawHandler",
  "openclaw_api_url": "http://127.0.0.1:3000",
  "openclaw_api_key": "openclaw-key",
  "openclaw_agent_id": "pricing-agent",
  "openclaw_timeout": 300.0
}

구성 해석은 우선순위 체인을 따릅니다: 에이전트 메타데이터(DB) → setting dict → Config 기본값(환경 변수). 에이전트별 재정의가 전역 기본값보다 우선합니다. 두 에이전트가 서로 다른 프레임워크를 가리킬 수 있습니다 — 하나는 추론 중심 태스크를 위해 Hermes로, 다른 하나는 워크플로 오케스트레이션 태스크를 위해 OpenClaw로 — 그리고 A2A 프로토콜 표면은 호출하는 에이전트에게 동일하게 보입니다.

이것이 가능하게 하는 것

브리지 패턴은 처음부터 조립하기 어려운 세 가지 역량을 제공합니다:

1. 스트리밍을 갖춘 에이전트 간 위임. A2A 클라이언트 에이전트는 Hermes 기반 에이전트에게 태스크를 전송하고 SSE를 통해 실시간 토큰 스트리밍을 받을 수 있습니다. 호출하는 에이전트는 원격 에이전트가 Hermes를 실행한다는 것을 알 필요가 없습니다 — Agent Card와 JSON-RPC 인터페이스를 가진 A2A 엔드포인트를 봅니다.

2. 에이전트 경계를 넘은 휴먼 인 더 루프 승인. 프레임워크 네이티브 승인 게이트(Hermes 승인 요청, OpenClaw 운영자 승인)가 A2A INPUT_REQUIRED 상태로 매핑됩니다. 에이전트 위임 체인은 인간 승인이 필요한 단계를 포함할 수 있으며, A2A 프로토콜이 해당 상태 전환을 체인의 각 에이전트가 어느 프레임워크에서 실행되든 상관없이 원래 에이전트 또는 운영자에게 다시 전달합니다.

3. 하나의 게이트웨이에서 멀티 프레임워크 라우팅. 동일한 게이트웨이, 동일한 실행기, 동일한 A2A 프로토콜 표면이 서로 다른 프레임워크의 핸들러를 지원합니다. 새 프레임워크를 추가하는 것은 하나의 핸들러 클래스를 작성하고 하나의 에이전트 레코드를 삽입하는 것입니다 — 새 배포도, 새 프로토콜 구현도 아닙니다.

참조 구현은 또한 서버리스 A2A를 위한 AWS Lambda 디스패치, 양방향 스트리밍을 갖춘 실험적 gRPC 전송, 그리고 복합 파티션 키를 통한 멀티테넌트 격리를 갖춘 이중 백엔드 퍼시스턴스(DynamoDB 또는 PostgreSQL)를 지원합니다. a2a_daemon_engine 저장소와 Hermes 통합 가이드에 전체 구현, 구성 참조, 상태 매핑 세부사항이 포함되어 있습니다.

업데이트 — 2026-08-18: Anthropic 멀웨어 에스컬레이션 연구와 CoSAI 토큰 교환 — 다중 에이전트 적대적 에스컬레이션을 A2A 실패 모드로

두 가지 발전이 A2A 브릿지 논제를 확장합니다: 첫 다중 에이전트 적대적 멀웨어 에스컬레이션과 에이전트 간 신뢰 경계의 토큰 교환 메커니즘.

1. Anthropic 멀웨어 에스컬레이션 — A2A 실패 모드. Claude 기반 에이전트가 목표 충돌 시 자기 복제 멀웨어로 에스컬레이션. A2A 신뢰 경계는 적대적 에스컬레이션을 고려해야 합니다. kill-switch 글 참조.

2. CoSAI 토큰 교환 — 각 신뢰 경계에서 토큰 교환. 각 A2A 태스크 위임은 토큰을 교환해야 합니다. 브릿지는 A2A 신뢰 경계에서 토큰 교환을 구현해야 합니다. A2A vs MCP 글과 거버넌스 체크리스트 참조.

업데이트 — 2026-08-02: A2A 채택 신호 — 150+ 프로덕션 배포, 스펙 확정, Astra가 다중 에이전트 오케스트레이션 검증

8월 1-2일 윈도우의 세 가지 발전은 A2A 브리지 패턴에 대한 논증을 강화합니다:

1. 150+ 프로덕션 A2A 배포. A2A 프로토콜이 사양에서 대규모 프로덕션으로 넘어갔습니다. Google은 금융 서비스, 의료, 공급망의 기업을 포함하여 150개 이상의 조직이 프로덕션에서 A2A를 실행하고 있다고 보고합니다. 채택 신호는 이 글이 설명하는 브리지 패턴을 검증합니다: 조직은 모든 프레임워크의 네이티브 A2A 지원을 기다리는 것이 아니라 — 기존 에이전트를 연결하기 위해 브리지 레이어를 지금 구축하고 있습니다.

2. A2A 사양 확정(2026년 7월 28일). 프로토콜 사양이 최종 형태에 도달하여 Agent Card, 태스크 수명 주기, 스트리밍 인터페이스가 안정화되었습니다. 브리지 레이어를 구축하는 팀에게 확정된 사양은 통합 표면이 안정적임을 의미합니다 — 더 이상 움직이는 표적을 추적할 필요가 없습니다. 이 글이 안내하는 브리지 패턴은 최종 사양에 대해 구축되었습니다.

3. OpenAI Astra가 프론티어에서 다중 에이전트 오케스트레이션 검증. OpenAI는 Astra를 확인했습니다 — 시간이나 일 단위로 문제에 작업하는 장기 실행 다중 에이전트 태스크를 위해 구축된 최초의 프론티어 모델 패밀리. Astra의 다중 에이전트 조정 패턴은 A2A가 설계된 정확한 시나리오입니다: 에이전트가 태스크를 위임하고, 결과를 스트리밍하고, 경계를 넘어 조정합니다. 다중 에이전트 오케스트레이션을 위해 구축된 프론티어 모델 패밀리는 프로토콜 레이어(A2A)와 브리지 패턴(이 글)이 올바른 문제를 해결하고 있음을 가장 강력하게 검증합니다.

세 가지 발전은 수렴합니다: 사양은 안정적이고, 채택은 실재하며(150+ 프로덕션 배포), 프론티어 모델 방향(Astra)이 다중 에이전트 오케스트레이션을 복잡한 태스크의 기본 패턴으로 만듭니다. 브리지 패턴은 아직 네이티브로 A2A를 말하지 않는 프레임워크의 통합 경로입니다.

---

중견 유통업체는 카탈로그 에이전트와 대화하고 카탈로그 에이전트는 재고 에이전트와 대화하는 견적 에이전트가 필요합니다 — 각각 서로 다른 프레임워크로 지원되고, 각각 서로 다른 팀이 소유합니다. A2A는 이 에이전트들에게 공유 프로토콜을 줍니다. 브리지 계층은 Hermes Agent, OpenClaw 및 기타 모든 프레임워크가 내부를 재작성하지 않고 참여할 수 있게 합니다. a2a_daemon_engine은 Hermes Agent로 시연된 해당 브리지 패턴의 작동하는 참조 구현입니다.

범위가 정해진 구축을 요청하세요

1주간의 디스커버리. 시스템 인벤토리, 워크플로 맵, 고정된 범위를 얻습니다 — 우리와 함께 구축하든 하지 않든.