LWN이 겪은 AI 스크래퍼 전쟁, 주범은 주거용 프록시였다

• LWN이 다시 스크래퍼 얘기를 꺼낸 이유는 단순함. 2025년에 이미 ‘AI 스크래퍼 봇 재앙’을 다뤘는데, 1년 넘게 지나도 문제가 줄기는커녕 더 커졌다는 것임

  • 몇 시간 동안 수백만 개의 고유 IP에서 요청이 들어오고, 각 IP는 두세 번만 사이트를 때린 뒤 사라지는 식
  • 유저 에이전트 같은 값은 얼마든지 조작되고, 요청 하나하나는 그냥 평범한 브라우저 사용자처럼 보이게 설계됨
  • 봇이 이미지나 CSS를 안 가져간다는 식의 단서는 있지만, 알아차렸을 때는 이미 그 IP가 다시 쓰이지 않아서 차단 효율이 거의 없음

• 핵심 인프라는 ‘주거용 프록시(residential proxy)’임. 데이터센터가 아니라 평범한 사람들의 집·휴대폰·스트리밍 기기가 봇 요청의 출구가 됨

  • 중앙 제어 노드가 감염되거나 동의받은 기기에 명령을 내리고, 기기는 웹페이지를 가져와 다시 컨트롤러로 넘김
  • 많은 경우 기기 주인은 자기 회선이 스크래핑에 쓰이는지 모름
  • LWN은 이런 구조가 단순 웹 스크래핑을 넘어, 수백만 기기가 붙어 있는 내부 네트워크 자원에 접근할 수 있는 권한이라는 점도 위험하다고 봄

• 운영자 유형도 꽤 노골적으로 갈림. 한쪽은 그냥 범죄형 봇넷이고, 다른 한쪽은 ‘윤리적으로 조달한 IP’ 같은 말을 붙인 회색지대 사업자임

  • 구글은 올해 초 IPIDEA라는 봇 네트워크를 차단했고, 그 직후 LWN의 스크래퍼 트래픽도 눈에 띄게 줄었다고 함
  • 최근에는 미디어 스트리밍 기기가 악성 스크래핑 소프트웨어의 주요 숙주로 지목됨. 출고 단계부터 문제가 있거나, 보안이 허술해 나중에 털리는 식
  • Bright Data 같은 회사는 무료 VPN을 제공하면서 사용자 기기를 자사 주거용 프록시 네트워크의 엔드포인트로 쓰는 모델을 광고함
  • 심지어 앱 개발자에게 SDK를 붙이게 하고, 그 앱 사용자의 네트워크 연결을 돈벌이에 쓰게 하는 업체들도 있음

• 대형 AI 회사의 공식 크롤러가 제일 큰 문제냐 하면, LWN은 그렇게 보지는 않음

  • 공개적으로 식별 가능한 크롤러는 보통 유저 에이전트에 정체를 밝히고, robots.txt 같은 규칙도 대체로 지킴
  • 물론 2003년에 쓴 글까지 매일 바뀌었을 거라는 듯 사이트 전체를 반복해서 긁는 건 여전히 짜증나는 일
  • 다만 수백만 시스템에서 몰려오는 압도적 트래픽의 주범으로 단정할 증거는 없다고 선을 그음
  • 문제는 누군가가 이 주거용 프록시 업체들에게 돈을 내고 있다는 점임. 공개 모델 회사일 수도 있고, 사설 모델·정부기관·범죄조직일 수도 있음

• 방어 쪽도 이미 군비 경쟁임. 열린 웹을 유지하려던 사이트들이 점점 문을 걸어 잠그고 있음

  • Anubis처럼 작업 증명(proof of work)을 요구하는 도구가 널리 퍼졌고, 상업용 봇 방어 서비스의 ‘사람인지 증명’ 버튼도 흔해짐
  • 신호등 타일 고르기, 퍼즐 맞추기 같은 캡차는 사용자를 괴롭히는 비용으로 전가됨
  • 많은 기능이 로그인이나 페이월 뒤로 들어갔고, iocaine 같은 도구로 스크래퍼에게 오염된 데이터를 먹이려는 시도도 나옴
  • LWN은 이 모든 것이 스크래퍼와 그 비용을 지불하는 쪽이 전 세계 웹 사용자에게 부과한 세금이라고 표현함

• LWN은 최근 역대 최대 규모의 스크래퍼 공격을 받았지만, 실제 독자 대부분은 눈치채지 못했을 정도로 버텼다고 함

  • 구체적 방어책은 공개하지 않음. 이 레벨에서도 공격자와 방어자가 서로 학습하는 군비 경쟁이기 때문
  • Anubis 같은 작업 증명은 쓰지 않았다고 밝힘. 정상 독자에게 지연을 만들고, 결국 스크래퍼도 우회할 가능성이 높다고 봤기 때문
  • 수백만 대의 남의 기계를 동원할 수 있다면 작업 증명 계산 비용도 그렇게 큰 장애물이 아닐 수 있음
  • 대신 사이트 일부를 공격 상황에 맞게 최적화하고, 공격 중에는 비싼 연산을 줄이는 식으로 대응했다고 함

• 흥미로운 디테일은 공격 중 응답 시간이 오히려 평시보다 더 좋아질 때도 있다는 점임

  • 방어 모드가 켜지면 고비용 작업을 줄이기 때문에 익명 사용자의 일부 기능은 제한될 수 있음
  • 로그인 사용자는 영향을 받지 않도록 설계했다고 함
  • 하지만 LWN은 이걸 ‘해결’로 보지 않음. 현재 대책이 무력화될 때 다음 단계를 이미 고민해야 하는 상황이라는 것

• 7월 2일 구글은 미국 연방수사국(FBI) 등과 협력해 NetNut이라는 주거용 프록시 네트워크를 차단했다고 발표함

  • 이 조치 이후 스크래퍼 공격량이 어느 정도 줄어든 것으로 보인다고 LWN은 말함
  • 다만 IPIDEA 때도 몇 달 평화롭다가 다시 공격이 올라왔기 때문에, 이번에도 오래 갈 거라고 기대하지 않음
  • 구글은 플레이 스토어가 NetNut 감염 앱을 검사한다고 강조했지만, LWN은 왜 이런 기능을 가진 앱이 앱스토어에 쉽게 들어갈 수 있는지 주요 벤더들이 침묵한다고 꼬집음

• 결론은 꽤 씁쓸함. AI 학습 데이터 경쟁이 독립 웹사이트를 약탈 가능한 자원처럼 취급하고 있고, 그 결과 열린 인터넷은 방어벽 뒤로 밀려나고 있음

  • LWN은 대규모 언어 모델(LLM)과 관련 기술을 만드는 회사들에 최소한의 윤리 기준을 요구해야 한다고 봄
  • 그 전까지는 사이트 운영자들이 각자 방어할 수밖에 없음
  • 문제는 이 방어 비용이 서버 운영자만의 문제가 아니라, 캡차·로그인·지연·검색 접근성 저하로 모든 사용자에게 돌아온다는 점임

---

기술 맥락

• 이 글에서 중요한 선택은 ‘나쁜 IP를 차단한다’가 아니라, 요청 비용 구조 자체를 바꾸는 쪽이에요. 주거용 프록시는 IP가 너무 빨리 바뀌기 때문에 전통적인 차단 목록 방식이 잘 안 먹히거든요.

• Anubis 같은 작업 증명은 봇에게 계산 비용을 떠넘기는 방식이에요. 그런데 공격자가 수백만 대의 남의 기기를 동원한다면, 그 계산 비용도 분산돼요. 그래서 LWN은 정상 독자의 지연을 늘리는 방식보다 사이트 내부의 고비용 작업을 줄이는 쪽을 택한 거예요.

• 여기서 방어의 핵심 레이어는 애플리케이션과 운영 정책 사이에 있어요. 정적 자원 요청 패턴, 로그인 여부, 비싼 쿼리나 렌더링 경로를 보고 공격 상황에서 처리 방식을 바꾸는 식이죠.

• 검색엔진이나 인터넷 아카이브를 막지 않으려는 선택도 중요해요. 특정 거대 검색엔진만 허용 목록에 넣으면 당장은 편하지만, 이미 강한 플랫폼을 더 강하게 만들 수 있거든요. 열린 웹을 지키려는 사이트일수록 이 트레이드오프가 꽤 아프게 다가와요.