최근 저는 현대적인 안티 봇 (anti-bot) 시스템을 연구하는 데 많은 시간을 보내고 있습니다.

오늘날 대부분의 논의는 Cloudflare, DataDome, Akamai, Kasada, Human Security 또는 PerimeterX를 중심으로 이루어집니다. 하지만 안티 봇 생태계를 탐색하던 중, 저는 Anubis라는 흥미로운 오픈 소스 프로젝트를 우연히 발견했습니다.

그 설명이 즉시 제 관심을 끌었습니다:

"Anubis는 스크레이퍼 봇 (scraper bots)으로부터 업스트림 리소스를 보호하기 위해 하나 이상의 챌린지 (challenge)를 사용하여 연결의 영혼을 무게를 재는 Web AI 방화벽 유틸리티입니다."

이 프로젝트는 AI 크롤러 (crawlers)와 대규모 스크레이퍼 (scrapers)에 의해 생성되는 방대한 양의 자동화된 트래픽으로부터 소규모 커뮤니티가 스스로를 방어할 수 있도록 돕기 위해 만들어졌습니다.

자연스럽게, 저는 이것이 실제로 어떻게 작동하는지 확인하고 싶었습니다.

Anubis란 무엇인가?

Anubis는 웹사이트 앞에 위치하여 접속을 허용하기 전에 방문자에게 연산 챌린지 (computational challenges)를 제시하는 경량 안티 봇 (anti-bot) 레이어로 자리매김하고 있습니다.

아이디어는 간단합니다:

• 정당한 사용자는 챌린지를 통과합니다.
• 자동화된 트래픽은 필터링됩니다.
• 웹사이트 리소스는 남용으로부터 보호됩니다.

이 프로젝트는 소규모 스크레이퍼를 차단할 수 있고 Internet Archive 봇과 같은 유익한 크롤러 (crawlers)에게까지 영향을 미칠 수 있기 때문에 "핵 옵션 (nuclear option)"으로 간주될 수 있다고 공개적으로 밝히고 있습니다.

기업용 안티 봇 벤더들과 달리, Anubis는 단순함과 셀프 호스팅 (self-hosting)에 집중합니다.

테스트 대상

저는 Anubis를 실행 중인 여러 공개 액세스 웹사이트를 찾았습니다:

• https://source.puri.sm/public
• https://bugs.winehq.org/
• https://scioly.org/

목표는 무엇인가를 우회하는 것이 아니었습니다.

저는 단순히 다음을 이해하고 싶었습니다:

일반적인 스크레이핑 (scraping) 도구들이 Anubis로 보호되는 웹사이트와 상호작용할 때 어떤 일이 벌어지는가?

실험 #1 — 일반 Requests

대부분의 스크레이퍼 (scrapers)와 마찬가지로, 저는 가능한 가장 단순한 설정으로 시작했습니다.

브라우저 없음.

JavaScript 없음.

특별한 헤더 (headers) 없음.

그저 Python Requests뿐입니다.

import requests
from datetime import datetime

...

제 기대는 단순했습니다.

저는 다음과 같은 결과를 예상했습니다:

403 Forbidden

또는 아마도:

429 Too Many Requests

하지만 대신, 모든 요청이 다음과 같이 반환되었습니다:

200 OK

연속된 20번의 요청.

동일한 IP.

프록시 로테이션 (Proxy rotation) 없음.

브라우저 핑거프린팅 (Browser fingerprinting) 없음.

TLS 스푸핑 (TLS spoofing) 없음.

그저 Requests뿐이었습니다.

첫 번째 놀라움

이 시점에서 저는 의구심이 생겼습니다.

많은 안티 봇 (Anti-bot) 솔루션들은 방어 수준을 높이기 전까지는 몇 번의 요청을 허용합니다.

그래서 다음과 같은 의문이 들었습니다:

'어쩌면 Anubis가 요청 빈도를 추적하고 있는 것일까?'

'어쩌면 임계값(Threshold) 이후에 속도 제한 (Rate limits)이 작동하는 것일까?'

'어쩌면 동시 트래픽 (Concurrent traffic)이 결과를 바꾸는 것일까?'

그래서 다음 테스트로 넘어갔습니다.

실험 #2 — 100개의 동시 요청

저는 aiohttp를 사용하여 100개의 동시 요청을 생성했습니다.

import asyncio
import aiohttp
from datetime import datetime
...

다시 한번, 저는 무언가 발생할 것이라 예상했습니다.

잠재적인 결과들:

• 속도 제한 (Rate limiting)
• 챌린지 에스컬레이션 (Challenge escalation)
• 일시적 차단 (Temporary blocking)
• 연결 스로틀링 (Connection throttling)

결과는 어땠을까요?

모든 요청이 결국 성공적으로 완료되었습니다.

100 requests
100 x 200 OK
0 blocks

일부 요청은 다른 요청보다 오래 걸렸지만, 모두 성공했습니다.

실험 내내 동일한 IP

한 가지 중요한 세부 사항이 있습니다:

저는 IP 주소를 전혀 변경하지 않았습니다.

실험 전반에 걸쳐 저는 다음을 사용했습니다:

• Requests
• AsyncIO
• Selenium
• Playwright
• Playwright MCP

모두 동일한 IP에서 실행되었습니다.

이는 매우 중요한데, IP 평판 (IP reputation)은 안티 봇 시스템이 사용하는 가장 초기 신호 중 하나이기 때문입니다.

동일한 소스로부터 반복되는 요청은 다음과 같은 요소에 영향을 줄 수 있습니다:

• 평판 점수 산정 (Reputation scoring)
• 속도 분석 (Velocity analysis)
• 남용 탐지 (Abuse detection)
• 챌린지 에스컬레이션 (Challenge escalation)

그럼에도 불구하고 저는 계속해서 성공적인 응답을 받았습니다.

실험 #3 — Selenium

이 시점에서 저는 브라우저 자동화 (Browser automation)가 보호 조치를 트리거할 가능성이 더 높을 것이라고 가정했습니다.

저는 Selenium을 실행했습니다.

브라우저에는 다음과 같은 익숙한 메시지가 표시되었습니다:

Chrome is being controlled by automated test software

이는 많은 안티 봇 벤더들이 적극적으로 모니터링하는 부분입니다.

결과는 어땠을까요?

정상적인 페이지 접속.

명백한 차단은 없었습니다.

눈에 띄는 챌린지 실패는 없었습니다.

실험 #4 — Playwright

다음은 Playwright였습니다.

Playwright는 일반적으로 더 현실적인 브라우저 환경을 제공하며, 안티 봇 (anti-bot) 보호 기능이 더 엄격해질 때 자주 사용됩니다.

결과는 동일했습니다.

페이지 로드 성공.

눈에 띄는 차단 조치는 없었습니다.

실험 #5 — Playwright MCP

마지막으로 Playwright MCP를 사용하여 테스트했습니다.

결과는 다시 한번 다음과 같았습니다:

Success

Anubis 챌린지가 성공적으로 완료되었고 접속이 허용되었습니다.

이것이 의미하는 바는 무엇인가?

가장 중요한 시사점은 다음과 같습니다:

200 응답이 반드시 안티 봇 시스템의 실패를 의미하는 것은 아닙니다.

여러 가지 가능한 설명이 존재합니다.

가능성 1: 보수적인 설정 (Conservative Configuration)

웹사이트들이 상대적으로 느슨한 Anubis 설정을 실행 중일 수 있습니다.

많은 관리자들이 공격적인 차단보다는 접근성을 우선시합니다.

가능성 2: 챌린지 완료 (Challenge Completion)

요청들이 추가적인 정밀 조사(scrutiny)를 유발하지 않고 챌린지 프로세스를 성공적으로 완료했을 수 있습니다.

가능성 3: 차단 임계값 미도달 (Enforcement Thresholds Were Not Reached)

Anubis는 보호 수준을 높이기 전에 다음과 같은 요소를 요구할 수 있습니다:

• 더 큰 트래픽 규모
• 더 긴 관찰 기간
• 다른 행동 패턴

가능성 4: 설정의 공백 (Configuration Gaps)

모든 보안 제품과 마찬가지로, 배포 설정이 중요합니다.

보호 계층은 적용된 규칙만큼만 효과적일 수 있습니다.

가능성 5: 향후 개선을 위한 영역 (Areas for Future Improvement)

모든 안티 봇 솔루션은 시간이 지나면서 진화합니다.

특히 오픈 소스 프로젝트는 커뮤니티의 테스트와 피드백으로부터 큰 도움을 받습니다.

이와 같은 실험은 에지 케이스 (edge cases)와 잠재적인 개선 사항을 식별하는 데 도움이 될 수 있습니다.

다음에 테스트할 내용

추측하기보다는, 직접 Anubis로 보호되는 환경을 구축할 계획입니다.

이를 통해 다음과 같은 항목들을 통제된 환경에서 테스트할 수 있을 것입니다:

• 요청 기반 스크래핑 (Request-based scraping)
• 브라우저 자동화 (Browser automation)
• TLS 핑거프린트 (TLS fingerprints)
• 헤더 이상 징후 (Header anomalies)
• 동시성 제한 (Concurrency limits)
• IP 평판 (IP reputation)
• 행동 분석 (Behavioral analysis)

그제야 비로소 제가 관찰한 것이 무엇인지 판단할 수 있을 것입니다:

• 설정상의 선택 (A configuration choice)
• 배포 환경 특유의 동작 (A deployment-specific behavior)
• 의도적인 설계 결정 (An intentional design decision)
• 또는 추가적인 조사가 필요한 영역 (An area that deserves further investigation)

마치며 (Final Thoughts)

웹 스크래핑 (Web scraping) 분야에서 수년간 일하며 배운 한 가지가 있습니다:

안티 봇 (Anti-bot) 시스템을 절대 과소평가하지 마십시오.

오늘 요청 (Request)이 성공했다고 해서 방어 체계가 약하다는 뜻은 아닙니다.

마찬가지로, 요청이 차단되었다고 해서 반드시 방어 체계가 강력하다는 의미도 아닙니다.

흥미로운 지점은 요청이 왜 성공하거나 실패하는지를 이해하는 것입니다.

이번 실험은 해답보다는 더 많은 질문을 던졌습니다. 그리고 바로 그 점이 안티 봇 연구를 매력적으로 만드는 요소입니다.

다음 단계는 통제된 환경을 구축하고, Anubis가 연결을 어떻게 평가하고, 클라이언트에 어떻게 챌린지 (Challenge)를 부여하며, 누가 통과할지를 어떻게 결정하는지 더 깊이 파고드는 것입니다.

그리고 솔직히 말해서, 바로 그 지점부터 진짜 재미가 시작됩니다.

#WebScraping #DataExtraction #BotDetection #AntiScraping #SecurityFail #DevOps #WebSecurity #CyberSecurity #BotDefense #ScraperLife