로그 파일 분석 (Log File Analysis)

로그 파일 분석은 웹 서버가 남긴 요청 기록을 검토해, 검색엔진과 AI 크롤러가 실제로 언제 어떤 URL을 방문했고 어떤 응답을 받았는지 확인하는 작업입니다. 서버가 요청을 받을 때마다 그대로 남긴 기록이라서, 검색엔진이 가공해서 보여주는 보고서보다 원본에 가깝습니다.

로그 파일 분석을 검색하면 보안 침해나 서버 장애 원인을 찾는 일반 IT 운영 목적의 로그 분석도 함께 나옵니다. 여기서는 검색엔진과 AI 크롤러의 방문을 확인하는 SEO 목적의 로그 분석만 다룹니다.

이 글은 Google 검색 센터와 Google Search Console 고객센터, Apache HTTP Server와 W3C의 로그 형식 공식 문서를 기준으로 작성했습니다. Ahrefs, Screaming Frog, Search Engine Land의 실무 자료도 참고했습니다.

로그 파일이 기록하는 요청 정보

각 방문은 서버 로그에 한 줄로 남습니다. 오랫동안 업계 관행으로 굳어진 형식은 Common Log Format이고, Apache 공식 문서는 이 형식을 클라이언트 IP, 인증 사용자, 요청 시간, 요청 라인, 상태 코드, 응답 크기 여섯 항목으로 정의합니다. 여기에 어느 페이지에서 왔는지 보여주는 Referer와 방문자를 식별하는 User-Agent를 더한 Combined Log Format을 실무에서 더 많이 씁니다. W3C도 별도로 Extended Log Format이라는 공식 표준을 발표해, 필요한 필드만 골라 기록할 수 있게 했습니다.

실제 로그 한 줄은 이런 모습입니다. 아래는 개인정보 없이 형식만 보여주는 가상 예시입니다.

66.249.66.1 - - [15/Aug/2026:09:12:03 +0900] "GET /glossary/log-file-analysis HTTP/1.1" 200 15320 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

이 한 줄만으로 어떤 IP가 언제 어떤 URL을 요청했고, 서버가 몇 번 상태 코드로 몇 바이트를 응답했는지, 요청자가 자신을 뭐라고 밝혔는지까지 알 수 있습니다. 로그 파일 분석은 이런 줄이 수천, 수만 개 쌓인 access log를 여는 데서 시작합니다.

로그 파일 분석으로 확인하는 정보

• 실제 크롤러 방문: Search Console이 요약해 보여주는 숫자가 아니라, 특정 URL을 어떤 크롤러가 언제 몇 번 가져갔는지 원본 기록으로 봅니다.
• 크롤 낭비: 중요하지 않은 URL에 요청이 몰리는지, 크롤 버짓이 어디서 새는지 페이지 단위로 짚어낼 수 있습니다.
• 오류 응답: HTTP 상태 코드가 4xx나 5xx로 반복되는 URL을 찾아 서버 문제를 먼저 손볼 수 있습니다.
• AI 크롤러 방문: GPTBot, ClaudeBot 같은 AI 크롤러가 실제로 사이트에 왔는지, 얼마나 자주 왔는지는 로그가 아니면 확인할 방법이 마땅치 않습니다. Search Console과 네이버 서치어드바이저는 각자의 검색 크롤러만 보여주기 때문입니다.

크롤링 통계 보고서와 로그 파일의 차이

Google Search Console의 크롤링 통계 보고서와 로그 파일은 둘 다 크롤러의 방문을 보여주지만, 집계 범위가 다릅니다. Google 고객센터 도움말은 robots.txt를 가져오지 못해 실제로 실행되지 않은 크롤링 시도도 크롤링 총계에 포함된다고 안내합니다. 보고서의 숫자는 Google이 시도한 요청까지 담고, 서버 로그는 실제로 서버에 도달한 요청만 담습니다.

Google 크롤링 흐름만 확인하고 싶다면 보고서로도 충분합니다. 그런데 AI 크롤러 방문이나 사칭 트래픽까지 보려면 로그를 직접 열어야 합니다.

진짜 크롤러인지 가려내는 법

로그에 남은 User-Agent 문자열은 이름만으로 신뢰할 수 없습니다. Googlebot이라고 적힌 요청도 실제로는 다른 프로그램이 이름만 흉내 낸 것일 수 있습니다.

Google 검색 센터 공식 문서도 User-Agent 확인을 진위 판별 방법으로 언급하지 않습니다. 대신 두 단계 확인을 요구합니다.

1. 로그에 남은 IP로 역DNS 조회를 실행해, 도메인이 googlebot.com, google.com, googleusercontent.com 중 하나인지 확인합니다.
2. 확인된 도메인으로 다시 순DNS 조회를 실행해, 원래 IP와 같은지 대조합니다.

방문마다 수동으로 조회하기 어렵다면, Google이 공개하는 크롤러별 IP 목록과 대조하는 방법도 있습니다. common-crawlers.json, special-crawlers.json, user-triggered-fetchers.json 같은 파일을 developers.google.com/static/crawling/ipranges/ 경로에서 내려받아 로그의 IP와 자동으로 맞춰볼 수 있습니다. Screaming Frog Log File Analyser 같은 도구는 이 대조 작업을 자동화해, Googlebot과 Bingbot의 스푸핑 여부를 바로 표시해 줍니다.

AI 크롤러도 같은 원리입니다. GPTBot, ClaudeBot처럼 각 운영사가 공개하는 IP 목록은 AI 크롤러 항목에서 정리했습니다. User-Agent만 보고 진짜라고 단정하지 말고, 의심되는 트래픽은 그 목록으로 다시 확인해야 합니다.

로그 파일 분석 진행 순서

1. 호스팅 서버나 CDN에서 access log를 내려받습니다. 기간이 너무 짧으면 크롤 주기를 놓치므로 최소 한 달 치는 모읍니다.
2. 검색엔진과 AI 크롤러의 User-Agent로 걸러 관련 요청만 추립니다.
3. IP를 역DNS나 공식 IP 목록과 대조해, 사칭이 아닌 진짜 크롤러 요청만 남깁니다.
4. URL별로 방문 빈도, 상태 코드, 마지막 방문 시각을 집계합니다.
5. 사이트맵이나 중요 URL 목록과 겹쳐 봐서, 방문이 뜸한 중요 URL과 낭비되는 URL을 가려냅니다.

자주 하는 실수는 두 가지입니다. User-Agent만 확인하고 IP 대조를 건너뛰는 것, 그리고 로그 기간이 며칠에 그쳐 크롤 패턴을 잘못 판단하는 것입니다.

함께 알아두면 좋은 용어

• 크롤링: 검색로봇이 URL을 발견하고 페이지를 가져오는 과정
• 구글봇: 구글 검색이 웹페이지를 발견하고 읽기 위해 쓰는 크롤러
• 크롤 버짓: Google이 한 사이트에서 크롤링하려는 URL 범위
• 크롤러빌리티: 크롤러가 페이지에 접근해 가져올 수 있는 상태
• AI 크롤러: AI 모델 학습, 검색 색인, 사용자 요청 처리를 위해 웹페이지에 접근하는 봇
• HTTP 상태 코드: 서버가 요청 처리 결과를 알리는 코드
• 구글 서치 콘솔: Google 검색에서 사이트 상태를 확인하는 도구

참고 문서

• Apache HTTP Server, Log Files
• W3C, Extended Log File Format
• Google 검색 센터, Google 크롤러 및 가져오기 도구의 요청 확인
• Google Search Console 고객센터, 크롤링 통계 보고서
• Ahrefs, Log File Analysis
• Ahrefs, How to Do an SEO Log File Analysis
• Screaming Frog, SEO Log File Analyser
• Screaming Frog, An SEOs Guide To W3C Log Files
• Search Engine Land, Log file analysis for SEO