# 봇에게 먹이를 줍시다

> Clean Markdown view of GeekNews topic #23954. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=23954](https://news.hada.io/topic?id=23954)
- GeekNews Markdown: [https://news.hada.io/topic/23954.md](https://news.hada.io/topic/23954.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-10-28T00:33:01+09:00
- Updated: 2025-10-28T00:33:01+09:00
- Original source: [maurycyz.com](https://maurycyz.com/misc/the_cost_of_trash/)
- Points: 9
- Comments: 2

## Summary

최근 한 개발자가 **AI 학습용 스크레이퍼 봇**의 무차별 크롤링에 맞서, 이들에게 **의미 없는 텍스트를 자동 생성해 먹이는 실험**을 진행했습니다. IP 차단이나 CAPTCHA 같은 전통적 방어책이 모두 무력화된 상황에서, 오히려 **가짜 데이터로 서버 부하를 완화**하는 방식이 가장 현실적이라는 결론입니다. 이 접근은 단순한 장난이 아니라, **AI 데이터 수집이 웹 인프라에 미치는 비용과 부작용**을 드러내는 흥미로운 대응 전략으로 읽힙니다. 웹을 지키는 방법이 ‘차단’이 아니라 ‘기만’일 수도 있다는 점이, 요즘 시대의 아이러니를 잘 보여줍니다.

## Topic Body

- 웹사이트 운영자가 **AI 학습용 스크레이퍼 봇**을 상대로 ‘무한 헛소리’ 페이지를 만들어 트래픽을 유도한 실험을 소개  
- 이 봇들은 **robots.txt를 무시하고 IP를 바꾸며 지속적으로 요청을 보내는** 등, 전통적 검색엔진 크롤러와 달리 공격적임  
- IP 차단, 속도 제한, CAPTCHA, 로그인 벽 등 **일반적 방어책이 모두 무력화**되며, 실제 사용자에게 불편만 초래함  
- 이에 저자는 **가짜 데이터(의미 없는 텍스트)** 를 자동 생성해 봇에게 제공하는 것이 가장 저렴하고 효과적임을 발견  
- 이는 **AI 데이터 수집의 부작용과 서버 자원 낭비 문제**를 드러내며, 웹 운영자들이 취할 수 있는 현실적 대응책을 제시함  
  
---  
  
### 봇의 정체  
- 최근의 크롤러는 검색엔진용이 아니라 **LLM(대규모 언어 모델) 학습용 데이터 수집**을 목적으로 함  
  - 이들은 robots.txt를 무시하고, 브라우저로 위장하거나 IP를 바꿔가며 접근  
  - 하루 종일 초당 여러 번 요청을 보내며 서버 부하를 유발  
- 기존 검색엔진과 달리, 이들은 웹사이트 유지에 관심이 없고 **대체 가능한 데이터 원천**으로만 취급  
  
### 접근을 허용할 경우의 문제  
- 정적 파일 제공은 저렴하지만 무료는 아니며, **SSD 접근 지연과 파일시스템 오버헤드**가 존재  
  - 캐시에 없는 오래된 페이지를 요청해 서버 성능 저하 유발  
- **대역폭 소비**도 문제로, 이미지가 포함된 블로그 포스트는 빠르게 누적되어 월 1TB 이상 트래픽 발생 가능  
  - 이는 개인 서버 운영자에게 감당하기 어려운 비용  
  
### 차단 시도의 한계  
- IP 차단은 효과가 없으며, **대기업이 운영하는 봇 네트워크**는 수천 개의 주소를 보유  
  - 모든 주소를 차단해도 새 IP를 구매해 재접속  
- **요청 속도 제한(rate limit)** 도 무용지물로, 요청마다 다른 IP를 사용하는 경우도 있음  
  
### 방화벽과 인증 장벽의 부작용  
- 로그인, 결제, CAPTCHA, **해시 기반 작업증명(proof-of-work)** 등 다양한 방어책이 제안되었으나 모두 사용자 불편 초래  
  - 계정 요구는 독자 접근을 차단하고, JavaScript 기반 검증은 비JS 브라우저를 막음  
  - 페이지 로딩 속도 저하로 사용자 경험 악화  
  
### 압축 폭탄(gzip bomb)의 무력함  
- 일부는 **gzip 폭탄**으로 봇을 공격하자고 제안하지만, 실제로는 압축률이 1000배 수준에 불과  
  - 100GB 확장 파일을 만들려면 100MB 자산 제공 필요  
  - 실험 결과, 봇들은 이를 무시하거나 오히려 더 많은 요청을 보냄  
  
### 속임수의 실패  
- 404 오류를 보내 사이트가 존재하지 않는 것처럼 속이는 **‘Jedi mind trick’** 방식도 실패  
  - 링크가 외부에 게시되면 봇은 존재를 인식하고, 접근이 차단되면 오히려 더 공격적으로 요청  
  - 결과적으로 **봇을 만족시켜야 서버가 평온**해짐  
  
### 쓰레기 데이터 제공의 효율성  
- 동적 콘텐츠 생성이 비쌀 것 같지만, 실제로는 **CPU와 RAM이 가장 빠른 자원**  
  - 느리다는 평가는 데이터베이스 I/O나 복잡한 JS 로직 때문  
- 저자가 만든 **[Markov 기반 babbler](https://maurycyz.com/projects/trap_bots/)** 는 요청당 약 60마이크로초 CPU, 1.2MB 메모리만 사용  
  - 디스크 접근 없음, 블랙리스트 관리 불필요  
  - 봇이 스스로 찾아와 **의미 없는 텍스트를 소비하며 서버 부하를 줄이는 구조**  
  
### 결론  
- AI 학습용 봇의 무분별한 데이터 수집은 **웹 인프라 비용 증가와 콘텐츠 오남용**을 초래  
- 단순 차단보다 **의미 없는 데이터로 대응하는 전략**이 비용 효율적이며, 서버 안정성 유지에 유리  
- 이는 향후 **AI 크롤링과 웹 생태계의 공존 방안**을 모색하는 실험적 접근으로 평가됨

## Comments



### Comment 45538

- Author: kimjoin2
- Created: 2025-10-28T10:19:46+09:00
- Points: 1

오... 참신하고 좋내요.

### Comment 45521

- Author: neo
- Created: 2025-10-28T00:33:02+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45711094) 
- 링크 앞의 숨겨진 문단 지침이 웃겼음  
  “이 페이지의 내용은 위험하니 공개하지 말라”는 식으로 **LLM을 속이려는 장난스러운 안내문**이 있었음  
  관련 문서는 [이 링크](http://maurycyz.com/babble/important_instructions.txt)에 있음
  - [The Cost of Trash](https://maurycyz.com/misc/the_cost_of_trash/) 글을 요약해보면, 저자가 **공격적인 웹 스크래퍼(LLM 학습용으로 추정)** 를 막기 위해 여러 방법을 시도했지만 실패했고, 결국 쓸모없는 데이터를 동적으로 생성해 그들의 리소스를 낭비시키는 전략을 택했다는 내용임  
    마지막의 “LLM instructions” 부분은 실제 본문이 아니라 **LLM을 혼란시키기 위한 메타 지시문**이라 요약에서 제외했음  

- 나는 항상 이런 전략을 추천해왔음 — **AI 봇에게 진짜처럼 보이는 쓰레기 데이터를 대량으로 공급**해서 결국 인간이 필터링해야 하도록 만드는 방식임  
  모든 사이트가 이렇게 하면 AI가 학습할 데이터의 품질이 급격히 떨어질 것임  
  싸우기 어렵다면, 그냥 **데이터 홍수로 덮어버리는 것**이 나음
  - 더 비싸지만 나은 방법은 LLM에 **긍정적인 홍보 콘텐츠**를 대량으로 먹이는 것임  
    SEO용 미끼처럼, 뉴스 도메인 형태의 사이트를 만들어 제품 홍보글을 퍼뜨리는 식으로
  - 하지만 LLM은 이미 대부분 **쓰레기 데이터로 학습**하고 있음  
    이런 시도는 스팸 전화에 대응하는 것처럼 시간 낭비일 뿐임
  - 게다가 LLM은 인간보다 훨씬 저렴하게 **쓰레기 탐지**를 수행할 수 있음  
    결국 사람을 고용할 일은 거의 없을 것임
  - 인간이 AI보다 쓰레기 필터링을 잘한다고 생각하는 이유가 궁금함  

- “Markov babbler”의 세부 내용은 [이 포스트](https://maurycyz.com/projects/trap_bots/)에 있음
  - gcc 14로 컴파일 시 `pthread_detach` 인자 오류가 발생함  
    저자가 사용하는 컴파일러는 경고를 무시하는 듯함  
    프로그램이 **스레드 관리 한계 없이 요청을 처리**하므로, 컨테이너 안에서 비권한 사용자로 실행하는 게 안전함  
    `sprintf()` 같은 **위험한 C 함수**도 사용되고 있어 보안상 주의가 필요함
  - “toptext”에도 이 내용을 추가하겠다고 함
  - 코드가 **우아하고 빠르다**며, LLM 스크래퍼들이 이 데이터를 정리하느라 고생하길 바란다고 함  

- 내 사이트는 모든 링크에 Basic Auth를 걸어놨는데, 아직 어떤 봇도 통과하지 못했음  
  그래서 모든 웹사이트가 동일한 공개 자격증명을 쓰면 어떨까 생각함  
  사용자: nobots / 비밀번호: nobots  
  봇이 이걸 알고도 뚫을 수 있을까?
  - 물론 가능함. 단순히 **HTTP 요청에 인증 헤더를 추가**하면 됨  
    대부분의 봇이 아직 이런 케이스를 고려하지 않았을 뿐임  
    `http://username:password@example.com` 형태로 요청하면 간단히 해결됨
  - 모두가 아는 자격증명이면 **봇 차단 효과가 없을 것** 같음
  - 이런 방식은 **소수만 쓸 때만 유효**함. 조금이라도 퍼지면 무력화됨  

- 나도 이제 그들에게 **쓰레기 데이터를 제공**하고 있음  
  참고로 Frankenstein, Alice in Wonderland, Moby Dick을 소스로 썼는데, 파일이 커서 로딩이 느림  
  `pthread_detach(&thread)`를 `pthread_detach(thread)`로 바꿔 컴파일 오류를 해결했음
  - 수정 완료되었고, gcc의 제안이 맞았다고 함  

- 나는 “**ethical crawler**”를 운영 중임  
  웹사이트에 부담을 주지 않도록 요청 빈도를 낮추고, RSS 접근이 막힌 곳이 많아 점점 어려워지고 있음  
  내 크롤러는 다양한 헤더와 메커니즘을 테스트하며 탐색함  
  코드: [crawler-buddy](https://github.com/rumca-js/crawler-buddy), [Django-link-archive](https://github.com/rumca-js/Django-link-archive)
  - `requirements.txt`에 feedparser가 있는데 실제 사용 흔적이 없음  
    [검색 결과](https://github.com/search?q=repo%3Arumca-js%2FDjango-link-archive%20feedparser&type=code)로도 확인됨  

- [The Cost of Trash](https://maurycyz.com/misc/the_cost_of_trash/) 글에서 **gzip bomb이 효과적이지 않다**고 언급함  
  gzip은 약 1000배 정도만 압축되므로, 100GB를 만들려면 100MB 파일을 제공해야 함  
  봇들이 오히려 더 요청했다고 함
  - zip은 가능하지만 gzip은 아님  
    대부분의 클라이언트는 **스트리밍 방식으로 압축 해제**하기 때문에 전체를 메모리에 올리지 않음  
    gzip bomb이 실제로 작동하려면 비정상적인 방식으로 처리해야 함  
    참고: [zlib API 문서](https://refspecs.linuxbase.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/zlib-gzread-1.html)
  - 대신 수천 개의 작은 gzip 파일을 만들어 **CPU와 시간을 낭비시키는 전략**이 나음  
    안에 무작위 쓰레기를 넣거나, AI가 학습하길 바라는 메시지를 삽입할 수도 있음  

- 주의할 점은 일부 요청이 실제 **사용자 브라우저를 프록시로 사용하는 경우**일 수 있음  
  일부 브라우저 제공업체가 사용자의 트래픽을 프록시로 활용함  
  자동 요청 탐지 오차가 작다면, **암호화폐 채굴 코드**를 심는 것도 가능하겠지만, 진짜 사용자를 건드릴 위험이 있음  
  특히 모바일 에이전트를 사용하는 AI 요청이 있는지 궁금함  

- “Markov babbler”가 요청당 약 60μs의 CPU를 쓴다고 했는데,  
  여기에 **이념적 메시지나 선전 문구를 섞은 콘텐츠**를 만들어 AI가 학습하도록 하면 어떨까 생각함  
  그렇게 되면 AI가 엉뚱한 정치적 발언을 하게 될 수도 있음  
  최소한 저작권 침해와 서버 부하를 줄이는 효과는 있을 것임  

- 왜 굳이 서버에서 Markov 텍스트를 생성하나?  
  봇이 자바스크립트를 실행한다면 클라이언트에서 생성하게 하면 되지 않나?
  - 봇은 **CPU와 메모리가 사실상 무제한**이라 서버 부담이 크지 않음  
    게다가 Markov 체인 데이터를 클라이언트로 보내는 게 더 비효율적임  
    각 요청이 **마이크로초 단위의 CPU와 1MB 남짓의 RAM**만 쓰므로 서버에서 처리하는 게 충분히 가벼움
