서버 로그가 구글봇으로 도배됐습니다 — 진짜 크롤러인지 가리는 순서

"서버 로그에 구글봇이 하루 십만 건씩 찍힙니다. 막아도 되나요?" 이번 주에만 두 번 받은 질문입니다. 결론부터 말하면 그 로그의 상당수는 구글이 아닐 가능성이 높고, 진짜인지 아닌지는 유저에이전트로는 절대 알 수 없습니다. 그런데도 많은 현장이 로그에 찍힌 이름만 보고 방화벽 규칙을 만듭니다. 그러다 진짜 구글봇을 막으면 색인이 통째로 빠지고, 가짜를 그대로 두면 대역폭과 통계가 계속 오염됩니다. 판정 순서를 정리합니다.

유저에이전트는 증거가 아니라 자기소개입니다

User-Agent 헤더는 요청을 보내는 쪽이 스스로 적어 넣는 문자열입니다. 누구든 Googlebot/2.1이라고 적을 수 있고, 실제로 스크래퍼·취약점 스캐너가 차단을 피하려고 이 이름을 즐겨 씁니다. 구글 공식 문서도 크롤러 확인 항목에서 유저에이전트만으로 판단하지 말라고 명시합니다.

그래서 첫 작업은 차단 규칙 작성이 아니라 로그를 IP 단위로 다시 세는 일입니다. 유저에이전트에 googlebot이 들어간 요청을 뽑아 IP별로 집계하면, 보통 상위 몇 개 대역이 전체의 대부분을 차지합니다. 판정 대상은 십만 건이 아니라 그 몇 개 IP뿐입니다. 여기까지 오면 작업량이 실무 범위로 줄어듭니다.

1차 판정 — 역방향 DNS를 정방향으로 되돌린다

구글이 안내하는 수동 확인법은 두 번의 조회로 끝납니다. 먼저 해당 IP를 역방향 조회(host 66.249.x.x)해서 나온 호스트명이 googlebot.com·google.com·googleusercontent.com 중 하나로 끝나는지 봅니다. 그다음 그 호스트명을 정방향 조회해서 원래 IP로 되돌아오는지 확인합니다. 이 두 단계를 모두 통과해야 진짜입니다.

실무에서는 이 확인을 사람이 하지 말고 배치로 돌리는 편이 낫습니다. 접근 로그에서 봇 이름이 들어간 요청의 IP를 중복 제거해 뽑고, 각 IP에 두 번의 DNS 조회를 돌려 결과를 표로 남기면 됩니다. 한 번 만들어 두면 다음에 같은 문의가 왔을 때 십 분이면 답이 나옵니다.

두 번째 조회를 빼먹으면 안 됩니다. 역방향 DNS 레코드는 IP 소유자가 마음대로 적을 수 있어서, crawl-...googlebot.com 비슷한 이름을 자기 IP에 붙여 두는 사례가 있습니다. 정방향으로 되돌렸을 때 다른 IP가 나오거나 조회가 실패하면 가짜입니다.

2차 판정 — 공개된 IP 목록으로 한 번에 거른다

IP가 수십 개를 넘어가면 DNS 조회를 일일이 돌리는 대신 구글이 공개하는 IP 대역 파일을 씁니다. developers.google.com/static/crawling/ipranges/ 아래에 JSON으로 있고, 용도가 갈립니다.

• common-crawlers.json — 구글봇 본체. 오늘 기준 프리픽스 315개, 파일 갱신일 2026년 8월 21일.
• special-crawlers.json — AdsBot 등 특수 크롤러. 270개.
• user-triggered-fetchers-google.json — 사용자 동작으로 발생하는 구글 소유 IP. 494개.

이 파일들은 수시로 바뀝니다. 오늘 받아서 방화벽에 하드코딩하는 순간 그 규칙은 낡기 시작합니다. 주 1회 내려받아 갱신하는 스크립트로 돌리거나, 아예 IP 목록 대신 앞의 DNS 방식을 쓰십시오.

진짜인데 robots.txt를 안 지키는 요청도 있습니다

여기서 한 번 더 갈립니다. 구글 IP에서 왔는데 robots.txt를 무시하는 요청을 보고 "구글이 규칙을 어긴다"고 보고하는 경우가 있는데, 대개 사용자가 직접 촉발한 페치입니다. 서치콘솔의 URL 검사, 사이트 소유권 확인, 사용자가 누른 미리보기 같은 동작이 여기 해당하고, 공식 문서는 이 부류가 사용자 요청이므로 robots.txt 규칙을 따르지 않는다고 안내합니다.

이 부류에는 구글 소유가 아닌 IP 대역 파일(user-triggered-fetchers.json, 1,056개 프리픽스)도 따로 있습니다. 즉 "구글 IP가 아니면 가짜"라는 이분법도 정확하지 않습니다. 로그를 볼 때는 이름과 IP만이 아니라 어떤 종류의 요청인지를 같이 봐야 합니다. robots.txt와 색인 차단을 혼동하는 문제는 robots.txt와 noindex의 차이에서 따로 정리해 두었습니다.

AI 크롤러도 같은 절차로 가릅니다

최근 로그를 어지럽히는 쪽은 오히려 AI 크롤러입니다. 다행히 판정 방식은 같고, 주요 사업자들도 IP 목록을 공개합니다. OpenAI는 용도별로 세 파일을 두는데 학습용 GPTBot이 21개, 검색용이 35개, 사용자 요청으로 움직이는 ChatGPT-User가 204개 프리픽스입니다. 애플 Applebot은 33개, Perplexity는 8개입니다. 특히 애플 목록은 최근 대역이 크게 늘어서, 예전에 받아 둔 목록을 그대로 쓰고 있다면 정상 크롤러를 가짜로 판정하게 됩니다.

주의할 점은 이 목록이 "차단해도 되는 명단"이 아니라 "신원 확인용 명단"이라는 것입니다. 목록에 없는 IP가 AI 봇을 자처하면 가짜로 보면 되지만, 목록에 있다고 해서 그 트래픽이 우리에게 이득인지 아닌지는 별개의 판단입니다. 크롤러 종류별로 우리 콘텐츠가 어디에 쓰이는지부터 갈라 놓아야 차단 논의가 성립합니다.

요청에 서명을 붙여 신원을 증명하는 방식(Web Bot Auth)도 논의되고 있지만 아직 표준화 진행 단계입니다. 당분간은 DNS와 공개 IP 목록이 실무의 전부라고 보시면 됩니다. 무엇을 막을지 정하기 전에 AI 크롤러를 막으면 실제로 무엇이 사라지는지를 먼저 확인하시길 권합니다.

점검 순서 요약

1. 유저에이전트에 봇 이름이 들어간 요청을 IP별로 집계한다. 판정 대상은 상위 IP 몇 개뿐이다.
2. 상위 IP를 역방향 DNS로 조회해 호스트명 접미사를 보고, 정방향으로 되돌려 같은 IP가 나오는지 확인한다.
3. 수가 많으면 사업자 공개 IP JSON과 대조한다. 파일은 주기적으로 다시 받는다.
4. 구글 IP인데 robots.txt를 무시한다면 사용자 촉발 페치인지 먼저 본다. 차단 대상이 아니다.
5. 가짜로 확정된 대역만 차단한다. CDN 단에서 막을 때는 규칙이 정상 크롤러까지 걸지 않는지 확인한다. Cloudflare 기본값이 검색을 흔드는 지점은 Cloudflare 설정 점검에 정리돼 있다.
6. 차단 후 1~2주간 서치콘솔 크롤링 통계에서 요청 수와 응답 코드가 정상 범위인지 본다. 여기서 5xx나 급감이 보이면 규칙을 되돌린다.

로그에 찍힌 이름은 주장일 뿐입니다. 판정은 IP에서 하고, 차단은 판정이 끝난 뒤에 합니다. 이 순서만 지켜도 "봇 때문에 서버가 느리다"는 보고의 절반은 차단이 아니라 집계 오류로 정리됩니다.