구글 검색 관계팀의 개리 일리예스가 "구글봇인 척하는 크롤러를 만드는 데는 아마 30초면 된다"고 말했다. 요청 헤더에 구글봇이라는 이름만 적으면 누구나 구글봇처럼 보일 수 있다는 뜻이다. 서버 로그나 방화벽에서 user-agent 문자열만 보고 구글봇을 통과시키는 사이트는 접근 허용 기준을 점검해야 한다.

이 발언은 2026년 10월 28일 유튜브 채널 Odys Podcast에 올라온 영상에서 나왔다. 진행자 아네타 삼코프와 크롤러 전반을 이야기하는 자리였다. 업계 매체 PPC Land가 10월 31일, 서치 엔진 라운드테이블의 배리 슈워츠가 10월 30일 이 내용을 각각 정리했다. 구글이 공식 문서로 낸 변경 발표가 아니라 구글 직원 한 사람의 팟캐스트 발언이라는 점은 구분해서 읽어야 한다. PPC Land도 인터뷰 내용은 일리예스 본인의 설명이며 독립적으로 측정한 결과가 아니라고 밝혔다.

user-agent는 가장 쉽게 속일 수 있는 신호

일리예스는 구글 크롤러가 스스로를 밝히는 방법을 세 겹으로 나눠 설명했다. 첫째는 요청마다 붙는 user-agent 헤더다. 그는 이 헤더가 "가장 눈에 띄는 방법이면서 가장 쉽게 속일 수 있는 방법"이라고 말했다. 크롬 개발자 도구에서 클릭 몇 번이면 user-agent를 구글봇으로 바꿀 수 있고, 스크립트로 크롤링할 때는 코드 한 줄이면 된다고 했다.

둘째는 요청한 IP 주소에 연결된 reverse DNS 기록이다. IP로 호스트 이름을 조회했을 때 googlebot.com 계열 이름이 나와야 한다. 셋째는 IP 주소 자체다. 일리예스는 이것이 지금 가장 가치 있는 방법이라고 했다. 구글, 빙, 애플, 오픈AI가 모두 크롤링 IP 대역을 공개하기 때문에, IP만 보면 요청이 어느 회사에서 왔는지 가릴 수 있다는 설명이다.

허니팟은 크롤러를 끌어들이려고 일부러 만든 미끼 사이트다. 로그에는 user-agent가 구글봇인데 IP는 어느 국가의 어느 데이터센터인지 알 수 없는 요청이 찍혔다고 한다. 다만 일리예스는 건수, 트래픽 비중, 기간을 밝히지 않았다. 사칭이 흔하다는 말은 본인의 관찰이지 공개된 통계가 아니다.

구글 공식 검증 절차는 한 단계가 더 있다

PPC Land는 구글 공식 문서가 일리예스의 설명에 없던 단계를 담고 있다고 짚었다. 2026년 3월 20일 갱신된 문서 "Verify requests from Google crawlers and fetchers"는 먼저 요청 IP로 reverse 조회를 하라고 안내한다. 나온 호스트 이름이 googlebot.com, google.com, googleusercontent.com 중 하나에 속하는지 확인하고, 그 호스트 이름으로 다시 forward 조회를 해서 원래 IP가 나오는지 봐야 한다. 마지막 forward 조회가 필요한 이유는 외부 IP 대역 운영자가 googlebot.com 이름을 단 reverse 기록을 마음대로 만들 수 있기 때문이다.

같은 문서는 크롤러 종류별 호스트 이름 형식과 IP 대역 파일도 안내한다. 일반 크롤러용 IP 범위는 common-crawlers.json부터 user-triggered-agents.json까지 JSON 파일 다섯 개로 공개된다. PPC Land에 따르면 일리예스는 2025년 3월 링크드인에서 이 파일의 갱신 주기를 주 1회에서 매일로 바꿨다고 발표했고, 1년 뒤 구글이 파일 위치를 developers.google.com/crawling/ipranges/ 아래로 옮겼다. 국내 운영자는 이 문서와 파일 위치를 직접 열어 확인하는 것이 안전하다.

사칭 크롤러가 위험한 이유

일리예스는 접속 자체보다 그 뒤를 걱정했다. 구글봇이 가져간 페이지는 검색에 쓰이지만, 사칭 크롤러가 가져간 콘텐츠는 어디에 쓰일지 알 수 없다는 것이다.

두 번째는 서버 부하다. 일리예스는 구글이 10년간 크롤러 인프라를 다듬어 사이트를 망가뜨리지 않으려 해왔다고 말했다. 반면 사칭 크롤러는 같은 URL을 짧은 시간에 수없이 반복 요청할 수도 있고, 한 번만 가져가고 사라질 수도 있다. 최악의 경우는 사이트가 내려가 실제 방문자가 접속하지 못하는 상황이라고 했다. 그는 요즘 피해는 악의보다 구현 미숙이나 무지에서 나오는 경우가 많다고 보았다.

배경으로는 AI를 꼽았다. 자체 모델 학습용 콘텐츠를 모으려는 회사가 늘면서 인터넷을 "큰 농장"처럼 수확하려는 시도가 많아졌다는 것이다. 방화벽과 CDN이 가짜 크롤러를 점점 잘 가려내지만 완벽하지는 않다고도 했다.

robots.txt는 보안 장치가 아니다

일리예스는 robots.txt를 "제안"이라고 불렀다. 구글, 빙 같은 대형 크롤러는 규칙을 따르지만, 규칙을 모르거나 일부러 무시하는 크롤러는 막을 수 없다는 설명이다. 그는 "막고 싶다면 네트워크 수준의 수단이 필요하다"고 말했고, 이 역할을 웹 애플리케이션 방화벽(WAF)이 한다고 했다. 서치 엔진 라운드테이블은 이 발언을 근거로 불필요한 트래픽을 차단하려면 CDN이나 WAF 같은 네트워크 수준 보호를 쓰라고 정리했다.

검색 접근과 AI 활용을 나누는 방법도 언급됐다. 사이트는 구글봇의 검색용 크롤링은 허용하면서 robots.txt의 Google-Extended 토큰으로 구글 AI 모델 학습 등에 쓰이는 것을 제한할 수 있다. 일리예스는 애플에도 비슷한 Applebot-Extended 토큰이 있고, 자동화 클라이언트 유형별 접근 통제가 앞으로 더 세분화될 수 있다고 내다봤다.

암호화 서명 시험은 아직 초기 단계

일리예스는 Web Bot Auth도 소개했다. 요청에 암호화 서명을 붙이고, 사이트가 공개 키로 그 서명을 확인해 요청이 주장하는 조직에서 왔는지 검증하는 방식이다. 서치 엔진 라운드테이블은 IP 주소 관리가 어렵고 비싸지는 흐름에서 인증이 단순해질 수 있다고 전했다. 크롤러 평판 점수 아이디어도 나왔지만 일리예스 스스로 초기 단계 구상이라고 했고, 한 회사가 운영하면 편향이 생길 수 있다고 경계했다.

일리예스는 사람 한 명을 대신해 페이지 하나를 가져오는 에이전트는 사용자가 직접 열 수 있는 페이지를 가져오는 것이므로 robots.txt를 따를 이유가 약하다고 말했다. 본인도 이 주장이 논쟁거리라고 인정했다. PPC Land는 구글이 2026년 3월 20일 Google-Agent를 사용자 요청형 가져오기 목록에 추가하면서 같은 취지로 robots.txt를 따르지 않는다고 밝혔다고 전했다. 출판사들은 이 전제에 반발하고 있다.

국내 운영자는 무엇을 보면 되나

일리예스의 발언은 user-agent 문자열만으로 구글봇을 허용하는 것이 안전하지 않다는 일반 원칙이다. 국내 사이트도 같은 원칙이 적용되는지는 각자의 방화벽, CDN, 로그 설정에 달려 있다.

서치 엔진 라운드테이블이 정리한 점검 항목은 다음과 같다. 구글이 공개한 크롤러 IP 대역과 reverse DNS로 구글봇을 검증하고, 서버 로그에서 의심스러운 크롤링 패턴과 낯선 IP, 비정상적으로 잦은 요청을 살피고, 원치 않는 봇이 성능을 위협하면 CDN이나 WAF로 네트워크 수준에서 막고, robots.txt는 규칙을 지키는 크롤러에게만 효과가 있다고 전제하라는 것이다. 일리예스는 작은 사이트라면 봇 트래픽이 실제로 문제가 되는지부터 확인하고, 필요하면 봇 관리 기능이 있는 CDN으로 시작하라고 조언했다.

운영 중인 사이트가 user-agent에 구글봇이 들어 있다는 이유만으로 요청을 통과시키는지, 구글이 공개한 IP 대역과 대조하는지부터 확인하면 된다. 확인 기준은 구글 공식 문서 "What is Googlebot and how to verify Googlebot requests"와 "Verify requests from Google crawlers and fetchers"에 있다.