- GeoAnalytics는 서버사이드 수집 방식으로 AI 봇의 사이트 방문을 페이지 단위로 측정하는 도구의 한 사례입니다.
- AI 봇 대부분은 자바스크립트를 실행하지 않으므로 GA·GTM 같은 태그 기반 분석 도구에는 원리적으로 기록되지 않습니다.
- 서버 측정 결과는 AI 봇이 어떤 페이지를 가져갔는지 확인한 사실일 뿐이며, AI 답변 인용을 보장하지 않습니다.
GA에 AI 봇 방문이 보이지 않는다고 해서 AI 봇이 오지 않았다는 뜻은 아닙니다. 태그 기반 분석은 브라우저가 자바스크립트를 실행해야 기록되는데, ChatGPT·Perplexity 등의 AI 봇 대부분은 이 스크립트를 실행하지 않기 때문입니다. 따라서 AI 봇 트래픽 측정은 요청이 서버에 도착하는 지점, 즉 서버사이드에서 해야 하며, 아래 체크리스트는 그 점검 순서를 정리한 것입니다.
목차
- 왜 GA·GTM에는 AI 봇 방문이 잡히지 않을까요?
- 서버사이드 AI 크롤러 측정은 어떤 원리로 이루어질까요?
- AI 봇 트래픽 측정 전에 무엇을 점검해야 할까요?
- 측정 결과는 어디까지 믿고 어떻게 해석해야 할까요?
- 자주 묻는 질문
왜 GA·GTM에는 AI 봇 방문이 잡히지 않을까요?
태그 기반 분석 도구는 방문자의 브라우저가 페이지 안의 스크립트를 실행해야 기록을 남기도록 설계되어 있으므로, 스크립트를 실행하지 않는 AI 봇은 집계 대상에서 빠집니다. 이는 GA·GTM의 결함이 아니라 사람 방문자의 행동을 분석하려는 도구의 설계 목적에서 나온 구조적 차이입니다. AI 봇은 HTML 문서를 내려받아 텍스트를 추출하는 데 집중하며, 화면을 그리거나 스크립트를 돌리는 단계를 대개 거치지 않습니다.
국제 인터넷 표준화 기구인 IETF의 HTTP 의미 규격(RFC 9110)은 User-Agent 헤더를 요청을 보낸 사용자 에이전트에 관한 정보를 담는 필드로 정의합니다. 이 헤더는 스크립트 실행 여부와 관계없이 모든 요청에 실려 서버에 도착하므로, 서버 쪽 기록에는 AI 봇의 방문 흔적이 남습니다.
| 구분 | 태그 기반 분석(GA·GTM) | 서버사이드 측정 |
|---|---|---|
| 기록 시점 | 브라우저가 스크립트를 실행한 뒤 | 요청이 서버에 도착한 순간 |
| AI 봇 기록 여부 | 스크립트 미실행 시 기록되지 않음 | 요청 자체가 기록됨 |
| 주요 용도 | 사람 방문자의 유입 경로·행동 분석 | 봇 포함 전체 요청 확인 |
| 식별 근거 | 쿠키·스크립트 이벤트 | User-Agent·IP 주소·요청 경로 |
서버사이드 AI 크롤러 측정은 어떤 원리로 이루어질까요?
서버사이드 AI 크롤러 측정은 웹 서버, 리버스 프록시, CDN처럼 요청이 반드시 거치는 지점에서 요청 정보를 수집하고, 그중 AI 봇에 해당하는 요청을 분류하는 방식입니다. 수집 대상은 요청 시각, 요청 경로(URL), User-Agent, 응답 상태 코드, 출발 IP 주소 정도이며, 이를 페이지 단위로 묶으면 어떤 AI 봇이 어떤 문서를 언제 가져갔는지 확인할 수 있습니다.
미국 국립표준기술연구소(NIST)의 컴퓨터 보안 로그 관리 지침(SP 800-92)은 조직이 효과적인 로그 관리 체계를 수립·구현·유지하는 데 필요한 실무 지침을 제공합니다. AI 봇 측정도 같은 원칙을 따르는 편이 안전하며, 어떤 지점에서 무엇을 얼마 동안 보관할지 먼저 정해 두어야 결과를 비교할 수 있습니다.
- 수집 지점: 원본 서버 접근 로그, 프록시·CDN 로그, 서버 미들웨어 중 하나 이상
- 분류 기준: 공개된 AI 봇 User-Agent 문자열과 운영사가 공개한 IP 대역 대조
- 집계 단위: 봇별·페이지별·기간별 요청 수와 응답 상태
직접 로그를 파싱하기 어려운 경우에는 이 과정을 대신 처리하는 도구를 쓰는 방법도 있습니다. 넥스트티의 GeoAnalytics는 서버사이드 수집으로 AI 봇 방문을 페이지 단위로 측정하는 사례이며, 무료로 시작할 수 있다고 안내되어 있습니다. 연동 방식과 세부 화면은 공식 안내에서 확인하는 것이 정확합니다. 서버사이드 방식의 AI 봇 트래픽 측정이 어떤 흐름으로 이루어지는지 살펴볼 때 참고할 수 있습니다.
AI 봇 트래픽 측정 전에 무엇을 점검해야 할까요?
측정을 시작하기 전에는 수집 지점, 식별 기준, 접근 정책, 개인정보 처리 네 가지를 먼저 확인해야 결과를 신뢰할 수 있습니다. 하나라도 빠지면 봇 요청이 누락되거나 사람 방문과 섞여 해석이 어긋납니다.
| 점검 항목 | 확인 질문 | 판단 기준 |
|---|---|---|
| 수집 지점 | CDN 캐시가 응답한 요청도 기록되는가 | 원본 서버 로그만 보면 캐시 응답이 빠지므로 CDN 로그 포함 여부 확인 |
| 봇 식별 | User-Agent만으로 판정하는가 | 문자열은 위조될 수 있으므로 공개 IP 대역 대조를 함께 적용 |
| 접근 정책 | robots.txt와 방화벽이 AI 봇을 막고 있지 않은가 | 의도하지 않은 차단 규칙이 없는지 측정 전 확인 |
| 응답 상태 | 봇 요청에 오류 코드가 반환되는가 | 4xx·5xx 비중이 높으면 수집 실패로 간주하고 원인 점검 |
| 개인정보 | IP 주소를 어떻게 보관하는가 | 보관 기간과 목적을 정하고 필요 시 가명 처리 |
접근 정책과 관련해 IETF가 표준화한 로봇 배제 프로토콜(RFC 9309)은 robots.txt를 크롤러가 따르도록 요청하는 규약으로 정의하며, 접근을 기술적으로 강제하는 수단은 아니라고 밝힙니다. 따라서 robots.txt 설정만으로 봇의 실제 방문 여부를 단정할 수 없고, 서버 기록으로 확인하는 과정이 필요합니다.
개인정보 측면에서는 개인정보보호위원회가 소관하는 개인정보 보호법이 다른 정보와 쉽게 결합하여 특정 개인을 알아볼 수 있는 정보도 개인정보에 포함된다고 정의합니다. 서버 로그에는 사람 방문자의 IP 주소도 함께 남으므로, AI 봇 분석 목적이라도 보관 범위와 기간을 내부 정책으로 정해 두는 것이 바람직합니다.
측정 결과는 어디까지 믿고 어떻게 해석해야 할까요?
서버사이드 측정 결과는 AI 봇이 특정 페이지를 가져갔다는 사실 확인이며, 그 페이지가 AI 답변에 인용된다는 약속이 아닙니다. 수집 기록은 GEO Signal, 즉 생성형 AI 검색 대응 상태를 읽는 여러 신호 가운데 하나로 다루는 것이 적절합니다.
| 관측 결과 | 읽을 수 있는 사실 | 단정할 수 없는 것 |
|---|---|---|
| 특정 페이지에 AI 봇 요청 다수 | 해당 문서가 수집 대상이 되었음 | 답변 인용 여부와 인용 빈도 |
| AI 봇 요청이 전혀 없음 | 측정 기간 동안 수집 흔적이 없음 | 영구적 미노출 여부 |
| 봇 요청에 오류 응답 반복 | 수집 시도가 실패했음 | 봇 운영사의 향후 재방문 일정 |
해석 절차는 다음 순서를 권합니다.
- 봇 이름별로 학습용 수집인지, 실시간 답변용 조회인지 운영사 공개 문서로 구분합니다.
- 페이지별 요청 수를 확인하고 수집되지 않은 핵심 페이지를 목록화합니다.
- 수집되지 않은 페이지의 차단 규칙, 응답 코드, 내부 링크 구조를 점검합니다.
- 개선 후 같은 기간 단위로 다시 측정해 변화를 비교합니다.
이 과정에서 GA·GTM은 사람 방문자의 유입과 전환을, 서버사이드 측정은 봇 수집 여부를 확인하는 도구로 나누어 쓰면 두 지표가 서로를 대체하지 않고 보완합니다.
자주 묻는 질문
GA 설정을 바꾸면 AI 봇 방문도 볼 수 있습니까?
태그 기반 분석은 스크립트가 실행되어야 기록되므로, 설정 변경만으로 스크립트를 실행하지 않는 AI 봇을 집계하기는 어렵습니다. AI 봇 방문은 서버 로그나 서버사이드 수집 도구로 확인하는 것이 원리에 맞습니다.
User-Agent에 GPTBot이라고 적혀 있으면 실제 OpenAI 봇이라고 볼 수 있습니까?
User-Agent 문자열은 누구나 임의로 적을 수 있어 그것만으로는 확정할 수 없습니다. 운영사가 공개한 IP 대역과 대조하거나 역방향 DNS 확인을 함께 적용해야 판정의 신뢰도가 높아집니다.
AI 봇 방문이 늘면 AI 답변 노출도 늘어납니까?
수집 증가는 문서가 AI 시스템에 전달될 기회가 생겼다는 뜻일 뿐, 인용을 보장하지 않습니다. 인용 여부는 AI 답변을 직접 관측하는 별도 측정으로 확인해야 하며, 봇 수집 기록은 그 원인을 점검하는 근거 자료로 활용합니다.