Anubis, AI를 막으려다 오히려 인간을 막는가?

논의의 핵심은 Anubis가 의도한 AI 기반 웹 스크래퍼 차단 목표 달성 여부입니다. 많은 사용자는 Anubis의 증명(Proof-of-Work) 메커니즘이 AI에게는 사소한 장애물일 뿐이며, 오히려 모바일 사용자나 JavaScript 비활성 사용자에게는 '회귀적 세금(Regressive Tax)'처럼 작용한다고 지적합니다. 특히 AI는 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 쿠키를 재사용하거나, 네이티브 코드(Native Code)로 PoW를 해결하여 비용을 상쇄하지만, 인간 사용자는 매번 시간과 배터리를 소모해야 한다는 점이 강조됩니다.

Anubis의 HTTP 프록시 기능은 AI 도구에 의해 쉽게 우회됩니다. anubis-fetch와 같은 도구는 Chromium을 직접 실행하거나 네이티브 Go 구현을 통해 Anubis의 PoW 챌린지를 해결합니다. 이는 AI 스크래퍼에게 일회성 또는 매우 낮은 비용으로 적용되지만, 인간 사용자에게는 매번 발생하는 비용이 됩니다. 이러한 비용 비대칭성(Cost Asymmetry)은 Anubis의 효과에 대한 의문을 제기합니다.

Anubis는 텍스트 기반 브라우저(w3m, Lynx), 스크린 리더, RSS 리더 등 JavaScript를 사용하지 않는 클라이언트들을 완전히 배제합니다. 이는 웹 접근성(Web Accessibility)의 근본적인 원칙에 위배된다는 비판입니다. 또한, 일부 사용자는 Anubis가 단순한 봇 차단을 넘어 상태 저장(Stateful) 메커니즘으로 작동하며, 코드버그(Codeberg)와 같은 대규모 플랫폼에서는 이미 우회 솔루션이 등장하여 효과가 미미하다고 주장합니다.

일부 의견은 Anubis를 CAPTCHA와 유사한 개념으로 보며, 소규모 웹사이트에서는 여전히 악성 트래픽을 줄이는 데 효과적이라고 주장합니다. Anubis를 도입한 웹사이트 운영자는 AI 스크래핑으로 인한 서버 과부하가 현저히 줄었다고 증언합니다. 하지만 이는 대규모 타겟 스크래핑에는 효과가 제한적이며, 결정적으로 Anubis를 우회하기 위한 특정 스크래퍼가 등장하면 그 효과는 사라질 수 있다는 반론도 존재합니다.

논의에서는 사용자 에이전트(User Agent) 필드의 신뢰성에 대한 의문도 제기됩니다. AI 도구나 프록시 사용 시 Chrome과 같은 일반적인 에이전트로 위장하는 것이 일반적입니다. 또한, 스마트 TV와 같은 저사양 기기가 PoW 계산 자체보다는 프록시 역할로 사용될 수 있다는 추측도 나왔습니다. 이는 Anubis가 실제 사용자 경험에 미치는 영향을 복합적으로 고려해야 함을 시사합니다.