Cloudflare 봇 트래픽 제어 설정 총정리

Cloudflare 대시보드의 Security 메뉴를 몇 달 만에 열어보면 꼭 뭔가가 바뀌어 있습니다. 이번에는 “Block AI Bots”가 있던 자리에 “Configure AI bot policies”가 생겼고 그 안의 Training 항목에는 못 보던 “Disallow”라는 선택지가 추가되어 있었습니다. 켜두었던 Managed robots.txt는 어느새 Bot Preference Sync라는 이름으로 바뀌어 있었고요. 😅

AI 크롤러 문제를 두고 이 블로그에서 여러 편을 썼는데요. robots.txt로 시작해 Pay Per Crawl, 콘텐츠 신호 정책, Web Bot Auth, 그리고 1년 뒤 결산까지 모두 “왜”에 관한 글이었습니다. 정작 “그래서 대시보드에서 뭘 켜야 하는데?”를 한곳에 모아둔 글이 없더라고요.

이 글이 그 지도입니다. 2026년 9월 현재 Cloudflare의 봇 트래픽 제어 설정을 계층별로 정리하고 제 블로그(Free 플랜)에는 실제로 어떻게 두었는지 보여드리겠습니다. 이번에 Training을 Disallow로 바꾸면서 부작용이 있는지도 데이터로 확인합니다. 설정이 또 바뀌면 이 글을 고치고 맨 아래 변경 이력에 남길 생각입니다.

이름이 바뀌어 온 순서

지금 대시보드가 헷갈리는 이유의 절반은 이름이 계속 바뀌었기 때문입니다. 순서대로 놓고 보면 흐름이 보입니다.

핵심은 두 가지입니다. 하나는 “AI 봇”이라는 단일 스위치가 크롤러의 행동별 정책으로 쪼개졌다는 것입니다. 다른 하나는 robots.txt에 뭘 쓸지를 사람이 정하는 대신 정책 설정에서 자동으로 도출하도록 바뀌었다는 것입니다.

요청 하나가 거치는 순서

설정 항목을 하나씩 보기 전에 Cloudflare가 요청을 어떤 순서로 검사하는지 알아두면 좋습니다. 어느 설정이 먼저 걸리는지에 따라 나머지 설정이 의미가 없어질 수도 있으니까요.

flowchart TB
    accTitle: Cloudflare가 요청 하나를 검사하는 순서
    accDescr: 요청은 규칙 엔진 안에서 HTTP DDoS 방어, 커스텀 규칙, 레이트 리밋, 관리형 규칙, Super Bot Fight Mode 순으로 평가된 뒤 오리진에 도달한다. Free 플랜의 Bot Fight Mode는 규칙 엔진 밖에서 독립적으로 평가된다.

    req[/"요청"/] --> ddos
    subgraph engine["규칙 엔진 (위에서 아래 순서로 평가)"]
        direction TB
        ddos["HTTP DDoS 방어"] --> custom["커스텀 규칙<br/>(Free 5개)"]
        custom --> rl["레이트 리밋<br/>(Free 1개)"]
        rl --> managed["관리형 규칙"]
        managed --> sbfm["Super Bot Fight Mode<br/>(Pro 이상)"]
    end
    subgraph outside["엔진 밖에서 독립 평가"]
        bfm["Bot Fight Mode<br/>(Free)"]
    end
    req -.-> bfm
    sbfm --> origin(["오리진"])
    bfm -.-> origin
    classDef dashed stroke-dasharray:4 4,stroke-width:1.5px
    class bfm dashed

규칙 엔진(Ruleset Engine) 안에서는 앞 단계가 차단이나 챌린지 같은 종료 동작을 하면 뒤 단계는 아예 실행되지 않습니다. 커스텀 규칙(custom rules)의 Skip 동작으로 뒤 단계를 건너뛸 수도 있고요. 그런데 Free 플랜의 Bot Fight Mode는 이 엔진 밖에서 돌아가기 때문에 커스텀 규칙으로 예외를 만들 수 없습니다. 이 사실이 뒤에서 Bot Fight Mode를 끌지 말지 판단하는 근거가 됩니다.

대시보드 지도: Security Settings의 그룹

새 대시보드에서는 Security 아래 Settings 페이지 하나에 모든 설정이 모여 있고 위협 유형별 그룹으로 필터링합니다. 문서에는 Web application exploits, DDoS attacks, Bot traffic, API abuse, Client side abuse 다섯 그룹이 나오는데 제 화면에는 Fraud와 Precursor까지 일곱 개가 보입니다. 한 설정이 여러 그룹에 동시에 속하기도 해서 Bot fight mode는 Bot traffic과 DDoS attacks 양쪽에 나타납니다.

개인 블로그 운영자가 실제로 만질 일이 있는 건 Bot traffic 그룹입니다. 필터를 걸면 다섯 항목이 남습니다.

이 다섯 항목 중 Challenge passage와 Cloudflare managed ruleset은 기본값으로 두면 되고 나머지 셋이 이 글의 본론입니다.

기본 방어선: 손댈 게 거의 없는 것들

먼저 건드릴 필요가 없는 것부터 치우겠습니다. DDoS 방어는 모든 플랜에서 항상 켜져 있고 Free 플랜에서는 조정할 항목 자체가 없습니다. Cloudflare Managed Free Ruleset도 마찬가지로 스위치가 비활성화된 채 “Always active”로 표시됩니다. Browser Integrity Check는 기본으로 켜져 있습니다. Challenge passage는 챌린지(challenge)를 통과한 방문자를 얼마나 오래 다시 묻지 않을지 정하는 값으로 기본 30분입니다.

예전에 Low부터 High까지 다이얼이 있던 Security Level은 사실상 사라졌습니다. 새 대시보드에서는 Under Attack 모드를 켜고 끄는 토글만 남았고 이 다이얼의 근거였던 위협 점수(threat score)는 이제 항상 0입니다. DDoS 공격을 받는 중이 아니라면 건드리지 않습니다.

커스텀 규칙과 레이트 리밋(rate limiting)은 Free 플랜에서 각각 5개와 1개까지 만들 수 있습니다. 봇 설정으로 표현할 수 없는 경로별 예외가 필요할 때 쓰는 도구인데, 정적 블로그에서는 아직 쓸 일이 없어서 제 존(zone)에는 하나도 없습니다.

Bot Fight Mode: 켜기 전에 알아야 할 것

Bot Fight Mode는 Free 플랜에서 쓸 수 있는 유일한 범용 봇 방어입니다. 알려진 봇 패턴에 해당하는 요청에 계산 비용이 큰 챌린지를 던져서 자동화 비용을 올리는 방식이죠. 켜면 JavaScript 감지(JavaScript Detections)가 자동으로 함께 켜지고 끌 수 없습니다.

문제는 예외를 만들 방법이 없다는 점입니다. 앞서 본 것처럼 규칙 엔진 밖에서 돌기 때문에 커스텀 규칙의 Skip이 통하지 않고 특정 IP나 User-Agent를 봐주는 설정도 없습니다. RSS 리더, 업타임 모니터, 결제 웹훅 같은 정당한 자동화 트래픽이 챌린지에 걸려도 손쓸 방법이 Pro 플랜의 Super Bot Fight Mode로 올라가는 것뿐입니다.

제 블로그에서는 꺼두었습니다. 정적 사이트라 폼이나 로그인처럼 봇이 노릴 만한 곳이 없고 피드 리더가 챌린지에 막히는 위험이 얻는 것보다 크다고 봤습니다. 봇 문제의 대부분은 아래 AI 봇 정책이 더 정교하게 처리해줍니다.

AI 봇 정책: Search, Agent, Training

이 글의 중심입니다. Cloudflare는 AI 봇을 이름이 아니라 행동(behavior)으로 분류합니다. 한 봇이 여러 행동을 가질 수 있고 각 행동을 따로 제어합니다.

• Search: 나중에 답을 내놓기 위해 콘텐츠를 수집하고 색인하는 크롤러
• Agent: 챗봇의 실시간 페이지 가져오기나 브라우저 에이전트처럼 사람의 지시로 그 자리에서 동작하는 봇
• Training: 모델을 학습하거나 파인튜닝하려고 콘텐츠를 가져가는 크롤러

각 행동마다 선택지가 있는데 Training에만 네 번째 선택지가 하나 더 있습니다.

대시보드에는 “Disallow”로만 표시되지만 Cloudflare 문서와 발표에서는 “Disallow AI Training”이라고 부릅니다. robots.txt에 발행하는 Disallow: 지시문에서 따온 이름입니다.

이 선택지가 왜 필요한지 이해하려면 혼합 용도 크롤러(mixed-use crawler) 문제를 알아야 합니다. Googlebot, Bingbot, Applebot은 검색 색인과 AI 학습에 같은 크롤러를 씁니다. 학습을 거부하려고 이 크롤러를 막으면 검색 노출까지 사라지는 것이죠. 그래서 2026년 9월 15일 이전에는 Training을 Block으로 두어도 이 세 크롤러에는 적용되지 않았습니다. Block이라고 써 있지만 Google은 안 막는, 좀 어정쩡한 상태였던 겁니다.

9월 15일부터 의미가 바뀌었습니다. 이제 Block과 Block on pages with ads는 혼합 용도 크롤러에도 그대로 적용됩니다. 즉 Training을 Block으로 두면 Googlebot도 막히고 검색에서 빠집니다. 학습은 거부하되 검색은 유지하고 싶다면 반드시 Disallow를 골라야 합니다. 기존 설정은 자동으로 옮겨졌습니다. 예전 Training의 Block과 Block on pages with ads는 모두 Disallow로, 구형 “Block AI Bots”를 켜두었던 존은 Search가 Allow, Training이 Disallow, Agent가 Block on pages with ads로 바뀌었습니다.

Disallow가 어떻게 검색을 지키면서 학습만 거부하는지는 크롤러 운영자에게 달려 있습니다. Cloudflare는 네 가지 조건을 충족하거나 기한을 정해 약속한 운영자를 책임 있는(Accountable) 운영자로 지정했습니다. 학습 거부 수단, AI 요약 거부 수단, URL 단위 투명성, 그리고 학습 거부가 검색 순위에 영향을 주지 않는다는 보증입니다. Apple, Google, Microsoft가 여기에 해당합니다. Amazon, Anthropic, Meta, OpenAI는 애초에 검색용과 학습용 크롤러를 분리해 운영하므로 학습용만 골라 막을 수 있습니다. 다만 Microsoft는 robots.txt의 학습 거부를 존중하는 기능을 2027년 초 목표로 아직 개발 중이라 그때까지 Bing의 학습을 멈추려면 NOARCHIVE 메타 태그를 따로 써야 합니다.

Agent에는 Disallow가 없습니다. 에이전트는 검색 노출과 얽히지 않아서 굳이 robots.txt로 표현할 이유가 없고 에이전트에게 거부 의사를 전달하는 표준도 아직 없기 때문입니다. “Disallow on pages with ads”도 없는데 광고가 실린 페이지 목록은 너무 크고 자주 바뀌어서 robots.txt에 열거할 수 없기 때문입니다.

새로 온보딩하는 도메인은 광고 수익 여부에 따라 다른 기본값을 받습니다. 광고가 없으면 셋 다 Allow, 광고가 있으면 Search는 Allow, Training은 Disallow, Agent는 Block on pages with ads입니다. Bot Preference Sync는 양쪽 모두 켜진 상태로 시작합니다. 광고 수익은 사람이 실제로 페이지를 봐야 생기는데 학습은 방문을 답변으로 대체하고 에이전트는 광고를 볼 사람 없이 페이지를 가져가니까 광고 사이트의 기본값이 더 보수적인 겁니다.

Bot Preference Sync: 설정을 robots.txt로 내보내기

정책 모달 맨 아래에 있는 “Enable Bot Preference Sync” 스위치는 예전 Managed robots.txt를 대체합니다. 둘의 차이는 robots.txt에 뭘 쓸지를 누가 정하느냐입니다. Managed robots.txt는 켜기만 하면 Cloudflare가 정한 AI 크롤러 목록을 무조건 붙였습니다. Bot Preference Sync는 위에서 고른 정책에서 내용을 도출합니다. 설명 문구 그대로 “your configured Cloudflare settings”를 robots.txt 앞에 붙이는 것이죠.

이 차이를 제 블로그에서 직접 확인했습니다. 스위치가 켜져 있는데도 Training이 Allow였을 때는 robots.txt가 저장소에 있는 원본 두 줄 그대로였습니다.

User-agent: *
Allow:/

발행할 거부 의사가 없으니 붙일 내용도 없었던 겁니다. Training을 Disallow로 바꾸자 몇 초 만에 파일이 2.6KB로 늘어났습니다. 콘텐츠 신호 정책 설명문에 이어 Content-Signal 한 줄과 학습 크롤러 목록이 앞에 붙고 원본은 맨 아래에 그대로 남습니다.

# BEGIN Cloudflare Managed content

User-agent: *
Content-Signal: search=yes,ai-train=no,use=reference
Allow: /

# Training crawlers
User-agent: Amazonbot
Disallow: /

User-agent: Applebot-Extended
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: GPTBot
Disallow: /

User-agent: meta-externalagent
Disallow: /

# ... 총 32개 User-Agent

# END Cloudflare Managed Content

User-agent: *
Allow:/

눈여겨볼 곳은 Googlebot이 아니라 Google-Extended, Applebot이 아니라 Applebot-Extended가 들어갔다는 점입니다. 검색용 토큰은 건드리지 않고 각 운영자가 학습 제어용으로 따로 마련한 토큰에만 Disallow를 거는 것이죠. 이게 앞서 말한 “검색은 유지하고 학습만 거부”가 robots.txt에서 구현되는 방식입니다.

Content-Signal 줄의 use=reference는 Cloudflare가 시험 중인 확장으로 색인과 발췌와 링크는 되지만 요약해서 재생산하지는 말라는 뜻입니다. ai-input은 빠져 있는데 명시하지 않으면 허용도 거부도 아니라는 정책 문구에 따라 Agent를 Allow로 둔 것과 맞아떨어집니다. 콘텐츠 신호 자체는 강제력이 없는 선호 표현이므로 실제 차단은 Cloudflare가 네트워크에서 학습 크롤러를 막는 것으로 이뤄집니다.

유지보수 관점에서 좋은 점은 저장소의 robots.txt를 손댈 필요가 없다는 것입니다. 정책은 대시보드에 살고 파일은 두 줄짜리 원본으로 남습니다. Google Search Console이 Content-Signal 줄에 “Syntax not understood”를 띄울 수 있는데 Cloudflare는 그 때문에 크롤링이나 SEO가 영향을 받은 사례는 없었다고 밝히고 있습니다.

AI Labyrinth: 막는 대신 헤매게 하기

AI Labyrinth는 페이지에 사람 눈에는 보이지 않는 nofollow 링크를 심어서 robots.txt를 무시하는 크롤러를 끝없는 링크 미로에 가두는 기능입니다. 미로에 들어온 크롤러의 정보는 Cloudflare 전체 고객의 차단 목록을 개선하는 데 쓰입니다. 링크는 봇에게만 보이므로 SEO나 화면에는 영향이 없다고 합니다.

이 기능은 차단이 아닙니다. Security Analytics에 “AI Labyrinth Served”와 “AI Labyrinth Crawls” 이벤트가 남는데 전자는 링크를 심었다는 뜻이고 후자는 크롤러가 그 링크를 따라갔다는 뜻입니다. 후자가 전자에 비해 많으면 규칙을 무시하는 크롤러가 실제로 활동하고 있다는 신호입니다. 끄더라도 이미 심어둔 링크는 얼마간 유효해서 이벤트가 한동안 더 보일 수 있습니다.

제 블로그에서는 아직 꺼두었습니다. 모든 페이지의 HTML에 생성된 내용이 주입되는 게 마음에 걸려서인데, Disallow로 바꾼 뒤 위반 크롤러가 얼마나 남는지 먼저 지켜보고 판단하려 합니다. 위 robots.txt 목록을 무시하는 크롤러가 계속 잡히면 켤 이유가 생깁니다.

AI Crawl Control: 크롤러 하나씩 보고 막기

Security Settings의 정책이 행동 단위라면 사이드바 상단의 AI Crawl Control은 크롤러 이름 단위입니다. 2026년 9월 현재 Overview, Metrics, Security, Optimization, Signals 다섯 페이지로 구성되어 있는데 문서에 나오는 Crawlers와 Robots.txt 탭이 각각 Security와 Signals로 바뀐 모양입니다.

Security 페이지에는 크롤러별 표가 있고 각 행에 Block Crawler 스위치가 달려 있습니다. 제 블로그의 최근 7일 요청 수를 보면 Meta-ExternalAgent가 8.09k로 1위이고 Googlebot 6.75k, Baidu 6.21k, Bingbot 4.16k, Applebot 2.36k, Claude-SearchBot 1.65k, GPTBot 1.08k, ClaudeBot 823 순입니다. Free 플랜에서는 User-Agent 문자열로 크롤러를 식별하므로 스스로 이름을 밝히는 크롤러만 잡힙니다. 차단 시 돌려줄 응답 코드와 메시지를 정하는 Configure Response도 여기 있는데, 402 Payment Required 같은 사용자 정의 응답은 유료 플랜부터입니다. 크롤러에게 통행료를 받는 Pay Per Crawl은 여전히 비공개 베타이고 제 존은 API로 물어보면 can_be_enabled: false가 돌아옵니다.

Signals 페이지에는 Bot Preference Sync 스위치가 한 번 더 나오고(정책 모달에 있는 스위치와 같은 설정입니다), 호스트별 robots.txt 상태와 요청 수, 그리고 robots.txt가 막은 경로를 요청한 크롤러의 위반 기록이 있습니다. 어떤 크롤러가 규칙을 무시하는지 여기서 확인하고 Security 페이지에서 그 크롤러만 막는 흐름입니다. 검증된 봇(verified bot)이 어떻게 신원을 증명하는지는 Web Bot Auth 글에서 다뤘습니다.

부작용은 없을까?

Training을 Disallow로 바꾸면서 가장 궁금했던 것입니다. 발행된 robots.txt를 보면 순수한 학습 크롤러가 아닌 것이 목록에 섞여 있거든요. Baiduspider와 PetalBot은 Baidu와 Huawei의 검색 크롤러이고 Amazonbot은 Alexa 답변에도 쓰입니다. CCBot은 Common Crawl이죠. 그리고 Google-Extended는 Gemini 모델 학습뿐 아니라 Gemini 앱과 Vertex AI의 그라운딩(grounding)에도 쓰이는 토큰입니다. 이 크롤러들이 Disallow를 존중하면 해당 서비스에서 제 콘텐츠가 빠집니다.

그래서 이 유입이 실제로 얼마나 되는지 GA4에서 최근 90일 세션을 소스별로 뽑아봤습니다. Google이 130,727, Naver가 약 5,800, Bing이 1,144입니다. Baidu는 1세션입니다. 반면 AI Crawl Control에서 본 Baidu의 크롤링은 7일에 6.21k 요청, 515MB였습니다. 일주일에 6천 페이지를 긁어가면서 석 달에 방문자 한 명을 보내는 셈이니, 검색에서 빠지더라도 잃을 게 없고 대역폭은 아낍니다. gemini.google.com 유입은 10세션이었습니다. Google 검색과 AI Overviews는 Googlebot을 쓰기 때문에 Google-Extended 거부의 영향을 받지 않고 Google도 이 토큰이 검색 순위에 쓰이지 않는다고 명시하고 있습니다.

AI 서비스에서 오는 유입은 chatgpt.com 60세션, claude.ai 41세션, perplexity 35세션 정도입니다. 이 유입은 OAI-SearchBot과 ChatGPT-User, Claude-SearchBot과 Claude-User처럼 Search와 Agent로 분류되는 봇을 타고 오는데 둘 다 Allow로 두었으므로 그대로입니다. 막히는 건 GPTBot과 ClaudeBot 같은 학습 전용 크롤러뿐입니다. Meta-ExternalAgent는 제 블로그를 가장 많이 긁어가는 크롤러였는데 이제 네트워크에서 차단되고 Meta AI에서 오는 유입은 GA에 잡힌 적이 없습니다.

정리하면 이 블로그 기준으로 실질적인 부작용은 없습니다. 다만 두 가지는 한계로 알아두어야 합니다. Bing은 2027년 초까지 robots.txt의 학습 거부를 존중하지 않으므로 이 설정만으로 Bing의 학습이 멈추지는 않습니다. 그리고 AI Overviews 같은 AI 요약을 거부하는 것은 학습 거부와 별개의 문제라 Disallow AI Training이 해결해주지 않습니다. Cloudflare는 이 제어를 내년 초에 대시보드로 가져오는 것을 목표로 하고 있습니다.

자기 사이트에서 같은 판단을 하려면 GA4에서 세션 소스에 baidu, gemini, chatgpt, claude가 얼마나 잡히는지 보면 됩니다. 유입이 의미 있는 크기라면 Disallow 대신 Allow를 유지하거나, AI Crawl Control에서 특정 크롤러만 따로 다루는 편이 낫습니다.

설정값을 API로 읽고 기록하기

대시보드는 계속 바뀌지만 API 필드는 상대적으로 안정적이라 현재 설정을 기록해두는 데는 API가 낫습니다. 존의 봇 관리 설정은 엔드포인트 하나로 다 읽힙니다.

curl -s "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/bot_management" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" | jq .result

이 글을 쓰는 시점의 제 블로그 설정입니다.

{
  "enable_js": true,
  "fight_mode": false,
  "ai_bots_protection": "disabled",
  "content_bots_protection": "disabled",
  "crawler_protection": "disabled",
  "ai_training": "disallow",
  "ai_search": "disabled",
  "ai_user": "disabled",
  "is_robots_txt_managed": true,
  "bot_preference_sync_enabled": true,
  "cf_robots_variant": "off",
  "ai_bots_migration_opt_out": false,
  "using_latest_model": true
}

필드 이름이 대시보드 표기와 꽤 다르므로 대응표를 남겨둡니다.

값도 표기가 다릅니다. 세 정책 필드에서 Allow는 disabled이고 Block은 block, Block on pages with ads는 only_on_ad_pages입니다. Training에만 disallow가 하나 더 있습니다. Agent가 ai_user라는 점과 켜져 있다는 뜻의 값이 필드마다 true, enabled, policy_only로 제각각이라는 점이 특히 헷갈립니다.

같은 엔드포인트에 PUT으로 바꾸고 싶은 필드만 보내면 설정이 바뀝니다. 제가 Training을 바꿀 때도 {"ai_training": "disallow"} 한 줄이었습니다. Cloudflare가 다음에 뭔가를 발표하면 이 명령을 다시 실행해서 새 필드가 생겼는지, 값이 옮겨졌는지 확인하고 이 글을 고칠 계획입니다.

변경 이력

• 2026-09-16: 최초 작성. Cloudflare의 2026년 9월 15일 변경(Disallow AI Training 추가, Block 의미 변경, Block AI Bots 폐기 예정, Managed robots.txt를 Bot Preference Sync로 대체)을 반영. daleseo.com의 Training을 Allow에서 Disallow로 변경.

마치며

설정이 복잡해 보이는 건 항목이 많아서라기보다 같은 문제를 푸는 층이 여러 겹이기 때문입니다. robots.txt는 선호를 말합니다. AI 봇 정책은 행동 단위로, AI Crawl Control은 크롤러 단위로 막습니다. AI Labyrinth는 규칙을 무시하는 쪽을 골라내고 Bot Fight Mode는 AI와 무관한 범용 봇을 상대합니다. 어느 층이 무엇을 담당하는지만 잡아두면 새 항목이 생겨도 어느 층에 들어가는지 금방 보입니다.

제 블로그의 결론은 Search와 Agent는 Allow, Training은 Disallow, Bot Preference Sync는 켬, 나머지는 끔입니다. 읽히는 게 목적인 기술 블로그라면 대체로 비슷한 선택이 될 텐데, 광고 수익이 있거나 유료 콘텐츠가 있다면 Block on pages with ads와 AI Labyrinth부터 다시 검토해보시길 권합니다. Cloudflare로 운영하는 다른 이야기는 Cloudflare 관련 글에 모아두었습니다.

이번 변경을 발표한 원문은 Accountable mixed-use AI crawlers이고 설정 항목의 정의는 Block AI bots 문서를 참고하세요.