크롤링 방지 방법

네이버가 쓰는 층을 실제로 관찰된 것부터 순서대로 보면:

1. IP 평판 (가장 싸고 효과 큼)
AWS·Azure·GCP는 자기 IP 대역을 공개합니다. 그 목록을 방화벽/CDN에 넣고 끊으면 끝입니다. "집에서 오는 트래픽만 사람"이라는 가정이 실제로 잘 맞아서, 우리가 본 ERR_CONNECTION_RESET처럼 TCP 단계에서 바로 거절합니다 — HTTP까지 오지도 않으니 서버 비용이 거의 안 듭니다. 상용으로는 IP 평판 DB(데이터센터/VPN/프록시 분류)를 구독해서 씁니다.

2. TLS 지문 (JA3/JA4)
이게 우리가 curl로 막혔던 층입니다. TLS 연결을 열 때 클라이언트가 "내가 지원하는 암호 목록, 확장, 그 순서"를 보내는데, 이 조합이 프로그램마다 다릅니다. Chrome은 Chrome만의 순서가 있고 curl·Python·Node는 각자 다르죠. 그 바이트들을 해시한 게 JA3/JA4 지문이고, 알려진 Chrome/Safari 지문 목록에 없으면 봇으로 판정합니다. User-Agent 헤더를 Chrome이라고 위조해도 안 통하는 이유가 이겁니다 — UA는 앱이 적어 보내는 글자지만 지문은 TLS 라이브러리가 만드는 것이라, 진짜 Chrome을 쓰지 않으면 못 흉내냅니다.

3. 브라우저 실행 환경 검사
페이지 안에서 자바스크립트로 navigator.webdriver, 플러그인 목록, 화면 크기, WebGL 렌더러 문자열 같은 걸 확인합니다. 자동화 브라우저에서 기본값으로 티가 나는 항목들이죠. 우리 수집 코드에 --disable-blink-features=AutomationControlled 플래그가 있는 건 이 검사 하나를 지나가기 위한 것입니다.

4. 상태 토큰 요구
정상 방문자는 첫 방문 때 발급받은 쿠키를 들고 다닙니다. 그게 없으면 거절하죠. 우리 코드가 lcs.naver.com에서 NNB 쿠키를 먼저 받아오는 게 이 층 때문입니다(없으면 에러 1006). 발급 경로를 거치지 않고 API만 때리는 스크립트를 걸러냅니다.

5. 행동 기반 레이트리밋
IP·계정·쿠키 단위로 "몇 초에 몇 번, 어떤 순서로" 요청하는지 봅니다. 사람은 페이지를 읽는 시간이 있고 순서가 들쭉날쭉한데, 스크립트는 규칙적이고 빠릅니다. 요청 간격의 분산이 비정상적으로 작으면 잡습니다.

직접 만든다면 층별 비용 대비 효과 순서가 그대로 구현 순서입니다: ①Cloudflare 같은 CDN 앞단에서 데이터센터/VPN 대역 차단 → ②JA4 지문 검사(Cloudflare Bot Management나 오픈소스 ja4 모듈) → ③민감한 엔드포인트에 발급 토큰 필수화 → ④엔드포인트별 레이트리밋 → ⑤그래도 새는 트래픽에 JS 챌린지. 실무에서는 이걸 직접 짜는 대신 Cloudflare Bot Management, AWS WAF Bot Control 같은 걸 켜는 게 대부분이고요.

한 가지 트레이드오프는 알아두시면 좋습니다: 이 방어는 오탐이 필연적입니다. 회사 VPN을 쓰는 실제 고객, 사내망에서 접속하는 직원이 데이터센터 IP로 보여 막히고, 정당한 API 파트너도 걸립니다. 그래서 보통 "차단" 대신 "챌린지 후 통과" 같은 완충 단계를 두고, 알려진 파트너는 API 키로 우회로를 열어줍니다. 우리 상황을 이 렌즈로 보면 — 네이버가 공식 API를 열어두지 않은 데이터를 브라우저 경로로 가져오고 있는 것이고, 그래서 하루 1회로 요청량을 최소화해 일반 방문자 수준을 넘지 않게 유지하는 게 중요합니다.