본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 05. 27. 00:42

감시 없이 AI 크롤러를 위한 웹사이트 분석 설계하기

요약

AI 크롤러와 에이전트의 트래픽이 증가함에 따라, 기존의 인간 중심 분석 모델을 넘어 기계 판독형 웹 트래픽을 효과적으로 분류하고 분석하는 설계 방안을 제시합니다.

핵심 포인트

  • AI 크롤러 트래픽을 노이즈가 아닌 유용한 운영 신호로 취급해야 함
  • 추적(Tracking)과 분류(Classification)를 분리하는 아키텍처 설계 필요
  • AI 가시성 확보를 위한 인프라 관점의 분석 데이터 확보 중요

tags: seo, analytics, webdev, ai

대부분의 웹사이트 분석(Website analytics)은 여전히 '누가 사이트를 방문했는가?'라는 오래된 질문에서 시작됩니다.

그 질문은 유용하지만, 더 이상 그것만으로는 충분하지 않습니다. 현대의 사이트들은 검색 크롤러(Search crawlers), AI 크롤러(AI crawlers), 프리뷰 봇(Preview bots), 모니터링 도구(Monitoring tools), 그리고 나중에 인간의 추천을 보낼 수도 있는 어시스턴트(Assistants)들에 의해서도 읽힙니다. 만약 이 모든 트래픽이 하나의 세션 스트림(Session stream)으로 평탄화된다면, 운영자는 기계 판독형 웹(Machine-readable web)이 실제로 사이트와 어떻게 상호작용하고 있는지 이해하는 능력을 상실하게 됩니다.

흥미로운 작업은 단순히 또 다른 봇 필터(Bot filter)를 추가하는 것이 아닙니다. 제품을 감시 소프트웨어(Surveillance software)로 만들지 않으면서, 인간 트래픽, 크롤러 트래픽, AI 가시성(AI visibility), 그리고 추천(Referrals)을 서로 다른 신호로 볼 수 있도록 분석을 설계하는 것입니다.

트래픽 모델이 변했다

전통적인 분석 설정은 보통 페이지뷰(Pageviews), 세션(Sessions), 리퍼러(Referrers), 캠페인(Campaigns), 그리고 전환 경로(Conversion paths)를 중심으로 최적화되어 있습니다. 그 모델은 인간의 행동에는 작동합니다. 하지만 방문자가 JavaScript를 전혀 실행하지 않을 수도 있고, 페이지의 일부만 가져올 수도 있으며, 자신을 일관되지 않게 식별할 수도 있고, 일반적인 클릭 경로를 생성하지 않으면서 나중에 발견(Discovery)에 영향을 미칠 수도 있는 크롤러일 경우에는 그 힘이 약해집니다.

AI 크롤러는 이러한 문제를 더욱 명확하게 드러냅니다. 어떤 페이지는 AI 답변을 통해 사람이 도착하기 훨씬 전부터 GPTBot, ClaudeBot, PerplexityBot, Google-Extended 또는 다른 에이전트형 클라이언트(Agent-like client)에 의해 읽힐 수 있습니다. 이러한 요청을 노이즈(Noise)로 취급하는 것은 유용한 운영 신호를 숨기는 것입니다. 즉, 사이트의 어느 부분이 기계에 의해 읽을 수 있는지, 중요한 페이지가 얼마나 자주 재방문되는지, 그리고 AI 대상 발견(AI-facing discovery)이 실제로 표현되기를 원하는 페이지에 집중되어 있는지와 같은 신호들 말입니다.

운영자에게 질문은 허영심을 위한 트래픽(Vanity traffic)에 관한 것이 아니라 증거에 관한 것이 됩니다. 배포(Deploy) 후에 문서가 크롤링되었는가? 제품 페이지가 AI 시스템에 보이는가? 크롤러 급증(Spikes)이 콘텐츠 변경, 사이트맵(Sitemap) 변경, 또는 외부 언급(External mention)과 관련이 있는가? 이것들은 마케팅 대시보드가 아니라 인프라(Infrastructure)에 관한 질문입니다.

추적(Tracking)에서 분류(Classification)를 분리하기

더 깔끔한 아키텍처(Architecture)는 분류(Classification)를 추적(Tracking)으로부터 분리하는 것에서 시작됩니다.

추적(Tracking)은 무엇이 일어났는지를 답합니다. 분류(Classification)는 어떤 종류의 행위자(Actor)가 해당 이벤트를 생성했는지를 답합니다. 이 둘은 너무 일찍 섞여서는 안 됩니다. 사람의 브라우저, 검색 봇(Search bot), AI 크롤러(AI crawler), 그리고 업타임 프로브(Uptime probe) 모두 요청(Request)을 생성할 수 있지만, 분석 계층(Analysis layer)은 이들이 모두 동일한 의미를 갖는 것처럼 가장해서는 안 됩니다.

이 패턴의 작은 버전은 다음과 같습니다:

const AI_CRAWLERS = [
  /GPTBot/i,
  /ClaudeBot/i,
...

이것은 완전한 봇 지능 시스템(Bot intelligence system)은 아닙니다. 사용자 에이전트(User-agent) 매칭만으로는 속이기 쉽고 불완전합니다. 하지만 이는 경계를 보여줍니다. 분류(Classification)는 명시적이고, 검사 가능하며, 신뢰도(Confidence)를 가질 수 있어야 합니다. 성숙한 버전에서는 역방향 DNS(Reverse DNS) 확인, 알려진 크롤러 목록, 적절한 경우 IP 범위 검증, 에지 로그(Edge logs), 그리고 신뢰도 레이블(Confidence labels)을 추가할 수 있습니다.

중요한 부분은 운영자(Operator)가 그 결정을 볼 수 있어야 한다는 점입니다. 시스템이 특정 요청을 AI 크롤러라고 말한다면, 왜 그런지를 설명할 수 있어야 합니다.

프라이버시(Privacy)는 여전히 중요합니다

AI 가시성(Visibility)이 침해적인 분석(Analytics)을 재구축하기 위한 핑계가 되어서는 안 됩니다.

사용자를 핑거프린팅(Fingerprinting)하거나, 제3자 쿠키(Third-party cookies)를 설정하거나, 원시 IP 주소(Raw IP addresses)를 저장하지 않고도 많은 것을 측정할 수 있습니다. 퍼스트 파티 이벤트(First-party events), 거친 수준의 요청 메타데이터(Coarse request metadata), 익명화된 네트워크 정보, DNT 및 GPC에 대한 존중 있는 처리, 그리고 명확한 봇 분류(Bot classification)를 통해 운영상의 요구 사항 중 상당 부분을 충족할 수 있습니다.

이러한 트레이드오프(Tradeoff)가 중요한 이유는 AI 검색 가시성이 기술적 SEO, 콘텐츠 운영, 그리고 인프라 모니터링(Infrastructure monitoring)과 밀접하게 맞닿아 있기 때문입니다. 목표는 모든 개인을 식별하는 것이 아닙니다. 목표는 사이트가 어떻게 읽히고 있는지, 카테고리 수준에서 누구에 의해 읽히고 있는지, 그리고 현재 발견(Discovery)을 매개하는 시스템들에 중요한 접점(Surfaces)들이 노출되고 있는지를 이해하는 것입니다.

유용한 분석 제품(Analytics product)은 데이터 모델(Data model)에서 그러한 구분을 명확하게 만들어야 합니다. 인간의 행동은 하나의 차선에 있어야 합니다. 봇과 크롤러의 가시성은 다른 차선에 있어야 합니다. AI 리퍼럴(AI referrals)은 또 다른 차선에 있어야 합니다. 이들을 결합하는 것은 유용하지만, 이들을 혼동하는 것은 유용하지 않습니다.

운영자가 증명할 수 있어야 하는 것들

실질적인 테스트는 간단합니다. 변경 사항을 배포한 후, 운영자는 추측 없이 몇 가지 질문에 답할 수 있어야 합니다.

  • 어떤 페이지를 인간이 방문했는가?
  • 어떤 페이지를 검색 봇(search bots)이 크롤링했는가?
  • 어떤 페이지를 AI 크롤러(AI crawlers)가 읽었는가?
  • 어떤 리퍼럴(referrals)이 AI 어시스턴트(AI assistants)나 AI 검색 인터페이스(AI search surfaces)로부터 왔는가?
  • 어떤 이벤트가 높은 신뢰도(high confidence)를 가지며, 어떤 것이 방향성(directional)만 제시하는가?

이것이 바로 WebmasterID가 구축된 형태입니다. 즉, 퍼스트 파티 분석(first-party analytics), AI 크롤러 가시성(AI crawler visibility), 봇 인텔리전스(bot intelligence), 그리고 AI 리퍼럴 기여도(AI referral attribution)를 운영자 중심의 단일 뷰(view)로 통합하는 것입니다. 핵심은 웹이 제공하지 않는 확실성을 억지로 만들어내는 것이 아닙니다. 핵심은 불확실성을 실제 운영자가 그에 따라 행동할 수 있을 만큼 충분히 가시화하는 것입니다.

AI 검색 시대에 적합한 양질의 분석(analytics)은 그로스 핵(growth hack)이라기보다 관측 가능성(observability)에 가까워야 합니다. 그것은 무엇이 일어났는지를 보여주어야 하고, 인간과 기계 사이의 차이를 보존해야 하며, 사이트 책임자에게 신호(signal)로부터 의사결정(decision)에 이르는 명확한 경로를 제공해야 합니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0