TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 25 READS

HN에 올렸더니 AI 봇이 서버를 삼켰다 — 실측으로 본 크롤러 대응

개인 개발자가 자신이 만든 서비스를 해커뉴스(HN)에 올리는 일은 흔하다. 피드 리더 sprinklz.io를 운영하는 샘미 스트라우스도 그랬다. 이 서비스는 뉴스 피드에서 특정 주제의 우선순위를 낮출 수 있는 맞춤형 리더로, '이제 LLM 이야기는 지겹다'는 정서와 맞물려 약 100개의 추천을 받으며 반응을 얻었다. 그런데 주목을 받은 직후부터 사이트가 눈에 띄게 느려졌고, 게시 며칠 뒤에는 오히려 더 심해졌다. 접속한 실사용자는 소수의 로그인 유저에 불과한데 서버 부하는 비정상적으로 높았다. 트래픽 급증의 단순한 후유증으로 보기엔 지표가 앞뒤가 맞지 않았다.

원인을 찾기 위해 그는 모든 엔드포인트에 요청 횟수를 기록하는 최상위 로깅을 추가했다. 결과는 분명했다. 요청의 상당수가 애초에 뉴스 기사를 불러오려는 시도조차 하지 않았던 것이다. 이 사이트는 단일 페이지 애플리케이션(SPA)으로 만들어져 있어 화면을 실제로 렌더링하려면 자바스크립트가 실행돼야 하는데, 대부분의 요청은 그 자바스크립트를 돌리지도 않았다. 사람이 브라우저로 들어와 콘텐츠를 보는 트래픽이 아니라, HTML만 긁어 가는 자동화된 접근이 부하의 실체였다는 뜻이다.

범인은 'AI 요약 뉴스레터'

NGINX 집계 로그를 더 파고들자 전체 트래픽의 절반 가까이가 단 하나의 출처에서 왔다는 사실이 드러났다. 저자가 확인해 보니 그 주체는 '웹사이트 변경을 감시해 AI 뉴스레터로 요약해 주는 서비스'를 표방하고 있었고, 여기서 '변경 감시'란 분당 수없이 많은 횟수로 사이트를 질의하는 것을 의미했다. 저자는 이 출처를 차단했다. 나머지는 자신을 정직하게 밝히는 표준 크롤러들이었다. 클로드 봇, OpenAI 봇, 구글 검색 인덱서 등이 식별자를 노출한 채 접근하고 있었다. 여기에 더해 취약점 스캐너도 섞여 있었는데, 워드프레스 사이트가 아님에도 /wp-content/phpinfo.php 같은 경로를 긁으려는 시도가 잡혔다.

대응과 그 한계

저자의 대응은 실무자에게 익숙하면서도 현실적이다. 먼저 robots.txt를 추가해 대부분의 AI 스캐너는 차단하되 구글봇과 검색 관련 트래픽은 허용했다. 검색 노출은 유지하면서 수집용 봇만 걸러내려는 선택이다. 또한 스캐너가 노리는 취약점 경로들을 클로드에게 직접 질의하고 스캐너의 동작을 흉내 내도록 시켜, 민감한 정보가 새어 나가는 곳이 없는지 점검했다. 마지막으로 합리적인 수준의 요청 속도 제한(rate limit)을 걸었다.

다만 여기에는 분명한 한계가 있다. robots.txt는 어디까지나 '권고'일 뿐 강제력이 없다. 정직하게 식별자를 밝히는 크롤러는 규칙을 따르겠지만, 문제의 핵심이었던 변경 감시형 서비스나 악의적 스캐너가 그 권고를 지킬 것이라는 보장은 없다. 결국 실질적인 방어선은 출처 기반 차단과 속도 제한이며, robots.txt는 선의의 봇에게만 유효한 1차 필터에 가깝다. 식별자를 위장하거나 IP를 분산하는 접근에는 또 다른 방어가 필요하다.

SPA 운영자가 새겨둘 교훈

이 사례가 한국 실무자에게 주는 시사점은 몇 가지로 정리된다. 첫째, 트래픽 이상이 감지될 때 전체 수치만 보면 오판하기 쉽다. '실사용자는 적은데 부하는 높다'는 괴리를 엔드포인트별 요청 수와 자바스크립트 실행 여부 같은 세분화된 로깅으로 쪼개 보면, 사람 트래픽과 봇 트래픽을 구분하는 결정적 단서가 나온다. 둘째, SPA 구조는 역설적으로 봇 판별에 유리한 신호를 준다. 콘텐츠를 보려면 반드시 자바스크립트가 돌아야 하는데, HTML만 받아 가고 렌더링 단계로 넘어가지 않는 요청은 사람이 아닐 가능성이 높기 때문이다.

셋째, 저자가 스스로 꼽은 가장 중요한 교훈은 방어가 아니라 성능이었다. 봇을 걸러내는 것과 별개로, 무거운 부하에서도 더 많은 실제 요청(QPS)을 안정적으로 소화하도록 사이트 자체를 빠르고 확장성 있게 만들어야 한다는 것이다. 그는 이 경험을 계기로 몇 주에 걸쳐 인프라를 개선했다고 밝혔다. AI 수집 봇이 일상이 된 환경에서 개인 서비스 운영자가 맞닥뜨리는 현실은 이중적이다. 한쪽에서는 요약·감시형 AI 서비스가 끊임없이 원본을 긁어 가고, 다른 쪽에서는 그 부담을 운영자가 고스란히 떠안는다. 차단 규칙과 속도 제한은 출혈을 막는 응급처치이고, 진짜 해법은 관측 가능성 확보와 견고한 인프라라는 점을 이 작은 사건이 압축해서 보여준다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://www.sammystraus.com/#i-posted-to-hn-and-then-my-webs...
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...