
3줄 요약
- Cloudflare가 자사 뒤에 있는 모든 자산(웹 페이지·데이터셋·API·MCP 툴)에 과금할 수 있는 Monetization Gateway의 대기자 명단을 열었다. 2026년 7월 1일 발표.
- 광고와 구독으로 굴러온 지난 30년의 웹 비즈니스 모델이 에이전트 시대에 무너지고 있다는 진단이 출발점이다. 에이전트는 광고를 보지도, 월 구독을 유지하지도 않고 페이지를 한 번 읽고 필요한 것만 가져간 뒤 떠난다.
- 대안은 모든 것에 대한 사용량 기반 과금이다. 정산은 오픈 프로토콜 x402와 스테이블코인으로 이뤄져, 판매자가 자체 결제 스택을 만들 필요가 없다.
웹의 비즈니스 모델이 바뀌고 있다
지난 30년간 웹은 단순한 경제적 거래로 돌아갔다. 콘텐츠를 내주고 사람의 주의(attention)를 받는 거래다. 그 주의는 광고, 구독, 이커머스로 수익화됐고, 이 거래가 우리가 아는 인터넷을 먹여 살렸다.
하지만 에이전트가 인터넷의 지배적 사용자가 되면서 이 모델이 깨지고 있다. 에이전트는 광고를 보지 않고, 쓰고 싶은 모든 도구에 월 구독을 유지하지도 않는다. 페이지나 데이터 피드를 한 번 읽고 필요한 것만 취한 뒤 이동한다. Cloudflare에 따르면 AI 크롤러는 이미 방문자 한 명을 돌려보낼 때마다 콘텐츠를 100번에서 수만 번까지 요청하고 있다.
이 현실이 요구하는 새 모델은 모든 것에 대한 사용량 기반 가격 책정이다. 주의와 이커머스가 웹사이트에서 AI 하네스와 AI가 작성한 소프트웨어로 옮겨간다면, 에이전트는 자신이 필요로 하는 입력(학습 데이터, 추론용 콘텐츠, 개발자 도구, API 사용)에 값을 치러야 한다. 소프트웨어의 자연스러운 결제 단위는 좌석이나 한 달이 아니라 요청, 토큰, 결과다. 글은 이런 예시를 든다.
- 웹 검색 1건당 몇 센트, 호출당 청구
- 업로드 엔드포인트에 기본요금 $0.001 + MB당 $0.01
- 해결된 지원 에스컬레이션 1건당 $0.99, 작업이 성공했을 때만 지불
인터넷의 일부는 이미 이렇게 굴러간다. 클라우드와 API는 오랫동안 호출당·시간당 팔려 왔다. 다만 알려진 구매자에게만 그랬다. 사용자가 가입하고, API 키를 발급받고, 사용량 기반 미터링 청구를 받는 식이다. 콘텐츠는 대체로 결제를 건너뛰고 광고에 기댔다. 기존 결제 레일은 검증되지 않은 구매자의 1센트 미만 거래를 감당한 적이 없다. 비용이 너무 크고 정산이 너무 느렸기 때문이다. 일정 금액 밑으로는 결제를 걷는 비용이 결제액보다 컸다.
역사적으로 사용량 기반 청구는 구현이 어려웠다. 기업이 사실상 결제 회사가 되어, 내부 사용량을 견고하고 감사 가능하게 추적하는 자체 회계를 돌려야 했다. 이 추적에는 백엔드 시스템의 대규모 개편이 필요했다. 많은 곳이 대신 좌석당 과금을 택했다. 더 단순하고 종종 더 수익성이 좋았기 때문이다.
에이전트가 이 역학을 뒤집는다. 에이전트 하나가 팀 전체의 일을 24시간 해낼 수 있어, 실제 소비와 무관한 일회성 정액 요금이 어색해진다. 동시에 에이전트는 마찰 없이 수천 건의 소액결제를 할 수 있는 반면, 사람에게 매 결제를 승인하라고 하는 것은 감당 불가능한 부담이다. 사용량 기반 가격대가 바로 에이전트가 사는 곳이고, 스테이블코인 소액결제가 빛나는 지점이다. Open USD나 USDC 같은 스테이블코인은 아주 작은 금액을 인터넷 너머로 옮기면서 수수료가 거의 없고 1초 안에 정산된다. 오늘날 다른 결제 레일로는 불가능한 일이다.
여기서 Cloudflare가 개입한다. Cloudflare는 자사 청구 시스템과 고객 분석을 위해 수년간 사용량 기반 회계를 구축해 왔다. 구매자와 판매자 사이의 프록시 계층이라는 위치 덕분에, 웹 자산의 사용량 기반 청구 구현을 크게 단순화할 수 있다는 것이다. Cloudflare가 사용량 기반 청구를 지원하면 결제의 증거가 요청 자체 안으로 들어가고, 결제 검증 경로와 요청 경로가 하나로 합쳐진다.
판매자에게 돌아오는 이점은 이렇다. 미터링, 결제 교환, 정산이 origin 서버에서 떨어져 나간다. 판매자에게 남는 것은 정작 중요한 것, 즉 규칙과 가격과 매출이다. 구매자를 온보딩하거나 청구 시스템을 세울 필요 없이, 규칙 하나만 쓰면 에이전트 구매자가 자신이 쓴 만큼 값을 치른다.
x402 다시 보기
작년 Content Independence Day에 Cloudflare는 사이트 소유자에게 어떤 AI 크롤러가 콘텐츠에 접근할지 원클릭으로 통제하는 기능을 줬고, Pay Per Crawl로는 크롤러에게 콘텐츠 값을 청구하게 했다. Monetization Gateway는 그다음 걸음이다. 크롤러에게 콘텐츠만 청구하는 데서 나아가, 어떤 호출자에게든 어떤 리소스든(API, 데이터, MCP 툴 호출까지) 청구할 수 있고, 결제 기계장치를 직접 만들 필요가 없다.
x402는 HTTP 위에서 결제를 가능하게 하는 오픈 프로토콜이다. 마침내 쓰임을 찾은 402 상태 코드에서 이름을 따왔다. 교환 방식은 단순하다.
클라이언트가 결제 게이트가 걸린 리소스를 요청한다. 서버는 그것을 내주는 대신
402 Payment Required와 함께 가격·허용 자산·결제처를 담은 작은 페이로드로 응답한다. 클라이언트는 값을 치르고 결제 증명을 붙여 요청을 반복한다. 퍼실리테이터가 검증하면 서버가 리소스를 돌려준다.
이 모든 게 평범한 HTTP 요청과 응답 안에서 일어난다. 체크아웃 페이지로의 리다이렉트도, 따로 호출할 결제 API도 없다. 정산은 P2P로 이뤄져, 구매자가 판매자에게 보낸 자금이 판매자 지갑에 곧바로 입금된다. Cloudflare는 Monetization Gateway를 결제 오버헤드가 낮게, 1초 미만 정산을 목표로 설계하고 있다.
x402를 기계 결제에 잘 맞게 하는 성질은 두 가지다. 하나는 결제 금액이 1센트의 분수까지 작아질 수 있다는 것이다. 프로토콜이 오버헤드를 거의 더하지 않기 때문이다. 다른 하나는 구매자가 판매자와 계정을 만들 필요가 없다는 것이다. 결제 자체가 자격증명이기 때문이다. x402는 레일에 구애받지 않지만, 1초 미만에 1센트의 분수로 정산되고 차지백이 없는 스테이블코인과 자연스럽게 어울린다.
Monetization Gateway가 하는 일
Monetization Gateway는 유연한 결제 규칙 API를 제공한다. 호출자가 언제 디지털 리소스에 접근하기 위해 값을 치러야 하는지를 판매자가 정확히 표현하게 해 준다.
토큰, API, MCP 툴 호출, 데이터는 이미 그 경로를 통과한다. 판매자는 원하는 만큼 정밀하게 어떤 트래픽이 값을 치러야 하는지 정하고, Cloudflare의 다른 규칙에 쓰는 것과 비슷한 표현식(expression)을 전용 제품 API에 작성해 그 결정을 집행한다. 게이트웨이는 330개 이상 도시의 Cloudflare 글로벌 네트워크 위에서 동작하므로, x402 핸드셰이크가 구매자 근처에서 일어나 요청 지연을 줄이고 origin을 보호한다.
계획된 기능의 예시는 이렇다.
| 기능 | 예시 |
|---|---|
| 특정 REST 동사에 과금 | /api/premium/*로 가는 모든 GET·POST에 $0.01 |
| 가변 가격 | 이미지 생성처럼 복잡도가 다른 작업에 최대 $2까지, 소비한 컴퓨트에 따라 차등 |
| 미인증 호출자에만 과금 | origin의 401 Unauthorized 응답을 가로채 가격·결제 안내와 함께 402 Payment Required로 대체 |
요청이 규칙에 걸리면 게이트웨이는 통과시키기 전에 결제를 검증한다. 규칙은 대시보드에서 설정하거나 Cloudflare API·Terraform으로 코드처럼 관리할 수 있어, 유료 엔드포인트가 인프라 설정의 또 다른 일부가 된다.
초기에는 스테이블코인 결제만 지원한다. 판매자는 모은 스테이블코인을 자신의 거래에 쓰거나, 은행 계좌로 상응하는 법정화폐로 상환할 수 있다. 게이트웨이의 이점은 제품의 도달 가능 시장을 넓히는 데 있다. 에이전트가 리소스를 요청하면 가격을 안내받고, 값을 치르고, 응답을 받는다. 가입도, API 키도, 사전 관계도 필요 없다. 구매자에 대해 얼마나 알아야 하는지는 판매자가 정한다. 필요하면 에이전트에게 Web Bot Auth로 인증을 요구하고, 이미 보유한 계정에 사용량 기반 가격을 적용할 수도 있다.
어디로 가는가
게이트웨이는 요청을 결제로 바꿔 Cloudflare 고객에게 새 매출 기회를 준다. 하지만 이 흐름이 향하는 곳은 훨씬 크다.
에이전트는 사용자를 대신해 자율적으로 행동하는 소프트웨어이고, 이제 스스로 행동하기 시작했다. 머지않아 에이전트는 지갑을 지니고 사람이 개입하지 않은 채 필요한 것(데이터셋, API 호출, 툴, 컴퓨트 블록)을 사게 된다. 그중 일부는 무료지만, 일부는 검증된 에이전트 신원을 통해 그 에이전트가 누구이며 누구를 위해 행동하는지 증명해야 한다. 상당수는 신원과 결제를 모두 요구하는데, Cloudflare는 origin이 호출을 보기도 전에 에이전트를 검증하고, 규칙을 적용하고, 결제를 확인하는 이 모두를 하나의 요청 안에서 정산할 수 있는 몇 안 되는 곳이라고 자평한다. 에이전트가 인터넷의 주 구매자가 되고, 요청이 곧 거래가 된다.
오늘날 인터넷에는 수익화되지 않거나 덜 수익화된 채 오가는 가치가 엄청나게 많다. 아무도 값을 치르지 않을 것이어서가 아니라, 그것에 청구할 도구가 존재한 적이 없었기 때문이다. 에이전트가 하는 유용한 API 호출 하나하나, 답변 하나하나, 툴 호출 하나하나에 가치가 있지만 오늘 그 대부분은 값이 매겨지지 않는다.
가장 흥미로운 지점
내가 곱씹은 대목은 “결제의 증거가 요청 자체 안으로 들어가, 결제 검증 경로와 요청 경로가 하나로 합쳐진다"는 문장이다. 지금까지 결제는 늘 콘텐츠 흐름 바깥에 있었다. 체크아웃 페이지로 리다이렉트되고, 별도 결제 API를 호출하고, 웹훅으로 결과를 받는 식으로 요청과 결제가 분리돼 있었다. 402 상태 코드를 되살려 그 둘을 한 HTTP 왕복 안에 합치겠다는 발상은, 웹이 처음 설계될 때 비워 둔 자리(예약만 되고 쓰이지 않던 402 Payment Required)를 30년 만에 채워 넣는 셈이다.
또 하나 눈여겨본 것은 좌석당 과금에서 사용량 기반 과금으로의 전환을 에이전트가 강제한다는 진단이다. 그동안 사용량 기반 청구가 기술적으로 가능했는데도 많은 기업이 좌석당 과금을 택한 것은, 단지 그게 더 단순하고 수익성이 좋았기 때문이었다. 그런데 에이전트 하나가 팀 전체의 일을 하는 순간 좌석이라는 단위 자체가 무의미해진다. 기술이 아니라 구매자의 성격 변화가 과금 모델을 밀어낸다는 관점이 인상 깊다. 다만 이 그림 전체가 스테이블코인 정산을 전제로 한다는 점은 짚어 둘 만하다. 규제와 지갑 인프라, 검증된 에이전트 신원 같은 조각이 함께 자리 잡아야 완성되는 청사진이고, 지금은 대기자 명단을 여는 발표 단계다.
출처
Cloudflare Blog — Rohin Lohe, Justin Ridgely, Will Papper. 2026년 7월 1일 발행. 원문: https://blog.cloudflare.com/monetization-gateway/
