AI 스크래퍼 트래픽이 공개 위키의 운영 비용과 서버 안정성을 심각하게 위협하고 있다. 게임 위키 호스팅 업체인 Weird Gloop(위어드 글룹, 대형 게임 위키 호스팅 서비스)과 위키미디어 재단(Wikimedia Foundation) 등은 LLM 학습 데이터를 수집하려는 봇 트래픽 대응에 막대한 자원을 쏟고 있다. 적절한 완화 조치가 없을 경우, 이러한 봇들은 일반적인 인간 사용자의 활동보다 약 10배 더 많은 컴퓨팅 자원을 소모하는 것으로 나타났다.

특히 올해 위키 생태계에서 발생한 서버 문제의 약 95%가 악성 스크래퍼로 인해 발생한 것으로 추정되며, 일부 소규모 독립 위키는 트래픽 부하를 견디지 못하고 완전히 오프라인 상태가 되기도 했다. 과거에는 봇의 정체가 명확해 차단이 쉬웠으나, 최근의 스크래퍼들은 최신 브라우저로 위장하거나 수백만 개의 IP를 돌려쓰는 등 탐지 회피 기술을 고도화하며 운영자들을 압박하고 있다.

하루 100만 개 IP 순환하는 AI 봇의 '위장술'

GPTBot이나 ClaudeBot, PerplexityBot 같은 공식 AI 봇들은 자신이 누구인지 밝히는 명찰을 달고 다닌다. 브라우저 식별 정보인 유저 에이전트(User Agent)라는 헤더에 자신의 이름을 명확히 적어 보내기 때문에 웹사이트 운영자는 이를 확인하고 쉽게 차단 규칙을 세울 수 있다. 하지만 최근의 AI 스크래퍼들은 이런 정공법 대신 정교한 위장술을 택하고 있다. 쉽게 말하면 최신 구글 크롬 브라우저를 사용하는 일반 사람처럼 보이도록 요청 헤더의 세부 설정을 꾸미는 방식이다. 비유하자면 제복을 입고 당당하게 방문하던 배달원이 이제는 평범한 티셔츠를 입고 이웃 주민인 척 집 안으로 스며드는 것과 같다. 운영자 입장에서는 들어오는 트래픽이 데이터를 긁어모으러 온 봇인지, 실제로 정보를 읽으러 온 사람인지 구분하기가 매우 까다로운 상황이다.

더욱 교묘한 점은 접속 경로를 쉴 새 없이 바꾸는 주거용 프록시(Residential Proxy)의 활용이다. 프록시는 클라이언트와 서버 사이에서 요청을 전달해주는 대리 서버를 말하는데, 주거용 프록시는 실제 일반 가정집에서 사용하는 인터넷 회선을 경유하는 서비스다. 보통의 데이터센터 IP 주소는 특정 범위에 몰려 있어 한 번에 묶어서 막기 쉽지만, 주거용 IP는 전 세계 가정에 흩어져 있어 일괄 차단이 거의 불가능하다. 실제로 일부 스크래퍼는 컴캐스트(Comcast)나 AT&T, 차터(Charter) 같은 실제 주거용 인터넷 서비스 제공자(ISP)의 IP를 이용해 하루에 100만 개에 달하는 IP 주소를 순환시키며 접속을 시도한다. 비유하자면 한 곳의 사무실 전화기로 계속 전화를 거는 것이 아니라, 매번 다른 집의 전화기를 빌려 전화를 거는 식이다. 정작 해당 IP를 할당받아 사용하는 일반 가정의 사용자는 자신의 인터넷 회선이 봇의 통로로 쓰이고 있다는 사실조차 인지하지 못할 가능성이 크다.

위장술은 여기서 그치지 않고 신뢰받는 외부 서비스의 이름을 빌려 보안망을 우회하기도 한다. 구글 번역(Google Translate)의 URL 도구를 이용하면 요청이 구글 서버에서 오는 것처럼 위장되어 웹사이트의 보안 필터를 쉽게 통과할 수 있다. 실제로 분석 결과 구글 번역 도구를 통해 들어오는 요청의 99.99%가 악용성으로 판명될 만큼 이 수법은 매우 광범위하게 쓰이고 있다. 페이스북의 링크 미리보기 기능인 facebookexternalhit을 이용해 실제 요청 출처를 가리는 방식도 같은 맥락이다. 이러한 정교한 위장술과 IP 순환 기법이 결합하면서 기존의 단순한 차단 방식은 사실상 무력화되고 있다. 올해 위키 서버에서 발생한 문제의 약 95%가 이런 나쁜 스크래퍼들로 인해 발생했다는 수치는 AI 봇의 공격적인 수집 활동이 단순한 트래픽 증가를 넘어 서비스의 생존과 안정성을 직접적으로 위협하는 수준에 이르렀음을 보여준다.

4만 개 문서 대신 10억 개 URL을 훑는 '멍청한 크롤링'

OSRS Wiki(올드스쿨 런스케이프 위키)의 실제 유용한 문서는 4만 개 정도지만, 봇이 탐색할 수 있는 전체 URL은 10억 개가 넘는다. 일반적인 크롤러라면 사이트맵(웹사이트의 지도 역할을 하는 파일)을 보고 효율적으로 필요한 페이지만 골라 가지만, 일부 AI 스크래퍼는 페이지 내의 모든 링크를 무차별적으로 방문하는 방식을 쓴다. 비유하자면 도서관에서 정식 출판된 책 4만 권만 읽으면 될 일을, 서고 구석에 쌓인 수정 초안과 메모지, 편집용 임시 문서와 폐기 예정 기록까지 전부 다 뒤지는 꼴이다. 이런 멍청한 크롤링은 서버에 기하급수적인 부하를 준다. 특히 LLM(거대언어모델) 학습 데이터로 전혀 가치가 없는 편집 화면이나 아주 오래전의 이전 판본 기록까지 긁어모으느라 정작 서버의 소중한 컴퓨팅 자원을 낭비하게 만든다.

서버 비용이 폭증하는 결정적인 이유는 요청 하나를 처리하는 데 드는 비용의 격차에 있다. 보통 사용자가 자주 찾는 페이지는 캐시(데이터를 미리 저장해 빠르게 보여주는 임시 저장소)에 저장되어 있어 응답 시간이 20밀리초 미만으로 매우 짧다. 하지만 봇이 요청하는 오래된 버전의 변경 사항 비교(diff) 페이지는 캐시 계층을 완전히 우회하여 서버가 매번 데이터를 대조하고 계산해야 하므로 처리 시간이 1~2초까지 늘어난다. 여기에 정체불명의 쿼리 파라미터(URL 끝에 붙는 추가 정보)가 복잡하게 얽힌 요청이 들어오면 처리 비용은 일반 요청보다 50배에서 100배까지 비싸진다. 쉽게 말하면 편의점에서 미리 만들어진 샌드위치를 집어가는 것과, 주방장에게 재료 하나하나를 새로 손질해 정교한 요리를 만들어달라고 주문하는 것만큼의 차이가 발생하는 셈이다.

트래픽의 단순한 양보다 더 무서운 것은 예측 불가능한 스파이크 현상이다. 월간 봇 요청은 약 2억 5천만 건으로 초당 평균 100건 수준이지만, 이는 장기적인 평균일 뿐이다. 실제 스크래퍼는 짧은 시간 동안 초당 1,000건 이상의 요청을 쏟아붓는 경우가 잦으며, 이는 의도적인 서비스 거부 공격인 DDoS(디도스)와 거의 구분되지 않는 양상을 띤다. 더 치명적인 점은 자원 점유의 효율성이다. 봇이 사용하는 CPU 사용량이 전체의 50% 수준에 불과하더라도, 실제 서비스 장애의 95%는 이런 악성 트래픽 스파이크가 유발한다. 단순한 트래픽 증가가 아니라 서버의 가장 취약한 경로를 타격하는 비효율적인 요청들이 한꺼번에 몰리면서 시스템 전체를 마비시키는 구조이기 때문이다.

'로그인 강제'라는 핵 옵션이 불러온 기여자 40% 감소

Cloudflare Challenge나 Anubis(봇 탐지 도구) 같은 보안 솔루션을 도입하면 전체 봇 트래픽의 약 90%를 걸러낼 수 있다. 하지만 남은 10%의 정교한 봇들이 서버를 계속 괴롭히면서 운영자들은 더 깊은 곳을 파헤치기 시작했다. 이제는 단순히 봇이 주장하는 신분증인 User Agent를 보는 수준을 넘어 ja4 해시(TLS 지문 기반 식별자)나 TLS cipher(암호화 방식) 같은 복잡한 요청 속성을 분석한다. 쉽게 말하면, 상대가 내민 신분증만 믿지 않고 걸음걸이나 필체, 사용하는 단어의 습관 같은 고유한 연결 특성을 분석해 정체를 밝혀내는 식이다.

문제는 이런 기술적 방어선이 무너질 때 선택하는 극단적인 조치, 이른바 핵 옵션이 커뮤니티의 뿌리를 흔든다는 점이다. 대표적인 사례가 위키 호스팅 플랫폼인 Fandom(팬덤)의 로그인 강제 조치다. 봇의 접근을 원천 차단하기 위해 특정 페이지를 보려면 반드시 계정을 만들어 로그인하게 만들었는데, 그 결과 신규 사용자의 기여도가 약 40%나 급감했다. 비유하자면 마을 도서관에 불청객이 들어오는 것을 막겠다고 높은 담장을 쌓고 출입증을 요구하는 것과 같다. 불청객은 막았을지 모르나, 정작 도서관을 가꾸려던 새로운 자원봉사자들까지 진입 장벽에 막혀 발길을 돌리게 만든 셈이다.

현재 운영자들은 보안과 개방성 사이에서 아슬아슬한 줄타기를 하고 있다. 사람이 실제로 웹사이트를 이용할 때 보이는 특유의 패턴을 분석하는 인간 행동 요청(Human-like requests) 기반의 휴리스틱(경험적 추측) 탐지 시스템을 테스트하는 이유도 이 때문이다. 하지만 이런 정교한 시스템을 직접 구축하고 유지하는 비용은 만만치 않다. 실제로 상용 봇 탐지 제품의 연간 비용은 여섯 자리 수, 즉 수십만 달러에 달해 소규모 독립 위키들이 감당하기에는 너무 무거운 짐이다. 결국 Cloudflare가 제공하는 새로운 crawling API(데이터 수집 전용 인터페이스)를 통해 봇들이 무분별한 스크래핑 대신 정해진 통로를 이용하도록 유인하는 방식이 현실적인 대안으로 거론되고 있다.