sprinklz.io, Hacker News 게시물 이후 AI 봇 홍수에 휩싸이다: 무슨 일이 있었고 개발자들은 어떻게 사이트를 방어하는가

작은 피드 리더 프로젝트에 관한 Hacker News 게시물은 약 100개의 추천을 받은 후 사이트를 봇 트래픽으로 묻어버렸고, 전체 요청의 거의 절반이 단일 AI 뉴스레터 스크래퍼에서 발생한 것으로 추적되었습니다. 사이트 작성자가 문서화하고 174명의 댓글 작성자가 논의한 이 사건은 HN에 공개적으로 노출되면 이제 인간 청중보다 종종 더 큰 자동화된 트래픽의 물결을 확실히 유발한다는 것을 보여줍니다.

짧은 버전

Sammy Straus는 LLM과 같은 주제를 우선순위에서 제외할 수 있는 맞춤형 피드 리더인 sprinklz.io를 Hacker News에 게시했습니다. 게시물은 "백 개 정도의 추천"을 받았습니다. 며칠 후, 실제로 활동 중인 로그인 사용자는 소수에 불과했음에도 사이트는 여전히 느렸고 점점 더 느려지고 있었습니다.

"제 웹사이트가 느려졌습니다. 정말, 고통스러울 정도로 느렸어요. 처음에는 갑자기 인기 있는 게시물로 인한 추가 관심 때문이라고 생각했습니다... 그런데 이상하게도 느려짐은 계속되었고, 제 게시물이 올라간 지 며칠 후에는 더 악화되기 시작했으며, 제가 기록한 지표도 이해가 되지 않았습니다."

원인은 HN 청중이 아니었습니다. 그것은 자동화된 트래픽이었고, 한 가해자가 그것을 지배했습니다.

진단 단서: 대부분의 요청은 JavaScript를 실행하지 않았습니다

sprinklz.io는 단일 페이지 애플리케이션이므로 실제 페이지 뷰에는 브라우저가 JavaScript를 가져와서 실행해야 합니다. 작성자가 모든 엔드포인트에 최상위 로깅을 추가했을 때 패턴은 명백했습니다: 대부분의 요청은 뉴스 기사를 전혀 가져오려고 시도하지 않았습니다.

"대부분의 요청은 페이지를 렌더링하는 데 필요한 자바스크립트조차 실행하지 않았습니다 (!)."

그 단일 신호는 인간 방문자와 스크래퍼를 구분합니다. 페이지를 로드하는 브라우저는 문서를 요청한 다음 CSS, JavaScript 및 파비콘 자산을 요청합니다. 텍스트만 원하는 스크래퍼는 문서만 요청하고 다른 것은 요청하지 않는 경우가 많습니다. 댓글 작성자 dhosek는 정확히 이 휴리스틱을 사용한다고 설명했습니다:

"페이지를 로드할 때 CSS/JS/favicon을 요청하지 않는 등의 요청 패턴으로 '스텔스' 봇 트래픽을 식별할 수 있는 것이 정말 유용했습니다."

트래픽의 거의 절반이 하나의 AI 뉴스레터 스크래퍼에서 발생했습니다

NGINX 로그를 집계하여 악용자를 찾은 작성자는 전체 트래픽의 거의 절반이 단일 소스, 즉 웹사이트의 변경 사항을 모니터링하고 이를 AI 생성 뉴스레터로 요약하는 서비스에서 발생한다는 것을 발견했습니다. 그 서비스는 분당 여러 번 사이트를 쿼리하고 있었습니다. 작성자는 그것을 차단했지만 이름을 밝히기를 거부했습니다.

댓글 작성자들은 그 자제에 반발했습니다. Havoc는 다음과 같이 썼습니다:

"그런 행동은 명예 훼손을 정당화한다고 생각합니다. 무례한 형편없는 서비스는 이름을 보호하는 예의를 받을 자격이 없습니다."

andai는 스크래퍼의 논리를 의문시했습니다: "초당 여러 요청을 하고 있는 것 같아서, 신선한 콘텐츠를 원하는 것이 그 이유일 수는 없습니다."

명명된 크롤러와 취약점 스캐너가 나머지를 차지했습니다

나머지 트래픽은 식별 가능한 크롤러와 공격자의 혼합이었습니다. 작성자는 ClaudeBot, OpenAI의 봇, Google의 검색 인덱서, "다른 여러 봇"과 함께 WordPress가 아닌 사이트에서 /wp-content/phpinfo.php와 같은 경로를 탐색하는 취약점 스캐너를 나열했습니다.

drnick1은 이 소음이 일상적이라고 확인했습니다: "이것은 정상입니다. 로그에서 매일 수백, 수천 개를 봅니다."

switz는 AWS, Google Cloud, Azure, Alibaba Cloud, Oracle과 같은 전체 클라우드 ASN을 차단한다고 설명했으며, 2년 전 Alibaba Cloud 차단이 여전히 한 도메인에 대해 하루 약 100만 건의 요청을 생성하고 모두 4xx 응답을 반환한다고 보고했습니다. 같은 댓글 작성자는 Apple이 "지난 몇 달 동안 스크래핑을 공격적으로 늘렸지만, 다행히 robots.txt를 존중한다"고 언급했으며, 일부 AI 스크래퍼는 이제 탐지를 피하기 위해 가정용 IP 봇넷을 통해 라우팅한다고 언급했습니다.

작성자가 적용한 완화 조치

작성자의 대응은 접근 제어와 성능 작업을 결합했습니다:

대부분의 AI 스캐너를 차단하면서 Googlebot 및 기타 검색 관련 트래픽을 허용하는 robots.txt를 추가했습니다.
합리적인 속도 제한을 추가했습니다.
Claude를 사용하여 취약점 경로를 쿼리하고 스캐너를 모방하여 누출되는 것이 없는지 확인했습니다.
사이트가 높은 초당 쿼리 수 부하를 처리할 수 있도록 상당한 인프라 개선을 시작했습니다.

"가장 중요한 교훈은 제 웹사이트를 더 빠르게 만들 때가 되었다는 것입니다. 저는 실제 트래픽의 xxx QPS를 처리할 수 있는 웹사이트가 되고 싶습니다."

HN 노출은 추천이 없어도 봇 자석입니다

여러 댓글 작성자는 프론트 페이지에 도달하지 못한 게시물에서도 같은 홍수를 보고했습니다. Twiin은 "문자 그대로 추천 0개와 댓글 0개"를 받은 게시물이 여전히 "미친 봇 트래픽"에 시달렸으며, 링크가 게시된 유일한 곳은 HN이었다고 썼습니다.

Jaxan은 트리거 조건을 단호하게 요약했습니다: "오, 서브도메인에 TLS를 추가하자마자 봇이 옵니다. 즉각적입니다." nubinetwork는 웹 콘텐츠가 전혀 없는 도메인에서 LLM 같은 트래픽을 받았다고 보고했습니다: "요즘은 그냥 존재하는 것만으로도 스캔을 당합니다."

firefoxd는 반대 효과를 설명했습니다 — 봇 방어 기술(집폭탄)에 대해 공개적으로 글을 쓰는 것이 문제를 악화시켰습니다: "그것은 웹 전체에서 엄청나게 바이럴이 되었고 후회합니다. 제 서버는 봇 트래픽으로 완전히 압도당했습니다."

봇 트래픽은 실제 청구서와 중단을 생성합니다

여러 댓글 작성자가 비용을 정량화했습니다. QueensGambit는 ClaudeBot으로 인한 단일 월 Google Cloud 청구서 $10,000를 보고했으며, 사용자가 코딩 에이전트와 브라우저 플러그인으로 자신들의 소프트웨어를 복제하려고 시도한 것으로 추측했습니다. pampas는 Wikipedia 미러링 게임인 redactle.net이 봇이 모든 페이지를 강타하고 캐시 적중률을 낮추어 큰 클라우드 이그레스 청구서를 생성했다고 말했습니다. trinsic2는 자신의 사이트가 "트래픽 때문에 한동안 종료되었다"고 말했습니다.

layerv-ai는 복합 위험을 언급했습니다: HN과 Twitter에서 프로젝트를 마케팅하면 CF의 봇 보호 기능이 있어도 Vercel 청구서를 "봇이 웹사이트를 갈가리 찢어 놓아 천장을 뚫을" 수 있습니다.

개발자들이 실제로 실행 중인 방어

댓글 작성자들은 합의된 승자 없이 다양한 대응책을 설명했습니다:

챌린지 페이지. 8by3는 Anubis의 Elixir 버전인 Sphinx를 만들었고 "합법적인 크롤러를 허용 목록에 추가해도 전체 트래픽의 80% 이상이 챌린지에 실패하는 봇입니다"라고 보고했습니다. paaloeye는 Cloudflare Turnstile을 제안했습니다.
타르핏. robotmay는 클라이언트가 패킷을 수락할 수 있는 한 느리게 요청을 제공하는 맞춤형 L7 프록시를 구축하여 두 개의 작은 Hetzner VM에서 약 3,000개의 동시 크롤러를 가두었습니다. "요청을 거부하기만 하면 그들이 제 서버를 더 세게 때렸습니다."
차단 목록. pmlnr는 abuseipdb 차단 목록을 권장했습니다. minimaxa는 팀이 전체 IP 범위를 차단하고 Vorwatch라는 무료 도구를 출시했다고 말했습니다.
기본 인증. goodthink는 홈 페이지를 제외한 모든 것을 잠그고 자격 증명을 거기에 두어 자산 스크래핑을 중단했습니다.
차단보다 속도 제한. mboyd1는 Lightpanda 사용자 에이전트만 하드 차단하고 그 외에는 속도 제한을 선호한다고 말했습니다. 에이전트 트래픽은 프리미엄 API 업셀로 전환될 수 있기 때문입니다.
포기하고 최적화. timpera는 Cloudflare, Anubis, fail2ban을 시도한 후 결론을 내렸습니다: "이 무기 경쟁에서 이길 수 없습니다. 그래서 서버 성능 개선과 모든 요청 처리에 의존했습니다."

모든 봇 트래픽이 가치 없는 것은 아닙니다

토론에는 무차별 차단에 대한 명확한 반론이 포함되었습니다. beybol은 인덱싱 크롤러와 사용자 트리거 페치를 구분했습니다:

"OAI-SearchBot/GPTBot/ClaudeBot은 단순히 인덱싱하지만 ChatGPT-User/Claude-User 등은 사용자의 LLM 대화로 생성된 가치 있는 트래픽일 수 있습니다. 따라서 모두 차단하는 대신 어떤 것을 차단할지 선택하는 것이 가치가 있습니다."

mboyd1는 비즈니스 관점에서 같은 주장을 했으며, 에이전트가 "제 애플리케이션을 유용한 리소스로 보고 더 큰 속도 제한을 원하는 에이전트 개발자에게 잠재적인 프리미엄 API 업셀을 유도"하는 것을 선호한다고 말했습니다.

아키텍처 교훈: SPA와 캐시 가능성

가장 반복된 기술적 비판은 봇이 아닌 사이트 아키텍처를 겨냥했습니다. est는 간단히 썼습니다: "제 웹사이트는 단일 페이지 애플리케이션으로 구축되었습니다. 바로 그겁니다. 버리세요. 페이지를 가능한 한 캐시 가능하게 만드세요." mediumsmart는 같은 결론의 시작점으로 Google Lighthouse와 PageSpeed Insights를 지적했습니다.

정적이고 캐시 가능한 페이지는 요청당 JavaScript를 실행해야 하는 SPA보다 봇 홍수를 훨씬 저렴하게 흡수합니다. 작성자 자신의 결론 — 사이트가 높은 QPS를 처리해야 한다는 것 — 은 다른 방향에서 본 같은 수정입니다.

실용적인 교훈

엔드포인트별 요청 수를 기록하세요. 이 사건에서 가장 유용한 신호는 대부분의 요청이 실제 사용자가 가져올 콘텐츠를 전혀 가져오지 않았다는 것입니다.
클라이언트가 CSS, JavaScript 및 파비콘을 요청하는지 확인하세요. 이를 건너뛰는 스크래퍼는 거의 확실히 브라우저가 아닙니다.
트래픽 급증이 인간이라고 가정하기 전에 소스별로 로그를 집계하세요. 이 사이트 부하의 거의 절반이 하나의 서비스에서 발생했습니다.
차단 전에 인덱싱 크롤러와 사용자 트리거 페치를 구분하세요. 검색 봇과 사용자를 대신한 에이전트 요청은 다른 가치가 있습니다.
참여가 전혀 없어도 공개 링크에서 트래픽을 예상하세요. 여러 댓글 작성자가 추천을 받지 못한 게시물에서 홍수를 보고했습니다.
대역폭뿐만 아니라 이그레스 및 컴퓨팅 비용도 예산에 포함하세요. 봇 홍수는 소규모 프로젝트에 대해 네 자리 및 다섯 자리 클라우드 청구서를 생성했습니다.
캐시 가능하고 정적으로 제공되는 페이지를 선호하세요. 스크래퍼 홍수에 대한 가장 저렴한 방어는 제공 비용이 거의 들지 않는 페이지입니다.