A2A는 AI 에이전트들의 ‘언어’가 될 수 있을까?

구글이 꿈꾸는 ‘에이전트 검색 포털’의 검색 엔진(일 것 같은) A2A의 모든 것

AI 에이전트가 ‘이렇게 해 줬으면 좋겠다’ 할 때 흔히 등장하는 예시로 생각나는 것이 있나요? 예를 들어, “다음 주에 뉴욕 여행을 예약해 줘. 직항 비행기면 좋겠고, 금요일 오후에 출발해서 일요일 저녁에 돌아와. 그리고 좋은 재즈바 근처에 있는 호텔을 찾아줘.” 같은 것이 있겠죠.

클리셰가 되어버린 예시기는 하지만, 그것보다 진짜 문제는 저것이 아직 불가능하다는 겁니다. 여전히 AI 에이전트가 우리의 의도를 완전히 이해하고, 여러 단계에 걸쳐서 계획을 세우고, 계속 들여다보며 도와주지 않아도 여러 도구를 사용하면서, 믿을 만하게 일을 해내는 게 쉽지 않다는 것이겠죠. 각각의 단계 - 작업을 분석하고, 옵션을 검색하고, 옵션들의 장단점을 확인해서 결정하고, 예약하는 것 - 는 개별적으로 볼 때는 쓸만한 경우가 많지만, 이 전체의 과정을 원활하고 부드러우며 안전하게 연결하는 것은 사실 여전히 불안정하고 오류도 발생하기 쉽습니다.

이처럼 현재 대부분의 AI 에이전트는 각자 자신의 생태계나 벤더의 구조에 갇힌 채 사일로(Silo)에서만 작동하도록 만들어져 있습니다. 그래서, 에이전트들이 직접 서로 대화할 수가 없는 파편화된 환경이 만들어지고, 결과적으로 복잡한 여러 시스템 간의 워크플로우에서는 그 쓸모가 상당히 제한되는 거죠.

2025년 4월, 구글에서는 이런 사일로를 깨기 위해서 A2A (Agent2Agent)를 오픈 프로토콜로 공개했습니다.

파트너들은 올스타급입니다. 아틀라시안(Atlassian), 세일즈포스(Salesforce), 랭체인(LangChain)까지 50개 이상의 파트너들이 지원합니다. 독립적으로 작동하는 AI 에이전트들이 애플리케이션 전반에 걸쳐서 원활하게 협업할 수 있게 해 주는 ‘공통의 언어’가 되겠다는 게 목표입니다.

그렇지만, 화려했던 출시와 화려한 파트너에도 불구하고 몇 주가 지난 지금까지도 A2A는 ‘아직은’ 그렇게 큰 관심을 받지 못하고 있는 것 같습니다. A2A의 배경을 고려할 때, 예상했던 것만큼의 열풍을 일으키지는 못하고 있다는 거죠.

미래의 중요한 인프라가 될 수 있는 무언가에 대해서 이렇게 반응이 미적지근한 이유는 뭘까요?

그래서 이번 에피소드에서는 한 번 ‘A2A’에 대해서 깊이 들여다볼까 합니다. A2A가 무엇인지, 왜 필요한지, 어떻게 작동하는지, 사람들이 어떻게 생각하는지, 왜 채택이나 도입이 미적지근한지, 그리고 왜 그런 상황이 곧 변할 수도 있는지를요. A2A의 기술적 기반을 살펴보고, 앤트로픽이 제안한 MCP 같은 프로토콜과 비교도 해 보고, 멀티 에이전트 시스템을 구축할 때 발생할 수 있는 실질적인 난제들을 같이 살펴볼 겁니다. 그 과정에서 구글이 밀어붙이고 있는 ‘에이전트 간의 상호운용성(Agent Interoperability)’이 생각보다 더 큰 의미를 가질 수 있는 이유 - 어쩌면, 검색이 가능한 인터넷 규모의 AI 에이전트 디렉터리를 위한 주춧돌을 놓을 수도 있는 무언가 - 도 한 번 생각해 볼 겁니다.

A2A를 처음 듣는 분들뿐 아니라 이미 A2A를 가지고 실험을 해 봤거나 더 많이 고민해 보고 싶은 분들에게도 유용하게 쓰려고 했습니다. 지금 바로 같이 들어가 보시죠.

왜 A2A는 ‘아직’ 큰 반향을 일으키지 못할까?

지난 4월 초에 있었던 구글의 A2A 발표, 이건 폭발적인 후속 반응을 이끌어 낼 만한 모든 조건을 갖추고 있었다고 할 수 있습니다: 에이전트 간의 협업에 대한 설득력 있는 비전, 강력한 파트너들, 오픈소스 코드, 그리고 앤트로픽 MCP(Model Context Protocol)와의 상호보완적인 관계까지요. 이론적으로는 완벽한 타이밍이었다고 봐요.

AI의 세계는 에이전트 프레임워크로 들썩이고 있지만, 대부분의 1세대 AI 에이전트 스택은 실질적으로는 솔로 플레이어, 즉, 플러그인이나 API 툴 박스를 장비하고 있는 하나의 거대 언어 모델이라고 봐야 하죠. 물론 최근에 ‘AI 에이전트가 도구와 컨텍스트에 접근하는 방법’을 표준화한 MCP가 큰 반향을 얻고 성공 가도를 달리고 있는데, 이건 일종의 ‘AI용 USB-C 포트’라고들 많이 표현합니다. A2A는 여기서 한 발 더 나가서, 여러 개의 자율 에이전트 간 통신을 표준화해서 ‘커스텀’ 방식으로 굳이 통합하지 않아도 에이전트가 하는 작업, 그리고 그 결과를 상호 교환할 수 있게 하는 겁니다.

그렇다면, 왜 A2A는 ‘자고 일어났더니 유명해졌더라’가 안 된 걸까요?

일단은, 하입(Hype)이 진짜 트렌드로 전환되는데 시간이 좀 걸리는 것일 수 있죠. 2024년 말 앤트로픽이 MCP를 발표했을 때도, 처음에는 반응이 미적지근한 편이었습니다. 몇 달 후에야 ‘아, 이것이 게임 체인저로구나’ 하는 주목을 받기 시작했죠. A2A도 어쩌면 비슷한 시기를 지나고 있는 것일지도 모릅니다.

사실 A2A가 만들어주는 가치는 첫눈에 보기에는 다소 추상적이라고 할 수도 있어요. ‘기업용 에이전트의 상호운용성’은 최첨단 SoTA 모델이라든가, 코드를 자동으로 작성해 주는 챗봇 같은 것들처럼 눈에 확 띄거나 화려한 건 아니니까요.

그리고, 대부분의 개발자들이 아직 단일한 에이전트 애플리케이션을 실험하는 단계에 있다고 볼 수 있어서 다중 에이전트가 협업할 때의 어려움을 느낄 새가 없었죠. 그러니까 시장이 아직 본격적으로 열리지 않은 겁니다. 소규모의 프로젝트라면, 하나의 스크립트 안에서 여러 개의 API 호출을 조정하든지, 공식 프로토콜이 없더라도 내부적으로 랭체인 같은 프레임워크를 사용하면 되는 경우도 많고요. A2A 솔루션이 시급하게 필요하다고 느끼려면, 대규모의 복잡한 환경 - 대기업 내부 환경 같은 - 에서 다중의 에이전트를 유연하게 결합해야 하는 정도의 일이어야 할 거예요.

다른 이유를 더 찾아보자면,‘또 다른 표준’에 대한 피로감도 있을 겁니다. 지난 1~2년 간 LLM을 확장하겠다는 수많은 기법이 등장했습니다. 오픈AI의 함수 호출, 다양한 플러그인 시스템, 커스텀 RPC 스킴, 벤더별로 각각 만든 에이전트 API 등이죠. 개발자들은 아마 “정말 또 다른 프로토콜이 필요해?”라는 생각을 할지도 몰라요.

게다가 지금 A2A는 아주 새롭게 나온 따끈따끈한 상태라서 공개된 성공 사례도 거의 없습니다. 즉, ‘에이전트들이 서로 대화하는’ 모습을 놀랍게 보여주며 바이럴을 일으킬 만한 킬러 데모가 없습니다. 그런 계기가 없다면, A2A는 구체적인 기술 스펙에 관심 있는 사람들에게는 꽤 관심을 받겠지만, 대부분의 AI 개발자 커뮤니티에서는 트렌드로 자리 잡지 못한 채 관심 밖에 머물 겁니다.

그래서, A2A는 뭐고 어떻게 작동하나?

그래서 A2A는 무엇일까요? 핵심만 이야기하자면, Agent2Agent(A2A)는 독립적인 AI 에이전트들이 ‘구조적’으로 ‘안전하게’ 서로 대화할 수 있도록 해주는 통신 프로토콜입니다.

조금 더 풀어서 이야기하면, 하나의 에이전트가 다른 에이전트에게 작업 수행을 요청하고 결과를 받아오는 - 필요한 경우에는 서로 대화를 해 가면서요 - HTTP 기반 JSON 메시지의 공통 셋을 정의합니다. 마치 웹 브라우저와 서버가 HTTP/HTML이라는 표준 프로토콜을 공유하면서 통신하듯이, A2A도 에이전트들 간의 상호 운용성(Interoperability)을 지원하는 공개된 표준(아파치 라이선스입니다)으로, 원하는 모든 개발사나 벤더가 자사의 에이전트 프레임워크 또는 개별적으로 구현할 수 있습니다.

A2A의 핵심 요소

A2A를 구성하는 중요한 요소들을 도식화하면 아래와 같습니다.

A2A의 핵심은 에이전트 카드(Agent Card)입니다. 에이전트 카드는 보통 /.well-known/agent.json에 호스팅되는 공개된 매니페스트로, 에이전트의 기능, 엔드포인트 URL 및 인증을 위한 요구사항을 설명해 줍니다. 오픈API 스타일의 프로필, 아니면 크롬 확장 프로그램의 manifest.json 같은 거라고 생각하시면 될 거예요. 클라이언트 에이전트가 다른 에이전트의 카드를 가져와 원하는 작업을 보내기(요청하기) 전에 “이 에이전트는 CRM 티켓을 처리하고 보고서를 생성할 수 있다” 같은 정보를 즉시 확인할 수 있는 겁니다.

A2A 작동과 관련해서는 크게 두 가지의 역할이 있는데요. 클라이언트(요청하는 에이전트)와 서버(수행하는 에이전트)입니다. A2A 프로토콜을 따르는 모든 에이전트는 이 두 가지 역할 사이에서 왔다갔다 유연하게 역할을 전환할 수가 있습니다. 그래서 여러 에이전트들이 P2P 메시나 Hub-and-Spoke 모델 같은 유연한 토폴로지를 구성할 수가 있죠.

‘협업’이 실제로 이루어지는 핵심 단위는 태스크(Task)입니다. 클라이언트가 원격에 있는 에이전트에게 작업을 수행해 달라 요청할 때 tasks/send를 사용해서 태스크를 생성합니다. 각각의 태스크는 고유 ID를 부여받고, Submitted(제출됨), Working(작업 중), Input-Required(입력 필요), Completed(완료) 또는 Failed(실패)를 거치는 ‘라이프 사이클’을 따라 상태가 바뀝니다. 상호작용을 하는 두 개의 에이전트가 함께 태스크의 진행 상황을 추적해 가며 질문을 더 명확하게 조정하거나 작업 결과물의 일부분을 먼저 전달하는 등 더 ‘풍부하고도 유연한’ 다단계 협업을 할 수 있습니다.

다음으로, 위 그림의 ‘Collaboration’ 박스에 있는 메시지와 파트는, 에이전트 간의 대화를 구조화하는 역할을 합니다. ‘메시지’는 사용자의 요청, 상태의 업데이트, 아니면 후속 조치 같은 걸 수도 있는데, 각각의 메시지가 여러 개의 ‘파트’로 구성됩니다. 여기서 파트는 일반적인 텍스트 형태, 구조화된 JSON 데이터, 이미지나 PDF 같은 바이너리 파일일 수도 있습니다. 한편 메시지는 멀티모달 통신을 지원하게끔 설계되어 있죠. 단순한 텍스트뿐 아니라 구조화된 데이터를 포함한 다양한 모달리티의 데이터를 보내서, 훨씬 더 다이나믹한 의견 교환을 할 수 있습니다.

태스크가 완료되면 출력을 보내야 하잖아요? 출력은 아티팩트(Artifact)라는 요소로 패키징을 하는데, 이것 또한 ‘파트’들로 구성됩니다. 이 아티팩트는 다른 에이전트가 추가로 파싱을 하지 않고도 새로운 태스크에서 즉각 재사용할 수 있게끔 되어 있는 영속적이고 구조화된 결과물(PDF 보고서, JSON 데이터셋, 이미지 등)입니다.

또한, A2A 프로토콜은 스트리밍(Streaming)과 알림(Notification)을 지원합니다. 오랜 시간 동안 실행되어야 하는 태스크도 있는데요. 그때, Server-Sent Events(SSE) 방식을 통해 실시간 업데이트를 스트리밍해서 클라이언트 쪽의 에이전트가 ‘태스크가 어떻게 진행되고 있나’를 구독해서 확인할 수 있다는 겁니다. 에이전트가 클라이언트의 웹훅(Webhook)으로 직접 업데이트를 푸쉬할 수도 있어서, 비동기적(Asynchronous) 아키텍처로 깔끔하게 통합할 수도 있습니다.

이렇게 내부를 살펴보면 A2A 자체는 많은 사람에게 익숙한 ‘웹 표준’만으로 구축되어 있습니다. JSON-RPC 2.0 Payload가 있는 간단한 HTTP 요청, 스트리밍을 위한 SSE, OAuth 2.0, 상호 TLS, 서명된 JWT 같은 일반적인 REST API 인증 방법 등이죠. 아주 특별한 전송 계층을 사용한다거나 커스텀 바이너리 인코딩은 없어요. 그만큼 일반적인 환경, 특히 기업에서 채택하기 훨씬 쉽도록 고민을 했구나 싶습니다.

요소 별로 설명한 내용을 이어보면, 일반적인 에이전트들이 A2A 프로토콜을 기반으로 협업을 하면 이런 모습일 거예요.

1. 클라이언트(에이전트 ‘A’)가 어떤 기업의 매출 차트가 필요합니다. 그럼 A는 서버(에이전트 ‘B’)의 에이전트 카드를 가져와서 ‘create_chart’ 기능을 확인합니다.
2. A는 “지난 1분기 지역별 매출 데이터로 Bar Chart를 만들어 줘”라는 태스크를 보냅니다.
3. B는 태스크를 승인하고, 작업을 진행하는 동안 상황 업데이트를 스트리밍합니다.
4. 만약 B가 ‘A가 말하는 지역이 어떤 지역인지’ 등 더 세부적인 정보가 필요하다고 판단하면, ‘Input-Required’ 메시지를 보내고, A가 응답합니다.
5. Bar Chart가 준비되면 B는 최종 아티팩트(이미지 파일)를 리턴하고, A는 이걸 사용하든지 아니면 다른 에이전트에게 전달합니다.

에이전트 B가 할 수 있는 ‘스킬 (Skill)’이 공개적으로 확인할 수 있게 되고, 동일한 구조의 JSON 프로토콜로 호출하게 되어 있어 이 전체 상호작용이 지금까지 많이 쓰인 맞춤 제작해야 하는 API 핸드오프, 커스텀 연결 코드 등을 전부 다 안 써도 되는 것이죠. 이게 바로 A2A 프로토콜이 지향하는바입니다. 바로 ‘에이전트 간의 협업이 REST 엔드포인트 호출처럼 쉽게 되는 세상’을 만드는 거요.

A2A를 사용해 보려면 뭘 어떻게 시작해야 할까?

자, 그럼 실제로 A2A 프로토콜을 사용해 보고 싶다면 어떻게 시작하면 좋을까요?

준비해야 할 것은 아래 2가지입니다.

• Visual Studio Code(VS Code) 같은 코드 에디터
• Terminal(Linux), iTerm(Mac) 또는 VS Code의 Terminal 같은 커맨드 프롬프트

이제 무엇을 해야 할까요?

1. 저장소 복제하기

git clone https://github.com/google/A2A && cd A2A

여기에는 스펙(Spec), 파이썬 SDK, 그리고 실행할 수 있는 데모 에이전트가 있습니다.

2. 두 개의 샘플 에이전트 실행하기

cd samples/python/agents/hello_world
python server.py --port 5001      # “remote” agent
cd ../cli
python main.py --task "say_hi"    # “client” agent

실행을 해 보면, HTTP를 통해서 스펙에 나와 있는대로 정확하게 태스크의 라이프 사이클 메시지가 흐르는 걸 볼 수 있을 겁니다.

3. 에이전트에 정체성 (Identity) 부여하기

만들고 싶은 서비스에 맞게 /.well-known/a2a.json(에이전트 카드)이라는 파일을 만들어야 합니다. 서비스에 대한 한 페이지짜리 이력서 정도로 생각하면 됩니다. 이름, 설명, 인증 방법, 그리고 이 서비스가 실행할 수 있는 태스크를 알려주는 capabilities 배열이 포함됩니다.

4. (있다면) 기존 에이전트 래핑하기

혹시 이미 랭체인, CrewAI 또는 파이썬으로 만든 에이전트가 있다면, 어댑터를 설치하고 이를 A2A 프로토콜로 노출시키세요.

pip install python-a2a
from python_a2a.langchain import to_a2a_server

a2a_server = to_a2a_server(my_langchain_agent)
a2a_server.run(port=5000)
``` :contentReference[oaicite:3]{index=3}  

여기까지 마쳤으면, 그다음 이슈들 - 보안, 레지스트리, Observability 등 - 은 일반적으로 마이크로서비스를 사용할 때와 완전히 동일하게 다루면 됩니다. A2A 기반의 이 ‘마이크로서비스’는 REST 대신 ‘태스크’와 ‘아티팩트’를 매개로 대화한다는 게 다를 뿐이죠.

A2A 이전의 시대: 고립된 에이전트들이 떠도는 ‘파편화’된 세계

A2A 이전의 시대라고 해서 뭐 아주 옛날이야기 같습니다만, 사실 아직도 그 연장선상에 있기는 합니다. 어쨌든, A2A 이전의 시대는 대부분의 AI 워크플로우가 ‘툴 스택(Tool Stack)을 맞춤형으로 조율하는, 하나의 슈퍼 에이전트’라는 느낌으로 구성됩니다. 어쩌면 이것이 MCP가 엄청나게 큰 반향을 일으킨 배경일 수도 있어요. 어쨌든 진짜 제대로 된 ‘에이전트 간’ 협업은 아주 드물다는 거죠.

생각해 보겠습니다. 마이크로소프트, 구글, 오픈AI, 그리고 오픈소스 에이전트를 모두 섞어 쓰는 시나리오가 지금 잘 상상되나요? 다른 에이전트를 찾거나, 작업을 요청하거나, 결과물을 가져와서 참고할 수 있는 공통의 방법이 없기에 모든 커넥션은 맞춤화로 이루어져야 하는 거죠. 이런 구조는 결국 금세 확장성(Scaling) 문제를 가져오게 될 것입니다. (물론, KQML이라든가 FIPA-ACL 같은 아카데미에서 고안한 프로토콜이 90년대에 이 문제를 해결해 보려고는 했습니다만, 현재 LLM 세계로까지 넘어오지는 못했고요)

‘AI 간의 협업’은 A2A면 만사형통일까?

A2A가 어떤 것인지 간단히 이해했다면, 지금 해야 하는 중요한 질문이 있죠: “A2A는 만병통치약일까요?”

물론 답은 “아니다”겠죠. MCP든 뭐든 다른 기술들과 마찬가지입니다. A2A도 여전히 자기 스스로 가진 도전 과제가 있고, 멀티 에이전트 시스템을 구축할 때의 모든 문제를 해결할 수 있는 만병통치약도 아닙니다. 아주 강력한, 도움을 주는 지원군 정도는 되겠죠. 이전에는 불가능했던 표준에 기반한 새로운 워크플로우를 효율적으로 만들 수 있게 해 주는 통합의 계층(Integration Layer) 이니까요. 하지만, 그 자체로 멀티 에이전트의 성공을 의미하는 건 당연히 아닙니다.

명심해야 합니다: A2A는 에이전트를 더 똑똑하게 만들어주지 않습니다. 단지 ‘대화하기 쉬운’ 환경을 만들어주는 것뿐입니다. 두 개의 평범한 에이전트를 연결한다고 갑자기 엄청난 결과가 만들어지지는 않겠죠. 오히려 진전은 없는데 끝없이 서로 태스크를 주고받거나 할 수도 있겠죠. 효과적인 협업은 신중한 설계의 결과입니다. 누가 뭘 처리할지 결정하고, 목표가 모두에게 잘 이해되도록 관리하고, 실패를 할 때 안전하게 잘 처리하는 설계요.

A2A를 채택하면 따라올 단점도 있습니다. 예를 들면, ‘운영의 오버헤드’ 같은 것이죠. 각각의 에이전트가 일종의 서비스(HTTP 엔드포인트 또는 내장 서버가 있는)가 될 테니까, ‘에이전트 메시(Agent Mesh)’를 관리해야 합니다. 워크데이 HR, 세일즈포스 영업, 자체 개발한 파이썬 분석 서비스까지, 모두 발견(Discovery), 인증(Authentication), 모니터링(Monitoring) 등을 관리해야 합니다. 결국, ‘마이크로서비스 아키텍처’의 재현이죠. 그래서 작은 규모의 워크플로우라면 차라리 간단히 스크립트로 작업해서 처리하는 게 쉬울 수도 있습니다. MCP도 마찬가지잖아요? 도구가 수없이 많고 컨텍스트에 따라 작동하도록 해야 할 때 MCP가 큰 가치가 있듯이, 다양한 기능을 가진 많은 에이전트를 유연하게 연결해야 할 필요가 있을 때, 바로 그때 최고의 가치가 있습니다.

게다가 A2A의 스펙이 이제 막 공개한 완전히 새로운 것이기 때문에 앞으로 많은 변화를 겪을 것이고, 호환성의 범위에 대해서 아직 예상하기 힘들다는 점, 그리고 보안의 관점도 주시해야 할 포인트입니다. 또한, A2A를 기반으로 멀티 에이전트 시스템을 구현하는 개발자가 변경 사항, 엣지 케이스의 버그 등을 예상할 수 있어야 하고, A2A 커뮤니티를 적극적으로 모니터링해야 합니다.

나아가 A2A는 더 많은 벤더가 지원할수록 가치가 커집니다. 그런 크리티컬 매스에 도달하지 못한다면, 차라리 네이티브 API를 사용하는 게 나을 수도 있겠죠. 실제 아직 오픈AI 같은 주요 플레이어들은 공개적으로 A2A를 지지하지는 않고 있습니다.

A2A는 토큰 인증과 TLS를 포함하고 있지만, 실제의 정책, 자격 증명이나 감사는 사용자에게 달려 있습니다. 그러니 아마도 나중에는 ‘에이전트 게이트웨이’ 같은 게 필요할 수도 있을 겁니다.

그럼에도 불구하고 이런 것들이 ‘딜 브레이커(Deal Breaker)’라는 말은 아니라는 점을 다시 한번 강조해서 말씀드립니다. A2A뿐 아니라 어떤 새로운 기술이나 인프라든 시장에 등장하면 어떤 발전 과정을 거쳐야 하는지, 어떤 고민을 맞닥뜨리게 되는지를 말하는 것이죠. ‘마이크로서비스’ 아키텍처 역시 성숙해 가는데 몇 년 이상이 걸렸고요.

A2A는 만병통치약이 아닌 ‘프로토콜 접착제’라고 표현하겠습니다. 우리가 적절한 수준으로 파일럿을 여러 개 발전시킨다면, A2A는 멀티 에이전트 시스템의 통신 문제를 상당 부분 해결할 수 있는 좋은 방안으로 진화할 수 있을 겁니다. 그 나머지인 신중한 설계, 사려 깊은 구현과 개발, 그리고 이를 발전시키는 커뮤니티의 구축 등은 우리 모두에게 달린 일이죠.

MCP와 A2A는 경쟁 관계에 있나?

여기에 대해서도 짧게 답변한다면, “아니오”입니다.

물론, 기업에서 데이터나 서비스를 단순 도구나 자원이 아니라 독립적인 에이전트로 모델링하기 시작하면, A2A가 전통적으로 MCP가 제공하던 기능을 흡수하기 시작하며 경쟁이 시작될 거라고 하는 사람들도 있습니다. 다만 개인적으로는 이 시나리오의 가능성은 그리 높지 않다고 생각합니다.

‘도구’나 ‘자원’은 항상 에이전트 시스템에서 별도의 요소로 구별되는 필수 구성 요소로 남을 겁니다. 이들을 통합하기 위한 공간은 MCP와 A2A 두 개의 프로토콜을 수용하고도 남을 만큼 넓습니다. MCP는 LLM과 외부 데이터 소스 또는 도구 간의 상호작용을 표준화하는데 딱 맞는 프로토콜이고, A2A는 안전하고 상태(State)가 유지되는 에이전트 간의 통신을 처리하는 프로토콜입니다. 상호 보완적인 두 프로토콜의 강점, 에이전트 생태계의 거대한 (예상) 규모를 고려하면, MCP와 A2A는 서로 공존하면서 각각 명확하게 다른 역할을 찾아 자리 잡을 거라고 생각합니다.

에이전트의 오케스트레이션 관점, 그리고 AI 스택에서 A2A의 위치

그렇다면 A2A는 새롭게 등장하고 확대되고 있는 AI 인프라 스택에서 어디쯤 위치를 하는 걸까요? 이 질문에 답하려면 기본적인 AI 모델을 사용해 자율형 에이전트를 구성하는 과정에 필요한 여러 스택 요소를 한번 생각해 보면 됩니다.

‘메모리’, ‘추론’, ‘도구 사용’ 같은 에이전트의 구성 요소가 있는데요. A2A는 이런 수많은 에이전트의 핵심 구성 요소를 대체하거나 다루려는 게 아니며, ‘통신’과 ‘조정’ 계층으로서의 역할을 담당합니다.

먼저, 단일한 하나의 에이전트를 생각해 봅시다. 아마 LLM 같은 핵심적인 모델, 행동 로직(프롬프팅이나 계획 요소), 외부 세계와 상호작용할 메커니즘(도구, API) 같은 것들로 구성될 겁니다. 랭체인, Semantic Kernel, 구글의 ADK(Agent Development Kit) 같은 프레임워크의 도움을 받을 수 있겠고요. MCP는 이 중에 ‘에이전트와 외부 도구를 연결하는 방식’을 표준화해 줍니다.

A2A는 이보다 ‘한 단계 위’에 있습니다. 에이전트 대 에이전트(Agent-to-Agent)의 관계를 처리하죠. MCP, 그리고 도구 API의 역할이 ‘에이전트가 세상과 상호작용할 수 있게’ 해 주는 거라면, A2A는 ‘에이전트들이 서로에게 이야기를 걸고 서로 영향을 끼칠 수 있게’ 해 줍니다. 그런 의미에서 본다면 경쟁자보다는 보완적인 관계로 보는 게 더 좋다고 생각해요.

실제로도 이 두 개의 프로토콜이 상승 작용을 일으키는 경우를 생각해 볼 수 있죠. 예를 들어, ‘인보이스 처리 에이전트’가 있다면, 이 에이전트는 인보이스의 특정한 필드를 추출하는 서비스를 A2A 프로토콜을 통해서 외부에 제공하되, 내부적으로는 OCR 도구를 MCP 프로토콜을 통해서 사용하는 구조로 만들 수 있겠죠. 즉, A2A는 멀티 에이전트의 워크플로우를 조율하면서, 내부적인 도구의 관리는 각각 에이전트에 맡기는 형태입니다.

‘스택’의 관점에서 본다면 아래 구분으로 나눌 수 있습니다.

• LLM과 추론(Reasoning): 에이전트의 핵심인 ‘지능’과 ‘의사결정 논리’를 담당하는 영역
• 도구/컨텍스트 인터페이스(MCP, Plugins): 에이전트가 외부 도구와 데이터를 사용할 수 있게 해 주는 레이어
• 에이전트 프레임워크/런타임: 에이전트 루프, 메모리, 작업 분할 등을 관리하는 레이어
• 에이전트 간 프로토콜(A2A): 여러 에이전트들이 운용되는 시스템 간에 상호 조정, 작업 위임 등을 할 수 있게 하는 레이어
• (Optional) 오케스트레이터/매니저: 다른 에이전트를 언제 호출할지 결정하는 감독 로직을 담당하는 레이어

주목해야 할 것은 A2A가 랭체인, Semantic Kernel 등 다른 프레임워크를 대체하려는 게 아닌, 이들 사이에서 ‘상호 운용’을 할 수 있는 ‘통로’를 제공한다는 점입니다. A2A 깃헙 저장소에는 이미 랭체인, LlamaIndex, Marvin, Semantic Kernel 등 여러 프레임워크를 위한 어댑터들이 있습니다. 즉, 랭체인 에이전트와 Semantic Kernel 에이전트도 특별히 연결을 위한 코딩을 하지 않고도 협업을 할 수 있다는 거죠.

돌이켜 보면 이런 패턴은 익숙합니다. 초기에 웹 개발을 할 때도, REST 같은 프로토콜이 표준화되기 전에 앱들이 서로 대화할 수 있었나요? 그렇지 않았죠. 이제 A2A가 AI 에이전트의 시대를 맞아서 같은 일을 하려고 하는 겁니다.

A2A의 이런 시도가 만약에 성공한다면, A2A는 ‘멀티 에이전트 워크플로우를 위한 최초의 Lingua-franca’가 될 겁니다. 엄청난 하이라이트를 받지는 않는다 하더라도, AI 에이전트의 세상을 앞당기게 될, 중요한 드라이버로의 역할이예요.

*Lingua-franca: 서로 다른 언어를 사용하는 화자들이 의사소통을 하기 위해 국제어, 공통어로 사용하는 제 3 언어. 국가나 단체에서 공식적으로 정한 언어를 뜻하는 공용어와는 다른 개념.

A2A가 열어가는 새로운 가능성

말한 대로 A2A는 아직 대중적으로 널리 알려지고 있는 상태는 아닙니다. 자연스럽게 A2A로 만들 수 있는 워크플로, 그리고 협업의 규모 역시 아무래도 가늠이 어렵고 과소평가되기 쉽습니다.

그래서 몇 가지 예시를 한 번 살펴볼게요.

전문가 에이전트들의 팀 작업

모든 일을 단독으로 처리하는 하나의 거대한 에이전트를 만드는 대신 A2A는 전문화된 개별 에이전트로 이루어진 팀이 다이나믹하게 협업할 수 있는 구조를 제공합니다. 예를 들어, 고객 지원에서는 기술 문제를 해결하는 에이전트, 금융 자문 에이전트, 캠페인 에이전트가 하나의 세션에서 원활하게 협업할 수 있습니다. 사실 사람을 써서도 하기 힘든 일이죠. 고객은 단 하나의 인터페이스와 상호작용을 하지만, 에이전트들은 백그라운드에서 협업합니다.

기업 간의 워크플로우 연계, 통합

각각의 기업들은 수많은 플랫폼을 운영하거나 사용합니다. CRM을 위한 세일즈포스, IT를 위한 서비스나우, HR을 위한 워크데이 등은 그냥 출발점일 뿐이죠. A2A를 사용하면 HR 에이전트가 IT 티켓을 매뉴얼하게 처리하게 하거나, 오류 발생이 쉬운 API 연결을 하지 않고도 노트북을 달라거나, 장비 문제를 해결해 달라는 요청을 IT 부서에 보내고 처리할 수 있습니다. 각각의 에이전트가 본래의 기능에만 집중하면서도 프로토콜을 통해서 더 대규모의 기업 간 워크플로우의 일부로 작동할 수 있습니다.

다이나믹한 에이전트 교체, 업그레이드

A2A 프로토콜은 에이전트 간 통신을 위한 기능들을 표준화하기 때문에, 자연스럽게 모듈화의 길을 열게 됩니다. 호출하는 방식은 그대로 두고도 오픈소스로 구한 파이낸셜 에이전트를 상업용으로 구매한 에이전트로 교체할 수 있죠. 시간이 지나고 A2A가 광범위하게 적용된다면, ‘상호 운용 가능한 에이전트’들이 올라와 있는 마켓 플레이스가 생길 수도 있을 겁니다: 법률 분석 에이전트, 번역 에이전트, 시장 분석 에이전트 등 모두가 A2A로 소통하게 될지도 모르겠네요.

HITL(Human-in-the-Loop) 감독

곰곰dl 생각해 보세요. 모든 에이전트가 AI일 필요는 없잖아요? 사람도 A2A 클라이언트를 통해 이 협업 구조에 참여할 수 있습니다. AI가 제안한 작업을 승인하거나 수정하고 에이전트 간의 민감한 상호작용을 모니터링한다든가 하는 작업들로부터 시작하겠죠. 이런 ‘공식화된 인계, 감독’ 작업은 표준화된 아티팩트와 작업 상태를 제공하는 A2A 프로토콜을 사용한다면 더 효율화할 수 있을 겁니다.

조직의 경계를 허물고 ‘연합하는’ 에이전트

여기서 좀 더 나간다면, A2A를 통해 서로 다른 기업의 에이전트들이 안전하게 협업하고, 조직의 경계를 넘어 함께 작업하며, 그 결과를 교환할 수 있게 됩니다. 재고를 협상하는 공급망 에이전트, 기업 간의 R&D 팀 등이 신뢰의 계층과 계약 구조, 그걸 반영하는 A2A 구조를 바탕으로 협업할 수가 있습니다.

위에 이야기한 것들 대부분은 지금까지는 사실상 불가능하든지 아니면 엄청난 비용이 드는 것들입니다. 어떻게 보면 아이러니하게도 AI의 세계가, 아니 AI 세계를 바라보는 ‘우리’가 더 큰 모델, 더 멋진 그림과 영상을 만들어줄 화려한 프롬프트를 찾아 헤매는 동안, 구글(을 포함한 수많은 개발 커뮤니티)은 A2A 같은 기본적인 발판을 놓았습니다. 그렇게 우리 미래가 질적으로 새로운 곳을 향해 움직일 수 있게 해 주고 있는 것이죠. 그리고 우리는, 이 가능성을 이제 막 보기 시작했을 뿐입니다.

마치며: A2A는 ‘구글의 에이전트 검색 엔진’으로 클 수 있을까?

기술적으로 안 될 이유는 없습니다.

A2A 프로토콜 규격에 호환되도록 하려면, 에이전트들은 /.well-known/agent.json에서 머신이 읽을 수 있는 에이전트 카드를 게시해야 하죠. 생각해 보면 이는 크롤러가 접근해서 읽을 수 있는 완벽한 액세스 포인트예요. URL을 따라가, 카드를 가져와서, 메타데이터를 Bigtable에 넣기만 하면 끝입니다. 정확히 구글이 robots.txt + sitemap.xml을 웹 인덱스로 전환했을 때 사용한 패턴이죠. 지금으로서는 이 발견(Discovery) 단계가 P2P 방식으로 대부분 진행될 뿐, 앞으로 에이전트용 구글 봇 같은 게 생겨 인터넷 스케일로 크롤링을 한다고 해도 막을 방법이 없어요.

구글 클라우드 내부에서 감지되는 신호들을 보면 이 방향으로의 고민도 분명히 하고 있는 것으로 보입니다. 에이전트스페이스(Agentspace)의 Agent Gallery는 기업 고객용으로 제한되어 있지만 ‘검색할 수 있는 카탈로그’에요. 구글이 직접 만든 파트너 및 사내용 에이전트를 보여주고, 배포는 클라우드 마켓플레이스를 활용합니다. 에이전트를 위한 미니어처 앱 스토어의 원형이죠. 공개된 크롤러만 ‘아직’ 없을 뿐이고요.

이제 구글의 A2A는 ‘통신을 위한 파이프’를 깔아놓은 셈입니다. 구글이 이 파이프를 전 세계를 연결하는 ‘교환기’로 확장할지, 이는 아직 좀 더 두고 봐야겠죠. 아직 A2A는 초기 단계에 있습니다.

개인적으로, 이전에 컨테이너, 쿠버네티스, REST API에 대한 소식을 처음 들었을 때 생각이 납니다. 어떤 생태계가 탄생해서 들끓기 시작하면 ‘조용한 폭발’이 여러 차례 일어나기 마련이죠. 만약, 구글에서 공개 에이전트 인덱스 같은 걸 내놓기 시작한다면, 이건 어쩌면 미래의 자율형 에이전트, 자율형 소프트웨어를 대상으로 한 DNS 같은 걸로 발전할지도 모르고요. 다만 이는 아주 강력하기도 하고 수익성도 있으면서, 동시에 정치적으로도 엄청난 파장과 반응을 몰고 올 겁니다.

그런 미래의 단초가 또 보일 때까지, A2A를 가지고 실험도 해 보고 이와 경쟁할 만한 다른 프로토콜이 뭐가 있는지 살펴보며 빠르게 움직여야 합니다. ‘인프라의 승리’는 기술적 탁월함보다는 신뢰, 인센티브, 그리고 수천 개의, 그렇지만 ‘조용하게 일어나는’ 연결과 통합의 스토리에 달려 있습니다. 그 이야기들이 우리가 지켜봐야 할 변화입니다.

보너스: 참고 자료

• Announcing the Agent2Agent Protocol (Google Blog)
• Official A2A Specification (GitHub)
• A2A Protocol Documentation (docs)​
• A2A Python Quickstart Tutorial
• Python A2A (GitHub)
• Awesome A2A (GitHub)
• LlamaIndex File Chat Workflow with A2A Protocol (GitHub)
• A2A Directory with community implementations (GitHub)
• Building the industry’s best agentic AI ecosystem with partners (Google Blog)
• Aravind Putrevu’s Agent2Agent Protocol Explained (blog)
• Building A Secure Agentic AI Application Leveraging Google’s A2A Protocol (research paper)
• A Survey of AI Agent Protocols (research paper)

<원문>

구글이 발표한 A2A는 뭔가? 왜 아직 큰 화제가 되지 않고 있을까?

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.