AI 크롤러, 이제 '봇이냐 아니냐'로 나누면 안 됩니다
작년 Cloudflare가 'Block AI Bots' 원클릭 옵션을 내놨을 때만 해도, 세상은 AI 봇을 그냥 '학습용이냐 아니냐'로 나눴어요. 그런데 1년이 지나니 상황이 완전히 달라졌죠. 구글 검색이 AI로 정렬되는 걸 넘어서 결과 페이지에서 바로 답을 주는 Answer Engine으로 변했고, ChatGPT나 Gemini 같은 에이전트가 사용자 대신 브라우저를 직접 조작하는 시대가 됐어요.
문제는 이 모든 게 다 '봇'이라는 하나의 라벨로 묶여 있다는 거예요. 사이트 운영자 입장에서는:
- 검색에 노출되고 싶은데, 학습까지 같이 당하는 건 억울하고
- 에이전트 트래픽은 실시간 사용자 요청인데, 학습 크롤러랑 똑같이 차단하면 서비스가 망가지고
- 그렇다고 전부 허용하면 콘텐츠가 그냥 털려나가는 구조
Cloudflare가 이 딜레마를 풀기 위해 내놓은 게 실용적 분류 체계(pragmatic taxonomy) 입니다. 핵심은 "이 봇이 AI냐"가 아니라 "이 봇이 내 사이트에서 뭘 하고 있냐" 를 묻는 거예요. 자세한 배경은 근거자료에서 확인할 수 있어요.
Search / Agent / Training — 3가지 축으로 나눈다
Cloudflare가 모든 고객(무료 플랜 포함)에게 제공하는 3가지 관리 축은 다음과 같아요.
1. Search (검색)
콘텐츠를 수집·색인해서 나중에 질문에 답하기 위한 DB를 구축하는 행위예요. 핵심은 이 크롤러가 나중에 referral traffic을 돌려준다는 기대가 있다는 점이에요. 그래서 기본값은 허용(Allow) 입니다.
2. Agent (에이전트)
사람을 대신해서 실시간으로 뭔가를 처리하는 자동화예요. ChatGPT-User 같은 채팅 fetch 봇, Gemini나 Claude가 Chrome을 조종하는 브라우저 에이전트가 여기 속해요. 반대편에 사람이 기다리고 있는 경우가 대부분이죠.
3. Training (학습)
콘텐츠를 가져가서 모델 학습이나 파인튜닝에 영구적으로 흡수시키는 크롤러예요. 데이터가 AI 아키텍처에 녹아들어가서 되돌릴 수 없다는 게 핵심이에요.
robots.txt에 새 시그널 추가
# 기존 Cloudflare 관리형 robots.txt
User-agent: *
Content-Signal: search=yes,ai-train=no
Allow: /
# 새 content-use 시그널이 추가된 버전
User-agent: *
Content-Signal: search=yes,ai-train=no,use=reference
Allow: /
use 필드는 세 단계로 나뉘어요.
use=immediate— 상호작용은 하되 저장·재사용 금지use=reference(기본값) — 색인·발췌·링크백까지만 허용use=full— 요약 및 전체 재현 허용
이 값들을 봇 분류와 조합하면 "Search, SEO, Ads Verification 용도 봇은 전부 허용하되 reference 레벨까지만" 같은 세밀한 규칙을 만들 수 있어요. 봇 하나하나 관리할 필요가 없어지는 거죠.
2026년 9월 15일, 기본값이 바뀝니다
가장 중요한 변화는 기본값(default) 변경이에요. 이 날짜 이후 Cloudflare에 새로 온보딩하는 도메인은:
| 구분 | 광고 표시 페이지 | 비광고 페이지 |
|---|---|---|
| Search | 허용 | 허용 |
| Agent | 차단 | 허용 |
| Training | 차단 | 차단 (기존 정책 유지) |
광고가 붙은 페이지는 "사람이 봐야 돈이 되는" 페이지니까, 사람의 시선을 뺏는 Agent·Training 봇을 기본 차단하는 논리예요.
멀티퍼포즈 봇의 함정
여기서 진짜 주의할 부분이 있어요. Googlebot, Applebot, BingBot 같은 봇은 Search와 Training을 동시에 수행해요. Cloudflare는 "가장 제한적인 규칙이 적용된다"는 원칙을 세웠기 때문에, Training을 차단한 고객은 이 멀티퍼포즈 봇 전체가 차단돼요. 즉, 검색 노출까지 같이 막힐 수 있다는 뜻이에요.
만약 검색은 살리고 학습만 막고 싶다면, 9월 15일 이전에 Security 설정에서 명시적으로 옵트아웃해야 해요. 이거 모르고 있다가 검색 트래픽이 뚝 끊기는 사고가 실제로 발생할 수 있어요.
BotBase — 엔터프라이즈용 가시성 레이어
Enterprise Bot Management 고객에게는 BotBase라는 새 대시보드가 열려요. Cloudflare가 추적하는 모든 봇(Verified 봇 + 에이전트)을 검색 가능한 DB로 보여주고, 각 봇이 어떤 분류에 속하는지, detection ID는 뭔지 바로 확인할 수 있어요. 봇 분류는 다음 10가지예요.
- Search — 검색 결과 노출용 스캔
- Agent — 사람 대신 방문하는 에이전트
- Training — 모델 학습/파인튜닝용
- Transact — 사용자 대신 결제
- Data Collection — 가격 스크래핑, 경쟁사 분석
- Security Testing — 취약점 스캔, 펜테스트
- SEO — 사이트 감사, 접근성 체크
- Ads Verification — 광고 배치 검증, 부정 클릭 탐지
- Social / Link Preview — SNS·메신저 링크 미리보기
- Feed Fetching — RSS, 팟캐스트, 뉴스 피드
- Monitoring & Operations — 업타임 모니터링, 웹훅, 헬스체크
한국 개발 생태계에서의 적용 맥락
국내 SI·스타트업 환경에서는 이 변화가 특히 중요해요. 네이버·다음 같은 국내 검색엔진은 물론, 쿠팡·무신사 같은 커머스 사이트의 가격 스크래핑 봇도 Data Collection 카테고리로 잡히기 시작했어요. 특히 광고 기반 수익 모델을 가진 미디어 사이트라면 9월 15일 기본값 변경 전에 반드시 자사 도메인의 Security 설정을 점검하세요. 그리고 robots.txt에 Content-Signal: use=reference 한 줄 추가하는 것만으로도 상당한 콘텐츠 보호 효과가 있어요.
정리 — 지금 당장 해야 할 3가지
- Cloudflare 대시보드에서 새 AI 트래픽 옵션 확인 — 무료 플랜도 가능해요. Search/Agent/Training 각각의 허용·차단 상태를 지금 점검하세요.
- robots.txt에
use=reference추가 — Cloudflare 관리형 robots.txt를 쓰고 있다면 자동 반영되지만, 직접 관리 중이라면 수동으로 넣어야 해요. - 9월 15일 이전에 멀티퍼포즈 봇 정책 결정 — Googlebot을 차단할지, 검색은 살릴지 미리 결정하지 않으면 검색 트래픽이 끊겨요.
이 기술의 한계와 주의사항
솔직히 말하면, 이 시스템은 Cloudflare 네트워크 안에 있는 사이트에만 적용돼요. 전 세계 웹 도메인의 20% 정도가 Cloudflare 뒤에 있으니까, 나머지 80%는 여전히 봇 운영자의 선의에 의존해야 하는 구조예요. 그리고 Content-Signal은 어디까지나 **"선호 표시"**지 강제 차단이 아니에요. 봇이 이걸 무시하면 Verified 상태를 잃는다는 페널티가 있지만, 애초에 Verified 신청을 안 한 봇에게는 아무 의미가 없어요.
다음 단계 학습 방향
- Content Signals 스펙 원문을 읽어보고 자체 robots.txt 정책에 어떻게 녹일지 고민해보세요.
- 에이전트 트래픽이 늘어나는 환경에서 rate limiting과 인증 레이어를 어떻게 설계할지 공부해두면 좋아요.
- 함께 보면 좋은 글: 스포티파이 앱 릴리스의 뒷모습 — 대시보드 설계와 자동화의 교훈에서는 대규모 배포 자동화 관점에서 비슷한 교훈을 얻을 수 있어요. 그리고 NVIDIA Cosmos 3 Edge 로봇 제어 온디바이스 월드 모델 튜토리얼은 에이전트 계열 기술이 실제로 어디까지 가는지 감을 잡는 데 도움이 됩니다.