Cloudflare 9/15 크롤러 3분리가 공식 시작: 검색 엔진, AI 에이전트, 학습 크롤러 드디어 분리 관리

지난 몇 년간 웹사이트 소유자는 AI 크롤러에 대처할 수 있는 하나의 도구만 있었습니다: 모든 봇을 차단하거나 모두 통과시키는 것. 이 이분법적 접근법에 2026년 7월에 실질적인 변화가 일어났습니다.

Cloudflare는 올해 7월 1일, 모든 고객(무료 티어 포함)에게 3개의 독립된 AI 트래픽 스위치를 제공했습니다: Search (검색 엔진 크롤러), Agent (실시간 AI 에이전트), Training (모델 학습 크롤러). 9월 15일부터 기본값이 반전되며, 광고를 표시하는 페이지는 자동으로 Training과 Agent 유형의 봇을 차단합니다.

"일괄 처리"에서 "단계별 관리"로: 왜 중요한가?

과거에는 robots.txt가 유일한 의사 표시 수단이었지만, 대부분의 AI 크롤러는 이를 무시했습니다. Google봇은 검색 색인과 Gemini 모델 학습을 위해 동시에 콘텐츠를 스크래핑하고, Anthropic의 ClaudeBot은 리퍼럴 클릭 하나를 생성하기까지 11,000페이지 이상을 크롤링합니다 (Cloudflare Radar 2026년 중반 데이터). OpenAI의 비율도 857:1로 엄숙한 상황입니다.

반면, 기존 Google봇은 페이지 5개 크롤당 클릭 하나를 발생시킵니다. 메시지는 명확합니다: 당신은 AI 학습 기업을 위해 막대한 서버 리소스를 무료로 운영하지만, 실제 방문자는 거의 얻지 못합니다. 그리고 이 무효 트래픽은 직접적으로 CDN 대역폭과 청구 한도를 소비하고 있습니다.

Cloudflare의 3분리는 드디어 웹사이트 소유자에게 "가치 있는 검색 엔진"과 "주지 않고 가져가는 학습 크롤러"에 대해 별도의 지시를 내릴 수 있게 해 주며, "전부 열기" 또는 "전부 닫기"의 이분법적 선택에서 해방되었습니다.

가장 큰 논쟁: Google봇도 차단됨

이 정책에서 가장 논란을 불러일으킨 부분은 Training 봇 차단이 아니라, Google봇이 "다목적 크롤러"로 분류된 것입니다. Google은 검색 색인과 Gemini 모델 학습 모두에 동일한 크롤러 인프라를 사용합니다. 따라서 Training 트래픽을 차단하면 광고 페이지의 Google봇도 함께 차단됩니다.

Hacker News에서의 논의는 매우 격렬했습니다. 많은 개발자들이 이것이 Google이 받아야 할 것이라고 말했습니다: "OpenAI가 이미 GPTBot, OAI-SearchBot, ChatGPT-User를 3개의 별도 ID로 분리했음에도, Google은 아직 검색과 학습 모두에 동일한 크롤러를 사용하고 있습니다—문제가 명확합니다."

Cloudflare는 옵트아웃도 제공합니다—보안 설정에서 "Training+Search" 하이브리드 크롤러의 화이트리스트를 설정할 수 있습니다. 하지만 이 선택 자체가 더 깊은 산업 모순을 반영합니다: Google 검색 트래픽을 유지하기 위해 무료 학습 데이터를 계속 공급해야 하는 웹사이트 소유자.

다른 규모의 웹사이트, 완전히 다른 전략

"이 3개 스위치를 어떻게 설정해야 하나요?"라는 답은 수익 모델과 트래픽 소스에 따라 다릅니다:

• Google 검색 트래픽에 의존하는 중소형 사이트: Search는 완전히 열기, Training은 차단 (단, Google봇에 예외 설정), Agent는 상황에 따라 토글.
• 광고 수익을 주력으로 하는 뉴스/콘텐츠 사이트: Training과 Agent 모두 차단이 CDN 예산을 보호하는 가장 직접적인 방법입니다. 검색 가시성의 몇 센트를 위해 학습企業が 광고 페이지를 크롤링할 필요가 없습니다.
• 기술 문서 / API 공급업체: Agent가 가장 가치 있는 트래픽 유형일 수 있습니다 (개발자가 AI 에이전트로 문서를 조회). 하지만 남용을 방지하려면 속도 제한과 조합해야 합니다.
• 광고나 SEO에 의존하지 않는 독립 플랫폼: 모두 차단이 가장 깨끗한 접근법입니다—봇 트래픽이 전혀 필요 없으므로 차단하면 인프라 비용이 절약됩니다.

robots.txt로는 이제 충분하지 않습니다

IETF는 최근 robots.txt에 "Content Signal" 확장 (search=yes,ai-train=no,use=reference)을 추진하고 있지만, 이 선언적 형식은 자발적으로 준수하는 기업에게만 유효합니다. Cloudflare 대시보드 설정이 에지 계층에서 실제로 방화벽 규칙을 강제하는 것입니다.

실무에서는 가장 효과적인 방법이 양쪽을 병렬로 실행하는 것입니다: robots.txt는 의도를 표시하고, 준수하는 크롤러가 자동으로 따릅니다. Cloudflare 패널은 마지막 방어선이며, 모든 비준수 트래픽을 차단합니다. 이는 WAF 운영 로직과 직접 대응합니다—선언형 정책 + 강제 실행 계층.

운영 팀에 대한 실제 영향

어떤 종류의 사이트도 Cloudflare의 대개편이 같은 결론을 가리킵니다: 봇 트래픽 관리가 "할 것인가 말 것인가"의 문제가 아니라, "자해를 하지 않고 어떻게 할 것인가"의 문제가 되었습니다.

첫째, 누가 무엇을 크롤링하는지 알아야 합니다. 로그 분석 도구가 아직 사람과 봇의 구분만 하는 경우, ClaudeBot이 오늘 몇 기가바이트를 소비했는지, 어떤 에이전트가 합법적으로 접근하는지, 어떤 것이 남용 중인지 전혀 보이지 않습니다. 보이지 않는 것은 관리할 수 없습니다—모든 자동 방어의 전제 조건입니다.

둘째, 에지에서 빠른 의사결정이 필요합니다. 크롤러 요청이 백엔드 서버에 도달한 후에 판단하면 너무 늦습니다—트래픽 비용은 "이 봇에 가치가 있는지"가 아니라 요청별과 대역폭으로 계산됩니다. 방어가 CDN/WAF 에지에서 분류·차단하여 데이터가 서버에 도달하기 전에 대응해야 합니다.

셋째, "설정하고 끝"은 작동하지 않습니다. 크롤러의 행동은 변합니다 (Google봇은 내일 두 개의 별도 UA로 분리될 수도 있습니다), 새로운 봇이 등장하며, 사이트의 목적도 진화합니다. 좋은 봇 관리는 정기적인 검토와 조정이 필요하며, 일회성 설정이 아닙니다.