서버 로그에 GPTBot으로부터의 요청이 표시됩니다. 이를 신뢰해야 할까요?

솔직한 답변은 다음과 같습니다: 단순히 그 문자열(string)만으로는 신뢰할 수 없습니다. User-agent 헤더는 클라이언트가 자신에 대해 주장하는 내용일 뿐이며, 어떤 클라이언트든 무엇이든 주장할 수 있습니다. curl -A "GPTBot"을 입력하는 데는 약 4초밖에 걸리지 않습니다. 만약 귀하의 robots.txt 정책, 분석(analytics), 또는 페이월(paywall) 로직이 user-agent 문자열을 기준으로 분기된다면, 그것은 검증되지 않은 입력값(unverified input)을 기준으로 분기되는 것입니다.

좋은 소식은 대부분의 주요 AI 크롤러들이 확인 방법을 공개하고 있다는 점입니다. 덜 좋은 소식은 의미 있는 소수의 크롤러는 아무것도 공개하지 않으며, 한 카테고리 전체는 설계상 검증이 불가능하다는 점입니다. 이 포스트에서는 각 검증 방법이 어떻게 작동하는지, 어떤 크롤러가 어떤 방법을 지원하는지, 그리고 정직한 답변이 여전히 "알 수 없다"인 경우는 어디인지 다룹니다.

User-agent 문자열은 정체성이 아니라 주장입니다

다음 세 가지를 구분할 가치가 있습니다:

• 식별 (Identification) — 크롤러가 자신이 누구인지 알려줍니다 (user-agent 문자열).
• 검증 (Verification) — 운영자가 제어하는 무언가와 대조하여 해당 주장을 독립적으로 확인합니다.
• 권한 부여 (Authorization) — 검증된 정체성이 무엇을 할 수 있는지 결정합니다.

robots.txt는 레이어 3(layer three)에서 작동하지만 레이어 2(layer two)에 대한 접근 권한은 없습니다. 이것은 권고 프로토콜(advisory protocol)입니다: RFC 9309는 구문과 준수에 대한 기대를 표준화할 뿐, 이를 강제하는 메커니즘을 제공하지는 않습니다. 귀하의 Disallow를 무시하는 크롤러는 기술적 제어(technical control)를 위반하는 것이 아니라, 요청을 거부하는 것입니다. 그리고 모범적인 크롤러를 *사칭(impersonates)*하는 크롤러는 귀하가 원래의 크롤러에게 부여했던 모든 권한을 그대로 이어받게 됩니다.

이러한 점은 2020년보다 2026년에 더 중요합니다. 왜냐하면 이제 권한이 실질적이기 때문입니다. 사이트들은 AI 크롤러가 모델 답변에 반영되도록 허용하거나, 크롤링당한 만큼 비용을 지불하는 방식(pay-per-crawl)으로 측정하거나, 봇 챌린지(bot challenges)에서 면제해 주기도 합니다. 이 모든 것들이 누군가가 가면을 쓸(사칭할) 이유가 됩니다.

세 가지 검증 방법, 강력한 순서대로

정방향 확인을 동반한 역방향 DNS (Reverse DNS with forward confirmation)

가장 고전적인 방법이며, 이를 지원하는 운영자들에게는 여전히 가장 강력한 방법입니다. 요청의 IP를 가져와 호스트네임(PTR 레코드)으로 확인(resolve)하고, 해당 호스트네임이 운영자가 제어하는 도메인으로 끝나는지 확인한 다음, 그 호스트네임을 다시 IP로 확인(resolve)하여 원래의 IP와 일치하는지 검증합니다.

정방향 확인(forward-confirm) 단계는 선택 사항이 아닙니다. PTR 레코드는 IP 블록의 역방향 존(reverse zone)을 제어하는 누구나 설정할 수 있으므로, 다시 정방향으로 확인하지 않으면 공격자가 제어하는 레코드를 신뢰하게 됩니다.

역방향 DNS 접미사(reverse-DNS suffix)를 문서화하는 운영자로는 Google(.googlebot.com / .google.com), Microsoft(.search.msn.com), Amazon(.crawl.amazonbot.amazon), Apple(.applebot.apple.com), 그리고 Common Crawl(.crawl.commoncrawl.org) 등이 있습니다.

공개된 IP 범위 (Published IP ranges)

운영자가 자신의 크롤러가 사용하는 CIDR 블록의 JSON 파일을 공개하면, 사용자가 해당 포함 여부를 확인하는 방식입니다. OpenAI는 openai.com/gptbot.json에서 이 방식을 사용하며, 이는 실제 환경에서 가장 흔히 쓰이는 방법입니다 — 저희 레지스트리에 등록된 41개의 크롤러 중 20개가 IP 범위 검증을 문서화하고 있으며, 이는 단일 항목 중 가장 널리 지원되는 확인 방법입니다.

두 가지 운영상의 주의사항이 있습니다. 목록은 변경되므로 하드코딩하기보다는 정기적으로 가져와서 캐싱해야 합니다. 또한, 범위의 신뢰도는 운영자 자체의 인프라 위생(hygiene) 상태에 달려 있습니다. 즉, 공유 클라우드 범위는 전용 범위보다 신뢰도가 낮습니다.

웹 봇 인증 서명 (Web Bot Auth signatures)

기술이 나아가는 방향이자, 네트워크 토폴로지(topology)가 아닌 암호학적으로 신원을 증명하는 유일한 방법입니다. 봇은 HTTP 메시지 서명(HTTP Message Signatures)을 사용하여 개인 키(private key)로 HTTP 요청에 서명하고, 발견 가능한 JWKS 디렉토리에 공개 키(public key)를 게시하며, 서버는 이 서명을 검증합니다. 이 방식은 IETF를 통해 진행 중이며, Cloudflare, Akamai, AWS는 검증자(verifier) 측면에서 지원 기능을 출시했습니다.

대부분의 글에서 생략되는 부분인 운영자(operator) 측면에서의 솔직한 현황은 다음과 같습니다: 저희 레지스트리에 등록된 41개 크롤러의 기본 문서를 확인한 결과, 현재 시점에서 검증 가능한 signature-agent 도메인과 JWKS URL을 게시하고 있는 크롤러는 단 하나도 확인되지 않았습니다. 인프라는 존재하지만, 사이트 소유자가 즉각적으로 조치를 취할 수 있는 방식으로 운영자 측의 배포(rollout)가 아직 문서화되지 않았습니다. Web Bot Auth를 이번 분기에 바로 적용해야 할 대상이 아니라, 향후 구축해 나가야 할 목표로 간주하십시오.

41개 크롤러가 실제로 지원하는 것

레지스트리 전반에 걸친 검증 방법(하나의 크롤러가 여러 방법을 지원할 수 있음)을 집계하면 다음과 같습니다:

크롤러는 하나 이상의 방법을 문서화할 수 있으므로, 처음 세 줄은 중복됩니다: 41개 중 25개는 최소 하나 이상의 네트워크 수준 확인(network-level check)을 지원하며, 나머지 16개는 전혀 지원하지 않습니다. 이 16개의 경우, 운영자가 게시하는 유일한 식별자는 user-agent 문자열뿐이며, 이를 대조하여 확인할 수 있는 수단이 없습니다. 이들을 허용할 수도 있고 차단할 수도 있지만, 검증할 수는 없습니다. (16개 중 하나인 Google-Extended는 user-agent 문자열조차 없습니다 — 아래 참조.)

목적별로 분류하면 동일한 41개는 다음과 같이 나뉩니다: 13개의 사용자 트리거 페처(user-triggered fetchers, 사람이 요청했기 때문에 페이지를 가져오는 에이전트), 10개의 검색 인덱스 크롤러(search-index crawlers), 9개의 학습 크롤러(training crawlers), 4개의 에이전틱 브라우저(agentic browsers), 3개의 데이터 제공자(data providers), 그리고 2개의 순수 옵트아웃(opt-out) 토큰 — Google-Extended와 Applebot-Extended는 크롤러가 아니라, 이미 가져온 페이지를 어떻게 사용할지 제어하는 robots.txt 토큰입니다.

단 하나의 Disallow를 작성하기 전에 이 차이점을 반드시 숙지해야 합니다. 학습 크롤러를 차단하는 것은 유입 트래픽(referral traffic) 측면에서 손해가 없습니다. 하지만 사용자 트리거 페처를 차단하는 것은, 어떤 사람이 자신의 어시스턴트에게 귀하의 페이지에 대해 물어봤으나 어시스턴트가 해당 페이지를 읽을 수 없음을 의미합니다.

전혀 검증할 수 없는 카테고리

에이전트 브라우저 (Agentic browsers)은 진정으로 다른 문제입니다. 이들은 사용자를 대신하여 AI 에이전트에 의해 구동되는 실제 브라우저 엔진입니다. 이들은 안정적인 봇 토큰 (bot token)을 가지고 있지 않은데, 네트워크 관점에서 볼 때 이들은 그 자체로 브라우저이기 때문입니다: 실제 Chrome User-Agent, 실제 TLS 지문 (TLS fingerprint), 실제 JavaScript 실행을 수행합니다.

레지스트리는 네 가지를 추적하며, 이 목록의 변동성 자체가 시사하는 바가 큽니다: ChatGPT Atlas (OpenAI)와 Comet (Perplexity)는 현재 사용 중인 반면, OpenAI의 Operator와 Google의 Project Mariner는 이미 폐기(deprecated)된 것으로 기록되어 있습니다 — 18개월 만에 대체되었습니다. 여기서 무엇을 구축하든, 교체될 것을 전제로 구축하십시오.

일치시킬 User-Agent 문자열도 없고, 공개된 IP 범위도 없으며, 역방향 DNS (reverse DNS) 접미사도 없습니다. 행동 신호 (Behavioural signals)만이 유일하게 남은 수단이며, 헤드리스(headless)이지만 실제 브라우저인 경우의 행동 신호는 약합니다.

이것이 현재 도구 세트의 솔직한 한계이며, 이것이 바로 Web Bot Auth가 중요한 이유입니다. 이는 에이전트 브라우저가 신원을 추론하도록 요구하는 대신, 검증 가능한 신원을 자발적으로 제공할 수 있게 하는 유일한 제안입니다.

검증 구현하기

순방향 확인을 포함한 역방향 DNS (Reverse DNS), 의존성 없는 Node 환경:

import { promises as dns } from "node:dns";

// 운영자가 크롤러를 위해 공개한 접미사들. 절대 이를 추측하지 마십시오 —
...

프로덕션 환경에서 반드시 지켜야 할 두 가지가 있습니다. 이를 대역 외 (out of band) 방식으로 처리하십시오. 요청 경로 내부에서의 DNS 라운드 트립 (round trip)은 지연 시간(latency) 및 서비스 거부(DoS) 취약점이 될 수 있으므로, 비동기적으로 검증하고 IP별로 판정 결과를 캐싱하십시오. 그리고 요청이 아닌 귀하의 정책에 따라 '실패 시 차단 (fail closed)' 하십시오: 검증되지 않은 요청이 반드시 적대적인 것은 아니며 단지 증명되지 않았을 뿐입니다. 따라서 실제 사용자일 수도 있는 요청에 403 에러를 반환하기보다는 권한을 낮추십시오 (downgrade privileges).

왜 확신에 찬 추측보다 "불분명함"이 더 나은 답변인가

대부분의 공개된 AI 크롤러 목록은 모든 봇에 대해 robots.txt 준수 여부를 명확한 Yes/No로 제공합니다. 이 데이터를 수집해 본 결과, 그 '명확함'이 가장 방어하기 어려운 부분임이 드러났습니다.

상당수의 크롤러(crawler)의 경우, 운영자가 해당 정확한 이름으로 에이전트에 대한 명시적인 성명을 발표한 적이 전혀 없습니다. 이 경우 선택할 수 있는 옵션은 형제 봇(sibling bot)으로부터 추론하거나, 다른 목록이 주장하는 내용을 복사하거나, 혹은 "불분명함(unclear)"으로 기록하고 운영자가 실제로 말하는 내용을 인용하는 것뿐입니다. 확인 절차를 거치는 사람을 상대로 살아남는 것은 오직 세 번째 방법뿐입니다.

따라서 이 포스트의 기반이 되는 레지스트리(registry)는 예(yes), 아니오(no), 불분명함(unclear)이라는 3가지 상태(tri-state)를 유지하며, 각 개별 주장에는 기본 출처 URL과 last_verified 날짜가 첨부됩니다. 또한, 그럴듯해 보이는 추측 대신 정보를 가져올 수 없는 필드에는 명시적인 null 값을 기록합니다. 이는 덜 깔끔해 보일 수 있습니다. 하지만 운영자가 조용히 문서를 변경하더라도 진실을 유지하는 유일한 방식입니다.

크롤러별 데이터 — user-agent 토큰, robots.txt 토큰, 검증 방법, 공개된 IP 범위 URL, 거부(opt-out) 메커니즘, 그리고 모든 필드 뒤에 숨겨진 출처 URL — 가 필요하다면 agentswelcome.dev/crawlers에서 확인할 수 있으며, 직접 읽는 것보다 차이점(diff)을 비교하는 것을 선호한다면 /api/crawlers에 JSON 엔드포인트가 마련되어 있습니다.

FAQ

robots.txt에서 AI 크롤러를 차단하면 실제로 차단되나요?
기술적으로는 그렇지 않습니다. robots.txt는 권고 사항(advisory)입니다. RFC 9309는 구문과 기대치를 정의할 뿐, 강제 집행 메커니즘을 정의하지 않습니다. OpenAI, Anthropic, Perplexity는 각각 자신들의 크롤러가 이를 준수한다고 명시한 문서를 발표하고 있으며, 주요 운영자들이 이를 준수한다는 것이 증거입니다. 만약 강제 집행이 필요하다면, 그것은 텍스트 파일이 아니라 WAF 규칙이나 에지(edge)에서의 검증된 봇 정책(verified-bot policy)이어야 합니다.

Google-Extended는 제가 차단해야 할 크롤러인가요?
Google-Extended는 크롤러가 아니며 user-agent 문자열도 없습니다. 이는 Google이 이미 수집한 콘텐츠를 Gemini 학습에 사용할 수 있는지 여부를 제어하는 robots.txt 토큰입니다. 이를 허용하지 않는다고 해서 크롤링 트래픽이 줄어들지는 않으며, 검색 인덱싱(Search indexing)에도 영향을 미치지 않습니다. Applebot-Extended도 Apple의 경우 동일한 방식으로 작동합니다.

학습용 크롤러는 차단하되 검색 크롤러는 허용해야 할까요?
그것이 일반적인 정책이며, 그 논거는 타당합니다. 학습용 크롤러(training crawler)는 참조 경로(referral path) 없이 귀하의 콘텐츠를 소비하는 반면, 검색 인덱스(search-index) 또는 사용자 트리거 방식의 페처(fetcher)는 현재 사람이 읽고 있는 답변에서 귀하를 노출할 수 있습니다. 기업 단위가 아닌 봇 유형(bot type)별로 결정하십시오. 여러 운영사(operators)가 서로 다른 토큰(token)을 사용하여 두 종류의 봇을 모두 운영합니다.

이 데이터는 얼마나 자주 변경되나요?
중요할 정도로 자주 변경됩니다. 운영사들은 공지 없이 토큰을 추가하고, 에이전트(agents)의 이름을 변경하며, IP 범위(IP ranges)를 업데이트합니다. 주장된 소스 URL과 확인 날짜가 포함되지 않은 모든 크롤러 목록은 누군가의 특정 시점(이 글을 쓰는 시점 포함)을 포착한 스냅샷에 불과합니다. 그렇기 때문에 위의 수치에는 확인 날짜인 2026-07-30이 포함되어 있습니다.

데이터 출처: AGENTS WELCOME crawler registry — 41개의 크롤러, 각 필드는 자체적인 기본 소스 및 확인 날짜를 포함하고 있습니다. 2026-07-30 확인됨.