저의 이전 x402 튜토리얼을 읽은 한 독자가 에이전트 결제 프로토콜(agent payment protocols)을 구축하는 모든 엔지니어가 결국 맞닥뜨리게 되는 일련의 질문들을 던졌습니다:

_"각 결제 증빙(payment proof)을 요청 메서드(request method), 경로(path), 금액(amount) 및 짧은 만료 시간(expiry)에 바인딩(bind)한 다음, 재사용된 영수증은 거부하세요. 결제 후 타임아웃과 중복 응답 후 재시도에 대한 작은 실패 테이블(failure table)을 보여주면 에이전트가 어떻게 중복 결제를 피하는지 보여주는 데 도움이 될 것입니다."

이것들은 예외적인 케이스(edge cases)가 아닙니다. 이것은 데모에서 작동하는 결제 흐름과, 감독 없이 자율 에이전트(autonomous agent)가 사용하도록 신뢰할 수 있는 흐름 사이의 차이입니다. 각 문제와 이를 해결하는 패턴을 살펴보겠습니다.

핵심 문제: 에이전트 결제는 결과적 일관성(Eventually Consistent)을 가집니다

x402 결제는 세 가지 단계로 이루어집니다:

1. 요청 (Request) — 구매자 에이전트가 HTTP 요청을 보내고, 결제 세부 정보가 포함된 402 Payment Required를 받습니다.
2. 결제 (Pay) — 구매자가 온체인(on-chain)으로 USDC를 제출합니다 (Base L2, 가스비 약 ~$0.003).
3. 전달 (Deliver) — 구매자가 x402-receipt 헤더와 함께 요청을 재전송하면, 판매자가 온체인 확인을 검증하고 결과를 반환합니다.

각 단계는 독립적으로 실패할 수 있습니다. 2단계는 온체인에서 성공했지만 3단계가 완료되지 않을 수 있습니다. 3단계는 동일한 영수증으로 재전송(replayed)될 수 있습니다. 판매자는 결제를 확인한 후 결과를 반환하기 전에 충돌(crash)할 수 있습니다. 에이전트는 사람이 지켜보지 않아도 이 모든 상황을 처리할 수 있어야 합니다.

패턴 1: 영수증 바인딩 (Receipt Binding) — 영수증은 무엇을 증명해야 하는가?

x402 영수증 표준은 다음 항목에 바인딩됩니다:

{
  "request_body_hash": "sha256(...)",
  "timestamp": "2026-08-07T17:00:00Z",
...

이것은 _"누군가가 이 정확한 요청 본문(request body)에 대해 이 시간에 결제했다"_는 것을 증명합니다.

하지만 이것은 결제가 **어느 엔드포인트(endpoint)**를 위한 것인지는 증명하지 못합니다. 만약 GET /search?q=cats와 GET /search?q=dogs가 모두 본문(body)이 비어 있다면, 본문 해시(body hash)가 일치하기 때문에 GET /search?q=cats에서 생성된 영수증이 기술적으로 GET /search?q=dogs에서도 유효할 수 있습니다.

해결책: 요청 컨텍스트 바인딩 (Request Context Binding)

영수증에 request_context 확장을 추가합니다:

{
  "request_body_hash": "sha256(...)",
  "timestamp": "2026-08-07T17:00:00Z",
...

이제 영수증은 단순히 본문(body)에만 묶여 있는 것이 아니라 특정 작업(operation)에 결합됩니다. 판매자는 현재 요청의 메서드(method), 경로(path), 그리고 금액(amount)과 일치하지 않는 영수증을 거부할 수 있습니다.

구현 (판매자 미들웨어, Go):

func verifyReceiptContext(receipt x402.Receipt, r *http.Request, expectedAmount int) error {
    ctx, ok := receipt.Extensions["request_context"]
    if !ok {
...

패턴 2: 영수증 재사용 방지 (Receipt Replay Protection) — 멱등성 캐시 (The Idempotency Cache)

영수증이 유효해지면, 공격자(또는 버그가 있는 에이전트)가 이를 재사용(replay)할 수 있습니다. 보호 조치가 없다면, 판매자는 동일한 유료 작업을 두 번 실행하게 되고, 구매자는 한 번만 결제했지만 두 개의 결과를 받게 됩니다.

해결책: 영수증 논스 캐시 (Receipt Nonce Cache)

판매자는 영수증의 만료 시간(expiry window)과 일치하는 TTL(Time To Live)을 가진 sha256(receipt_signature)를 저장합니다:

type ReceiptCache struct {
    mu    sync.RWMutex
    store map[string]CachedResult
...

핵심 통찰: 재사용된 영수증은 원래의 응답과 함께 409 Conflict를 반환합니다. 구매자는 자신이 결제한 결과를 받게 되며, 판매자는 재실행하지 않습니다. 이중 결제도, 이중 실행도 발생하지 않습니다.

패턴 3: 결제 후 타임아웃 (Timeout After Payment) — 가장 어려운 사례

시퀀스:

1. 구매자가 온체인(on-chain)에서 결제 완료 ✅
2. 구매자가 영수증과 함께 요청을 전송 → 판매자가 처리 시작
3. 네트워크 타임아웃 (Network timeout) — 판매자의 응답이 영원히 도착하지 않음
4. 구매자는 알 수 없음: 성공했는가, 실패했는가?

해결책: 영수증을 키로 사용하는 멱등적 재시도 (Idempotent Retry with Receipt as Key)

구매자는 동일한 영수증으로 재시도합니다. 결과를 캐싱해 둔 판매자는 캐시에서 해당 결과를 반환합니다 (패턴 2가 이를 처리합니다). 만약 판매자가 처리를 완료하지 못했다면 (실행 도중 충돌/크래시 발생), 영수증 서명(signature)이 아직 캐시에 없으므로 판매자는 작업을 재실행합니다.

하지만 여기서 미묘한 차이가 있습니다: 부수 효과가 있는 작업 (side-effectful operations). 만약 엔드포인트가 이메일을 보내거나 트랜잭션을 제출한다면, 재실행은 위험합니다.

해결책은 명시적인 idempotency_key를 사용하는 것입니다:

type x402Request struct {
    IdempotencyKey string `json:"idempotency_key,omitempty"` 
    Payload        json.RawMessage `json:"payload"` 
...

멱등성(Idempotent) 작업(GET, 순수 연산)의 경우: 영수증 서명(receipt signature)이 멱등성 키(idempotency key)가 됩니다.
부수 효과(side-effectful)가 있는 작업(외부 효과를 동반하는 POST/PUT)의 경우: 구매자가 결제 흐름 전에 고유한 idempotency_key를 생성하여 본문 해시(body hash)에 포함시키며, 판매자는 이를 사용하여 중복을 제거(deduplicate)합니다.

패턴 4: 실패 테이블 (The Failure Table)

독자께서 "결제 후 타임아웃 및 중복 응답 후 재시도에 대한 작은 실패 테이블"을 요청하셨습니다. 여기 그 결과가 있습니다:

마지막 행은 프로토콜의 문제가 아니라 온체인 검증(on-chain verification)의 문제입니다. 판매자는 자신의 주소로 온체인 확인이 완료된 영수증만을 수락합니다.

구현: 완전한 판매자 미들웨어 (Implementation: A Complete Seller Middleware)

이 모든 것을 종합하면, 다음과 같은 판매자 측 미들웨어가 완성됩니다:

func x402Middleware(next http.Handler) http.Handler {
    cache := NewReceiptCache()

...

이것이 에이전트 자율성(Agent Autonomy)에 의미하는 바

이제 에이전트는 결제를 안정적으로 처리할 수 있습니다:

1. POST /classify → 402 Payment Required
2. Base 네트워크에서 $0.10 USDC 결제 → 트랜잭션(tx) 확인됨
3. POST /classify + x402-receipt → 200 OK { "label": "spam" }
...

이 루프를 감시하는 인간은 없습니다. 이중 청구도 없습니다. 결제 누락도 없습니다. 에이전트는 자신이 사용하는 만큼만 정확히 지불합니다.

여기 소개된 패턴들은 저희 minia2a가 프로덕션 환경에서 실제로 실행 중인 방식입니다. 영수증 논스 캐시(receipt nonce cache)는 이중 청구 사고 없이 약 387,000건의 요청을 처리했습니다. request_context 확장은 저희 사양(spec) 위시리스트에 올라와 있으며, 이는 영수증 바인딩(receipt binding)을 위한 다음 단계의 논리적 진전입니다. 만약 x402를 기반으로 구축하면서 동일한 문제에 직면하고 있다면, 멱등성 캐시(idempotency cache)를 도입하는 것이 가장 레버리지가 높은(highest-leverage) 변화가 될 것입니다.

이 글을 쓰게 된 계기가 된 질문들을 던져준 Swapnoneel Saha에게 감사를 표합니다. 훌륭한 엔지니어링 질문은 더 나은 문서(documentation)를 만듭니다.