AI 어시스턴트가 내 글을 인용했다는 말은 사실 두 가지 전혀 다른 일을 가리킵니다. 모델이 내 서버를 직접 방문해서 읽은 것일 수도 있고, 사람이 AI 답변을 보고 링크를 클릭해서 온 것일 수도 있습니다. 이 둘을 구분하지 않으면, “AI 트래픽이 늘었다”는 숫자가 실제로 무엇을 의미하는지 알 수 없습니다.
SurfacedBy의 Ali Khallad가 이 질문에 직접 답하기 위해 nginx 탐침을 설치하고 주요 AI 어시스턴트 8개에 동일한 쿼리를 던졌습니다. 각 어시스턴트가 라이브로 페이지를 가져오는지, 아니면 미리 쌓아둔 인덱스에서 답하는지를 서버 로그로 실측한 결과입니다.
출처: What nginx logs prove about AI traffic vs referral traffic – SurfacedBy
AI 트래픽의 두 가지 신호
실험 전에 개념부터 짚을 필요가 있습니다. nginx 로그에서 “AI 트래픽”으로 보이는 것은 사실 성격이 전혀 다른 두 신호가 섞여 있습니다.
하나는 provider-side fetch — AI 어시스턴트가 사용자 질문에 답하기 위해 서버를 직접 방문해 페이지를 읽어가는 것입니다. 이때는 ChatGPT-User나 Claude-User 같은 전용 user-agent가 남습니다.
다른 하나는 클릭 트래픽 — 사람이 AI 답변을 읽고 링크를 눌러 직접 방문하는 것입니다. 이때는 일반 브라우저 user-agent와 함께 chatgpt.com이나 claude.ai 같은 referrer가 남습니다.
이 둘을 하나의 “AI 트래픽” 숫자로 합산하면, 모델이 내 콘텐츠를 실시간으로 읽고 있는지 아닌지를 전혀 알 수 없게 됩니다.
자신을 밝힌 어시스턴트들
실험에서 ChatGPT, Claude, Perplexity, Meta AI, Manus는 모두 고유한 user-agent로 자신을 명시하며 라이브 fetch를 수행했습니다.
각각의 방식은 조금씩 달랐습니다. ChatGPT는 여러 IP에서 동시에 요청을 보내 여러 후보 페이지를 한꺼번에 가져갔습니다. 하나의 IP만 차단하면 놓칩니다.
Claude는 유일하게 페이지를 읽기 전에 매번 robots.txt를 먼저 확인했습니다. 216.73.216.0/24 대역의 Anthropic IP에서 온 요청이었고, 리디렉션도 깔끔하게 따라갔습니다. 참고로 Anthropic의 봇은 세 가지입니다. Claude-User(사용자 질문에 반응하는 실시간 fetch), Claude-SearchBot(검색 인덱스 구축), ClaudeBot(학습용 크롤러). 로그에서 구분이 필요한 것은 Claude-User뿐입니다.
Manus는 HTML뿐 아니라 CSS, JS, 이미지까지 전체 페이지를 렌더링했습니다. 실험에 등장한 어시스턴트 중 가장 완전한 형태의 브라우저처럼 동작한 셈입니다.
로그에서 보이지 않는 어시스턴트들
문제는 나머지 세 어시스턴트입니다.
Gemini는 탐침 기간 동안 단 한 번도 Google user-agent로 요청을 보내지 않았습니다. 클릭 트래픽(사람이 Gemini 답변을 보고 클릭)은 있었지만, 모델이 직접 페이지를 읽는 provider fetch는 없었습니다. 구조적인 이유가 있습니다. Google은 Gemini를 위한 별도의 retrieval user-agent를 공개하지 않았고, Gemini는 Googlebot이 이미 쌓아둔 Search 인덱스를 기반으로 답합니다. 만약 Gemini가 라이브 fetch를 한다면 Googlebot으로 오겠지만, 이는 일반 검색 크롤링과 구별이 안 됩니다.
한 가지 추가로 알아둘 점이 있습니다. Google-Extended를 차단하는 것은 Googlebot이 수집한 콘텐츠를 Gemini 학습·그라운딩에 쓸 수 있는지를 제어하는 것이지, Googlebot 크롤링 자체를 막는 것이 아닙니다.
Copilot과 Grok은 각각 일반 Chrome과 Safari user-agent로 fetch를 수행했습니다. 로그만 봐서는 사람의 방문과 구별이 안 됩니다. 두 서비스 모두 retrieval 전용 user-agent를 공개하지 않았습니다.
결과적으로 주요 어시스턴트 8개 중 3개(Gemini, Copilot, Grok)는 로그만으로는 provider-side fetch 여부를 파악할 방법이 없습니다.
한눈에 보는 실측 결과
| 어시스턴트 | 라이브 Fetch | 로그 식별 가능 | User-Agent |
|---|---|---|---|
| ChatGPT | ○ | ○ | ChatGPT-User/1.0 |
| Claude | ○ | ○ | Claude-User/1.0 |
| Perplexity | ○ | ○ | Perplexity-User/1.0 |
| Manus | ○ | ○ | Manus-User/1.0 (suffix) |
| Meta AI | ○ | 부분 | meta-webindexer/1.1 |
| Gemini | × | × (구조적) | 없음 |
| Copilot | ○ | × (위장) | 일반 브라우저 |
| Grok | ○ | × (위장) | 일반 브라우저 |
로그에서 실제로 측정할 수 있는 것
이 실험이 정리해주는 측정 가능한 범위는 다음과 같습니다.
- Provider fetch (모델이 직접 읽은 것):
ChatGPT-User,Claude-User,Perplexity-User,Manus-User,Meta-ExternalFetcher,meta-webindexer로 들어오는 요청 - 클릭 트래픽 (사람이 AI 답변을 보고 방문한 것): 일반 브라우저 user-agent +
chatgpt.com,claude.ai,perplexity.ai,gemini.google.com등의 referrer
여기서 놓치기 쉬운 것이 있습니다. 검색 인덱스 봇(OAI-SearchBot, Claude-SearchBot, PerplexityBot, Googlebot)과 학습 크롤러(GPTBot, ClaudeBot, CCBot)는 특정 사용자 질문에 반응하는 것이 아닙니다. 이들을 AI 트래픽으로 집계하면 숫자가 부풀어오릅니다.
AI 어시스턴트들이 웹을 어떻게 읽는지에 대한 공개 데이터가 거의 없는 상황에서, 이 실험은 드물게 실측값을 제공합니다. 각 어시스턴트별 user-agent 목록과 robots.txt 설정 방법, 그리고 Copilot·Grok의 측정 한계에 대한 상세한 내용은 원문에서 확인할 수 있습니다.
참고자료:
답글 남기기