FastAPI 백엔드 서버를 마비시키는 악성 크롤러 봇 완벽 방어기: Cloudflare WAF ASN 차단 및 딥 페이징(Deep Pagination) 제한

👤 인스피

조회 수 13

1. 진짜 사람과 악성 봇의 소름 돋는 로그 차이

일반적인 사람 유저가 브라우저를 통해 사이트에 접속하면, 화면을 렌더링하기 위해 HTML을 다운로드한 직후 수십 개의 썸네일 이미지 파일(.webp)을 연속으로 요청하게 됩니다. 반면, 악성 봇들의 로그는 매우 기형적이었습니다.

이들은 이미지는 단 한 장도 요청하지 않고, 1초 간격으로 page=81, page=180 등 일반 유저라면 절대 누르지 않을 게시판의 아득히 깊은 하단 목록까지 파고들며 HTML 텍스트 데이터만 무자비하게 긁어가고(Scraping) 있었습니다.

IP를 추적해 보니 3.221.61.12는 미국 Amazon AWS 데이터센터의 IP였고, 다른 IP들도 대부분 해외 클라우드 호스팅 업체의 가상 서버였습니다. 한국어로 된 IT 커뮤니티를 미국 AWS 서버에서 80페이지씩 넘겨가며 읽을 사람은 없습니다. 이는 100% 무단 크롤링 봇이었고, 이들이 무거운 DB 조회 쿼리를 1초에 수십 번씩 유발하며 서버를 죽이고 있었던 것입니다.

2. 방어 전략 1: Cloudflare WAF ASN 챌린지로 핀셋 판단하기

이러한 악성 봇들은 IP 주소를 무한대로 생성할 수 있기 때문에 개별 IP를 차단하는 것은 두더지 게임에 불과합니다. 가장 확실한 방법은 봇들이 서식하는 '클라우드 호스팅 업체' 자체를 묶어서 방어막을 치는 것입니다.

저는 Cloudflare의 WAF(웹 애플리케이션 방화벽) 커스텀 룰을 활용하여, 특정 ASN(Autonomous System Number, 자율 시스템 번호)을 타겟팅했습니다.

16509 (Amazon AWS)
14061 (DigitalOcean)
20473 (Vultr)
24940 (Hetzner)

위 ASN 대역에서 들어오는 트래픽에 대해 '관리형 챌린지(Managed Challenge)'를 부여했습니다. 파이썬 스크립트로 동작하는 멍청한 봇들은 클라우드플레어의 자바스크립트 보안 챌린지 화면을 뚫지 못하고 우주 밖으로 튕겨 나가게 됩니다.

3. 방어 전략 2: 구글 애드센스 심사 봇(Known Bots) 예외 처리

이 방어막을 칠 때 가장 주의해야 할 점은 "구글 봇(Googlebot)과 애드센스 심사 봇(Mediapartners-Google)이 튕겨 나가면 안 된다"는 것입니다. 이를 완벽하게 해결하기 위해 WAF 규칙에 Known Bots = Off (꺼짐) 조건을 추가했습니다. 즉, "아마존 서버에서 들어오면서, 동시에 구글 봇처럼 착하게 인증된 봇이 아닌 녀석들에게만 챌린지를 띄워라!"라는 완벽한 논리 구조를 완성했습니다. 이 설정 덕분에 애드센스 심사에는 단 0.1%의 악영향도 주지 않으면서 사이트를 보호할 수 있었습니다.

4. 방어 전략 3: 백엔드(FastAPI) 딥 페이징(Deep Pagination) 강제 제한

클라우드플레어가 앞단에서 막아주더라도, 우회해서 들어오는 봇들을 위해 백엔드 파이썬 코드(FastAPI) 단에서도 2차 방어막을 쳤습니다. 일반적인 유저 경험(UX) 상 특정 게시글을 보며 하단 목록을 15페이지 이상 넘기는 경우는 없습니다. 따라서 백엔드 로직에 if page > 15: 조건을 추가하여, 15페이지를 초과하는 비정상적인 호출이 들어오면 가차 없이 404 Not Found 에러를 뱉어내거나 1페이지로 강제 리다이렉트(Cap) 시켜버렸습니다.

이 조치는 단순히 봇을 막는 것을 넘어, 구글 봇의 크롤링 예산(Crawl Budget) 낭비를 막아 검색엔진 최적화(SEO) 점수를 대폭 끌어올리는 1등 공신이 되었습니다.

맺으며: 완벽한 평화를 되찾은 서버 터미널

모든 세팅을 마치고 서버 로그를 다시 모니터링했을 때, 저는 안도의 한숨을 내쉬었습니다. 지긋지긋했던 503 에러와 DB 타임아웃 로그는 완벽하게 자취를 감추었습니다. 대신 진짜 사람 방문자들이 정적 이미지 파일(.webp)을 호출하는 200 OK와 304 Not Modified 로그만이 평화롭게 흘러가고 있었습니다.

클라우드 환경에서 1인 개발자로 서비스를 운영하다 보면, 악성 트래픽과의 전쟁은 피할 수 없는 숙명입니다. 무작정 서버 사양(Scale-up)을 올려 비용을 낭비하기 전에, WAF를 통한 네트워크 계층의 방어와 백엔드 애플리케이션 계층의 로직 최적화(Pagination 캡)를 적절히 조화시키는 것이 진정한 엔지니어의 문제 해결 방식임을 뼈저리게 배울 수 있었습니다.

❓ 자주 묻는 질문 (FAQ)

Q1. 이미지 파일(webp)을 요청하지 않는 IP를 무조건 봇으로 간주하고 차단하면 안 되나요?

A. 절대 안 됩니다. 구글 검색 봇(Googlebot)이나 애드센스 심사 봇 역시 서버 부하를 줄이기 위해 HTML 텍스트만 긁어가고 썸네일 이미지는 다운로드하지 않는 경우가 많습니다. 또한, 재방문하는 일반 유저는 브라우저 캐시에 이미지가 저장되어 있어 HTML만 호출하기도 합니다. 이를 막으면 충성 유저와 구글 검색 노출을 모두 잃게 됩니다.

Q2. Cloudflare의 "I'm Under Attack" 모드를 켜면 봇을 쉽게 막을 수 있지 않나요?

A. 해당 모드를 켜면 사이트에 접속하는 모든 유저와 봇(구글 봇 포함)에게 5초 대기 화면(자바스크립트 챌린지)을 강제합니다. 이는 유저 경험(UX)을 심각하게 훼손하며, 애드센스 심사 봇이 사이트를 읽지 못해 심사에서 탈락하는 결정적인 원인이 되므로 상시 켜두는 것은 권장하지 않습니다.

Q3. 게시판 하단 목록의 페이지 수를 15페이지로 제한하면, 과거의 옛날 글들은 구글에 노출되지 않나요?

A. 그렇지 않습니다. 구글 봇은 게시판 하단의 1, 2, 3페이지 버튼을 일일이 눌러가며 글을 수집하는 것이 아니라, 우리가 구글 서치 콘솔에 제출한 sitemap.xml 파일을 지도로 삼아 모든 개별 게시글의 다이렉트 URL 주소로 직접 찾아 들어갑니다. 따라서 딥 페이징을 막는 것은 과거 글 노출에 아무런 악영향을 주지 않습니다.