AI 크롤러 트래픽은 모두 같지 않다: 웹사이트는 접근 범위를 어떻게 정해야 할까

웹사이트는 사용자에게 발견되기를 원하지만, 콘텐츠가 제한 없이 수집되는 것은 원하지 않습니다. 두 목표는 서로 충돌하지 않습니다. 문제는 모든 자동화된 방문에 "AI 크롤러"라는 꼬리표를 붙이는 순간, 선택지가 완전 개방 아니면 전면 차단으로 좁혀지기 쉽다는 점입니다.

더 유용한 구분은 특정 방문이 검색 색인 구축, 모델 학습, 사용자를 대신한 작업 수행 중 무엇을 목적으로 하는지 묻는 것입니다. 목적에 따라 얻는 이익, 부담, 필요한 통제 수단이 다릅니다. 이 글은 Cloudflare의 공개된 변경 사항을 살펴보며 콘텐츠 사이트와 제품 홈페이지가 이를 어떻게 판단할 수 있는지 논의합니다. 사실 확인은 2026년 9월 5일 기준이며, 실제 웹사이트 설정을 변경하는 내용은 다루지 않습니다.

2026년 9월 8일 검토 시점에도 Cloudflare의 공지와 설정 문서는 9월 15일을 향후 기본값 조정 일정으로 안내하고 있었습니다. 이 글은 최초 게시 시점과 당시 맥락을 그대로 유지합니다. 해당 날짜가 된 뒤 변경이 계획대로 적용되었는지는 공식 문서를 다시 확인해야 하며, 여기서 미리 단정할 수 없습니다.

AI 여부가 아닌 접근 목적으로 판단하기

Cloudflare는 2026년 7월 공지에서 AI 관련 트래픽을 Search, Agent, Training으로 더 세분화했습니다. Search는 이후 검색에 대비해 콘텐츠를 수집하거나 색인하는 용도이고, Agent는 사용자를 대신해 즉각적인 작업을 수행하는 데 초점을 맞추며, Training은 모델 학습이나 파인튜닝에 쓰입니다. 이는 Cloudflare의 제품 분류 체계이며, 인터넷 전반에 강제되는 표준이 아닙니다.

이 구분에 주목할 필요가 있는 이유는 하나의 공개 문서가 여러 역할을 할 수 있기 때문입니다. 검색 시스템은 나중에 다른 사람이 답을 찾도록 돕기 위해 문서를 읽고, 어시스턴트는 사용자가 지금 API를 디버깅하고 있어서 문서를 읽으며, 학습용 수집은 현재 방문자의 질문과 전혀 무관할 수 있습니다.

제품 홈페이지에서도 두 번째 유형의 방문이 본질적으로 가치 없는 것은 아닙니다. 개발자가 어시스턴트에게 파라미터의 의미를 물을 때, 어시스턴트가 버전이 정확한 문서에 접근할 수 있는지에 따라 사용자가 연동을 계속 진행할 수 있는지가 달라집니다. 이 가치가 곧바로 브라우저 클릭으로 나타나지 않을 수도 있습니다.

그렇다고 모든 에이전트에게 접근을 허용해야 한다는 뜻은 아닙니다. 방문이 허용된 용도에 맞는지, 인증이 필요한지, 비정상적인 부담을 주는지는 여전히 개별적으로 평가해야 합니다. 이름에 "AI"가 들어간 트래픽을 모두 고객 유치 기회로 보는 것은, 모두 가치 없는 트래픽으로 보는 것만큼이나 거친 판단입니다.

9월 15일 일정을 모든 웹사이트에 이미 적용된 것처럼 말할 수는 없다

Cloudflare 설정 문서에 따르면 2026년 9월 15일에 일부 기본 동작이 조정될 예정입니다. 새로 등록된 도메인에서는 학습 및 에이전트 트래픽이 기본적으로 차단되고 검색은 유지되며, 검색과 학습을 함께 수행하는 다목적 크롤러가 학습 차단 정책과 상호작용하는 방식도 업데이트됩니다.

이 설명에는 생략할 수 없는 단서가 여러 개 붙어 있습니다. 예정된 날짜, 새로 등록된 도메인, 적용 대상 페이지, 다목적 방문에 대한 규칙입니다. 검토 시점의 날짜는 아직 9월 5일이므로, 이를 "Cloudflare가 모든 웹사이트의 AI 접근을 차단했다"로 바꿔 말할 수 없습니다. 웹사이트의 최종 동작은 실제 설정과 이후 제품 업데이트에 따라 달라집니다.

관련 서비스를 사용한다면, 요약 기사가 얼마나 강한 제목을 썼는지보다 현재 계정 정책, 페이지 분류, 실제 접근 로그를 확인해야 합니다. 사이트 전체 스위치 하나가 여러 용도의 페이지에 동시에 영향을 줄 수 있으며, 다목적으로 분류된 방문자를 이름만 보고 허용된 것으로 가정할 수 없습니다.

저희는 이런 변경이 감정적으로 사이트 전체 설정을 전환할 일이 아니라 범위를 검토할 계기가 되어야 한다고 판단합니다. 먼저 발견되기를 원하는 콘텐츠를 나열한 다음, 현재 정책이 그 목표와 충돌하는지 확인하세요. 이 글은 특정 설정을 그대로 따라 하라고 권하지 않으며, 저희가 여러분의 계정을 점검했다는 뜻도 아닙니다.

robots.txt, 사용 선호, 실제 차단은 서로 다른 계층에서 작동한다

RFC 9309는 로봇 배제 규칙이 접근 인가 메커니즘이 아니라고 명시합니다. 이 규칙은 규칙을 준수하는 크롤러에게 사이트 접근 방식을 안내할 뿐, 로그인 자격 증명, 권한 검사, 서버 측 접근 제어를 대신할 수 없습니다.

따라서 기밀이 필요한 문서를 robots.txt만으로 숨겨서는 안 됩니다. 반대로 공개하려는 설명 문서는 robots.txt에서 크롤링을 허용해도 다른 네트워크나 애플리케이션 규칙에 의해 차단될 수 있습니다. 접근 가능 여부는 파일 하나에 의존하지 말고 실제 응답을 확인해 판단해야 합니다.

Cloudflare의 해당 공지는 현재 테스트 중인 콘텐츠 사용 선호 신호도 소개하며, 선호를 표현한다고 해서 바로 차단이 이루어지지는 않는다고 설명합니다. 웹사이트 운영자는 "내가 표현한 선호", "서비스가 적용한 규칙", "방문자가 실제로 한 행동"을 따로 기록해야 합니다. 신호를 제출했다고 해서 콘텐츠가 더 이상 학습되거나 재현되지 않는다는 보장은 없습니다.

이 글은 기술과 제품 범위를 다루며, 접근 설정을 콘텐츠 권리나 사용 라이선스에 대한 완전한 판단으로 보지 않습니다. 제한이 필요한 비공개 정보는 적절한 신원 및 권한 메커니즘으로 보호해야 하고, 공개 자료에는 명확한 버전 관리, 출처 표기, 사용 범위가 필요합니다.

읽혔다고 해서 인용된 것은 아니다

Google의 AI 검색 기능 문서는 여전히 기본 SEO를 강조합니다. 크롤링 가능성, 내부 링크를 통한 발견 가능성, 텍스트로 제공되는 핵심 콘텐츠, 페이지 본문과 일치하는 구조화된 데이터입니다. 관련 AI 검색 기능의 지원 링크로 표시되려면 페이지가 색인 생성 및 스니펫 표시 자격을 갖춰야 하지만, 요건을 충족한다고 해서 크롤링, 색인 생성, 표시가 보장되지는 않습니다.

따라서 서버 로그에 크롤러 요청이 나타났다는 것은 접근 이벤트가 발생했다는 뜻일 뿐입니다. 페이지가 검색 색인에 포함되었음을 증명하지 않으며, 특정 AI 응답이 그 콘텐츠를 사용했음은 더더욱 증명하지 않습니다. 응답에 브랜드가 언급되었다고 해서 출처 목록이 해당 페이지를 인용했다는 뜻도 아닙니다.

콘텐츠 팀에게 이 구분은 일상적인 평가 방식을 바꿉니다. 글을 새로 게시하면 먼저 공개 접근, 링크, 내용의 정확성을 확인하고, 이후 검색 시스템의 색인과 표시 여부를 검토할 수 있습니다. 처음부터 "AI가 인용했는가"를 유일한 검수 기준으로 삼으면 너무 일찍 실패로 판단하거나, 우연한 언급을 장기적인 성장으로 착각할 위험이 있습니다.

호출하는 쪽도 비슷한 문제를 겪습니다. 검색 매칭, 본문 읽기, 결론 검증은 서로 다른 단계입니다. 사이트의 에이전트 검색 도구 선택 가이드는 사용자 관점에서 이 구분을 설명하고, 이 글은 콘텐츠 소유자 관점에서 접근과 배포를 살펴보며 둘을 하나의 지표로 합치지 않습니다.

AI에 대한 태도보다 페이지 목적을 기준으로 결정하기

접근 목적을 논의하기 전에 페이지부터 분류할 것을 권장합니다. 공개 제품 문서는 대개 사용자가 이해하고 연동을 완료하도록 돕는 데 초점을 둡니다. 독자적인 연구 글은 출처 표기, 인용, 지속적인 관리를 우선할 수 있습니다. 로그인 후 볼 수 있는 고객 데이터는 노출을 늘리기 위해 공개할 것이 아니라 사용자 권한으로 계속 제한해야 합니다.

페이지 분류마다 다음 네 가지 구체적인 질문을 할 수 있습니다:

1. 누가 어떤 맥락에서 읽도록 의도한 페이지입니까? 제품을 알아보는 잠재 사용자입니까, 아니면 문제를 해결하려는 기존 사용자입니까?
2. 자동화된 접근이 이 작업을 완료하는 데 도움이 됩니까? 이를 뒷받침하는 관찰 가능한 근거는 무엇입니까?
3. 어떤 접근 패턴이 예상 범위를 벗어납니까? 선호 사항 표시, 트래픽 제어, 엄격한 인증 중 무엇이 필요합니까?
4. 정책을 조정한다면 대상 사용자에게 불이익이 없고 원래 설정으로 복원할 수 있는지 어떻게 확인할 수 있습니까?

크롤러마다 복잡한 정책을 따로 작성하라는 뜻이 아니라, 규칙을 바꿀 때 명확한 근거가 있어야 한다는 뜻입니다. 예를 들어 API 문서가 사용자의 문제 해결을 돕기 위한 것이라면 사용자가 시작한 정상적인 읽기 요청이 본문을 제대로 받는지 확인하고, 로그인한 사용자에게만 제공되는 데이터라면 인가되지 않은 요청이 제대로 거부되는지 테스트하세요. 두 경우의 성공 기준은 완전히 다릅니다.

규칙 변경은 데이터 표본도 바꿀 수 있습니다. 공개 소스에 일시적으로 접근할 수 없게 되면 관찰 시스템이 받는 콘텐츠는 줄지만, 이것이 외부 논의가 실제로 줄었다는 뜻은 아닙니다. 여러 소스를 분석할 때는 누락된 데이터를 0으로 처리하지 말고 수집 범위의 공백을 그대로 남겨 두어야 합니다. 사이트의 멀티 플랫폼 평판 모니터링 청사진은 수집 상태와 비즈니스 결론을 분리하는 방법을 다루며, 이는 실제 고객 장애 사례가 아니라 방법론에 관한 설명입니다.

효과를 평가하면서 정상적인 사용은 방해하지 않기

정책을 조정한 뒤에는 동일한 관찰 기간을 기준으로 지표를 추적하세요. 자동화 트래픽 양과 오류율, 핵심 페이지 접근성, 검색 노출수와 클릭수, 검증 가능한 인용 링크, 문서 열람이나 연동 완료로 이어지는 사용자 전환 행동 등입니다. 이 수치들을 모호한 "AI 트래픽" 지표 하나로 합치지 마세요.

일부 효과는 당분간 출처를 파악할 수 없을 수도 있습니다. 예를 들어 사용자가 어시스턴트를 통해 제품을 알게 된 뒤 홈페이지에 직접 방문하면, 일반적인 유입 경로 추적으로는 전체 여정을 파악하지 못할 수 있습니다. 이때는 정책 효과를 증명하려고 추정치를 채워 넣기보다 알 수 없는 부분을 그대로 남겨 두는 것이 올바른 방법입니다.

AI 접근 관리는 점점 세분화되고 있으며, 웹사이트 거버넌스도 그에 맞춰야 합니다. 먼저 어떤 콘텐츠가 누구를 위한 것인지 분명히 한 다음, 접근 목적, 실제 규칙, 사용 결과를 확인하세요. 발견이 필요한 홈페이지의 목표는 자동화 봇의 로그 항목을 최대한 늘리는 것이 아니고, 보호된 콘텐츠의 목표는 모든 자동화 요청을 실패시키는 것이 아닙니다. 목표는 허용된 범위 안에서 적절한 사람과 도구가 작업을 완료하는 데 충분한, 신뢰할 수 있는 정보를 제공하는 것입니다.