웹 트래픽 99%가 봇일 때, 150만 페이지 사이트가 택한 방어선

웹 트래픽 99%가 봇일 때, 150만 페이지 사이트가 택한 방어선

AI 뉴스 썸네일

150만 개의 공개 프로필 페이지를 운영하는 PatronView는 분석 화면보다 서버 로그를 먼저 봐야 했어요. 한 주 동안 외부 요청 250만 건과 전체 페이지 로드 128만 건을 처리했지만, 분석 도구에 기록된 페이지뷰는 5,977건뿐이었어요. 운영자는 실제 사용자보다 크롤러가 서버 비용과 방어 업무를 좌우한다고 판단했어요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
트래픽 측정	서버가 처리한 페이지 로드와 분석 도구의 페이지뷰가 214배가량 벌어졌어요	자바스크립트 기반 분석만 보면 봇이 만든 비용을 놓칠 수 있어요
크롤러 평가	크롤링한 페이지 수를 실제 유입 방문자 수로 나눠 효율을 비교했어요	검색·AI 크롤러를 모두 허용하는 대신 운영 가치에 따라 정책을 나눌 수 있어요
방어 방식	국가, 사용자 에이전트, ASN, 요청 속도, 브라우저 버전을 조합했어요	IP 하나씩 막는 방식보다 여러 신호를 함께 보는 편이 오래 버텼어요
운영 비용	방어용 자바스크립트가 모바일 성능을 낮추는 부작용도 겪었어요	보안을 강화할수록 실제 방문자 경험이 나빠질 수 있어 균형이 필요해요

1. IP 차단만으로는 따라잡기 어려워진 웹 크롤러

분석 도구 밖에서 서버 비용이 쌓였어요

Plausible과 Google Analytics 같은 도구는 보통 자바스크립트를 실행한 방문을 집계해요. 반면 단순 HTTP 크롤러는 페이지를 받아 가면서도 분석 화면에는 거의 흔적을 남기지 않아요. PatronView 사례에서는 측정된 페이지뷰 한 번당 서버가 약 214회의 보이지 않는 페이지 로드를 처리했어요. 작은 사이트처럼 보이는 대시보드와 매주 수백만 건을 감당하는 서버 사이에 큰 차이가 생긴 셈이에요. 1

이 차이를 방치하면 캐시 적중률, 대역폭, 데이터베이스 부하를 사람 방문 기준으로만 해석하기 쉬워요. 웹 운영팀은 분석 도구뿐 아니라 CDN과 원본 서버의 요청 수, 응답 바이트, 경로별 요청 빈도를 함께 봐야 해요. 봇 비용은 페이지뷰가 아니라 서버가 실제로 수행한 작업에서 드러나요.

728x90

크롤러가 보내는 방문자까지 함께 계산했어요

PatronView는 크롤러의 이름보다 `크롤링한 페이지 수 ÷ 보내 준 방문자 수`를 판단 기준으로 삼았어요. Google은 방문자 1명을 보내는 동안 46페이지를 읽었어요. Claude-SearchBot은 6월 한 주에 420,680페이지를 요청하고 방문자 12명을 보냈어요. 약 35,000대 1이에요. Amzn-SearchBot은 하루 약 117,000건을 요청했지만 확인할 수 있는 방문 유입이 없어 차단 대상이 됐어요. 1

모든 크롤링이 같은 가치를 주는 건 아니에요. 검색 노출이나 실제 유입으로 돌아오는 크롤러는 서버 비용을 감수할 이유가 있어요. 답변 생성이나 내부 색인에만 데이터를 쓰고 방문자를 보내지 않는 크롤러라면 운영자가 허용 범위를 다르게 정할 수 있어요. PatronView 운영자는 이 기준에 따라 Claude-SearchBot을 막았고, 하루 약 60,000건이던 요청이 약 25건의 차단 시도로 줄었다고 적었어요. 2

봇은 데이터센터 밖으로 이동했어요

초기에는 사용자 에이전트나 데이터센터 IP 대역만으로도 눈에 띄는 크롤러를 걸러낼 수 있었어요. 이후에는 중국의 361,844개 고유 IP에서 하루 360만 건이 들어왔고, AWS와 Azure에서 실행한 헤드리스 Chrome도 나타났어요. 자바스크립트를 실행하는 봇은 분석 도구에 실제 방문처럼 기록돼 통계까지 흐렸어요. 1

가정용 회선을 빌리는 residential proxy botnet은 더 까다로워요. 요청이 일반 통신사 IP에서 오고 각 IP가 낮은 요청량을 유지하면 국가 차단, 데이터센터 ASN 차단, IP별 레이트 리밋을 피할 수 있어요. PatronView는 국가, ASN, 오래된 브라우저 버전, 요청 속도를 조합해 차단이나 Managed Challenge를 적용했어요. 최근 48시간 CAPTCHA 106,437건 가운데 252건만 성공해 해결률은 0.24%였어요. 다만 이 수치는 자동 요청을 잘 걸러냈다는 신호일 뿐, 정상 사용자가 겪은 불편까지 설명해 주지는 않아요. 1

방어 코드도 실제 사용자에게 비용을 만들어요

Cloudflare의 JavaScript Detections를 켜자 모든 페이지에 챌린지 스크립트가 들어갔고, 모바일 Lighthouse 점수는 58까지 떨어졌어요. 기능을 끈 뒤 점수는 99로 올랐지만 5시간 뒤 Azure 기반 스크래퍼가 80개가 넘는 IP에서 한 시간 동안 23,000페이지를 읽었어요. 성능을 회복하자 방어력이 약해지는 교환관계가 바로 드러났어요. 1

그래서 방어 규칙은 전 방문자에게 무거운 검사를 적용하기보다 위험 신호가 겹친 요청에만 챌린지를 거는 편이 나아요. 예를 들어 데이터센터 ASN, 오래된 브라우저, 비정상적인 경로 순회, 높은 요청 속도를 단계별로 묶을 수 있어요. 검색엔진과 접근성 도구, VPN 이용자처럼 정상 요청이 함께 막히는지도 로그로 확인해야 해요.

왜 중요한가요

공개 페이지가 많은 서비스는 이제 크롤링 허용 여부를 비용과 유입의 문제로 다뤄야 해요. 서버 요청량, 전송량, 실제 방문 유입을 크롤러별로 나누면 허용 목록과 차단 목록을 근거 있게 운영할 수 있어요. `robots.txt`를 지키는 봇에는 명시적인 정책을 제공하고, 이를 무시하거나 출처를 숨기는 요청에는 WAF와 속도 제한을 적용하는 식이에요. 2

방어가 성공해도 작업은 끝나지 않아요. 봇은 사용자 에이전트, 클라우드 사업자, 국가, 프록시망을 바꿔 돌아와요. 운영팀은 차단 건수만 보지 말고 원본 서버 비용, 정상 방문자의 CAPTCHA 실패, 검색 유입 변화, 페이지 성능을 함께 확인해야 해요. 한 지표만 최적화하면 서버 비용을 줄이는 대신 검색 유입이나 실제 사용자 경험을 해칠 수 있어요.

PatronView가 제안한 pay-per-crawl도 이 비용 문제에서 나왔어요. 크롤러가 요청 비용을 부담하면 사이트 운영자는 무조건 차단과 무조건 허용 사이에서 다른 선택지를 가질 수 있어요. 아직 널리 정착한 방식은 아니므로 당장 적용할 표준으로 보기는 어려워요. 지금 할 수 있는 일은 크롤러별 비용과 유입을 측정하고, 서비스 목적에 맞는 허용 기준을 문서로 남기는 거예요. 1

참고 자료

1. 150만 페이지 웹사이트에서 scraper와 싸운 1년 — GeekNews
2. 99% of My Website Traffic Is Bots — PatronView