내 서버를 갉아먹는 AI 크롤러: robots.txt부터 데이터 독(Poisoning)까지 완벽 방어 가이드)

지난 30여 년간, 우리가 아는 인터넷을 지탱해 온 것은 거대한 해저 광케이블만이 아니었습니다.

그 이면에는 보이지 않는 ‘신뢰’라는 거대한 사회적 자본이 깔려 있었죠.

웹사이트 운영자(Publisher)와 검색 엔진(Search Engine) 사이에는 아주 오래된 암묵적 계약이 존재했습니다.

“내 콘텐츠를 가져가서 세상에 알려주세요. 그 대신, 나에게 트래픽(Traffic)을 보내주십시오.”

이 호혜적인 관계를 조율하던 유일한 규약은 robots.txt라는 아주 단순한 텍스트 파일 하나였습니다.

법적 강제성? 전혀 없습니다.

그저 디지털 생태계 구성원이라면 으레 지킬 것이라 믿었던 이 ‘신사협정’은 웹의 평화를 지키는 헌법과도 같았습니다.

하지만, 냉정하게 말해 이제 그 시대는 끝났습니다.

2023년 시작된 생성형 인공지능(Generative AI)의 폭발적인 성장은 이 오래된 평화 조약을 휴지 조각으로 만들어버렸습니다.

AI 기업들에게 웹 데이터는 더 이상 사용자에게 길을 안내해 주기 위한 ‘지도’가 아닙니다.

거대언어모델(LLM)의 지능을 높이기 위해 태워 없애야 하는 ‘연료’가 되어버린 것입니다.

우리는 지금 **‘디지털 공유지의 비극(Tragedy of the Digital Commons)’**이 실시간으로, 그것도 아주 파괴적인 규모로 펼쳐지는 현장을 목격하고 있습니다.

이 글에서는 AI 크롤러들이 어떻게 오픈소스 커뮤니티의 숨통을 조이고 있는지 심층 분석하고, 나아가 robots.txt를 통한 1차 방어선부터 Anubis와 Cloudflare를 활용한 능동적 방어 시나리오까지, 인프라 생존을 위한 실질적인 해법을 이야기해보려 합니다.

1. 인프라의 비명: 비용의 외부화와 공유지의 파괴

AI 기업들의 무차별적인 데이터 수집 경쟁, 겉으로는 기술 혁신처럼 보이죠?

하지만 경제학적인 관점에서 냉정하게 뜯어보면 이건 전형적인 **‘비용의 외부화(Externalization of Costs)’**입니다.

모델 학습으로 얻는 막대한 이익은 AI 기업이 독점하는데, 데이터를 처리하고 전송하는 인프라 비용은 비영리 단체나 오픈소스 프로젝트가 고스란히 떠안고 있는 기형적인 구조입니다.

실제 피해 사례를 통해 그 심각성을 뜯어보겠습니다.

1.1 SourceHut 사태: 연산을 훔치는 도둑들

오픈소스 소프트웨어 개발 플랫폼인 SourceHut의 설립자 드류 드볼트(Drew DeVault)가 겪은 일은 충격적입니다.

AI 크롤러가 단순한 ‘데이터 수집기’를 넘어 ‘컴퓨팅 자원 기생충’으로 변질되었음을 보여주는 결정적 사례이기 때문입니다.

I/O가 아닌 CPU를 노리는 공격

보통 구글봇(Googlebot) 같은 일반 검색 봇은 정적 페이지(HTML)를 긁어갑니다.

서버 입장에서는 파일을 읽어 보내주기만 하면 되니 부하가 크지 않습니다(I/O Bound).

그런데 SourceHut을 덮친 AI 크롤러들은 악의적일 정도로 교묘하게 고비용 엔드포인트를 노렸습니다.

공격 유형	세부 내용	기술적 부하의 실체
Git Blame 공격	소스 코드 파일뿐만 아니라 `git blame` 페이지 집중 호출	파일의 각 라인 수정 이력을 추적하기 위해 전체 커밋 히스토리를 역추적해야 함.
Git Log 공격	변경 로그 페이지의 무차별적 크롤링	방대한 로그 데이터를 정렬하고 필터링하는 과정에서 CPU 자원 극한 소모 (CPU Bound).
결론	컴퓨트 절도 (Compute Theft)	단순 대역폭 점유가 아닌, AI 데이터 정제를 위해 서버의 연산 능력(Computing Power)을 무단 차용함.

봇넷(Botnet)과 구별 불가능한 은신술

더 골치 아픈 건 공격의 출처였습니다.

단일 데이터 센터 IP가 아니라, **수만 개의 주택용 IP(Residential IP)**를 타고 들어왔습니다.

_일반 가정집 PC나 공유기를 해킹한 봇넷을 썼거나, 유료 주택용 프록시 서비스(Residential Proxy Service)로 신분을 세탁했다는 뜻_입니다.

이는 전통적인 IP 차단 방식을 무력화시킵니다.

1.2 Read the Docs와 73TB의 청구서: 무능이 낳은 재앙

기술 문서 호스팅 서비스인 ‘Read the Docs’의 사례를 보면, AI 기업들의 기술적 태만(Negligence)이 어떻게 금전적 피해로 이어지는지 적나라하게 드러납니다.

비용의 시각화: 2024년 5월, 단 하나의 봇이 하루 10TB, 한 달간 무려 73TB의 데이터를 긁어갔습니다. 이로 인해 발생한 **초과 대역폭 비용만 약 5,000달러(약 700만 원)**였습니다.

기술적 결함: 더 화가 나는 건, 해당 봇이 HTTP의 기본 캐싱 메커니즘을 완전히 무시했다는 점입니다.

\[ AI 봇의 기술적 결함 분석 \]

점검 항목	정상적인 봇 (Googlebot 등)	문제의 AI 봇	결과
If-None-Match	Etag를 확인하여 변경된 파일만 요청	사용 안 함	이미 다운로드한 파일도 매번 새로 받음
If-Modified-Since	마지막 수정일 이후 변경분만 요청	사용 안 함	3년 전 파일도 매일 새로 다운로드
QA 수행 여부	배포 전 철저한 로직 검증	미수행	기본적인 품질 관리 없이 배포됨

1.3 지정학적 차단: 브라질이 사라진 이유 (Geo-blocking)

리눅스 배포판 페도라(Fedora) 프로젝트는 브라질 IP 대역에서 쏟아지는 스크래핑 공격으로 인프라가 마비될 지경에 이르렀습니다.

조사 결과, 브라질 내 보안이 취약한 IoT 기기들이 ‘Aisuru’라는 봇넷에 감염되어 AI 데이터 수집용 좀비 군단으로 악용되고 있었습니다.

결국 페도라 팀은 **‘브라질 전체 트래픽 차단(Geo-blocking)’**이라는 극단적 조치를 취했습니다.

디지털 공간의 기술적 문제가 물리적 국경의 폐쇄로 이어지는, 마치 디스토피아 영화의 한 장면 같은 현실이 벌어진 것입니다.

2. 실전 방어 전략 I: robots.txt 최적화 및 한계 극복

아직도 많은 웹마스터들이 User-agent: * 하나로 모든 걸 해결하려 합니다.

하지만 지금 같은 AI 크롤러 전성시대에 이건 대문을 활짝 열어두고 “도둑님, 들어오세요” 하는 것과 같습니다.

가장 기본이지만 필수적인 1차 방어선, robots.txt부터 현대적으로 재설계해야 합니다.

2.1 AI 방어용 robots.txt 핵심 차단 목록

AI 봇들은 꽤 자주 별도의 사용자 에이전트(User-Agent) 이름을 달고 활동합니다.

아래 표는 반드시 차단해야 할 주요 AI 봇들의 목록입니다.

User-Agent 명	소유 기업 / 서비스	차단 이유 및 특징
GPTBot	OpenAI (ChatGPT)	가장 일반적인 LLM 학습 데이터 수집 봇.
ChatGPT-User	OpenAI	ChatGPT의 ‘브라우징’ 기능 사용 시 작동하는 봇.
CCBot	Common Crawl	대부분의 LLM이 기초 데이터셋으로 사용하는 대규모 크롤러.
anthropic-ai	Anthropic (Claude)	Claude 모델 학습을 위한 데이터 수집.
Google-Extended	Google (Gemini 등)	검색 노출은 유지하되, AI 학습만 선택적으로 차단할 때 사용.
Bytespider	ByteDance (TikTok/Doubao)	공격적인 성향이 매우 강함. 서버 부하의 주범 중 하나.
FacebookBot	Meta (Llama 등)	Llama 시리즈 등 Meta의 AI 모델 학습용.
Amazonbot	Amazon	Alexa 및 Bedrock 모델 학습용.

2.2 권장 robots.txt 설정 코드

위의 분석을 바탕으로, 여러분의 서버에 즉시 적용 가능한 최적화된 설정값을 제공합니다. 복사해서 사용하세요.

Plaintext

User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: FacebookBot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Amazonbot
Disallow: /

# [중요] 모든 봇에 대해 고비용 연산 페이지 원천 차단
User-agent: *
Disallow: /git/blame/       # 리소스 소모가 큰 경로 (CPU 부하 방지)
Disallow: /search/          # 내부 검색 결과 페이지
Disallow: /admin/           # 관리자 페이지
Crawl-delay: 10             # (참고) 일부 '착한' 봇만 준수하지만 설정 권장

2.3 robots.txt의 치명적 한계

위 설정은 필수지만, 안타깝게도 완벽하진 않습니다.

자발적 준수: robots.txt는 법이 아니라 ‘요청’입니다. 악성 AI 스타트업이나 해커들이 만든 스크래퍼는 이를 100% 무시합니다.
User-Agent 스푸핑: 악성 봇은 자신의 이름을 Mozilla/5.0 (Windows NT 10.0...) 같이 일반 크롬 브라우저인 척 위장해서 들어옵니다.

결국 robots.txt는 ‘문패’일 뿐이고, 실제로 침입자를 막으려면 ‘자물쇠(기술적 방어)’가 필요합니다.

3. 실전 방어 전략 II: 기술적 방어 도입 시나리오

단순 차단을 넘어, 시스템 자원을 보호하고 봇을 무력화하기 위한 구체적인 시나리오를 규모별로 정리했습니다.

3.1 시나리오별 기술적 방어 솔루션 비교

구분	시나리오 A: 중소규모/오픈소스	시나리오 B: 엔터프라이즈/미디어
권장 솔루션	Anubis (작업 증명 미들웨어)	Cloudflare WAF & AI Labyrinth
주요 대상	개인 블로그, 오픈소스 커뮤니티	언론사, 대형 쇼핑몰, 플랫폼 기업
핵심 기술	Proof-of-Work (PoW)	Honey Pot & Data Poisoning
작동 원리	접속하려는 클라이언트에게 암호학적 퍼즐(SHA-256 해시 찾기)을 제시하고 풀어야만 접속 허용.	봇을 감지하면 가짜 데이터가 있는 ‘미궁’으로 리다이렉트하여 무한 루프에 빠뜨림.
방어 효과	봇의 CPU 자원을 강제로 소모시켜 채산성을 떨어뜨려 포기하게 만듦.	학습 데이터를 오염시켜 AI 모델에 환각(Hallucination)을 유발, 강력한 억제력 제공.
비용	저렴함 (오픈소스 활용 가능)	비용 발생 (엔터프라이즈 플랜 필요)

시나리오 A 상세: Anubis의 난이도 조절 전략

Anubis는 트래픽 상황에 따라 퍼즐의 난이도를 조절합니다.

일반 모드: 해시 앞자리 4개가 0이어야 함 (사람은 0.5초, 봇에게는 부담 시작).

방어 모드: 트래픽 급증 시 해시 앞자리 5~6개가 0이어야 함. 봇의 연산 부하가 기하급수적으로 증가하여 공격을 지속할 수 없게 만듭니다. (단, Google 등 주요 검색엔진 IP는 화이트리스트 처리 필수)

시나리오 B 상세: Cloudflare의 AI 미궁과 데이터 오염

Cloudflare Workers를 활용하여 비인가 봇이 감지되면 실제 콘텐츠 대신 AI가 실시간 생성한 가짜 페이지로 보냅니다.

보이지 않는 링크(Invisible Links): 봇만 볼 수 있는 링크를 심어 무한히 그 안을 맴돌게 합니다.

데이터 오염(Data Poisoning): 팩트와 다른 미묘한 거짓 정보를 섞습니다. 이를 학습한 AI 모델은 성능이 저하되므로, AI 기업에게 가장 두려운 반격이 됩니다.

4. 프로토콜의 재정립: 허가형 웹(Permissioned Web)의 도래

이런 기술적 난타전 끝에, 인터넷의 근본적인 구조가 바뀌고 있습니다.

‘누구나 접근 가능한 개방된 웹’에서 **‘신원이 증명된 자만 접근할 수 있는 계약된 웹’**으로의 거대한 전환입니다.

4.1 “IP를 잊어라”: 암호학적 신원 증명 (Web Bot Auth)

클라우드플레어는 최근 “IP 기반 차단의 시대는 끝났다"고 선언하며 ‘Web Bot Auth’ 표준을 제안했습니다.

작동 원리: 봇 개발자는 자신의 신원을 증명할 수 있는 개인키로 HTTP 요청 헤더에 서명(Signature-Input)을 합니다. 웹사이트는 공개키로 이를 검증합니다.

의의: 이제 IP 스푸핑은 통하지 않습니다. “이게 정말 OpenAI의 봇이 맞나?“를 수학적으로 검증할 수 있게 된 것입니다. 인터넷이 ‘익명 신뢰’에서 ‘검증된 신뢰(Zero Trust)’로 이동하고 있다는 신호입니다.

4.2 Pay-Per-Crawl: 데이터의 자산화

Pay-Per-Crawl

2025년 7월, 클라우드플레어가 런칭한 ‘Pay-Per-Crawl’ 모델은 타임(TIME), 포춘(Fortune) 같은 대형 미디어가 AI 기업에게 공식적으로 돈을 받고 데이터를 파는 시대를 열었습니다.

결국 인터넷은 두 갈래로 쪼개지고 있습니다.

돈을 낸 AI만 접근 가능한 ‘프리미엄 웹’과, 봇과 가짜 데이터가 뒤엉킨 ‘정크 웹’.

씁쓸하지만 피할 수 없는 현실입니다.

5. 결론: 디지털 성벽을 높여야 할 때

SourceHut과 Read the Docs의 사례는 더 이상 robots.txt라는 종이 방패에 의존해서는 인프라를 지킬 수 없음을 명확히 보여주었습니다.

AI 기업의 탐욕스러운 데이터 크롤링은 멈추지 않을 것입니다.

이제 방어는 선택이 아니라 생존의 문제입니다.

웹사이트 운영자 여러분, 지금 당장 다음 조치를 취하시길 권합니다.

즉시 점검: robots.txt를 열어 위에서 언급한 명시적인 AI 봇 차단 규칙을 추가하십시오.

로그 분석: 자신의 트래픽 로그를 분석해서 비정상적인 사용자 에이전트와 고비용 엔드포인트(git blame 등) 접근이 없는지 확인하십시오.

방어 도입: 규모에 맞는 기술적 방어 솔루션(Anubis 또는 Cloudflare WAF) 도입을 진지하게 검토하십시오.

우리는 지금 인터넷의 재설계(Re-architecture) 과정을 목격하고 있습니다.

IP 주소는 신뢰를 잃었고, 데이터는 유료 자산이 되었습니다.

이 거친 변화의 파도 속에서, 강력한 기술적 방어막을 구축한 자만이 자신의 디지털 영토를 온전히 지켜낼 수 있을 것입니다.

참고자료

DeVault, D. (2025). “Please stop externalizing your costs directly into my face.” Drew DeVault’s Blog.
The Register. (2025). “AI crawlers haven’t learned to play nice with websites.”
Search Engine Journal. (2025). “AI Crawlers Are Reportedly Draining Site Resources & Skewing Analytics.”
Read the Docs. (2024). “AI crawlers need to be more respectful.”
Cloudflare Blog. (2025). “Trapping misbehaving bots in an AI Labyrinth.”
Cloudflare Docs. (2025). “Web Bot Auth Reference & Pay-Per-Crawl Implementation.”
GitHub (TecharoHQ). (2025). “Anubis: Weighs the soul of incoming HTTP requests to stop AI crawlers.”
Stytch Blog. (2025). “Browser fingerprinting: Implementing fraud detection.”
Fedora Community Blog. (2025). “Council Policy Proposal: Policy on AI-Assisted Contributions.”
Slashdot. (2025). “Open Source Devs Say AI Crawlers Dominate Traffic, Forcing Blocks On Entire Countries.”

</details>