Cloudflare x402 API 결제 시스템 분석: HTTP 402를 이용한 유료 서비스 구현의 네 가지 함정

AI 에이전트에게 유료 API를 사용하게 할 경우, '승인했으니 결제가 완료되었다'고 생각하는 것은 오늘로 끝내야 합니다.

Cloudflare의 새로운 Monetization Gateway에서는 한 번의 요청에 설정할 수 있는 가격이 최대 $100이고, 최소 결제액은 $0.001입니다. 공개된 요금 규칙에는 다음과 같은 메커니즘들이 나열되어 있습니다.

• HTTP 402를 통해 API 자체가 결제 조건을 반환합니다.
• 변동 요금에서는 상한액에 승인(署名)하고, 처리 후에 실제 금액을 결정합니다.
• 결제가 성공한 후에야 구매자에게 리소스를 반환합니다.

이것이 9월 30일에 클로즈드 베타를 시작한 x402 버전의 API 요금소입니다. 이 회사는 추론(inference), 검색, 주식 관련 데이터, PDF 생성이라는 네 가지 실제 사용 사례도 공개했습니다. 판매자와 구매자 모두 미국 거점이 조건입니다.

주목해야 할 것은 금액이 작다는 것만이 아닙니다. x402의 upto 사양을 살펴보면, 서버와 결제를 중개하는 Facilitator 사이에서 동일한 필드가 도중에 의미를 바꿉니다.

PaymentRequirements.amount
/verify : 승인할 상한액
/settle : 실제로 결제할 금액

위는 사양을 정리한 대응표이며, API 응답을 수집한 로그가 아닙니다.

같은 amount라도 같은 금액일 것이라고 단정할 수 없습니다. 이 부분을 건너뛰면 변동 요금 구현이 망가집니다.

승인 상한액과 사용량에 따른 결제를 자동판매기에 비유하여 AI 생성 개념을 설명하는 일러스트. 실제 제품의 구조도는 아닙니다.

조사일은 2026년 10월 4일, 발표일은 9월 30일이며, 가격 및 이용 조건은 Cloudflare 공식 문서를, 서명의 성격은 x402 공식 사양을 기반으로 합니다. 네 가지 사용 사례는 Cloudflare의 발표 값이며, 사용자 수나 성능을 독자적으로 측정한 것이 아닙니다. 외부 API 결제, 월렛 서명, 베타 환경에서의 통합 테스트는 미실행입니다. 본문의 금액 예시와 로컬 계산은 설명용이며 실제 거래가 아닙니다.

10월 4일에 제품 개요, 요금 규칙, 이용 조건을 대조하여 Monetization Gateway의 조건을 정리했습니다.

여기서 $0.001은 API의 결제 하한이며, Cloudflare 수수료가 $0.001을 의미하는 것은 아닙니다. 또한, 판매자에게는 카드 등록, 이메일 확인, 계정/존 검증 등도 필요합니다.

여기까지는 'API에 가격표를 붙이는' 이야기입니다. 흥미로운 것은 그 다음입니다.

검색 1회당 고정 가격이라면 이야기는 간단합니다. 요청된 금액을 승인하고, 같은 금액을 결제하면 됩니다.

PDF 생성은 다릅니다. 계산 시간이나 출력 크기가 처리 전에 확정되지 않습니다. 추론 역시 마지막에 몇 토큰이 나올지 처음에는 확정할 수 없습니다.

선불 고정액으로 할 것인지, 아니면 사용한 후에 구매자에게 승인을 다시 받을 것인지. 그 사이에 있는 것이 upto입니다.

Cloudflare의 x402 해설에서는 미납 액세스에 대해 402 Payment Required를 반환하고, PAYMENT-REQUIRED 헤더에 Base64로 인코딩된 JSON을 담습니다.

구매자가 읽는 것은 단순히 '얼마'가 아닙니다.

amount

만 보고 자동 서명하는 구현 방식은 통화와 수취인 확인을 놓치게 한다. 금액이 작다는 것과, 지불 조건이 옳다는 것은 별개다.

조건을 선택한 클라이언트는 서명을 만들고, 동일한 요청을 PAYMENT-SIGNATURE를 붙여 재전송한다. 서명 페이로드 생성은 대응하는 x402 라이브러리에 맡기는 것이 공식 안내이다.

상한을 M, 실제 사용량에서 산정하는 금액을 A라고 하자. 둘 다 atomic units의 정수이다. 결제 시 지켜야 할 관계는 다음과 같다.

0 <= A <= M

다만, 서명 검증 대상까지 A로 대체해서는 안 된다.

EVM용 사양의 결제 시 검증은 이렇게 명시한다.

Verify the signature against

permitted.amount
구매자가 서명한 것은 M을 포함하는 메시지이다. 실제 금액 A로 재작성된 메시지로 검증하면, 정상적인 부분 결제까지 서명이 불일치하게 된다.

사양에는 상한 20000, 실액 1858이라는 예시도 있다. 여기서 필요한 것은

Cloudflare의 공개 데모에 있는 API2PDF 요청은 매우 간단하다.

curl -iX POST https://v2.api2pdf.com/chrome/pdf/html \
--header "Content-Type: application/json" \
--data '{"html":"<p>Hello from an AI agent</p>"}'

공식 게재 예시는 HTTP/2 402와 payment-required를 반환한다. 여기에는 지갑 서명이 포함되어 있지 않다. 이 curl을 성공적인 결제의 예시로 취급하지 말 것.

헤더를 얻었다면, 다음 보조 코드로 내용을 표시할 수 있다. 이는 필자가 작성했으며, 합성된 Base64 JSON을 사용한 로컬 실행을 확인한 것이다. 금액 표시는 이번 Cloudflare 문서의 1 단위=$0.000001로 한정한다.

# 획득한 payment-required 값을 환경 변수로 설정한 후 실행한다
python3 - <<'PY'
import os, base64, json
...

이것은 열람용이다. Base64 복호화는 서명 검증이 아니며, 표시할 수 있었다는 조건으로 자동 승인해도 된다는 의미도 아니다.

다른 제품의 AI Gateway에도 같은 날 Machine Payments의 베타 버전이 추가되었다. 공식적인 첫 요청은 다음 형태다. 이용 조건을 충족하는 미국 계정을 대상으로 하며, 카드 등록과 API 토큰이 필요하다.

curl -iX POST \
"https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/ai/run" \
--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
...

Payment-Method: x402는 Cloudflare 고유의 선택적 헤더다. 이것을 생략하면 일반적인 과금 경로로 진행되어 Unified Billing 잔액에서 차감될 수 있다.

이 역시 서명 없는 첫 요청이며, 추론 결과를 받으려면 결제 조건 확인과 서명된 재전송이 계속된다. 앞서 언급한 Monetization Gateway의 $0.001을 이 모델의 추론 단가로 전용하지 말 것.

근거는 가격 책정 단위에 있다. 여기서는 1000이 $0.001이 된다. 반대로 $0.01을 10,000 단위로 변환해야 할 곳에 1을 넣으면 1센트가 되지 않는다.

부동 소수점으로 달러를 계산하는 것보다 내부적으로는 정수 단위를 사용하고 화면 표시만 십진수로 하는 것이 경계를 파악하기 쉽다.

대책: amount를 정수 단위로 저장하고, 통화/자산의 자릿수를 확인하여 표시 시 변환할 것. 이번 환산을 다른 자산에 유용하지 말 것.

EVM(Ethereum Virtual Machine)용 upto 사양은 리소스 서버가 실액 산정을 담당하며, 악의적인 판매자가 사용량과 관계없이 상한 전체 금액을 청구할 수 있다고 설명한다.

암호화가 지키는 것은 '서명된 상한을 초과하지 않는다'라는 경계다. PDF 계산 시간이나 LLM(Large Language Model) 사용량이 올바르게 계산되었다는 증명은 거기에서 나오지 않는다.

설명을 위해 상한 $0.10, 적정하게 측정된 실액 $0.02라고 가정하자. $0.10 결제는 상한 내이지만, 과다 청구 여부는 다른 증거가 필요하다.

대책: 승인 상한을 불필요하게 넓히지 말고, 앱 측에서 견적/사용량/결제 결과를 대응시킬 것.

Cloudflare의 검증 요건은 PAYMENT-CONTEXT가 없으면 미납/미검증으로 처리한다고 한다. JSON을 디코드만 했다고 이 조건을 충족하지 못한다.

이 부분을 생략하면, 앱은 승인을 확인하기 전에 CPU나 외부 API 비용을 사용하는 설계가 된다.

대책: 지정된 JWKS(JSON Web Key Set) 및 서명 방식/유효 기간/대상 URL 등을 검증하는 진입점을 마련하고, 실패 시 유료 처리를 시작하지 말 것.

근거는 upto의 단회 사용 규칙이다. 결제 후 승인은 상한을 다 썼는지 여부와 관계없이 재사용할 수 없다.

$0.10까지 승인해서 $0.02를 결제해도, 같은 서명에 '남은 $0.08 사용권'이 남는 것은 아니다.

대책: 다음 구매는 새로운 승인으로 취급할 것. 통신 실패의 재시도 역시 앱의 요청 ID/처리 상태/결제 상태를 대조한 후에 수행할 것.

'에이전트 결제 대응'으로 요약하면, 다른 작업을 하는 메커니즘까지 나란히 놓이게 된다.

10월 4일, Monetization Gateway, x402의 공식 구현, Stripe Link 연동 문서를 비교했다. 아래는 같은 기능을 가진 속도 순위가 아니라, 담당하게 할 업무의 비교이다.

• API를 판매할 쪽이라면, Gateway 또는 직접 구현이 비교 대상이 된다. 무엇을 엣지(edge)에 맡기고 자신의 서버에 무엇을 남길지를 선택해야 한다. -
  기존 카드 결제 폼으로 구매한다면, Link의 업무가 가깝다. x402 엔드포인트가 없는 상점에서는 402 재전송만으로는 결제가 불가능하다. -
  프로토콜이 공개되어 있어도, 이용하는 서비스의 참여 조건은 사라지지 않는다. x402 자체와 Cloudflare의 지역/심사 조건을 동일시해서는 안 된다.

가격을 비교할 때는 '승인한 금액'과 '결제 서비스의 수수료'를 분리하고 싶다. 이번에 확인한 Gateway 문서의 $0.001~$100은 리소스에 설정하는 가격/결제의 범위이며, 3가지 방식의 수수료 비교표에는 사용할 수 없다.

구매자 측의 설계를 시작한다면, 예를 들어 다음과 같이 예산과 자동 승인을 분리할 수 있다. 이것은 필자가 작성한 설계용 JSON이며, 특정 SDK가 그대로 읽는 설정 파일이 아니다. JSON으로서의 구문만 로컬에서 검증했다.

{
"automatic_signing": false,
"max_authorization_usd_per_request": "0.02",
...

$0.02는 설명용 예산이다. 이것을 실제 amount로 사용할 때는, 검증된 자산과 단위로 변환해야 한다. 설정을 해 놓았다고 해서 제한이 걸리는 것이 아니라, 서명 전의 판정 처리(判定処理)에 연결할 필요가 있다.

✗ "402는 전부 에러" → 결제 조건을 전달하는 응답이 된다
✗ "서명이 유효하다면 결제 완료" → 검증과 결제는 별개의 단계다
✗ "amount는 항상 청구액" → upto의 검증 시에는 상한액이다
...

HTTP 안에 결제를 넣게 되면, API를 발견한 에이전트가 그 자리에서 조건을 읽고 승인하고 구매할 수 있는 길이 열린다. 그 중심에 있는 것은 화려한 구매 화면보다 작은 헤더와 서명된 정수(integer)이다.

그러니 첫걸음도 작아도 괜찮다. 자신의 클라이언트에서 402를 버리고 있지는 않은지. 상한액과 결제액을 같은 변수에 밀어 넣고 있지는 않은지. 오늘 중으로, 결제 조건을 읽는 처리와 서명하는 처리 사이에 하나의 경계를 그렸으면 좋겠다.

Cloudflare: Monetization Gateway beta: charge AI agents for consumption with HTTP 402 (2026년 9월 30일)

Cloudflare: Monetization Gateway

Cloudflare: Monetization rules

Cloudflare: Eligibility

Cloudflare: x402 protocol

Cloudflare: Payment validation

x402: Scheme upto

x402: Scheme upto on EVM

Cloudflare: Pay for AI inference with Machine Payments (2026년 9월 30일)

Cloudflare: Machine Payments (x402)

x402: A payments protocol for the internet

Stripe: Enable agents to spend

API나 AI 에이전트를 만들고 있다면, 좋아요/저장해서 설계할 때 다시 보고 싶다. 결제를 구현하는 팀원들에게도 공유해 주었으면 좋겠다.

댓글로 알려주세요.

에이전트가 자동 승인해도 되는 금액을 리퀘스트당 얼마로 할까요? 매번 사람의 승인을 거칠까요? 자신의 API를 판매한다면, 고정 가격의 exact와 변동 가격의 upto, 어느 것을 선택할까요? HTTP 402를 현재 클라이언트에 반환하면, 조건을 읽을 수 있을까요? 아니면 에러로 끝날까요?