파일 하나 배포하는 데 1년, Anubis의 WebAssembly가 보여준 진짜 난제

AI 크롤러를 막는 Anubis가 WebAssembly 파일 하나를 배포하기까지 1년이 걸렸습니다. 최근 한 달간 새로 나온 커뮤니티 논의 중 확인할 만한 내용은 거의 없었습니다. 그래도 이 사례가 던진 질문은 여전히 유효합니다. 웹에서는 “빠르게 작동한다”와 “누구에게나 안전하게 작동한다”가 전혀 다른 이야기이기 때문입니다.

Anubis는 문지기가 아니라 통행료 징수원입니다

Anubis는 웹사이트 앞에서 봇을 막는 도구입니다. 방문자에게 짧은 계산 문제를 내고, 답을 맞힌 브라우저만 원래 페이지로 들여보냅니다.

이 방식을 작업증명이라고 합니다. 비트코인의 채굴이나 이메일 스팸 방지 기술인 Hashcash와 비슷한 발상입니다.

사람이 페이지 한 장을 열면서 계산을 한 번 하는 데 드는 비용은 크지 않습니다. 하지만 AI 크롤러는 수만 장을 긁어 가므로 같은 비용이 금세 쌓입니다.

예를 들어 페이지마다 계산하는 데 1초가 걸린다고 해보겠습니다. 일반 방문자는 한 번만 기다리면 됩니다. 반면 10만 페이지를 수집하는 크롤러에는 약 27.8시간의 연산이 누적됩니다.

물론 이해를 돕기 위해 단순하게 계산한 숫자입니다. 실제 비용은 기기 성능과 난이도 설정에 따라 달라집니다. 요점은 봇을 완벽하게 가려내는 데 있지 않습니다. 대량 수집의 채산성을 떨어뜨리는 데 있습니다.

WebAssembly로 바꾸면 그냥 빨라지는 것 아닐까요

WebAssembly는 브라우저에서 실행할 수 있는 저수준 바이트코드입니다. 보통 WASM이라고 줄여 부릅니다. 자바스크립트보다 계산 성능을 가늠하기 쉽고, 여러 언어로 작성한 코드를 웹에서도 실행할 수 있습니다.

반복 계산이 많은 작업증명에는 잘 맞습니다. 사용자는 같은 문제를 더 빨리 풀 수 있고, 서버도 기기마다 다른 성능을 조금 더 안정적으로 다룰 수 있습니다.

하지만 WASM 파일을 서버에 올리는 것만으로는 끝나지 않습니다.

브라우저는 WASM을 화면에 바로 연결하지 못합니다. 자바스크립트가 파일을 불러와 계산을 시작하고, 나온 결과를 다시 서버에 보내야 합니다. 화면이 멈추지 않도록 Web Worker 같은 별도 실행 공간도 마련해야 합니다.

서버 설정도 제대로 맞춰야 합니다. WebAssembly.instantiateStreaming()으로 효율적으로 실행하려면 올바른 MIME 타입이 필요합니다. 보안 정책인 CSP 때문에 WASM 실행이 막힐 수도 있습니다. 스트리밍 실행에 실패할 경우를 위한 우회 경로도 준비해야 합니다.

결국 파일은 하나여도 실제 배포 경로는 여러 갈래입니다.

더 빠른 작업증명이 항상 더 좋은 것은 아닙니다

여기서 역설이 생깁니다. WASM으로 계산 속도를 높이면 일반 방문자는 덜 기다립니다. 하지만 크롤러도 똑같이 빨라질 수 있습니다.

Anubis의 목표는 최고 속도가 아닙니다. 사람에게는 가볍고 대량 수집자에게는 비싼 지점을 찾는 것입니다.

고성능 데스크톱을 기준으로 난이도를 높이면 오래된 스마트폰이 피해를 봅니다. 모바일 브라우저에서는 배터리 소모와 발열도 생길 수 있습니다. 저사양 기기에서는 잠깐 계산하는 동안 페이지가 고장 난 것처럼 보일 수도 있습니다.

반대로 가장 느린 기기를 기준으로 삼으면 대규모 크롤러가 비용을 거의 느끼지 못합니다. 데이터센터용 CPU나 병렬 처리 장비를 가진 상대라면 더욱 그렇습니다.

그래서 WASM 전환을 단순한 성능 개선으로만 볼 수는 없습니다. 기기별 난이도와 제한 시간, 재시도 횟수, 실패했을 때의 처리 방식까지 함께 설계해야 합니다. 계산 엔진보다 정책 엔진을 만드는 일이 더 어려운 이유입니다.

진짜 위험은 ‘차단’보다 ‘무한 대기’입니다

봇 방어 시스템은 일반 기능보다 실패가 눈에 잘 띄지 않습니다. 운영자에게는 정상적으로 열리는데 특정 브라우저나 지역의 사용자만 통과하지 못할 수 있습니다.

CDN에는 예전 자바스크립트가 남아 있고 서버에는 새 검증 코드가 배포됐다고 해보겠습니다. 브라우저가 문제를 제대로 풀어도 서버는 다른 형식의 답을 기다릴 수 있습니다. 사용자는 영문도 모른 채 인증 화면만 계속 보게 됩니다.

오래된 Safari, 개인정보 보호 기능이 강한 브라우저, 스크립트 차단 확장 프로그램도 변수로 작용합니다. 회사나 학교의 보안 장비가 WASM 파일을 막는 상황도 생각해야 합니다.

이럴 때 필요한 건 더 영리한 알고리즘이 아닙니다. 버전 호환성을 확인하고 캐시를 무효화하며 단계적으로 배포해야 합니다. 실패를 감지하는 장치와 자바스크립트 대체 경로, 즉시 되돌릴 수 있는 롤백 절차도 갖춰야 합니다.

Anubis가 1년을 쓴 까닭도 여기서 짐작할 수 있습니다. WASM 자체를 만드는 것보다, WASM이 실패해도 웹사이트가 문을 닫지 않도록 하는 일이 훨씬 어렵습니다.

AI 시대의 방어는 정확도보다 비용을 따집니다

Anubis도 모든 AI 크롤러를 가려낼 수는 없습니다. 작업증명을 대신 풀어 주는 서비스가 생길 수 있고, 자원이 충분한 수집자는 비용을 감수할 수도 있습니다.

그래도 이 방식은 달라진 흐름을 잘 보여줍니다. 이제 웹 운영자는 “사람인가, 봇인가”만 묻지 않습니다. 그보다 “이 요청을 10만 번 반복해도 이득인가”를 따지기 시작했습니다.

WebAssembly 파일 하나에 1년이 걸렸다고 해서 개발이 느렸던 것은 아닙니다. 공개 웹의 문턱을 높이면서 정상 이용자를 밀어내지 않으려면 그만큼 세심하게 운영해야 한다는 뜻입니다. 여러분이 운영하는 웹사이트에는 AI 크롤러에게 어느 정도의 통행료를 매기는 게 적당할까요?