"내 웹사이트 트래픽의 99%는 봇이다"

• 150만 개 프로필 페이지를 운영하는 PatronView는 한 주 동안 서버가
  250만 건의 외부 요청과 128만 페이지 로드를 처리했지만 분석 도구에는 5,977 pageview만 기록돼, 측정된 1회당 약214회의 보이지 않는 페이지 로드가 발생함 - 봇은 단순한 SEO 크롤러에서 중국의 36만 개 IP를 동원한 대규모 크롤링, AWS/Azure의 headless Chrome, 일반 가정용 회선을 쓰는
  residential proxy botnet으로 진화했고 IP 단위 차단이나 국가/데이터센터 차단만으로는 막기 어려워짐 - 크롤러를 평가하는 기준으로
  크롤링한 페이지 수 / 보내준 방문자 수를 사용했으며, Google은 방문자 1명당 46페이지인 반면 Claude-SearchBot은 35,000페이지, Amzn-SearchBot은 하루 약 117,000페이지를 읽으면서 방문자를 한 명도 보내지 않아 차단함 - Cloudflare WAF에서 국가/UA/ASN/오래된 브라우저/요청 속도를 조합해 차단 또는 Managed Challenge를 적용했으며, 최근 48시간의 CAPTCHA
  106,437건 중 252건만 성공해 0.24% solve rate를 기록함 - 봇이 전체 비용의 99%를 유발하는 상황에서 스크래핑 비용이 방어 비용보다 빠르게 낮아지고 있다고 보고, 최종적으로는 Cloudflare의
  pay-per-crawl처럼 크롤러가 요청 비용을 부담하는 경제적 구조가 필요하며 당장은 "방문자를 전혀 보내지 않는 크롤러는 차단"하는 원칙을 적용함

분석 도구에 보이지 않는 트래픽

• PatronView는 미국의 자선 기부자를 다루는 데이터베이스로, IRS 990 양식/공개 기부자 명단/연례보고서에서 수집한 정보로
  150만 개의 개인 프로필 페이지를 운영함- 사이트 자체도 공개 문서를 스크래핑해 데이터를 구축했기 때문에, 스크래퍼를 막는 입장과 스크래핑으로 서비스를 만든 입장이 공존함

• 글을 발행한 주에 서버는 외부에서 250만 요청을 받고 128만 개의 전체 페이지를 제공했지만, 자체 호스팅 Plausible에는 5,977 pageview만 기록됨

• JavaScript를 실행하는 방문자만 세는 Plausible/Fathom/Google Analytics 같은 분석 도구로는 서버가 실제로 받는 요청 대부분을 볼 수 없음

• 분석 화면상으로는 하루 약 500명이 방문하는 작은 사이트지만 서버에서는 매주 수백만 건의 요청이 처리됨

처음 등장한 봇과 중국발 대규모 크롤링

• 초기에는
  SemrushBot

,AhrefsBot

,MJ12bot

,DataForSEOBot

같은 SEO 크롤러가 모든 페이지를 반복해서 크롤링함robots.txt

와 Cloudflare 보안 규칙을 이용해 이들을 차단하기 시작함

• 2025년 11월에는 며칠 사이 약 4,000명의 비정상적인 "방문자"가 등장함

• 모두 정확히 한 페이지만 방문했고 bounce rate가 99%였으며 referrer가 없었음

• 실제 방문자의 약 10%만 찾는 fund 페이지들만 집중적으로 요청함

• 2026년 4월 22일에는 하루 동안
  360만 건의 요청이 들어옴- 361,844개의 고유 IP에서 발생했고 거의 모두 중국에 위치함

• 첫 10시간 동안 Cloudflare Managed Challenge가 118만 건을 처리했지만 일부 봇은 challenge를 통과함

• 다음 날 중국 전체를 edge에서 차단했고, 이후 유사한 트래픽이 베트남과 싱가포르에서 나타나 이 지역들도 차단함

• 실제 검색 유입은 미국 95.9%, 캐나다 1.3%임

• 같은 문제를 겪는 다른 운영자들도 중국/러시아 등 국가 단위 차단이나 수천 개 residential IP에서 각 IP당 한 번씩 요청하는 패턴을 경험하고 있었음

Claude가 방문자 1명을 보내는 동안 35,000페이지를 읽음

• Cloudflare는 Anthropic 크롤러가 보내주는 방문자 1명당 약 3,000페이지를 크롤링한다고 밝혔지만 PatronView에서 측정한 비율은
  35,000:1이었음 - 6월 한 주 동안
  Claude-SearchBot

이 420,680페이지를 요청했고 Claude에서 유입된 방문자는 12명이었음- 크롤러에는 4.63GB를 전송한 반면 Claude가 보낸 사람들에게 제공된 데이터는 175KB였음

• PatronView 자체는 Claude Code로 만들었고 Cloudflare API 보안 규칙을 다듬는 데도 Claude Code를 사용했지만, 실제 웹사이트 유입에는 기여하지 않는다고 판단해
  Claude-SearchBot

을 방화벽에서 차단함 - 차단 뒤 Claude 요청은 하루 약 60,000건에서 약 25건의 시도로 감소함

• 403 응답을 받은 뒤 크롤링을 멈췄기 때문에 이를 "polite AI companies"의 사례로 봄

크롤러의 가치를 방문자 대비 크롤링 비율로 판단

• 이후 모든 크롤러를
  pages crawled per visitor referred로 평가하기 시작함- Google은 방문자 1명을 보내는 데 46페이지를 크롤링함
• Bing은 Google보다 약 9배 많은 페이지를 읽지만 실제 Bing 유입이 증가하고 있어 허용함

Amzn-SearchBot

은 글 작성 시점에 하루 약117,000 요청으로 가장 활발한 크롤러가 됨- 6월 Claude-SearchBot보다 거의 두 배의 속도임

• Rufus와 Alexa 답변에 사용되기 때문에 PatronView로 웹 방문자를 보내지 않을 것으로 보고 차단함

• Cloudflare AI Crawl Control은
  GPTBot

,ClaudeBot

,CCBot

,Bytespider

같은 선언된 학습용 봇을 별도 규칙보다 먼저 차단함 - 같은 대시보드에서 Bingbot은 158,610회 요청해 방문자 680명을 보내고 있었으며, Anthropic은 자체 차단 후 47회의 요청만 남음

미국 데이터센터를 이용한 headless Chrome

• 7월부터 미국 내 AWS에서 실행되는
  headless Chrome이 대량으로 들어오기 시작함- JavaScript까지 실행해 분석 도구에 실제 방문자인 것처럼 기록됐고 방문자 통계를 오염시킴

• 가장 지속적인 방어 규칙은
  모든 데이터센터 트래픽에 challenge를 거는 것이었음- 실제 방문자는 Comcast/T-Mobile 같은 일반 ISP를 사용한다고 봄

• VPN을 쓰는 사람은 CAPTCHA를 한 번 풀 수 있지만 headless browser fleet에는 장벽이 됨

JavaScript Detections를 끄자 Lighthouse 58 → 99

• Cloudflare의
  JavaScript Detections

가 모든 페이지에 challenge 스크립트를 삽입하고 있었음- 중급 스마트폰 기준
2,875ms를 소비함 - 사이트 자체 JavaScript 실행 시간은 278ms에 불과함

• 모바일 Lighthouse 점수가 58까지 떨어진 가장 큰 원인이었음

• 사용 중인 Cloudflare 요금제에서는 이 기능의 판정 결과를 방화벽 규칙에서도 읽을 수 없었음

• 중급 스마트폰 기준

• 8월 5일 이 기능을 끄자 한 시간 안에
  Lighthouse 99를 기록함 - 그러나 5시간 뒤 Microsoft Azure 기반 스크래퍼가 한 시간 동안 80개 이상의 IP에서 23,000페이지를 읽음

• 각 IP가 개별 rate limit 아래에 머물도록 요청함

• 동시에 Chrome 118~120처럼
  2023년 버전에 고정된 브라우저 UA를 사용하는 residential IP 봇넷도 발견함

Residential proxy botnet의 등장

• Residential botnet은 프록시 업체가 제공하는 수천 개의 실제 가정용 인터넷 연결을 통해 요청을 전달해 각 요청이 일반 사용자 ISP에서 발생한 것처럼 보이게 함

• 2025년 11월에도 같은 형태의 징후가 있었음

• 인도네시아/일본/칠레/브라질/홍콩 등 수십 개 국가에서 거의 동일한 수의 방문자가 같은 날 나타남

• 수천 개의 실제 회선을 빌려주는 proxy network와 일치하는 패턴으로 봄

• 9개월 뒤에는 미국 residential IP에서 같은 패턴이 다시 나타남

• 국가 규칙에도 걸리지 않고 데이터센터 ASN 규칙에도 걸리지 않음

• 대응을 위해 Azure와 다른 주요 클라우드를 데이터센터 challenge 목록에 추가함

• 오래된 브라우저를 challenge하는 규칙도 추가함

• Chrome 100~130과 오래된 Firefox에 CAPTCHA를 적용함

• 실제 검색 방문자 중 해당 구형 브라우저 사용자는 0.54%에 불과했음

• 오래된 운영체제에서 사용되는 Firefox 115 ESR은 예외 처리함

현재 사용하는 Cloudflare WAF 9단계

• Cloudflare Pro 요금제
  월 $25에서 모든 규칙을 운영하며, 동일한 논리는 다른 현대적 방화벽에도 옮길 수 있다고 봄 - 규칙의 순서는 다음과 같음
  중국/베트남 차단- 다른 지역 방문자의 latency에는 영향을 주지 않음

12개 SEO crawler를 User-Agent로 차단- Semrush/Ahrefs/MJ12bot/DotBot/BLEXBot/Barkrowler 등

방문자 대비 크롤링 비율이 나쁜 AI crawler 차단- 현재
Claude-SearchBot

,Amzn-SearchBot

robots.txt

는 읽을 수 있도록 별도 허용함

• 현재
  verified bot은 이후 규칙을 모두 skip- Cloudflare가 Googlebot/Bingbot/Applebot을 검증함
• 차단 규칙 뒤에 배치해 이미 명시적으로 차단한 verified bot은 그대로 차단되지만 Google 같은 허용 봇은 challenge를 받지 않음

북미 이외 모든 대륙에 Managed Challenge- 방문자의 97%가 북미이므로 적용함

• Guam/American Samoa/Northern Mariana Islands는 미국령이어서 예외 처리함

빈 User-Agent에 challenge****46개 데이터센터 ASN에 challenge- AWS/Azure/Google Cloud/Oracle/Alibaba/DigitalOcean/Vultr/Linode/OVH/Hetzner/Hurricane Electric 등

오래된 브라우저에 challenge- Chrome 100130 및 Firefox 100124 일부에 적용

• Firefox 115 ESR은 제외함
• Cloudflare Pro에서는 정규식이 Business 기능이라 55개의
  contains

조건을 직접 나열함

IP당 10초에 페이지 요청 30회를 초과하면 Managed Challenge- 확장자가 없는 페이지 경로만 계산해 이미지/스타일시트 등 정적 파일은 제외함

• Cloudflare 데이터센터별/IP별 카운터라 분산 봇넷은 우회할 수 있음

robots.txt와 실제 Cloudflare 규칙

patronview.com/robots.txt

에서도 12개 SEO crawler와GPTBot

,ClaudeBot

,CCBot

,Bytespider

등 선언된 AI crawler를 차단함- 중국/베트남은 국가 코드로 직접 Block함

(ip.src.country in {"CN"})
(ip.src.country eq "VN")

• AI 검색 crawler는
  /robots.txt

를 제외한 모든 경로에서 차단함

(http.request.uri.path ne "/robots.txt" and
(http.user_agent contains "Claude-SearchBot" or
http.user_agent contains "Amzn-SearchBot"))

• 이후 규칙에서 verified bot을 제외하는 핵심 조건은 다음 하나임

(cf.client.bot)

• 북미 외 지역, 데이터센터 ASN, 빈 User-Agent, 구형 브라우저에는 Block이 아니라
  Managed Challenge를 사용함 - rate limit은 확장자가 없는 요청만 세어 IP당 10초에 30건을 넘을 때 Managed Challenge를 적용함

(http.request.uri.path.extension eq "") and not cf.client.bot

• 비상시 사용할 수 있도록 verified bot을 제외한
  모든 페이지 요청에 Managed Challenge를 거는 panic button규칙도 만들어 두었으나 평소에는 비활성화함- 대규모 스크래핑이 발생하면 켰다가 한 시간 이내에 다시 끔

CAPTCHA solve rate로 오탐 판단

• 최근 48시간 동안 Cloudflare가
  106,437개의 challenge를 발행했고 252개만 성공함- solve rate는 0.24%임

• Singapore에서는 7,089회 challenge 중 3회만 해결됨

• 이 수치를 방어 규칙의 품질을 판단하는 지표로 사용함

• solve rate 약 0.2%라면 거의 봇으로 보고 규칙을 유지함

• 30%라면 실제 사람에게 부담을 주고 있다고 판단해 규칙을 수정함

비용보다 더 큰 문제는 통계 오염

• 사이트는 Cloudflare Workers/D1/KV cache를 이용해 edge에서 실행함

• 대부분의 봇 요청이 캐시에 적중해 요청 하나당 비용은 매우 작음

• 평소 전체 운영비는 월 약
  $90 - 한 번의 심한 스파이크가 있었던 달에는 약 500% 증가함

• 전체 비용의 99%를 봇이 발생시키지만 비용은 사이트 운영자가 모두 부담함

• 직접적인 비용보다 더 심각했던 문제는 두 가지였음

• 봇이 visitor analytics를 오염시켜 실제 사람들이 무엇을 읽는지 신뢰할 수 없게 됨

• Azure burst의 cache miss가 쌓였던 어느 날에는 실제 사용자에게 504 오류가 발생함

• CPU와 bandwidth를 직접 부담하는 전통적인 VPS였다면 매주 수백만 요청 중 99% 이상이 봇인 상황이 생존에 영향을 줄 수 있지만, edge 플랫폼에서는 상대적으로 nuisance에 머물렀음

같은 문제를 겪는 사이트에 권하는 대응

visitor analytics가 아니라 server log를 확인- 분석 도구에는 실제 트래픽의 0.5%도 보이지 않을 수 있음

IP보다 ASN으로 차단- IP는 계속 바뀌지만 네트워크는 상대적으로 고정됨

• 사람이 포함될 수 있는 범위에서는
  block보다 challenge- 실제 사용자는 Managed Challenge를 대부분 눈치채지 않고 통과할 수 있으며 solve rate 측정도 가능함

challenge solve rate를 모니터링- 약 0.2%면 봇 가능성이 높고 30%면 실제 사용자에게 부담을 주고 있을 가능성이 큼

보안 기능 자체의 성능 비용도 측정- Cloudflare CAPTCHA 스크립트가 사이트 전체 JavaScript보다 훨씬 비쌌던 사례처럼 방어 기능이 서비스 성능을 더 크게 떨어뜨릴 수 있음

현재 효과와 남아 있는 한계

• 최종 규칙을 완성한 뒤 24시간 동안 Cloudflare가
  46,729개 요청을 직접 차단함- 그중 43,150개가 이틀 전에 차단한 Amazon crawler였음

• 같은 기간 63,969회의 challenge를 발행했고 552회만 해결됨

• Google/Bing/DuckDuckGo처럼 방문자를 보내주는 crawler는 계속 허용하면서 데이터를 대량으로 가져가기만 하는 crawler는 막고 싶지만,
  residential botnet은 실제 브라우저/실제 네트워크와 거의 동일하게 보여 네트워크 계층에서 완벽하게 차단하기 어려움 - 몇 주마다 새로운 형태의 scraper가 나타나 지속적으로 규칙을 수정해야 하는 whack-a-mole 상태가 이어짐

스크래핑 문제의 경제적 해법

• 스크래핑이 계속 심해지는 이유를
  스크래퍼의 비용이 방어 비용보다 빠르게 낮아진 비대칭 구조에서 찾음 - Cloudflare가 개발 중인 pay-per-crawl은 edge에서 crawler에게 요청당 비용을 부과하는 방식임

• Amazon이 매달 읽는 약 350만 페이지에 적절한 가격을 지불한다면 데이터를 제공할 의향이 있음

• 이런 시장이 생기기 전까지 적용할 운영 원칙은 단순함
  "방문자를 한 명도 보내지 않는 crawler는 차단함"