몇 주 전, 저는 어떤 AI든 사용할 수 있도록 사이트를 한 번만 설명하는 방법에 대해 글을 썼습니다. 그 이후로 제가 막연하게 언급했던 것("에이전트가 사용자를 대신해 결제할 것이다")이 더 이상 가설에 머물지 않게 되었습니다. OpenAI는 ACP를 출시했고, Google은 AP2를 출시했습니다. 이들은 거의 정반대의 방식으로 동일한 문제를 해결합니다.

저는 두 방식 모두의 판매자(merchant) 측 구현을 진행했습니다. 차이점은 직접 구현해 보기 전까지는 명확히 드러나지 않기 때문에, 여기 현장 기록을 남깁니다.

30초 요약
ACP (Agentic Commerce Protocol, OpenAI + Stripe)는 세션 기반(session-based)입니다. 에이전트가 마치 헤드리스 장바구니(headless cart)처럼 귀하의 서버에서 실시간 결제 세션을 구동합니다. 이는 ChatGPT의 인스턴트 결제(Instant Checkout)를 지원합니다.
AP2 (Agent Payments Protocol, Google)는 위임 기반(mandate-based)입니다. 귀하의 상점은 "장바구니와 가격은 다음과 같다"라는 객체에 서명하고, 구매자의 에이전트는 "이를 승인한다"라는 객체에 서명합니다. 이는 검증 가능한 자격 증명(verifiable credentials)과 현재의 FIDO Alliance에 의존합니다.
목표는 같습니다. 하지만 형태는 완전히 다릅니다.

ACP: UI를 소유하지 않는 결제 세션
ACP는 5개의 REST 엔드포인트와 상태 머신(state machine)으로 구성됩니다. 에이전트는 세션을 생성하고, 이를 업데이트(주소, 배송, 쿠폰)하며, 완료합니다:

POST /checkout_sessions create from line items
POST /checkout_sessions/:id update (address, shipping, discounts) 
POST /checkout_sessions/:id/complete   pay

귀하가 반환하는 것은 CheckoutSession입니다: 품목(line items), 실시간 배송 옵션, 그리고 세부 내역이 구분된 합계(소계, 할인, 이행 비용, 세금, 총액)입니다. 금액은 정수 단위의 최소 단위(minor units)로 처리됩니다 (330 = $3.30). 에이전트가 귀하에게 공유 결제 토큰(Shared Payment Token)을 전달하고 귀하가 Stripe를 통해 이를 청구하면 결제가 완료됩니다. 카드는 에이전트에게 절대 노출되지 않습니다.

사고 모델: 브라우저만 제외하면 기존의 결제 방식과 동일합니다.

AP2: 세션을 실행하지 말고 장바구니에 서명하라
AP2에는 세션이 없습니다. 에이전트는 귀하에게 의도 위임(Intent Mandate, 예: "120달러 미만의 빨간색 농구화")을 보냅니다. 귀하는 가격을 책정하고 암호학적으로 서명된 장바구니 위임(Cart Mandate)을 반환합니다:

{
  "contents": { /* W3C PaymentRequest: items, total, currency */ },
  "merchant_authorization": "<RS256 JWT>"   // iss, sub, aud, exp, jti, cart_hash
} 

해당 JWT는 가격에 대한 유효 기간이 짧은 보증서입니다. 여기서 금액은 센트(cents) 단위가 아닌 십진수 주요 단위(major units, 예: 19.99)입니다. 그러면 구매자의 자격 증명 제공자(credentials provider)가 사용자 측에서 서명된 결제 위임(Payment Mandate)을 반환하며, 결제(settlement)는 결제 네트워크를 통해 실행됩니다. 귀하의 역할은 정직하게 서명하고 그 구속력(binding)을 검증하는 것입니다.

아무도 경고해주지 않는 부분
만약 두 프로토콜을 모두 지원한다면, 귀하는 두 개의 서로 다른 세계를 유지 관리하게 됩니다. 즉, 상태 유지 세션(stateful session) 대 무상태 서명 문서(stateless signed document), 소수 단위(minor units) 대 주요 단위(major units), 귀하가 청구(you-charge)하는 방식 대 네트워크가 결제(network-settles)하는 방식의 차이입니다.

그리고 하루를 통째로 잡아먹었던 미묘한 문제 하나가 있습니다. AP2의 cart_hash는 이를 계산하는 주체가 누구든 간에 바이트 단위로 동일(byte-identical)해야 하며, 그렇지 않으면 검증에 실패합니다. JSON.stringify만으로는 충분하지 않습니다(키 순서, 숫자 형식, Go 언어의 맵 키 정렬 방식 등...). 정형화된 JSON(Canonical JSON, RFC 8785 / JCS)이 필요합니다. 즉, 키 정렬, 공백 제거, 소수점이 없는 정수 형식이 필요합니다. 저는 모든 SDK가 동일한 객체에 대해 동일한 '골든 스트링(golden string)'을 생성할 때에만 이를 신뢰했습니다.

왜 하나만 선택하지 않았는가
상점 운영자가 굳이 하나를 선택해야 한다고 생각하지 않습니다. 에이전트가 어떤 프로토콜을 사용하든 카탈로그, 가격, 재고, "허용 여부" 규칙은 동일합니다. 그래서 저는 AI2Web에서 하나의 매니페스트(manifest) 위에 두 가지를 모두 구축했습니다. 상점을 한 번만 기술하면, 동일한 단일 진실 공급원(source of truth)으로부터 ACP 세션을 제공하거나 AP2 장바구니에 서명할 수 있습니다. 안전 모델도 동일합니다. 서버 권한 기반의 가격 책정(server-authoritative pricing), 에이전트를 통한 카드 데이터 전송 없음, 그리고 돈이 움직이는 모든 동작은 승인을 위한 미리보기(previews)를 거칩니다.

지난 포스트에서의 가설이 이제 막연한 설명이 아닌 실제 프로토콜을 바탕으로 구체화되었습니다.

내가 알고 싶은 것
이 부분은 정말 확신이 서지 않으며, 이것이 바로 유용한 질문입니다:

만약 하나만 지원해야 한다면, 무엇을 선택해야 하며 그 이유는 무엇일까요? ChatGPT 배포 (ACP)가 Google의 레일 (AP2) 위에 있는 것보다 더 가치가 있을까요, 아니면 그 반대일까요?

두 가지를 모두 제공하는 레이어가 그만한 가치를 증명할 수 있을까요, 아니면 솔직히 두 가지를 직접 통합하는 것만으로도 충분할까요?

크립토(Crypto) 관계자들을 위한 질문입니다: 상점별 장바구니 승인 (Cart Mandate signing)이 적절한 신뢰 경계 (trust boundary)일까요, 아니면 네트워크에 의해 사용자 측이 검증될 때까지는 보안 연극 (security theater)에 불과할까요?

아직 초기 단계이며 오픈 소스입니다 (코드 MIT, 명세 CC-BY).

어느 사이트에서든 확인할 수 있는 검증기 (Validator):
https://ai2web.dev

코드 및 명세 (Code and spec):
https://github.com/ai2web-foundation

두 개의 프로토콜, 하나의 카탈로그. 이 방식이 실패할 지점이 있다면 어디일까요?