CDN, WAF 기본 설정 AI 크롤러 차단 점검표: Cloudflare, AWS WAF, Akamai

"CDN, WAF 기본 설정이 AI 크롤러를 막고 있는지 어떻게 점검하나." robots.txt에서 OAI-SearchBot과 PerplexityBot을 허용해 두고도 AI 답변에 인용되지 않는 사이트를 보면, 흔한 원인 중 하나가 그 앞단의 엣지 계층이다. CDN의 봇 관리 설정, WAF의 관리형 규칙 그룹, 무료 요금제의 봇 차단 토글은 robots.txt를 읽기 전에 요청을 거절할 수 있다. 이 글은 Cloudflare, AWS WAF, Akamai, Fastly, Vercel의 AI 봇 관련 문서를 대조하고, 어떤 순서로 무엇을 확인하면 되는지 정리한다.

30초 정의

• CDN 봇 기본값은 사이트 소유자가 별도 예외를 만들지 않았을 때 CDN 엣지가 봇 요청에 적용하는 허용, 차단, 챌린지 동작이다.
• WAF 관리형 봇 규칙은 보안 벤더가 유지하는 규칙 묶음으로, 추가하는 순간 벤더가 정한 기본 액션이 봇 요청에 적용된다.
• **검증 봇(verified bot)**은 CDN이나 WAF 벤더가 출처를 확인한 봇이며, Cloudflare는 신원을 정직하게 밝히고 robots.txt를 지키는 등 남용하지 않는 봇으로 설명한다(Cloudflare, 2026).^[4]
• 검색용 AI 봇은 AI 검색 답변에 링크로 노출할 페이지를 수집하는 봇이며, OpenAI의 OAI-SearchBot과 Perplexity의 PerplexityBot이 여기에 해당한다(OpenAI, 2026; Perplexity, 2026).^[10][11]
• 사용자 요청 페처는 사용자가 질문할 때 실시간으로 페이지를 가져오는 봇이며, ChatGPT-User와 Perplexity-User가 여기에 해당하고 robots.txt가 적용되지 않을 수 있다(OpenAI, 2026; Perplexity, 2026).^[10][11]

벤더별 AI 봇 기본값 비교

표의 근거는 다음과 같다. Cloudflare의 AI 봇 정책과 관련 분류는 Block AI bots와 Verified bots 문서에서 확인할 수 있다(Cloudflare, 2026).^[2][4] Bot Fight Mode를 WAF 사용자 규칙이나 Page Rules로 건너뛸 수 없다는 내용은 Bot Fight Mode 문서에 있다(Cloudflare, 2026).^[3] AWS WAF의 CategoryAI 규칙 액션은 Bot Control 규칙 그룹 문서에 있다(AWS, 2026).^[5] Akamai의 AI bots 카테고리와 검색 엔진 봇 분류 가능성은 Akamai 블로그에 나온다(Akamai, 2024).^[6] Fastly의 AI Crawler와 AI Fetcher 구분은 출시 공지에 있고(Fastly, 2025), ^[7] Vercel의 두 범주 분리와 관리형 규칙은 변경 기록에 있다(Vercel, 2025; Vercel, 2026).^[8][9]

Cloudflare와 AWS WAF에서 특히 확인할 점

Cloudflare는 AI 크롤러 정책 변화를 보도자료와 제품 문서로 안내한다. 2025년 보도자료는 신규 도메인에 AI 크롤러 접근 허용 여부를 묻는 흐름과 AI 크롤러 차단 기능을 소개한다(Cloudflare, 2025).^[1] 현재 운영 중인 계정에 실제로 어떤 정책이 보이는지는 제품 문서의 설정 화면 설명으로 다시 확인해야 한다(Cloudflare, 2026).^[2] 같은 이유로 오래전에 만든 도메인과 새로 만든 도메인의 상태가 다를 수 있으니, 문서에서 본 설명을 그대로 가정하지 말고 대시보드의 현재 값을 확인하는 편이 안전하다.

Cloudflare의 검증 봇 문서에는 AI Assistant, AI Crawler, AI Search 같은 분류가 보이며, 문서가 갱신되면서 검색 관련 분류나 정책 이름이 바뀔 수 있다(Cloudflare, 2026).^[4] 기존 사용자 규칙이 예전 분류 이름을 참조하고 있으면, 새 분류 체계와 어긋나 예외 규칙이 기대대로 동작하지 않을 수 있다. 이때는 규칙 이름만 보지 말고 실제 매칭 조건과 로그의 봇 분류 값을 함께 봐야 한다.

AWS WAF는 동작이 더 단순하지만 영향이 크다. Bot Control 규칙 그룹의 카테고리 규칙 대부분은 미검증 봇에만 Block을 적용하고 검증 봇에는 라벨만 붙인다. 반면 CategoryAI 규칙은 검증 여부와 무관하게 일치하는 모든 요청에 Block을 적용한다(AWS, 2026).^[5] 따라서 보안팀이 Bot Control을 켜고 CategoryAI를 그대로 두면, 검색용 AI 봇도 함께 막힐 수 있다. WAF를 쓴다는 사실만으로 자동 차단이 일어나는 것은 아니지만, 규칙 그룹을 추가한 뒤 기본 액션을 확인하지 않으면 문제가 생기기 쉽다.

Akamai는 알려진 봇 디렉터리에 AI bots 카테고리를 두고 여러 AI 크롤러를 포함한다고 설명한다. 같은 글은 일부 AI 챗봇이 모회사 검색 크롤러를 사용하므로 검색 엔진 봇으로 분류될 수 있다고 적는다(Akamai, 2024).^[6] 따라서 AI bots 카테고리만 보고 허용, 차단을 정하면 실제 수집 흐름과 어긋날 수 있다. 검색 엔진 봇 분류도 함께 확인해야 한다.

Fastly는 AI Crawler를 학습이나 대규모 데이터셋 구축용으로, AI Fetcher를 사용자 질문에 실시간으로 답을 보강하는 용도로 구분한다(Fastly, 2025).^[7] Vercel도 AI crawlers와 AI assistants를 따로 다룬다(Vercel, 2026).^[9] 두 제품 모두 핵심은 같다. 학습용과 검색용, 실시간 fetch용 봇을 한 규칙으로 묶지 말고 목적별로 나눠 액션을 확인해야 한다.

엣지 차단이 AI 검색 인용에 미치는 영향

차단이 어느 봇에 걸리느냐에 따라 결과가 달라진다. OpenAI는 OAI-SearchBot을 차단한 사이트가 ChatGPT 검색 답변에 표시되지 않을 수 있다고 설명한다(OpenAI, 2026).^[10] 반면 GPTBot 차단은 학습용 수집을 거부하는 신호이며, 검색용 봇 차단과는 구분해서 봐야 한다(OpenAI, 2026).^[10]

검색용 크롤러를 엣지에서 막으면 robots.txt에 허용을 적어도 결과는 달라지지 않는다. Perplexity는 WAF를 쓰는 사이트라면 자사 봇을 명시적으로 허용해야 할 수 있다고 안내하고, 공식 JSON 엔드포인트의 최신 IP 대역과 User-Agent를 함께 대조하라고 권한다(Perplexity, 2026).^[11] 학습용 봇과 검색용 봇을 user agent 단위로 나누는 기준은 AI 크롤러 관리 가이드에 정리돼 있다. Perplexity 인용이 유독 없는 사이트라면 Perplexity가 내 콘텐츠를 인용하지 않는 이유의 다른 원인과 함께 본다.

실행, CDN과 WAF AI 크롤러 차단 점검 체크리스트

3번과 6번은 Cloudflare와 Perplexity 문서가 공통으로 중요하게 다루는 부분이다. Bot Fight Mode는 WAF 사용자 규칙으로 건너뛸 수 없고, IP Access 규칙이 먼저 일치하면 Bot Fight Mode가 동작하지 않는다(Cloudflare, 2026).^[3] Perplexity도 Skip 규칙은 그 뒤에 실행되는 규칙에만 적용되므로 허용 규칙을 차단, 챌린지 규칙보다 앞에 두라고 안내한다(Perplexity, 2026).^[11]

4번은 AWS 문서에 해법이 있다. Bot Control은 봇 이름, 카테고리, 검증 여부를 라벨로 남기므로, 규칙 그룹 뒤에 라벨 일치 규칙을 두면 원하는 봇만 허용하거나 차단할 수 있다(AWS, 2026).^[5] AWS WAF에서 IP 세트와 User-Agent 일치를 묶은 허용 규칙을 만들고 차단 규칙보다 낮은 우선순위 번호를 주라는 안내는 Perplexity 문서에도 있다(Perplexity, 2026).^[11]

# AWS WAF 규칙 순서 예시 (우선순위 번호가 작을수록 먼저 평가)
0  Allow   IP 세트(OAI-SearchBot, PerplexityBot 공식 대역) AND User-Agent 일치
1  AWSManagedRulesBotControlRuleSet  (CategoryAI 규칙 액션 Count로 재정의)
2  Block   라벨 awswaf:managed:aws:bot-control:bot:category:ai
           AND NOT 라벨 bot:name 이 허용 목록에 포함

8번은 놓치기 쉽다. AWS WAF는 요청 출발지 IP로 봇 검증 여부를 판단하며, 프록시나 로드밸런서 뒤의 검증 봇은 전달 IP 설정을 쓰는 별도 허용 규칙을 Bot Control보다 앞에 두라고 안내한다(AWS, 2026).^[5] 같은 이유로 사무실에서 User-Agent만 GPTBot으로 바꿔 보내는 curl 시험은 미검증 봇 판정을 받을 수 있다. 판정은 로그에서 공식 IP 대역의 요청을 찾아 확인하는 편이 정확하다. OpenAI는 OAI-SearchBot, GPTBot, ChatGPT-User의 IP 대역 정보를 문서에서 안내한다(OpenAI, 2026).^[10]

9번에서 차단이 0건이어도 끝은 아니다. 엣지를 통과한 봇이 빈 HTML을 받으면 결과는 차단과 비슷하다. 렌더링 쪽 점검은 자바스크립트 렌더링과 AI 크롤러 사각지대에서 이어서 볼 수 있다. 블로그 플랫폼처럼 엣지 설정을 직접 바꾸기 어려운 환경은 국내 블로그 플랫폼 AI 크롤러 정책을 참고한다.

10번은 설정 변경이 실제 인용에 어떤 차이를 냈는지 확인하는 단계다. 같은 질문 세트를 엔진별로 반복 조회해 인용 여부를 날짜와 함께 기록해야, 인용 변화가 엣지 설정 때문인지 모델 업데이트 때문인지 구분하기 쉽다. 측정 설계는 멀티 엔진 측정에 정리돼 있다.

정리

AI 검색 인용이 없는 사이트에서 robots.txt만 고치고 끝내면 엣지 계층의 차단을 놓치기 쉽다. Cloudflare는 AI 봇 관련 정책과 분류를 문서로 제공하므로 현재 계정의 설정값을 직접 확인해야 하고(Cloudflare, 2025; Cloudflare, 2026), ^[1][2] AWS WAF Bot Control의 CategoryAI 규칙은 검증 봇까지 Block한다(AWS, 2026).^[5] Akamai, Fastly, Vercel은 AI 봇 분류를 제공하고 액션은 고객이 정한다. 점검 순서는 엣지 계층 목록화, AI 봇 규칙의 현재 액션, 허용 규칙의 평가 순서, 로그 기반 확인, 엔진별 인용 추적이다. GEO 전체 구조 안에서 이 점검이 어디에 놓이는지는 GEO란 무엇인가에서 볼 수 있다.