Cloudflare의 AI 학습 차단, 검색 노출과 모델 학습을 분리하다

Cloudflare가 동일한 크롤러의 모델 학습은 거부하면서도 검색 색인은 유지할 수 있도록 설계된 새로운 제어 기능인 Disallow AI Training을 출시했다. 지금까지 퍼블리셔는 여러 용도로 쓰이는 봇을 다룰 때 두 목적을 모두 허용하거나 크롤러를 완전히 차단해야 하는 거친 선택지에 놓이는 경우가 많았다.

이번 변경은 Cloudflare가 복합 용도 크롤러로 분류하는 Applebot, Googlebot, Bingbot에 적용된다. 이들 각각은 검색 및 AI 관련 용도를 지원할 수 있기 때문이다. Cloudflare는 운영사가 제어 기능, 보고 체계, 그리고 학습 거부가 기존 검색 노출을 낮추지 않는다는 보장을 제공할 경우 이러한 봇을 이제 “Accountable”로 부른다.

이 지정은 Cloudflare, Apple, Google, Microsoft 간의 공통 운영 모델을 구축한다. 다만 구속력 있는 기술 표준을 만드는 것은 아니다. 새 시스템은 대시보드 제어 기능, robots.txt 지침, 기업의 약속, 그리고 다른 학습용 크롤러에 대한 Cloudflare의 차단 조치를 결합한다.

이것이 핵심적인 절충점이다. 퍼블리셔는 검색에서 사라지지 않고도 더 간단하게 동의 여부를 표현할 수 있게 되지만, 보호의 상당 부분은 여전히 크롤러 운영사가 그 선택을 존중하는 데 달려 있다.

Cloudflare Disallow AI Training이 기본 선택을 바꾼다

Cloudflare는 하나로 묶여 있던 차단 결정을 검색, 학습, 사용자 지시형 에이전트를 위한 별도의 선택지로 전환하고 있다.

Cloudflare의 AI 크롤러 제어 기능은 모든 AI 관련 요청을 동일하게 취급하지 않고, 행동에 따라 자동화 활동을 분류한다. 검색 크롤러는 색인을 구축하고, 학습 크롤러는 모델 개발을 위한 자료를 수집하며, 에이전트는 사용자를 대신해 페이지를 가져온다.

이러한 분류는 경제적 효과가 서로 다르기 때문에 중요하다. 검색 엔진은 일반적으로 사용자를 원래 웹사이트로 보낼 수 있는 링크를 표시한다. 학습 과정은 즉각적인 방문을 만들어내지 않은 채 정보를 흡수할 수 있다. 에이전트는 사용자가 페이지를 열지 않아도 그 내용을 가져와 전달할 수 있다.

하나의 크롤러는 둘 이상의 범주에 속할 수 있다. Googlebot, Applebot, Bingbot이 중요한 사례인데, 이들의 검색 기능 때문에 퍼블리셔가 차단하기 어렵다. 이들의 접근을 제거하면 결국 색인 생성, 최신성, 검색 노출에 영향을 줄 수 있다.

Cloudflare의 이전 제어 기능은 일부 학습 차단에서 복합 용도 크롤러를 제외함으로써 이 문제를 수용했다. 검색 노출은 보호했지만, 퍼블리셔는 같은 설정을 통해 학습 기능만 직접 거부할 방법이 없었다.

새로운 크롤러 제어 모델은 Disallow AI Training을 중간 선택지로 도입한다. robots.txt를 통해 학습 금지 선호를 게시하고, Accountable 복합 용도 크롤러에는 검색 접근을 유지하며, 학습과 연관된 다른 크롤러는 차단한다.

Cloudflare에 따르면 Amazon, Anthropic, Meta, OpenAI가 운영하는 학습 전용 크롤러는 별도의 검색 크롤러에 영향을 주지 않고 차단할 수 있다. 이들 기업은 목적별로 서로 다른 봇을 사용하므로 네트워크 수준에서 더 직접적으로 집행할 수 있다.

Cloudflare는 더 강력한 설정의 의미도 바꾸고 있다. 이제 “Block”과 “Block on pages with ads”는 Googlebot, Applebot, Bingbot을 포함한 복합 용도 크롤러에도 적용된다. 따라서 두 옵션 가운데 하나를 선택하면 학습뿐 아니라 검색에도 영향을 줄 수 있다.

이 차이로 인해 설정의 중요성이 커진다. Disallow AI Training은 검색 접근을 유지하면서 제한적인 선호를 전달한다. 반면 Block은 특정 요청이 검색 또는 학습을 지원하는지와 관계없이 크롤러 자체를 거부한다.

기존 설정은 새 제어 기능으로 이전되고 있다. 이전에 일반 AI 차단 옵션을 사용하던 도메인은 일반적으로 검색 접근을 유지하는 동시에 학습 선호가 Disallow AI Training으로 옮겨진다. 기존의 세부 정책을 보유한 도메인 역시 실질적인 선택 사항이 이어진다.

새로운 광고 기반 도메인에는 검색 허용, 학습 거부, 광고가 표시되는 페이지에서 에이전트 차단을 권장한다. 광고가 없는 신규 도메인에는 세 범주를 모두 허용하는 덜 제한적인 권장 설정이 적용된다.

이 사전 설정은 영구적인 규칙이 아니라 권장 사항이다. 사이트 소유자는 온보딩 과정에서 또는 이후 Security Settings를 통해 변경할 수 있다. 제어 기능은 모든 Cloudflare 요금제에서 제공되며 도메인 단위로 작동한다.

그 결과 의사결정 체계가 더 명확해진다. 퍼블리셔는 일반적인 색인을 허용하고, 학습은 거부하며, 에이전트에는 별도 정책을 선택할 수 있다. 이 구조는 자동화 시스템이 이제 웹사이트와 상호작용하는 방식을 더 잘 반영한다.

또한 잘못된 설정을 진단하기도 쉬워진다. 퍼블리셔가 Block을 선택한 뒤 크롤러 접근을 잃는다면, 그 결과는 선택한 설정에서 직접 비롯된 것이다. Disallow AI Training은 검색을 유지하면서 모델 개발용 사용만 거부하려는 더 좁은 목적을 위해 마련됐다.

이는 단순히 이름만 바꾼 봇 스위치가 아니다. 제어 단위를 크롤러의 신원만이 아니라 신원, 공개된 목적, 운영사 행동의 조합으로 바꾼다.

복합 용도 크롤러가 퍼블리셔를 압박하는 이유

가치 있는 검색 트래픽을 제공하는 크롤러가 전혀 다른 상업적 목적을 위해 자료를 수집할 수도 있기 때문에 갈등이 발생한다.

오픈 웹의 전통적인 교환 구조는 비교적 이해하기 쉬웠다. 퍼블리셔는 검색 엔진이 페이지를 크롤링하도록 허용했고, 검색 엔진은 링크, 발췌문, 잠재적 방문자를 돌려줬다. 광고, 구독, 판매, 독자와의 관계는 그중 일부 사용자가 실제로 유입되는 데 의존했다.

생성형 AI는 이 교환 구조를 복잡하게 만든다. 모델은 학습 중에 수집한 자료를 활용할 수 있으며, AI 답변은 독자가 인용된 출처를 방문하기 전에 질의를 해결할 수 있다. 따라서 검색, 모델 개발, 답변 생성은 서로 다른 형태의 가치를 만든다.

Cloudflare 자체 측정치는 퍼블리셔가 우려하는 이유를 보여준다. 회사는 12개월 동안 분류된 AI 크롤링의 80%가 학습 목적이었다고 보고했다. 이어진 6개월 관측에서는 학습의 비중이 82%로 상승했고, 검색은 15%, 사용자 행동은 3%를 차지했다.

이 수치는 전체 웹이 아니라 Cloudflare가 관찰하고 분류한 트래픽을 설명한다. 그럼에도 학습 활동이 콘텐츠 제공자에게 도달하는 자동화 수요를 지배할 수 있음을 보여준다.

퍼블리셔가 학습 전용 크롤러를 차단할 때는 비교적 관리 가능한 판단을 내릴 수 있다. 주요 검색 색인기를 제거하지 않고도 원치 않는 수집을 멈출 수 있기 때문이다. GPTBot과 OAI-SearchBot처럼 구분된 봇은 이러한 목적을 더 쉽게 분리한다.

복합 용도 크롤러는 더 어려운 문제를 만든다. 동일한 크롤러가 검색과 학습을 모두 지원한다면, 인프라 수준의 차단은 콘텐츠가 운영사에 도달한 뒤 어떻게 사용될지 판단할 수 없다. 접근을 차단하면 자료는 보호되지만 검색 기능도 사라진다.

접근을 허용하면 발견 가능성은 유지되지만, 이후 사용을 제한할 다른 장치가 필요하다. Cloudflare Disallow AI Training 설정은 바로 이 공백을 메우려는 시도다.

Cloudflare는 robots.txt에 배치하는 제안 어휘인 Content Signals로 이 공백을 해결하기 시작했다. 콘텐츠 신호 정책은 search, ai-input, ai-train이라는 세 가지 선언된 용도를 구분한다.

검색 신호는 색인화와 기존 검색 결과를 다룬다. AI가 생성한 요약은 포함하지 않는다. ai-input 신호는 검색 및 근거 제공을 포함한 AI 시스템의 실시간 사용과 관련된다. ai-train 신호는 모델 학습과 미세 조정을 다룬다.

따라서 사이트는 search=yes와 ai-train=no를 게시할 수 있다. 소유자가 생성형 답변이 콘텐츠를 어떻게 사용해야 하는지 결정하지 않았다면 ai-input은 지정하지 않을 수 있다.

이 분리는 누락된 선호가 허용이나 거부로 해석되어서는 안 되기 때문에 중요하다. Cloudflare의 정책은 퍼블리셔의 의도를 추측하지 않고 생략된 신호를 중립으로 취급한다.

그러나 Content Signals는 선호의 표현이다. 스크레이퍼가 페이지를 내려받는 일을 물리적으로 막는 장벽은 아니다. Cloudflare는 기술적 집행이 필요할 경우 퍼블리셔가 이러한 신호를 봇 제어 기능이나 방화벽 규칙과 결합해야 한다고 이전에 조언했다.

새로운 Accountable 지정은 이러한 계층을 연결하려 한다. 이는 Cloudflare가 특정 제어 기능과 투명성을 제공하거나 제공하겠다고 약속했다고 설명하는 크롤러 운영사를 식별한다. 요구 사항에는 학습 거부, AI 요약 거부, URL 수준 가시성, 기존 검색 순위 보호가 포함된다.

Apple, Google, Microsoft는 현재 기능과 기한이 정해진 약속을 서로 다르게 조합해 이 기준을 충족한다. 이 지정이 이들의 구현이 동일하다는 뜻은 아니다. 각 운영사가 동일한 기본 책임을 받아들였다고 Cloudflare가 판단한다는 의미다.

이는 다른 크롤러 운영사에도 압박을 만든다. 폭넓은 접근을 원하는 기업은 이제 동의, 검사, 검색 중립성에 대한 공개 기준과 비교될 수 있다. 봇 신원을 분리하는 방식은 여전히 이 기준을 충족하는 한 방법이지만, 더는 유일한 경로가 아니다.

퍼블리셔에게도 새로운 운영상 책임이 생긴다. 검색 노출, AI 학습, 답변 생성, 에이전트 접근에는 이제 각각 별도의 정책이 필요하다. 하나의 “AI 차단” 결정으로는 더 이상 사업상 절충점을 포착할 수 없다.

페이지 조회 수로 운영되는 뉴스 사이트는 광고 페이지에서 학습과 에이전트 접근을 모두 거부할 수 있다. 소매업체는 규모가 더 작더라도 질 높은 AI 유입을 가치 있게 볼 수 있다. 문서화 사이트는 장기적인 모델 학습은 거부하면서 실시간 AI 검색을 환영할 수 있다.

더 이상 중요한 질문은 AI 봇이 좋은지 나쁜지가 아니다. 어떤 사용이 접근을 정당화하는지, 퍼블리셔에게 어떤 가치가 돌아오는지, 그리고 그 사용을 검증할 수 있는지다.

Apple, Google, Microsoft는 모델을 공유하지만 구현은 하나가 아니다

세 기업은 같은 원칙을 지지하지만, 제어 기능의 기술적 완성도는 여전히 고르지 않고 도입 시점도 다르다.

Apple은 이미 Applebot-Extended를 통해 퍼블리셔가 학습을 다룰 수 있도록 한다. 사이트 소유자는 robots.txt에서 해당 사용자 에이전트를 허용하지 않으면서 Applebot의 일반 검색 기능은 계속 허용할 수 있다.

Apple 문서에 따르면 Applebot-Extended 선호는 사이트가 검색 결과에 표시되는 방식에 영향을 주지 않는다. 또한 nosnippet 및 유료 콘텐츠 라벨을 포함해 생성형 출력과 관련된 페이지 수준 메커니즘도 지원한다.

이 도구들은 아직 Cloudflare의 Accountable 프레임워크에 포함된 모든 요소를 제공하지는 않는다. Cloudflare에 따르면 Apple에는 이 목적을 위한 URL 수준 검사가 없다. Apple은 내년 제공이 예상되는 개발 중 솔루션의 세부 사항을 공유한 것으로 알려졌다.

따라서 현재의 Applebot 제어 기능은 검색과 학습을 실질적으로 분리하지만, 접근 이후 어떤 일이 발생했는지에 대한 가시성은 불완전하다. Cloudflare는 이 격차를 해소하겠다는 약속을 받아들이고 있다.

Google은 유사한 확장 모델을 사용한다. 퍼블리셔는 Googlebot을 차단하지 않고 Google-Extended를 차단할 수 있다. Google-Extended는 항상 자체 요청을 보내는 별도 크롤러가 아니라, 특정 생성형 AI 사용을 관리하는 제어 토큰이다.

이 세부 사항은 중요하다. Googlebot은 여전히 검색을 위해 콘텐츠를 가져올 수 있으며, Google은 Google-Extended 선호를 활용해 해당 자료가 적용 대상 AI 시스템을 지원할 수 있는지 결정한다. 퍼블리셔는 별도의 네트워크 신원이 아니라 정책을 통해 이후 사용을 제어한다.

Google은 Google-Extended를 통한 옵트아웃이 Google Search의 포함 여부나 순위에 영향을 미치지 않는다고 말합니다. 학습 옵트아웃 안내에는 Googlebot과 Google-Extended의 관계가 문서화되어 있습니다.

Google은 생성형 검색 경험과 관련된 검색 성과 보고 및 제어 기능도 제공합니다. Cloudflare는 Google이 Google-Extended와 연계한 추가 URL 수준 투명성 기능을 개발 중이며, 수주 내 출시될 것으로 예상된다고 밝혔습니다.

이 특정 메커니즘에서 Microsoft는 세 곳 중 가장 미흡합니다. Bing은 세분화된 웹마스터 제어 기능을 지원하며, 게시자는 NOARCHIVE 메타 태그를 사용해 캐시되거나 표시되는 콘텐츠의 일부 활용을 제한할 수 있습니다.

Microsoft는 NOARCHIVE가 검색 순위에서 페이지를 제거하지는 않는다고 말합니다. 사이트 소유자는 Bing Webmaster Tools를 통해 콘텐츠 삭제와 URL 관리도 할 수 있습니다.

그러나 Bingbot은 아직 robots.txt를 통한 Cloudflare의 도메인 수준 학습 거부 선호를 자동으로 준수하지 않습니다. Cloudflare는 Microsoft가 이 기능을 2027년 초 도입 목표로 개발하고 있다고 밝혔습니다.

그때까지는 Disallow AI Training을 선택해도 새로운 워크플로를 통해 의도한 제한이 Bing에 자동으로 전달되지는 않습니다. 즉시 Bing 제한을 원하는 게시자는 여전히 Microsoft의 기존 도구와 페이지 수준 메타데이터를 사용해야 합니다.

Microsoft는 AI 제어 옵션을 생성형 경험에서 콘텐츠가 표시되는 방식을 제한하면서도 검색 발견 가능성을 유지하는 방법으로 설명해 왔습니다. 그러나 Cloudflare의 통합 스위치는 현재 이러한 제어 기능과 완전히 연결되어 있지 않습니다.

이 구현상의 공백은 이번 출시에서 가장 중요한 유의점입니다. Cloudflare는 Applebot, Googlebot, Bingbot을 하나의 Accountable 라벨 아래 제시하지만, 현재 학습 선호를 위한 특정 확장 사용자 에이전트 경로를 제공하는 곳은 Apple과 Google뿐입니다.

Microsoft의 포함은 부분적으로 오래된 약속에 기반합니다. 협력적 표준을 마련하는 데는 합리적일 수 있지만, 게시자는 현재 이용 가능한 집행과 향후 약속된 호환성의 차이를 이해해야 합니다.

공유 모델은 각 운영자가 학습을 어떻게 해석하느냐에도 좌우됩니다. 새 모델의 사전 학습, 기존 시스템의 미세 조정, 실시간 답변의 근거 제공, 검색 요약 생성은 서로 별개의 활동입니다. “학습 금지” 선택이 AI 매개 활용 전체를 반드시 거부하는 것은 아닙니다.

Cloudflare는 AI 입력과 AI 요약을 명시적으로 서로 다른 문제로 취급합니다. 이는 하나의 선호가 관련 없는 활용까지 묵시적으로 포괄하지 않도록 하지만, 동시에 새 제어 기능이 단순한 대시보드 라벨이 시사하는 것보다 범위가 좁다는 뜻이기도 합니다.

게시자는 모델 학습을 거부하면서도 AI 생성 검색 요약의 대상이 될 수 있습니다. 또 다른 게시자는 학습은 허용하면서 운영자별 요약 제어 기능을 사용할 수 있습니다. 이러한 선택은 서로 다른 트래픽 및 출처 표시 결과를 낳을 수 있습니다.

따라서 Accountable 프레임워크는 최소한의 계약으로 이해하는 것이 가장 적절합니다. 이는 운영자에게 목적을 구분하고, 선호를 준수하며, 검사 기능을 제공하고, 기존 검색에서 학습 거부를 불이익으로 이어지게 하지 말 것을 요구합니다.

이는 Apple, Google, Microsoft를 기술적으로 상호 대체 가능한 존재로 만들지는 않습니다. 또한 이들 기업이 제공하는 모든 AI 기능이 동일한 옵트아웃 범위에 포함된다는 보장도 아닙니다.

즉각적인 가치는 통합에서 나옵니다. Cloudflare 고객은 하나의 장소에서 공통 선호를 표시할 수 있고, 각 운영자는 이를 기존 또는 향후 제어 기능에 매핑합니다.

장기적 가치는 이러한 매핑이 게시자가 URL 수준에서 감사할 수 있을 만큼 투명해지는지에 달려 있습니다.

이 설정은 동의 신호일 뿐, 준수의 증거는 아니다

Cloudflare는 지침을 간소화했지만, 사이트가 해당 지침을 게시했다는 이유만으로 모든 후속 활용이 중단됐음을 증명할 수는 없습니다.

이 한계는 robots.txt에서 시작됩니다. 이 파일은 접근 제어 시스템이 아니라 자발적 크롤러 프로토콜로 설계되었습니다. 규정을 준수하는 크롤러는 이를 읽고 행동을 조정합니다. 이를 무시하는 운영자는 다른 제어 기능이 트래픽을 차단하지 않는 한 공개적으로 이용 가능한 페이지를 계속 요청할 수 있습니다.

Cloudflare는 크롤러를 인식할 수 있을 때 네트워크 엣지에서 결정을 집행할 수 있습니다. 따라서 차단은 선호 신호보다 더 강력합니다. 다만 집행은 신뢰할 수 있는 식별에 달려 있으며, 사용자 에이전트 문자열은 관련 없는 봇이 복제할 수 있습니다.

검증된 봇 프로그램은 운영자가 제공한 정보와 요청 출처를 대조해 이러한 위험을 줄입니다. 암호학적 인증은 더 강력한 증명을 제공할 수 있지만, 크롤러 시장 전반에서의 도입은 아직 불완전합니다.

검증된 요청조차 누가 페이지를 가져갔는지는 보여주지만, 그 콘텐츠의 이후 모든 활용까지 드러내지는 않습니다. 크롤러 운영자는 검색 색인화, 모델 학습, 답변 생성 및 기타 처리 사이에 내부적 분리를 유지해야 합니다.

Cloudflare의 Accountable 요구사항은 보고 및 약속을 통해 이러한 신뢰 공백을 다룹니다. URL 수준 가시성은 게시자가 어떤 페이지가 학습에 제공됐는지, 그리고 콘텐츠가 검색에서 어떻게 표시됐는지 확인하는 데 도움이 될 것입니다.

핵심 단어는 “도움이 될 것”입니다. Apple의 검사 시스템은 아직 개발 중이고, Google의 추가 도구는 출시 예정이며, Microsoft의 도메인 수준 robots.txt 지원은 2027년 초를 목표로 하고 있습니다.

따라서 이 지정은 현재 기능과 미래의 약속을 결합합니다. Cloudflare는 네 가지 요구사항 모두가 오늘날 동일한 프로덕션 구현을 갖췄다고 주장하는 것은 아닙니다.

게시자는 “Disallow AI Training”을 보편적인 법적 해결책으로 해석해서도 안 됩니다. 저작권 예외, 계약 조건, 관할권 차이, 과거 수집은 별개의 문제로 남습니다. 새로운 선호는 기존 모델에서 자료를 소급해 제거할 수 없습니다.

이 설정은 참여 운영자와 Cloudflare가 구현한 범위에서 향후 크롤러 행동을 규율합니다. 이전에 수집된 사본이 삭제됐음을 확인하지는 않습니다. 또한 학습된 모델이 정보를 보존하거나 재현할 수 있는 방식을 규정하지도 않습니다.

또 다른 불확실성은 분류와 관련됩니다. Cloudflare는 운영자 공개 정보와 기타 관찰된 정보를 일부 바탕으로 Search, Training, Agent 행동을 분류합니다. 크롤러의 표방 목적은 바뀔 수 있으며, 하나의 서비스가 여러 제품을 지원할 수도 있습니다.

분류가 제품 변경을 따라가지 못하면, 정책은 게시자가 예상하는 것보다 더 많은 활동을 허용할 수 있습니다. 초기 대시보드 설계만큼이나 투명한 변경 로그와 독립적 모니터링이 중요해질 것입니다.

AI 요약은 훨씬 더 큰 공백을 드러냅니다. 학습은 콘텐츠가 모델 개발에 기여하는지를 결정합니다. 요약은 최신 콘텐츠가 방문 필요성을 줄일 수 있는 답변으로 변환되는지를 결정합니다.

Cloudflare는 AI 요약이 이미 검색 행동에서 흔하다는 연구를 인용합니다. 한 검색 행동 연구는 AI 요약이 표시될 때 사용자가 결과 링크를 클릭할 가능성이 낮아졌다고 밝혔습니다.

이는 학습과 같은 문제가 아닙니다. 게시자는 학습을 성공적으로 거부하더라도 검색 제품이 새로 색인된 자료를 요약할 때 방문을 잃을 수 있습니다.

Cloudflare는 Accountable 운영자가 AI 요약 옵트아웃을 직접 제공해야 하며, 궁극적으로 Cloudflare를 통해서도 제공해야 한다고 말합니다. 다음 목표는 요약에 포함될 수 있는 콘텐츠의 양을 더 세분화해 제어하는 것입니다.

이 계획은 이분법적 동의의 약점을 인정합니다. 명확한 링크와 함께 짧은 인용을 허용하는 것은 원문을 대체하는 상세 답변을 허용하는 것과 다릅니다. 두 경우 모두 기술적으로는 요약 활용에 해당할 수 있습니다.

비즈니스 모델에 따라 허용 가능한 균형도 달라집니다. 광고 기반 게시자는 노출이 수익을 뒷받침하므로 방문량이 필요합니다. 소매업체는 AI 유입이 더 많은 구매를 유도한다면 방문 감소를 수용할 수 있습니다. 구독 기반 게시자는 단순 클릭 수보다 출처 표시와 독자 인지를 더 중시할 수 있습니다.

Cloudflare는 AI 유입이 기존 검색 유입보다 더 높은 전환율을 낼 수 있다는 제3자 추정치를 인용해 왔습니다. 이 수치는 데이터셋과 방법론에 따라 달라지므로, 손실된 트래픽을 보편적으로 상쇄하는 요소로 간주해서는 안 됩니다.

실제 측정 문제는 인과관계에 있습니다. 게시자는 어떤 크롤러가 URL에 접근했는지, 어떤 제품이 이를 사용했는지, 요약이 표시됐는지, 얼마나 많은 콘텐츠가 표시됐는지, 그리고 그 상호작용이 방문으로 이어졌는지를 알아야 합니다.

현재 대부분의 조직에는 이 전체 사슬이 없습니다. 서버 로그는 요청을 보여주고, 검색 콘솔은 노출과 클릭을 보여줍니다. 그러나 어느 것만으로는 콘텐츠가 AI 제품을 통해 어떻게 흘러갔는지 입증할 수 없습니다.

새 제어 기능은 완전한 책임성을 제공하기 전에 주체성을 개선합니다. 게시자가 더 좁은 정책을 선언하고 Accountable 예외에 해당하지 않는 크롤러에 더 강력한 차단을 적용할 수 있게 합니다.

모니터링의 필요성을 없애지는 않습니다. 게시자는 설정을 변경한 뒤 검색 노출 범위, 크롤러 로그, 유입 패턴, 주요 AI 제품의 공개 출력 결과를 점검해야 합니다.

연구, 문서화 또는 기관 지식을 관리하는 팀에게 크롤러 정책은 정보 거버넌스의 한 계층일 뿐입니다. 검색 가능한 지식 베이스는 외부 플랫폼이 공개 버전을 요약하더라도 내부에서 출처 맥락을 보존할 수 있습니다.

회의적인 결론은 명확합니다. Cloudflare는 신뢰할 만한 제어 표면을 만들었지만, 준수는 여전히 기술적 집행, 자발적 표준, 운영자 정책, 미래의 투명성으로 이루어진 체계입니다.

크롤러를 Accountable로 부르는 것은 기대되는 기준을 높입니다. 근본적인 신뢰 문제를 사라지게 하지는 않습니다.

새 모델의 작동 여부를 보여줄 세 가지 신호

다음 시험대는 더 많은 기업이 그 표현을 지지하는지가 아니라, Cloudflare의 공유 정책이 측정 가능한 행동을 만들어내는지 여부입니다.

첫 번째 신호는 Microsoft가 약속한 robots.txt 내 도메인 수준 학습 거부 선호 지원입니다. Cloudflare는 이 기능이 2027년 초를 목표로 하고 있다고 말합니다.

작동하는 구현은 세 가지 혼합 용도 크롤러 운영자 사이의 현재 최대 공백을 메울 것입니다. 별도의 NOARCHIVE 배포나 삭제 워크플로 없이도 동일한 Cloudflare 설정이 Bing에 학습 거부 의사를 전달할 수 있게 됩니다.

지연은 가장 중요한 참여자 중 하나가 여전히 수동 또는 페이지 수준 대안에 의존하게 되므로 Accountable 지정을 약화할 것입니다. 구현은 또한 어떤 Microsoft AI 활용이 “학습”에 속하고 어떤 활용이 별도 제어 기능의 적용을 받는지도 명확히 해야 합니다.

두 번째 신호는 Apple과 Google의 URL 수준 보고입니다. 게시자에게는 도메인 선호가 존재한다는 확인만으로는 충분하지 않습니다. 어떤 페이지가 접근됐는지, 어떤 활용이 허용됐는지, 그리고 선호가 이후 처리에 변화를 일으켰는지를 알아야 합니다.

Google-Extended와 관련한 Google의 출시 예정 기능은 초기 시험대가 됩니다. Apple의 계획된 검사 기능은 더 장기적인 시험대가 됩니다. 유용한 보고는 크롤러 접근을 검색 성과 및 AI 가시성과 비교할 수 있을 만큼 구체적이어야 합니다.

일반적인 대시보드 집계 수치는 제한적인 책임성만 제공합니다. 페이지 수준 기록, 이해하기 쉬운 목적 라벨, 안정적인 과거 데이터는 게시자가 정보에 기반한 결정을 내릴 수 있다는 Cloudflare의 주장을 강화할 것입니다.

세 번째 신호는 AI 요약 제어 기능에 대한 Cloudflare의 작업입니다. 학습 옵트아웃은 게시자 갈등의 한 부분만 해결합니다. 검색이 생성한 답변은 모델 학습 권한이 없더라도 트래픽에 영향을 줄 수 있습니다.

요약에 표시되는 콘텐츠의 양을 제어하려는 Cloudflare의 계획은 단순한 옵트아웃보다 더 야심 찬 접근입니다. 이를 위해서는 운영자가 공유 선호를 일관되게 해석하고, 게시자가 결과를 평가할 수 있을 만큼 충분한 데이터를 공개해야 합니다.

성공한다면 Cloudflare Disallow AI Training의 더 넓은 원칙, 즉 접근은 목적별로 구분되고 측정 가능하며 콘텐츠 소유자가 변경할 수 있어야 한다는 원칙도 강화될 것이다. 실패한다면 퍼블리셔는 모든 검색 및 AI 제공업체마다 분리된 제어 기능을 관리해야 하는 상황에 놓이게 된다.

오늘날의 실질적인 대응은 이번 출시를 한 번 설정해 두면 끝나는 보장이 아니라 정책 업그레이드로 보는 것이다. 사이트 소유자는 각 도메인에 이전된 설정을 검토해야 하며, 특히 이전에 포괄적인 AI 차단 옵션을 활성화했다면 더욱 그렇다.

Search가 계속 허용되는지, 그리고 Training이 이제 Block이 아닌 Disallow AI Training으로 표시되는지 확인해야 한다. 전체 Block을 선택하면 Applebot, Googlebot, Bingbot이 차단될 수 있으며, 이는 학습 거부 의사를 게시하는 것과는 다른 결과를 낳는다.

팀은 각 카테고리를 허용하거나 거부하는 이유도 문서화해야 한다. 검색, 학습, 에이전트는 서로 다른 목적을 수행하므로 정책은 사이트의 수익 모델과 이용자 관계를 반영해야 한다.

변경 후에는 크롤러 응답과 색인 생성을 모니터링해야 한다. 검색 노출 범위가 감소한다면 잘못된 설정을 선택했거나 다른 방화벽 규칙이 해당 선호 설정을 덮어쓰고 있음을 의미할 수 있다.

이 검토는 중요한 하위 도메인도 포함해야 한다. 문서, 지원 센터, 블로그, 애플리케이션 페이지는 동일한 상위 브랜드를 공유하더라도 서로 다른 구성 뒤에 있을 수 있다.

Cloudflare의 출시는 인위적인 이분법을 더 현실적인 선택지로 대체한다는 점에서 중요하다. 사이트가 일반적인 검색 색인에서 계속 노출되기 위해 모델 개발용 자료를 제공해야만 해서는 안 된다.

다만 이 시스템의 신뢰성은 검증 가능한 결과에서 나올 것이다. Microsoft는 통합을 완료해야 하고, Apple과 Google은 유용한 검사 기능을 제공해야 하며, Cloudflare는 요약 수준의 제어를 퍼블리셔가 측정할 수 있는 것으로 바꿔야 한다.

현재로서는 Cloudflare Disallow AI Training이 웹사이트 소유자에게 더 명확한 지침과 더 안전한 중간 경로를 제공한다. 다음 질문은 최대 규모의 크롤러 운영업체들이 그 지침을 신뢰할 수 있을 만큼 충분히 관찰 가능하게 만들 것인지다.

도메인의 세 가지 크롤러 정책을 검토하고, 의도한 결과를 기록하며, 변경 후 검색 노출 범위를 지켜보라. 트래픽은 안정적으로 유지되는 반면 학습 접근은 줄어든다면, 이 공동 모델은 첫 번째 실질적 시험을 통과한 셈이다.