구글봇은 잊으세요. 몇 년 동안 열심히 점검해왔던 크롤링 가능성, 색인 가능성, 속도, 모바일 친화성, 구조화된 데이터 등의 체크리스트는 이제 박물관에나 가야 할 유물이 되었습니다.
우리가 알던 인터넷이 더 이상 구글의 색인기만을 위한 놀이터가 아니기 때문입니다.
2026년이면 여러분의 웹사이트는 적어도 12개 이상의 추가적인 비인간 사용자를 맞이하게 될 것입니다.
AI 크롤러인 GPTBot, ClaudeBot, PerplexityBot 등은 단순히 웹사이트를 둘러보는 것을 넘어, LLM(대규모 언어 모델) 학습에 적극적으로 참여하고 차세대 AI 검색 결과를 지원합니다. 여기에 더해, 최근 발표된 Google-Agent와 같은 사용자 요청 에이전트들은 특정 사용자를 대신해 실시간으로 웹을 탐색합니다. Cloudflare의 2026년 1분기 분석에 따르면, 전체 웹 트래픽의 30.6%가 봇에서 발생하며, AI 크롤러와 에이전트가 그 비중을 빠르게 늘려가고 있습니다. 여러분의 기술 SEO 감사? 이 모든 것을 고려하도록 근본적으로 다시 작성해야 합니다.
구세대 vs. 신세대 봇: 충돌의 시작
robots.txt 파일에 대해 이야기해 봅시다. 아마도 여러분은 구글봇이나 빙봇 등 소수의 알려진 봇을 염두에 두고 작성했을 것입니다. 하지만 AI 크롤러는 전혀 다른 종류입니다. 이들은 기존에 관리하던 봇과는 별개로, 명시적인 규칙을 요구합니다. 이를 무시하는 것은 마치 현관문을 활짝 열어두고 특정 손님만 들어오기를 기대하는 것과 같습니다. 그렇게 작동하지 않습니다.
여기서 중요한 질문이 생깁니다. 각 크롤러별로 의식적인 결정을 내리고 있습니까, 아니면 기본 설정만 따르고 있습니까? 그 기본 설정 말입니다. 여러분이 원치 않는 봇을 조용히 들여보내거나, 더 심각하게는 여러분이 원하는 봇을 차단하고 있을지도 모릅니다.
그렇다면 무엇을 확인해야 할까요?
AI 특정 사용자 에이전트(GPTBot, ClaudeBot, PerplexityBot, Google-Extended, Bytespider, AppleBot-Extended, CCBot, ChatGPT-User)를 대상으로 하는 규칙이 robots.txt에 있는지 검토하세요. 이들이 명시적으로 목록에 없다면, 여러분은 위험한 가정 하에 운영 중인 것입니다. 즉, 기본 설정이 여러분의 전략적 목표와 일치할 것이라고 말이죠. 거의 확실하게 그렇지 않습니다.
AI 크롤러 트래픽은 크게 세 가지로 분류할 수 있습니다. Cloudflare에 따르면 AI 크롤러 트래픽의 89.4%를 차지하는 학습용 크롤러는 데이터 수집기이고, 8%인 검색용 크롤러는 AI 답변을 지원하며, 2.2%인 사용자 요청 에이전트는 실시간 프록시 역할을 합니다. 각기 맞춤형 접근 방식이 필요합니다.
크롤링 대비 추천 트래픽 비율을 고려해 보세요. 예를 들어 Anthropic의 ClaudeBot은 추천 트래픽 단 1건을 위해 무려 20,600개의 페이지를 크롤링합니다. OpenAI의 비율은 1,300:1입니다. Meta는 0건입니다. OpenAI의 OAI-SearchBot이나 PerplexityBot을 직접 차단하는 것은 ChatGPT Search 및 Perplexity의 AI 답변에서의 가시성에 직접적인 영향을 미칩니다. 반대로 CCBot이나 Meta와 같은 학습 중심 크롤러를 차단하면, 실질적인 트래픽 이득이 없는 소스에서 데이터 추출을 막을 수 있습니다.
크롤링 대비 추천 트래픽 비율은 ‘주는 것 없이 가져가기만 하는’ 대상을 알려줍니다.
그리고 Google-Agent가 있습니다. 이 녀석은 특별한 주의가 필요합니다. 2026년 3월 Google의 공식 사용자 요청 페처 목록에 추가되었으며, 사용자를 대신해 웹을 탐색하는 Google의 AI 시스템으로부터의 요청을 식별합니다. 핵심은 무엇일까요? 바로 robots.txt를 무시한다는 것입니다. Google의 논리는 이렇습니다. 사용자가 요청했기 때문에 사용자 프록시로 작동한다는 것입니다. Google-Agent를 차단하려면 간단한 robots.txt 수정이 아닌 서버 측 인증이 필요합니다. 미래를 위한 흥미롭고, 솔직히 중요한 발전입니다.
JavaScript 렌더링: 보이지 않는 장벽
이제부터 많은 최신 웹사이트에 있어 정말 까다로운 문제가 발생합니다.
구글봇은 JavaScript를 렌더링합니다. 이건 구식 뉴스입니다. 새로운 점은 무엇일까요? 사실상 다른 모든 주요 AI 크롤러는 그렇지 않다는 것입니다. GPTBot, ClaudeBot, PerplexityBot, CCBot 등은 모두 정적 HTML만 가져옵니다. AppleBot과 Googlebot이 예외입니다.
이게 실제로는 무슨 의미일까요?
제품 이름, 가격, 서비스 설명과 같은 중요한 콘텐츠가 클라이언트 측 JavaScript(React, Vue, Angular 등으로 구축된 대부분의 SPA를 생각해보세요) 내부에 있다면, OpenAI, Anthropic, Perplexity의 모델을 학습시키는 AI에게는 사실상 보이지 않는 것입니다. 그들에게는 빈 페이지만 보내는 셈입니다.
주요 페이지에 대해 curl -s [URL] 같은 간단한 명령을 실행해 보세요. 만약 해당 중요 콘텐츠가 원시 HTML 응답에 포함되어 있지 않다면, 내일의 검색 결과를 구동할 모델을 학습시키는 AI 크롤러도 이를 보지 못할 것입니다. 브라우저의 ‘요소 검사’와 혼동하지 마세요. 그것은 JavaScript 실행 후 렌더링된 DOM을 보여줍니다. 여러분은 소스 코드를 확인해야 합니다.
서버 측 렌더링(SSR) 또는 정적 사이트 생성(SSG)은 더 이상 단순한 최적화 전략이 아닙니다. AI 검색에서의 가시성을 위해서는 이제 필수적인 요구 사항이 되었습니다.
크롤링 예산과 AI 학습의 미래
기존의 크롤링 예산 논의는 훨씬 더 복잡해질 것입니다. 특히 AI 학습용 크롤러는 상당한 리소스를 소비할 수 있습니다. 이들의 행동을 이해하고 적절한 robots.txt 지시문을 설정하는 것은, 직접적인 반환이 없는 봇에 의해 서버 리소스가 고갈되는 것을 방지하고 접근을 제어하는 데 매우 중요합니다.
이것이 단지 시작일까요? 당연합니다. AI의 지속적인 발전은 이러한 크롤러와 그들의 행동을 끊임없이 변화시킬 것입니다. 앞서 나가려면 과거의 정적인 체크리스트를 넘어, 여러분의 콘텐츠와 상호작용하는 모든 중요한 디지털 엔티티의 요구를 예측하는 동적이고 다각적인 감사로 나아가야 하는, 선제적이고 데이터 기반적인 접근 방식이 필요합니다.
단일 목적 봇을 위해 구축된 표준 기술 SEO 감사는 죽었습니다. AI를 인지하는 기술 SEO 감사가 오래도록 번영하기를.
