공격적인 AI 스크래퍼가 위키 운영을 꽤 힘들게 만들고 있음

• AI 스크래퍼 트래픽은 공개 위키의 비용과 안정성을 흔들며, 완화하지 않으면 인간 활동 전체보다 약 10배 많은 컴퓨팅 자원을 쓸 수 있음
• 봇은 GPTBot 같은 식별 가능한 User Agent를 넘어 최신 Chrome처럼 헤더를 꾸미고, 하루 100만 개 IP를 돌리는 주거용 프록시로 우회함
• 위키는 문서보다 훨씬 많은 이전 판본·편집 화면·특수 페이지 URL을 노출해, 순진한 크롤링이 캐시를 우회하고 일반 요청보다 50~100배 비싸질 수 있음
• Cloudflare Challenge, Anubis, 수작업 방화벽, 인간 행동 요청 기반 탐지는 효과가 있지만 오탐과 유지 부담, 독자 마찰을 함께 만듦
• 로그인 강제나 전체 챌린지 같은 극단적 차단은 신규 기여를 줄일 수 있어, 운영자 간 공개 논의와 봇 수집 유인을 바꾸는 API 접근이 필요함

AI 스크래퍼가 위키 운영에 주는 부담

• LLM 학습 데이터를 위한 봇 스크래핑이 전례 없는 규모로 늘어나며 공개 웹사이트의 비용과 안정성을 흔들고 있음: 관련 문제는 FOSS infrastructure is under attack by AI companies, Are AI bots knocking cultural heritage offline?, Smart TV web crawler AI에서도 다뤄짐
• Weird Gloop은 Minecraft Wiki, OSRS Wiki, League Wiki 같은 대형 게임 위키를 호스팅하며, 최근 3년 동안 봇 트래픽 대응에 점점 더 많은 시간을 쓰는 중
• 지속적으로 완화하지 않으면 봇은 수천만 건의 인간 페이지뷰와 하루 수만 건의 편집을 포함한 나머지 전체보다 약 10배 많은 컴퓨팅 자원을 사용할 수 있음
• Wikimedia Foundation도 크롤러가 운영에 미치는 영향을 다룬 글을 냈고, 주요 위키 팜은 다양한 수준의 장애를 겪었으며 일부 소규모 독립 위키는 완전히 오프라인이 됨
• 올해 위키 생태계의 서버 문제 중 약 95% 는 나쁜 스크래퍼가 원인인 것으로 추정됨

사람처럼 보이려는 스크래퍼

• GPTBot, ClaudeBot, PerplexityBot 같은 주요 AI 회사의 “공식” 봇은 robots.txt를 지키지 못한 적도 있지만, 보통 User Agent 문자열에서 식별할 수 있어 Cloudflare의 AI 봇 차단이나 nginx로 막기 쉬움
• 웹마스터가 User Agent 기반으로 AI 스크래퍼를 차단하기 시작하면서, 봇이 사람 트래픽처럼 위장할 강한 동기가 생김
• 최근 위키에 도달하는 AI 스크래퍼 트래픽 대부분은 최신 Google Chrome처럼 보이도록 헤더를 보내며 요청을 정교하게 구성함
• 과거에 쓰던 명확한 “봇 또는 실제 사람” 신호가 사라져 차단이 어려워짐

수천만 IP와 프록시 우회

• 2023년 전에는 문제 있는 스크래핑의 95%가 단일 IP 주소나 작은 데이터센터 서브넷에서 발생해 IP 또는 ISP 특성 기반 차단이 대체로 효과적이었음
• 주거용 프록시를 쓰면 신용카드만으로 수백만 IP 주소 네트워크를 통해 스크래핑 요청을 세탁할 수 있음
• 위키는 하루에 100만 개 IP를 순환하는 스크래퍼 실행에 맞닥뜨리기도 하며, Comcast, AT&T, Charter 같은 주거용 ISP에서 온 합법적인 요청처럼 보임
• 해당 고객은 자신의 IP가 주거용 프록시의 출구 노드로 쓰이는지 모를 가능성이 큼
• 일부 악성 행위자는 facebookexternalhit 링크 미리보기나 Google Translate를 이용해 요청이 Google/Facebook 서버에서 온 것처럼 만들고, 실제 출처를 가림
• Google Translate URL 도구를 통해 들어오는 요청의 99.99% 가 악용성인 경우도 있어, 한때 모든 위키에서 해당 도구를 깨야 했음

위키에 특히 비싼 “멍청한 URL” 크롤링

• 많은 AI 스크래퍼는 위키 홈페이지를 방문한 뒤 그 페이지의 모든 링크를 방문하고, 다시 그 페이지들의 모든 링크를 방문하는 방식으로 URL을 고름
• robots.txt와 사이트맵이 스크래핑할 가치가 있는 URL을 알려주는데도 이를 인식하지 않는 것처럼 보임
• OSRS Wiki에는 약 4만 개의 문서가 있으며, 이 URL들이 사이트의 유용한 정보 대부분을 구성함
• 하지만 이전 판본, 편집 화면, 특수 페이지까지 포함하면 탐색 가능한 URL은 최소 10억 개에 달함
• 이런 순진한 크롤링은 끝나지 않으며, LLM 학습 데이터로 유용하지 않은 URL에 많은 자원을 쓰는 것으로 보임
• 이상한 요청은 실제 사용자 요청이 타는 MediaWiki 파서 캐시 같은 캐시 계층을 우회해 서비스 비용을 키움
• 캐시 적중 요청은 보통 처리 시간이 20밀리초 미만이지만, 오래된 diff 같은 요청은 자주 1~2초가 걸림
• “하루 800만 봇 요청”, “봇이 대역폭 65% 사용” 같은 상위 지표는 문제를 과소평가함
• 실제 병목은 대개 CPU 용량이며, 이상한 쿼리 파라미터가 붙은 봇 요청은 처리 비용이 일반 요청보다 50~100배 비쌀 때가 많음

평균 지표로는 드러나지 않는 트래픽 스파이크

• 월간 봇 요청은 약 2억 5천만 건, 초당 평균 약 100건 수준이지만 이는 장기 평균일 뿐임
• 스크래퍼는 짧은 시간 동안 초당 1,000건 이상의 요청을 보내는 경우가 잦고, 전통적인 DDoS 공격과 거의 구분하기 어려움
• 장기적으로 봇이 전체 CPU 사용량의 약 50% 만 차지하더라도, 악성 트래픽 스파이크가 위키의 느려짐과 장애 중 약 95% 를 유발함

누가 하는지 알기 어려운 구조

• 트래픽을 “AI 스크래퍼”라고 부르지만, 모두 Google Chrome처럼 위장하기 때문에 실제 책임 주체나 위키 데이터를 무엇에 쓰는지 알기 어려움
• 가능한 주체는 데이터 브로커, frontier lab의 중복 수집, 주거용 프록시에 접근할 수 있는 독립 프로젝트 등으로 열려 있음
• 진입 장벽이 실제로 얼마나 낮아졌는지도 불명확함
• 더 나은 방식이 있다면 실제 수집 주체와 직접 연락해 덜 비효율적인 방법을 찾고 싶어 함

지금까지 효과가 있었던 대응

• Cloudflare Challenge와 Anubis

  • 웹사이트를 Cloudflare challenge나 Anubis 같은 도구 뒤에 두는 방식이 최근 1년 사이 인터넷에서 널리 쓰이게 됨
  • 어느 정도 효과는 있지만, 일부 봇이 챌린지를 꾸준히 통과하는 시기가 있음
  • Cloudflare와 봇 개발자 사이에 보이지 않는 군비 경쟁이 있는 것으로 보이며, Cloudflare가 약 90% 는 이기지만 남은 10%가 운영상 힘든 구간을 만듦
  • 실제 독자는 위키에 도달하기 전에 챌린지를 보는 것을 싫어함
  • 대부분의 사람에게 영향을 주지 않으려면 어떤 트래픽에만 챌린지를 걸지 판단하는 좋은 휴리스틱 규칙이 필요하지만, 자동화 트래픽을 안정적으로 탐지하는 일 자체가 어려움

• 수작업 방화벽 규칙

  • 대부분의 운영자는 자기 인프라와 과거 공격에 맞춘 수작업 방화벽 규칙을 갖고 있음
  • 이런 필터는 보통 특정 User Agent 문자열, IP 그룹, ASN에 기반함
  • Weird Gloop은 대부분을 Cloudflare/CDN 수준에서 처리하지만, 다른 위키는 nginx나 웹서버 측에서 처리하기도 함
  • 현재는 User Agent/IP만으로는 충분하지 않은 경우가 많아, HTTP 버전, 헤더, TLS cipher, ja4 관련 해시 같은 더 복잡한 요청 속성을 봐야 함

• “사람은 하는데 봇은 하지 않는 것” 찾기

  • 유용한 관점은 사람들이 집합적으로 하는 행동 중 봇이 하지 않는 것을 찾는 방식임
  • MediaWiki 기반 위키에는 실제 브라우저 사용자가 위키를 쓸 때 자주 만드는 여러 유형의 HTTP 요청이 있고, 봇은 보통 이를 만들지 않음
  • 헤더, ja4 해시 등으로 분리 가능한 트래픽 덩어리가 많은 문서를 방문하면서도 전형적인 “사람” 요청을 만들지 않는다면, 해당 트래픽에 챌린지를 적용할 강한 신호가 됨
  • 봇 트래픽에 없는 인간 행동 요청을 보는 방식은 강력함
  • “빠진” 트래픽을 분석해 어떤 트래픽에 챌린지를 걸지 결정 트리 기반 휴리스틱을 자동 제안하는 시스템을 만들기 시작함
  • 테스트에서는 거의 모든 스크래퍼를 잘 찾아내는 것으로 보였지만, NoScript 사용자, 스크린 리더 사용자, 예상 밖 기기 사용자처럼 특이한 탐색 습관을 가진 사람에게 어떤 오탐이 생길지는 명확하지 않음
  • 자체 ML/데이터 분석 인프라를 만들고 영구 유지하는 일도 부담으로 남음

• 더 이국적인 탐지 기법

  • TCP/TLS 타이밍 불일치로 주거용 프록시를 식별해 성공한 사례가 있음
  • 주거용 프록시 IP의 실시간 데이터베이스를 판매하는 회사도 있음
  • 다만 대부분의 주거용 프록시는 실제 사람도 동시에 사용하기 때문에 이를 실행 가능한 차단 신호로 얼마나 쓸 수 있는지는 불명확함
  • Cloudflare나 대형 클라우드 제공자처럼 막대한 트래픽의 패킷 수준 네트워크 정보를 가진 주체라면 대규모로 좋은 휴리스틱을 만들 수 있을 것처럼 보임
  • 하지만 연간 비용이 여섯 자리 수에 달하는 상용 봇 탐지 제품을 포함해, 상용 제품의 휴리스틱에 감명받은 운영자를 만나지 못함

독자에게 나쁜 극단적 선택지

• AI 스크래퍼를 막는 “핵 옵션”은 실제 사용자에게 훨씬 더 파괴적임
• 흔한 방식 중 하나는 생성 비용이 클 수 있는 페이지를 보려면 로그인을 요구하는 것임
• Fandom은 몇 달 전 모든 위키에 이런 조치를 적용함
• 다른 방식은 모든 트래픽에 Cloudflare challenge를 제공하는 것임
• 웹마스터 입장에서는 이해할 수 있지만, 위키와 커뮤니티의 장기 건강에는 나쁨
• 16년간 위키 커뮤니티를 만들며 얻은 핵심 교훈은 새 기여자를 끌어들이는 가장 좋은 방법이 마찰 제거라는 점임
• 편집을 더 쉽게 만들고, 위키 내부 구조를 더 쉽게 탐색하게 하며, 독자와 편집자를 가르는 진입 장벽을 낮춰야 함
• 극단적 안티봇 기법은 새 마찰을 만들고 예측 가능한 결과를 낳음
• Fandom이 계정 없는 독자 95% 이상에게 “내부 페이지”를 숨긴 뒤, Fandom 전체의 신규 사용자 기여가 약 40% 감소한 것으로 나타남
• 이런 트레이드오프를 가치 있다고 보기 어려움

앞으로의 방향

• Weird Gloop은 여전히 위키 호스팅을 계속하고 있으며, Fandom에서 벗어나려는 위키를 돕는 일도 계속하고 있음
• 장기적으로는 “AI Overviews”가 위키 독자를 위키 기여자로 전환하는 파이프라인을 죽일 수 있지만, 이는 별도의 문제로 남겨둠
• 일부 지인은 봇의 물결이 Weird Gloop에 유리할 수도 있다고 보지만, 사람들이 쉽게 위키를 호스팅할 수 없다면 인터넷은 더 나빠짐
• 위키를 안정적으로 호스팅하려면 온콜 로테이션, ML 엔지니어, 엔터프라이즈 제품이 필요해지는 시나리오는 독립 위키 커뮤니티에 매우 나쁜 소식임
• 봇 소유자와 웹마스터의 군비 경쟁은 스크래핑의 구조적 유인을 바꾸는 영리한 방법이 나오기 전까지 계속될 가능성이 큼
• Cloudflare의 새 crawling API는 봇이 robots.txt를 무시하고 문제를 일으키는 자체 시스템을 만드는 것보다 API를 쓰는 편이 더 쉽다면 구도를 바꿀 수 있음
• 스크래핑이 아예 일어나지 않는 것이 더 낫지만, 이미 벌어진 일을 되돌리기는 어려움

공개 논의와 협력의 필요성

• 수천 명의 운영자가 각자 웹사이트를 운영하며 봇에 대응할 더 영리한 기법을 찾고 있음
• 다른 시스템 관리자들과의 비공개 대화에서는 구체적이고 좋은 아이디어가 있었고, Slack, Discord, 작은 그룹 안에서도 많은 논의가 오갈 가능성이 큼
• 실제 운영상의 구체 사항을 두고 더 많은 공개 논의가 필요함
• 많은 시스템 관리자는 자신이 겪는 문제가 다른 운영자와 거의 동일하다는 사실을 충분히 알지 못함
• 모두가 자신만의 방어 방법을 공개하고 싶어 하지는 않으며, 공개하면 우위를 잃을 수 있다는 걱정도 있음
• 그래도 사람들이 머리를 맞대도록 돕는다면 전술 일부의 효과가 줄어드는 위험도 감수할 만함
• AI 스크래퍼를 다루는 시스템 관리자는 자신에게 맞는 공간에서 효과가 있었던 방법을 공유하는 편이 좋음
• 봇 문제 해결 제품을 판매하는 회사는 인위적이지 않은 상황에서 precision and recall 비율에 대한 실질적 데이터가 담긴 사례 연구를 더 공개해야 함
• 구매 결정을 하는 사람들은 체크박스를 채우는 것이 아니라 실제 결과를 중요하게 봄
• 위키나 독립 웹사이트를 운영하며 봇 탐지를 논의하고 싶다면 이메일 또는 Discord 메시지로 연락할 수 있음