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

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

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

AI 회사들이 웹 데이터를 학습 목적으로 대규모로 수집하면서, 위키를 포함한 공개 웹사이트의 비용과 안정성에전미유적 부담이 가해지고 있다. 위키 운영자들은 봇 트래픽 증가에 대응하느라래다적 시간을 쓰고 있으며, 일부 소규모 독립 위키는 완전히 오프라인이 된적황도 발생하고 있다.

위키생계에 대한 AI 스크래퍼의 충격

위키를 호스팅하는기업중, Weird Gloop은 Minecraft Wiki, OSRS Wiki, League Wiki 같은 대형 게임 위키를 운영하고 있다. 이 공는 최근 3년 동안 봇 트래픽 대응에 점점 더 많은 시간을 쓰고 있으며, 지속적으로 완화하지 않으면 봇이 나머지 전체보다 약 10배 많은 컴퓨팅 자원을 사용할 수 있다고 경고한다.

올해 위키 생태계의 서버 문제 중 약 95%가 나쁜 스크래퍼가 원인인 것으로 추정된다. Wikimedia Foundation도 크롤러가 운영에 미치는 영향을 다룬 글을 발했으며, 주요 위키 팬은 다양한 수준의 장애를 겪고 있다.

사람을 가장하는 스크래퍼

과거에는 GPTBot, ClaudeBot, PerplexityBot 같은 공식 봇이 User Agent 문자열에서 쉽게 식별되어 Cloudflare나 nginx로 차단이 가능했다. 그러나 웹마스터가 User Agent 기반으로 AI 스크래퍼를 차단하기 시작하면서, 봇이 사람 트래픽처럼 위장할 강한 동기가 생겼다.

현재 위키에 도달하는 AI 스크래퍼 트래픽 대부분은 최신 Google Chrome처럼 보이도록 헤더를 보내며 요청을 정교하게 구성한다. 과거에 쓰던 명확한 "봇 또는 실제 사람" 신호가 사라져 차단이 어려워졌다.

수천만 IP와 프록시 우회

2023년 전에는 문제 있는 스크래핑의 95%가 단일 IP 주소나 작은 데이터센터 서브넷에서 발생해 IP 또는 ISP 특성 기반 차단이 효과적이었다. 그러나 주거용 프록시를 쓰면 신용카드만으로 수백만 IP 주소 네트워크를 통해 스크래핑 요청을 세탁할 수 있다.

위키는 하루에 100만 개 IP를 순환하는 스크래퍼 실행에 맞닥뜨리기도 하며, Comcast, AT&T, Charter 같은 주거용 ISP에서 온 합법적인 요청처럼 보인다는 문제가 있다. 해당 고객은 자신의 IP가 주거용 프록시의 출구 노드로 쓰이는지 모를 가능성이 크다.

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

많은 AI 스크래퍼는 위키 홈페이지를 방문한 뒤 그 페이지의 모든 링크를 방문하고, 다시 그 페이지들의 모든 링크를 방문하는 방식으로 URL을 고른다. robots.txt와 사이트맵이 스크래핑할 가치가 있는 URL을 알려주는데도 이를 인식하지 않는 것처럼 보인다.

OSRS Wiki에는 약 4만 개의 문서가 있으며, 이 URL들이 사이트의 유용한 정보 대부분을 구성한다. 하지만 이전 판본, 편집 화면, 특수 페이지까지 포함하면 탐색 가능한 URL은 최소 10억 개에 달한다. 이런 순진한 크롤링은 끝나지 않으며, LLM 학습 데이터로 유용하지 않은 URL에 많은 자원을 쓰는 것으로 보인다.

또한 이런 요청은 MediaWiki 파서 캐시 같은 캐시 계층을 우회해 서비스 비용을 키운다. 캐시 적중 요청은 보통 처리 시간이 20밀리초 미만이지만, 오래된 diff 같은 요청은 자주 1~2초가 걸린다. "하루 800만 봇 요청", "봇이 대역폭 65% 사용" 같은 상위 지표는 문제를 과소평가한다. 실제 병목은 대개 CPU 용량이며, 이상한 쿼리 파라미터가 붙은 봇 요청은 처리 비용이 일반 요청보다 50~100배 비쌀 때가 많다.

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

Cloudflare Challenge와 Anubis

웹사이트를 Cloudflare challenge나 Anubis 같은 도구 뒤에 두는 방식이 최근 1년 사이 인터넷에서 널리 쓰이게 되었다. 어느 정도 효과는 있지만, 일부 봇이 챌린지를 꾸준히 통과하는 시기가 있다. Cloudflare와 봇 개발자 사이에 보이지 않는 군비 경쟁이 있는 것으로 보이며, Cloudflare가 약 90%는 이기지만 남은 10%가 운영상 힘든 구간을 만듦니다.

실제 독자는 위키에 도달하기 전에 챌린지를 보는 것을 싫어한다. 대부분의 사람에게 영향을 주지 않으려면 어떤 트래픽에만 챌린지를 걸지 판단하는 좋은 휴리스틱 규칙이 필요하지만, 자동화 트래픽을 안정적으로 탐지하는 일 자체가 어렵다.

수작업 방화벽 규칙

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

특정 특수 페이지는 한 번 로그인해서 해당 쿠키가 설정된 클라이언트만 접근하게 하고, 아니면 거부하는 방식도 꽤 잘 동작한다. 대부분의 크롤러가 위키를 훑기 위해 특수 페이지를 노리므로, 로그인 사용자로 제한하면 시스템 부하가 크게 줄어든다.

"사람은 하는데 봇은 하지 않는 것" 찾기

유용한 관점은 사람들이 집합적으로 하는 행동 중 봇이 하지 않는 것을 찾는 방식이다. MediaWiki 기반 위키에는 실제 브라우저 사용자가 위키를 쓸 때 자주 만드는 여러 유형의 HTTP 요청이 있고, 봇은 보통 이를 만들지 않는다.

헤더, ja4 해시 등으로 분리 가능한 트래픽 덩어리가 많은 문서를 방문하면서도 전형적인 "사람" 요청을 만들지 않는다면, 해당 트래픽에 챌린지를 적용할 강한 신호가 된다. 테스트에서는 거의 모든 스크래퍼를 잘 찾아내는 것으로 보였지만, NoScript 사용자, 스크린 리더 사용자처럼 특이한 탐색 습관을 가진 사람에게 어떤 오탐이 생길지는 명확하지 않다.

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

AI 스크래퍼를 막는 "핵 옵션"은 실제 사용자에게 훨씬 더 파괴적이다. 흔한 방식 중 하나는 생성 비용이 클 수 있는 페이지를 보려면 로그인을 요구하는 것이다. Fandom은 몇 달 전 모든 위키에 이런 조치를 적용했다.

16년간 위키 커뮤니티를 만들며 얻은 핵심 교훈은 새 기여자를 끌어들이는 가장 좋은 방법이 마찰 제거라는 점이다. 편집을 더 쉽게 만들고, 위키 내부 구조를 더 쉽게 탐색하게 하며, 독자와 편집자를 가르는 진입 장벽을 낮춰야 한다. 극단적 안티봇 기법은 새 마찰을 만들고 예측 가능한 결과를 낳는다.

Fandom이 계정 없는 독자 95% 이상에게 "내부 페이지"를 숨긴 뒤, Fandom 전체의 신규 사용자 기여가 약 40% 감소한 것으로 나타났다. 이런 트레이드오프를 가치 있다고 보기 어렵다.

앞으로의 방향

위키 운영자 간 공개 논의와 봇 수집 유인을 바꾸는 API 접근이 필요하다. Cloudflare의 새 crawling API는 봇이 robots.txt를 무시하고 문제를 일으키는 자체 시스템을 만드는 것보다 API를 쓰는 편이 더 쉽다면 구도를 바꿀 수 있다.

lebih 나은 방식이 있다면 실제 수집 주체와 직접 연락해 덜 비효율적인 방법을 찾고 싶어하는 운영자들도 있다. 하지만 봇 소유자와 웹마스터의 군비 경쟁은 스크래핑의 구조적 유인을 바꾸는 영리한 방법이 나오기 전까지 계속될 가능성이 높다.

위키를 안정적으로 호스팅하려면 온콜 로테이션, ML 엔지니어, 엔터프라이즈 제품이 필요해지는 시나리오는 독립 위키 커뮤니티에 매우 나쁜 소식이다. 사람들이 쉽게 위키를 호스팅할 수 없다면 인터넷은 더 나빠질 것이다.

함께 보면 좋은 글

• FOSS 인프라가 AI 회사로부터 공격받고 있음

• Git의 --author 플래그로 GitHub 저장소의 AI 봇 스팸을 막은 방법

• AI 보조 코딩에 대해 틀리는 열두 가지 방식

---

📚 출처

• https://news.hada.io/topic?id=29744