Kernel.org의 크리피 크롤러, 오픈 액세스를 CPU 부담으로 바꾸다

Konstantin Ryabitsev에 따르면, 자동 스크래핑을 비싸게 만들기 위한 방어 장치에도 불구하고 크리피 크롤러가 현재 git.kernel.org 전반에서 CPU 코어 14~16개를 계속 점유하고 있다. 이 크롤러들은 기본 Git 저장소를 클론하는 대신 개별 커밋 페이지를 수백만 건 요청한다. 그 결과 효율적인 공개 아카이브가 정체를 알 수 없는 시스템을 위한 상시 HTML 렌더링 서비스로 바뀌고 있다.

kernel.org 인프라에 관여하는 Linux Foundation 시스템 관리자인 Ryabitsev는 2026년 8월 29일 이 수치를 공개했다. Simon Willison은 Datasette도 유사한 위험 특성을 지닌다는 이유로 9월 7일 이를 조명했다. Datasette는 방대하면서도 유용하고 크롤링 가능한 페이지를 통해 데이터베이스를 노출할 수 있다.

당장의 이야기는 Linux 인프라에 관한 것이지만, 이 갈등은 훨씬 더 넓은 영역으로 이어진다. 개방형 기술 아카이브는 사람들이 정보를 검토하고, 참조하고, 보존하도록 돕기 위해 설계됐다. 대규모 머신 클라이언트는 이러한 개방성을 대가가 책정되지 않은 컴퓨팅 의무로 바꿀 수 있다.

그 반전은 git.kernel.org에서 특히 두드러진다. 관리자는 이미 전체 저장소 이력을 효율적으로 전송하도록 설계된 Git 프로토콜로 제공하고 있다. 그럼에도 스크레이퍼들은 커밋, 패치, diff별로 따로 렌더링된 페이지를 요청하며 계산 비용이 큰 경로를 선택하는 것으로 전해진다.

이런 행태는 관리자가 합법적인 개발자들이 사용하는 인터페이스를 제한하도록 압박한다. Ryabitsev에 따르면 서비스는 여전히 응답성을 유지하고 있지만, 이미 기능을 비활성화하고 더 많은 작업을 접근 제어 뒤로 옮기고 있다. 따라서 크롤러 급증의 비용은 CPU 시간뿐 아니라 사라진 개방성으로도 측정된다.

크리피 크롤러, 하루 600만 건 요청 발생

사이트가 사람 방문자에게 정상적으로 보이더라도, 이 규모는 인프라를 지속적으로 소모할 만큼 크다.

Ryabitsev의 크롤러 측정 자료에 따르면, 무작위로 보이는 커밋을 향한 일일 요청은 약 600만 건에 이른다. 메인 사이트 앞에 배치된 브라우저 챌린지 Anubis는 이 요청의 약 66%를 즉시 거부한다. 나머지 33%는 챌린지를 통과해 git.kernel.org로 계속 진행한다.

이 수치가 모든 챌린지 요청이 AI 기업에서 왔다는 사실을 증명하는 것은 아니다. Ryabitsev는 운영자가 모든 클라이언트를 확실히 식별할 수는 없다고 명시했다. 사람이 오래된 커밋을 열어볼 수 있는 것처럼, 봇도 최신 브라우저를 흉내 낼 수 있다.

가장 강력한 근거는 요청 패턴이다. 비활성 상태인 오래된 포크의 무관한 커밋들을 옮겨 다니는 클라이언트는 패치 시리즈를 따라가는 개발자와 닮지 않았다. Ryabitsev는 사용자에게 유리한 가정을 적용한 뒤에도 합법적 활동이 전체 트래픽의 약 2%에 불과하다고 추정한다.

그 결과 발생하는 작업 부하는 지리적으로 분산된 5개 노드의 CPU 코어 90개 중 14~16개를 차지한다. 평균적으로 서비스 전체 처리 용량의 약 20%에 해당한다. 실제 수요는 파도처럼 몰려오기 때문에, 부하는 고정된 20% 할당보다 훨씬 불규칙하다.

이 코어들이 수행하는 작업은 제한적이다. 렌더링된 결과를 다시 파싱하는 클라이언트를 위해 Git 객체를 HTML 페이지로 변환한다. Ryabitsev는 Git 클론을 포함한 모든 합법적 접근 방식의 CPU 시간 합계보다 이 활동이 더 많은 CPU 시간을 소모한다고 말한다.

이 차이는 중요하다. 클론은 Git의 네이티브 객체 모델을 통해 저장소를 전송한다. 클라이언트는 이력을 받아 로컬에서 커밋을 탐색할 수 있다. 서버는 클라이언트가 살펴보려는 모든 객체마다 표시용 페이지를 다시 만들 필요가 없다.

HTML 요청은 이러한 효율성을 뒤집는다. 요청 하나하나는 서버에 저장소 데이터를 찾고, cgit을 실행하며, 사람이 읽을 수 있는 응답을 구성하라고 요구한다. 클라이언트는 필요한 텍스트를 추출한 뒤 주변 인터페이스 대부분을 버린다.

이 과정이 수백만 URL에 걸쳐 반복되면, 개별적으로는 합리적인 페이지 하나가 비용이 큰 머신 엔드포인트가 된다. 전통적인 용량 계획은 흔히 페이지뷰를 비슷한 작업량의 단위로 취급한다. git.kernel.org 사례는 URL 하나가 다른 URL보다 훨씬 많은 연산을 유발할 수 있을 때 이 모델이 왜 무너지는지를 보여준다.

서비스는 현재의 상시 부하로 아직 붕괴하지는 않았다. Ryabitsev는 특히 많은 노드가 동시에 얕은 클론을 수행할 때, 잘 설계되지 않은 지속적 통합 시스템이 더 심각한 장애를 일으킬 수 있다고 말한다. 크롤러 트래픽은 운영 여유를 영구적으로 줄인다는 점에서 다른 문제를 만든다.

이렇게 사라진 여유는 트래픽 급증, 유지보수 이벤트, 합법적인 자동화에 대한 내성을 낮춘다. 또한 운영자가 커널 개발자를 위한 서비스를 개선하는 대신 적대적인 행태를 분석하는 데 시간을 쓰게 만든다. 겉으로 안정적인 웹사이트도 상당한 숨은 비용을 떠안을 수 있다.

핵심 변화는 공개 소스 코드를 내려받을 수 있다는 사실 자체가 아니다. Kernel.org는 의도적으로 그러한 사용을 지원한다. 변화는 정체를 알 수 없는 클라이언트들이 비용이 큰 표현 방식을 선택하고 이를 산업적 규모로 요구한다는 데 있다.

Git은 데이터를 저렴하게 만들지만, HTML은 비싸게 만든다

핵심 갈등은 접근과 비밀주의의 대립이 아니다. 효율적인 대량 접근과 낭비적인 페이지별 추출의 대립이다.

Linux 개발은 언제나 복제의 혜택을 받아왔다. Git 저장소는 클론할 수 있고, 메일링 리스트 아카이브는 복사할 수 있으며, 미러는 단일 서버의 수명을 넘어 자료를 보존할 수 있다. Kernel.org는 모든 다운로드를 위협으로 취급하기보다 이런 중복성을 장려한다.

Git은 객체 간 관계에 따라 객체를 전송함으로써 이 모델을 경제적으로 만든다. 저장소는 커밋, 트리, 파일 내용을 주소 지정 가능한 객체로 저장한다. 클라이언트와 서버는 클라이언트에 없는 객체를 협상한 뒤, 각 커밋 주변에 웹페이지를 다시 만들지 않고 필요한 데이터를 전송한다.

웹 인터페이스는 다른 목적을 수행한다. 개발자가 하나의 변경 사항을 검토하고, 안정적인 링크를 공유하고, 리비전을 비교하거나, 대규모 저장소를 클론하지 않고 패치를 내려받도록 돕는다. git.kernel.org가 사용하는 인터페이스인 cgit은 각각이 합법적인 인간 워크플로를 지원하기 때문에 여러 보기를 제공한다.

이 선택지는 크롤링 가능한 표면도 늘린다. Ryabitsev의 설명에 따르면 주요 Linux 저장소에는 약 148만 개의 커밋이 있다. Git.kernel.org는 동일한 기본 객체를 상당 부분 공유하는 약 922개의 포크를 호스팅한다.

따라서 크롤러는 중복된 커밋 콘텐츠로 이어지는 많은 URL을 발견할 수 있다. 패치 보기, 일반 텍스트 렌더링, 저장소 트리, 임의 비교도 요청할 수 있다. 콘텐츠는 유한하지만 가능한 URL 공간은 훨씬 커진다.

이는 데이터베이스 기반 웹사이트에서 익숙하게 나타나는 실패 양상이다. 데이터베이스에는 관리 가능한 수의 레코드가 있어도, 인터페이스는 무수한 필터, 정렬, 페이지네이션, 비교 조합을 허용할 수 있다. 무차별적인 크롤러에게 생성된 모든 경로는 또 하나의 문서처럼 보인다.

Willison은 이 패턴을 웹에서 검색 가능한 데이터베이스를 공개하는 자신의 오픈 소스 도구 Datasette와 연결했다. Datasette 인스턴스는 구조화된 정보를 탐색 가능한 페이지와 쿼리 결과로 바꿀 수 있다. 이런 접근성은 사람, 검색 엔진, 연구자, 보조 도구에 가치가 있다.

하지만 비용이 큰 매개변수 조합도 노출할 수 있다. 봇이 유해한 부하를 만들기 위해 악성 코드가 필요한 것은 아니다. 애플리케이션이 저렴하게 처리할 수 있는 속도보다 빠르게 링크를 열거하거나 유효한 URL을 구성하기만 하면 된다.

같은 위험은 문서 시스템, 이슈 트래커, 코드 브라우저, 공공 기록 포털, 개인 아카이브에도 적용된다. 구조화된 데이터를 요청 시 변환하는 사이트는 정적 페이지보다 취약하다. 모든 가져오기가 데이터베이스 작업이나 서버 측 렌더링을 유발할 수 있기 때문이다.

여러 클라이언트가 같은 리소스를 요청하면 캐싱이 도움이 된다. 크롤러가 의도적으로 또는 우연히 고유 URL에 요청을 분산하면 효과가 떨어진다. 쿼리 매개변수, 임의 diff, 오래된 포크는 캐시의 가치를 만드는 재사용을 무력화할 수 있다.

운영자는 인기 페이지를 사전 렌더링할 수 있지만, 가능한 모든 비교를 사전 렌더링하는 것은 불가능하다. 대량 내보내기를 제공할 수도 있지만, 웹 링크 중심으로 설계된 크롤러는 효율적인 경로를 발견하거나 선택하지 못할 수 있다. 기술적으로 이용 가능하다고 해서 클라이언트가 합리적으로 행동하는 것은 아니다.

검색 가능한 아카이브를 구축하는 개발자에게 이는 아키텍처상의 경고다. 머신 접근에는 가능한 한 제한된 API, 피드, 내보내기 또는 저장소 프로토콜을 사용해야 한다. 인간용 인터페이스에는 각 응답을 생성하는 비용을 반영한 제한이 필요하다.

이러한 선택을 문서화하는 팀은 코드와 함께 운영 결정도 보존해야 한다. 검색 가능한 엔지니어링 지식 기반은 또 다른 트래픽 파도가 오기 전에 크롤러 정책, 비용이 큰 경로, 인시던트 증거를 연결할 수 있다.

kernel.org 인시던트는 대역폭이 비용의 일부일 뿐임을 보여준다. 자동화된 클라이언트가 동적 표현을 반복적으로 요청하면 CPU 시간, 캐시 교체 비용, 관측 가능성 비용, 운영자의 주의가 더 큰 비중을 차지할 수 있다.

Anubis는 크롤러가 대가를 치를 때까지 비용을 높였다

작업 증명은 악성 트래픽을 일시적으로 줄였지만, 기본 데이터의 가치가 유지되자 끈질긴 크롤러는 적응했다.

Kernel.org는 처음에는 익숙한 방어책을 사용했다. 운영자는 의심스러운 사용자 에이전트 문자열을 식별하고, 로그를 조사하며, 명백한 자동 수집과 관련된 주소를 차단했다. 이 접근법은 크롤러가 자신을 식별하거나 관리 가능한 네트워크 집합에서 발생하던 동안에는 효과가 있었다.

이후 트래픽은 분류하기 더 어려워졌다. Ryabitsev는 일반 브라우저를 자처하고 클라우드 서브넷 전반에 요청을 분산하는 클라이언트를 설명한다. 네트워크 전체를 차단하면 악용을 막을 수 있지만, 같은 제공업체에서 호스팅되는 합법적 자동 검사도 차단할 수 있다.

다음 변화는 주소 기반 통제를 더욱 약화시켰다. 요청은 다수의 주거용 및 모바일 주소에서 도착하기 시작했다. Ryabitsev에 따르면 각 주소는 로그에서 사라지기 전 네다섯 건의 요청만 발생시켰다.

이 패턴은 소비자 기기를 통해 트래픽을 라우팅하는 프록시 네트워크와 닮았다. 사이트는 집중된 스크래핑 작업 대신 서로 관계없는 광범위한 사용자 집단으로 보이는 대상을 마주한다. 주소가 의심스럽게 보일 무렵이면 그 특정 출처는 다시 돌아오지 않을 수 있다.

Kernel.org는 클라이언트가 업스트림 서비스에 도달하기 전에 챌린지를 제시하는 오픈 소스 웹 방화벽 Anubis로 대응했다. 핵심 메커니즘은 작업 증명으로, 클라이언트에는 상대적으로 비용이 크지만 서버는 저렴하게 검증할 수 있는 작은 수학적 작업이다.

Anubis 프로젝트는 이 소프트웨어를 지속적인 AI 크롤러 트래픽에 직면한 소규모 인터넷 서비스를 위한 방어책으로 설명한다. 관리자는 챌린지가 소규모 스크레이퍼와 합법적인 아카이브 봇까지 차단할 수 있으므로 이를 강도 높은 대응책이라고도 부른다.

git.kernel.org에서 이 챌린지는 처음에는 경제성을 바꿨다. 자동화된 클라이언트는 접근 시도를 중단했고, 사람 방문자는 약간의 지연을 감수했다. 이 기간은 수개월간 지속됐다.

이후 봇은 난이도 4를 풀기 시작했다. 운영자는 더 많은 클라이언트 연산을 요구하는 난이도 5로 챌린지를 높였다. Ryabitsev는 이 설정이 모바일 기기에서 몇 초가 걸릴 수 있고 휴대전화가 눈에 띄게 뜨거워질 수 있다고 말한다.

난이도를 높이자 다시 수개월의 시간을 벌 수 있었다. 동시에 챌린지를 받은 모든 합법적 방문자에게 더 큰 비용을 부과했다. 오래된 하드웨어, 개인정보 보호 중심 브라우저, 비활성화된 JavaScript, 불안정한 연결 환경에서는 예상된 흐름을 완료할 수 없어 접근성이 저하된다.

크롤러들은 결국 레벨 5도 해결했다. Ryabitsev가 보고서를 공개했을 당시, 하루 600만 건의 커밋 요청 가운데 약 3분의 1이 이 과제를 통과했다. 작업 증명은 여전히 나머지 3분의 2를 막아냈으므로 무용해진 것은 아니었지만, 이전의 균형을 되돌리지는 못했다.

이 결과는 경제적 억지의 핵심 약점을 드러낸다. 과제는 비용이 스크레이퍼의 기대 가치를 넘는 동안에만 효과가 있다. 가치 있고 정제된 기술 기록은 수집자에게 더 많은 자원을 투입할 이유를 제공한다.

Ryabitsev는 Linux 커밋 이력이 특히 매력적인 이유로, 그 상당 부분이 생성형 텍스트가 확산되기 이전에 만들어졌다는 점을 든다. 연구자들은 합성 자료를 반복 학습하면 모델 품질이 저하되거나 아티팩트가 증폭될 수 있다고 우려한다. 따라서 구조화가 잘 되어 있고 사람이 작성한 기술 기록은 바람직한 학습 자료가 된다.

해당 클라이언트의 정확한 신원과 목적은 아직 검증되지 않았다. 일부는 모델 학습을 지원할 수 있고, 다른 일부는 검색 색인, 코드 데이터세트, 보안 제품 또는 상업용 아카이브를 구축할 수 있다. 운영 측면에서는 그 이름표보다 이들이 공유하는 행동 양식이 더 중요하다.

Anubis 개발자 Xe Iaso 역시 작업 증명이 완전한 해답은 아니라는 점을 인정했다. 기술 토론에서 Iaso는 이 메커니즘이 대규모 스크래핑의 경제성을 겨냥한다고 설명했지만, 역량 있는 분산형 클라이언트에 대해서는 효과에 회의적인 견해를 밝혔다.

브라우저 자동화를 사용하는 클라이언트는 JavaScript를 실행하고, 쿠키를 저장하며, 사람과 동일한 공개 과제를 해결할 수 있다. 분산형 클라이언트는 많은 기기에 작업을 나눠 수행할 수 있다. 이때 난도를 높이면 충분한 자원을 보유한 수집자를 억제하기보다 합법적 방문자를 먼저 불이익 줄 위험이 있다.

Kernel.org의 사례는 실제 운영 데이터로 이런 상충관계를 확인해 준다. 방어는 성공했고, 적대적 클라이언트는 적응했으며, 운영자는 비용을 높였다. 공격자와 방어자 모두 조정할 수 있는 설정값이 하나 더 있었기에 경쟁은 끝나지 않았다.

공개 아카이브는 유용한 기능을 제거하도록 내몰리고 있다

가장 큰 피해는 서버 비용 증가가 아니다. 익명성과 사람 친화적 접근이 서서히 후퇴하는 데 있다.

Kernel.org는 크롤링 가능한 URL 수를 줄이고 실행 비용이 큰 작업에 접근 제한을 둘 계획이다. Ryabitsev는 익명 사용자가 일부 기능이 사라질 것으로 예상해야 한다고 경고한다. 원본 데이터는 계속 다운로드할 수 있지만, 이를 얻으려면 추가 절차가 필요할 수 있다.

인프라 운영자에게 이런 대응은 합리적이다. 하나의 인터페이스가 불균형적인 부하를 발생시킨다면 이를 제한해 서비스의 나머지 부분을 보호할 수 있다. Git 클론과 개발자 워크플로는 임의의 비교를 익명으로 무제한 렌더링하는 것보다 더 중요하다.

하지만 모든 제한은 누가 아카이브를 사용할 수 있는지를 바꾼다. Git이 설치된 개발자는 저장소를 클론해 로컬에서 살펴볼 수 있다. 그러나 링크를 따라온 학생, 하나의 커밋을 확인하는 기자, 또는 제약된 기기를 쓰는 사람은 브라우저 인터페이스에 의존할 수 있다.

자동화된 연구 도구도 정당한 목적을 가질 수 있다. 검색 색인은 사용자가 오래된 수정 사항을 찾도록 돕는다. 아카이브 시스템은 증거를 보존한다. 보안 서비스는 커밋과 취약점을 연관 짓는다. 접근성 도구는 일반적인 브라우징과 다른 방식으로 페이지를 가져올 수 있다.

광범위한 제한으로는 이러한 클라이언트와 악의적 수집자를 깔끔하게 구분할 수 없다. 인증은 책임성을 만들지만 관리 업무를 추가한다. 요청이 분산된 주소에서 들어오면 속도 제한도 효과를 잃을 수 있다.

주거용 네트워크를 차단하면 실제 가정 사용자가 배제된다. 클라우드 제공업체를 차단하면 개발자 자동화에 지장을 준다. 작업 증명을 요구하면 서버가 요청의 유용성을 알기도 전에 모든 방문자가 전기와 시간을 써야 한다.

Robots.txt는 정책 신호를 제공하지만 접근 제어 메커니즘은 아니다. 공식 robots 표준은 그 규칙이 권한 부여를 의미하지 않는다고 명시한다. 협조적인 크롤러는 선언된 선호를 따르지만, 신원이 확인되지 않은 클라이언트는 이를 무시하거나 브라우저를 사칭할 수 있다.

그 결과 비대칭이 발생한다. 책임 있는 조직은 크롤러를 식별하고, 문서를 공개하며, 제외 규칙을 지키므로 차단하기 쉬워진다. 반면 책임감이 낮은 수집자는 신원을 숨기고 트래픽을 분산해 막기 더 어렵다.

이 때문에 규정을 준수하는 크롤러가 접근 권한을 잃는 반면 회피적인 크롤러는 계속 접근하는 역설적 결과가 나올 수 있다. 또한 트래픽 귀속의 신뢰성도 떨어진다. 운영자는 특정 요청을 이름이 알려진 모델 개발사와 연결하지 못하더라도, 행동 특성을 기준으로 한 집단을 AI 스크래핑으로 합리적으로 설명할 수 있다.

이 불확실성은 이 이야기에서 가장 중요한 회의적 쟁점이다. Ryabitsev의 트래픽 측정은 직접적인 운영 증거이지만, 모든 요청의 목적이 독립적으로 확립된 것은 아니다. 98% 추정치는 검증된 AI 기업 목록이 아니라, 겉으로 드러난 스크래핑 행동에 관한 것이다.

이 구분은 정책과 보도 모두에 반영되어야 한다. 네트워크 증거 없이 모든 부하를 특정 공급업체에 돌리는 것은 부정확하다. 그렇다고 모든 클라이언트가 공개 신원을 갖지 않는다는 이유로 문제를 축소해서도 안 된다.

측정 가능한 피해는 애플리케이션 계층에 존재한다. 수백만 건의 요청이 오래된 커밋, 중복된 포크, 비용이 큰 렌더링을 선택한다. 방어 과제는 많은 요청을 차단하지만, 상당한 물량은 계산 비용을 지불하고 계속 진행한다.

Cloudflare는 사이트 소유자에게 검색, 에이전트, 학습 크롤러를 더 세밀하게 제어할 수 있는 권한을 제공하는 방식으로 더 광범위한 문제에 접근했다. AI 트래픽 제어 기능은 모델 학습 크롤러와 사용자가 요청한 어시스턴트가 같은 목적을 수행하지 않는다는 중요한 구분을 반영한다.

대규모 엣지 네트워크는 주소 정보, 브라우저 신호, 트래픽 이력, 고객 전반의 관측치를 결합할 수 있다. 작은 오픈 소스 서비스에는 이런 가시성이 거의 없다. 이들은 로컬 로그와 불완전한 식별자만으로 결정을 내려야 한다.

이 격차는 피해를 감당할 능력이 가장 부족한 조직에 집중시킨다. 대형 상업 플랫폼은 더 많은 용량을 구매하고 특화된 봇 관리 기능을 배포할 수 있다. 자원봉사 프로젝트, 학술 아카이브 또는 독립 출판사는 비용이 큰 경로를 단순히 닫을 수 있다.

그렇게 되면 오픈 웹은 몇 가지 인터페이스 기능 이상을 잃는다. 유용하고 링크 가능한 정보를 공개하는 일이 경제적으로 안전하다는 전제를 잃는다. 페이지는 기술적으로는 공개 상태로 남지만, 접근은 조건부가 되거나 과제를 통과해야 하며, 대량 데이터 워크플로를 통해서만 가능해진다.

진짜 충돌은 개방성과 가격이 매겨지지 않은 컴퓨팅 사이에 있다

오픈 데이터가 가능한 모든 표현 방식을 무료, 익명, 무제한으로 유지해야 한다는 뜻은 아니다.

크롤링을 둘러싼 윤리적 논의는 대개 콘텐츠 복제 권한에 초점을 맞춘다. Kernel.org는 두 번째 질문을 던진다. 수집자가 원하는 형식으로 콘텐츠를 변환하는 비용은 누가 부담해야 하는가?

Linux 저장소는 이미 효율적인 전송 메커니즘을 통해 이용할 수 있다. 운영자들은 이력을 숨기거나 이에 대한 독점적 통제를 요구하는 것이 아니다. 이들은 공개 서비스가 더 비용이 큰 표현을 반복 계산하도록 만드는 클라이언트에 이의를 제기하고 있다.

이 차이는 이 사례를 지식 제한에 관한 단순한 논쟁과 구분한다. 효율적인 클론 방식은 전송 이후 처리 비용의 상당 부분을 수집자가 부담하게 한다. 커밋 단위 HTML 스크래핑은 반복 작업을 원본 제공자에게 떠넘긴다.

책임 있는 수집자는 먼저 대량 내보내기, 저장소 접근, 피드, 사이트맵 또는 문서화된 API를 찾아야 한다. 가져온 자료를 캐시하고, 포크를 중복 제거하며, 임의의 매개변수 조합을 피해야 한다. 또한 자신의 신원을 밝히고 작동하는 연락 채널을 제공해야 한다.

요청량 협상도 중요하다. 비정상적으로 많은 물량이 필요한 크롤러는 운영자에게 미러나 예약된 내보내기를 요청할 수 있다. Kernel.org는 익명 인터페이스가 더 제한적이 되더라도, 요청하는 사람에게는 계속 데이터를 제공할 계획이라고 밝혔다.

이러한 관행은 성숙한 검색 엔진이 수십 년에 걸쳐 발전시켜 왔기에 기본적인 내용처럼 들린다. AI 수요는 웹 규모 데이터세트를 수집하는 조직의 수를 늘렸다. 모든 팀이 같은 운영 규범을 물려받은 것은 아닌 것으로 보인다.

인센티브도 다르다. 희소한 AI 이전 자료를 확보하려 서두르는 수집자는 빠르게 움직일수록 이득을 본다. 비효율적 수집의 비용은 서로 관련 없는 수천 개 사이트 운영자에게 돌아간다. 계약, 집행 또는 신뢰할 수 있는 신원이 없다면 크롤러는 그 외부 비용을 자동으로 부담하지 않는다.

작업 증명은 비용 일부를 요청자에게 되돌리려는 시도다. git.kernel.org의 결과는 이 모델의 매력과 한계를 모두 보여준다. 한계 비용은 높이지만, 가치 있는 인간 요청과 가치 있는 자동화 요청을 구별하지는 못한다.

크롤링당 과금은 또 다른 경로가 될 수 있지만, 결제만으로 시스템 설계 문제가 해결되지는 않는다. 가격, 할당량, 용량 제어가 제대로 맞물리지 않으면 크롤러는 동적 엔드포인트에 여전히 과부하를 줄 수 있다. 작은 사이트에는 기계 접근을 협상하는 데 필요한 결제 시스템도 부족하다.

더 나은 프로토콜 탐색 기능도 도움이 될 것이다. 기계가 읽을 수 있는 페이지는 수집자에게 저장소 클론, 압축 아카이브 또는 범위가 제한된 데이터 내보내기를 안내할 수 있다. 그래도 크롤러가 그 방향을 따르도록 하려면 인센티브나 요구 사항이 필요하다.

애플리케이션 설계는 트래픽이 도착하기 전에 노출을 줄일 수 있다. 개발자는 결과 크기를 제한하고, 비합리적인 비교를 거부하며, 동등한 URL을 정규화하고, 비용이 큰 경로에 별도 제한을 적용할 수 있다. 일반적인 뷰는 사전 계산하고, 이례적인 쿼리에는 인증을 요구할 수 있다.

관측 가능성은 요청 수만이 아니라 작업량을 측정해야 한다. 캐시된 정적 응답 100만 건은 캐시되지 않은 데이터베이스 쿼리 수천 건보다 비용이 적을 수 있다. 운영자에게는 경로별 CPU 시간, 캐시 효과성, 과제 완료율, 주소 전반에서 묶은 클라이언트 행동 정보가 필요하다.

더 깊은 정책 문제는 집행 가능한 신원에 관한 것이다. 운영자와 목적을 밝히는 크롤러는 맞춤형 접근 권한을 받을 수 있다. 수백만 개의 브라우저인 척하는 분산형 클라이언트는 협상을 막고 모든 요청을 신뢰 판단으로 바꾼다.

신원 확인이 개선되기 전까지 방어 시스템은 행동 추론에 의존할 수밖에 없다. 이는 오탐이 계속 불가피하다는 뜻이다. 실제 사용자를 배제하는 보호 조치는 자신이 보존하려는 서비스를 훼손할 수 있으므로, 차단된 트래픽만큼이나 사람에게 드는 비용도 추적해야 한다.

따라서 Creepy crawlies는 트래픽 문제인 동시에 거버넌스 실패를 보여준다. 웹에는 자발적인 크롤러 행동을 위한 규범이 있지만, 그 규범을 무시하는 기계 규모 클라이언트를 위한 신뢰할 만한 체계는 부족하다.

압력이 완화되는지 보여줄 세 가지 신호

다음 단계는 트래픽 행동, 사라지는 기능, 더 나은 크롤러 책임성으로 측정될 것이다.

첫 번째 신호는 git.kernel.org의 과제 통과율이다. Ryabitsev가 수치를 공개했을 때 무작위 커밋 요청의 약 33%가 Anubis를 통과하고 있었다. 지속적인 하락은 새로운 제어가 경제적 압박을 회복했거나 클라이언트 분류를 개선했음을 시사할 것이다.

통과율이 안정적이거나 상승한다면 반대 방향을 가리킨다. 이는 수집자들이 각 방어 강화에 따른 비용을 감수할 만큼 데이터를 계속 가치 있게 여기고 있음을 보여준다. 과제 난도가 다시 높아진다면 경쟁의 초점이 여전히 신원이 아닌 비용에 있음을 드러낼 것이다.

두 번째 신호는 kernel.org가 제거하는 익명 기능의 규모다. 비정상적으로 비용이 큰 비교에만 제한을 두는 것은 표적화된 대응을 뒷받침할 것이다. 일반적인 커밋, 패치 또는 탐색 뷰 전반으로 손실이 확대된다면, 크롤러 압력이 공개 사용자 경험을 바꾸고 있음을 보여줄 것이다.

운영자는 무엇이 사라졌는지와 그 이유를 문서화해야 합니다. 그 기록은 다른 프로젝트가 같은 지점에 이르기 전에 위험한 URL 패턴을 식별하는 데 도움이 될 것입니다. 또한 방어책이 본래 보호하려 했던 일반적인 인간의 작업 흐름을 유지하는지도 드러낼 것입니다.

세 번째 신호는 주요 크롤러 운영자가 검증 가능한 신원과 효율적인 수집 경로를 채택하는지 여부입니다. 공개된 주소 범위, 목적별 사용자 에이전트, 연락처 정보, 집행 가능한 속도 제한 정책이 있다면 사이트는 협조적인 자동화와 은밀한 스크래핑을 구분할 수 있습니다.

그러한 책임성이 없다면 방어 시장은 계속해서 브라우저 핑거프린팅, 관리형 엣지 제어, 인증, 유료 접근 방식으로 이동할 것입니다. 이러한 도구는 용량을 보호할 수 있지만, 독립적인 퍼블리싱도 더 복잡하게 만듭니다.

개발자가 당장 할 일은 어떤 공개 경로가 가장 많은 CPU를 소모하는지, 그리고 서로 다른 URL 중 얼마나 많은 수가 동일한 기저 레코드를 노출하는지 점검하는 것입니다. 대량 클라이언트가 더 저렴한 인터페이스를 통해 같은 정보를 가져올 수 있는지 테스트하세요.

그 경로를 명확히 공개하고, 동적 HTML 생성에는 엄격한 예산을 설정하세요. 작업 증명 완료율과 정상 사용자 실패를 별도로 모니터링하세요. 방어책은 모든 독자를 부수적 피해자로 만들지 않으면서 악성 연산을 줄여야 합니다.

AI 구축자에게 책임 있는 선택은 더 간단합니다. 비용이 가장 낮은 승인된 표현 방식을 사용하고, 크롤러의 신원을 밝히며, 사이트 정책을 준수하고, 확장하기 전에 운영자에게 연락하세요. 공개 접근은 공동 지식을 활용하라는 초대이지, 타인의 프로세서를 무제한으로 사용할 수 있다는 권리가 아닙니다.

git.kernel.org의 기이한 크롤러들은 그 경계를 분명히 드러냈습니다. 오픈 웹은 기계 독자를 수용할 수 있지만, 그러려면 기계가 모든 공개 URL을 무료 컴퓨팅 용량으로 취급하는 일을 멈춰야 합니다.