이 콘텐츠는 minia2a의 게시일 기준이며 기록용으로 보존됩니다. 현재 모델은 Base에서 USDC로만 호출당 비용을 지불하며, 서명된 지갑당 5회 무료 체험 호출이 제공되고 크레딧이나 충전 시스템은 없습니다.
2026-10-18 · x402 결제 기록이 담아야 할 것들
ex402 클라이언트가 결제를 보냅니다. 서버는 EIP-712 서명을 검증하고, 정산하며, 상품을 반환합니다. 이 결제는 _준수(conformant)_합니다. 이제 네 가지 다른 질문을 던지면 이야기가 산으로 흘러갑니다.
- 에이전트가 이 돈을 쓸 권한이 있었는가?
- 이 엔드포인트가 원칙자(principal)가 부여한 범위 내에 있었는가?
- 호출이 실제로 완료되었는가?
- 만약 완료되지 않았다면, 기록에는 누가 결정했는지, 그리고 돈은 어떻게 되었는지 나와 있는가?
유효한 서명으로는 이 질문들 중 어느 것도 답변할 수 없습니다. 서명은 키가 결제에 동의했다는 것을 증명합니다. 하지만 그 결제가 승인되었거나, 범위 내였거나, 할 가치가 있었다는 것을 증명하지 못하며—게다가 나중에 무슨 일이 일어났는지 기록하지도 않습니다.
현재 상황은 어떤 모습인가요
거래량은 더 이상 오차 범위를 넘어섰습니다. Chainalysis에 따르면 2026년 3분기 말까지 Base에서 누적된 x402 거래는 약 1억 3,850만 건에 달했습니다. XRPL 기반의 x402 결제는 1,340만 건을 기록했으며, 당시 7일 평균은 약 216,000건이었습니다. 같은 Chainalysis 보고서는 이 수치가 가치를 의미하는 것은 아니라고 경고합니다.
이러한 주의사항은 심각하게 받아들일 가치가 있습니다. 지난 10월 한 주간의 스냅샷에 따르면 Base와 Solana 전반에서 실제 x402 서비스 지출액으로 약 $294.5K가 기록되었으며, 이는 훨씬 더 큰 규모의 총 USDC 흐름과 비교됩니다. 두 개의 체인, 수백만 건의 호출(call), 주당 수십만 달러에 달하는 유료 수요입니다. 이 프로토콜은 돈으로 신뢰받는 것보다 훨씬 더 많이 사용되고 있으며 — 감사 가능성(auditability)이 그 이유 중 하나입니다. 한 10월 비평가(critique)의 말처럼, 현재 '적합한(conformant)'이라는 것은 결제 서명이 검증되었다는 의미일 뿐, 그 결제가 승인(authorized)되었다는 것을 의미하지 않습니다. 10월 1일에 첫 번째 전무이사(executive director)를 임명하고 현재 50명 이상의 멤버를 보유하게 된 x402 Foundation은 워킹 그룹을 구성하고 있습니다. 지금이야말로 결제 기록이 무엇을 포함해야 하는지에 대해 논쟁할 때입니다.
서명이 볼 수 없는 네 가지 실패 사례
이것들은 가설이 아닙니다. 정산(settlement)과 전달(delivery)이 별개의 단계인 호출당 비용 지불 플랫폼(pay-per-call platform)을 운영하면서 우리가 겪는 문제들입니다.
1. 거부(Refusal)가 실패(Failure)가 아니다
호출자(caller)가 유효하지 않은 매개변수(parameter)를 전송합니다. 핸들러(handler)가 이를 400 클래스 오류로 거부합니다. 아무것도 전달되지 않았습니다. 만약 플랫폼의 카운터(counter)가 이것을 _상위 스트림 실패(upstream failure)_로 간주한다면, 해당 엔드포인트는 경고(strike)를 쌓게 되고 결국 서비스에서 제외될 수 있습니다 — 이는 호출자의 입력 때문에 서비스를 처벌하는 것입니다. 서명은 유효하고, 결제는 정산되었지만, 기록은 누가 원인인지 잘못 알고 있습니다.
결제 기록은 호출자 오류(caller error), 핸들러 실패(handler failure), 그리고 **상위 스트림 실패(upstream failure)**를 분리해야 합니다. 왜냐하면 그 해결책이 다르기 때문입니다: 환불(refund), 경고(strike), 또는 재시도(retry)입니다.
2. 전달할 것이 없다는 것이 결제가 없다는 것을 의미하지 않는다
결제(Settlement)는 배송 실패보다 먼저 성공할 수 있다. 돈은 이동했지만, 응답은 작업이 실행되지 않았다고 말한다. 단지 '서명 유효함(signature valid)'만 저장하는 기록으로는 지불자가 가장 중요한 질문에 답할 수 없게 만든다: 나는 이것을 돌려받는가, 그리고 어떻게 알 수 있는가? 이 답변은 부울 값(boolean)이 아니라 상태(state)여야 하며, refund: enqueued | not-applicable | failed과 같이 되어야 하고, 그 상태가 선택된 이유도 포함해야 한다.
3. 재시도는 새로운 결제다
재생 보호(Replay protection)는 실제이다: 동일한 서명된 결제는 두 번 모두 상환 가능해서는 안 된다. 하지만 클라이언트들은 오류를 읽고 같은 헤더로 재시도하는 경우가 흔하다. 만약 기록에 _이 결제가 사용되어 잠겼다_라는 내용이 없다면, 클라이언트는 잠금장치를 강제로 걸어 아무것도 배우지 못한다. '재시도 가능(Retryable)'은 기록에 포함되어야 하며, 결제는 되었지만 배송되지 않은 호출의 경우 정직한 값은 false이다. 재시도는 새로운 요청이 아니라 새로운 결제가 필요하다.
4. 알 수 없음(Unknown)은 거짓(False)이 아니다
에이전트 도구링에서 가장 비용이 많이 드는 버그 클래스는 잘못된 답변이 아니다. 그것은 '답변' 그 자체다. 업스트림 타임아웃이나 null 스칼라가 0, false, 또는
- Fail-open. 클라이언트가 확장(extension)을 누락하더라도 호출은 진행됩니다. 필수 필드를 추가하면 생태계 전체가 하루아침에 파편화될 수 있습니다.
- 제한된 크기 (Bounded size). 이 문제는 이미 헤더를 통해 전송되고 있습니다. 모든 부록(addendum)은 엄격한 제한 내에서 바이트를 소모합니다. 기록을 간결하게 유지하고 인라인으로 포함하기보다는 증거에 대해 해시(hash)를 사용하세요.
- 비밀 정보 없음 (No secrets). 스코프 이름이 엔드포인트(endpoint)를 지정해야 합니다. 매개변수(parameter), 프롬프트(prompt), 또는 페이로드(payload)의 이름을 지정해서는 안 됩니다. 일관성을 나중에 증명하기 위해서는 해시만으로 충분합니다.
- 결과는 최소한 세 가지 값이어야 한다. 전달됨(Delivered), 거부됨(Refused), 측정되지 않음(Not-measured)은 완전히 다른 개념입니다. 이들을 하나로 합치는 것이 원장(ledger)이 거짓말하기 시작하는 방식입니다.
- 기록은 거부되어도 살아남아야 한다. 만약 기록이 성공적인 전달에만 존재한다면, 가장 중요한 경우—지불되었지만 전달되지 않은 경우—는 아무런 기록도 없는 경우가 됩니다.
이를 활용하는 방법 (What to do with this)
x402 서비스를 구축하고 있다면: 표준이 생기기 전이라도 결제 옆에 결과(outcome)와 환불 상태(refund state)를 기록하기 시작하세요. 이는 한 줄의 비용이며, '우리가 돈을 받았다'와 '무슨 일이 일어났는지 알고 있다' 사이의 차이를 만듭니다. 사양(spec) 작업을 하고 있다면: 인증 기록은 새로운 프로토콜 버전보다 작은 변화이며, 거래 건수 증가 속도가 신뢰를 따라가지 못한다는 비판에 대응합니다.
에이전트 지불의 다음 단계는 가장 많은 호출을 하는 체인(chain)에 의해 승리하지 않을 것입니다. 그것은 문제가 발생한 후에도 기록을 감사할 수 있는 레일(rails)에 의해 승리할 것입니다. 서명 유효성(Signature validity)은 진입 티켓입니다. 기록(The record)이 제품입니다.
출처: BraveNewCoin / Chainalysis · XRPL 누적 x402 결제액 · x402 준수성에 대한 10월 비판. $294.5K로 기재된 지출액은 정산 총액이 아닌, 1주일간의 제3자 추적기 스냅샷입니다.
원래 minia2a.uk에 게시됨.