본문 바로가기
서치뉴스SearchNews
검색
← 목록으로

AI 검색봇을 위한 서버 로그 분석 방법

moz.com조회수 01일 전

핵심

많은 팀이 AI 검색에 시간과 예산을 투자하고 있지만, 실제로 AI 봇이 우선순위 페이지에 도달할 수 있는지, 로딩을 완료하기 전에 포기하는지 확인하지 않는다. 서버 로그 파일에는 이 모든 답이 담겨 있다.

로그 파일이란

로그 파일의 각 줄은 기록된 요청 하나를 나타낸다. 사람이나 크롤러, 스크래퍼가 서버에 요청할 때마다 기록된다.

예시:

203.0.113.42 [12/Aug/2026:14:28:19] "GET /guides/pricing" 200 48213 "ChatGPT-User/1.0"

각 필드의 의미:

로그 파일은 이 줄을 수백만 번 반복한다. 분석 도구의 프롬프트 추적이나 레퍼럴 데이터는 사람이 클릭했는지만 보여주지만, 로그 파일은 봇이 실제로 페이지에 도달할 수 있었는지 기록한다.

여섯 개 요청, 다섯 가지 이야기

행 1~2: 성공

행 3: 대기 포기

행 4: 인간 사용자

행 5: 껍데기만 반환

행 6: 방화벽 차단

중요한 주의사항: 로그 파일은 끌어온 계층 내에서, 선택한 시간대 내에 캡처된 요청만 보여준다. CDN이 대부분의 요청을 캐시에서 응답하고 오리진 서버 로그만 보면 트래픽을 놓친다. 호스트명과 서브도메인을 샘플링에서 제외하면 완전하지 않은 데이터가 될 수 있다.

AI 검색을 위한 로그 파일 분석 6단계 프레임워크

1단계: 올바른 로그를 얻고 관리 가능한 샘플을 열기

로그 위치는 조직과 기술 스택에 따라 다르다. 세 곳에서 시작하는 것이 좋다:

팁: 먼저 샘플을 요청해야 한다. 몇 백 줄이면 파일이 열리는지, 도구가 형식을 읽을 수 있는지, 필요한 필드가 있는지 확인할 수 있다. 사용할 수 없는 40GB을 일주일 동안 내보내는 상황을 피하는 것이 좋다.

2단계: 올바른 데이터 요청하기

DevOps 팀에 "로그 파일"을 요청하면 몇 개 필드만 받을 수 있고 중요한 것들을 놓칠 수 있다.

필수 필드:

스택에 따라 다르지만 요청할 가치가 있는 필드:

샘플 이메일:

제목: SEO 분석을 위한 로그 파일 내보내기 요청

안녕하세요 [이름],

검색 엔진과 AI 크롤러가 우리 사이트에 접근하는 방식을 조사하고 있으며, 
액세스 로그부터 시작하고 싶습니다. 먼저 작은 샘플(수백 줄 정도)을 
끌어올 수 있을까요? 더 큰 것을 내보내기 전에 형식이 작동하는지 확인하고 싶습니다.

출처: [CDN — 예: Cloudflare, Akamai, Fastly] (있으면), 또는 [웹 서버 — 예: nginx, Apache]
도메인: [example.com 및 모든 서브도메인]

필수 필드:
- 클라이언트 IP 주소
- 요청된 URL과 요청 메서드 (GET, POST 등)
- 요청 날짜 및 시간
- 사용자 에이전트
- HTTP 응답 코드
- 전송한 바이트

가능하면:
- 응답 시간 (서버가 응답하는 데 걸린 시간)
- 캐시 상태 (HIT, MISS 등)

샘플이 확인되면 전체 분석을 위해 대략 [2주]의 데이터가 필요합니다. 
내보내기가 가장 쉬운 형식(CSV 또는 원본 로그 파일 모두 괜찮음)을 알려주세요. 
로그가 샘플링되거나 필터링되는 방식에 대해 알아야 할 사항이 있으면 알려주세요.

감사합니다!
[이름]

얼마나 많은 데이터가 필요한가? 완벽한 답은 없지만, 데이터가 요구사항을 충족하면 다음을 고려하자:

3단계: 파일을 열고 평가하기

데이터 웨어하우스가 필요하지 않다. 두 가지 옵션이 있다:

중요한 주의사항: 로그를 가져올 때 봇 검증을 활성화한다. Screaming Frog의 Log File Analyser에서 "Verify Bots When Importing Logs"를 찾아 지원되는 봇이 실제인지 확인한다. 다음 단계에서 이것이 왜 중요한지 설명한다.

로그가 이미 어딘가로 흐르면 특히 크롤 데이터에 연결되면 그것을 사용한다. 수백만 개 로그 행을 가진 대규모 사이트는 BigQuery와 SQL을 사용할 수 있지만, 시작하는 데는 필요하지 않다.

4단계: 누가 오는지 확인하기

로그 파일을 열면 누가 보이는지 파악하는 것부터 시작한다. 많은 사람이 여기서 실수하는데, AI 봇이 네 가지 범주로 나뉘고 각각 다른 목적으로 다른 일정에 따라 작동한다.

티어 1 훈련: 모델을 훈련시킬 텍스트 수집 티어 2 색인: AI 어시스턴트가 인용할 콘텐츠를 찾기 위해 검색하는 목록 구축 티어 3 라이브 페칭: 사람의 질문에 응답하여 페이지 가져오기 티어 4 행동: 에이전트가 사람을 대신해 사이트를 통해 작업

티어 3과 4의 차이는 티어 3은 페이지를 읽고 티어 4는 사이트를 사용한다는 것이다. 현재 에이전트는 대부분 평가한 후 인간에게 넘긴다. Google은 적격 판매자가 고객의 확인으로 구매를 완료하도록 하는 좁은 예외다.

2026년 10월 현재 각 그룹에서 볼 가능성 있는 봇 샘플이 있다. 이 이름들은 모델 출시와 새 플레이어 진입에 따라 변할 수 있고, 여기 나열되지 않은 작은 봇들도 많다:

도움되는 팁: 사용자 에이전트 이름에 "-User"가 있으면 보통 라이브 페칭을 의미하지만, 이를 명명 규칙으로 생각해야 한다. Google-Agent도 사용자 요청에 응답하여 행동하고 사용자 에이전트 문자열에서 식별한다. OpenAI의 브라우저 에이전트는 검증을 위해 서명된 요청 헤더를 사용한다.

이제 더 큰 문제가 나온다: 봇이 실제로 자신이 말하는 것이 맞는지 확인하기.

많은 사이트가 하는 두 가지 실수

함정 1: 잘못된 봇 차단하기 OpenAI를 예로 들자. GPTBot을 차단하면 OpenAI가 모델 훈련에 콘텐츠를 사용하지 않도록 지시한다. 이것은 정당한 비즈니스 결정이다. 하지만 OAI-SearchBot을 차단하면 ChatGPT 검색 답변에 콘텐츠가 나타나지 않을 수 있다. 광범위한 "AI 봇 차단" 규칙은 둘 다 차단할 수 있다.

robots.txt와 CDN 규칙을 검토하여 어떤 봇이 차단됐는지 알아낸다. 누군가 "AI 봇을 차단했다"고 말하면, 첫 번째 질문은 "어떤 것들?"이어야 한다.

함정 2: 봇이 자신을 뭐라고 하는지 믿기 사용자 에이전트는 요청자가 자신에게 주는 이름이다. 누구든지 브라우저나 크롤링 도구에서 "GPTBot"을 요청 헤더에 추가하여 재정의할 수 있다. 스크래퍼는 수치를 부풀릴 수 있고, 가짜 봇을 차단하기 위한 보안 규칙이 실제 봇을 실수로 차단할 수 있다.

봇 검증은 요청을 세기 전에 사기꾼을 표시하는 데 도움이 된다. 운영자에 따라 검증은 게시된 IP 범위 확인, DNS 레코드 확인, 또는 서명된 요청 헤더 검증을 포함할 수 있다.

5단계: 무엇을 봐야 하는가

이 글은 AI 봇에 중점을 두지만, 로그 파일 분석은 크롤 예산(crawl budget) 사용을 평가하고 기존 검색의 크롤링 비효율을 찾는 데도 도움이 된다. 특히 크롤 예산 최적화가 더 큰 역할을 하는 대규모 사이트에서는 로그 파일을 무시하지 말자.

로그를 열고 검증된 봇으로 필터링한 후, 세 가지 질문에 집중한다:

들어올 수 있는가?

확인할 두 가지 주요 사항:

두 목록 모두 생각보다 쉽게 컴파일할 수 있다. Moz Site Crawl을 사용해 일반 크롤을 실행하고 All Crawled Pages 보고서를 CSV로 내보낸 후, 스프레드시트나 로그 파일 분석기에서 URL을 로그 파일 데이터와 비교한다.

두 문제 모두에 대한 해결책은 기술 SEO에 속한다: 적절한 내부 링킹 전략과 XML 사이트맵.

무엇을 얻는가?

다음으로, 각 봇이 받는 HTTP 응답 코드를 본다:

사이트 전체가 아닌 봇별 오류율에 집중한다. 작은 오류율도 ChatGPT 같은 AI 어시스턴트에서 귀중한 라이브 트래픽을 잃을 수 있다.

조사하려면 403부터 시작한다. 의도하지 않은 방화벽 또는 봇 관리 규칙이 합법적인 요청을 차단할 수 있다.

기다려 주는가?

많은 감사가 이 질문을 건너뛴다. 봇과 폴더별 평균 응답 시간을 보고, 두 가지 패턴에 집중한다:

이는 중요하다. 검색 엔진 크롤러는 느린 페이지가 로드되기를 기다리거나 나중에 돌아올 수 있다. 질문에 답하는 어시스턴트는 사람이 답을 기다리고 있으므로, 서버가 콘텐츠를 전달하기 전에 포기할 수 있다.

이전 질문들은 봇이 페이지에 도달할 수 있는지에 집중했다. 이것은 충분히 오래 머물러서 읽을 수 있는지 묻는다. 여기서 499 상태 코드가 나온다.

6단계: 499 조사하기

앞의 로그 예제의 세 번째 행으로 돌아가자:

23.102.140.7  [12/Aug/2026:14:32:07 +0000] "GET /guides/pricing HTTP/1.1" 499 0 "-" "…ChatGPT-User/1.0" rt=31.412 cache=MISS

499 상태 코드는 "클라이언트 요청 닫음"을 의미한다. 요청자가 서버가 보내기를 완료하기 전에 끊었다.

이는 공식 HTTP 상태 코드가 아니다. nginx가 발명했고 많은 CDN과 로드 밸런서가 채택했다 (일부 시스템은 다른 라벨로 기록한다).

이 예제에서 ChatGPT-User는 캐시 미스에서 31초 이상 후 연결을 끊었고, 서버가 바이트를 전송하지 않았다. 응답 시간을 조사할 만한 가치가 있지만, 코드만으로는 요청자가 연결을 끊은 이유를 알 수 없다.

499가 로그에서 가장 흥미로운 상태 코드 중 하나인 이유다. 왜냐하면 다른 사람이 당신에 대해 한 결정을 기록하기 때문이다.

하지만 놓치기도 쉽다. 500대 서버 오류에 중점을 둔 모니터링은 499를 놓칠 수 있다. 한눈에 보면 방문자의 잘못처럼 보여 팀이 무시할 수 있다. 하지만 ChatGPT-User나 Claude-User에서 발생하면, 어시스턴트가 콘텐츠를 인용하지 않고 사용자의 질문에 답해야 할 수도 있다.

반복되는 499를 조사하는 방법

단일 499는 뭔가를 강력히 증명하지 못한다. 사람들은 브라우저 탭을 닫을 수 있고, 봇도 레이트 제한되거나 재시작될 수 있다. 다른 상태 코드처럼, 패턴을 찾자.

반복되는 499를 확인한다:

느린 서버의 증거로 모든 연결 끊김 요청을 취급하지 말자. 특히 다른 팀이 처리해야 할 때는 더욱 그렇다. 팀 동료에게 명확한 패턴과 뒷받침하는 데이터를 제공한다.

목표는 크롤러가 페이지를 받았는지 확인하는 것이다. 로그가 응답 코드, 전송한 바이트, 클라이언트가 연결을 끊었는지 보여준다. 문제 해결이 더 많은 인용이나 언급으로 이어지는지는 별개의 질문으로, Moz AI Visibility 같은 도구를 사용해 AI 답변에서 측정해야 한다.

로그 파일이 수정하도록 알려주는 것

보고 있는 것에 따른 수정 사항의 상위 목록:

실제 사이트에서는 어떻게 보이는가

몇 달 전, iPullRank의 클라이언트는 파일럿 프로그램으로 단기 영향을 증명해 달라는 명확한 요청이 있었다.

기술 부분부터 시작했고, 로그 파일에 액세스 제한 문제가 있었고, AI 크롤러 요청의 많은 부분이 499로 끝났다. 이를 여러 크롤링 가능성 문제와 함께 수정했다.

이를 콘텐츠와 측정을 다루는 더 광범위한 AI 검색 프로그램과 함께 실행했으므로, 로그 수정만의 결과라고 할 수 없다. 하지만 기술적 문제를 해결한 후, AI 가시성(AI visibility)은 다음 몇 달에 증가했다.

이것은 한 클라이언트만의 사례가 아니다

Profound와 파트너십으로 분석을 확대했고 2026년 4월에 700,000개 페이지를 살펴봤다:

iPullRank 사이트의 AI Citation vs Page Speed Analysis에서 더 자세한 조사 결과를 다룬다. 명확히 말하면, 이는 상관관계 분석이지 대조된 시험이 아니다.

맺으며: 적격은 새로운 순위

명확하고 권위 있으며 잘 구조화된 콘텐츠는 어시스턴트가 받을 때만 중요하다. 로그 파일은 페이지가 적격인지 확인하는 데 도움이 된다.

이번 주에 시작하는 방법:

  1. 한 개 이메일 보내기: DevOps에 작은 샘플을 요청한 후, 2단계의 여섯 개 필수 필드 + 응답 시간과 캐시 상태(가능하면)가 포함된 2주 치 로그를 요청한다.
  2. 로그 열기: Screaming Frog의 Log File Analyser 같은 도구를 사용한다. 지원하는 곳에서 봇 검증을 활성화하고 "-User" 에이전트와 Google-Agent의 검증된 요청을 우선시한다.
  3. 액세스 실패 조사: 우선순위 페이지의 403과 반복되는 499부터 시작한 후, 나머지 리다이렉트와 오류를 처리한다.