서버 로그에서 AI 크롤러 확인하기

Q: 로그에 Google-Extended가 보이지 않는 이유는 무엇인가요?

Google은 Google-Extended에 별도의 user agent 문자열이 없다고 밝힙니다. 크롤링은 Google의 기존 크롤러가 하고, 토큰은 콘텐츠를 어떻게 사용할 수 있는지만 제어합니다. 크롤링하지 않는다고 Apple이 밝힌 Applebot-Extended도 마찬가지입니다.

Q: ChatGPT-User 트래픽은 크롤러인가요?

OpenAI는 ChatGPT-User가 특정 사용자 동작에 쓰이며 웹을 자동으로 크롤링하는 데는 쓰이지 않는다고 밝힙니다. 방문은 대개 누군가 ChatGPT에 페이지에 대해 물을 때 일어나므로 수가 많지 않습니다.

게시일 2026-11-12

핵심 답변

접근 로그의 user agent 필드에서 GPTBot, OAI-SearchBot, ClaudeBot, Claude-SearchBot, PerplexityBot 같은 토큰을 검색한 다음 이들이 받은 상태 코드를 확인하세요. user agent만으로는 아무것도 증명되지 않으므로, 각 출발지 IP를 업체가 공개한 IP 목록과 대조하거나 Google과 Apple은 역방향 및 정방향 DNS로 확인합니다.

robots.txt는 크롤러에게 요청하는 내용을 보여 줍니다. 접근 로그는 실제로 일어난 일, 즉 어떤 AI 크롤러가 왔고 어떤 페이지를 요청했으며 서버가 무엇으로 응답했는지를 보여 줍니다. 가장 직접적인 증거이며, 로그 파일과 터미널만 있으면 됩니다. 아래 예시는 nginx와 Apache가 기본으로 사용하는 combined 로그 형식을 기준으로 합니다.

이 글의 목차

접근 로그에서 AI 크롤러 방문은 어떻게 보이나요?
AI 크롤러 방문 횟수는 어떻게 세나요?
각 크롤러는 실제로 무엇을 받았나요?
OpenAI, Anthropic, Perplexity에서 온 방문이 맞는지 어떻게 검증하나요?
Googlebot, Applebot, CCBot은 어떻게 검증하나요?
가짜 AI 크롤러는 어떻게 생겼나요?
로그로 알 수 없는 것은 무엇인가요?

접근 로그에서 AI 크롤러 방문은 어떻게 보이나요?

combined 형식에서 각 줄에는 클라이언트 IP, 시각, 요청 줄, 상태 코드, 응답 크기, 리퍼러, user agent가 들어 있습니다. nginx는 이를 $remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"로 정의하며, Apache의 combined 형식도 같은 필드를 가집니다. OpenAI 학습 크롤러의 방문은 다음과 같이 보입니다.

20.171.206.5 - - [12/Nov/2026:10:00:01 +0000] "GET /pricing HTTP/1.1" 200 5120 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot"

찾아야 할 토큰은 업체들이 문서화한 것들입니다. OpenAI의 GPTBot, OAI-SearchBot, ChatGPT-User, Anthropic의 ClaudeBot, Claude-SearchBot, Claude-User, Perplexity의 PerplexityBot, Perplexity-User, 그리고 Googlebot, Applebot, meta-externalagent, meta-webindexer, CCBot입니다. Google-Extended와 Applebot-Extended는 로그에 나타나지 않습니다. Google은 Google-Extended에 별도의 user agent 문자열이 없다고 밝히고, Apple은 Applebot-Extended가 크롤링하지 않는다고 밝히며, 둘 다 robots.txt 토큰일 뿐입니다.

AI 크롤러 방문 횟수는 어떻게 세나요?

각 줄을 큰따옴표 문자로 나누면 user agent가 6번째 필드가 됩니다. 이 필드만 대조하면 URL에 봇 이름이 우연히 들어 있어서 생기는 오탐을 피할 수 있습니다. 다음 명령은 현재 로그와 회전·압축된 로그 전체에서 크롤러별 방문 횟수를 셉니다.

zcat -f /var/log/nginx/access.log* \
  | awk -F'"' '{print $6}' \
  | grep -Eo 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-SearchBot|Claude-User|PerplexityBot|Perplexity-User|Googlebot|bingbot|Applebot|meta-externalagent|meta-webindexer|CCBot' \
  | sort | uniq -c | sort -rn

Apache에서는 경로를 /var/log/apache2/access.log* 또는 /var/log/httpd/access_log*처럼 바꾸세요. zcat -f는 일반 파일과 gzip 파일을 모두 읽습니다. 예상한 크롤러가 보이지 않는다고 해서 그것만으로 차단되었다는 증거는 아닙니다. 로그가 다루는 기간에 그냥 방문하지 않았을 수 있습니다.

각 크롤러는 실제로 무엇을 받았나요?

방문 여부보다 응답이 더 중요합니다. 모든 요청에서 403을 받은 크롤러는 방문했지만 아무것도 읽지 못한 것입니다. 다음 명령은 상태 코드, 가장 많이 요청된 경로, 그리고 크롤러가 robots.txt를 가져갔는지를 보여 줍니다.

# Status codes returned to PerplexityBot
zcat -f /var/log/nginx/access.log* | awk -F'"' '$6 ~ /PerplexityBot/ {split($3, s, " "); print s[1]}' | sort | uniq -c

# Most requested paths for OAI-SearchBot
zcat -f /var/log/nginx/access.log* | awk -F'"' '$6 ~ /OAI-SearchBot/ {split($2, r, " "); print r[2]}' | sort | uniq -c | sort -rn | head -20

# Did ClaudeBot fetch robots.txt, and what did it get?
zcat -f /var/log/nginx/access.log* | awk -F'"' '$6 ~ /ClaudeBot/ && $2 ~ /robots\.txt/ {split($3, s, " "); print s[1]}' | sort | uniq -c

대부분 200이면 바람직합니다. 403이나 429가 많다면 방화벽 규칙이나 요청 제한을 의심하세요. robots.txt에 대한 5xx 응답은 심각합니다. RFC 9309에 따르면 robots.txt에서 서버 오류를 받은 크롤러는 사이트 전체가 차단된 것으로 간주해야 합니다.

사이트가 CDN 뒤에 있으면 두 가지가 달라집니다. CDN이 차단한 요청은 원본 서버에 도달하지 않으므로 원본 로그에는 전혀 나타나지 않습니다. 대신 CDN 자체의 보안 이벤트를 확인하세요. 또한 방문자 IP를 복원하지 않으면 원본 서버는 CDN의 주소를 기록합니다. 예를 들어 Cloudflare는 원래 IP를 CF-Connecting-IP 헤더로 전달하며, 기본적으로는 Cloudflare IP가 기록됩니다.

OpenAI, Anthropic, Perplexity에서 온 방문이 맞는지 어떻게 검증하나요?

이 업체들은 에이전트가 사용하는 IP 대역을 공개합니다. OpenAI는 openai.com/gptbot.json, openai.com/searchbot.json, openai.com/chatgpt-user.json에, Anthropic은 claude.com/crawling/bots.json에, Perplexity는 perplexity.ai/perplexitybot.json과 perplexity.ai/perplexity-user.json에 게시합니다. Anthropic은 출발지 IP가 자사 목록에 있으면 크롤러가 Anthropic에서 오고 있다는 뜻이라고 밝힙니다. 이 세 곳 모두 역방향 DNS 검증은 문서화하지 않으므로 목록을 사용하세요.

이 파일들은 ipv4Prefix 또는 ipv6Prefix 항목으로 이루어진 prefixes 목록이라는 같은 구조를 가지므로, 작은 스크립트 하나로 어느 파일에든 IP를 대조할 수 있습니다.

python3 - 20.171.206.5 https://openai.com/gptbot.json <<'EOF'
import ipaddress, json, sys, urllib.request
ip = ipaddress.ip_address(sys.argv[1])
req = urllib.request.Request(sys.argv[2], headers={"User-Agent": "log-check"})
prefixes = json.load(urllib.request.urlopen(req))["prefixes"]
nets = [ipaddress.ip_network(p.get("ipv4Prefix") or p.get("ipv6Prefix")) for p in prefixes]
print(ip, "listed" if any(ip in n for n in nets) else "NOT listed")
EOF

특정 크롤러라고 주장한 IP를 나열하려면 로그에 awk -F'"' '$6 ~ /GPTBot/ {split($1, a, " "); print a[1]}'를 실행하고 그 결과를 sort | uniq -c | sort -rn에 넘기세요. 각 IP를 해당하는 목록과 대조합니다. 목록은 바뀌므로 오래된 사본을 두지 말고 매번 새로 가져오세요.

Googlebot, Applebot, CCBot은 어떻게 검증하나요?

Google, Apple, Common Crawl은 역방향 및 정방향 DNS 확인을 문서화하고 있습니다. IP의 호스트 이름을 조회해 도메인을 확인한 다음, 그 호스트 이름을 다시 조회해 같은 IP를 가리키는지 확인합니다.

host 66.249.66.1
# 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.
host crawl-66-249-66-1.googlebot.com
# crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Google의 경우 크롤러에 따라 호스트 이름이 googlebot.com, google.com, googleusercontent.com 중 하나로 끝나야 합니다. Google은 IP 대역도 공개하며 Googlebot은 common-crawlers.json에 있습니다. Apple의 경우 applebot.apple.com에 속해야 하고 대역은 applebot.json에 있습니다. Common Crawl의 경우 crawl.commoncrawl.org 아래여야 하며, Common Crawl은 다른 크롤러가 CCBot 이름을 도용한다고 경고합니다.

가짜 AI 크롤러는 어떻게 생겼나요?

스크레이퍼는 필터를 피하려고 잘 알려진 크롤러의 user agent를 빌려 쓰는 경우가 많습니다. 전형적인 징후는 다음과 같습니다.

user agent는 크롤러를 내세우지만 IP가 해당 업체의 공개 목록에 없거나 역방향 DNS가 일치하지 않습니다.
출발지가 업체가 목록에 올리지 않은 가정용 네트워크나 클라우드 제공업체입니다.
클라이언트가 robots.txt를 요청하지 않거나, 해당 크롤러에 대해 robots.txt가 차단한 경로를 요청합니다.
요청 빈도나 패턴이 같은 이름으로 확인된 트래픽과 크게 다릅니다. 예를 들어 검색이나 로그인 엔드포인트에 짧은 시간에 몰려드는 요청이 있습니다.

반대 문제도 있습니다. 일반 브라우저 user agent를 쓰는 크롤러는 로그 줄만으로는 전혀 식별할 수 없습니다. 2025년 Cloudflare는 Perplexity가 공개된 대역 밖의 IP에서 선언되지 않은 브라우저형 user agent로 크롤링하는 것을 관찰했다고 밝혔고, Perplexity는 이 설명에 이의를 제기하며 트래픽 일부를 제3자 서비스에 돌렸습니다. 이런 사례는 로그만으로 결론을 내릴 수 없으며, 그래서 공개된 IP 대역에 의한 검증이 양방향 모두에서 중요합니다.

로그로 알 수 없는 것은 무엇인가요?

로그는 서버에 도달한 것만 보여 줍니다. CDN이 원본 서버 앞에서 차단한 것, 200을 반환한 페이지에 텍스트가 있었는지 스크립트 껍데기뿐이었는지, 오늘 크롤러가 온다면 허용될지는 알 수 없습니다. 또한 보관하는 기간만 다루며, 방문이 적은 사이트에는 AI 크롤러가 드물게 올 수 있습니다.

AISeeWhy 계정에서는 combined 형식의 접근 로그(일반 또는 .gz, 최대 50MB)를 업로드할 수 있습니다. 로그는 분석 후 폐기되며, 각 AI 크롤러의 요청을 상태 코드와 함께 집계하고 업체가 공개한 IP 대역과 대조합니다.

자주 묻는 질문

로그에 Google-Extended가 보이지 않는 이유는 무엇인가요?

Google은 Google-Extended에 별도의 user agent 문자열이 없다고 밝힙니다. 크롤링은 Google의 기존 크롤러가 하고, 토큰은 콘텐츠를 어떻게 사용할 수 있는지만 제어합니다. 크롤링하지 않는다고 Apple이 밝힌 Applebot-Extended도 마찬가지입니다.

로그의 user agent를 믿어도 되나요?

아닙니다. 누구나 어떤 user agent든 보낼 수 있습니다. 하나의 주장으로 보고, 업체가 공개한 IP 대역으로 확인하세요. Google, Apple, Common Crawl은 역방향 및 정방향 DNS 조회로도 확인할 수 있습니다.

로그에 AI 크롤러 방문이 없습니다. 차단된 건가요?

반드시 그렇지는 않습니다. 크롤러가 아직 방문하지 않았을 수도 있고, CDN이 원본 서버 앞에서 차단했을 수도 있으며, 로그에 CDN의 IP 주소만 기록되고 있을 수도 있습니다. CDN의 보안 이벤트를 확인하고, 각 크롤러의 user agent로 페이지를 테스트해 보세요.

ChatGPT-User 트래픽은 크롤러인가요?

OpenAI는 ChatGPT-User가 특정 사용자 동작에 쓰이며 웹을 자동으로 크롤링하는 데는 쓰이지 않는다고 밝힙니다. 방문은 대개 누군가 ChatGPT에 페이지에 대해 물을 때 일어나므로 수가 많지 않습니다.