AI 크롤러가 소규모 블로그에 실제로 하는 일: 9일간의 로그 분석

저는 작은 Home Assistant / 셀프 호스팅 (self-hosting) 블로그를 운영하고 있습니다. 평상시에는 수십 명의 사람이 방문합니다. 그래서 마침내 nginx 로그에서 AI 크롤러를 검색(grep)했을 때, 그 숫자를 보고 멈칫했습니다. 9일 동안 AI 봇이 사이트를 18,209번 방문했습니다. 이 정도 규모의 블로그에서는 이제 저를 읽어가는 기계의 수가 사람보다 더 많습니다.

다음은 전체적인 분석 내용과 저를 놀라게 했던 점들, 그리고 대부분의 "AI 봇을 차단해야 할까요?" 스레드들이 잘못 알고 있는 몇 가지 포인트입니다.

가공되지 않은 수치 (9일, 소규모 블로그 하나)

총 348,667건의 요청 중, **18,209건 (5.2%)**이 AI/LLM 사용자 에이전트 (user-agents)로부터 발생했습니다:

봇 (Bot)	요청 수 (Requests)	실제 정체
ChatGPT-User	6,687	OpenAI — 누군가 ChatGPT에게 특정 페이지에 대해 물었을 때 수행하는 실시간 가져오기 (live fetch)
...

놀라움 #1: 1위 "AI 봇"은 크롤러가 아니다

압도적인 최대 소스인 **ChatGPT-User (6,687건의 요청)**는 모델 학습을 위해 크롤링하는 것이 아닙니다. 이것은 _실시간 가져오기 (live fetch)_입니다. 누군가 ChatGPT에게 질문을 던졌고, ChatGPT가 제 페이지가 관련이 있다고 판단하여, 질문에 답하기 위해 실시간으로 페이지를 가져온 것입니다. Perplexity-User 및 다른 어시스턴트 측 가져오기(assistant-side fetchers) 도 마찬가지입니다.

이 사실은 _"차단해야 할까요?"_라는 계산법을 뒤집어 놓습니다. ChatGPT-User는 당신을 스크래핑(scraping)하는 것이 아닙니다. 그것은 실제 사용자가 자신의 어시스턴트를 통해 지금 이 순간 당신의 페이지를 읽고 있는 것입니다. 이를 차단한다고 해서 학습을 막을 수 있는 것이 아닙니다. 단지 답변에 당신의 페이지가 나타나는 것을 막고 방문을 놓치게 될 뿐입니다. (제 분석 도구에서도 claude.ai 및 gemini.google.com으로부터 실제 세션이 유입되는 것을 확인할 수 있습니다.)

따라서 _"AI 봇 = 차단해야 할 스크래퍼"_라는 사고 모델은 트래픽의 상당 부분에 대해 잘못된 것입니다. 학습용 크롤러 (training crawlers) (GPTBot, ClaudeBot, CCBot)가 있는가 하면, 실시간 답변 엔진 가져오기 (live answer-engine fetchers) (ChatGPT-User, Perplexity-User, DuckAssistBot)가 있습니다. 이 둘을 동일하게 취급하는 것이 실수입니다.

놀라움 #2: robots.txt 동작 방식이 제각각이다

실제로 /robots.txt를 요청하는 주체가 누구인지 확인해 보았습니다:

• ClaudeBot: 233 — 성실하며, 지속적으로 확인합니다.
• PerplexityBot: 56 — 간헐적으로 확인합니다.
• Bytespider: 77 — 이를 가져옵니다 (내용을 준수하는지는 해당 봇의 평판에 달려 있습니다).
• GPTBot: 0 — 이 기간 동안 단 한 번도 가져오지 않았습니다 (물론 낮은 빈도이긴 합니다).
• ChatGPT-User: 0 — 전혀 없습니다. 그리고 이것은 정상입니다. 이 봇은 브라우저처럼 사용자에 의해 시작되기 때문입니다. 브라우저는 robots.txt를 읽지 않으며, 사용자를 대신한 실시간 페치 (fetch) 역시 읽지 않아야 합니다.

실질적인 결과: 일괄적인 Disallow 설정은 예의 바른 학습용 크롤러 (training crawlers) 에 의해서는 준수되지만, 사용자 페처 (user-fetchers) 에 의해서는 무시됩니다. 왜냐하면 robots.txt는 애초에 그들을 위해 만들어진 것이 아니기 때문입니다. 만약 당신의 목표가 *

• "AI 봇"을 무조건적으로 차단하지 마세요. 학습용 크롤러(GPTBot, ClaudeBot, CCBot — robots.txt가 작동함)와 실시간 답변 추출기(ChatGPT-User, Perplexity-User — 이들을 차단하면 실제 유입(referrals) 손실이 발생함)를 구분해야 합니다.
• User-Agent가 아닌 ASN 또는 역방향 DNS(reverse DNS)로 검증하세요. User-Agent(UA) 문자열은 아주 쉽게 위조될 수 있습니다. 일반 소비자 IP에서 오는 "GPTBot"은 GPTBot이 아닙니다.
• 서버 사이드 렌더링(server-rendered)된 HTML에 구조화된 데이터(structured data)와 메타데이터(metadata)를 포함하세요. 만약 데이터가 JavaScript(JS) 실행 후에만 나타난다면, AI 크롤러는 이를 절대 볼 수 없습니다.
• 부하가 걱정된다면 Bytespider를 주의 깊게 살펴보세요. 이는 실제 크롤러 중 가장 공격적입니다.

하루에 수십 명의 인간 독자가 방문하는 블로그의 경우, AI 크롤러는 이제 서버에 접속하는 검색 엔진 이외의 단일 최대 규모의 오디언스(audience)입니다. 이들은 사라지지 않을 것이기에, 어떤 크롤러가 당신의 글을 읽고 있는지 파악하고, 그들이 당신이 게시하는 내용을 실제로 볼 수 있도록 보장하는 것이 가치 있는 일입니다.

제가 사용한 JS 미실행 뷰(JS-less-view) 크롤러는 오픈 소스(seo-geo-audit)입니다. 이 도구는 유료 종속성 없이 순수 Node 환경에서 일반적인 SEO 점검과 더불어 바로 이러한 격차를 정확히 찾아냅니다.