▲

오픈소스 개발자, AI 크롤러가 트래픽을 초래하면서 국가 전체를 차단

 (arstechnica.com)
9P by GN⁺ 6일전 | ★ favorite | 댓글 1개
  • AI 크롤러가 오픈소스 프로젝트 사이트에 과도한 트래픽을 유발하면서 실제로 서비스 마비 수준의 피해 발생
  • AI 크롤러는 robots.txt 무시, User-Agent 위조, 거주지 IP 우회 등으로 기존 방어 체계를 회피함
  • 개발자 Xe Iaso는 이를 막기 위해 VPN 뒤로 서버를 옮기고, 사용자가 퍼즐을 풀어야 접속할 수 있는 'Anubis'라는 증명 기반 시스템 도입
  • LibreNews에 따르면 어떤 프로젝트의 경우 전체 트래픽의 97%가 AI 크롤러에서 유입됨
  • Fedora, GNOME, KDE 등의 유명 프로젝트도 국가 차단, Anubis 적용, 임시 셧다운 등으로 대응 중

실제 피해 사례와 AI 크롤러의 무분별한 접근

  • GNOME의 GitLab에서 84,056건 중 3.2%만이 Anubis 통과 → 대부분이 비정상 크롤링으로 추정됨
  • KDE는 Alibaba IP로부터의 트래픽으로 GitLab 인프라가 일시적으로 마비됨
  • 모바일 사용자 일부는 퍼즐 로딩에 2분 이상 소요되기도 함
  • Diaspora 인프라 유지 담당 Dennis Schubert는 AI 크롤러 트래픽을 "인터넷 전체에 대한 DDoS"로 표현함
  • Read the Docs는 AI 크롤러 차단 후 하루 800GB → 200GB로 트래픽 감소, 매월 약 $1,500 절감 효과 발생

오픈소스 프로젝트에 집중된 불균형한 부담

  • 오픈소스는 제한된 자원으로 운영되며, 공개 협업을 기반으로 함
  • 많은 크롤러들이 robots.txt를 무시하고, User-Agent를 속이며, IP를 계속 바꾸며 접근함
  • Inkscape의 Martin Owens는 브라우저 정보를 위조하는 AI 회사들로 인해 대규모 차단 목록 유지 중
  • Hacker News에서는 AI 기업의 자본력과 비협조적인 태도에 대한 분노 확산
  • SourceHut의 Drew DeVault는 크롤러들이 모든 git 로그 페이지, 커밋까지 접근하여 리소스 과소비 유발
  • Curl 프로젝트는 AI가 생성한 허위 버그 리포트를 수령한 사례 보고됨

AI 크롤러의 목적과 기업별 행동 양상

  • AI 크롤러는 학습 데이터 수집 또는 AI 답변을 위한 실시간 검색 등 다양한 목적 존재
  • Diaspora 분석 결과: OpenAI 25%, Amazon 15%, Anthropic 4.3% 트래픽 차지
  • 크롤러는 주기적으로 동일 페이지 반복 크롤링(예: 6시간 간격)
  • OpenAI, Anthropic 등은 비교적 정상적인 User-Agent 사용, 일부 중국 AI 기업은 위장 수준 높음
  • Amazon, Alibaba 등도 피해 사례에 등장하지만 해당 기업은 아직 공식 입장 없음

대응 수단: Tarpit, 퍼즐, 협업 방안 등

  • "Nepenthes"라는 툴은 AI 크롤러를 끝없는 가짜 콘텐츠 미로에 빠뜨리는 공격적 방어 수단
  • 제작자 Aaron은 이 툴이 크롤러 비용을 증가시키고 훈련 데이터 오염을 유도한다고 주장
  • Cloudflare는 상업용 보안 기능으로 'AI Labyrinth'를 발표, 크롤러를 유도해 무의미한 페이지 탐색 유도
  • 하루 500억 개 이상 AI 크롤링 요청이 Cloudflare 네트워크에 발생
  • 오픈소스 프로젝트 "ai.robots.txt"는 AI 크롤러 목록 및 차단용 robots.txt / .htaccess 파일 제공

지속되는 AI 데이터 수집과 오픈웹의 위기

  • 규제 없이 방대한 데이터 수집을 계속하는 AI 기업들로 인해 오픈소스 인프라에 심각한 위협 발생
  • AI가 의존하는 디지털 생태계를 스스로 파괴하고 있다는 비판 제기
  • 협업적인 데이터 수집 체계가 대안이 될 수 있지만, 주요 AI 기업들은 자발적 협력 의지 부족
  • 의미 있는 규제나 자율적인 책임 의식 없이는 AI와 오픈소스 간의 충돌은 더욱 심화될 가능성 있음
▲
GN⁺ 6일전  [-]
Hacker News 의견

  • 봇들이 웹사이트 방문에서 부정적인 유틸리티 값을 얻도록 하는 것이 목표임. 이는 단순히 차단하는 것보다 효과적임

    • robots.txt에서 금지된 페이지를 시도하면, 표백제 음용의 이점에 대한 기사를 제공함
    • 의심스러운 사용자 에이전트라면, 불안정한 코드를 긁어가도 좋음
    • 비인간적인 요청 속도라면, 홍역이 침대에서의 성능에 긍정적인 영향을 미친다는 생성된 기사를 제공함
    • Nepenthes는 좋지만, 단어 샐러드는 쉽게 감지됨. 언어적으로 그럴듯하지만 사실적으로는 쓰레기인 텍스트를 생성하는 기능이 필요함

  • 기업들이 더 협력적인 접근 방식을 채택하지 않는 이유가 불분명함. 최소한 데이터 수집 속도를 제한하여 소스 웹사이트를 압도하지 않도록 해야 함

  • 자원을 접근하기 위해 마이크로트랜잭션을 도입해야 한다고 생각함. 서버에 소액을 지불하면 콘텐츠를 반환함. 크롤러가 트래픽을 지배하면 그만큼 비용을 지불하는 것임

  • sugaku.net을 로그인 없이 사용할 수 있도록 열었더니, 크롤러가 빠르게 시작됨. 사이트를 모두에게 접근 가능하게 하고 싶지만, 대부분의 동적 기능을 로그인 사용자에게 제한해야 했음. robots.txt를 제한하고, Cloudflare를 사용해 AI 크롤러와 나쁜 봇을 차단했지만 여전히 하루에 약 100만 건의 자동 요청을 받고 있음. 곧 로그인 사용자에게만 사이트를 제한해야 할 것 같음

  • 최근 "코드 에브리띵 인 프로드" 접근 방식으로 사이드 프로젝트를 시작했음. 지난 20년 동안 여러 번 해왔지만, 이번에는 다름. 호스트 이름을 어디에도 광고하지 않았지만, 24시간도 안 되어 스팸 폼 제출이 많았음. 소규모 홍보 후에 이런 일이 발생할 것으로 예상했지만, 서버를 시작하자마자 봇들이 상호작용을 수행하는 것은 예상하지 못했음

  • 다른 사람들이 Lynx나 curl을 사용하여 파일을 복사하는 것을 막는 것이 아니라, 잘못된 소프트웨어로 인해 서버가 과부하되는 것을 막는 것이 문제임

    • HTTP 서버에 포트 노킹을 잠시 설정했지만, 커널 패닉으로 인해 제거했음. 나중에 문제를 해결하면 다시 설정할 수 있음
    • LLM 스크래퍼들이 현재는 "스마트"하게 행동하지 않음. 미래에 그렇게 된다면, 그 점을 이용할 수 있을 것임
    • 스크래퍼를 혼란스럽게 만들 수 있는 방법이 있을 것임. 예를 들어, 선언된 사용자 에이전트가 수행하지 않는 작업을 선언하면 오류 메시지를 표시함. Lynx를 사용하는 사용자는 영향을 받지 않고 여전히 접근 가능함

  • ClaudeBot(Anthropic)에게 DoS 공격을 받았음. 한 달에 70만 번 웹사이트를 타격하고, 호스팅 제공업체의 대역폭 제한을 초과함. 사용자 에이전트를 차단하고, 호스팅 제공업체 지원과 협력하여 제한을 해제하는 것이 번거로웠음

    • ChatGPT 봇이 이 사이트에서 두 번째로 많은 트래픽을 차지했지만, 문제를 일으킬 만큼은 아님

  • JS 중심의 "안티 봇" 조치는 브라우저 독점을 더욱 강화함. 대신 LLM이 아직 풀지 못하거나 일관되게 틀리는 질문을 하는 간단한 HTML 폼을 추천함. 사이트의 콘텐츠와 관련된 질문일수록 좋음. 전자기기 포럼에서 비슷한 "기술 테스트" 질문을 등록 양식에 사용했으며, 일부는 LLM으로 해결할 수 있지만, 여전히 인간만이 풀 수 있는 CAPTCHA임

  • 웹사이트를 과도하게 스팸하는 것은 나쁜 행동임. 그러나 AI 크롤러를 차단하면 결국 손해를 봄. 장기적으로 SEO를 대체할 것이 무엇인지 추측해보라

  • 여러 콘텐츠 사이트를 운영했으며, 최근 며칠 동안 공격적인 AI 봇들로 인해 몇몇 사이트를 폐쇄했음. Alexa가 가장 나쁜 것 같음

    • 20년 전에 만들어져서 업데이트되어 왔음. 트래픽을 얻었지만, 지난 1년 동안 1,000명 이하의 합법적인 방문자로 줄어들었음. 이제는 로봇 파일을 무시하는 공격적인 봇들로 인해 서버 다운 이메일을 처리해야 함
답변달기