코어 14개가 크롤러만 위해 돈다 — 열린 인프라의 청구서는 누가 받는가
코어 14개가 크롤러만 위해 돈다 — 열린 인프라의 청구서는 누가 받는가
AI 학습용 크롤러가 공용 오픈소스 인프라에 지우는 비용은 누가 부담해야 하는가. 그리고 왜 크롤러는 같은 데이터를 가져가면서 언제나 가장 비싼 경로를 고르는가.
도입
2026년 8월 29일, kernel.org 의 인프라를 운영하는 Konstantin Ryabitsev 가 개인 블로그에 “Creepy crawlies” 라는 글을 올렸다. 이 글이 같은 주제의 다른 성토문과 갈리는 지점은 첫 문단에 이미 나온다. 그는 “AI 크롤러에 대한 내 불평을 들어본 적이 있을 것”이라고 운을 뗀 뒤, 이번에는 그 영향을 보여줄 “실제 수치”가 생겼다고 적는다. 감정이 아니라 계측 결과를 내놓겠다는 선언이다.
요약에 해당하는 두 문장이 글 전체의 무게를 지고 있다. 첫째, kernel.org 는 스크레이퍼를 위해 커밋을 HTML 로 렌더링하는 데에, git clone 을 포함한 모든 정상 접근을 합친 것보다 더 많은 CPU 사이클을 쓴다. 둘째, 지리적으로 분산된 5개 노드에서 어느 순간에나 CPU 코어 14개가 오직 git 커밋을 HTML 로 그리는 일만 하고 있다. 그는 이 상태를 “시스템 부하의 상시적 배경 복사(background radiation)“라고 부른다. 부하 스파이크가 아니라, 용량의 일부가 영구히 뜯겨 나간 상태라는 뜻이다.
이 글이 Hacker News 에서 1384점과 708개의 댓글을 받은 이유도 여기에 있다. 대부분의 크롤러 논쟁은 저작권과 윤리의 언어로 진행됐다. Ryabitsev 의 보고는 그 논쟁을 회계의 언어로 옮겨 놓는다. 누군가 학습 데이터를 얻는 동안, 그 데이터를 공짜로 내주기로 이미 결정한 조직이 자기 용량의 5분의 1을 지불하고 있다. 문제는 데이터를 주느냐 마느냐가 아니라, 데이터를 주는 방식의 비용을 누가 청구받느냐다.
600만 요청과 코어 14개 — kernel.org 가 실제로 측정한 것
수치부터 정리한다. git.kernel.org 는 하루 약 600만 건의 요청을 받으며, 그 요청들은 임의의 커밋을 보여 달라고 한다. 이 가운데 66퍼센트는 Anubis 챌린지에서 즉시 튕겨 나간다. 나머지 33퍼센트는 챌린지의 연산을 실제로 풀고 본 사이트까지 들어온다. Ryabitsev 는 어느 쪽이 봇이고 어느 쪽이 사람인지 확실히 구분할 수는 없다고 단서를 달면서도, “오래된 임의의 포크에 있는 오래된 커밋을 요청하고 있다면 그건 일하러 온 개발자가 아닐 확률이 높다”고 적는다. 그가 “넉넉하게 잡은 가정”을 여러 겹 얹어 추정한 정상 요청 비율은 전체 트래픽의 약 2퍼센트다.
이 2퍼센트가 자원으로 환산되면 다음과 같다. 5개 노드에 걸친 전체 90개 코어 가운데, 14개에서 16개가 상시로 스크레이퍼를 위한 커밋 렌더링만 수행한다. 평균 20퍼센트다. 다만 그는 이 평균값이 실제 그래프를 왜곡한다고 덧붙인다. 크롤러 무리는 파도처럼 몰려오기 때문에 실제 곡선은 20퍼센트 평탄선보다 훨씬 뾰족하다.
주목할 만한 반전이 하나 있다. kernel.org 를 실제로 넘어뜨리는 것은 스크레이퍼가 아니다. 그는 사이트가 여전히 빠르고 반응이 좋을 것이라고 말한 뒤, 서비스를 실제로 죽이는 범인으로 잘못 설계된 CI 시스템을 지목한다. 20개 노드에서 동시에 stable.git 을 얕은 복제(shallow clone)하는 종류의 행위다. 그는 “얕은 복제는 끔찍하다. 그런 짓을 할 거면 자기 미러를 직접 돌려라”라고 못 박는다. 스크레이퍼는 시스템을 죽이지 않는다. 대신 용량의 5분의 1을 영구히 점유한다. 이 구분이 중요하다. 장애가 아니라 상시 과세이기 때문에, 알림도 울리지 않고 대응 우선순위도 밀린다.
왜 하필 kernel.org 인가. 그의 설명은 데이터의 품질에 관한 것이다. 리눅스 개발은 공개적으로 이루어진다. 저장소도 복제 가능하고 토론 아카이브도 실시간으로 따라갈 수 있다. 대형 언어 모델 입장에서 이것은 학습 데이터의 노다지인데, 즉시 이용 가능하다는 점보다 더 중요한 성질이 있다. 순도 높은 AI 이전(pre-AI) 콘텐츠임을 보증할 수 있다는 것이다. 그는 LLM 이 생성한 콘텐츠로 LLM 을 학습시키는 것을 “디지털 프리온 병”에 비유하며, 커밋 히스토리 전체처럼 LLM 오염이 없다고 보증되는 소스는 그 무게만큼의 금값이라고 쓴다.
그리고 문제의 핵심인 URL 공간이 나온다. 집필 시점에 linux.git 은 약 148만 개의 커밋을 갖고 있다. git.kernel.org 에는 그 포크가 약 922개 존재한다. 백엔드에서는 이것이 대단히 효율적이다. 대부분의 오브젝트가 모든 포크에서 공유되기 때문이다. 그러나 스크레이퍼에게 이것은 수십억 개의 유효한 URL 이며, 그 전부를 긁어 봐야 손에 들어오는 것은 같은 148만 커밋의 922벌 사본이다. 여기에 cgit 이 제공하는 부가 기능 — 패치, 평문 렌더, 임의의 두 커밋 사이의 diff — 이 조합적으로 곱해진다. 그는 포크 하나만으로 “1.2 메트릭 바질리언”개의 유효 URL 을 생성할 수 있다고 과장 섞인 표현을 쓴다. 정확한 수가 중요한 게 아니라, 유한한 저장소에서 사실상 무한한 URL 표면이 파생된다는 성질이 중요하다.
방어의 역사도 그대로 기록되어 있다. 처음에는 쉬웠다. 봇들이 User-Agent 로 자기 정체를 친절히 알려 줬기 때문에 로그를 보고 fail2ban 하면 끝났다. 봇들이 영리해져 평범한 브라우저를 사칭하기 시작하자 IP 단위 차단으로 옮겼다. 8년 전에 버려진 리눅스 포크의 모든 커밋을 순회하는 IP 가 윈도우에서 링크를 미친 듯이 클릭하는 개인 사용자일 리는 없다. 봇들이 서브넷 전체로 퍼지자 ASN 단위 차단으로 올라갔다. Google Compute 에서 오는 IP 가 파이어폭스 사용자를 자칭한다면 정당한 차단이라는 논리였고, 커밋 안의 링크 검사를 자동화하던 정상 인스턴스가 가끔 함께 잘려 나가는 것은 감수했다.
진짜 악화는 그다음이었다. 크롤러가 수백만 개의 임의의 주거용·모바일 IP 에서 오기 시작했고, 전부 최신 브라우저를 사칭했다. 그런 IP 하나는 요청 4~5건을 날리고 로그에서 영영 사라진다. 봇이라고 판별했을 때는 이미 볼일을 끝낸 뒤이므로 차단할 이유가 없고, 다시 오지 않을 IP 를 방화벽 룰셋에 쌓아 올리는 낭비만 남는다. 그는 이 무리를 메뚜기 떼에 비유한다. 시스템이 쓰러질 때까지 빠르고 세게 때리고, 다음 표적으로 넘어갔다가, 복구되면 돌아온다. 그리고 이 공급망의 이름을 지목한다. “프록시 SDK 수익화”다. 큰 사업이고, “당신의 TV 도 아마 그 일을 하고 있다.”
HN 토론에서 한 이용자는 자기 블로그 통계에서 같은 현상을 관측했다고 보고했다. 예전에는 몇몇 국가에서 소수의 조회가 들어왔는데, 최근 몇 달 사이 아주 작은 나라들과 구식·희귀 브라우저 및 운영체제에서 조회가 잡히기 시작했다는 것이다. 그는 스크레이퍼가 여러 나라의 VPN 서비스에 헤더 익명화 도구를 겹쳐 기기 정체를 감추는 것으로 추정한다 (@initramfs). 출처 분산은 이제 대형 사업자만의 기법이 아니다.
마지막 방어선이 Anubis 였다. 자기 IP 와 서버가 준 비밀값을 조합해 SHA256 해시 앞자리에 0이 4개 오도록 만드는 문자열을 찾게 하는, 버리는 연산을 강제하는 관문이다. 효과는 즉각적이었다. 봇들은 그냥 포기했고 몇 달간 평화가 왔다. 몇 달 뒤 봇들이 난이도 4를 풀기 시작하자 난이도를 5로 올렸다. 정상 사용자의 불편은 이때부터 실측 가능한 크기가 됐다. 난이도 5는 모바일 기기에서 몇 초가 걸리고, 그동안 전화기가 불편할 만큼 뜨거워진다. 그렇게 몇 달을 더 벌었다. 그리고 봇들이 난이도 5도 풀기 시작했다. 지금의 33퍼센트가 그 결과다.
왜 가장 비싼 경로가 크롤러에게는 합리적인가
Ryabitsev 가 던지는 질문은 단순하다. “인공지능”을 자칭하는 무언가라면 우리 데이터를 학습에 쓰는 가장 효율적인 방법을 택하지 않겠는가. 저장소를 복제하고, 모든 커밋을 순회하면 끝이다. kernel.org 는 거의 모든 것을 복제 가능하게 만들어 두었다. 저장소도, 아카이브도 그렇다. LKML 전체를 복제해 원하는 대로 쓸 수 있다는 사실을 아느냐고 그는 되묻는다. 전부 git 저장소다. 그런데 크롤러들은 “가능한 가장 멍청한 방식”, 즉 모든 것을 커밋 단위 HTML 로 렌더링시킨 뒤 그것을 파싱하는 쪽을 택한다.
여기에 대한 가장 설득력 있는 반론이 HN 토론에서 나왔다. 이런 저장소가 크롤링 대상의 10퍼센트 이상을 차지한다면 복제 가능한 저장소를 위한 특수 경로를 넣는 것이 똑똑한 선택이겠지만, 웹 전체를 긁고 있는 입장이라면 더 파싱하기 좋은 대안이 존재하는 특수 케이스마다 효율화를 넣지는 않는다는 지적이다 (@lkbm). 같은 이용자는 “왜 그냥 git clone 하지 않는가”라는 질문에 더 짧게 답했다. 10억 개의 웹페이지를 긁고 있고 그중 git clone 이 가능한 것은 극히 일부인데, 그 일부를 위한 특수 처리를 설정하는 것은 크롤러 입장에서 들일 만한 수고가 아니라는 것이다.
이 설명이 중요한 이유는 크롤러를 악의로 설명하지 않기 때문이다. 악의라면 설득이나 규범으로 교정할 여지가 있다. 그러나 이것은 합리적 무관심이다. 효율적 경로는 크롤러의 엔지니어링 시간을 소비하고, 비효율적 경로는 남의 CPU 를 소비한다. 두 비용이 서로 다른 장부에 기록되기 때문에, 크롤러의 최적화 계산에는 kernel.org 의 14개 코어가 아예 등장하지 않는다. 이것이 외부효과(externality)의 교과서적 정의다. 생산자가 자기 결정의 한계비용을 지지 않으면 절약할 유인도 생기지 않는다. HN 의 한 이용자가 던진 질문은 이 구조를 정확히 겨눈다. 모든 이용자가 자기 몫을 냈다면, 그러니까 실제로 일하는 사람들에게 떠넘기지 않았다면 AI 접근 비용은 얼마였겠는가 (@Artoooooor).
여기서 흥미로운 비대칭이 하나 더 드러난다. 922개의 포크는 백엔드에서 거의 공짜다. 오브젝트가 공유되기 때문이다. 그러나 스크레이퍼에게 각 포크는 완전히 새로운 URL 네임스페이스다. 저장 효율은 크롤 효율로 번역되지 않는다. 서버 쪽 최적화가 훌륭할수록 노출되는 URL 표면은 오히려 넓어지고, 그 표면을 그리는 비용은 요청이 올 때마다 발생한다.
캐싱으로 해결될 문제 아니냐는 반응도 많았다. git 의 성질상 그 HTML 은 대부분 불변이니 캐시가 잘 들을 것이고, cgit 이 매번 생성하는 것보다는 훨씬 싸지 않겠느냐는 것이다 (@chuckadams). 리버스 프록시 캐시를 앞에 두면 극적으로 줄어들 것이라는 의견도 붙었다 (@Zariel). 이에 대한 반박이 문제의 성질을 잘 요약한다. cgit 은 구식 서버 사이드 렌더러이고 렌더 가능한 페이지가 조합적으로 폭발하기 때문에, 합리적으로 저장할 수 있는 것보다 훨씬 많은 페이지가 존재한다는 것이다 (@rcxdude). 캐시는 요청 분포가 좁은 인기 집합에 몰릴 때 작동한다. 여기서는 요청이 사실상 무한한 공간에 고르게 퍼진다. 적중률이 0에 수렴하는 캐시는 비용을 옮기지 않고 한 단계 더할 뿐이다. 다른 이용자가 짚었듯 cgit 은 스스로를 “git 저장소를 위한 초고속 웹 프론트엔드”라고 소개한다. 봇들에게는 어떤 속도도 충분히 빠르지 않다 (@kees99).
그렇다면 Anubis 같은 작업증명 관문은 왜 유효 기간이 있었는가. 이 토론에서 가장 날카로운 분석은 작업증명이 성립하는 조건 자체를 문제 삼는다. 스팸 방지에서 작업증명이 작동하는 이유는 보상의 비대칭 때문이다. 정상 사용자는 요청 한 번으로 보상 V 를 얻고, 남용자는 수백만 번의 요청으로도 같은 상수 보상 V 를 노린다. 그래서 비용이 남용자 쪽에 수백만 배로 몰린다. 스크레이퍼는 그렇지 않다. 스크레이퍼의 모든 요청은 각각 자기 몫의 보상을 생산한다. 비대칭이 아예 없고, 양쪽 모두에게 고정 비용 하나가 더해질 뿐이다. 게다가 데이터센터 규모의 스크레이핑 사업자는 개인 사용자보다 작업증명 연산을 감당할 준비가 훨씬 잘 되어 있다 (@tptacek). 이 예측은 1년 전에 이미 제기됐고, kernel.org 의 33퍼센트라는 숫자가 그것을 실증했다. 정직한 이용자가 지불한 것은 뜨거워진 전화기와 몇 초의 대기 시간이었고, 봇이 지불한 것은 사업 비용의 반올림 오차였다.
동적 난이도 제안도 나왔다. 하루 1000페이지 이상을 요청하는 IP 에는 난이도를 1씩 올리면 되지 않겠느냐는 것이다 (@nicman23). 방향은 맞지만 이 제안이 부딪히는 벽이 정확히 kernel.org 가 이미 관측한 적응이다. 난이도를 IP 로 키잉하는 순간, 요청 4~5건만 날리고 사라지는 수백만 개의 주거용 IP 앞에서 그 키는 무의미해진다. 공격자가 이미 IP 라는 식별자를 무한 공급받고 있기 때문이다. 문제는 난이도 조절 알고리즘이 아니라, 조절의 기준이 될 지속적 신원(identity)이라는 원시 자료가 없다는 데 있다.
그리고 이 지점에서 근본 긴장이 드러난다. 공개 인프라는 익명·무등록 접근을 전제로 설계됐다. 그런데 크롤러에 대한 모든 유효한 대응책은 그 전제를 조금씩 깎아 내는 방향으로만 존재한다. 신원을 요구하거나, 관문을 세우거나, 기능을 줄이거나. HN 의 한 이용자는 이 흐름을 질문의 형태로 요약했다. 이것은 익명 브라우징의 종말이자 모든 요청에 신원을 붙여야 하는 시대의 시작인가, 아니면 커뮤니티가 호스팅하는 무료 정보 서비스 자체의 종말인가 (@a-dub). 다른 이용자는 더 담담하게 정리했다. 트래픽의 99퍼센트가 가짜인 상태로 운영을 계속하는 것은 현실적이지 않으므로, 많은 시스템이 로그인이나 신뢰 IP 기반으로 옮겨 가는 것은 불가피해 보인다는 것이다 (@acedTrex).
운영자가 지금 쥘 수 있는 카드와 각각의 청구서
kernel.org 자신의 답부터 보는 것이 순서다. Ryabitsev 는 크롤 가능한 URL 의 수를 줄이고, 실행 비용이 큰 동작에 관문을 세우기 위해 기능을 꺼 나가고 있다고 밝힌다. 익명으로 접근할 때 일부 기능이 사라질 것을 예상하라고 하면서, 자기들도 그것을 싫어하지만 이제는 필요라고 덧붙인다. 동시에 그는 약속 하나를 유지한다. 요청하는 누구에게나 모든 데이터를 다운로드로 제공하겠다는 것이다. 다만 더 많은 절차를 거쳐야 할 수는 있다.
이 조합이 시사하는 원칙은 분명하다. 크롤러를 식별하려 하지 말고, 조합적으로 폭발하는 표면 자체를 줄여라. 자체 사이트나 사내 git 호스팅을 운영하는 입장에서 실제로 집을 수 있는 카드는 다음과 같고, 각각 청구서가 붙는다.
첫째, URL 표면 축소다. 임의의 두 커밋 사이 diff 처럼 조합적으로 무한한 엔드포인트를 익명 접근에서 제거하고, GET 링크로 구현한 정렬·검색 파라미터를 손본다. HN 에서 한 게임 사이트 운영자는 정확히 이 함정을 보고했다. 접속자 카운터가 100~200명에서 수천 명으로 늘어난 원인이 전부 크롤러 세션이었고, 실제 이용자는 소수였으며, 정렬과 검색을 GET 링크로 만든 것이 상황을 악화시켰다는 것이다 (@Demiurge). 부작용은 명확하다. 딥링크가 깨지고, 그 엔드포인트에 의존하던 정상 도구가 함께 죽는다.
둘째, 대량 전송 경로를 일급 시민으로 만드는 것이다. 클론 URL, tarball, 덤프를 눈에 띄게 공개하고 문서화한다. 비용은 대역폭이고, 효과는 예의 바른 크롤러에게 싼 길을 내주는 것이다. 다만 앞의 구조적 설명이 여기에도 적용된다. 이 경로는 특수 케이스 최적화를 넣을 유인이 있는 상대에게만 작동한다.
셋째, 캐싱이다. 배포하기 전에 요청 분포를 먼저 재라. 적중률을 측정하지 않고 리버스 프록시를 앞에 세우면, cgit 형 표면에서는 계층 하나를 더 운영하면서 적중률 0에 가까운 캐시를 유지하게 된다.
넷째, 작업증명 관문이다. 유효하다. 다만 유효 기간이 년 단위가 아니라 개월 단위라는 것을 알고 배포해야 한다. 그리고 그 기간 동안 세금을 내는 쪽은 모바일 이용자다. 한 이용자는 여러 사이트에서 높아진 Anubis 난이도가 심하게 거슬린다고 불평하면서, 그런데도 이제는 LLM 봇을 막지 못하는 것 아니냐고 되물었다 (@yellow_lead).
다섯째, CDN 의 봇 관리 기능이다. 문제를 중개자에게 넘기고 의존성을 새로 만든다. 시장의 세 위치를 모두 경험했다는 한 이용자의 보고는 신중하게 읽을 가치가 있다. 주거용 프록시를 쓰면 아주 단순한 요청으로도 차단은 15퍼센트 정도만 걸리며, 이는 프라이버시 브라우저로 정상 접속할 때 받는 차단보다도 낮다는 것이다. 그의 결론은 냉정하다. “클라우드플레어는 봇을 막지 않는다. 사람을 막는다” (@inigyou). 유료 크롤 모델을 미는 사업자가 그 거래에서 수수료를 가져간다는 지적도 함께 나왔다 (@timpera).
여섯째, 독 먹이기와 타르핏이다. 싸고 즉각적이지만, 오탐에 걸린 정상 이용자에게도 같은 쓰레기를 먹이게 되고, 혼자서는 이길 수 없는 확전에 스스로를 밀어 넣는다.
일곱째, 인증이다. 가장 효과적이고, 공개 인프라의 존재 이유에 가장 비싸다.
향후 시나리오는 세 갈래다. 낙관은 Ryabitsev 자신이 열어 둔 두 가지다. AI 거품이 꺼져 학습 데이터를 원하는 주체가 줄거나, 크롤러들이 철들어 가장 멍청한 방식으로 데이터를 소비하는 것을 그만두는 것이다. 그는 어느 쪽도 단언하지 않고 “불확실하다”고만 적는다. 비관은 그가 마지막 문단에서 언급한 공급 구조다. 맞춤형 AI 모델을 파는 회사는 매일 새로 생기고 전부 학습 데이터에 굶주려 있으며, 앱 제작자들은 계속 수익 모델을 찾다가 가정용 가전을 공격 벡터로 바꿔 놓을 것이다. 현실적 시나리오는 그 중간이다. 표면이 줄고, 관문이 퍼지고, 중개자를 통한 유료 크롤 계층이 자리를 잡는다. 한 이용자가 정리했듯 클라이언트가 자원을 쓰는 것만으로는 부족하고 서버가 요청을 처리한 대가로 무언가를 받아야 한다면, 결국 남는 길은 크롤 과금이다 (@Self-Perfection). 열린 인프라는 계속 작동하되, 문의 개수는 줄어든 채로 작동한다.
실무자에게 남는 가장 값싼 교훈은 순서에 관한 것이다. 완화 조치를 고르기 전에 먼저 재라. kernel.org 의 2퍼센트라는 숫자는 그들이 측정했기 때문에 존재한다. 대부분의 운영자는 자기 사이트의 그 비율을 모른 채로 방어책을 고르고 있다.
결론
리드 질문으로 돌아간다. 지금 비용을 부담하는 쪽은 인프라를 운영하는 사람이다. 그것은 절약이 아니라 이전(transfer)이다. 크롤러가 절약한 엔지니어링 시간만큼이 kernel.org 의 코어 14개로 나타났을 뿐, 사회 전체의 연산량은 오히려 늘었다. 같은 148만 개의 커밋을 922번 중복해서, 그것도 HTML 렌더링을 거쳐 가져가는 것보다 낭비적인 데이터 이동 방식을 설계하기는 어렵다.
크롤러가 가장 비싼 경로를 고르는 이유도 이제 분명하다. 멍청해서가 아니라, 그 경로의 비용이 자기 장부에 찍히지 않기 때문이다. 효율적 경로는 자기 엔지니어링 시간을 쓰고 비효율적 경로는 남의 CPU 를 쓴다면, 웹 전체를 긁는 규모에서 후자를 고르는 것이 개별적으로는 합리적이다. 개별 합리성의 총합이 공유 자원을 갉아먹는 익숙한 형태다.
그래서 실제로 소모되고 있는 것은 코어 14개가 아니다. 공적 자원을 관문 없이 내놓을 수 있다는 전제 자체다. kernel.org 는 여전히 요청하는 누구에게나 전체 데이터를 주겠다고 약속한다. 다만 그 앞에 절차가 하나씩 늘어난다. 절차가 하나씩 늘어나는 과정은 개별적으로는 전부 합리적인 결정이고, 그 합은 우리가 알던 형태의 공개 웹이 조금씩 닫히는 일이다.
남는 질문은 이것이다. 익명 접근을 지키면서 비용을 내부화할 방법이 존재하는가. 아니면 우리는 이미, 무엇을 포기할지만 고르는 국면에 들어와 있는가.
출처: