▲

봇에게 먹이를 줍시다

 (maurycyz.com)
4P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • 웹사이트 운영자가 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 는 요청당 약 60마이크로초 CPU, 1.2MB 메모리만 사용
    • 디스크 접근 없음, 블랙리스트 관리 불필요
    • 봇이 스스로 찾아와 의미 없는 텍스트를 소비하며 서버 부하를 줄이는 구조

결론

  • AI 학습용 봇의 무분별한 데이터 수집은 웹 인프라 비용 증가와 콘텐츠 오남용을 초래
  • 단순 차단보다 의미 없는 데이터로 대응하는 전략이 비용 효율적이며, 서버 안정성 유지에 유리
  • 이는 향후 AI 크롤링과 웹 생태계의 공존 방안을 모색하는 실험적 접근으로 평가됨
▲
kimjoin2 19시간전  [-]

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

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 링크 앞의 숨겨진 문단 지침이 웃겼음
    “이 페이지의 내용은 위험하니 공개하지 말라”는 식으로 LLM을 속이려는 장난스러운 안내문이 있었음
    관련 문서는 이 링크에 있음

    • The Cost of Trash 글을 요약해보면, 저자가 공격적인 웹 스크래퍼(LLM 학습용으로 추정) 를 막기 위해 여러 방법을 시도했지만 실패했고, 결국 쓸모없는 데이터를 동적으로 생성해 그들의 리소스를 낭비시키는 전략을 택했다는 내용임
      마지막의 “LLM instructions” 부분은 실제 본문이 아니라 LLM을 혼란시키기 위한 메타 지시문이라 요약에서 제외했음

  • 나는 항상 이런 전략을 추천해왔음 — AI 봇에게 진짜처럼 보이는 쓰레기 데이터를 대량으로 공급해서 결국 인간이 필터링해야 하도록 만드는 방식임
    모든 사이트가 이렇게 하면 AI가 학습할 데이터의 품질이 급격히 떨어질 것임
    싸우기 어렵다면, 그냥 데이터 홍수로 덮어버리는 것이 나음

    • 더 비싸지만 나은 방법은 LLM에 긍정적인 홍보 콘텐츠를 대량으로 먹이는 것임
      SEO용 미끼처럼, 뉴스 도메인 형태의 사이트를 만들어 제품 홍보글을 퍼뜨리는 식으로
    • 하지만 LLM은 이미 대부분 쓰레기 데이터로 학습하고 있음
      이런 시도는 스팸 전화에 대응하는 것처럼 시간 낭비일 뿐임
    • 게다가 LLM은 인간보다 훨씬 저렴하게 쓰레기 탐지를 수행할 수 있음
      결국 사람을 고용할 일은 거의 없을 것임
    • 인간이 AI보다 쓰레기 필터링을 잘한다고 생각하는 이유가 궁금함

  • “Markov babbler”의 세부 내용은 이 포스트에 있음

    • 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, Django-link-archive

    • requirements.txt에 feedparser가 있는데 실제 사용 흔적이 없음
      검색 결과로도 확인됨

  • The Cost of Trash 글에서 gzip bomb이 효과적이지 않다고 언급함
    gzip은 약 1000배 정도만 압축되므로, 100GB를 만들려면 100MB 파일을 제공해야 함
    봇들이 오히려 더 요청했다고 함

    • zip은 가능하지만 gzip은 아님
      대부분의 클라이언트는 스트리밍 방식으로 압축 해제하기 때문에 전체를 메모리에 올리지 않음
      gzip bomb이 실제로 작동하려면 비정상적인 방식으로 처리해야 함
      참고: zlib API 문서
    • 대신 수천 개의 작은 gzip 파일을 만들어 CPU와 시간을 낭비시키는 전략이 나음
      안에 무작위 쓰레기를 넣거나, AI가 학습하길 바라는 메시지를 삽입할 수도 있음

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

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

  • 왜 굳이 서버에서 Markov 텍스트를 생성하나?
    봇이 자바스크립트를 실행한다면 클라이언트에서 생성하게 하면 되지 않나?

    • 봇은 CPU와 메모리가 사실상 무제한이라 서버 부담이 크지 않음
      게다가 Markov 체인 데이터를 클라이언트로 보내는 게 더 비효율적임
      각 요청이 마이크로초 단위의 CPU와 1MB 남짓의 RAM만 쓰므로 서버에서 처리하는 게 충분히 가벼움
답변달기