Read the Docs DDoS, AI 크롤러 시대의 인프라 경고

분당 550만 요청은 공개 문서 사이트에도 온다

Read the Docs의 사고 분석은 2026년 6월 중하순 발생한 자사 역사상 최대 DDoS를 다룬다. 공격은 거의 열흘 동안 이어졌고, 정점에서는 분당 550만 요청을 기록했다. 이는 평소 일일 피크인 분당 10만 요청 미만의 약 100배 수준이다. 공격자는 단순 트래픽 홍수가 아니라 캐시를 우회하는 경로, 404, 302 리다이렉트, 로그인 대시보드까지 노렸다.

흥미로운 점은 Read the Docs가 원래 문서 크롤링에 관대했던 서비스라는 사실이다. 공개 문서 호스팅은 검색엔진, 패키지 색인, 개발 도구, 기업 봇이 합법적으로 많이 방문한다. 그러나 글은 AI 크롤러가 늘어난 최근 2년 사이 대규모 스크래핑과 공격의 경계가 흐려졌다고 설명한다. AI 검색 최적화, 가짜 권위의 새 공급망이 다룬 AI 검색 생태계의 부작용이 인프라 비용으로도 나타난다.

공격자는 캐시 미스를 찾아낸다

이번 공격의 특징은 전 세계 수백 개 네트워크와 수백만 고유 IP, HTTP 헤더와 TLS 파라미터 랜덤화, Cloudflare 자동 방어 일부 우회, 캐시되지 않는 URL 집중이었다. Read the Docs는 Cloudflare의 Under Attack Mode처럼 모든 방문자에게 자바스크립트 챌린지를 걸 수 있었지만, API 통합과 정상 문서 독자를 깨뜨리지 않기 위해 표적형 rate limit과 challenge를 선택했다.

캐시되는 200 응답은 상대적으로 싸다. 문제는 캐시되지 않는 404, 임시 리다이렉트, 검색, 동적 대시보드다. 공격자는 CDN 응답 속도를 보고 어떤 요청이 origin까지 가는지 찾아낸다. 한때는 Python backend가 처리하던 302 리다이렉트가 병목이 됐고, 팀은 30분 안팎에 해당 처리를 Cloudflare edge로 옮겼다. Cloudflare DDoS 문서와 Cloudflare Rate Limiting이 말하는 엣지 방어가 추상론이 아니라 생존 조건이 된 사례다.

Terraform으로 WAF를 운영한 이유

Read the Docs는 Cloudflare 규칙을 Terraform으로 관리한다고 밝혔다. 공격 중 WAF와 rate limit 규칙은 수십 개가 될 수 있고, IP, ASN, 호스트명, 하위 도메인, 브라우저 fingerprint 조합을 빠르게 바꿔야 한다. 수동 콘솔 변경은 사고 뒤 설명하기 어렵다. Terraform 공식 문서는 이런 인프라 변경을 코드 리뷰와 버전 관리 대상으로 만든다.

글에서 가장 실용적인 개념은 penalty box다. 정상 사용자는 성공 응답이 많고, 공격성 봇은 비싼 404와 리다이렉트를 많이 만든다. 그래서 단순 출처가 아니라 요청의 모양과 실패율을 보고 제한 대상을 고른다. 이는 Rails CVE 공격, 패치 속도가 보안 체계다가 말한 자동화된 방어 속도와도 연결된다. 방어 규칙이 코드화되어야 공격 패턴 변화에 맞춰 운영할 수 있다.

한국 서비스가 배워야 할 것

국내 SaaS, 개발자 문서, API 포털, 공공 데이터 사이트도 같은 문제를 만날 수 있다. AI 학습과 검색 수요가 커질수록 문서와 API는 더 많이 긁힌다. 모든 봇을 막으면 검색성과 생태계가 죽고, 모두 허용하면 비용과 장애가 커진다. vLLM의 AMD speculative decoding, 추론비 경쟁의 다음 축이 추론 비용을 다뤘다면, Read the Docs 사례는 지식 인프라를 공급하는 쪽의 비용을 보여준다.

실무 체크리스트는 명확하다. 404와 302도 캐시 가능한지 본다. origin에 닿는 검색과 동적 엔드포인트를 계측한다. Cloud ASN과 residential proxy를 구분한다. 정상 API 사용자에게 우회 경로를 제공한다. WAF 규칙을 코드로 관리한다. 무엇보다 장애 대응 문서에 AI 크롤러와 proxy network를 별도 시나리오로 넣어야 한다. OWASP Automated Threats도 자동화 트래픽을 사용자 행동과 분리해 다루라고 조언한다.

자주 묻는 질문

Q1: 이번 공격은 단순 AI 크롤러였나요?

A: 글은 DDoS 공격으로 설명합니다. 다만 AI 크롤러와 proxy network가 자동화 트래픽 비용을 키우는 배경으로 언급됩니다.

Q2: 왜 404와 302가 위험한가요?

A: 캐시되지 않으면 origin 서버가 직접 처리해야 하고, 공격자가 고유 경로를 계속 만들면 비용과 부하가 빠르게 증가합니다.

Q3: 모든 사용자에게 챌린지를 걸면 해결되나요?

A: 일시적으로는 도움이 되지만 API 통합과 정상 문서 독자에게 큰 마찰을 줍니다. Read the Docs는 표적형 제한을 택했습니다.

Q4: IP 차단은 왜 부족한가요?

A: 공격이 수백만 IP와 다양한 네트워크로 분산되면 단순 IP 기준은 정상 사용자 오탐을 만들거나 효과가 약합니다.

Q5: 작은 팀이 당장 할 수 있는 대응은 무엇인가요?

A: CDN 캐시 범위를 넓히고, 404·302·검색 같은 캐시 미스 표면을 계측하며, WAF와 rate limit 규칙을 코드로 관리하는 것부터 시작할 수 있습니다.