Cloudflare가 2026년 7월 1일 changelog에서 AI 봇 트래픽 관리 방식을 크게 세분화했습니다. 지금까지는 “AI 크롤러 차단”이 사실상 단일 토글이었지만, 이제 크롤러가 무엇을 하려는지에 따라 다른 정책을 적용할 수 있습니다.

Cloudflare를 사용하지 않는 사이트도 이 변화를 눈여겨봐야 합니다. Cloudflare가 시장 표준을 만들고 있고, 다른 CDN·WAF·자체 서버 정책도 이 흐름을 따라가고 있기 때문입니다.

무엇이 바뀌었나

Cloudflare는 AI 크롤러를 아래 세 가지 행동 유형으로 분류합니다.

  • Search — 콘텐츠를 색인화해 나중에 검색·질문 응답에 사용. 전통적인 검색 엔진과 유사하지만 AI 답변용 인덱싱까지 포함. 사이트 입장에서는 트래픽·노출 이득이 있는 카테고리.
  • Agent — 사용자를 대신해 실시간으로 페이지를 열어 정보를 수집하거나 작업을 수행. 예: ChatGPT의 브라우징, AI 에이전트가 사이트에서 예약·주문 대행. 사용자 이익은 있지만 트래픽·매출은 사이트 소유자에게 잘 돌아가지 않음.
  • Training — 대규모 언어 모델 학습용 데이터 수집. 사이트 소유자 입장에서 가장 논쟁적인 카테고리. 콘텐츠는 가져가지만 트래픽·보상은 없다.

각 카테고리마다 세 가지 옵션이 있습니다.

  • 모든 페이지에서 차단
  • 광고 페이지에서만 차단(=수익 페이지만 보호)
  • 차단 안 함

즉 “Search는 환영하지만 Training은 완전 차단”, “Agent는 광고 페이지에서만 막고 나머지는 허용” 같은 세밀한 조합이 가능합니다.

기본값 변경 일정 (2026-09-15)

새로 등록되는 도메인은 2026년 9월 15일부터 다음이 기본값이 됩니다.

  • Training — 광고 페이지에서 차단
  • Agent — 광고 페이지에서 차단
  • Search — 허용

기존 도메인의 설정은 그대로 유지됩니다. 다만 앞으로 등록될 신규 사이트는 별도 설정이 없어도 광고 페이지에서 학습·에이전트 봇이 자동으로 차단됩니다.

9월 15일 전에 대시보드에서 opt-out 하면 기본값 적용을 거부할 수 있습니다.

왜 이런 변화가 중요한가

지금까지 웹사이트 운영자의 AI 봇 대응은 이분법이었습니다. “허용” 아니면 “차단”. 그런데 실제로는 그 사이에 여러 층이 있습니다.

  • Search 봇은 사이트에 트래픽을 되돌려줍니다. 차단하면 자기 콘텐츠가 AI 답변에서 사라집니다.
  • Agent 봇은 사용자에겐 편하지만, 사이트는 원래 자기가 가져갈 트래픽을 봇에게 뺏깁니다.
  • Training 봇은 콘텐츠를 무단 학습하지만, 그 대가로 사이트가 얻는 건 없습니다.

Cloudflare의 이번 변화는 이 층을 정책 옵션으로 명시한 첫 대규모 사례입니다. 앞으로 다른 사업자·표준화 기구도 이 프레이밍을 따라갈 가능성이 큽니다.

Cloudflare를 쓰지 않아도 대응은 필요합니다

TCP-80.NET의 일본 VPS·전용서버 고객처럼 자체 서버로 웹사이트를 운영하는 경우, Cloudflare의 이번 변화 자체는 직접 적용되지 않습니다. 그러나 같은 원칙을 자체 서버 레벨에서 구현하면 동일한 효과를 낼 수 있습니다.

1) robots.txt로 명시적 정책 선언

robots.txt는 강제성이 없지만, 정직한 크롤러(GoogleBot·BingBot·GPTBot·ClaudeBot·PerplexityBot 등)는 대부분 준수합니다. 카테고리별 선언 예시.

# Training 봇 전면 차단
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

# Agent 봇은 광고 페이지에서 차단
User-agent: ChatGPT-User
Disallow: /ads/

# Search 봇은 허용 (별도 지시 없음)

# 나머지 봇 기본 정책
User-agent: *
Allow: /

Google-Extended는 구글 검색과 별개로 Gemini 학습에만 적용되는 지시자입니다. 검색은 허용하고 학습만 차단할 때 사용합니다.

2) Nginx/Apache에서 User-Agent 기반 차단

정직하지 않은 크롤러는 robots.txt를 무시합니다. 그럴 때는 웹서버 레벨에서 직접 차단.

# Nginx
if ($http_user_agent ~* "(GPTBot|CCBot|anthropic-ai|Bytespider)") {
    return 403;
}

# 광고 페이지에서만 차단하려면
location /ads/ {
    if ($http_user_agent ~* "(ChatGPT-User|Google-Extended)") {
        return 403;
    }
}

User-Agent 문자열은 크롤러가 마음대로 위조할 수 있으므로 이 방법도 완벽하지 않습니다. IP 대역 기반 차단과 결합해야 실효성이 있습니다.

3) IP 대역·rate limit 병행

주요 AI 사업자의 크롤러 IP 대역은 대부분 공개돼 있습니다.

이 대역을 iptables·nftables·Cloudflare Zero Trust IP List 등에 등록하고, 특정 경로에서 rate limit도 걸면 정책이 이중화됩니다.

4) 로그 분석으로 실태 파악

먼저 자기 사이트에 어떤 크롤러가 얼마나 오는지 파악해야 정책이 맞는지 판단할 수 있습니다.

# Nginx access log에서 크롤러별 요청 수
awk -F'"' '/GPTBot|ClaudeBot|Bytespider|CCBot|anthropic-ai/ {print $6}' access.log \
  | sort | uniq -c | sort -rn | head -20

한 달치 로그를 위 명령으로 훑어보면 “우리 사이트에는 하루 몇 만 건씩 학습 봇이 온다”는 실감이 생깁니다. 트래픽·서버 부하 관점에서도 무시하기 어려운 규모인 경우가 많습니다.

정책을 결정할 때 던져야 할 질문

Cloudflare 정책이든 자체 서버 정책이든, 결정 전에 던져야 할 질문은 같습니다.

  • 이 사이트의 콘텐츠는 광고 수익 기반인가? 그렇다면 Agent·Training 차단 실익이 크다.
  • 이 사이트는 검색 노출이 매출·인지에 중요한가? Search 차단은 자기 발등을 찍는 결정이 될 수 있다.
  • API 매출이 있는가? 유료 API를 무료 페이지에서 크롤링당한다면 강경 대응 근거가 된다.
  • 개인정보·저작권 이슈가 있는가? 사용자 게시물·이미지가 학습 데이터가 되는 것을 사용자에게 어떻게 설명할 것인가.

정답은 사이트 성격에 따라 다릅니다. Cloudflare의 이번 프레이밍은 그 결정을 명시적으로 만들어준다는 데 의미가 있습니다.

실무적 액션 요약

이번 주에 한 번쯤 해볼 만한 작업.

  • robots.txt에 GPTBot·ClaudeBot·Google-Extended·Bytespider 정책을 명시적으로 추가
  • Nginx/Apache 로그에서 최근 30일 AI 크롤러 요청 수 집계
  • 결과가 무시할 수준이 아니면 IP 대역 차단·rate limit 도입
  • Cloudflare를 사용 중이면 대시보드에서 2026-09-15 기본값 변경 전에 정책 점검

마무리

AI 크롤러 관리는 앞으로 “선택적 대응”에서 “기본 위생”으로 넘어갈 겁니다. Cloudflare가 이번에 프레이밍을 세분화한 것이 그 신호입니다.

TCP-80.NET의 VPS·전용서버 고객 중에서 크롤러 트래픽이 서버 부하로 이어지는 경우 @tcp80net 텔레그램으로 문의 주시면 Nginx·방화벽 레벨의 정책 세팅을 함께 검토해 드립니다.

출처 (Source)

이 글은 아래 Cloudflare 공식 changelog를 참고해 tcp-80.net 청중 관점에서 재구성·번역·확장했습니다. 정책 원문·정확한 옵션명·향후 업데이트는 원문을 확인하시기 바랍니다.

본 글에는 원문에 없는 자체 서버(Nginx·Apache·robots.txt) 대응 가이드가 포함되어 있습니다. Cloudflare 제품 설명은 원문 기준이며, 실제 옵션명·UI는 시점에 따라 다를 수 있으니 Cloudflare 대시보드에서 최종 확인하시기 바랍니다.