AI 봇을 전부 막을까? Cloudflare의 Search·Agent·Training 분류로 다시 보는 콘텐츠 접근 정책

결론부터

AI 봇을 전부 막는 것은 시원하지만, 검색과 인용까지 같이 닫을 수 있다. 반대로 전부 열어두면 내 글이 어디에 저장되고, 어떤 에이전트가 어떤 행동을 하는지 모호해진다.

Cloudflare가 2026년 7월 공개하고 9월 15일 기본값 변경까지 예고한 AI 트래픽 옵션에서 중요한 변화는 이 지점이다.[1][2]

이제 질문은 “AI 봇을 막을까?”가 아니다.
“Search, Agent, Training 중 무엇을 허용할까?”다.

Search는 검색·답변을 위해 색인한다. Agent는 누군가를 대신해 지금 웹사이트에서 일을 한다. Training은 콘텐츠를 가져가 모델 학습이나 fine-tuning에 흡수한다.[1][2] 세 행동은 모두 자동화지만, 사이트 운영자 입장에서는 얻는 것과 잃는 것이 다르다.

기준 시점은 2026년 9월 15일이다. 아래 내용은 Cloudflare 공식 블로그와 개발자 문서를 바탕으로 정리했다.[1][2][3]

왜 갑자기 이 이야기가 중요해졌나

지난 몇 년 동안 작은 사이트 운영자가 AI 봇을 보는 방식은 대체로 둘 중 하나였다.

첫째, 검색 노출이 필요하니 열어둔다. 둘째, 내 글을 무단 학습에 쓰는 것이 싫으니 막는다. 문제는 이 둘이 같은 스위치에 묶여 있을 때다. 내 글이 검색되고 인용되는 것은 원하지만, 그 글이 영구적으로 모델 학습 데이터로 흡수되는 것은 원하지 않을 수 있다. 누군가의 브라우저 에이전트가 내 페이지를 한 번 읽고 예약이나 비교를 돕는 것은 괜찮지만, 같은 봇이 폼 제출이나 결제 흐름까지 자동으로 밟는 것은 싫을 수 있다.

Cloudflare는 이 차이를 Search, Agent, Training이라는 세 가지 행동으로 나눴다.[1]

• Search: 콘텐츠를 수집하거나 색인해 나중에 질문에 답하는 데 쓴다.
• Agent: 사람을 대신해 실시간으로 웹 애플리케이션을 방문하고 어떤 일을 처리한다.
• Training: 콘텐츠를 가져가 모델을 훈련하거나 fine-tune하는 데 쓴다.

이 분류가 실무적으로 유용한 이유는 간단하다. “AI”라는 말 하나로는 정책을 만들 수 없기 때문이다. 검색엔진도 AI를 쓴다. 브라우저 자동화도 AI를 쓴다. 학습 크롤러도 AI 회사가 운영한다. 이름은 비슷하지만 내 사이트에 남기는 흔적과 위험은 다르다.

Search는 발견성, Training은 재사용 권리, Agent는 행동 권한이다

세 분류를 더 쉽게 말하면 이렇게 나눌 수 있다.

분류	사이트 입장에서 받는 질문	대표적인 판단 기준
Search	“내 콘텐츠가 검색·답변에서 발견되어도 되는가?”	유입, 인용, 브랜드 노출, referral 기대
Training	“내 콘텐츠가 모델 안에 흡수되어 재사용되어도 되는가?”	저작권, 보상, 경쟁 서비스 재사용, 영구 보존
Agent	“사람을 대신한 자동 브라우저가 지금 내 사이트에서 행동해도 되는가?”	로그인, 폼 제출, 예약, 결제, rate limit, 남용

Search는 SEO와 GEO 관점에서 완전히 막기 어렵다. 특히 개인 블로그나 작은 서비스는 “찾히는 것” 자체가 큰 가치다. AI 답변 엔진이 글을 인용해 독자를 보내준다면, 운영자에게 돌아오는 이익이 있다.

Training은 성격이 다르다. 한 번 가져간 데이터가 모델 개선에 쓰이면, 원문 페이지로 돌아오는 흐름이 약하거나 없을 수 있다. 글쓴이는 트래픽을 받지 못하고, 콘텐츠만 사라지는 느낌을 받을 수 있다. Cloudflare가 작년부터 “Content Independence Day”라고 부른 맥락도 여기에 있다.[1]

Agent는 또 다르다. 브라우저를 움직이는 AI 에이전트가 사람을 대신해 페이지를 읽는 것까지는 검색과 비슷해 보일 수 있다. 하지만 장바구니에 담고, 버튼을 누르고, 예약을 만들고, 폼을 제출하기 시작하면 보안·운영 문제가 된다. 좋은 Agent 트래픽도 있다. 접근성 보조, 개인 비서, 구매 비교, 예약 대행은 사용자에게 편하다. 그렇지만 운영자는 어느 지점부터 사람 확인을 요구할지 정해야 한다.

9월 15일 기본값 변경에서 봐야 할 것

Cloudflare는 2026년 9월 15일부터 새로 Cloudflare에 온보딩되는 도메인에 대해, 광고가 표시되는 페이지에서는 Training과 Agent를 기본 차단하고 Search는 기본 허용한다고 설명했다.[1][3]

여기서 핵심은 “Cloudflare가 모든 AI를 막는다”가 아니다. 오히려 반대에 가깝다. Search는 남겨두고, 광고 페이지처럼 사람의 방문 자체가 수익 모델인 영역에서는 Training과 Agent를 더 조심하겠다는 방향이다.

또 하나 중요한 변화는 다목적 크롤러다. 하나의 크롤러가 Search와 Training을 동시에 한다면, 사이트 운영자가 Training 차단을 선택했을 때 가장 제한적인 규칙이 적용될 수 있다고 Cloudflare는 설명한다.[1][3] 봇 운영자에게 “검색용, 학습용, 에이전트용을 명확히 나눠 달라”는 압박이 생기는 셈이다.

이 변화는 작은 블로그에도 의미가 있다. seonoh.dev 같은 개인 기술 블로그는 검색과 AI 인용으로 발견되는 것이 중요하다. 동시에 글 전체가 아무 조건 없이 학습 재료로만 소비되는 것은 별개의 문제다. 따라서 “AI 봇 허용”을 한 줄로 정하기보다 아래처럼 정책을 나누는 편이 낫다.

페이지	Search	Agent	Training	이유
공개 블로그 글	허용	제한적 허용	선택적으로 제한	발견성과 인용은 필요하지만 학습 재사용은 별도 판단
포트폴리오·소개	허용	허용 또는 모니터링	제한	브랜드 노출은 중요, 대량 복제는 불필요
관리자·미리보기	차단	차단	차단	인증 전제 영역. 검색·학습·자동 행동 모두 불필요
결제·폼 제출	제한	승인·rate limit	차단	에이전트 자동 행동은 남용 방지와 사람 확인 필요
광고·유료 콘텐츠	허용 또는 제한	제한	제한	사람 방문과 보상이 핵심인 영역

robots.txt만으로 충분하지 않은 이유

robots.txt는 여전히 중요하다. 크롤러에게 “어디를 읽어도 되는지”를 알리는 가장 오래된 약속이기 때문이다. 하지만 AI 트래픽 정책을 robots.txt 하나로 끝내기에는 부족한 부분이 있다.

첫째, 모든 봇이 정직하게 따르지 않는다. 둘째, Search와 Training을 같은 user agent가 동시에 수행하면 운영자가 의도를 구분하기 어렵다. 셋째, Agent는 색인 크롤러가 아니라 실시간 브라우저 방문처럼 보일 수 있다. 넷째, 로그인 뒤 행동, 폼 제출, 결제, API 호출은 robots 규칙보다 애플리케이션 권한과 rate limit의 문제다.

Cloudflare의 접근이 흥미로운 이유는 그래서다. “AI 봇”이라는 이름표가 아니라 행동 기준으로 분류하겠다고 한다.[2] 사이트 운영자도 같은 방식으로 생각하면 된다.

• 이 요청은 나중에 답변하기 위한 색인인가?
• 이 요청은 지금 누군가를 대신해 행동하는가?
• 이 요청은 내 콘텐츠를 모델 학습에 흡수하려는가?
• 이 요청이 실패하거나 남용되면 누구에게 비용이 생기는가?

답이 다르면 정책도 달라야 한다.

개인 사이트 운영자가 오늘 바꿀 수 있는 것

Cloudflare를 쓰고 있다면 먼저 Security 설정에서 AI bot traffic 관련 옵션을 확인한다.[1][3] Cloudflare를 쓰지 않더라도 정책표는 만들 수 있다. 중요한 건 “우리는 AI를 허용한다/차단한다”가 아니라 페이지와 목적별로 나누는 것이다.

내가 지금 개인 사이트라면 이렇게 시작하겠다.

1. 공개 글은 Search 친화적으로 유지한다.
   제목, 요약, canonical, sitemap, structured data, llms.txt 같은 발견성 장치를 유지한다. AI 답변에 인용될 가능성을 완전히 버리지 않는다.

2. Training은 별도 의사결정으로 둔다.
   모든 글을 막을지, 일부만 허용할지, 향후 pay-per-crawl이나 content signal을 볼지 정책을 적어둔다. “검색에 나오고 싶다”와 “학습에 쓰이고 싶다”를 같은 답으로 처리하지 않는다.

3. Agent는 행동 권한 기준으로 본다.
   읽기만 하는 Agent는 허용해도, 제출·예약·구매·삭제·업로드는 사람 확인이나 rate limit을 둔다. 브라우저 자동화가 들어오는 순간 일반 크롤러가 아니라 사용자 행동 대행자다.

4. 관리자·미리보기·파일 전송 영역은 닫는다.
   공개 콘텐츠와 운영 도구를 섞지 않는다. 관리자페이지, preview URL, transfer manifest, 배포 로그는 검색과 학습 어느 쪽에도 필요 없다.

5. 로그에서 분리해 본다.
   모든 bot hit를 하나의 숫자로 보지 말고 검색, 에이전트, 학습, 일반 자동화, 인간 방문을 가능한 한 나눠 본다. 분리해서 봐야 “막아서 손해 본 트래픽”과 “막아서 줄인 위험”을 구분할 수 있다.

seonoh.dev에 적용하면 이렇게 본다

이 사이트는 글을 쓰고, 검색되고, AI 답변에 인용되는 것이 목적이다. 그래서 Search를 막는 것은 마지막 선택에 가깝다. 오히려 구조화 데이터, canonical, sitemap, FAQ, 명확한 정의 문장으로 검색과 GEO를 계속 챙기는 편이 맞다.

하지만 Training과 Agent는 별개다.

Training은 글의 원문을 모델 학습에 쓰는 문제다. 공개 글이라고 해서 무조건 학습 재사용까지 동의한다는 뜻은 아니다. 특히 직접 실험하고 정리한 운영 체크리스트, 실패 기록, 배포 런북은 단순한 뉴스 요약보다 재사용 가치가 크다. 앞으로는 글 유형별로 허용 범위를 다르게 둘 수 있다.

Agent는 더 실무적이다. 누군가의 AI 에이전트가 글을 읽고 요약하는 것은 괜찮다. 하지만 댓글, 문의, 관리자 전송, 파일 업로드, 결제, 예약 같은 쓰기 행동을 대신하려 한다면 다른 규칙이 필요하다. 여기서는 봇 분류보다 애플리케이션 권한, CSRF, rate limit, 인증, 감사 로그가 먼저다.

내 기준의 기본 정책은 이렇다.

공개 글 / 포트폴리오
- Search: 허용
- Agent: 읽기 중심 허용, 쓰기 행동은 서비스별 권한으로 제한
- Training: 기본 제한 또는 별도 신호 검토

관리자 / preview / 업로드 / 배포 산출물
- Search: 차단
- Agent: 차단
- Training: 차단

문의 / 폼 / 액션
- Search: 불필요
- Agent: rate limit + 사람 확인 + 서버 검증
- Training: 차단

독자가 오늘 적용할 1가지

오늘 하나만 한다면, 아래 표를 자기 사이트 기준으로 채우면 된다.

내 페이지	Search 허용?	Agent 허용?	Training 허용?	이유
홈
블로그 글
문서/가이드
로그인 뒤 화면
결제/폼 제출

이 표를 채우면 “AI 봇을 막을까?”라는 큰 질문이 작아진다. 검색은 열되 학습은 제한할 수 있고, 읽기 Agent는 허용하되 쓰기 행동은 막을 수 있다. 이 구분이 있으면 robots.txt, Cloudflare 설정, 애플리케이션 권한, 로그 분석을 같은 방향으로 맞출 수 있다.

FAQ

Cloudflare가 AI 봇을 전부 막는다는 뜻인가?

아니다. Cloudflare의 설명은 더 세밀한 분류에 가깝다. Search, Agent, Training을 나눠 관리하고, 새 도메인의 광고 표시 페이지에서는 Training과 Agent를 기본 차단하되 Search는 기본 허용하는 방향이다.[1][3]

Search와 Training은 왜 분리해야 하나?

Search는 내 콘텐츠를 발견하게 만들고 방문자나 인용을 돌려줄 수 있다. Training은 콘텐츠가 모델 개선에 흡수되는 문제라 보상, 저작권, 장기 재사용 논점이 생긴다. 둘을 같은 크롤러가 수행하면 사이트 운영자는 허용 기준을 정하기 어렵다.

Agent 트래픽은 좋은 것인가 나쁜 것인가?

둘 다 가능하다. 개인 비서나 접근성 도구처럼 사람에게 도움이 되는 Agent도 있다. 하지만 로그인, 제출, 예약, 결제, 삭제 같은 행동을 자동으로 수행하면 남용과 책임 문제가 생긴다. 그래서 Agent는 “읽기”와 “쓰기”를 나눠 봐야 한다.

robots.txt만 설정하면 끝인가?

아니다. robots.txt는 중요한 신호지만 강제 보안 장치는 아니다. 정직한 크롤러에게는 방향을 줄 수 있지만, 로그인 뒤 행동이나 폼 제출, 관리자 접근, rate limit 같은 문제는 애플리케이션 권한과 서버 검증으로 다뤄야 한다.

작은 블로그도 이런 정책표가 필요한가?

필요하다. 작을수록 기본값을 한 번 정해두면 이후 자동화가 쉬워진다. 공개 글은 Search를 허용하고, preview·관리자·업로드 영역은 닫고, Training은 별도로 판단한다는 정도만 적어도 다음 설정 변경 때 흔들리지 않는다.

Sources

[1] https://blog.cloudflare.com/content-independence-day-ai-options/ — Your site, your rules: new AI traffic options for all customers
[2] https://developers.cloudflare.com/bots/concepts/bot/#ai-bots — Cloudflare bot solutions docs: AI bots classification
[3] https://developers.cloudflare.com/changelog/post/2026-07-01-ai-traffic-options/ — New options to manage AI traffic