요약
HN에 글이 오른 뒤 사이트를 느리게 만든 주범은 사람이 아니라 봇이었습니다.
피드 리더 sprinklz.io를 만든 개발자 새미 스트라우스의 경험담입니다. HN 글이 추천 100개 남짓을 받은 뒤 사이트가 크게 느려졌고, 며칠이 지나도 오히려 나빠지자 원인을 직접 추적했습니다.
왜 중요한가
- 작은 사이트가 널리 알려지면 실제 방문자보다 자동화된 봇이 더 큰 부하를 만들 수 있음을 보여 줍니다.
- 접속 지표가 실제 사용자 수와 맞지 않았고, 요청을 경로별로 쪼개 보고서야 원인이 드러났습니다.
- 작성자는 봇 차단만이 아니라 사이트 자체를 빠르고 튼튼하게 만들어야 한다는 결론을 얻었습니다.
핵심 내용
- 전체 트래픽의 절반 가까이가 웹사이트 변경을 감시해 AI 뉴스레터로 요약하는 서비스 한 곳에서 나왔습니다.
- 이 서비스는 1분에도 여러 번씩 사이트를 조회했고, 작성자는 이름을 밝히지 않고 차단했습니다.
- 요청 대부분은 기사를 불러오지도, 화면을 그리는 자바스크립트를 실행하지도 않았습니다.
- 앤트로픽·오픈AI의 크롤러와 구글 검색 봇 말고도 워드프레스 파일을 뒤지는 취약점 스캐너가 있었습니다.
- AI 크롤러는 막고 검색 봇은 허용하는 robots.txt와 요청 속도 제한을 넣고 인프라도 손봤습니다.
HN 반응
- 여러 이용자가 비슷한 일을 겪었다며 AWS, Azure, Alibaba Cloud 같은 클라우드 대역을 통째로 막았다고 전했습니다.
- 반면 가정용 회선 IP를 계속 바꿔 쓰는 봇넷은 IP 차단이나 fail2ban(실패 요청이 잦은 IP를 막는 도구)으로 막기 어렵다는 지적이 이어졌습니다.
스팸, 악용, 공격적인 스크래핑이 너무 심해서 제 거의 모든 사이트에서 다음을 차단해야 했습니다.
그 밖에도 ASN 몇 개를 더 막았습니다. 단순한 스크래핑이라면 차라리 괜찮겠지만, 실제로는 에이전트를 동원한 악용인 경우가 많습니다. 취약점을 찾겠다고 스팸 요청을 보내거나(*), 값어치 있는 내용이나 동적인 내용이 거의 없는 페이지를 수백만 개씩 긁어 갑니다. 이런 클라우드 업체들은 자기네 영역에서 벌어지는 악용을 반드시 통제해야 합니다.
2년 전에 알리바바 클라우드를 차단했는데, 그동안 모든 경로가 4xx를 돌려주는데도 제 도메인 하나에 지금도 하루 100만 번씩 요청이 들어옵니다.
애플도 최근 몇 달 사이 스크래핑을 공격적으로 늘렸습니다. 다행히 robots.txt는 지키고 있습니다.
답답한 건 제 실제 사용자 중 일부가 회사 VPN을 통해 이런 클라우드를 거쳐 접속한다는 점입니다. 게다가 평판이 별로인 AI 스크래퍼 중에는 가정용 IP로 이루어진 전 세계 봇넷을 써서 긁어 가는 곳이 많습니다. 그래서 실제 사람에게 피해를 주지 않고 이들을 찾아내 차단하기가 더 어렵습니다.
* 유출된 .env 경로, 관리자 페이지 무차별 대입 같은 것들입니다.
적응도 안 하는 상대라면 그냥 패킷을 조용히 버리는 편이 낫겠네요.
Bing 봇도 똑같아요. 왜 그렇게까지 말을 안 듣는지 모르겠습니다.
마이크로소프트는 '동의'라는 걸 이해해 본 적이 없죠.
봇과 스파이더는 옛날 URL을 제가 원한을 품는 것보다도 오래 붙들고 있습니다.
저희는 SSR을 쓰면서, 새 페이지를 통째로 불러오는 대신 자바스크립트 리스너로 인터랙티브하게 갱신하는 구조를 얹어 두었습니다. 그런데 담당 팀이 nofollow를 넣지 않았고, 일부 봇은 nofollow가 있어도 무시합니다. 클러스터 규모의 상당 부분이 그 요청에 답하는 데 쓰였습니다. 그러다 한 번 배포에서 누군가 그 링크들을 완전히 박살 냈고, 곧바로 4xx 오류 통계에 드러나서 일주일 안에 변경을 롤백했습니다.
3년이 지나도 그 망가진 URL이 계속 들어오는 걸 봤습니다.
그 뒤 nofollow 수정이 구현되어 끝난 걸로 처리됐는데, 정작 그 플래그는 영구 적용이 안 돼 있었습니다. 팀 간 대화에서 누가 지나가듯 한 말로 그걸 알게 됐을 때는 다들 꽤 열이 받았죠.
저희는 이미 경계에서 '좋은' 봇과 '나쁜' 봇을 가려 나쁜 쪽은 꺼지라고 하고 있었으니, 이 모든 요청은 소위 우리 친구라는 쪽에서 온 겁니다. 그때 깨달았습니다. 검색 엔진과 클라우드 서비스 업체를 둘 다 가진 회사는 보호비 갈취 조직이나 마찬가지라는 걸요. 구글 클라우드는 구글 봇의 요청을 받아 주라고 서버를 파는 셈입니다.
그 옛날 슬로로리스 같은 수법을 거꾸로 쓸 수는 없을까요? 연결 한도를 올려 두고 알리바바 쪽 연결 N개를 영원히 열어 둔 채, 연결이 끊기거나 타임아웃이 날 때까지 데이터를 조금씩 찔끔찔끔 흘려 보내는 거죠.
작년에 저는 봇 트래픽을 zip 폭탄으로 처리한다는 글을 썼습니다0. 그 글이 웹 전체에 엄청나게 퍼졌고, 저는 후회하고 있습니다. 서버가 봇 트래픽에 완전히 압도당했거든요. 몇 달을 시달린 끝에 더 나은 전략을 찾아야 했는데, 그게 입을 다무는 것이었습니다.
작년에 당신 글을 읽고 그대로 적용해 봤습니다. 효과가 있는지 확인할 방법이 없어서 결국 접었습니다. 압축된 데이터에 압축도 미리 계산해 둔 거라 해도 그걸 내보내는 것 자체가 대역폭 낭비였습니다. 정상 사용자의 브라우저에 날아갈 수도 있었고요(오탐).
제 사이트의 가장 큰 문제는 봇이 CGIT 저장소를 때린다는 점입니다. 파일을 열 때마다 구문 강조 스크립트가 돌거든요.
그래서 상식 퀴즈 같은 방식을 도입했습니다. 정답을 맞히면 가능한 한 오래 유지되는 접근 쿠키를 주기 때문에, 정상 사용자는 최대한 적게 번거롭게 됩니다.
구문 강조가 클라이언트 쪽에서 돌아가는 것도, 미리 렌더링해 둔 것도 아니라는 말씀인가요?
그러니까 결국 봇에는 눈에 띄는 영향이 없었다는 건가요?
소규모에서는 잘 먹혔습니다. 하지만 파리 몇 마리를 쫓는 것과 말벌 떼와 싸우는 건 전혀 다른 일이죠. 작은 digitalocean 드롭릿에서 1MB짜리 파일을 하루에 100만 번 내보내는 건 불가능합니다. 한마디로 확장이 안 됐습니다. 게다가 AI 봇은 보통 사양이 더 좋은 머신으로 오고, 폭탄을 맞아도 더 빨리 회복합니다.
왜 DigitalOcean에서 내보내신 건가요?
CDN을 쓰지 그랬어요?
페이지의 내용, 즉 원본 HTML 자체를 zip 폭탄으로 바꿔치기하는 방식이라서요. 예를 들어 https://example.com 이 악성 봇인지 확인한 다음, 결과에 따라 gzip으로 압축한 HTML이나 압축한 폭탄을 보냅니다. 그래서 CDN으로 바꾸거나 리디렉션할 수 없습니다. 봇은 리디렉션을 그냥 무시할 테니까요.
정말 성가시겠네요. 설명 감사합니다! 저도 새로 만든 작은 제품을 곧 출시하려는데, 지난번 제품도 봇에 시달렸거든요.
다행히 다른 분들이 겪은 것처럼 악의적인 수준은 아니었지만, 그래도 짜증스러웠어요.
그 기법을 패킷 압축에도 적용할 수 있나요?
한편 GitHub Pages에 글을 올리는데 유명한 사람이 아니면 트래픽이 거의 안 들어오는 모양이에요 :( (봇이 하필 제 서드파티 방문자 카운터 링크만 안 따라가기로 한 게 아니라면요…)
https://github.com/borestad/blocklist-abuseipdb 에 올라 있는 모든 곳의 트래픽을 차단하시길 정말 권합니다.
공유해 주셔서 감사합니다. 편집증 있는 셀프 호스터로서 이미 잔뜩 갖춘 차단 목록에 이것도 추가할게요.
저는 Claude가 웹 로그에서 패턴을 찾고 나쁜 트래픽 양상을 가려내는 데 정말 도움이 된다는 걸 알게 됐습니다. 제가 운영하는 위키에서 Meta가 robots.txt를 무시하고 트래픽을 엄청나게 일으켜, 크롤러를 차단하기 전까지는 사실상 사이트에 DoS를 거는 상태였습니다.
특히 유용했던 건 요청 패턴으로 '스텔스' 봇 트래픽을 알아낼 수 있다는 점입니다(예: 페이지를 불러오면서 CSS, JS, 파비콘을 요청하지 않는 경우).
저도 여기 댓글에 제가 만든 온라인 게임 링크를 한 번 올렸는데, 곧바로 좋은 트래픽과 나쁜 트래픽이 온갖 종류로 몰려왔습니다.
제 작업을 좋아해서 LinkedIn에서 저를 찾아 긍정적인 메시지와 함께 연결 요청을 보낸 사람들도 있었습니다. 반면 어떻게든 SQL 인젝션이나 공격을 시도하고, 입력창이란 입력창에는 모조리 욕설을 남긴 사람들도 있었죠.
누군가는 사이트를 통째로 복사해서 몇 군데만 살짝 바꾼 자기 버전을 호스팅했습니다. 링크 하나를 지우지 않고 그대로 둔 덕에 그쪽 사본에서 유입되는 트래픽이 생겨서야 알았습니다.
이게 전부 HN 댓글 하나에서 벌어진 일이고, AI가 나오기 전의 일입니다. 워드프레스나 PHP의 알려진 취약점을 노리는 것으로 짐작되는 일상적인 요청이 매일 쏟아지는 건 말할 것도 없고요.
인터넷은 온갖 주체가 드나드는 수문이고, 그중 상당수는 자동화된 존재입니다. HN 같은 곳에 링크가 올라가면 그 밸브가 특히 활짝 열리는 거죠.
저는 크론 몇 개를 엮어서 접근 로그를 가져와 LLM으로 처리하고, WHOIS에 나온 악용 신고 담당자에게 알려 주게 해 놨습니다.
예전 글에 댓글을 달기엔 너무 늦었지만, 옛날 웹 브라우저가 최신 웹에서도 제대로 동작하게 만드는 분을 보니 반갑다는 말씀을 드리고 싶습니다.
https://www.sammystraus.com/#using-llms-to-make-the-emacs-web-browser-great-again
:) 쓸 만한 emacs 브라우저를 정말 오랫동안 꿈꿔 왔거든요
저도 그 얘기를 하려던 참이었습니다. 정작 중요한 내용을 파묻어 놓으셨네요! LLM으로 특정 웹사이트 전용의 정적 프로그램을 생성한다는 발상은 훌륭합니다. 두 번째 후타무라 사영이 떠오릅니다.
https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_projections
https://blog.sigfpe.com/2009/05/three-projections-of-doctor-futamura.html
저는 몇 가지 이유로(*) Anubis를 직접 만들어 쓰고 있는데, 정상 크롤러를 화이트리스트에 올려 둬도 전체 트래픽의 80% 넘게가 챌린지를 통과하지 못하는 봇입니다.
* 프록시로 앞에 세우지 않고 기존 앱 옆에서 같이 돌릴 수 있도록 elixir 버전이 필요했습니다. 이렇게 하면 기존 앱이 호출자가 이미 화이트리스트에 있는지 확인하고, 없으면 챌린저 https://sphinx.8by3.com 로 리디렉션합니다. 챌린지를 통과하면 거기서 원래 사이트(예: https://tuhat.net )로 돌려보냅니다.
직접 만드신다면 Anubis처럼 영리할 필요는 없을 겁니다. JS로 CPU를 꽤 먹는 작업이면 충분하고, 메모리까지 많이 먹게 만들 수 있다면 가산점입니다. 지금은 CPU를 많이 쓰는 작업이면 대부분의 봇이 실행을 포기합니다(웹의 상당 부분이 JS 없이는 접근 불가라 JS 자체는 많이 돌리지만요). 그리고 당신의 챌린지를 WASM 같은 걸로 최적화해 줄 일은 없습니다. 그 챌린지가 지켜 주는 사이트가 얼마 안 돼서 그럴 가치가 없거든요. 반면 Anubis의 챌린지는 널리 쓰이니 그렇게 최적화할 만할 수 있고, 그래서 그 프로젝트는 영리함 겨루기의 소모전에 갇혀 있습니다. 메모리 집약적인 문제와 JS보다 효율적인 무언가로 하루빨리 옮겨 가야 하는 게 분명하죠.
저도 기성품 대신 직접 구현하려는 가장 큰 이유가 두 가지 있습니다.
위에서 말한 점들
일부 집단에는 더 어려운 일을 시키는 심술을 부릴 수 있다는 점입니다(더 긴 챌린지, 봇은 신경도 안 쓸 시간 지연 추가 등). "안녕하세요, 북미 IP님. 관세를 사실상 직접 내는 걸 보니 번거로운 걸 정말 좋아하시나 봐요. 자, 제가 일을 좀 더 얹어 드릴게요!"
이런 생각을 하시는 걸 보니 미국 밖에 계신가 보네요.
그냥 "관세 때문에 당신네 나라에 화가 나서 대기 시간을 더 줍니다"라고 말하는 거나 마찬가지예요. 관세를 매기는 나라 사람들에게 이렇게 앙갚음하고 싶어진다는 건, 관세가 당신에게 어떤 식으로든 악영향을 줬다는 뜻이잖아요. 관세가 투표로 그걸 밀어붙인 관세 부과국 사람들이 '사실상 내는 것'이라는 당신 주장과는 맞지 않죠.
몇 가지 잘못 짚으셨습니다. 네, 저는 미국 밖에 있지만, 이 지지부진한 관세 다툼 때문에 겪은 불편은 전혀 없습니다. 미국 시민들이 관세 때문에 물가가 오른다고 불평하거나, 불평까지는 아니어도 필요한 고통이라고 받아들인다는 이야기는 들었고요. 저도 화나는 일이 꽤 많고 그중 일부는 지금 그쪽 행정부에서 비롯된 것이지만, 이번 건은 분명 아닙니다. 오히려 지금은 재미있어하는 중이고, 미국 쪽 사람들을 살짝 짜증 나게 하고 싶은 마음도 그 재미를 조금 더 이어 가려는 겁니다.
미니 게임이 있으면 좋겠어요! "5점 얻기" 같은 거요. 물론 ADA 준수에는 분명 어긋나겠지만요. ADA를 지키면서 이런 걸 실질적으로 효과 있게 만들 방법이 저는 잘 안 보입니다.
서버 로그에서는 LLM 트래픽의 종류를 구분할 수 있습니다. OAI-SearchBot, GPTBot, ClaudeBot은 색인만 하지만, ChatGPT-User, Claude-User 같은 건 사용자가 LLM과 대화하다가 생기는, 가치 있는 트래픽일 수 있습니다. 그러니 전부 차단하지 말고 어느 쪽을 막을지 골라 보는 게 좋습니다.