grep -E

저는 이 이야기를 여러 번 읽었습니다. 몇 달 동안의 콘텐츠가 있었지만, ChatGPT나 Perplexity에서는 인용된 바가 전혀 없었고, 감사(audit)를 통해 마침내 Cloudflare가 GPTBot에게 계속해서 403 오류를 주고 있었다는 사실이 밝혀졌습니다.

## 수정 안에 숨겨진 함정

`User-Agent`에 `GPTBot`을 포함하는 모든 것을 허용한다는 명백한 해결책은 잘못되었습니다. 왜냐하면 User-Agent는 누구나 입력할 수 있는 문자열이기 때문입니다. 가격 스크래퍼(price scraper)가 스스로를 `GPTBot`으로 레이블링하고 여러분의 관대한 새 규칙 사이로 거닐 수 있습니다.

Cloudflare 자체 투명성 추적 기능이 이 점을 지적합니다. 어떤 운영자가 검증될 수 있는지 플래그를 지정하기 때문입니다. 2026년 중반 기준으로, **ByteDance는 미검증(unverified) 상태**로 표시되어 있습니다. 이것이 바로 User-Agent만으로는 신뢰할 수 없는 이유입니다.

[![Cloudflare Radar — AI bot transparency: Amazon, Anthropic, Google, OpenAI verified; ByteDance not](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2Fg5rpv8h1imsvw9m0wvvd.png)](https://radar.cloudflare.com/ai-insights#ai-bot-crawler-traffic)
_AI 봇 투명성 추적. 출처: Cloudflare Radar, AI Insights, 2026년 7월 18일 기준._

따라서 진정한 검증은 이름이 아닙니다. 기원(origin)입니다. 두 가지 방법이 있습니다:

**1. 게시된 IP 범위로 검증.** OpenAI, Anthropic 등 다른 회사들도 크롤러 IP를 공개합니다 — `openai.com/gptbot.json`, `openai.com/searchbot.json`, `openai.com/chatgpt-user.json` 및 그에 상응하는 파일들입니다. 요청한 IP에 대해 역방향 DNS(Reverse-DNS)를 수행하여 호스트 이름이 해당 공급업체에 속하는지 확인하고, 그런 다음 이를 동일한 IP로 순방향 해석(forward-resolve)합니다. 이 단계 중 어느 하나라도 실패하면, 그것은 이름을 도용하는 스푸퍼(spoofer)입니다.

**2. 암호화 서명으로 검증.** 이것이 나아갈 방향입니다. **Web Bot Auth**—Cloudflare가 주도한 IETF 초안(`draft-meunier-web-bot-auth-architecture`, RFC 9421 기반)—는 크롤러들이 각 요청에 Ed25519 키로 서명하도록 하여, 주장하는 것이 아니라 신원을 증명하게 합니다. 이는 Cloudflare의 Verified Bots 프로그램에 통합되어 전용 Signed Agents 디렉터리를 가지고 있으며, ChatGPT 에이전트는 2025년 최초의 서명된 코호트(signed cohort)에 속했습니다. 또한 Cloudflare만의 이야기도 아닙니다 — AWS WAF는 2025년 후반에 Web Bot Auth 지원을 추가하여 검증된 에이전트를 자동으로 허용하게 했습니다.

Web Bot Auth의 현황을 솔직하게 파악하세요: 이는 승인된 표준이 아닌 **활성 IETF 초안**입니다. 하지만 Cloudflare, OpenAI, Anthropic, AWS가 같은 방향으로 움직이고 있기 때문에 이미 사실상의(de-facto) 방향이 되었습니다.

여러분에게 중요한 점은 다음과 같습니다: '나쁜 봇을 차단하는 것'과 'AI를 허용하는 것'은 동일한 문제입니다. 그리고 User-Agent는 어느 쪽도 해결하지 못합니다. 출처(origin) 또는 서명(signature)으로 검증하세요. 그렇지 않으면 원하는 크롤러를 차단하고 원치 않는 것을 허용하게 됩니다.

## 실제로 해야 할 일

**브라우저가 아닌 로그를 확인하세요.** 지난주간의 접근 로그를 가져와 AI User-Agent로 필터링하고 상태 코드(status codes)를 살펴보세요. 이것이 전체 감사 과정이며, 프로젝트가 아니라 오후에 끝낼 수 있는 작업입니다.

**403/429 오류가 보이면 규칙을 찾으세요.** 그것은 거의 항상 관리형 규칙 세트(managed ruleset), 'AI 봇 차단' 설정, 또는 지나치게 적극적인 봇 방어 점수(bot-fight score) 때문이며, 여러분이 직접 작성한 코드가 아닙니다. 원하는 크롤러는 검증된 IP나 Web Bot Auth를 통해 화이트리스트에 추가하고, 절대 User-Agent만으로 판단하지 마세요.

## 제가 얻은 교훈

여러분의 HTML은 요청 경로의 마지막 부분이 아니라 가장 마지막 부분입니다. 봇이 그 내용을 단 한 바이트도 읽기 전에, 요청은 DNS, CDN, WAF, 속도 제한기(rate limiter), 봇 관리 점수 등을 모두 통과해야 합니다. 이 중 어느 하나라도 여러분이 결코 볼 수 없는 상태 코드로 요청을 종료시킬 수 있으며, 이는 사용자에게는 완벽하게 보이는 페이지에서 발생합니다.

'내 브라우저에서는 작동한다'는 주장은 항상 약한 주장입니다. 크롤러의 경우 심지어 올바른 질문조차 아닙니다. 올바른 질문은 다음과 같습니다: **봇이 어떤 상태 코드를 받았는가?** 그리고 유일하게 솔직한 대답은 로그에 있습니다.

관련 읽을거리:

-   [Google에서 1위를 차지하고 ChatGPT에게 보이지 않는 방법](https://seo7.es/en/blog/ai-seo-blog/ranks-1-on-google-invisible-to-chatgpt)
-   [전체 사례: Django SSR 재구축, 0개에서 116개 인덱싱 페이지까지](https://seo7.es/en/proyecto/yoga-praktika)