▲

AI 에이전트 프로토콜 개발자 가이드

 (developers.googleblog.com)
10P by GN⁺ 8시간전 | ★ favorite | 댓글과 토론
  • MCP, A2A, UCP, AP2, A2UI, AG-UI 등 6가지 AI 에이전트 프로토콜을 하나의 레스토랑 공급망 에이전트 시나리오로 묶어, 각 프로토콜이 해결하는 문제를 실전 코드와 함께 단계별로 설명하는 가이드
  • Google의 Agent Development Kit(ADK) 를 활용해 빈 LLM에서 출발, 프로토콜을 하나씩 추가하며 재고 확인·견적·주문·결제·대시보드 렌더링까지 완성하는 구조
  • MCP는 도구/데이터 연결, A2A는 에이전트 간 통신, UCP는 상거래 표준화, AP2는 결제 인가, A2UI는 UI 구성, AG-UI는 스트리밍 전달을 각각 담당
  • 각 프로토콜은 잘 알려진 URL 기반 디스커버리, 타입 지정 스키마, 표준 이벤트 스트림 등 공통 패턴을 공유하여 생태계 호환성 확보
  • 첫날부터 6개 전부 도입할 필요 없이, 필요에 따라 점진적으로 추가하는 접근을 권장

MCP(Model Context Protocol) — 도구·데이터 연결

  • 에이전트를 시스템과 데이터에 연결할 때 발생하는 첫 번째 장벽을 해결하는 프로토콜로, 각 API마다 커스텀 통합 코드를 작성하는 수작업을 제거
  • MCP 서버가 자신의 도구를 광고(advertise)하면 에이전트가 자동으로 디스커버리하는 구조로, 수백 개 서버에 대해 단일 표준 연결 패턴 제공
  • MCP 서버는 해당 시스템을 만든 팀이 유지보수하므로, 에이전트 측에서 통합 코드를 작성하거나 업데이트할 필요 없이 항상 최신 도구 정의를 확보
  • ADK에서 McpToolset을 통해 1급 지원하며, 예시에서는 PostgreSQL 데이터베이스 조회(MCP Toolbox for Databases), Notion MCP를 통한 레시피 조회, Mailgun MCP를 통한 공급업체 이메일 발송을 구현
    • ToolboxToolset으로 재고 DB 연결
    • McpToolset으로 Notion, Mailgun 등 외부 서비스 연결
  • 별도 코드 없이 npx 명령으로 MCP 서버를 실행하고 에이전트에 바로 연결하는 간결한 패턴

A2A(Agent2Agent Protocol) — 에이전트 간 통신

  • MCP가 데이터 접근을 해결한 뒤 남는 전문성(expertise) 문제를 다루는 프로토콜로, 서로 다른 팀·프레임워크·서버에서 운영되는 원격 에이전트 간 표준 디스커버리·통신 방법 제공
  • 각 A2A 에이전트는 /.well-known/agent-card.json에 Agent Card를 게시해 이름, 능력, 엔드포인트를 공개하며, 키친 매니저 에이전트가 이를 패치해 런타임에 적절한 에이전트로 쿼리 라우팅
  • 새로운 원격 에이전트 추가 시 URL만 추가하면 되므로 수동 코드 변경이나 재배포 불필요
  • ADK의 RemoteA2aAgent는 턴당 하나의 원격 에이전트로 라우팅하며, 여러 원격 에이전트에 동시 쿼리가 필요한 경우 a2a-sdk를 직접 사용
  • to_a2a() 함수로 모든 ADK 에이전트를 A2A 서비스로 변환 가능
  • 가격 확인, 품질 등급, 배송 윈도우 등 원시 데이터가 API로 노출되지 않더라도 에이전틱 인터페이스를 통해 접근 가능

UCP(Universal Commerce Protocol) — 상거래 표준화

  • 공급업체마다 다른 API를 가진 주문 프로세스를 통합하는 프로토콜로, 쇼핑 라이프사이클을 모듈형 기능으로 표준화
  • 강타입 요청/응답 스키마로 일관성을 유지하며, 하위 전송 계층이 REST, MCP, A2A, EP(브라우저 기반 임베디드 프로토콜) 중 어떤 것이든 동일한 패턴으로 동작
  • A2A와 동일한 /.well-known/ucp URL 패턴으로 공급업체 카탈로그 디스커버리 가능
  • 독점 SDK 불필요, 기존 HTTP 클라이언트로 표준 REST API와 바로 연동
  • 예시에서는 CheckoutCreateRequest로 연어 10파운드와 올리브오일 3병을 주문하고, PaymentCreateRequest로 결제 요청을 구성
  • UCP 샘플 저장소에 ADK와 A2A를 결합한 AI 기반 쇼핑 어시스턴트 예제 포함

AP2(Agent Payments Protocol) — 결제 인가·감사 추적

  • UCP가 주문 대상과 공급업체를 처리한다면, AP2는 누가 구매를 승인했는지와 감사 추적을 담당
  • 타입 지정 mandate로 의도의 부인 불가능한 증거(non-repudiatable proof of intent)를 제공하며, 모든 거래에 설정 가능한 가드레일 적용
  • 전체 플로우: IntentMandate → PaymentMandate(서명됨) → PaymentReceipt
    • IntentMandate: 허용 가맹점, 지출 한도, 자동 승인 여부, 환불 가능성 요구, 만료 시간 등 가드레일 설정
    • PaymentMandate: 특정 카트와 금액에 바인딩된 결제 위임장으로, 한도 초과 시 관리자의 명시적 승인까지 미서명 상태 유지
    • PaymentReceipt: 감사 추적을 완결하는 영수증
  • UCP의 확장(extension)으로 동작하여, 체크아웃 플로우에 암호화된 인가 증명 추가
  • 현재 v0.1 단계이며, ADK 코어에 내장되지 않고 별도 패키지로 타입 제공

A2UI(Agent-to-User Interface Protocol) — 동적 UI 구성

  • 에이전트가 일반 텍스트 대신 대시보드, 주문 양식, 공급업체 비교표 등을 동적으로 구성할 수 있게 하는 프로토콜
  • 18개의 안전한 컴포넌트 프리미티브(행, 열, 텍스트 필드 등)로 구성된 고정 카탈로그에서 선언적 JSON 형식으로 새로운 레이아웃 조합
  • UI 구조와 데이터를 분리하여, 컴포넌트 재전송 없이 데이터만 업데이트 가능
    • 컴포넌트는 ID로 상호 참조하는 플랫 리스트로 전송
    • 데이터는 별도의 dataModelUpdate로 전달
  • 클라이언트 측 렌더러가 JSON을 Lit, Flutter, Angular 등 네이티브 UI로 변환
  • 동일 에이전트가 같은 18개 프리미티브로 재고 체크리스트, 주문 양식, 공급업체 비교 등 완전히 다른 인터페이스 생성 가능
  • ADK 웹 인터페이스(adk web)에서 A2UI 컴포넌트를 네이티브로 렌더링할 수 있어 개발 중 별도 렌더러 구축 불필요
  • A2UI Widget Builder로 레이아웃을 인터랙티브하게 조합 가능

AG-UI(Agent-User Interaction Protocol) — 스트리밍 전달

  • 에이전트는 기존 REST API와 달리 텍스트를 점진적으로 스트리밍하고, 응답 중간에 도구를 호출하고, 사람의 입력을 기다리며 일시정지하는 등 복잡한 상호작용 패턴을 가짐
  • AG-UI는 미들웨어로 동작하여 프레임워크별 원시 이벤트를 표준화된 SSE 스트림으로 변환
  • 프런트엔드는 TEXT_MESSAGE_CONTENT, TOOL_CALL_START 등 타입 지정 이벤트만 수신하면 되고, 어떤 에이전트 프레임워크가 생성했는지 알 필요 없음
  • ADK는 네이티브 /run_sse 엔드포인트를 제공하지만, 파싱 코드가 보일러플레이트이고 이벤트 포맷 변경 시 깨지는 문제를 AG-UI가 해결
  • ag_ui_adk 패키지로 래핑 후 FastAPI 앱에 마운트하는 것만으로 AG-UI 스트리밍 엔드포인트 구성 가능

전체 통합 동작 흐름

  • 사용자가 "연어 재고 확인, 오늘 도매가·품질 등급 조회, 재고 부족 시 Example Wholesale에서 10파운드 주문 및 결제 인가"를 요청하면 6개 프로토콜이 단계적으로 동작
  • 1단계 — 정보 수집: MCP로 재고 DB 쿼리(check_inventory) → A2A로 원격 가격·품질 에이전트에 쿼리(ask_agent)
  • 2단계 — 거래 완료: UCP로 체크아웃 요청(place_order) → AP2로 설정된 가드레일 내에서 결제 mandate 확보(authorize_payment)
  • 3단계 — 결과 표시: A2UI로 인터랙티브 위젯 구성 → AG-UI로 도구 호출과 텍스트 응답을 실시간 스트리밍

프로토콜 활용 팁

  • 각 프로토콜이 해결하는 문제를 정확히 파악해야 아키텍처가 깔끔하게 유지됨
  • 첫날부터 6개 전부 필요하지 않으며, 대부분 MCP로 시작한 뒤 멀티 에이전트 통신, 상거래, 결제, 리치 UI, 스트리밍 등 요구사항 증가에 따라 점진적 추가
  • 프로토콜로 빌드하기 전에 ADK 통합, 공식 SDK, 샘플 코드를 먼저 확인하여 직접 재구현하지 않도록 할 것
  • 프로토콜들이 아직 성숙 중이지만, 잘 알려진 URL 디스커버리·타입 지정 스키마·표준 이벤트 스트림 등의 패턴을 일찍 채택하면 도구·서비스·에이전트 생태계와의 호환성 확보