미국 자선 기부자 데이터베이스 PatronView의 운영자는 2026년 8월, 150만 개 프로필 페이지를 운영하며 웹 트래픽의 99%가 봇이라고 기록했다. 한 주 동안 서버는 외부 요청 250만 건과 전체 페이지 로드 128만 건을 처리했지만, 자바스크립트 기반 분석 도구 Plausible에 잡힌 페이지뷰는 5,977건이었다. 분석 화면의 방문자 수만 보고 인프라 용량이나 방어 정책을 정하면, 실제 요청의 대부분을 빼고 판단하게 되는 셈이다.
이 사례의 핵심은 봇을 한 덩어리로 보지 않는 데 있다. 검색 유입을 보내는 크롤러, 답변 생성에만 쓰이는 AI 검색 크롤러, 데이터센터에서 실행한 headless Chrome, 가정용 회선을 빌린 프록시 봇넷은 로그에서 남기는 흔적과 막아야 할 이유가 모두 다르다. 운영자는 IP 수보다 서버 로그의 요청 경로·ASN·사용자 에이전트·챌린지 해결률을 함께 보며 규칙을 바꿨다.
분석 도구의 5,977과 서버의 128만은 무엇이 다른가
Plausible 같은 방문 분석은 브라우저가 자바스크립트를 실행해야 페이지뷰로 남는다. 반면 서버 로그에는 HTML을 받아 간 요청, 자바스크립트를 실행하지 않은 크롤러, 캐시에서 처리된 요청까지 남는다. PatronView의 주간 수치에서는 분석 도구의 페이지뷰 1건당 약 214건의 보이지 않는 전체 페이지 로드가 있었다. 봇이 자바스크립트를 실행하면 반대로 분석 지표 자체가 오염될 수도 있다. 실제로 AWS 기반 headless Chrome 트래픽은 방문자처럼 기록되기 시작했다.
따라서 먼저 볼 숫자는 방문자 수가 아니라 서버가 처리한 요청의 구성이다. 같은 URL을 짧은 주기로 다시 읽는지, 특정 국가·클라우드 ASN에 몰리는지, 정적 파일을 제외한 문서 경로만 훑는지에 따라 대응도 달라진다. 이 사이트는 중국의 36만여 IP에서 하루 360만 요청이 온 날을 겪은 뒤 국가·데이터센터·오래된 브라우저 사용자 에이전트·요청 속도를 규칙의 입력값으로 삼았다.
크롤러의 가치는 요청 수가 아니라 유입과 함께 봐야 한다
운영자가 세운 단순한 기준은 ‘크롤링한 페이지 수 ÷ 보내 준 방문자 수’다. Google은 방문자 1명당 46페이지를 읽었고, Bing은 더 많은 페이지를 읽어도 실제 유입이 늘어 허용했다. 반면 6월 한 주 Claude-SearchBot은 420,680페이지를 요청하고 Claude 유입 12명을 보내 35,000페이지 대 1명의 비율을 남겼다. Amzn-SearchBot은 하루 약 117,000건을 읽으면서 사이트 방문자를 보내지 않아 차단 대상이 됐다.
이 비율은 모든 크롤러에 공통의 허용선을 만드는 공식은 아니다. 검색 결과 노출, 답변 인용, 공개 데이터의 재사용처럼 사이트마다 기대하는 교환 가치가 다르기 때문이다. 대신 ‘알려진 봇인가’라는 이름표보다 운영자가 실제로 얻는 유입과 서버가 내는 비용을 같은 기간에 놓고 볼 수 있게 한다. PatronView는 Claude-SearchBot을 방화벽에서 차단한 뒤 하루 약 6만 건이던 요청 시도가 약 25건으로 줄었다고 썼다.
차단보다 챌린지가 맞는 구간을 어떻게 찾았나
IP 차단만으로는 대규모 분산 요청과 residential proxy를 따라가기 어렵다. PatronView는 사람일 가능성이 남는 범위에는 Cloudflare Managed Challenge를 걸고, 선언된 AI 크롤러나 명확한 국가 규칙에는 차단을 적용했다. 요청 속도 규칙도 IP당 10초 30건이라는 단일 기준에만 기대지 않고, 데이터센터 ASN·빈 사용자 에이전트·구형 브라우저를 함께 사용했다.
챌린지 해결률은 오탐을 읽는 실용적인 신호였다. 최근 48시간에 106,437건의 챌린지 중 252건만 성공해 해결률은 0.24%였고, 운영자는 약 0.2%면 봇 가능성이 높다고 봤다. 반대로 해결률이 30%에 가까워지면 사람에게 장벽을 만들고 있다는 신호로 규칙을 손본다. 방어 기능의 성능 비용도 함께 측정했다. Cloudflare JavaScript Detections를 끈 뒤 모바일 Lighthouse 점수가 58에서 99로 오른 사례는, 봇 방어가 정상 사용자의 성능을 더 크게 깎을 수 있음을 보여 준다.
스크래퍼 비용은 청구서보다 먼저 서비스 품질에 나타난다
PatronView는 Cloudflare Workers·D1·KV 캐시를 사용해 요청 하나의 비용을 낮췄지만, 평소 월 약 90달러이던 운영비가 한 번의 급증이 있던 달에는 약 500% 늘었다고 적었다. 더 큰 문제는 캐시 미스가 몰린 날 실제 사용자에게 504 오류가 난 것과, 무엇이 읽히는지 판단할 방문 통계가 흔들린 것이었다. 전통적인 VPS처럼 CPU와 대역폭을 직접 부담하는 구조에서는 같은 요청량이 더 빠르게 생존 문제로 바뀐다.
결론은 모든 자동 접근을 막자는 데 있지 않다. 서버 로그와 분석 도구를 분리해 읽고, 유입을 만드는 크롤러와 일방적으로 비용만 만드는 요청을 구분하며, 차단과 챌린지의 결과를 해결률·성능·오류율로 계속 되먹이는 운영이 필요하다. 운영자가 언급한 요청당 과금 모델은 이런 비용 비대칭을 시장에서 풀려는 시도지만, 그 전까지는 ‘방문자를 전혀 보내지 않는 대량 크롤러’를 식별할 수 있는 로그가 가장 현실적인 출발점이다.
출처: PatronView, “99% of My Website Traffic Is Bots” (2026-08-08 확인)