소름 끼치는 크롤러들

5 hours ago 3

AI 학습용 크롤러가 Git 커밋을 하나씩 HTML로 렌더링하면서, git.kernel.org에서 Git 복제를 포함한 모든 정상 접근을 합친 것보다 많은 CPU를 사용하고 있음 전체 저장소를 한 번 복제하면 될 데이터를 크롤러들이 약 148만 개 커밋과 922개 포크에서 URL별로 요청해, 같은 커밋을 최대 922번씩 중복 처리하게 만듦 IP와 ASN 차단을 시작하자 주거용·모바일 프록시로 옮겨가 IP마다 4~5회만 요청하고 사라지는 방식으로 차단을 피함 작업증명 도구 Anubis가 처음에는 효과가 있었지만 크롤러가 난이도 5의 SHA-256 문제까지 풀기 시작했고, 정상 모바일 사용자만 수초의 대기와 발열을 감수하게 됨 하루 약 600만 건의 무작위 커밋 요청 가운데 정상 트래픽은 넉넉히 잡아도 약 2%로 추정되며, 현재 전체 CPU의 약 20% 가 크롤러용 HTML 렌더링에 쓰이고 있음 Linux 개발 데이터가 크롤러를 끌어들이는 이유 Linux 개발은 복제 가능한 Git 저장소와 실시간 토론 아카이브를 통해 공개적으로 진행됨 커널의 전체 커밋 이력은 AI가 만든 콘텐츠가 섞이지 않은 AI 이전의 코드·설명·토론 데이터로 활용할 수 있음 LLM이 만든 콘텐츠로 다시 LLM을 학습시키면 품질이 떨어질 수 있으므로, AI 생성물이 없다고 확신할 수 있는 자료의 가치가 높아짐 Linux 커널 개발 이력은 규모가 크고 구조화돼 있으며 작성 시점도 분명해 학습 데이터 수집 대상이 되기 쉬움 저장소를 복제하지 않고 커밋마다 HTML을 요청함 kernel.org의 저장소와 메일 아카이브는 보존과 재사용을 위해 대부분 git clone으로 복제할 수 있음 Linux 커널 저장소 전체를 한 번 내려받아 모든 커밋을 순회할 수 있음 LKML 아카이브도 Git 저장소로 복제해 원하는 방식으로 처리할 수 있음 크롤러는 이 방식을 쓰지 않고 각 커밋을 서버에서 HTML로 렌더링한 뒤 결과를 다시 파싱함 linux.git에는 약 148만 개의 커밋이 있고 git.kernel.org에는 약 922개의 포크가 있음 서버 내부에서는 포크들이 같은 Git 객체를 공유하므로 효율적으로 저장되지만, 웹에서는 각 포크에 별도의 커밋 URL이 생김 그 결과 크롤러는 같은 148만 개 커밋을 최대 922번씩 요청할 수 있으며 유효한 URL도 수십억 개로 늘어남 cgit은 커밋 HTML 외에도 다음 결과를 요청에 따라 생성함 패치와 일반 텍스트 파...

Read Entire Article