LLM 스크래핑 봇이 acme.com HTTPS 서버를 마비시키다
acme.com 운영자가 네트워크 단절 문제의 원인을 추적한 결과, 수많은 LLM 스크래핑 봇이 존재하지 않는 HTTPS 페이지를 무차별적으로 요청하면서 서버가 과부하에 걸린 것을 확인했습니다. 서버는 HTTPS(443포트)를 임시로 차단해 문제를 해결했지만, 이는 인터넷 전반으로 확산되는 무분별한 봇 트래픽의 심각성을 보여주는 사례입니다.
ACME 업데이트 2026년 4월 7일 HTTPS 서비스 중단
2월 25일부터 약 한 달 동안 acme.com은 간헐적인 네트워크 단절을 겪었습니다. 증상은 매우 높은 핑(ping) 지연 시간과 패킷 드롭이었습니다. 이러한 장애는 몇 시간 동안 지속되다가 잠시 사라지기를 반복했습니다.
문제는 인터넷 서비스 제공업체인 Sonic이 정기 유지보수를 진행하여 저를 새로운 네트워크로 이관한 직후에 시작되었습니다. 저는 Sonic 고객 지원 팀과 협력하여 이들의 네트워크 변경이나 새 네트워크를 위한 저의 설정 변경이 문제를 일으켰는지 확인하려고 노력했습니다. 제가 실수한 부분도 일부 발견했지만, 그것을 고친다고 장애가 해결되지는 않았습니다.
며칠 전, 또다시 장애가 발생한 새벽 1시에 불안감을 느끼던 중, 들어오는 트래픽을 더 면밀히 분석해보기로 했습니다. 그리고 몇 가지 흥미로운 사실을 발견했습니다. 들어오는 패킷의 거의 전부가 웹 요청이었습니다. 그중 거의 대부분이 존재하지 않는 페이지에 대한 요청이었습니다. 또한 80번 포트(HTTP)가 아닌 443번 포트(HTTPS)로 들어오는 요청이 압도적으로 많았습니다. 무엇보다 이 요청들의 User-Agent(사용자 에이전트)는 자신들이 LLM 스크래핑 봇임을 당당하게 표시하고 있었습니다.
저는 ACME에서 두 개의 웹 서버를 운영 중인데, 하나는 매우 빠른 HTTP 서버이고, 다른 하나는 다소 느린 HTTPS 서버입니다. 아마도 이 느린 HTTPS 서버가 요청 처리를 따라가지 못한 것 같았습니다. 이를 테스트해보기로 했습니다. 443번 포트를 차단한 것입니다. 그러자 문제가 즉시 사라졌고, 이후 재발하지도 않았습니다.
제가 추정하는 상황은 이렇습니다. 2월 25일 Sonic의 유지보수 이전에도 제 HTTPS 서버는 아슬아슬하게 요청을 감당하고 있었을 것입니다. 유지보수 과정에서 변경된 무언가(아마도 가용 대역폭이 증가한 것?)가 상황을 역전시켜 웹 서버가 종종 요청 처리에 뒤처지게 만든 것 같습니다. 특히 두 개 이상의 서로 다른 봇이 동시에 서버를 공격할 때 그랠 것입니다. 서버가 지연되면 혼잡이 natd(네트워크 주소 변화 데몬, Network Address Translation daemon)로 확산됩니다. natd마저 포화 상태에 이르면, 순식간에 패킷 지연 및 손실이 발생하게 됩니다.
HTTPS 서비스를 차단한 것은 분명 임시 방편에 불과합니다. 저도 HTTPS를 계속 제공하고 싶기 때문입니다. 하지만 생각보다 상황이 나쁘지는 않습니다. 정상적인 웹 트래픽 중 HTTP가 90%, HTTPS가 10%를 차지하므로 트래픽 손실은 최대 10%에 그칩니다. 물론, 조만간 근본적인 조치를 취할 계획입니다.
또한, 이 문제는 저만의 문제가 아닙니다. LLM 기업들이 저를 겨냥한 것이 아니라, 인터넷상의 모든 사이트를 무차별적으로 공격하고 있는 것입니다. 저는 이와 비슷한 이유로 문제를 겪고 있는 다른 취미 수준의 웹사이트 두 곳을 알고 있습니다. 누군가는 정말로 이 문제에 대해 조치를 취해야 합니다.
ACME 업데이트로 돌아가기.