[번역] Agent2Agent (A2A) 프로토콜은 무엇인가요?

Sonny·2025년 7월 6일
3

Article

목록 보기
36/36
post-thumbnail

원문: https://www.builder.io/blog/a2a-protocol

오늘날의 AI 에이전트는 좁은 범위의 작업은 해결할 수 있지만, 맞춤형 연결(glue) 코드 없이는 서로에게 작업을 전달할 수 없습니다. 모든 작업 인계(hand-off)는 일회성 패치입니다.

이 문제를 해결하기 위해 구글은 최근 Agent2Agent (A2A) 프로토콜을 출시했습니다. 이는 하나의 에이전트가 다른 에이전트의 결과를 검색, 인증하며 스트리밍할 수 있게 해주는 소규모 개방형 표준 프로토콜입니다. 공유된 프롬프트 컨텍스트도 없고 맞춤형 REST 엔드포인트도 없으며 인증을 10번째 다시 구현할 필요도 없습니다.

이 스펙은 이제 막 출시되었고 많은 변화가 있을 수 있지만, 덜 취약하고 더 조합 가능한 에이전트 워크플로우를 향한 구체적인 단계입니다.

에이전트에게 네트워크 수준의 표준이 왜 필요한지, A2A가 어떤 방식으로 이를 해결하는지, 그리고 A2A를 안전하게 운영하기 위한 보호 장치는 어떤 것들이 있는지 궁금하시다면 계속 읽어보세요.

Agent2Agent 프로토콜이 필요한 이유

현대 앱들은 이미 다양한 "부조종사(copilot)"들을 다루고 있습니다. 한 명은 지라 티켓을 작성하고, 다른 한 명은 젠데스크를 분류하며, 또 다른 한 명은 마케팅 카피를 조정합니다.

하지만 각 AI 에이전트는 자체 프레임워크 안에 있으며, 이들에게 협력을 요청하는 순간 JSON을 복사하여 붙여넣거나 단기간의 REST 브리지를 연결해야 하는 상황으로 돌아가게 됩니다. (솔직히 말해서, 에이전트 간에 프롬프트를 복사,붙여넣기하는 것은 draft-final-final_v2 압축 파일을 자신에게 이메일로 보내는 것의 현대 버전입니다.)

모델 컨텍스트 프로토콜(MCP)은 이러한 골칫거리의 일부만 해결해 주었습니다. MCP는 단일 에이전트가 도구 스키마를 노출하여 LLM이 함수를 안전하게 호출할 수 있게 해줍니다. 문제는 해당 에이전트가 프롬프트 컨텍스트 밖의 동료에게 전체 작업을 전달해야 할 때 시작됩니다. MCP는 검색, 인증, 스트리밍 진행 상황, 파일 전달에 대해서는 침묵을 지키고 있기 때문에 팀들은 맞춤형 마이크로서비스를 구축할 수 밖에 없었습니다.

실제로 힘들었던 부분은 다음과 같습니다.

  • 불안정한 핸드오프: DIY "handover" JSON의 추가 필드가 하나만 있어도 체인을 깨뜨릴 수 있습니다.
  • 보안 교착상태: 모든 인하우스 에이전트는 자체 인증 체계를 제공하며, 보안팀은 알 수 없는 엔드포인트 승인을 거부합니다.
  • 벤더 락인: 일부 SaaS 제공업체는 독점 SDK를 통해서만 에이전트를 노출하여 사용자를 특정 클라우드나 프레임워크에 종속시킵니다.

여기서 Agent2Agent (A2A)가 등장합니다. JSON-RPC 위에 구축된 슬림하고 개방적인 레이어라고 생각하시면 됩니다. 검색을 위한 에이전트 카드, 작업 상태 머신, 그리고 스트리밍된 메시지 또는 아티팩트정의하면 모든 클라이언트 에이전트가 프롬프트나 비공개 코드를 살펴보지 않고도 모든 원격 에이전트와 협상할 수 있습니다.


사진을 클릭하면 동영상으로 이동합니다.

(^구글의 발표 게시물에서 가져온 A2A 사용 사례 예시입니다.)

A2A는 MCP를 대체하는 것이 아니라 그 위에 위치하여 실제 도입을 지연시킨 "에이전트 간" 간격을 메웁니다. 에이전트를 사무실의 직원들로 생각해보세요. MCP는 직원 핸드북, 팩스, 서류 캐비닛을 제공하고, A2A는 휴게실에서 잡담할 수 있게 해줍니다.

A2A의 목표는 간단합니다. 멀티 에이전트 오케스트레이션이 위험하지 않고 일상적인 것으로 느껴지도록 하면서도 프레임워크와 벤더들이 내부적으로 혁신할 수 있는 여지를 제공하는 것입니다.

Roles 101: 클라이언트 에이전트 vs. 원격 에이전트

전체 A2A 교환을 살펴보기 전에, 두 플레이어를 명확하게 구분하는 것이 도움이 됩니다.

클라이언트 에이전트

이는 여러분의 스택 내부에 있는 측면으로, Genkit의 함수, LangGraph 노드, 또는 n8n 워크플로우일 수도 있습니다. 이 함수는 원격 에이전트의 카드를 검색하고, 인증 방식을 수락할 수 있는지 여부를 결정한 다음, createTask와 같은 JSON-RPC 메시지를 전송하여 작업을 생성합니다.

순서도

그 순간부터 클라이언트는 상태 이벤트를 수신하고, 원격 요청에 대한 모든 후속 입력을 전달하며, 마지막으로 다운스트림에서 사용할 아티팩트를 수집하는 등 작업의 관리자 역할을 수행합니다.

원격 에이전트

A2A를 사용하는 전문화된 마이크로서비스라고 생각하시면 됩니다. Cloud Run, Lambda, 또는 bare VPS에서 실행될 수 있습니다. 일단 작업을 받으면 벡터 저장소를 쿼리하거나 모델을 파인튜닝하거나 PDF를 내보내는 등 무거운 작업을 처리합니다.

작업을 실행하는 동안 TaskStatusUpdateTaskArtifactUpdate 이벤트를 스트리밍합니다. 중요한 것은 원격이 연결을 뒤집을 수 없다는 점입니다. 클라이언트로부터 더 많은 입력(status: input-required)을 요청할 수는 있지만, 호출자가 되지는 않습니다.

작업 가능한 상태들에 대한 순서도

단방향 통신

  • 클라이언트만 JSON-RPC 요청을 시작합니다.
  • 원격만 작업 상태를 업데이트합니다.
  • 어느 쪽이든 문제가 생기면 스트림을 종료할 수 있지만, 정리(예: 임시 파일 삭제) 책임은 원격에 있습니다.

잘 작동하는 멘탈 모델은 "앞집 vs 뒷집"입니다. 클라이언트는 프런트에서 새 주문을 받 설명을 전달하며, 원격은 주방에서 요리가 완성될 때까지 묵묵히 일합니다. (단점도 있습니다. 원격이 수플레를 태워도 클라이언트는 여전히 미소를 지으며 디저트를 무료로 제공해야 합니다.)

이러한 차선을 표시하면, 안전한 핸드오프를 위한 데이터 구조와 보안 레일을 확대할 수 있습니다.

A2A가 적합한 위치: MCP 위, 오케스트레이터 옆

A2A를 처음 접한 사람들은 "잠깐, MCP가 이미 에이전트 도구를 다루지 않나요?"라고 묻는 경우가 많습니다. 거의 비슷하지만 완벽하게는 아닙니다.

레이어의 간단한 맵을 보면 그 차이를 명확히 알 수 있습니다.

  • 단일 에이전트 내부(프롬프트 수준): 여기서 에이전트는 모델이 도구를 호출할 수 있도록 스키마가 필요합니다. 이것이 바로 MCP 영역입니다. JSON 스키마, 함수 이름, 인자 유효성 검사, 프롬프트 삽입 문제 등이 여기에 해당합니다.
  • 에이전트 간(네트워크 수준): 에이전트가 전체 작업을 동료에게 넘기려는 순간, MCP는 검색, 인증, 또는 스트리밍된 아티팩트에 대해 침묵합니다. 이 침묵을 A2A가 에이전트 카드, 작업, 상태 이벤트로 채우는 것입니다. (에이전트 시스템과 오케스트레이터에 대해 자세히 알아보기.)
  • 프로세스 내부(워크플로우 수준): LangGraph, CrewAI, AutoGen과 같은 프레임워크는 메모리 내에서 단계들을 서로 연결합니다. 이러한 프레임워크는 하나의 시스템에서 소규모 체인을 사용하는 데 적합하지만, 네트워크 경계를 넘거나 언어와 벤더를 혼합해야 하는 순간 샌드박스를 벗어나 A2A로 전환해야 합니다.

컴포넌트 이미지

이렇게 생각해보세요.

  • MCP는 단일 마이크로서비스 내부의 API 계약입니다.
  • A2A는 마이크로서비스 사이의 HTTP 계층입니다.
  • LangGraph 등은 각 마이크로서비스가 호출되는 시점을 결정하는 워크플로우 엔진입니다.

규모에 따라 대부분의 실제 시스템은 세 가지를 모두 사용하게 됩니다. LangGraph 흐름은 내부 Python 에이전트(in-progress)를 호출한 다음 A2A를 통해 서드파티 금융 에이전트에게 작업을 넘기고, 그 금융 에이전트는 자체 프롬프트 내부에서 스프레드시트 내보내기 도구를 트리거하기 위해 MCP에 의존할 수 있습니다.

이러한 경계를 명확히 유지하면 모든 MCP 도구에 커스텀 인증을 적용하지 않아도 되고, 파싱하려고 의도하지 않았던 프롬프트 스키마로 A2A에 과부하를 주지 않아 중복된 작업을 방지할 수 있습니다.

레이어가 정리되면 에이전트 카드, 작업 상태 머신, 그리고 메시지와 아티팩트가 스트림을 통해 이동하는 방법 등 와이어 형식 자체를 파헤쳐 볼 수 있습니다.

A2A 교환의 구조

아마존에서 책을 구매하는 것을 상상할 수 있다면, A2A가 와이어를 통해 이동시키는 네 가지 데이터 형태를 이미 이해하고 있는 것입니다.

비유를 살펴보세요.

table

단계별 체크아웃

  1. 목록 검색하기: 클라이언트가 에이전트 카드를 한 번 가져옵니다. "기능"(capabilities)과 "체크아웃"(auth)이 정상적으로 보이면 계속 진행합니다.
  2. 주문하기: 클라이언트가 "지금 구매" 클릭하는 것과 같이 createTask JSON-RPC 요청을 보냅니다. 원격 에이전트가 작업의 주문 번호인 task_id로 응답합니다.
  3. 추적 이메일 확인하기: 원격에서 서버 전송 이벤트(Server-Sent Events)를 통해 pending, processing, input-required("서명 필요" 순간) 등의 메시지를 스트리밍합니다. 클라이언트는 배송 지침을 업데이트할 때와 마찬가지로 addInput으로 응답할 수 있습니다.
  4. 패키지 받기: 상태가 completed로 변경되면, 아티팩트 이벤트는 PDF 보고서, PNG 자산, JSON 데이터, 또는 약속된 모든 페이로드를 전달합니다.
  5. 루프 닫기: 작업이 실패하거나 취소되면, 원격에서 failed 또는 canceled로 표시하고 아티팩트는 배송되지 않습니다(아마존이 이행되지 않은 주문을 환불하는 것과 같습니다).

이런 식으로 교환을 구성하면 A2A가 스펙을 최소한으로 유지하는 이유를 알 수 있습니다. 모든 구매자(클라이언트)와 판매자(원격)에게 꼭 필요한 것 (카탈로그, 주문, 추적, 배송)만 정의하면서 "창고 내부"(모델 프롬프트, 도구 스키마)는 MCP 또는 판매자가 선택하는 다른 메커니즘에 맡깁니다.

A2A 프로토콜의 안전성, 관찰성, 거버넌스

A2A는 온 와이어 스펙을 가볍게 유지하지만, 프로덕션 시스템은 여전히 세 가지 보호 계층과 및 가시성이 필요합니다.

핸드셰이크 보안

  • 서명된 에이전트 카드: 카드에 JSON 웹 서명(JWS)을 추가하고 서명자의 공개 키를 게시합니다. 클라이언트가 해당 키를 "고정"하고, 누군가 전송 중에 카드를 교체하면 서명 검증에 실패하고 통신이 끊어집니다. "나를 믿어"는 진정한 보안 정책이 아닙니다.
  • 인증 선택: 데모는 보통 간단한 Bearer 토큰에 의존하지만, 상호 TLS(양방향 신원 확인 방식)로 레벨업하거나 회사의 싱글 사인온 플로우에 연결할 수 있습니다.
  • 런타임 정책: 원격 에이전트는 모델이 실행되기 전에 크기가 너무 크거나 위험한 페이로드를 거부할 수 있습니다. 일반적인 가드는 다음과 같습니다. "5MB 미만의 JSON 또는 PNG 파일만 허용." (이는 MCP의 Zod 스키마 검증과 매우 유사합니다.)

에이전트 간(A2A) 보안 아키텍처의 개념도

에이전트가 보는 것 보기

각 상태나 아티팩트 이벤트는 이미 타임스탬프, task_id, 선택적 추적 헤더를 포함합니다. A2A 클라이언트를 OpenTelemetry 미들웨어로 감싸면 JSON을 해킹하지 않고도 즉시 엔드투엔드 범위를 얻을 수 있습니다.

이러한 범위를 통합 가시성 스택에 파이프하면 "오후 3시에 어떤 원격 에이전트가 느려졌나요?"라는 질문에 고객이 알아차리기 전에 대답할 수 있어야 합니다.

신뢰하되, 검증하기

오늘날 A2A 원격에서의 검색은 DIY입니다.

  • 내부 팀을 위한 YAML 파일 내부 팀을 위한 저장소에 체크인된 registry.yaml.
  • Vertex AI 카탈로그: "게시"를 선택하면 구글이 비공개 디렉터리에서 카드를 호스팅합니다.
  • 신흥 공개 허브: LangChain과 Flowise 커뮤니티들이 npm 스타일의 레지스트리를 만들고 있지만, 아직 글로벌 "인증 배지"는 없습니다.

이러한 허브가 성숙해질 때까지 대부분의 회사는 보안 설문지, 소프트웨어 자재 명세서(SBOM), 제한된 네트워크 범위 등 서드파티 에이전트를 SaaS 벤더처럼 취급할 것입니다.

A2A가 MCP 대비 공격 표면을 좁히는 방법

MCP는 모든 도구 스키마를 자연어 프롬프트로 노출하므로 인젝션과 인자 변조가 일상적인 걱정거리입니다.

A2A는 이 모든 것을 원격의 경계 밖에 숨겨두고, 클라이언트는 고수준 작업과 제한된 아티팩트만 볼 수 있습니다. 여전히 원격의 코드를 신뢰해야 하지만, 프롬프트가 노출되지 않으므로 모든 종류의 익스플로잇을 제거할 수 있습니다.

이 모든 것의 요점은 다음과 같습니다. 게시한 내용에 서명하고, 신뢰할 수 있는 내용을 고정하고, 모든 홉을 추적하고, 페이로드 한도를 적정 수준으로 유지하세요. 이러한 가드레일이 마련되어 있으면 A2A는 제대로 작동하는 REST 서비스를 호출하는 것보다 더 위험하지 않으며, 향후 새로운 에이전트를 추가할 때 훨씬 더 유연하게 대처할 수 있습니다.

A2A의 이상 vs. 현재 현실

이상

  • "에이전트 몰" 탐색. CoolAgentMall.dev를 열고 "세무 규정 준수"를 검색하면 별점과 서명된 카드가 있는 실시간 에이전트들을 볼 수 있습니다. 한 번의 클릭으로 URL을 개인 레지스트리에 저장되며 SDK도, 암호도 없습니다.
  • 드래그 앤 드롭 체인. Flowise(또는 n8n)에서 "송장 생성" 다음에 녹색 Tax-Check (A2A) 블록을 드래그하고 실행을 누르면 올바른 관할권 코드와 함께 JSON 아티팩트가 스트리밍으로 돌아오는 것을 볼 수 있습니다. (여러분 쪽에서는 글루 코드가 전혀 없습니다.)

현실 (2025년 5월)

  • ~50개 벤더가 지원을 발표했지만, 대부분의 에이전트는 여전히 "데모 요청" 단계에 있습니다.
  • LangGraph, CrewAI, AutoGen 어댑터는 견고하며, Flowise와 n8n은 커뮤니티 베타 버전에 머물러 있습니다.
  • 아직 공개 레지스트리는 없으며 팀들은 registry.yaml 파일이나 Vertex AI의 비공개 카탈로그에 의존하고 있습니다.
  • 서명된 카드를 제공하는 에이전트는 거의 없으며, 요금 제한이나 청구 상한은 자체 미들웨어에서 처리해야 합니다.
  • 성능 데이터는 대부분 경험 기반이며, 구글의 레퍼런스 서버는 로컬 테스트에서 홉당 ~30ms를 추가합니다.

A2A는 프로토타입과 내부 워크플로우에는 사용할 수 있지만, 소비자 앱과 규제 대상 스택은 레지스트리와 보안 표준이 성숙해질 때까지 추가적인 보호 장치가 필요합니다.

A2A를 활용해야 하는 경우와 그렇지 않은 경우

적합한 경우

  • 크로스 벤더 워크플로우: 제품 관리자 에이전트가 다른 회사의 재무 예측 에이전트가 필요합니다. A2A는 프롬프트 내용을 노출하지 않고도 공유된 핸드셰이크, 인증, 스트리밍을 제공합니다.
  • 보안에 민감한 블랙박스: 벤더가 모델 프롬프트를 공유하지 않지만 서명된 에이전트 카드를 노출합니다. 여전히 깨끗한 계약과 작업 수준 감사 추적이 제공됩니다.
  • 하이브리드 스택 & 혼합 언어: 타입스크립트 프런트엔드가 파이썬 데이터 사이언스 에이전트를 호출하거나 그 반대로 호출할 수 있는데, 이는 와이어를 건너는 것은 JSON-RPC뿐이기 때문입니다.
  • 진행 상황 업데이트가 필요한 장기 실행 작업: 빌드 파이프라인, PDF 렌더링, 데이터 내보내기: 커스텀 REST 엔드포인트를 폴링하는 대신 서버 전송 이벤트를 통해 상태와 아티팩트를 스트리밍합니다.

과도한 경우

  • 모든 것이 하나의 프로세스에서 실행: 전체 플로우가 선택한 오케스트레이터 안에 있다면, 프레임워크의 인메모리 호출을 사용하세요.
  • 작은 헬퍼 스크립트: 하나의 OpenAI 함수를 핑하는 크론 작업은 검색이나 스트리밍이 필요하지 않으며 직접 API 호출하는 것이 더 가볍습니다.
  • 일회성 데이터 가져오기: 지연 시간과 잡담이 중요하지 않은 주간 내보내기의 경우, 일반 REST 엔드포인트가 모니터링하기 더 쉽습니다.
  • 스키마가 많고, 프롬프트가 가벼운 도구: 프롬프트 내에서 복잡한 인자를 검증해야 하는 경우에는 MCP만으로도 충분합니다.

작업이 네트워크 경계를 넘나들고 신뢰, 실시간 진행 상황, 또는 나중에 새로운 전문 에이전트를 교체하는 것을 신경 쓰는 경우, A2A를 사용하세요. 잘 문서화된 API가 이미 요구사항에 적합하거나 전체 스택이 모니터에 테이프로 붙인 Raspberry Pi에 적합할 때는 건너뛰세요.

A2A는 모델에 새로운 마법을 추가하지 않습니다. 대신 기존 에이전트들이 만나고, 작업을 교환하고, 깔끔한 감사 추적을 유지할 수 있도록 신뢰할 수 있는 핸드셰이크를 추가합니다.

레지스트리 생태계는 여전히 수작업 수준이고 대부분의 에이전트가 비공개 데모 단계에 머물러 있지만, 프로토타입 개발이나 내부 업무 자동화에는 충분히 안정적인 기반을 제공합니다.

글루를 더 적게 만들고, 더 흥미로운 작업을 하세요.

🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article을 구독해주세요!

profile
FrontEnd Developer

0개의 댓글