오늘날의 AI 에이전트는 좁은 범위의 작업은 해결할 수 있지만, 맞춤형 연결(glue) 코드 없이는 서로에게 작업을 전달할 수 없습니다. 모든 작업 인계(hand-off)는 일회성 패치입니다.
이 문제를 해결하기 위해 구글은 최근 Agent2Agent (A2A) 프로토콜을 출시했습니다. 이는 하나의 에이전트가 다른 에이전트의 결과를 검색, 인증하며 스트리밍할 수 있게 해주는 소규모 개방형 표준 프로토콜입니다. 공유된 프롬프트 컨텍스트도 없고 맞춤형 REST 엔드포인트도 없으며 인증을 10번째 다시 구현할 필요도 없습니다.
이 스펙은 이제 막 출시되었고 많은 변화가 있을 수 있지만, 덜 취약하고 더 조합 가능한 에이전트 워크플로우를 향한 구체적인 단계입니다.
에이전트에게 네트워크 수준의 표준이 왜 필요한지, A2A가 어떤 방식으로 이를 해결하는지, 그리고 A2A를 안전하게 운영하기 위한 보호 장치는 어떤 것들이 있는지 궁금하시다면 계속 읽어보세요.
현대 앱들은 이미 다양한 "부조종사(copilot)"들을 다루고 있습니다. 한 명은 지라 티켓을 작성하고, 다른 한 명은 젠데스크를 분류하며, 또 다른 한 명은 마케팅 카피를 조정합니다.
하지만 각 AI 에이전트는 자체 프레임워크 안에 있으며, 이들에게 협력을 요청하는 순간 JSON을 복사하여 붙여넣거나 단기간의 REST 브리지를 연결해야 하는 상황으로 돌아가게 됩니다. (솔직히 말해서, 에이전트 간에 프롬프트를 복사,붙여넣기하는 것은 draft-final-final_v2
압축 파일을 자신에게 이메일로 보내는 것의 현대 버전입니다.)
모델 컨텍스트 프로토콜(MCP)은 이러한 골칫거리의 일부만 해결해 주었습니다. MCP는 단일 에이전트가 도구 스키마를 노출하여 LLM이 함수를 안전하게 호출할 수 있게 해줍니다. 문제는 해당 에이전트가 프롬프트 컨텍스트 밖의 동료에게 전체 작업을 전달해야 할 때 시작됩니다. MCP는 검색, 인증, 스트리밍 진행 상황, 파일 전달에 대해서는 침묵을 지키고 있기 때문에 팀들은 맞춤형 마이크로서비스를 구축할 수 밖에 없었습니다.
실제로 힘들었던 부분은 다음과 같습니다.
여기서 Agent2Agent (A2A)가 등장합니다. JSON-RPC 위에 구축된 슬림하고 개방적인 레이어라고 생각하시면 됩니다. 검색을 위한 에이전트 카드, 작업 상태 머신, 그리고 스트리밍된 메시지 또는 아티팩트만 정의하면 모든 클라이언트 에이전트가 프롬프트나 비공개 코드를 살펴보지 않고도 모든 원격 에이전트와 협상할 수 있습니다.
사진을 클릭하면 동영상으로 이동합니다.
(^구글의 발표 게시물에서 가져온 A2A 사용 사례 예시입니다.)
A2A는 MCP를 대체하는 것이 아니라 그 위에 위치하여 실제 도입을 지연시킨 "에이전트 간" 간격을 메웁니다. 에이전트를 사무실의 직원들로 생각해보세요. MCP는 직원 핸드북, 팩스, 서류 캐비닛을 제공하고, A2A는 휴게실에서 잡담할 수 있게 해줍니다.
A2A의 목표는 간단합니다. 멀티 에이전트 오케스트레이션이 위험하지 않고 일상적인 것으로 느껴지도록 하면서도 프레임워크와 벤더들이 내부적으로 혁신할 수 있는 여지를 제공하는 것입니다.
전체 A2A 교환을 살펴보기 전에, 두 플레이어를 명확하게 구분하는 것이 도움이 됩니다.
이는 여러분의 스택 내부에 있는 측면으로, Genkit의 함수, LangGraph 노드, 또는 n8n 워크플로우일 수도 있습니다. 이 함수는 원격 에이전트의 카드를 검색하고, 인증 방식을 수락할 수 있는지 여부를 결정한 다음, createTask
와 같은 JSON-RPC 메시지를 전송하여 작업을 생성합니다.
그 순간부터 클라이언트는 상태 이벤트를 수신하고, 원격 요청에 대한 모든 후속 입력을 전달하며, 마지막으로 다운스트림에서 사용할 아티팩트를 수집하는 등 작업의 관리자 역할을 수행합니다.
A2A를 사용하는 전문화된 마이크로서비스라고 생각하시면 됩니다. Cloud Run, Lambda, 또는 bare VPS에서 실행될 수 있습니다. 일단 작업을 받으면 벡터 저장소를 쿼리하거나 모델을 파인튜닝하거나 PDF를 내보내는 등 무거운 작업을 처리합니다.
작업을 실행하는 동안 TaskStatusUpdate
와 TaskArtifactUpdate
이벤트를 스트리밍합니다. 중요한 것은 원격이 연결을 뒤집을 수 없다는 점입니다. 클라이언트로부터 더 많은 입력(status: input-required
)을 요청할 수는 있지만, 호출자가 되지는 않습니다.
잘 작동하는 멘탈 모델은 "앞집 vs 뒷집"입니다. 클라이언트는 프런트에서 새 주문을 받 설명을 전달하며, 원격은 주방에서 요리가 완성될 때까지 묵묵히 일합니다. (단점도 있습니다. 원격이 수플레를 태워도 클라이언트는 여전히 미소를 지으며 디저트를 무료로 제공해야 합니다.)
이러한 차선을 표시하면, 안전한 핸드오프를 위한 데이터 구조와 보안 레일을 확대할 수 있습니다.
A2A를 처음 접한 사람들은 "잠깐, MCP가 이미 에이전트 도구를 다루지 않나요?"라고 묻는 경우가 많습니다. 거의 비슷하지만 완벽하게는 아닙니다.
레이어의 간단한 맵을 보면 그 차이를 명확히 알 수 있습니다.
이렇게 생각해보세요.
규모에 따라 대부분의 실제 시스템은 세 가지를 모두 사용하게 됩니다. LangGraph 흐름은 내부 Python 에이전트(in-progress)를 호출한 다음 A2A를 통해 서드파티 금융 에이전트에게 작업을 넘기고, 그 금융 에이전트는 자체 프롬프트 내부에서 스프레드시트 내보내기 도구를 트리거하기 위해 MCP에 의존할 수 있습니다.
이러한 경계를 명확히 유지하면 모든 MCP 도구에 커스텀 인증을 적용하지 않아도 되고, 파싱하려고 의도하지 않았던 프롬프트 스키마로 A2A에 과부하를 주지 않아 중복된 작업을 방지할 수 있습니다.
레이어가 정리되면 에이전트 카드, 작업 상태 머신, 그리고 메시지와 아티팩트가 스트림을 통해 이동하는 방법 등 와이어 형식 자체를 파헤쳐 볼 수 있습니다.
아마존에서 책을 구매하는 것을 상상할 수 있다면, A2A가 와이어를 통해 이동시키는 네 가지 데이터 형태를 이미 이해하고 있는 것입니다.
비유를 살펴보세요.
createTask
JSON-RPC 요청을 보냅니다. 원격 에이전트가 작업의 주문 번호인 task_id
로 응답합니다.pending
, processing
, input-required
("서명 필요" 순간) 등의 메시지를 스트리밍합니다. 클라이언트는 배송 지침을 업데이트할 때와 마찬가지로 addInput으로 응답할 수 있습니다.completed
로 변경되면, 아티팩트 이벤트는 PDF 보고서, PNG 자산, JSON 데이터, 또는 약속된 모든 페이로드를 전달합니다.failed
또는 canceled
로 표시하고 아티팩트는 배송되지 않습니다(아마존이 이행되지 않은 주문을 환불하는 것과 같습니다).이런 식으로 교환을 구성하면 A2A가 스펙을 최소한으로 유지하는 이유를 알 수 있습니다. 모든 구매자(클라이언트)와 판매자(원격)에게 꼭 필요한 것 (카탈로그, 주문, 추적, 배송)만 정의하면서 "창고 내부"(모델 프롬프트, 도구 스키마)는 MCP 또는 판매자가 선택하는 다른 메커니즘에 맡깁니다.
A2A는 온 와이어 스펙을 가볍게 유지하지만, 프로덕션 시스템은 여전히 세 가지 보호 계층과 및 가시성이 필요합니다.
각 상태나 아티팩트 이벤트는 이미 타임스탬프, task_id
, 선택적 추적 헤더를 포함합니다. A2A 클라이언트를 OpenTelemetry 미들웨어로 감싸면 JSON을 해킹하지 않고도 즉시 엔드투엔드 범위를 얻을 수 있습니다.
이러한 범위를 통합 가시성 스택에 파이프하면 "오후 3시에 어떤 원격 에이전트가 느려졌나요?"라는 질문에 고객이 알아차리기 전에 대답할 수 있어야 합니다.
오늘날 A2A 원격에서의 검색은 DIY입니다.
registry.yaml
.이러한 허브가 성숙해질 때까지 대부분의 회사는 보안 설문지, 소프트웨어 자재 명세서(SBOM), 제한된 네트워크 범위 등 서드파티 에이전트를 SaaS 벤더처럼 취급할 것입니다.
MCP는 모든 도구 스키마를 자연어 프롬프트로 노출하므로 인젝션과 인자 변조가 일상적인 걱정거리입니다.
A2A는 이 모든 것을 원격의 경계 밖에 숨겨두고, 클라이언트는 고수준 작업과 제한된 아티팩트만 볼 수 있습니다. 여전히 원격의 코드를 신뢰해야 하지만, 프롬프트가 노출되지 않으므로 모든 종류의 익스플로잇을 제거할 수 있습니다.
이 모든 것의 요점은 다음과 같습니다. 게시한 내용에 서명하고, 신뢰할 수 있는 내용을 고정하고, 모든 홉을 추적하고, 페이로드 한도를 적정 수준으로 유지하세요. 이러한 가드레일이 마련되어 있으면 A2A는 제대로 작동하는 REST 서비스를 호출하는 것보다 더 위험하지 않으며, 향후 새로운 에이전트를 추가할 때 훨씬 더 유연하게 대처할 수 있습니다.
A2A는 프로토타입과 내부 워크플로우에는 사용할 수 있지만, 소비자 앱과 규제 대상 스택은 레지스트리와 보안 표준이 성숙해질 때까지 추가적인 보호 장치가 필요합니다.
작업이 네트워크 경계를 넘나들고 신뢰, 실시간 진행 상황, 또는 나중에 새로운 전문 에이전트를 교체하는 것을 신경 쓰는 경우, A2A를 사용하세요. 잘 문서화된 API가 이미 요구사항에 적합하거나 전체 스택이 모니터에 테이프로 붙인 Raspberry Pi에 적합할 때는 건너뛰세요.
A2A는 모델에 새로운 마법을 추가하지 않습니다. 대신 기존 에이전트들이 만나고, 작업을 교환하고, 깔끔한 감사 추적을 유지할 수 있도록 신뢰할 수 있는 핸드셰이크를 추가합니다.
레지스트리 생태계는 여전히 수작업 수준이고 대부분의 에이전트가 비공개 데모 단계에 머물러 있지만, 프로토타입 개발이나 내부 업무 자동화에는 충분히 안정적인 기반을 제공합니다.
글루를 더 적게 만들고, 더 흥미로운 작업을 하세요.
🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article을 구독해주세요!