A2A

독립적인 AI 에이전트를 협업시키는 방법: Hermes Agent를 위한 A2A 브리지

글쓴이: IdeaBosque최종 업데이트: 2026年7月24日

이것이 당신의 비즈니스에 의미하는 바

에이전트를 다시 쓰지 않고도 협업합니다. Agent2Agent Protocol(A2A)은 AI 에이전트가 서로를 발견하고, 작업을 위임하고, 결과를 스트리밍하도록 하는 개방형 표준입니다. 얇은 브리지가 기존 에이전트의 내부를 바꾸지 않고 그 표준을 말하게 합니다——이미 들인 투자가 그대로 살아납니다.
공급업체 종속이 없습니다. 브리지가 표준과 에이전트 사이에 위치하므로, 나중에 기반 에이전트 프레임워크를 교체해도 그 위에 쌓은 통합은 깨지지 않습니다. 다른 팀들은 여전히 같은 표준 엔드포인트를 호출합니다.
하나의 시스템이 다수의 고객이나 사업부를, 엄격한 데이터 분리와 함께 서비스합니다. 테넌트 격리는 애플리케이션 코드뿐 아니라 데이터베이스 계층에서 강제되므로, 코딩 실수가 있어도 한 고객의 데이터가 다른 고객으로 새어 나갈 수 없습니다. 이것이 보안 심사를 통과하게 하는 결정적 차이입니다.
사람이 민감한 작업의 통제권을 유지합니다. 에이전트가 승인을 필요로 할 때——구매, 데이터 접근 결정, 견적 승인——그 요청은 표준의 "승인 대기" 상태로 나타나, 프레임워크 경계를 넘어서라도 그 사슬을 시작한 사람이나 에이전트에게까지 되돌아옵니다.
이는 슬라이드가 아니라 실재하며 검증된 것입니다. 전체가 오픈소스 배포(docker-a2a-hermes-agent-gateway)로 패키징되어 있으며, 각 기능을 당신이 의존하기 전에 검증하는 자동화 테스트 모음을 갖추고 있습니다.

문제: 서로 대화할 수 없는 에이전트

대부분의 조직은 "하나의 AI 에이전트"를 채택하는 것이 아니라 여러 개를 쌓아 갑니다. 여기에 견적 에이전트, 저기에 카탈로그 조회 에이전트, 그리고 다른 팀이 소유한 재고 에이전트——흔히 서로 다른 프레임워크 위에, 때로는 서로 다른 공급업체에서, 서로 다른 시기에 구축됩니다. 개별적으로는 잘 작동합니다. 병목은 이들을 협업시키는 것, 즉 작업을 다른 에이전트에게 넘기고, 결과를 기다리고, 제어를 되돌리는 데 있습니다.

각 에이전트를 다른 모든 에이전트와 손으로 배선해 해결하는 방식은 느리고 취약하며, 에이전트가 늘 때마다 더 나빠집니다. 게다가 조용히 종속을 초래합니다——통합이 한 공급업체의 인터페이스에 하드코딩되는 순간, 그 공급업체 교체는 전부 다시 하는 것을 의미합니다.

**Agent2Agent Protocol(A2A)**은 그 병목을 없애는 개방형 표준입니다. 각 에이전트가 무엇 위에 구축되었든, 서로를 발견하고, 작업을 위임하고, 진행 상황을 스트리밍하고, 완료를 보고하기 위한 공통 언어를 정의합니다. 표준을 한 번 채택하면, 이후 추가되는 모든 에이전트가 나머지와 같은 언어를 말합니다.

함정은, 기존 에이전트가 A2A를 기본으로 말하지 않는다는 점입니다. 예를 들어 Nous Research의 Hermes Agent는 자체 인터페이스를 노출합니다. 잘 작동하는 에이전트에 새 프로토콜을 더하려고 다시 쓰는 것은, 팀이 피하고 싶어 하는 바로 그 비싸고 위험한 프로젝트입니다.

답은 브리지입니다——바깥에서는 A2A를 말하고, 안에서는 에이전트 자신의 언어로 소통하는 작은 번역 계층입니다. 에이전트 자체는 결코 바뀌지 않습니다. docker-a2a-hermes-agent-gateway 프로젝트는 그 브리지의 작동하는 오픈소스 예시로, 단일 배포 단위로 패키징되어 있습니다.

각 부분이 어떻게 맞물리는가

움직이는 부분은 셋이며, 그중 외부에 노출되는 것은 단 하나뿐입니다.

정문(게이트웨이). 모든 것은 통제된 단일 입구로 들어옵니다. 누가 들어올 수 있는지, 요청이 어느 고객에 속하는지, 호출자가 얼마나 빨리 진행할 수 있는지, 실시간 진행을 어떻게 되돌려 줄지를 결정합니다. 그 밖의 것은 직접 접근할 수 없습니다.
번역기(브리지). 개방형 A2A 표준으로 요청을 받아, 당신의 에이전트가 실제로 이해하는 형태로 바꾸고, 응답을 다시 되돌립니다. 특정 에이전트를 아는 유일한 부분이며, 그렇기에 에이전트를 나중에 교체할 수 있습니다.
에이전트와 그 작업 기록. 기존 에이전트가 실제 추론을 수행합니다. 그것이 하는 모든 일이 기록되며——모든 작업, 모든 메시지——고객별로 엄격히 분리됩니다.

정문과 기록이 에이전트 본체와 독립되어 있으므로, 게이트웨이를 자사 클라우드 안에 두고 다른 곳에서 도는 에이전트나, 당신이 고른 관리형 데이터베이스로 향하게 할 수 있습니다. 셋을 같은 자리에 두라고 강제하는 것은 없습니다.

에이전트를 다시 쓰지 않고 표준을 채택하기

여기서 가장 가치 있는 성질은 에이전트가 결코 바뀌지 않는다는 점입니다. 표준을 말하는 일은 번역기가 대신 모두 처리합니다.

여기에는 두 가지 직접적인 비즈니스 결과가 따릅니다.

이미 들인 투자를 지킵니다. 견적 에이전트를 만든 팀은 새 프로토콜을 위해 다시 만드느라 멈출 필요가 없습니다. 브리지를 더하고 계속 나아가면 됩니다.
양방향으로 종속을 피합니다. 호출자는 오직 개방형 표준에만 의존하며, 당신의 에이전트 공급업체에 의존하지 않습니다. 나중에 에이전트를 교체해도——더 나은 모델, 더 저렴한 공급자, 자체 구축——번역기만 바꾸면 그 위에 쌓인 모든 통합은 손대지 않아도 계속 작동합니다. 반대로, 하나의 게이트웨이가 동시에 여러 서로 다른 에이전트의 앞단이 될 수 있습니다. 추론이 많은 작업은 하나로, 일상적 워크플로 단계는 다른 하나로 보내도, 호출자에게는 동일하게 보입니다. 엔진 선택은 당신이 통제하는 구현 세부가 되며, 당신을 묶어 두는 약속이 아닙니다.

다수의 고객이나 사업부를, 감사를 견디는 데이터 분리와 함께 서비스하기

동일한 배포가 단일 실행 시스템에서 다수의 테넌트——서로 다른 고객, 또는 서로 다른 내부 사업부——에 서비스할 수 있습니다. 각자가 자신의 에이전트, 자신의 작업 이력, 자신의 메시지 저장소를 갖습니다.

이것을 단지 편리한 것을 넘어 안전하게 만드는 것은 분리가 어디서 강제되는가입니다. 각 요청은 어느 고객에 속하는지 태깅되며, 데이터베이스 자체가 한 고객의 행을 다른 고객에게 반환하기를 거부합니다——애플리케이션 코드 아래, 데이터 계층에서 가해지는 통제입니다. 실제로 이는 소프트웨어의 버그나 빠뜨린 필터가 있어도 고객 간에 데이터가 새어 나갈 수 없음을 뜻합니다. 최후의 보루가 애플리케이션이 아니라 데이터베이스이기 때문입니다. 이것이 보안·컴플라이언스 심사자가 찾는 차이이며, 여러 고객을 공유 인프라에 올려도 그 데이터를 위태롭게 하지 않게 해 줍니다.

사람이 민감한 작업의 통제권을 유지하게 하기

자율성은 중요한 순간에 사람이 개입할 수 있을 때만 수용 가능합니다. 에이전트가 승인이 필요한 단계에 이르면——구매 승인, 견적 승인, 민감 데이터 공개——그저 진행하지 않고, 멈춰서 표준의 "승인 대기" 상태를 제기합니다.

핵심은 그 상태가 이동한다는 점입니다. 몇 단계 앞선 에이전트에서 시작된 요청——아마 완전히 다른 프레임워크 위, 다른 팀 소유——이 동일한 "입력 필요" 신호를 변경 없이 받습니다. 사람이 승인(또는 거부)하면 작업이 재개됩니다. 거버넌스는 하나의 에이전트 경계에서 멈추지 않습니다. 개방형 표준이 승인 게이트를 사슬 전체로 실어 나릅니다. 돈, 계약, 규제 대상 데이터에 닿는 어떤 워크플로에서도, 이 끝에서 끝까지의 통제가 에이전트 위임을 무모함이 아닌 방어 가능한 것으로 만듭니다.

데이터가 있어야 할 곳에서 운영하기

이 배포는 단일하고 자립적인 패키지로, 빠른 시작을 위해 묶어서——에이전트·데이터베이스·게이트웨이를 하나로——돌릴 수도, 프로덕션을 위해 분리할 수도 있습니다. 통제된 정문을 자사 네트워크 안에 두고, 관리형 데이터베이스(백업·암호화·컴플라이언스를 클라우드 사업자가 담당)와 별도 하드웨어에서 도는 에이전트로 향하게 할 수 있습니다.

데이터 상주나 주권 요건이 있는 기업에게 이는 중요합니다. 모든 에이전트 상호작용의 기록을, 통제할 수 없는 제3자 클라우드가 아니라, 당신의 정책이 요구하는 경계 안에 보관할 수 있습니다.

의존하기 전에 검증됨

검증할 수 없는 기능은 부채입니다. 이 배포에는 실제로 실행 중인 시스템을 끝에서 끝까지 구동하는 자동화 테스트 모음이 딸려 옵니다——에이전트를 발견할 수 있는지, 요청이 완료되는지, 실시간 진행이 올바르게 스트리밍되는지, 실시간 갱신을 놓친 클라이언트도 전체 결과를 되찾을 수 있는지, 실패와 취소가 예상대로 동작하는지 확인합니다. 테스트는 각 점검마다 명확한 합격/불합격을 보고하며, 자동화 게이트로 실행되도록 설계되어, 결함 있는 변경이 프로덕션에 이르기 전에——이후가 아니라——잡힙니다.

실질적 가치는 위험 감소입니다. 통합이 작동한다는 누군가의 말을 믿을 필요가 없습니다. 변경할 때마다 반복 가능하게 입증됩니다.

프로덕션에서 운영하는 데 실제로 필요한 것

운영 비용에 정직한 것도 사업적 논거의 일부입니다. 계획해 둘 만한 몇 가지 현실이 있습니다.

가볍게 돌리다가 의도적으로 확장하도록 설계되었습니다. 기본은 단일하고 단순한 배포입니다. 여러 복제본으로 매우 높은 트래픽을 감당하는 것은 지원되지만, 우연이 아니라 의도된 단계이며, 복제본들이 일관성을 유지하도록 공유 인프라가 필요합니다. 확장을 계획하십시오. 공짜라고 가정하지 마십시오.
최신 상태 유지는 재작성이 아니라 정례 작업입니다. 구성 요소는 오픈소스 출처에서 가져오므로, 최신화는 팀이 일정에 따라 수행하는 표준 갱신 작업입니다.
보안 태세는 당신이 설정합니다. 패키지에는 자리표시 비밀번호와 관대한 기본값이 딸려 있어 상자에서 꺼내 쉽게 시작할 수 있습니다——인터넷에 노출되기 전에 교체하도록 의도된 것입니다. 선택적으로 딸려 오는 에이전트는 강력하므로 신뢰하는 인프라에서만 돌려야 합니다. 어느 것도 특별하지 않으며, 어떤 프로덕션 시스템에나 필요한 통상적 강화이고, 오픈 체크리스트에 올려야 합니다.

어느 것도 장애물이 아닙니다. 실제 시스템을 운영하는 통상적 책무이며, 미리 짚어 두는 것이 출시 후의 뜻밖을 피하는 방법입니다.

이것이 가능하게 하는 것

종합하면, 브리지 패턴은 스스로 조립하기가 정말 어려운 세 가지를 제공합니다.

1. 재작성 없는 표준 기반 협업. A2A를 말하는 어떤 에이전트든 기존 에이전트와 즉시 협업할 수 있습니다——그것을 발견하고, 위임하고, 진행을 추적하며——그 에이전트를 수정하지 않고요. 이미 작동하는 것을 지키면서 개방형 표준을 채택합니다.

2. 진정한 격리를 갖춘 멀티테넌트 서비스. 단일 배포가 다수의 고객이나 사업부에 서비스하며, 데이터 분리는 데이터베이스 계층에서 강제됩니다. 그래서 보안을 약화시키지 않고 공유 인프라로 통합할 수 있습니다.

3. 경계를 넘는 통제된 자율성. 사람의 승인 게이트가 작업과 함께 이동하므로, 요청이 몇 개의 에이전트——또는 몇 개의 프레임워크——를 거쳤든 민감한 작업에는 사람이 관여합니다.

구현은 오픈소스이며 충분히 문서화되어 있습니다. 브리지와 그 통합 가이드는 a2a_daemon_engine 저장소(Hermes 통합 가이드 참조)에 있고, 통제된 정문은 SilvaEngine Gateway 저장소에 문서화되어 있습니다. 완전한 배포는 docker-a2a-hermes-agent-gateway에 패키징되어 있습니다.