A2A 생태계 상호운용: 서로 다른 프레임워크의 AI도 서로 전화할 수 있다

모든 브랜드의 휴대폰이 자기 브랜드끼리만 통화할 수 있다면, 전화는 이미 사라졌을 것이다. AI 에이전트도 같은 위기에 직면해 있다—A2A 프로토콜이 등장하기 전까지는.

문제: 프레임워크마다 AI가 제각각 말하는 ‘방언’ 상황

상상해보자. 집에는 Hermes 에이전트가 있고, 회사에서는 LangChain으로 만든 워크플로 봇을 쓰고 있고, 친구가 추천해준 CrewAI 기반 미니 어시스턴트도 있다. 셋 다 유능하지만, 문제는—서로 말이 통하지 않는다는 거다.

이건 마치 중국에 일곱 가지 방언 권역이 있어서, 각 지역 사람들은 자기 마을 사람들이랑은 활발하게 대화하지만 마을만 넘어가면 멘붕이 오는 것과 같다. 지금의 AI 프레임워크도 마찬가지다: Hermes는 Hermes식으로 말하고, LangChain은 LangChain 인터페이스를 쓰고, CrewAI는 CrewAI 규칙을 따른다. Hermes가 LangChain한테 작업을 넘기고 싶다고? 미안하지만, 직접 복사해서 붙여넣거나, 끈적한 글루 코드를 잔뜩 짜야 한다.

이게 바로 소위 ’에이전트 고립(Agent Island)’이다. 각각의 AI는 똑똑하지만, 합치면 바보가 된다.

A2A가 왜 뚫을 수 있나: 명함 한 장 + 표준어 하나

A2A(Agent-to-Agent) 프로토콜이 해결하려는 건 바로 이 ‘마을 간 통신’ 문제다. Google이 주도하고 Linux 재단이 관리하는 개방형 프로토콜로, 코드는 오픈소스(Apache 2.0)이며 어느 한 회사의 소유가 아니다. 이게 무슨 뜻일까? 특정 업체의 ’사유물’이 아니라, 다 같이 모여서 합의한 ’표준어’라는 뜻이다.

A2A의 핵심 설계는 아주 현실적이다. 딱 두 가지다:

첫째, Agent Card(에이전트 명함). 모든 에이전트는 고정된 위치(.well-known/agent-card.json)에 ’명함’을 하나 놓아야 한다. 거기에는 내 이름이 뭐고, 뭘 할 수 있고, 어떤 스킬이 있고, 어떤 권한이 필요한지가 적혀 있다. 다른 쪽은 명함만 보면 이 에이전트한테 부탁할 수 있는지, 어떻게 부탁해야 하는지 알 수 있다. 상대 회사 직원 명함 받아서 직함만 봐도 그 사람한테 얘기할지 말지 정하는 것과 똑같다.

둘째, JSON-RPC 2.0 표준 통화. 모든 에이전트는 하나의 통일된 ’전화 회선’으로 통신한다—메시지 보내기, 받기, 작업 취소, 진행 상황 확인까지 전부 표준 동작이다. 게다가 SSE 스트리밍 전송을 지원해서, 마치 전화 통화처럼 상대가 한 마디 하면 한 마디 듣는 식이라 긴 문장이 끝날 때까지 기다릴 필요가 없다. 긴 작업은 webhook으로 알림을 보내서, 끝나면 알려주니 계속 지켜볼 필요도 없다.

이 설계 덕분에 A2A는 또 다른 인기 프로토콜인 MCP와 완벽한 보완 관계를 이룬다: MCP는 ’내가 어떤 도구를 쓸 수 있는지’를 답하고, A2A는 ’누가 나 대신 일을 해줄 수 있는지’를 답한다. 하나는 도구를 관리하고, 하나는 협업을 관리한다.

생태계 전체: 누구랑 연동할 수 있나?

공식 문서에 아주 명확하게 나와 있다: Hermes의 A2A 플러그인은 어떤 A2A 호환 피어와도 상호운용이 가능하다. 즉:

다른 Hermes(당연히 가능)
LangChain 에이전트(가능)
CrewAI 에이전트(가능)
Google ADK 에이전트(가능)
공식 a2a-sdk로 만든 모든 것(전부 가능)

그리고 이 상호운용은 구두선이 아니다—이미 공식 Python a2a-sdk로 실측 검증을 마쳤다: 명함 파싱, 메시지 전송, 스트리밍 대화까지 전부 동작한다.

실제 사례: 이미 일어나고 있는 크로스 프레임워크 협업

사례 1: Hermes + OpenClaw 같은 머신 통신 (GitHub issue #42747)

한 사용자가 같은 Mac에서 Hermes와 OpenClaw를 동시에 돌리고 있었다. 두 에이전트 모두 Telegram에 연결되어 있었는데, Telegram에는 짜증 나는 제한이 있다: 그룹에서 봇끼리는 서로의 메시지를 볼 수 없다. 그래서 이 두 AI는 같은 집에 살면서도 사용자가 직접 메시지를 전달해줘야만 했다.

이게 바로 A2A의 전형적인 시나리오다: Hermes가 OpenClaw의 스킬에 직접 작업을 위임하고, 그 반대도 마찬가지로, Telegram과 사람 중계를 완전히 우회하는 것이다. 에이전트끼리 직접 전화하지, 교환대를 거치지 않는다.

사례 2: Gotong 통합 제안 (#58325)

Gotong은 자체 호스팅 워크플로우 조정 플랫폼으로, 에이전트한테 ’프로젝트 매니저’를 붙여주는 셈이다. 제안의 핵심은: Hermes는 개인 기억, 추론, 의사결정을 담당하고, Gotong은 거버넌스가 적용된 협업 기반—작업 스케줄링, 인간 승인, 전체 작업 기록—을 담당한다. 둘은 A2A 엔드포인트로 연결되어 각자 잘하는 걸 맡는다.

사례 3: 제로 침습 엔터프라이즈 협업 (#67951)

누군가 더 가벼운 전환 방안을 제시했다: Hermes의 Skill 메커니즘만으로 협업 패키지를 만들고, 에이전트가 터미널 도구로 셸 스크립트를 호출하고, 스크립트는 HTTP로 중앙 Hub와 통신하는 방식이다. 코드 수정 제로로 멀티 에이전트 협업이 가능하다. A2A가 정식으로 자리 잡기 전의 ’임시 다리’인 셈이다.

사용자에게 의미하는 바

A2A 생태계 상호운용이 가져오는 변화는 일반 사용자 입장에서 아주 직관적이다:

더 이상 편 가를 필요가 없다. 오늘은 Hermes 쓰고, 내일은 CrewAI 써볼까? 문제없다. 둘 사이에 통신이 되니까, 데이터와 작업, 컨텍스트가 끊김 없이 흘러간다.

내 에이전트는 더 이상 외로운 히어로가 아니다. 에이전트 하나로 안 되는 일은, 스스로 ‘사람을 부를’ 수 있다—A2A로 관련 스킬을 가진 다른 에이전트를 발견해서 작업을 위임한다. 회사에서 모르는 게 있으면 직접 아는 동료한테 물어보지, 매번 사장님을 거쳐서 전달받지 않는 것과 같다.

생태계가 점점 더 커진다. 프로토콜이 개방적이고 중립적이기 때문에, 어떤 프레임워크든 접속할 수 있다. 오늘은 LangChain에 연결되고, 내일은 회사 내부에서 자체 개발한 에이전트에도 연결될 수 있다—A2A 표준만 따르면 된다.

한마디로 정리하면: A2A는 AI 에이전트를 ’방언 섬’에서 ’표준어 커뮤니티’로 바꿔준다. 당신의 AI는 더 이상 고립된 섬이 아니라, 언제든 도움을 찾고 다른 이에게 발견될 수 있는 거대한 협업 네트워크의 한 노드다.