커널 git 서버, AI 크롤러 때문에 CPU 20%를 그냥 태우고 있다

출처: Konstantin Ryabitsev (people.kernel.org)
원문: https://people.kernel.org/monsieuricon/creepy-crawlies
작성자: 팔복소프트-김팔복

한눈에 보기

• kernel.org 관리자 Konstantin Ryabitsev가 AI 크롤러가 git.kernel.org에 주는 부하를 실측 수치로 공개했다.
• 5개 노드 총 90코어 중 14~16코어가 상시 크롤러용 커밋 HTML 렌더링에만 쓰이고 있다. 전체 용량의 약 20%다.
• 크롤러는 git clone이라는 효율적인 수단을 놔두고, cgit 웹 UI에서 커밋을 하나씩 HTML로 긁는 가장 비효율적인 방식을 택했다.
• linux.git은 약 148만 커밋에 포크가 922개라, 크롤러 입장에서는 유효 URL이 수십억 개 규모로 존재한다.
• PoW(작업증명) 기반 차단 도구 Anubis를 붙여 한동안 효과를 봤지만, 봇들이 난이도 4에 이어 5까지 풀기 시작했다.
• 현재 일 600만 건의 커밋 조회 요청 중 정상 이용자는 약 2%로 추정된다.
• 대응책으로 익명 접근 시 일부 기능을 꺼서 크롤링 가능한 URL 자체를 줄이는 방향으로 가고 있다.

배경

git.kernel.org는 리눅스 커널 공식 git 저장소를 웹에서 열람할 수 있게 해주는 cgit 기반 서비스다. cgit은 커밋, diff, patch, 임의 커밋 간 비교까지 전부 URL로 접근할 수 있게 해주는데, 이 유연함이 크롤러 시대에는 URL 폭발이라는 부메랑이 됐다. 한편 커널 커밋 히스토리는 전부 LLM 등장 이전에 사람이 쓴 코드와 텍스트라는 점이 보장되기 때문에, 모델 학습 데이터로서 가치가 높다. AI가 생성한 데이터로 AI를 다시 학습시키면 품질이 무너지는 문제(model collapse) 때문에, "AI 오염이 없는" 데이터의 몸값이 올라간 상황이다.

주요 내용

가장 비효율적인 수집 방식

kernel.org는 저장소 전체를 git clone으로 통째로 받아가라고 열어두고 있다. LKML(리눅스 커널 메일링 리스트) 아카이브조차 git 저장소로 clone할 수 있다. 학습 데이터가 목적이라면 clone 한 번으로 전체 히스토리를 얻는 것이 압도적으로 효율적이다.

그런데 크롤러들은 웹 UI를 커밋 단위로 긁는다. 148만 커밋짜리 저장소의 포크 922개를 각각 돌면서, 백엔드에서는 같은 객체인 커밋을 922번 중복으로 렌더링하게 만드는 식이다. 서버는 매 요청마다 커밋을 HTML로 새로 렌더링해야 하니, 정적 파일 서빙과는 비용 차원이 다르다.

차단 전쟁의 에스컬레이션

대응은 단계적으로 강해졌지만 크롤러도 같이 진화했다.

특히 3→4단계 전환이 결정적이었다. 크롤러가 수백만 개의 주거용 IP에서 IP당 4~5회만 요청하고 사라지는 패턴으로 바뀌자, IP 차단 자체가 무의미해졌다. 이 IP들의 출처는 스마트 TV나 앱에 심어진 프록시 SDK다. 앱 수익화 명목으로 사용자의 가정용 회선을 프록시로 파는 사업이 이미 산업 규모로 존재한다.

Anubis는 접속자에게 SHA-256 해시 퍼즐을 풀게 해서 크롤링의 경제성을 무너뜨리는 도구다. 처음에는 봇이 그냥 포기하고 떠날 정도로 효과적이었지만, 지금은 일 600만 요청 중 33%가 연산 비용을 감수하고 퍼즐을 풀고 들어온다. 그만큼 이 데이터가 학습용으로 값어치가 있다는 뜻이다. 부작용도 있다. 난이도 5는 모바일 기기에서 몇 초가 걸리고 발열도 생겨서, 정상 사용자 경험이 같이 나빠졌다.

결과와 향후 방향

현재 서비스가 마비된 수준은 아니지만, 전체 CPU의 20%가 학습 데이터 공급이라는 단일 용도에 상시 소모되고 있다. Ryabitsev는 익명 접근에서 비용이 큰 기능을 끄고 크롤링 가능한 URL 수를 줄이겠다고 밝혔다. 다만 요청하는 사람에게는 데이터 전체 다운로드를 계속 제공하겠다는 원칙은 유지한다.

팔복소프트 관점

• 이건 kernel.org만의 문제가 아니다. 국내에서도 self-hosted GitLab, Gitea, cgit을 외부에 열어둔 팀이라면 같은 패턴의 트래픽을 이미 받고 있을 가능성이 높다. 접근 로그에서 오래된 커밋·diff URL로의 산발적 요청이 많다면 의심해볼 만하다.
• 기술적으로 주목할 부분은 "robots.txt와 IP 차단이라는 기존 방어 체계가 사실상 끝났다"는 실증이다. 주거용 프록시를 통한 분산 크롤링 앞에서는 WAF의 rate limit도 IP 단위로는 무력하다. 국내 서비스도 봇 대응 전략을 IP 기반에서 행동 패턴·비용 부과 기반으로 옮겨야 한다.
• Anubis 같은 PoW 방식도 만능이 아니라는 점이 확인됐다. 데이터 가치가 연산 비용을 넘으면 봇은 그냥 비용을 지불한다. 결국 방어는 "차단"이 아니라 "비용 전가 + URL 표면적 축소"의 조합으로 갈 수밖에 없고, 이는 익명 사용자 편의를 깎는 트레이드오프를 동반한다. Cloudflare의 AI 크롤러 차단·과금 같은 상용 옵션과 비교하면, Anubis는 무료 self-hosted라는 장점 대신 이 군비경쟁을 직접 감당해야 한다.
• 운영 관점에서 실용적인 교훈 하나: 동적 렌더링 URL을 무한정 열어두는 설계 자체가 리스크다. cgit처럼 임의 커밋 간 diff까지 URL로 만들어주는 기능은, 사람만 쓰던 시절의 유산이다. 사내 도구를 외부 공개할 때 "URL 공간이 얼마나 큰가"를 이제는 보안 항목처럼 점검할 필요가 있다.
• 아쉬운 점은 크롤러 운영 주체에 대한 책임 추궁이 사실상 불가능하다는 것이다. 주거용 프록시 뒤에 숨은 이상, 어느 AI 회사의 트래픽인지 특정할 수 없고, 오픈소스 인프라가 비용을 일방적으로 떠안는 구조가 당분간 이어질 것이다.

정리

기억할 것은 세 가지다. AI 크롤러는 이제 클라우드가 아니라 가정용 IP에서 브라우저인 척 들어오고, IP 차단과 robots.txt는 이들에게 통하지 않으며, PoW 방어조차 데이터 가치가 높으면 뚫린다. 외부에 git 웹 UI나 동적 렌더링 페이지를 열어둔 팀이라면, 지금 로그를 확인하고 익명 접근의 URL 표면적을 줄이는 작업을 검토할 시점이다. 무료 공개 인프라의 비용 구조가 바뀌고 있다.

• kernel.org
• AI크롤러
• Anubis
• 봇차단
• 인프라운영