IP로 AI 크롤러와 에이전트를 검증하는 방법: 역방향 DNS, CIDR 대역, Web Bot Auth

로그에서 GPTBot, ClaudeBot, PerplexityBot을 보고 허용할지, 요청 빈도를 제한할지, 차단할지 결정해야 합니다. 하지만 그 전에 더 기본적인 질문에 답해야 합니다. 정말 그 봇이 맞는가? User-Agent 헤더는 증거가 아니라 주장이기 때문입니다. 누구나 curl -A "GPTBot/1.3" https://your-site.com을 실행할 수 있고, 로그에는 성실하게 "GPTBot"이라고 기록됩니다.

이론적인 이야기가 아닙니다. HUMAN Security의 Satori 팀은 널리 알려진 AI 크롤러라고 주장하는 전체 트래픽의 5.7%가 스푸핑이었고, 어떤 날은 7.7%(하루 약 200만 건)까지 올랐으며, ChatGPT-User 에이전트는 요청 약 여섯 건 중 한 건꼴로 사칭되었다고 밝혔습니다. 이 가이드는 IP 및 암호 계층에서 크롤러를 검증하는 세 가지 실제 방법(정방향 확인 역방향 DNS, 운영자가 공개한 CIDR 허용 목록, Web Bot Auth)과, 다른 거의 모든 가이드가 놓치는 실패 사례를 다룹니다.

User-Agent가 "GPTBot"이라는 것이 아무것도 증명하지 못하는 이유

User-Agent는 스스로 보고하는 메타데이터입니다. 인증도, 서명도, 원본 서버가 확인할 수 있는 것도 없습니다. 크롤러를 검증한다는 것은 요청을 운영자가 실제로 통제하는 인프라나 키와 연결하는 것입니다. 이를 수행하는 체계는 정확히 세 가지입니다.

1. 정방향 확인 역방향 DNS(FCrDNS): IP가 운영자의 도메인으로 확인되고 다시 그 도메인에서 확인됨을 증명합니다.
2. 공개 CIDR 허용 목록: IP를 운영자가 공개하는 대역과 대조합니다.
3. Web Bot Auth(RFC 9421): 요청 자체에 붙은 암호화 서명을 검증합니다.

이하의 내용은 이 방법들을 올바르게 수행하는 방법과, 각각이 무엇을 증명할 수 있고 없는지에 관한 것입니다.

2026년의 판돈: 봇이 웹의 다수입니다

자동화된 트래픽이 인터넷의 대부분이 된 순간부터 크롤러 검증은 SEO의 틈새 주제가 아니게 되었습니다. Imperva의 2026 Bad Bot Report에 따르면 자동화된 트래픽은 2025년에 관측된 웹 트래픽의 53%를 차지했고, 악성 봇만으로도 40%였습니다. 대부분의 요청이 자동화된 것이고 AI 크롤러의 규모가 계속 커지면 "이 봇이 진짜인가?"는 robots.txt뿐 아니라 로그인, 가입, 결제 엔드포인트의 문제가 됩니다. 결제에서는 이제 사기 문제이기도 합니다. 실제 에이전트 매출을 막지 않고 AI 쇼핑 에이전트 사기를 막는 방법을 참고하세요. 크롤러 대역부터 스캐너 플래그까지 어떤 IP 신호가 어떤 봇 질문에 답하는지는 IP 기반 봇 탐지 허브에서 볼 수 있습니다.

방법 1: 정방향 확인 역방향 DNS를 제대로 하기

FCrDNS는 Google이 Googlebot 검증을 위해 문서화한 표준적인 방법입니다. 네 단계입니다.

정방향 단계가 핵심인 이유: 공격자는 자기 IP의 역방향(PTR) 레코드를 통제하므로 1.2.3.4가 crawl-fake.googlebot.com을 가리키게 할 수 있습니다. 하지만 그 호스트 이름이 다시 1.2.3.4로 확인되도록 googlebot.com의 권한 있는 정방향 DNS를 위조할 수는 없습니다. PTR 레코드에 "googlebot.com"이 있는지 문자열만 맞춰 보는 검사(놀랄 만큼 많은 튜토리얼이 권하는 방식)는 그 자체로 스푸핑에 취약합니다. 정방향 확인이 이 방법의 전부입니다. 크롤러 유형이 세 가지이고 대역 파일이 따로 있는 Google에 대해서는 IP로 Googlebot 검증하기와 가짜 Googlebot 찾아내기 가이드를 참고하세요.

짚어 둘 정확도의 한계가 있습니다. PTR 레코드는 선택 사항이며 특히 새로운 AI 업체에서는 없는 경우가 많습니다. PTR이 없으면 FCrDNS는 "검증 불가"를 반환하며 통과도 실패도 아닙니다. 이때 방법 2가 필요합니다.

방법 2: 봇별 공개 CIDR 허용 목록

대부분의 AI 업체는 PTR 레코드를 건너뛰고 크롤러 IP 대역을 JSON으로 공개합니다. 운영상 가장 실용적인 검사입니다. 각 운영자의 1차 소스 피드를 가져오세요.

• OpenAI: 봇별 파일: openai.com/gptbot.json, openai.com/searchbot.json, openai.com/chatgpt-user.json (OpenAI 크롤러 문서).
• Google: developers.google.com/static/crawling/ipranges/ 아래의 CIDR 파일 다섯 개.
• Anthropic: 자사 봇용 파일 하나인 claude.com/crawling/bots.json을 공개하며 크롤러 도움말 페이지에서 링크됩니다. 플랫폼 문서의 주소 목록은 API용이며 크롤러용이 아닙니다.
• Perplexity: perplexitybot.json과 perplexity-user.json.
• Apple iCloud Private Relay: mask-api.icloud.com/egress-ip-ranges.csv의 출구 CSV (Apple 문서). 참고로 이들은 프라이버시 릴레이를 쓰는 사람이지 봇이 아닙니다. 허용 목록에 넣고 차단하지 마세요.

우리는 운영자 10곳의 크롤러 대역 파일 19개를 불러옵니다. 검증된 크롤러 IP 목록에 각 파일과 파일 날짜, 허용 목록을 만드는 방법이 있습니다.

올바른 구현과 잘못된 구현을 가르는 세 가지 규칙이 있습니다.

• 각 봇을 운영자의 파일에 대응시키되, 운영자가 봇별로 파일을 공개하는 경우에만 그 봇의 파일에 대응시키세요. GPTBot은 "OpenAI의 어떤 대역"이 아니라 gptbot.json에 있으며, 엉뚱한 OpenAI 파일과 대조하면 학습용 크롤러와 사용자 요청 기반 페처가 뒤섞입니다. Anthropic은 봇 세 개를 위해 공유 파일 하나를 공개하고 DuckDuckGo의 두 파일은 동일하므로, 그런 경우에는 운영자가 가능한 가장 정밀한 대조 단위입니다. GPTBot vs OAI-SearchBot vs ChatGPT-User 비교에서는 OpenAI 봇 각각이 하는 일, 차단했을 때의 비용, 파일별 실제 조회 결과를 보여 줍니다.
• 호스팅 ASN이 아니라 공개된 정확한 프리픽스와 대조하세요. 봇이 우연히 거기서 실행된다는 이유로 "AWS 전체"나 "Google Cloud 전체"를 허용하면 같은 클라우드의 모든 공격자가 통과합니다.
• 일정에 따라 갱신하세요. 이 대역은 바뀌므로 상수가 아니라 피드로 취급하세요.

업체별 비대칭: 어떤 방법이 존재하는가

대부분의 가이드는 업체들을 뭉뚱그립니다. 업체마다 어떤 검증 방법이 존재하는지와 각자 내놓는 크롤러 토큰이 다르며, 이는 서로 다른 정책적 함의를 가집니다.

단순한 파이프라인을 망가뜨리는 미묘한 점이 있습니다. 사용자 요청 기반 페처는 실제 방문자처럼 동작하며 공개된 봇 대역 밖에서 정당하게 올 수 있습니다. 사용자가 어시스턴트에게 특정 URL을 열도록 요청하면, 그 가져오기는 일반 브라우저 User-Agent를 단 일반 클라우드 인프라에서 나올 수 있습니다. 따라서 "GPTBot 대역에 없음"을 차단하면 실제 사용자의 에이전트 동작을 차단할 수 있습니다. 요청 빈도 제한과 차단 정책은 업체별이 아니라 토큰별로 달라야 합니다.

SEO 및 분석 크롤러 검증하기: AhrefsBot과 그 동료들

같은 두 가지 IP 계층 방법으로 로그에서 가장 자주 확인하고 싶어 하는 SEO 및 분석 크롤러도 검증할 수 있습니다. AhrefsBot, 그리고 SemrushBot과 DataForSeoBot 같은 동류입니다. 이들은 AI 크롤러는 아니지만 검증은 동일합니다.

• AhrefsBot은 정방향 확인 역방향 DNS로 검증할 수 있고(주소가 Ahrefs 자체 도메인 아래의 호스트 이름으로 확인됨), Ahrefs는 허용 목록용 크롤러 IP 대역을 공개합니다. 방법 1의 FCrDNS 검사를 그대로 실행하거나 방법 2의 공개 목록과 대조하세요.
• 함정은 AI 크롤러에서도 똑같이 걸리는 것입니다. ASN으로 허용하지 마세요. 검증한 적 없는 임의의 호스팅 대역에서 도착한 "AhrefsBot"은 바로 스푸핑 패턴입니다. 누구나 User-Agent: AhrefsBot/7.0을 보낼 수 있기 때문입니다. 문자열이 아니라 IP를 확인하세요.

방화벽 규칙을 만들려고 "AhrefsBot IP 주소"를 검색하고 있다면, 지속 가능한 방식은 정방향 확인 역방향 DNS 검사와 운영자가 공개한 대역을 일정에 따라 갱신하는 것이지, 크롤러가 용량을 늘리는 순간 낡아 버리는 하드코딩된 IP 목록이 아닙니다.

방법 3: Web Bot Auth와 암호학적 검증

스푸핑의 구조적 해법은 네트워크상의 위치를 신뢰하는 것을 멈추고 대신 서명을 검증하는 것입니다. Web Bot Auth는 에이전트가 RFC 9421 HTTP 메시지 서명(2024년 2월의 제안 표준)을 사용해 Ed25519 키로 요청마다 서명하게 합니다. 요청에는 다음이 담깁니다.

• Signature: 서명 값
• Signature-Input: 서명 대상 구성 요소, created/expires, keyid, tag="web-bot-auth"
• Signature-Agent: 선택 사항이며 서명하는 에이전트의 이름

키는 /.well-known/http-message-signatures-directory의 JWKS로 탐색됩니다(RFC 8615 잘 알려진 URI 메커니즘 기반). 검증 방법은 디렉터리를 가져와 keyid 썸프린트를 대조하고 서명과 created/expires 기간을 검증하는 것입니다. IP 방식에 비해 결정적인 장점이 있습니다. 신원이 경로가 아니라 요청에 실려 있으므로 공유, 순환, CGNAT 주소에서도 유지됩니다.

현실 점검: 표준이 아니라 실험 단계입니다

아키텍처에서는 솔직해지세요. Web Bot Auth는 IETF 인터넷 드래프트(draft-meunier-web-bot-auth-architecture, 2026년 3월 2일, 저자는 Cloudflare와 Google)에 명세되어 있으며, 이 드래프트에는 "not endorsed by the IETF and has no formal standing"(IETF의 승인을 받지 않았고 공식 지위가 없음)이라는 문구가 붙어 있고 2026년 9월 3일에 만료됩니다. Google 자체의 지원도 명시적으로 실험적입니다. "not yet signing every request"(아직 모든 요청에 서명하지는 않음)라고 하며 운영자에게 IP, 역방향 DNS, User-Agent 검증을 계속 사용하라고 안내합니다. 인프라 계층에서는 더 진전되어 있습니다. Cloudflare는 Verified Bots Program에 메시지 서명을 통합했고(2025년 7월) AWS WAF도 지원을 추가했습니다(2025년 11월). 결론: 서명이 있으면 우선하되 아직은 거기에 의존하지 마세요.

계층형 의사 결정 파이프라인 (그대로 복사하세요)

세 가지 방법을 우선순위로 묶은 다음 보강하고 분류하세요. 봇이 검증되면 해당 가이드의 3단계 정책으로 검증된 AI 크롤러 각각을 어떻게 처리할지 결정하세요.

5단계가 GeoIPHub가 들어가는 자리입니다. 스스로를 밝힌 봇의 IP가 공개된 대역에 없고 PTR도 없을 때, ASN 소유자, 데이터센터/호스팅 플래그, VPN, 프록시, Tor 플래그와 위험 점수가 있으면 추측하는 대신 로그인, 가입, 결제에서 판단 보류 사례를 점수화할 수 있습니다. 선언했지만 미검증인 그룹에 요청 빈도 제한을 건다면 IPv6 출발지는 주소가 아니라 프리픽스를 기준으로 하세요. 이유는 /64 프리픽스로 IPv6 요청 제한 및 차단하기 가이드에서 설명합니다.

같은 Google ASN인데 하나는 검증된 Googlebot이고 하나는 아닙니다

같은 Google 네트워크의 두 주소가 정반대의 크롤러 판정을 받습니다. 검사가 ASN이 아니라 공개된 프리픽스를 사용하기 때문입니다. 2026-10-05에 Google IP 두 개를 조회했습니다(대역이 바뀌면 결과도 달라집니다). Google이 공개한 Googlebot 대역 파일의 첫 IPv4 프리픽스의 첫 주소인 192.178.4.0과 Google Public DNS인 8.8.8.8입니다.

두 주소 모두 AS15169에 있고 둘 다 호스팅이므로 ASN 허용 목록은 둘을 똑같이 취급할 것입니다. Googlebot 파일 안에 있는 것은 첫 번째뿐이며, threat.crawler.verification_method: "ip_range_list"는 판정이 방법 2에서 나왔음을 보여 줍니다. verified_crawler 신호가 fraud_score를 0으로 끌어내리는 반면 8.8.8.8은 일반 데이터센터 점수인 15를 유지합니다. 우리 기록에 두 주소의 PTR이 없어서 no_ptr_datacenter 방식은 둘 다에서 작동하지만, 실시간 dig -x 192.178.4.0은 crawl-192-178-4-0.googlebot.com을 반환합니다. 대역 검사를 자동화해야 하는 이유를 보여 주는 작지만 실제적인 사례입니다. 이 검사는 PTR 조회의 성공 여부에 의존하지 않습니다.

실패 사례와 오탐

순위 기사들이 틀리는 부분입니다.

• 대역 밖 ≠ 가짜. Perplexity 사례(Cloudflare, 2025년 8월)는 크롤러가 일반 Chrome UA를 쓰고, 공개된 대역 밖의 IP를 쓰고, 하루 300만~600만 건의 요청에서 ASN을 바꿔 가며 사용하는 것을 보여 주었습니다. 대역 안은 참양성이고, 대역 밖은 가짜라는 증거가 아니라 판단 보류입니다.
• CGNAT의 지역적 편향. 2025년 말 Cloudflare 연구(The Register 경유)에서는 봇 신호가 더 낮은데도 CGNAT IP가 약 3배 더 자주 요청 제한을 받았습니다. 수백 명의 사용자가 하나의 IPv4를 공유하며 아프리카와 아시아에 집중되어 있습니다. 단순한 IP 차단은 공정성의 문제입니다.
• iCloud Private Relay. 실제 사람을 태우는 공유 순환 출구 IP이므로 Apple의 CSV로 허용 목록에 넣으세요.
• 주거용 프록시. ASN 허용 목록을 완전히 무력화합니다(Imperva의 2025년 보고서에서는 봇 공격의 21%가 이를 사용). 그래서 실제 고객을 차단하지 않고 익명화된 트래픽을 탐지하는 일은 목록 조회가 아니라 행동의 문제입니다.

규칙은 이렇습니다. 하드 차단은 행동과 출처의 결합에 두고, 목록에 없다는 사실만으로는 하지 마세요.

검증된 봇은 GIVT, 스푸핑된 봇은 SIVT입니다

Media Rating Council의 분류에서 선언된 크롤러와 알려진 데이터센터 IP는 목록으로 걸러낼 수 있는 일반 무효 트래픽(General Invalid Traffic)이고, "masquerading as legitimate users"(정상 사용자로 가장한) 봇은 분석과 검토가 필요한 정교한 무효 트래픽(Sophisticated Invalid Traffic)입니다. IP로 크롤러를 검증하면 요청이 두 번째 범주에서 첫 번째 범주로 옮겨 갑니다. 전체 범주 목록, Google 자체의 아홉 가지 범주와 그중 IP 조회로 볼 수 있는 것은 GIVT vs SIVT: Google의 무효 트래픽 범주에 있습니다.

GeoIPHub로 AI 크롤러와 에이전트 검증하기

GeoIPHub는 기존 지리 IP 업체들이 사용 가이드에서 빠뜨리는 5단계 보강 정보를 제공합니다. ASN 및 연결 유형, 호스팅/데이터센터 탐지, VPN / 프록시 / Tor 플래그, 공식 대역 피드 19개(GPTBot, ClaudeBot, PerplexityBot, AhrefsBot 포함)에 기반한 검증된 크롤러 플래그, 그리고 IP 사기 위험 점수입니다. 주거용 프록시는 탐지하지 않으며, 그런 것은 행동 신호가 필요합니다. 이를 통해 스스로를 밝힌 봇이 실제로 업체의 인프라에서 오는지 확인하고, 판단 보류 사례를 뭉뚱그려 차단하는 대신 점수화할 수 있습니다. 위의 검증 방법과 함께, 관련 가이드인 계정 탈취 및 크리덴셜 스터핑 탐지와 IP 지리적 위치는 실제로 얼마나 정확한가도 참고하세요.

FAQ

요청이 스푸핑이 아니라 실제 GPTBot에서 왔는지 어떻게 검증하나요?

User-Agent 헤더는 쉽게 위조되므로 믿지 마세요. 출발지 IP를 OpenAI가 봇별로 공개한 대역 파일(openai.com/gptbot.json)과 대조하되, 일반적인 OpenAI 대역이 아니라 GPTBot에 한정해서 검사를 고정하세요. 유효한 Web Bot Auth 서명이 있으면 IP와 무관하므로 OpenAI의 키 디렉터리로 먼저 검증하세요. 공개된 대역에 없는 IP는 가짜로 입증된 것이 아니라 판단 보류로 취급하세요. 사용자 요청 기반 에이전트 트래픽은 다른 인프라에서 나올 수 있기 때문입니다. GPTBot vs OAI-SearchBot vs ChatGPT-User 비교에서 OpenAI 대역 파일별 실제 조회 결과를 볼 수 있습니다.

정방향 확인 역방향 DNS(FCrDNS)란 무엇인가요?

FCrDNS는 네 단계 검사입니다. 출발지 IP를 역방향 DNS로 호스트 이름으로 바꾸고, 호스트 이름이 운영자의 도메인으로 끝나는지 확인하고, 그 호스트 이름을 정방향 DNS로 조회한 뒤, 원래 IP로 되돌아오는지 확인합니다. 스푸핑을 막는 것은 정방향 단계입니다. 공격자는 자기 IP에 가짜 PTR 레코드를 설정할 수 있지만 운영자의 권한 있는 정방향 DNS는 위조할 수 없습니다. PTR 문자열만 검사하는 방식은 스푸핑에 취약합니다.

AI 크롤러를 User-Agent 문자열로 차단하면 안 되는 이유는 무엇인가요?

User-Agent는 누구나 보낼 수 있는 주장이기 때문입니다. HUMAN Security는 널리 알려진 AI 크롤러로 표시된 전체 트래픽의 5.7%가 가짜였고, ChatGPT-User 에이전트는 요청 여섯 건 중 한 건 가까이까지 치솟았다고 밝혔습니다. 헤더만으로 차단하면 스푸핑된 봇은 통과시키면서, 아예 신원을 밝히지 않는 운영자는 막지 못합니다.

Web Bot Auth란 무엇이며 완성된 표준인가요?

Web Bot Auth는 봇이 RFC 9421 HTTP 메시지 서명을 사용해 Ed25519 키로 모든 HTTP 요청에 암호화 서명을 붙이고, 원본 서버가 /.well-known/http-message-signatures-directory에 공개된 키로 검증하는 새로운 방식입니다. RFC 9421 자체는 제안 표준(2024년 2월)이지만 Web Bot Auth는 2026년 중반 현재 공식 지위가 없는 IETF 인터넷 드래프트입니다. 실험적인 것으로 취급하세요. 서명이 있으면 검증하되, IP와 역방향 DNS 검증을 기본으로 유지하세요.

AI 업체는 크롤러 IP 대역을 어디에 공개하나요?

OpenAI는 openai.com/gptbot.json, searchbot.json, chatgpt-user.json에 봇별 JSON을 공개합니다. Google은 developers.google.com/static/crawling/ipranges/ 아래에 CIDR JSON을 공개합니다. Anthropic은 claude.com/crawling/bots.json에 자사 봇용 파일 하나를 공개합니다. Perplexity는 perplexitybot.json과 perplexity-user.json을 공개합니다. 각 검사를 해당 봇의 파일에 고정하고, 호스팅 ASN이 아니라 공개된 정확한 프리픽스와 대조하며, 파일을 일정에 따라 갱신하세요. OpenAI 파일 세 개와 현재 프리픽스 수는 GPTBot, OAI-SearchBot, ChatGPT-User IP 대역을 참고하세요.

IP가 업체가 공개한 대역에 없으면 요청이 가짜라는 뜻인가요?

아니요. 대역 안의 IP, 통과한 FCrDNS, 유효한 서명은 신뢰도 높은 참양성이지만, 대역 밖의 IP는 판단 보류입니다. 다른 인프라에서 온 정당한 사용자 요청 기반 에이전트 트래픽, CGNAT로 공유되는 주소, iCloud Private Relay 출구, PTR 레코드를 공개하지 않는 업체, 또는 자체적으로 가지고 있는 오래된 대역 파일일 수 있습니다. 하드 차단은 목록에 없다는 사실만이 아니라 행동 및 출처 신호에 두세요.

크롤러 IP 대역을 차단하면 공유 주소를 쓰는 실제 사용자에게 영향을 주지 않나요?

줍니다. 그래서 IP가 목록에 없다는 이유로 하드 차단을 해서는 안 됩니다. 2025년 말 Cloudflare 연구에서는 봇 지표가 더 낮았는데도 CGNAT 주소가 CGNAT가 아닌 주소보다 약 세 배 더 자주 요청 제한을 받았습니다. 수백에서 수천 명의 사용자가 하나의 IPv4 주소를 공유하고, CGNAT가 아프리카와 아시아 일부에 집중되어 지역적 편향이 생기기 때문입니다. iCloud Private Relay 출구 IP도 실제 사람을 태우므로 Apple이 공개한 CSV로 허용 목록에 넣어야 합니다.