AI 크롤러의 비용: git.kernel.org에서 얻는 교훈

AI 스크레이퍼가 git.kernel.org CPU 용량의 20%를 점유

AI 크롤러는 git.kernel.org에 지속적인 "배경 방사선"과 같은 시스템 부하를 생성하며, 대규모 언어 모델(LLM) 학습에만 사용되는 데이터를 생성하기 위해 상당한 컴퓨팅 자원을 영구적으로 점유하고 있습니다. 현재 총 90개의 코어를 가진 5개의 지리적 분산 노드에서, 약 14~16개의 코어가 스크레이퍼를 위해 git 커밋을 HTML로 렌더링하는 데만 전용되고 있습니다. 이는 사이트 전체 용량의 약 20%에 해당합니다.

HTML 스크레이핑 vs. Git 클로닝의 비효율성

데이터 획득을 위한 매우 효율적인 방법이 있음에도 불구하고, AI 크롤러는 가장 자원 집약적인 방식을 선택하고 있습니다. Linux 커널 전체 이력과 LKML 아카이브는 git clone을 통해 이용 가능하여 스크레이퍼가 전체 이력을 한 번에 다운로드하고 로컬에서 처리할 수 있음에도 불구하고, 봇들은 대신 모든 커밋을 HTML로 렌더링하고 결과 페이지를 파싱하고 있습니다.

이 비효율성은 사용 가능한 URL의 조합 폭발로 인해 더욱 심화됩니다. linux.git에 약 148만 개의 커밋과 922개의 포크가 있어, 커밋, 패치, 일반 렌더링 및 diff에 대한 유효한 URL의 수는 수십억 개에 달합니다. 스크레이퍼들은 버려진 포크에 있는 URL을 포함하여 이러한 수십억 개의 URL을 빈번하게 타겟팅하며, 이는 고유한 데이터를 제공하지 않으면서도 엄청난 서버 부하를 발생시킵니다.

봇 완화 전략의 진화

봇이 점점 더 정교해짐에 따라 이러한 크롤러를 차단하기 위한 노력은 여러 단계를 거쳐 진화해 왔습니다.

  1. User-Agent 및 IP 차단: 초기에는 봇의 자체 식별 User-Agent나 명백한 데이터 센터 IP 범위(예: Google Compute Engine)를 기반으로 봇을 차단하려 시도했으나, 봇들이 표준 웹 브라우저인 척하기 시작하면서 빠르게 우회되었습니다.
  2. 주거용 프록시 네트워크: 크롤러들은 수백만 개의 주거용 및 모바일 IP를 사용하기 시작했으며, 이는 종종 가전제품(예: Smart TV)을 프록시로 사용하는 "프록시 SDK 수익화" 체계를 통해 라우팅됩니다. 이로 인해 각 IP가 사라지기 전에 몇 번의 요청만 수행하므로 IP 기반 차단은 효과가 없습니다.
  3. Proof-of-Work (PoW) 챌린지: 스크레이핑의 경제적 비용을 역전시키기 위해, git.kernel.org는 클라이언트가 콘텐츠에 접근하기 전에 수학적 과제(SHA-256)를 해결해야 하는 작업 증명(proof-of-work) 시스템인 Anubis를 구현했습니다.

Proof-of-Work의 영구적 해결책으로서의 실패

Anubis는 초기에 효과적이었으나, 나아가서는 군비 경쟁이 되었습니다. 현재 시스템은 무작위 커밋에 대한 일일 약 600만 건의 요청을 처리하고 있으며, 그 중 66%는 챌린지로 차단되지만 33%는 이제 수학 문제를 풀고 사이트에 접속합니다.

커뮤니티의 기술적 분석에 따르면, PoW는 지속 불가능한 전략입니다. 계산 비용이 비대칭적이기 때문입니다. 고성능 스크레이퍼는 모바일 기기를 사용하는 정당한 사용자가 훨씬 더 효율적으로 이러한 챌린지를 해결할 수 있습니다. 예를 들어, iPhone 사용자는 높은 난이도의 챌린지를 해결하는 데 몇 초가 걸리고 기기가 발열하는 것을 경험할 수 있지만, 봇은 최적화된 C 커널이나 특수 하드웨어를 사용하여 동일한한 챌린지를 밀리초초 단위로 해결할 수 있습니다.

커뮤니티 인사이트 및 대안적 제안안

개발자와 사이트 관리자들 사이의 논의를 통해, 이것이 Linux 커널뿐만 아니라 많은 공개 리소스에 영향을 미치는 시스템적 문제임을 알 수 있습니다.

관찰된 패턴

  • 타겟팅된 크롤링 vs. 일반 크롤링: 일부에서는 봇이 git 호스트를 특정하여 타겟팅하는 것이 아니라, 단순히 일반적인 웹 크롤링 과정에서 사용 가능한 모든 링크를 따라가며 git 웹 인터페이스의 조합적 특성으로 인해 생성된 "크롤러 트랩"에 빠지는 것이라고 주장합니다.

  • 합성 데이터 리스크: 저자는 LLM-free 데이터(예: 커널 커밋)는 매우 소중히 여약되어야 한다고 언급합니다. LLM이 생성한 콘텐츠로 LLM을 학습시키는 것은 "디지털 프리온 질병"(모델 붕괴)을 유달히하게 만듭니다.

제안된 기술적 완화책 o

  • 클라이언트 측 렌더링: HTML 렌더링 로직을 JavaScript를 통해 사용자의 브라우저로 옮겨, 서버를 단순한 파일 및 diff 파일의 객체 저장소로 전환하는 방식입니다.
  • 게이트형 접근: git clone은 제한 없이 유지하되 HTML 뷰에 대해서는 인증을 요구하거나, 인증되지 않은 요청에 대해 공격적인 속도 제한(rate limiting)을를까
  • Tarpitting (타르피팅): 감지된 봇에게 가짜 데이터를 제공하거나 매우 느린 응답을 제공하여 그들의 자원을 낭비하게 만드는 "ioicaine-style" 트랩을 구현하는 방식입니다.
  • 수익화: 작업 증명(proof-of-work)에서 마이크로 결제(예: L402)로 전환하여 사용된 서버 자원의 실제 비용을을까

현재 상태 및 향후 전망

git.kernel.org는 현재 부하를 완화하기하기 위해 익명 사용자용 기능을 축소하고 비용이 많이 드는 기능을 끄고 있습니다. 관리진은 모든 데이터는 다운로드 가능하지만 사용자가 데이터에 접근하기 위해 더 많은 "허들"을 마주할 수 있다고 강조합니다. 훈련 데이터에 대한 수요가 계속 증가하고 주거용 프록시 네트워크 인프라가 확장됨에 따라 장기기적인 해결책은 여전히 불개명확하지 않습니다.n

Sources

관련

  • Dispatch
  • Dispatch
  • Dispatch
  • Dispatch
  • Dispatch