Yandex 봇 트래픽이 하룻밤 사이에 99% 감소했습니다. 서버를 공격하는 AI 크롤러 측정 및 차단 방법

로이터와 BBC에 따르면 지난 주말 Yandex의 다섯 데이터 센터 중 두 곳이 우크라이나 드론 공격을 받았습니다. 하루 만에 Cloudflare의 트래픽 데이터는 Yandex 네트워크에서 오는 봇 트래픽이 최근 최대치 대비 0.4%까지 떨어졌음을 보여주었습니다. 몇 주 동안 사이트를 집중적으로 공격하던 크롤러 군단은 하룻밤 사이에 사라졌고, 그 전후 비교 차트는 Hacker News 상위권에 오르며 600점 이상의 점수를 받았습니다.

전쟁 이야기가 핵심이 아닙니다. 중요한 것은 이 차트들이 증명한 바입니다. 단일 봇 네트워크가 트래픽의 큰 부분을 차지할 수 있으며, 대부분의 사람들은 이를 확인하지 않는다는 것입니다. AI 크롤러 볼륨은 폭발적으로 증가하고 있습니다. HUMAN Security의 '2026년 벤치마크 리포트'는 1경(quadrillion)이 넘는 상호작용을 분석하여, AI 기반 트래픽이 2025년에 거의 세 배로 증가했으며 AI 에이전트 트래픽은 7,851% 성장했다고 밝혔습니다. 이 트래픽은 Cloudflare 대시보드가 아닌 원본(origin) 서버에 도달하며, 누군가가 CPU 비용을 지불합니다.

이 글은 두 부분으로 구성되어 있습니다. 첫째는 접근 로그만 사용하여 실제로 서버를 공격하는 것을 측정하는 10분짜리 방법입니다. 둘째는 이에 대해 무엇을 할지 결정하는 경로를 제시하며, 그 마지막에는 GNOME의 GitLab, kernel.org, Arch wiki, Codeberg, FFmpeg 인프라 앞에 자리 잡은 오픈 소스 작업 증명(proof-of-work) 프록시인 Anubis가 있습니다.

시작하기 전에 전체 공개 고지 사항이 있습니다: 아래 측정 명령어는 제가 제 서버에서 사용하는 표준 로그 분석이지만, 저는 개인적으로 Anubis를 운영 환경에 적용해 본 적은 없습니다. 여기에 언급된 모든 내용은 Anubis의 소스 코드, 문서 및 마지막에 나열된 공개 발표 자료에서 가져온 것입니다. 이것을 전쟁 이야기가 아닌 연구 기반 분석으로 간주해 주십시오.

파트 1: 차단하기 전에 측정하기

가장 많은 트래픽을 발생시키는 사용자 에이전트를 찾으세요. 사이트가 nginx나 Caddy 뒤에 있다면, 접근 로그에 이미 답이 들어 있습니다. 이 한 줄 명령어는 요청 수별로 상위 클라이언트를 순위화합니다:

awk -F'"' '{print $6}' /var/log/nginx/access.log \
  | sort | uniq -c | sort -rn | head -20

Field 6은 기본 조합 형식에서 User-Agent를 나타냅니다. 트래픽이 적은 개인 사이트라면 다소 불편한 것을 예상해야 합니다: 본인 모니터링, 몇몇 검색 엔진, 그리고 Bytespider, meta-externalagent, Amazonbot, PerplexityBot, anthropic-ai와 같은 이름들의 벽입니다. 이들 중 상당수는 자신들을 정직하게 식별합니다. 다른 일부는 브라우저 문자열을 보내고 당신이 확인하지 않기를 바랍니다.

AI 크롤러를 검색 엔진과 분리하세요. 이 구분이 중요한 이유는 Googlebot을 차단하는 것이 실제 비용을 수반하기 때문입니다. 커뮤니티에서 유지 관리하는 ai.robots.txt 프로젝트는 AI 크롤러의 user agent 문자열을 추적하며, Anubis는 이로부터 동기화된 블랙리스트를 배포합니다: AI2Bot, Bytespider, Claude-Web, cohere-ai, Diffbot, DuckAssistBot, FacebookBot, FirecrawlAgent, GoogleOther, meta-externalagent, omgili, PerplexityBot, Perplexity-User, TikTokSpider, YouBot 등 수십 가지가 있습니다. 이들의 비중을 다음과 같이 계산할 수 있습니다:

grep -ciE "bytespider|perplexitybot|amazonbot|meta-externalagent|anthropic-ai|claude-web|omgili|youbot|firecrawl" \
  /var/log/nginx/access.log
wc -l < /var/log/nginx/access.log

첫 번째 숫자를 두 번째 숫자로 나눕니다. 만약 AI 크롤러가 요청의 5% 미만이라면, 아마도 robots.txt 업데이트 이상의 조치가 필요하지 않을 것입니다. 하지만 그 비율이 30%라면, 계속 읽어보세요.

양(amount)뿐 아니라 무엇을 크롤링하는지 확인하세요. 이것이 크롤러가 성가신 존재인지 아니면 위협인지를 결정하는 부분입니다:

awk -F'"' '$6 ~ /[Bb]ot|[Ss]pider|[Cc]rawl/ {print $2}' /var/log/nginx/access.log \
  | awk '{print $2}' | sort | uniq -c | sort -rn | head -15

AI 크롤러들은 비용이 많이 드는 페이지를 좋아합니다. git forge의 경우 이는 diff 및 blame 뷰를 의미하며, 문서화 사이트의 경우 모든 페이지의 모든 개정판을 의미합니다. Anubis를 개발한 개발자 Xe Iaso는 Amazon 크롤러가 robots.txt 규칙을 우회하여 자동화된 클라이언트들을 비용이 많이 드는 엔드포인트에서 막으려 했음에도 불구하고, 자체 호스팅 Gitea 인스턴스를 정확히 이런 방식으로 분해해 나간 후에 이 도구를 작성했습니다. 모든 링크를 따라가는 크롤러는 의도치 않게 서비스 거부(denial of service)와 동일한 효과를 냅니다.

파트 2: 에스컬레이션 사다리 (The escalation ladder)

1단계: robots.txt. 무료이며 즉각적이고, 대부분의 주요 AI 크롤러들(현재 옵트아웃 토큰을 게시하는)에게는 잘 작동하는 크롤러들이 준수합니다. Google-Extended, GPTBot, ClaudeBot, PerplexityBot 모두 이를 존중합니다. 문제는 이를 따르지 않는 크롤러들과 아예 브라우저 사용자 에이전트를 위장하는 크롤러들입니다. robots.txt는 통제가 아니라 요청(request)일 뿐입니다.

2단계: 속도 제한 (Rate limiting). nginx의 limit_req 또는 Caddy의 속도 제한 모듈은 IP당 피해를 제한할 것입니다. 이는 단일 출처 플러드에는 잘 작동하지만, 대형 AI 크롤러들이 실제로 사용하는 패턴인 IP 범위를 순환하는 분산 크롤러에게는 효과가 떨어집니다.

3단계: 웹 애플리케이션 방화벽 또는 Cloudflare. 이미 Cloudflare 뒤에 있다면, 그들의 봇 전투 모드(bot fight mode)가 이 중 상당 부분을 다루므로 더 이상 읽으셔도 됩니다. 모든 트래픽을 다른 사람의 엣지(edge)를 통해 라우팅할 수 없거나 원하지 않는 경우는 Anubis가 만들어진 바로 그 경우입니다: 자체 호스팅 인프라, 일반 상업용 호스팅, 그리고 대시보드나 6자리 수 계약을 원하지 않는 운영자들.

4단계: Anubis. 프로젝트의 README에 적힌 말로 '핵전력 옵션(nuclear option)'이며,

Anubis는 에지 서버와 애플리케이션 사이에 리버스 프록시(reverse proxy)로 작동하는 단일 Go 바이너리입니다. 이 프로그램은 YAML 정책 파일을 읽고 모든 요청을 ALLOW, DENY, CHALLENGE, 또는 WEIGH 네 가지 액션 중 하나로 분류합니다. 흥미로운 부분은 '챌린지(challenge)'가 무엇인지에 있습니다.

작업 증명(proof-of-work) 게이트. 요청이 브라우저처럼 보일 때, 즉 사용자 에이전트(user agent)에 "Mozilla"라는 문자열을 포함하고 있을 때 Anubis는 콘텐츠 대신 인터스티셜 페이지를 제공합니다. 이 페이지는 방문자의 브라우저가 충분한 수의 선행 0진수(leading zero hex digits)로 시작하는 SHA-256 해시값을 계산하도록 만듭니다. 기본 난이도는 4이며, 이는 16개의 선행 0비트, 즉 대략 65,000개의 예상 해시를 의미합니다. 현대 데스크톱에서는 1~2초가 걸립니다. 휴대폰에서는 최대 15초까지 걸릴 수 있습니다. JavaScript 엔진이 없는 일반 HTTP 클라이언트의 경우 불가능하며, 이것이 진정한 게이트입니다. 즉, 최신 JavaScript를 실행할 수 없는 크롤러는 쿠키를 받지 못하고 콘텐츠를 볼 수 없습니다.

가장 많은 작업을 수행하는 지루한 부분. 기본 정책은 이름으로 전체 ai.robots.txt 블랙리스트를 거부하고 Google, Bing, DuckDuckGo, Internet Archive, Kagi 및 더 이상 화나게 하고 싶지 않은 다른 검색 엔진을 허용합니다. 대부분의 AI 크롤러가 정직하게 자신을 식별하기 때문에, 이 블랙리스트는 해싱이 발생하기도 전에 대량의 AI 트래픽을 차단합니다. 작업 증명은 자신의 신원을 속이는 모든 것에 대한 세금입니다.

HTTP 200 트릭. 여기서 제가 정말 재미있다고 느끼는 세부 사항이 있습니다. Anubis가 요청을 거부하거나 챌린지할 때, 403이 아닌 HTTP 200 OK로 응답합니다. 배포된 설정 파일의 주석에는 그 이유가 설명되어 있습니다. 공격적인 스크래퍼들은 정말로 200을 원하며, 다른 모든 것을 일시적 오류로 간주하고 더 강하게 재시도하기 때문입니다. 기사 대신 jackal 마스코트가 있는 200 응답을 주면, 그들의 상태 머신(state machine)은 페이지를 가져온 것으로 표시하고 넘어갑니다. 사용자의 HTML 파이프라인은 가짜 심오한 쓰레기 데이터(pseudoprofound gibberish)를 받게 되고, 크롤러는 그 차이를 알지 못합니다.

솔직하게 밝히는 비용. 배포하기 전에 알아야 할 세 가지 문제가 있습니다:

• 피드 리더 및 링크 미리보기. RSS 가져오기(fetchers), Slack unfurls, 가동 시간 모니터링 도구는 JavaScript를 전송하지 않습니다. 따라서 피드 경로에 대한 명시적 허용 규칙을 추가하고 IP를 모니터링해야 하며, 그렇지 않으면 해당 도구들이 귀하의 사이트를 다운되었다고 보고할 수 있습니다.
• 기본적으로 수평 확장 불가. Anubis는 시작할 때마다 새로운 Ed25519 키 쌍(keypair)을 생성하며, 인스턴스 간에 이를 공유하는 내장 기능이 없습니다. 로드 밸런서 뒤에 두 개의 인스턴스를 실행하더라도 한쪽에서 발급된 쿠키가 다른 쪽에서 거부됩니다. 재시작 또한 모든 보류 중인 쿠키를 무효화시키므로, 정기적인 배포는 모든 리더들에게 다시 인증(re-challenge)을 요구합니다.
• 집요한 공격자는 우회할 수 있습니다. 보안 연구원 Tavis Ormandy는 무료 Google Cloud VM에서 약 6분 만에 약 11,000개의 Anubis 배포 환경의 인증 절차를 해결하는 것을 시연했습니다. 헤드리스 Chromium은 인간 브라우저가 하는 것과 정확히 같은 방식으로 이 인증 절차를 해결합니다. 이를 운영하는 사람들 사이의 일반적인 의견은 Anubis가 인증 시스템이 아니라 부하 분산(load-shedding) 도구라는 것입니다. 이는 대부분을 차지하는 게으르고 대량 트래픽 크롤러는 막지만, 예산을 가진 표적 공격자는 막지 못한다는 것입니다.

최소 배포 구성

표준적인 배치는 엣지(edge)에 Caddy 또는 nginx를 두고, 그 뒤에 Anubis를 배치하며, 앱을 그 뒤에 두는 방식입니다. Docker Compose를 사용하면 다음과 같습니다:

services:
  anubis:
    image: ghcr.io/techarohq/anubis:latest
...

정책 파일(policy file)에 결정 사항이 담겨 있습니다. 합리적인 시작점은 다음과 같습니다:

bots:
  - name: well-known
    path_regex: ^/.well-known/.*$
...

위에서 아래로 읽어보면, 배관 경로(plumbing paths)는 통과되고, 알려진 AI 크롤러들은 가짜 200 응답 거부(fake-200 denial)를 받으며, 브라우저라고 주장하는 모든 것은 주간당 하나의 해시 퍼즐을 받게 됩니다. 이는 통과된 인증 쿠키가 7일 동안 유효하기 때문입니다. 만약 이미 AI 봇 차단 목록으로 가득 찬 robots.txt 파일을 유지하고 있다면, Anubis는 동일한 목록을 두 번 유지할 필요가 없도록 robots2policy 변환기를 제공합니다.

최신 버전에는 WEIGH 액션이 추가되어 규칙에 의심 점수(suspicion points)를 더하고 빼고, 임계값(thresholds)을 총점에 적용하여 점점 더 어려운 도전 과제를 만듭니다. 이는 모든 상용 봇 공급업체가 사용하는 요청 점수화 아키텍처(request-scoring architecture)의 경량 버전이며, 오픈 소스로 진화하고 있습니다.

제가 실제로 할 일

2026년 10월에 작은 사이트나 자체 호스팅 서비스라면 다음 순서로 진행해야 합니다:

• 먼저 측정합니다. 위의 로그 분석을 실행하세요. 한 번도 살펴본 적 없는 숫자에 대해서는 방어할 수 없으며, Yandex 차트는 이 플릿(fleets)들이 누구나 생각하는 것보다 훨씬 클 수 있음을 증명했습니다.
• robots.txt와 속도 제한(rate limits)부터 시작합니다. AI 크롤러 점유율이 적당하다면 이것만으로 충분하며 비용이 들지 않습니다.
• 실제 부하가 걸릴 때에만 Anubis로 확대합니다. 트레이드오프를 받아들이세요. 피드와 모니터를 허용 목록(allowlist)으로 지정하고, 단일 인스턴스를 실행하며, 이것이 벽이 아니라 속도 저해 장치임을 인식해야 합니다.
• AI 크롤러에게 화풀이하듯 검색 엔진을 절대 차단하지 마세요. Google, Bing, DuckDuckGo를 위한 허용 목록은 도전 과제를 받는 검색 봇들이 우회하여 작동하기 때문에 존재하며, 이는 작은 사이트가 감수해서는 안 될 거래입니다.

지난 주말의 더 깊은 이야기는 불편합니다. 우리는 대부분의 요청이 기계가 기계와 대화하는 웹을 구축했으며, 2달러 VPS를 운영하는 사람이 이제 보안팀의 업무였던 트래픽 분류(traffic triage)를 하고 있습니다. Anubis는 한 개발자가 이에 대응하여 만든 것이며, GNOME, kernel.org, Codeberg에 의해 빠르게 채택되고 있다는 것은 이 문제가 현실임을 보여줍니다. 필요하기 전에 자체 로그를 측정하세요.

여러분의 트래픽 중 봇이 차지하는 비율을 알고 계신가요? 원라인(one-liner)을 실행하고 발견한 내용을 댓글로 알려주세요. 제가 숫자를 수집하고 있습니다.

출처: Yandex 데이터 센터 공격에 대한 로이터(Reuters)와 BBC 보도, Tom's Hardware를 통한 Cloudflare 트래픽 데이터, HUMAN Security의 2026년 AI 트래픽 현황 보고서, Anubis 프로젝트 문서 및 소스 코드(github.com/TecharoHQ/anubis), 그리고 ai.robots.txt 크롤러 목록.