필사 모드: 방문자 통계로는 트래픽의 0.5퍼센트만 보인다 — 봇 방어는 자기 신고가 아니라 출처로 한다

• 들어가며 — 대시보드에 보이지 않는 99퍼센트
• 자바스크립트 분석 도구는 봇을 셀 수 없다
• 크롤당 유입 비율 — 판단을 하나의 숫자로 압축하기
• 공개된 비율과 내 사이트의 비율이 다른 이유
• 자기 신고를 믿는 규칙과 출처를 보는 규칙
• 주거용 IP 봇넷 앞에서 출처 규칙도 무력해진다
• 방어 장치 자체의 비용을 재라
• 작업 증명은 무엇을 해결하고 무엇을 해결하지 못하나
• 참고 자료

들어가며 — 대시보드에 보이지 않는 99퍼센트

2026년 8월 7일 PatronView라는 사이트의 운영자가 1년간의 스크레이퍼 방어 기록을 공개했습니다. 미국 자선 기부자 데이터베이스로, IRS 990 서류와 공개 기부자 명단을 바탕으로 만든 개인 프로필 페이지가 150만 개 있습니다.

글이 공개된 주에 서버는 외부로부터 요청 250만 건을 받았고 완전한 페이지 128만 개를 서빙했습니다. 그런데 방문자 통계에는 페이지뷰 5,977건만 기록되어 있었습니다.

보이는 페이지 로드 하나당 보이지 않는 것이 약 214개 있었다는 뜻입니다.

여기서 배울 것은 봇이 많다는 사실이 아닙니다. 봇이 많다는 것은 다들 압니다. 배울 것은 여러분이 지금 보고 있는 지표가 이 상황을 구조적으로 보여 줄 수 없다는 점입니다.

자바스크립트 분석 도구는 봇을 셀 수 없다

원인은 단순합니다. Plausible, Fathom, Google Analytics를 포함해 클라이언트 사이드 분석 도구는 자바스크립트를 실행하는 방문자만 셉니다. 대부분의 봇은 자바스크립트를 실행하지 않습니다.

그래서 대시보드는 하루 방문자 500명 정도의 아담한 사이트를 보여 주고, 서버는 매주 수백만 건을 답합니다. 두 숫자가 모두 참입니다. 서로 다른 것을 세고 있을 뿐입니다.

실무적 결론은 하나입니다. 봇 트래픽을 판단할 때는 분석 도구가 아니라 서버 로그나 엣지 로그를 봐야 합니다. 그리고 이 둘의 차이를 정기적으로 확인해야 합니다. 차이가 벌어지기 시작하는 시점이 곧 뭔가 시작된 시점입니다.

원문의 첫 번째 봇 감지 사례가 정확히 그런 식이었습니다. 2025년 11월, 며칠에 걸쳐 4,000명의 "방문자"가 나타났습니다. 각각 정확히 한 페이지만 보고, 이탈률 99퍼센트, 레퍼러 없음. 그리고 실제 방문자의 10퍼센트만 보는 특정 유형의 페이지만 훑고 있었습니다.

이 신호들 중 어느 하나도 결정적이지 않지만 함께 나타나면 명확합니다. 그리고 이 신호들은 분석 도구에서도 볼 수 있는 것들입니다. 자바스크립트를 실행하는 봇이었기 때문입니다.

크롤당 유입 비율 — 판단을 하나의 숫자로 압축하기

원문에서 가장 실용적인 부분은 저자가 정착한 지표입니다. 크롤러가 페이지를 몇 개 읽을 때마다 방문자 한 명을 보내 주는가.

저자가 측정한 값은 이렇습니다.

Claude 쪽 근거가 구체적입니다. 어느 한 주에 Claude-SearchBot이 420,680페이지를 요청했고, 같은 주에 실제 사람이 페이지를 요청할 때 쓰이는 별도 사용자 에이전트인 Claude-User를 통해 들어온 방문자는 12명이었습니다. 대역폭으로 보면 봇에게 4.63GB, 그 봇이 보내 준 사람들에게 175KB였습니다.

Amazon 쪽은 하루 약 117,000건으로 그 시점 1위 크롤러였고 방문자는 한 명도 보내지 않았습니다.

이 지표의 좋은 점은 정책 판단을 도덕이 아니라 산수로 만든다는 것입니다. "AI 크롤러는 나쁘다"가 아니라 "이 크롤러는 내 대역폭을 쓰면서 아무것도 돌려주지 않는다"입니다. Bingbot은 406대 1로 Google보다 아홉 배 나쁘지만 유입이 실제로 늘고 있어서 계속 허용한다고 저자는 씁니다. 같은 기준을 적용해서 결론이 갈리는 것이 좋은 기준의 증거입니다.

차단 후 관찰도 기록해 둘 만합니다. Claude-SearchBot을 방화벽에서 막자 하루 6만 건이던 요청이 하루 25건 정도의 시도로 떨어졌습니다. 저자의 표현으로 "예의 바른 AI 회사들은 정말로 403을 받아들입니다."

공개된 비율과 내 사이트의 비율이 다른 이유

저자는 "Cloudflare가 Anthropic 크롤러를 크롤 약 3,000건당 방문자 1명 정도로 말했다"고 인용하면서 자기 사이트에서는 35,000대 1을 측정했다고 씁니다.

이 두 숫자가 다른 이유를 아는 것이 중요합니다.

Cloudflare가 이 지표를 처음 공개한 글은 2025년 7월 1일자이고, 계산 방식을 명시합니다. 해당 플랫폼과 연관된 사용자 에이전트에서 온 요청 중 응답의 콘텐츠 타입이 HTML인 것의 총합을, 그 플랫폼에서 온 유입 트래픽으로 나눈 값입니다. 당시 2025년 6월 19일부터 26일까지 구간에서 Anthropic은 70,900대 1로 보고되었습니다.

같은 글에 Cloudflare 스스로 붙인 단서가 있습니다. Claude 네이티브 앱이 보내는 유입 트래픽에는 레퍼러 헤더가 없고, 다른 네이티브 앱도 마찬가지일 가능성이 높다는 것입니다. 그래서 자기들의 계산이 "해당 비율을 과대평가할 수 있으며 얼마나 그런지는 불분명하다"고 적습니다.

여기서 세 가지가 따라옵니다.

첫째, 이 비율은 시점에 따라 크게 움직입니다. 70,900, 3,000, 35,000이 모두 서로 다른 시점과 서로 다른 모집단의 값입니다. 어느 하나를 "AI 크롤러의 비율"로 인용하면 틀립니다.

둘째, 집계값보다 자기 사이트 값이 중요합니다. 여러분 사이트의 콘텐츠 성격, 지리적 독자층, 인덱싱 상태에 따라 값이 크게 달라집니다.

셋째, 레퍼러 헤더가 없는 유입은 과소 계산됩니다. 즉 실제 비율은 측정값보다 유리한 쪽일 수 있습니다. 차단 결정을 내리기 전에 이 한계를 알고 있어야 합니다.

자기 신고를 믿는 규칙과 출처를 보는 규칙

원문 부록에 실제 방화벽 규칙 표현식이 전부 공개되어 있습니다. 규칙 하나하나보다 중요한 것은 어떤 성질의 정보에 의존하는가입니다.

자기 신고 값에 의존하는 규칙이 있습니다. 사용자 에이전트 문자열이 대표적입니다.

(lower(http.user_agent) contains "semrushbot") or
(lower(http.user_agent) contains "ahrefsbot") or
(lower(http.user_agent) contains "mj12bot")

이런 규칙은 정직한 크롤러에게만 통합니다. 저자도 SEO 크롤러들에 대해 "정직하게 자기를 밝혀 준다, 고마운 일이다"라고 씁니다. 거짓말하는 쪽에는 아무 효과가 없습니다.

출처 정보에 의존하는 규칙은 다릅니다. IP가 어느 나라에서 왔는지, 어느 ASN에 속하는지는 요청을 보내는 쪽이 마음대로 정할 수 없습니다.

((ip.src.asnum in {212238 139341 9009}) or
 (ip.src.continent in {"AF" "AN" "AS" "OC" "SA" "T1" "EU"}))
and not cf.client.bot
and not (ip.src.country in {"GU" "AS" "MP"})

저자가 가장 오래 버틴 규칙 두 개가 모두 이 성질입니다. 북미 외 대륙에 챌린지를 걸고, 대규모 클라우드 ASN 46개에 챌린지를 겁니다. 실제 독자가 97퍼센트 북미이고 사람은 AWS us-east-1 IP에서 웹을 보지 않기 때문입니다. 차단이 아니라 챌린지인 이유는 클라우드 데스크톱이나 VPN을 쓰는 사람이 안에 있을 수 있기 때문입니다.

세 번째 종류가 암호학적 검증입니다. Cloudflare는 Googlebot, Bingbot, Applebot의 신원을 검증하고, 규칙에서는 cf.client.bot으로 참조합니다. 저자가 짚는 순서가 요령입니다. 이 우회 규칙을 차단 규칙 뒤에 두면, 내가 막기로 한 검증된 봇은 계속 막히면서 Google에게는 챌린지가 절대 가지 않습니다.

규칙을 설계할 때는 항상 이 질문을 먼저 하세요. 이 규칙이 참조하는 값을 상대가 마음대로 바꿀 수 있는가. 바꿀 수 있으면 그 규칙의 수명은 상대가 신경 쓰기 시작하는 날까지입니다.

주거용 IP 봇넷 앞에서 출처 규칙도 무력해진다

그런데 출처 기반 규칙에도 한계가 있고, 원문은 그 한계에 정확히 부딪힙니다.

2026년 7월, 새로운 물결이 미국에서 왔습니다. 오하이오의 한 가정집, Spectrum 회선에서 옵니다. 대륙 규칙도 통과하고 데이터센터 규칙도 통과합니다. 둘 다 이 트래픽을 그냥 보내 줍니다. 7월 31일 하루 고유 IP가 124,000개까지 올라갔고, 평상시 기준선은 약 18,000개였습니다.

주거용 프록시 네트워크의 정의상 그렇습니다. 수천 개의 실제 가정 인터넷 회선을 요청 단위로 빌려 쓰기 때문에 모든 요청이 진짜 사람의 회선에서 나옵니다. 저자의 결론이 정확합니다. "네트워크 계층에서 이들을 막는 것은 설계상 불가능합니다."

이 물결에 대해 저자가 찾은 대응은 조금 다른 축이었습니다. 같은 봇넷이 Chrome 118에서 120인 척하고 있었던 것입니다. 2023년의 브라우저 버전이 스크레이핑 툴킷 안에 그대로 굳어 있었던 셈입니다.

그래서 오래된 브라우저에 챌린지를 겁니다. Chrome 100부터 130까지, 그리고 오래된 Firefox. 먼저 실제 트래픽을 확인했더니 실제 검색 유입 방문자 중 그렇게 오래된 브라우저를 쓰는 비율은 0.54퍼센트였고, 그중 대부분이 Firefox 115 ESR이라 그것만 예외 처리했습니다.

이 규칙도 결국 자기 신고 값(사용자 에이전트)에 의존합니다. 상대가 문자열 하나만 고치면 무력해집니다. 저자도 이를 알고 "내가 좋아하는 멍청한 규칙"이라고 부릅니다. 요점은 이겁니다. 자기 신고에 의존하는 규칙을 쓸 거라면, 먼저 그 규칙이 실제 사용자 중 몇 퍼센트를 때리는지 측정하고 쓰세요.

방어 장치 자체의 비용을 재라

이 글에서 가장 예상 밖이면서 가장 널리 적용되는 교훈이 여기 있습니다.

Cloudflare의 "JavaScript Detections" 기능이 1년 내내 모든 페이지에 검증 스크립트를 주입하고 있었습니다. 저자는 사이트 속도를 개선하려다 이것을 발견했습니다.

그 스크립트는 중급 사양 휴대폰에서 2,875밀리초를 썼습니다. 사이트 자체의 자바스크립트 전체가 278밀리초였습니다. 모바일 Lighthouse 점수가 58점이었던 가장 큰 이유였고, 게다가 사용 중인 요금제에서는 그 판정 결과를 방화벽 규칙에서 읽을 수조차 없었습니다. 아무도 읽을 수 없는 원격 측정을 위해 성능 40점을 내고 있었던 것입니다.

8월 5일 이 기능을 끄자 한 시간 안에 Lighthouse 점수가 99가 되었습니다.

그리고 다섯 시간 뒤, Azure의 스크레이퍼가 한 시간에 23,000페이지를 가져갔습니다. IP 80개가 넘게 동원되어 각자 얌전히 속도 제한 아래에 머물면서요. 즉 그 기능은 실제로 일을 하고 있었습니다.

이 이야기의 교훈은 "끄지 말라"도 "켜라"도 아닙니다. 방어 장치의 비용을 측정한 적이 있는가입니다. 봇 대응 기능은 대개 "켜기" 토글로 제공되고, 한번 켜면 아무도 다시 보지 않습니다. 그 사이 그 기능은 여러분의 성능 예산과 사용자 경험에서 요금을 계속 걷어 갑니다.

측정 가능한 형태로 운영하는 요령도 원문에 있습니다. 차단 대신 챌린지를 쓰면 통과율이 남습니다. 저자의 48시간 구간에서 챌린지 106,437건 중 252건이 통과되어 통과율 0.24퍼센트였습니다. 저자의 판단 기준이 명확합니다. 통과율 0.2퍼센트면 봇이니 규칙을 유지하고, 통과율 30퍼센트면 사람에게 세금을 물리고 있는 것이니 규칙을 고칩니다.

작업 증명은 무엇을 해결하고 무엇을 해결하지 못하나

이 글의 Hacker News 토론에서 가장 밀도 높은 논쟁이 Anubis 같은 작업 증명 방식에 대한 것이었습니다. 양쪽 주장을 그대로 옮길 가치가 있습니다.

비판 쪽은 이렇습니다. Anubis의 챌린지는 챌린지 문자열 뒤에 논스를 붙여 SHA-256 해시를 구하는 형태인데, 논스가 뒤에 오기 때문에 앞부분의 압축 라운드를 캐시할 수 있습니다. 비트코인 채굴에서 쓰는 중간 상태 재사용 기법이 그대로 통합니다. 논스를 앞에 두었다면 피할 수 있었던 문제라는 지적입니다. 그래서 네이티브 코드 솔버는 브라우저 자바스크립트보다 수천 배 빠르고, 브라우저에서 10분 걸릴 난이도를 밀리초 단위로 풉니다.

옹호 쪽의 반론은 경험적입니다. 우회가 가능한 것과 실제로 우회하는 것은 다릅니다. 전용 스크레이퍼라면 훨씬 효율적으로 우회할 수 있지만 거의 아무도 그렇게 하지 않습니다. 대부분의 봇은 여러분을 특정해서 노리는 것이 아니라 낮은 비용으로 대량 수집하려는 것뿐이기 때문입니다.

Anubis 관리자도 토론에 참여해서, 다음 릴리스 이후 WASM 솔버 기능을 준비 중이며 오래된 스마트 TV 브라우저까지 검증하느라 시간이 걸린다고 밝혔습니다.

정리하면 작업 증명은 사람과 봇을 구분하는 장치가 아니라 대량 수집의 단가를 올리는 장치입니다. 그렇게 이해하면 평가 기준도 명확해집니다. 여러분을 표적으로 삼은 상대에게는 별 효과가 없고, 무차별 수집에는 잘 듣습니다. 그리고 자바스크립트 실행을 강제하므로 텍스트 브라우저 사용자나 느린 회선 사용자에게는 실질적인 비용이 됩니다.

저자 본인의 결론도 기술이 아니라 경제입니다. 스크레이핑이 계속 나빠지는 이유는 계속 싸지기 때문이고, 진짜 해법은 크롤당 과금 같은 시장이라는 것입니다. 그 시장이 생기기 전까지 저자의 규칙은 한 문장입니다. 방문자를 한 명도 보내 주지 않는 크롤러는 막는다.

참고 자료

• 99% of My Website Traffic Is Bots — PatronView, Nick Gray, 2026-08-07 (수치와 규칙 표현식은 전부 이 글에서 옮긴 것입니다)
• The crawl before the fall of referrals — Cloudflare Blog, 2025-07-01 (크롤당 유입 비율의 정의와 Cloudflare 자체 단서)
• Hacker News 토론 스레드 (작업 증명 논쟁의 출처)
• Anubis

이 글의 수치는 개별 사이트 한 곳의 측정치이며, 사이트의 성격과 독자층에 따라 크게 달라집니다. 직접 재현한 값이 아닙니다.