Anubis는 실제로 누구를 막는가?

2 days ago 4

HTTP 접근 전에 작업 증명(Proof-of-Work) 을 요구하는 Anubis는 AI 스크레이퍼보다 일반 사용자와 저사양 기기, JavaScript 미지원 클라이언트에 더 큰 지속적 비용을 부과함
LLM이 만든 anubis-fetch는 작업 증명을 직접 풀고 필요하면 Chromium을 실행하며, Chrome의 TLS/JA3 지문을 모방해 Cloudflare의 수동 차단까지 통과함
스크레이퍼는 발급받은 쿠키를 캐시·재사용해 비용을 여러 요청에 걸쳐 상각할 수 있지만, 사람은 방문할 때마다 수초의 대기와 배터리 소모를 감수해야 함
기본 난이도 4는 평균 65,536회 해시를 요구하며, 네이티브 Go 구현은 약 1.3ms, 브라우저 JavaScript는 약 130ms가 걸리지만 실제 체감 대기 시간은 약 1~5초임
회당 체감 시간 2초와 에너지 20J를 가정하면 하루 100만 회의 도전은 연간 약 23인년·2MWh, 하루 1억 회는 약 2,300인년·200MWh를 소모함

AI가 우회한 Anubis

Linux 커널에서 binfmt_misc의 bpf를 통해 인터프리터 PT_INTERP에 $ORIGIN을 지원하는 패치를 작업하면서, LLM에 Linux 커널 메일링 리스트 스레드를 읽도록 요청함
lore.kernel.org는 리소스 접근 전에 작업 증명을 요구하는 HTTP 프록시 Anubis를 도입한 상태였음
LLM은 이 제한을 처리하는 anubis-fetch를 제작함
- 우선 작업 증명을 네이티브로 풀고, 실패하면 Chromium으로 URL을 방문함
- req로 실제 Chrome의 TLS/JA3 지문을 모방해 Cloudflare의 수동 차단도 통과함
- anubis-fetch <URL>은 HTML을 표준 출력으로 내보내고, --text 옵션은 읽기 쉬운 일반 텍스트를 출력함
Anubis가 겨냥한 AI와 봇은 작업 증명 지원을 한 번 추가하면 쉽게 우회할 수 있음
- 스크레이퍼는 도전을 해결한 뒤 받은 쿠키를 캐시·재사용해 비용을 여러 요청에 걸쳐 상각함
- 반면 사람은 방문할 때마다 스피너를 기다리고 배터리를 소비하며, 이 비용을 다른 사용자와 나눌 수 없음
- 저사양 기기와 스마트폰일수록 부담이 커지고, JavaScript를 사용하지 않는 w3m·lynx·스크린 리더·RSS 리더는 접근할 수 없음
AI를 막으려는 장치가 AI에는 쉽게 우회되는 반면, 사람과 개방형 웹에는 계속 비용을 부과하는 역진적 부담으로 작동함

난이도 d는 해시가 가져야 하는 선행 0의 16진수 문자 개수이며, 풀이당 기대 작업량은 W = 16^d회 해시임
- 흔한 기본값인 난이도 4는 65,536회 해시를 요구함
  - 약 50 MH/s인 네이티브 Go 구현: 약 1.3ms
  - 약 0.5 MH/s인 브라우저 JavaScript: 약 130ms
  - 페이지 로드와 워커 실행, 재로딩을 포함한 체감 시간: 약 1~5초
- 난이도 5는 1,048,576회 해시를 요구함
  - 네이티브 Go 구현: 약 20ms
  - 브라우저 JavaScript: 약 2초
  - 체감 시간: 약 5~15초
전 세계의 일일 Anubis 도전 풀이 횟수를 C, 회당 체감 시간을 t = 2초, 화면과 CPU를 포함한 기기 에너지를 E = 20J로 가정함
- 연간 사람 시간은 C × t × 365 / 3.15×10⁷로 계산함
- 연간 에너지는 C × E × 365 / 3.6×10⁶kWh로 계산함
이 가정에 따른 연간 비용은 다음과 같음
- 하루 100만 회: 약 23인년, 약 2MWh
- 하루 1,000만 회: 약 230인년, 약 20MWh
- 하루 1억 회: 약 2,300인년, 약 200MWh
모든 수치는 대략적인 추정치이며, 봇 팜과 AI 도구가 몇 자릿수 더 많은 에너지를 사용하므로 환경 문제를 주장하기 위한 계산은 아님
로봇에게 시간은 제약이 아니지만 사람의 시간은 유한하므로, 이용자들은 AI 시대 이전에는 없었던 웹사이트 접근 대기에 집단적으로 상당한 시간을 쓰게 됨