디지털 상품, API 액세스, 데이터 구독 또는 AI 에이전트가 프로그래밍 방식으로 구매할 수 있는 모든 서비스를 판매하는 플랫폼을 구축하고 있다면, 기존의 결제 흐름(checkout flow)이 이를 위해 설계되지 않았다는 점을 이미 눈치챘을 것입니다. Stripe가 호스팅하는 결제 페이지는 사람이 읽는 것을 전제로 합니다. PayPal 리다이렉트(redirect)는 브라우저 세션(browser session)을 기대합니다. 구매자가 LangChain 에이전트이거나 예약된 curl 스크립트라면 이 중 어느 것도 존재하지 않습니다.

구매자가 자율적일 때 실제로 무엇이 변하는지, 그리고 판매자 측에서 이를 안전하게 처리하기 위해 어떤 인프라가 필요한지 설명하겠습니다.

핵심 문제: 자율적 구매자에게는 인간 중심의 결제 흐름이 작동하지 않음

전통적인 결제 흐름은 인간의 의도 신호(intent signals)를 중심으로 구축되었습니다. 사용자가 장바구니를 불러오고, 가격을 확인하고, 카드 정보를 입력하고, 확인을 클릭합니다. 부정 결제 방지(Fraud prevention)는 해당 세션의 행동 신호(behavioral signals)에 크게 의존합니다. 차지백(Chargebacks, 결제 취소 요청)이 존재하는 이유는 시스템이 승인 시점에 "결제"를 클릭한 인간이 실제로 그렇게 할 권한이 있는지 확인할 수 없기 때문이기도 합니다.

AI 에이전트는 이러한 신호의 대부분을 제거합니다. 브라우저 세션도 없고, 마우스 움직임도 없으며, 나중에 은행에 전화할 수 있는 인간과 연결된 저장된 카드(card-on-file)도 없습니다. 대신 여러분이 얻게 되는 것은 암호화된 인증(cryptographic authorization)이 첨부된 프로그래밍 방식의 요청이며, 확인하는 방법을 안다면 이는 실제로 인간으로부터 받는 것보다 더 검증 가능합니다.

대부분의 판매자 인프라는 이를 확인하는 방법을 모릅니다.

x402란 무엇이며, 왜 여기서 중요한가

x402는 오랫동안 사용되지 않았던 402 Payment Required 상태 코드를 기반으로 구축된 HTTP 네이티브 결제 프로토콜입니다. 아이디어는 이렇습니다: 에이전트가 여러분의 엔드포인트(endpoint)에 접속하면, 여러분은 402 코드와 결제 기술자(payment descriptor)로 응답합니다. 에이전트는 온체인(on-chain)에서 스테이블코인(stablecoin) 결제를 정산하고, 다음 요청에 증빙을 첨부하며, 여러분은 이를 이행합니다. 리다이렉트도, 세션도, 개입하는 인간도 없습니다.

순수한 기계 간 상거래(machine-to-machine commerce)를 위해 이것은 올바른 원시 구성 요소(primitive)입니다. 결제 증빙이 요청에 포함되어 있습니다. 정산은 최종적입니다. 3주 후에 결제를 되돌릴 수 있는 카드 네트워크가 중간에 끼어 있지 않습니다.

하지만 x402만으로는 판매자의 문제를 해결할 수 없습니다. 그것은 단지 문제가 발생하는 위치를 옮길 뿐입니다. 인간의 카드가 도난당했는지 의심하는 대신, 방금 결제한 에이전트가 애초에 그 돈을 사용할 권한이 있었는지 의심하게 됩니다. 책임의 소재는 달라지지만, 문제는 여전히 실재합니다.

위임장(Mandate)이란 무엇이며, 왜 이를 검증해야 하는가

에이전트 결제 시스템(Agentic payment systems)에서 위임장(Mandate)이란, 운영자(기업, 개발자, 인간 본인)가 특정 에이전트에게 특정 목적을 위해 일정 한도 내에서 자금을 사용할 수 있도록 명시적으로 권한을 부여했음을 나타내는 암호학적으로 서명된 승인(Authorization)입니다. 이를 범위가 지정된, 기계 판독 가능한 위임장(Power of attorney)이라고 생각하면 됩니다.

에이전트로부터 자금을 징수하기 전에, 다음 세 가지 사항을 확인해야 합니다:

• 위임장이 실제인지 (승인 서명이 유효하며 위조되지 않았는지)
• 위임장이 최신인지 (취소되었거나 이전 트랜잭션에서 재사용(Replay)된 것이 아닌지)
• 트랜잭션이 범위 내에 있는지 (에이전트가 구매하려는 것이 위임장에서 실제로 허용하는 것과 일치하는지)

이 검증은 빨라야 합니다. 요청 시점에 API 액세스를 판매하고 있다면, 매 호출마다 제3자 검증 서비스로 왕복(Round-trip)하는 비용을 감당할 수 없습니다. 지연 시간(Latency) 문제를 차치하더라도, 외부 서비스가 사용할 수 없을 때마다 결제 승인 경로가 중단되어서도 안 됩니다.

올바른 아키텍처는 네트워크 의존성 없이 로컬에서 위임장을 검증합니다. 오프라인에서 확인할 수 있는 서명된 승인은 필요한 지연 시간 및 회복 탄력성(Resilience) 특성을 모두 제공합니다.

순서가 생각보다 중요한 이유

위임장 검증 체계가 갖춰져 있더라도, 결제를 징수하기 전 검증 단계의 순서를 신중하게 고려해야 합니다. 단계를 건너뛰거나 잘못된 순서로 실행하는 것은 단순한 품질 문제가 아니라 책임(Liability) 문제입니다.

Veto Checkout의 문서에서는 자금이 징수되기 전에 실행되는 고정된 4단계 게이트(Gate)를 설명합니다:

• 위임 사항 확인 (mandate verification: 권한 서명이 유효한지 확인)
• 재전송 확인 (replay check: 이 트랜잭션 토큰이 이전에 사용된 적이 없는지 확인)
• 평판 평가 (reputation evaluation: 해당 에이전트 또는 운영자에 대해 알려진 정보 확인)
• 정책 실행 (policy execution: 가맹점이 정의한 자체 규칙 적용: 속도 제한 (rate limits), 지출 한도 (spend caps), 허용된 제품 카테고리 등)

문서에서는 이 순서를 명시적으로 설명합니다: "순서가 곧 차지백 (chargeback) 방어 수단입니다." 그리고: "결제 레일 (rail)은 게이트가 이미 승인한 지출만을 실행합니다."

이러한 프레임워크는 매우 유용합니다. 게이트는 "정산은 최종적이다 (settlement is final)\