AI 크롤러에게 통행료 받기: Cloudflare Pay Per Crawl
혹시 여러분이 운영하는 웹사이트의 서버 로그에서 AI 크롤러가 하루에 몇 번이나 다녀가는지 확인해보신 적 있나요? 저는 개인 블로그의 로그를 살펴보다가 GPTBot, ClaudeBot, Bytespider 같은 봇들이 사람 방문자 못지않게 부지런히 드나드는 걸 보고 묘한 기분이 들었습니다. 제 글이 AI 모델의 학습 자료나 답변 재료로 쓰일 수 있는데, 그 사용 조건은 제가 정할 수 없으니까요.
웹에는 오랫동안 콘텐츠를 무료로 공개하는 대신 트래픽과 인용으로 보상받는 암묵적인 상생 구조가 있었습니다. 하지만 AI 크롤러는 이 구조를 흔들어 놓았죠. 그동안 창작자가 쓸 수 있는 카드는 사실상 두 장뿐이었습니다. robots.txt로 크롤러를 차단하거나, 아니면 그냥 무료로 열어두거나.
Cloudflare가 2025년 7월에 발표한 Pay Per Crawl은 여기에 세 번째 카드를 추가했습니다. 크롤러에게 돈을 받고 콘텐츠를 내어주는 것이죠. 이 글에서는 Pay Per Crawl이 처음 어떤 원리로 출발했고, 2026년 7월 현재 이 실험이 어디까지 왔는지 살펴보겠습니다.
Pay Per Crawl이란?
Pay Per Crawl은 콘텐츠 소유자가 AI 크롤러의 페이지 접근에 요금을 부과할 수 있게 해주는 Cloudflare의 기능입니다. 사이트 운영자는 크롤러별로 허용(Allow), 과금(Charge), 차단(Block) 중 하나를 선택할 수 있는데요. 무료로 열어줄 크롤러는 허용하고, 돈을 내야만 들어올 수 있는 크롤러에게는 요금을 매기고, 아예 들이고 싶지 않은 크롤러는 차단하는 식입니다.
발표 방식부터 심상치 않았습니다. Cloudflare는 2025년 7월 1일을 “콘텐츠 독립기념일(Content Independence Day)“이라고 부르면서, 같은 날부터 신규 고객의 사이트에서 AI 크롤러를 기본으로 차단하도록 정책을 뒤집었습니다. 크롤러가 콘텐츠에 접근하려면 먼저 허락을 구해야 하는 구조로 바꾸고, 그 위에 결제라는 협상 수단을 얹은 셈이죠.
물론 대형 언론사라면 AI 회사와 직접 라이선스 계약을 맺을 수 있습니다. 실제로 그런 계약이 여럿 성사되기도 했고요. 문제는 저 같은 개인 블로거나 중소 규모 사이트인데요. 개별 협상은 꿈도 못 꾸는 작은 창작자에게 Cloudflare라는 중개자가 표준화된 과금 창구를 열어주는 셈이니, Pay Per Crawl이 제 눈에 그저 신기능 하나로 보이지 않는 이유입니다.
30년 만에 소환된 HTTP 402
Pay Per Crawl의 기술적인 토대는 뜻밖에도 아주 오래된 표준입니다. 바로 402 Payment Required 상태 코드인데요. 웹 개발자를 위한 HTTP 상태 코드 안내서에서 다뤘던 404나 500과 달리, 402는 실무에서 마주칠 일이 거의 없는 코드였습니다.
402는 1990년대 HTTP 초안 시절부터 “디지털 결제가 언젠가 웹의 일부가 될 것”이라는 기대를 담아 자리를 잡아둔 코드입니다. 하지만 소액 결제(micropayment) 인프라가 끝내 대중화되지 않으면서, 최신 HTTP 명세인 RFC 9110에서도 여전히 “향후 사용을 위해 예약(reserved for future use)“된 상태로 남아 있었죠. 30년 가까이 이름만 있고 쓰임새는 없던 코드가 AI 크롤러 과금이라는 용도로 드디어 출근하게 된 것입니다.
Cloudflare를 거치는 요청에서 Pay Per Crawl이 활성화되어 있으면, 결제 의사가 없는 크롤러는 콘텐츠 대신 이런 응답을 받게 됩니다.
HTTP/1.1 402 Payment Required
crawler-price: USD 0.01crawler-price 헤더에 담긴 가격이 바로 이 사이트가 크롤링 한 건에 매긴 요금입니다.
크롤러가 결제하는 두 가지 방법
그렇다면 크롤러는 어떻게 요금을 내고 콘텐츠를 가져갈까요? Pay Per Crawl은 두 가지 흐름을 제공합니다.
첫 번째는 가격을 먼저 확인하는 반응형 흐름입니다. 크롤러가 평소처럼 페이지를 요청하면 위에서 본 402 응답으로 가격을 통보받는데요. 그 가격을 받아들이기로 했다면 crawler-exact-price 헤더에 동의한 금액을 담아 다시 요청합니다.
GET /example.html HTTP/1.1
Host: example.com
User-Agent: ExampleBot/1.0
crawler-exact-price: USD 0.01서버가 요청을 수락하면 콘텐츠와 함께 결제가 확정되었다는 표시가 돌아옵니다.
HTTP/1.1 200 OK
crawler-charged: USD 0.01
<!doctype html>
...두 번째는 결제 의사를 먼저 밝히는 선제형 흐름입니다. 크롤러가 첫 요청부터 crawler-max-price 헤더로 “이 금액까지는 낼 용의가 있다”고 선언하는 방식인데요. 사이트가 매긴 가격이 그 한도 이하라면 402를 거치지 않고 바로 콘텐츠를 받으면서 crawler-charged 헤더로 실제 청구 금액을 확인하게 됩니다. 왕복 횟수가 줄어들기 때문에 대량 크롤링에는 이쪽이 효율적이겠죠.
이 방식의 묘미는 가격 협상이 HTTP 헤더라는 표준 인프라 위에서 기계끼리 자동으로 이뤄진다는 데 있습니다. 사람이 계약서에 도장을 찍는 대신, 요청과 응답이 오가는 몇 밀리초 사이에 흥정이 끝나는 셈이죠.
아무 봇이나 결제할 수는 없다
여기서 한 가지 의문이 생깁니다. User-Agent는 누구나 마음대로 위조할 수 있는데, 결제 주체를 어떻게 믿을 수 있을까요? 돈이 오가는 시스템이니 신원 보장이 필수인데 말이죠.
Pay Per Crawl은 이 문제를 Web Bot Auth라는 봇 인증 표준으로 풉니다. 결제에 참여하려는 크롤러는 먼저 Ed25519 키 쌍을 만들고 공개 키를 Cloudflare에 등록해야 하는데요. 이후 모든 요청에 개인 키로 생성한 서명을 첨부합니다. 서명 방식은 RFC 9421로 표준화된 HTTP 메시지 서명(HTTP Message Signatures)을 따릅니다.
GET /example.html HTTP/1.1
Host: example.com
User-Agent: ExampleBot/1.0
Signature-Agent: "https://examplebot.com"
Signature-Input: sig1=("@authority" "signature-agent");created=1719791475;keyid="ba3e64==";alg="ed25519";nonce="e8N7S2MFd/qrd6T2R3tdfAuuANngKI7LFtKYI/vowzk4lAZYadIX6wW25MwG7DCT9RUKAJ0qVkU0mEeLElW1qg==";tag="web-bot-auth"
Signature: sig1=:jdq0SqOwHdyHr9+r5jw3iYZH6aNGKijYp/EstF4RQTQdi5N5YYKrD+mCT1HA1nZDsi6nJKuHxUi/5Syp3rLWBA==:서명 검증에 실패한 요청은 애초에 결제 협상 대상이 되지 못합니다. 덕분에 어떤 봇이 유명 크롤러를 사칭해서 남의 이름으로 요금을 떠넘기는 일도, 반대로 사이트가 엉뚱한 상대에게 요금을 청구하는 일도 막을 수 있습니다.
콘텐츠 소유자 관점에서 본 동작 방식
사이트 운영자 입장에서 설정은 단순합니다. 가격은 존(zone) 단위, 그러니까 도메인 전체에 하나의 균일 요금으로 매기고, 크롤러마다 허용, 과금, 차단 중 하나를 지정하면 됩니다. 특정 크롤러와 별도 제휴를 맺었다면 그 크롤러만 무료로 풀어주는 것도 가능하고요.
Pay Per Crawl은 웹 애플리케이션 방화벽(WAF)과 봇 관리 규칙이 모두 적용된 다음에 동작합니다. 다시 말해 보안 규칙으로 차단된 크롤러는 아무리 지갑을 열어도 콘텐츠에 접근할 수 없습니다. 돈으로 방화벽을 뚫을 수는 없다는 원칙이죠.
정산은 Cloudflare가 기록상 판매자(Merchant of Record) 역할을 맡아 처리합니다. 인증된 크롤러가 결제 의사를 밝힌 요청에 200 응답이 나갈 때마다 과금 이벤트가 기록되고, Cloudflare가 이를 집계해서 크롤러 운영사에 청구한 뒤 콘텐츠 소유자에게 수익을 분배합니다. 창작자가 AI 회사 수십 곳과 개별 정산할 필요 없이 Cloudflare 한 곳만 상대하면 되는 구조입니다.
다만 아직은 누구나 쓸 수 있는 기능이 아닙니다. 2026년 7월 현재도 Pay Per Crawl은 비공개 베타 상태이고, 참여하려면 대기 명단에 등록하거나 Cloudflare 계정 담당자에게 문의해야 합니다.
1년 뒤, 크롤링당 과금의 한계
그사이 Cloudflare의 실험은 한 걸음 더 나아갔습니다. 발표 1주년인 2026년 7월 1일, Cloudflare는 크롤링당 과금 모델의 한계를 스스로 짚으면서 사용량 기반 과금(pay per use)이라는 후속 모델을 공개했는데요.
문제의식은 이렇습니다. Cloudflare의 관측에 따르면 AI 봇 크롤링의 절반 이상이 변경되지 않은 페이지를 다시 가져가는 요청이라고 합니다. 반대로 어떤 페이지는 한 번만 크롤링되고도 수천 개의 AI 답변에 인용되죠. 크롤링 횟수와 콘텐츠가 만들어내는 실제 가치가 어긋나 있으니, 크롤링 시점이 아니라 콘텐츠가 AI 답변에 실제로 쓰이는 시점에 정산하자는 것입니다.
이를 위해 Cloudflare는 결제를 담당하는 Monetization Gateway를 출시하고 두 파트너와 실험을 시작했습니다. Ceramic.ai와 제휴한 콘텐츠 소유자는 자신의 콘텐츠가 AI 검색 결과에 노출될 때마다 보상을 받고, 어떤 질의에서 어떤 대목이 인용됐는지 리포트도 받아볼 수 있습니다. You.com과의 제휴에서는 AI 에이전트가 유료 콘텐츠를 건별로 구매해서 읽어가는 방식을 실험하고 있고요.
봇을 바라보는 관점도 정교해졌습니다. 이제 AI 봇을 검색, 에이전트, 학습 세 범주로 나눠 각각 따로 제어할 수 있는데요. 2026년 9월 15일부터는 광고가 실린 페이지에서 학습 봇과 에이전트 봇이 기본으로 차단됩니다. 광고는 사람이 방문하기를 의도했다는 신호이니, 그 지면의 사람 트래픽을 우선 보호하겠다는 논리입니다. 여기에 2025년 9월 발표한 콘텐츠 신호 정책까지 포함하면 접근 제어, 사용 조건, 과금이라는 세 축이 맞물려 돌아가는 그림이 완성됩니다.
주의할 점은 사용량 기반 과금이 Pay Per Crawl을 대체하는 게 아니라 보완한다는 것입니다. Cloudflare 스스로도 어떤 과금 모델이 정답인지 아직 모른다는 입장이고, 여러 모델을 동시에 실험하면서 연말까지 적용 범위를 넓혀가겠다고 밝혔습니다.
한 가지 더 눈여겨볼 변화는 이 과금 방식이 Cloudflare 울타리 밖으로 나가고 있다는 점입니다. AI 에이전트 결제 표준인 x402에 cloudflare:402라는 네트워크와 크롤링 요금을 모아서 정산하는 스킴이 정식으로 등록되어 있거든요. 크롤러 입장에서는 Cloudflare 전용 헤더를 따로 익히지 않고도 다른 사이트에 값을 치르던 것과 같은 방식으로 결제할 수 있게 되는 셈입니다.
마치며
지금까지 Cloudflare Pay Per Crawl의 동작 원리와 1년간의 진화 과정을 살펴봤습니다. 30년 가까이 예약석으로만 남아 있던 402 상태 코드가 부활하고, HTTP 헤더 위에서 기계끼리 가격을 흥정하고, 암호학적 서명으로 결제 주체를 검증하는 이 모든 설계가 새로운 프로토콜이 아니라 기존 웹 표준의 조합 위에 세워졌다는 점이 저는 특히 인상적이었습니다.
개인 블로거로서는 이 실험이 반갑습니다. 차단과 무료 개방 사이에서 양자택일을 강요받던 창작자에게 협상이라는 선택지가 생겼으니까요. 그렇다고 장밋빛 전망만 하기에는 이릅니다. 아직 비공개 베타인 데다 참여하는 크롤러도 제한적이고, 크롤링당 과금과 사용량 기반 과금 중 무엇이 살아남을지도 알 수 없거든요. 그래도 콘텐츠에 값을 매기는 인프라가 웹 표준 위에서 자라나기 시작했다는 사실만큼은 분명해 보입니다. AI 시대의 웹이 창작자에게도 지속 가능한 공간으로 남으려면, 이런 시도가 더 많아져야 하지 않을까요?
더 자세한 내용은 Cloudflare의 Pay Per Crawl 발표 원문과 AI Crawl Control 공식 문서를 참고하세요.
This work is licensed under CC BY 4.0
