I posted to HN, and then my website was flooded with AI bot traffic
HN에 글을 올린 뒤 웹사이트에 AI 봇 트래픽이 몰렸습니다
개발자는 Hacker News에 제품을 소개한 뒤 웹사이트가 느려졌고, 로그를 살펴보니 상당수 요청이 페이지를 렌더링하지 않는 봇에서 왔다고 설명합니다. 특정 서비스의 과도한 요청을 차단하고 robots.txt와 속도 제한을 적용했으며, 서버 성능도 개선하고 있습니다.
- 주제
에디터 노트
사이트가 느려졌다는 사실과 봇이 원인이었다는 판단은 구분해야 합니다. 개발자는 요청 로그에서 봇 트래픽을 확인했지만, 해당 요청이 지연을 일으켰다고 결론 내리지는 않았습니다. 댓글에서도 분당 수십 회 요청은 작은 서버가 처리할 수 있다는 반론이 나왔고, 요청 빈도와 서버 작업량을 함께 봐야 한다는 점이 드러납니다. 반면 다른 운영자들은 크롤러가 robots.txt를 무시하거나 취약점 경로를 반복 조회하고, 차단 장치를 우회한다고 경험을 나눴습니다. 이런 사례는 개별 웹사이트의 부하 원인을 입증하지는 않지만, 봇 종류에 따라 차단과 허용을 나누고 서버 부하를 실제 로그로 확인하는 대응이 필요하다는 맥락을 보탭니다. 글에서 요청량과 지연 원인을 정량화하지 않아 성능 개선이 얼마나 효과를 냈는지는 확인하기 어렵습니다.
AI 요약
개발자는 맞춤형 피드 리더 sprinklz.io를 Hacker News에 소개한 뒤 약 100개의 추천을 받았습니다. 며칠 뒤부터 사이트가 눈에 띄게 느려졌지만, 기록된 로그인 사용자 수와 서버 부하가 맞지 않아 요청 경로별 횟수를 기록했습니다. 그 결과 요청 대부분이 뉴스 기사를 가져오지 않았고, 단일 페이지 앱의 JavaScript도 실행하지 않는 것으로 나타났습니다.
트래픽을 확인하고 대응한 과정
개발자는 NGINX 로그를 집계해 트래픽을 살폈습니다. 전체 요청의 거의 절반이 특정 서비스 한 곳에서 왔습니다. 해당 서비스는 웹사이트 변경 사항을 확인해 AI 뉴스레터로 요약한다고 설명했으며, 사이트를 분당 여러 차례 조회했습니다. 개발자는 해당 요청을 차단했습니다. 그 밖에는 Claude와 OpenAI의 봇, Google 검색 크롤러, 취약점 탐색 도구 등이 확인됐습니다. 워드프레스 사이트가 아닌데도 워드프레스 경로를 찾는 요청이 있었습니다.
개발자는 검색 관련 크롤러는 허용하고 AI 스캐너는 억제하도록 robots.txt를 추가했으며, 속도 제한도 설정했습니다. 이 경험을 계기로 인프라를 손봐 성능을 높이고 있습니다. 다만 글에서 특정 봇의 요청량이나 서버 부하의 구체적인 수치는 공개하지 않았습니다. 개발자는 봇 요청이 사이트 지연의 직접 원인이었다고 단정하지 않고, 로그를 확인하게 된 계기였다고 설명합니다.
Hacker News 반응
- @vanschelven — 저도 HN에 글을 올려 1위까지 갔지만, Hetzner의 월 5유로 VPS에서 CPU와 네트워크 트래픽이 늘어난 폭은 한 자릿수 퍼센트였습니다. 이 문제는 10여 년 전에 해결됐습니다. 물론 작성자도 그 점을 인정하는 것 같습니다.
- @dboreham — C10k 문제는 동시에 열리는 TCP 연결 수에 관한 별개의 문제입니다. 크롤러 봇이 1만 개의 연결을 열려면 엄청나게 많아야 할 것 같습니다.
- @bix6 — "특정 사용자 한 명"이라고 했는데, 누구인가요?
- @sammy0910 — 이름은 밝히지 않겠습니다.
- @nekusar — 나쁜 행위자와 남용자를 감싸면 안 됩니다. 이름을 숨기면 그들이 다른 사람도 무차별적으로 공격하도록 돕는 셈입니다.
- @janalsncm — 봇 하나가 AI 뉴스레터를 만들려고 사이트를 두드린 건 짜증 나는 일입니다. 그래도 분당 60회라 해도 2015년 노트북으로 감당할 수 있는 수준 아닌가요?
- @sammy0910 — 맞습니다. 애플리케이션의 일부를 더 빠르게 만들어야겠다고 깨닫는 계기였고, 지난 몇 주 동안 작업했습니다.
- @Exoristos — 설명한 목적이라면 24시간에 한 번 확인해도 충분해 보입니다.
- @bostik — 취약점 탐색은 LLM이 나오기 훨씬 전부터 있었습니다. 호스트가 온라인에 올라오거나 첫 Let's Encrypt 인증서가 발급된 직후에도 나타납니다. 보안 회사의 스캐너, 취약점 도구, 실제 봇넷이 모두 이런 요청을 보냅니다.
- @paaloeye — 봇 트래픽에 Cloudflare Turnstile을 써 봤나요?
- @sammy0910 — 아직이지만 다음 단계로 고려하고 있습니다.
- @diath — Turnstile은 curl이나 requests를 쓰는 단순한 봇에는 효과가 있을지 몰라도 브라우저 드라이버를 쓰는 봇에는 효과가 없습니다.
- @beybol — 서버 로그에서 LLM 트래픽 종류를 구별할 수 있습니다. OAI-SearchBot이나 GPTBot, ClaudeBot은 색인용이지만 ChatGPT-User나 Claude-User는 사용자 대화에서 온 유입일 수 있으니, 어떤 봇을 차단할지 골라야 합니다.
- @mplewis — 사용자 에이전트를 차단해도 가짜 브라우저 사용자 에이전트로 다시 요청합니다. 나쁜 봇을 완전히 막을 방법은 없습니다.
- @mediumsmart — 사이트를 빠르게 만들고 싶다면 JavaScript로 렌더링하지 말고 Google Lighthouse로 개선점을 확인하세요.
- @jacobgkau — 악성 방문자가 서버를 두드리는 문제와 방문자 브라우저의 JavaScript 실행 시간은 별개입니다. 이런 상황에서는 서버 작업을 줄이려고 클라이언트 렌더링을 늘릴 수도 있습니다.
- @timpera — Cloudflare와 Anubis, fail2ban을 비롯해 여러 방법을 써 봤지만 단점이 있고 사용자 불만도 있어 그만뒀습니다. 봇과의 경쟁에서 이길 수 없어서 서버 성능을 높이고 모든 요청을 처리합니다. 지금은 훨씬 원활합니다.
원문: Sammy's Blog / 번역·요약: Trawling