로그에서 발견된 ChatGPT-User: 이름으로 스캐너 트래픽과 실제 ChatGPT 트래픽을 구분하는 방법

접근 로그에서 ChatGPT-User를 검색하여 ChatGPT가 사이트에서 찾지 못한 내용을 확인하더라도, 그중 대부분은 ChatGPT가 아닙니다.

저희는 2026년 10월 7일 수요일 하루 동안 LovedByAI에서 운영하는 소규모 비즈니스 웹사이트들의 봇 트래픽을 분석했습니다. ChatGPT-User 사용자 에이전트를 가진 요청 중 404 오류가 발생한 건수는 111개 사이트에서 총 1,022건이었으며, 이 중 703건(69%)은 ChatGPT가 아닌 익스플로잇 프로브(exploit probes)였습니다. 즉, 취약점 스캐너가 그 이름을 사용하고 있는 것입니다.

한편, 실제로 의미 있는 404 오류, 즉 실제 사람이 ChatGPT를 통해 존재하지 않는 페이지에 접속한 경우는 해당 사용자 에이전트 아래에서 전혀 나타나지 않습니다. 본 게시물에서는 이 둘을 구분하는 방법을 자체 로그로 실행할 수 있는 스크립트를 제공합니다. 숫자 배경의 전체 연구는 ChatGPT broken links: why visitors land on 404s를 참고하세요.

ChatGPT-User 사용자 에이전트란 무엇인가요?

ChatGPT-User는 사람이 대화 도중에 무언가를 질문했을 때 ChatGPT가 페이지를 가져올 때 사용하는 사용자 에이전트입니다. 이는 OpenAI의 세 가지 크롤러 중 하나이며, 각각 다른 역할을 수행합니다:

ChatGPT-User 요청은 결합 형식 로그에서 다음과 같이 보입니다 (OpenAI 목록의 주소를 사용한 데모 라인):

104.208.184.197 - - [07/Oct/2026:10:14:02 +0000] "GET /services/ HTTP/1.1" 200 512 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot"

사용자 에이전트 문자열은 복사하기가 매우 쉽습니다. 하지만 IP 범위는 그렇지 않기 때문에 OpenAI에서 이를 공개하는 것입니다.

몇 개의 ChatGPT-User 404 오류가 가짜인가요?

2026년 10월 7일 기준으로, 저희 로그에 기록된 소규모 비즈니스 웹사이트로 향하는 총 823,928개의 봇 요청 중 5.8%가 404 오류를 반환했습니다. 사용자를 위해 페이지를 가져오는 AI 어시스턴트라고 주장하는 사용자 에이전트(ChatGPT-User, Claude-User, Perplexity-User 등)의 경우 404 비율은 43.7% (10,528개 중 4,597건)였습니다. AI 검색 크롤러는 10.0%, 일반 검색 엔진은 7.2%, 그리고 AI 학습 크롤러는 4.4%를 기록했습니다.

차이점은 스캐너입니다. 이날 발생한 1,022개의 ChatGPT-User 404 오류 중 703건은 다음과 같은 엄격한 익스플로잇 패턴과 일치했습니다:

• allow_url_include 인수가 포함된 /cgi-bin/php-cgi: PHP-CGI 인수 주입 공격으로 CVE-2024-4577로 추적됨
• .env 파일
• /proc/self 읽기 및 경로 순회(path traversal)
• Vite dev server의 /@fs/ 파일 읽기
• Kubernetes 서비스 계정 토큰

나머지 대부분은 소규모 비즈니스 웹사이트가 제공하지 않는 설정 및 디버그 파일(runtime-config.js, /debug/pprof)을 요청했습니다. 동일한 탐색 시도는 GrokBot, MistralAI-User, DuckAssistBot 등으로 위장하여 도착하기도 했습니다. 로그에 나타난 몇 가지 예시(데모 라인, 문서 범위의 주소):

203.0.113.24 - - [07/Oct/2026:10:14:02 +0000] "GET /cgi-bin/php-cgi.exe?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input HTTP/1.1" 404 512 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot"
203.0.113.24 - - [07/Oct/2026:10:14:02 +0000] "GET /.env HTTP/1.1" 404 512 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot"
198.51.100.7 - - [07/Oct/2026:10:14:02 +0000] "GET /@fs/etc/passwd?raw HTTP/1.1" 404 512 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; ChatGPT-User/1.0; +https://openai.com/bot"
...

워드프레스(WordPress) 사이트의 경우 이 모든 것이 404가 나오는 것이 올바른 답변입니다. 문제는 보고 방식에만 있습니다: 이를 모두 ChatGPT로 계산하면, 귀하의

클라이언트 IP를 OpenAI가 공개한 범위와 비교합니다. 이 스크립트는 그렇게 하여 실제 ChatGPT-User 요청과 가짜 요청을 분리하고, 더 유용한 작업을 수행합니다. 바로 사람이 방문하여 ChatGPT가 보낸 트래픽 중 404 에러 페이지에 도달한 경우를 찾아냅니다.

#!/usr/bin/env python3
"""액세스 로그의 ChatGPT 트래픽을 실제와 가짜로 분리합니다.

...

표준 라이브러리만 사용하며, Python 3.8 이상에서 작동합니다. 다음 형식으로 로그에 실행하세요:

python3 chatgpt_404s.py /var/log/nginx/access.log

작은 데모 로그(가상의 라인: OpenAI 목록의 실제 ChatGPT-User 주소 1개, 문서 범위에서 가져온 가짜 주소 2개, 그리고 방문자 몇 명)로 실행하면 다음과 같이 출력됩니다:

ChatGPT-User 요청
      2  실제 ChatGPT-User
      6  가짜 (OpenAI IP 범위를 따르지 않음)
...

프로덕션 로그에서 이 스크립트를 신뢰하기 전에 알아야 할 세 가지 사항:

• Cloudflare 또는 다른 프록시 뒤에 있다면, 실제 클라이언트 IP를 기록하세요. 그렇지 않으면 모든 요청이 프록시 주소에서 오기 때문에 모든 것이 가짜처럼 보입니다. nginx의 경우 real_ip_header CF-Connecting-IP와 set_real_ip_from에 Cloudflare 범위를 지정해야 합니다.
• 범위는 최신으로 가져오세요. OpenAI가 chatgpt-user.json을 업데이트합니다. 우리가 2026년 10월 10일에 가져온 사본은 날짜가 2026년 10월 7일이었습니다.
• Gzipped, 로테이션된 로그는 먼저 압축 해제해야 합니다 (zcat access.log.2.gz > access.log.2).

ChatGPT 방문자가 도달한 404 에러 페이지를 어떻게 찾나요?

봇이 아닌 클릭을 찾아보세요. 사람이 ChatGPT 답변의 링크를 클릭하면, 브라우저가 일반적인 브라우저 사용자 에이전트를 사용하여 요청을 보내고, ChatGPT는 URL에 utm_source=chatgpt.com을 추가합니다 (리퍼러 역시 종종 https://chatgpt.com/입니다). 이것이 바로 sent_by_chatgpt()가 일치시키는 내용입니다.

문제가 되는 것은 이들입니다. 2026년 9월 30일부터 10월 9일 사이에 ChatGPT 방문을 받은 323개의 소규모 비즈니스 웹사이트 중, 4,053개의 ChatGPT 방문 중 36개(약 113분의 1)가 404 에러 페이지에 도달했습니다. 우리가 10월 10일에 각 주소를 라이브 사이트와 Wayback Machine의 CDX 인덱스와 비교 확인했을 때, 그 비율은 다음과 같이 나뉘었습니다:

개발자가 주의를 기울여야 할 '깨진' 유형은 네 가지입니다: 페이지는 존재했지만, ChatGPT가 작성한 링크의 퍼센트 인코딩(percent-encoding)이 두 배로 되어 있거나(%가 있어야 할 곳에 %25), 바이트 하나가 변경되었거나, 중간에 바이트가 누락되어 유효한 UTF-8 형식이 아닌 경우입니다. 길고 인코딩된 슬러그는 모델이 깨뜨리는 부분인데, 이는 URL을 복사하는 대신 토큰 단위로 작성하기 때문입니다.

각 유형의 404 오류 페이지는 무엇을 반환해야 할까요?

같은 수정 사항들을 5분 이내에 따라 해보는 방법:

우리가 증명할 수 없었던 것들

• 우리의 69%는 IP 기반이 아니라 경로(path) 기반입니다. 우리는 요청한 내용으로 10월 7일의 탐색을 분류했을 뿐, 각 주소를 OpenAI의 범위와 비교하지 않았습니다. 위에 제시된 스크립트가 우리가 권장하는 방식이며, 연구에서 계산한 방식은 아닙니다.
• 10일은 첫 번째 읽기입니다. 36건의 죽은 페이지 방문은 패턴을 보여줄 뿐, 정확한 비율을 나타내지는 않습니다.
• CDN 리다이렉트는 우리에게 보이지 않습니다. Cloudflare나 웹 서버에 의해 수행되는 리다이렉트는 WordPress까지 도달하지 않기 때문에, 그곳에서 문제를 해결한 사이트는 깨끗해 보입니다.

소유자 입장에서의 이 부분은 코드가 없으므로, 저희 Medium 게시물에서 자세히 다루었습니다: ChatGPT로부터 온 죽은 링크: 여전히 삭제된 페이지로 고객을 보내고 있습니다।

LovedByAI의 플러그인은 WordPress 사이트에서 발생하는 모든 AI 추천 방문의 상태 코드(status code)를 기록하며, 위에서 언급된 4,053건의 방문이 바로 이 데이터에서 나온 것입니다. 만약 WordPress가 아니라면, 해당 스크립트는 원본 로그(raw logs)에서 동일한 목록을 가져옵니다.

원본 연구 및 전체 데이터셋: ChatGPT 깨진 링크: 왜 방문자들이 404 페이지에 도달하는가