GA4에서 AI 봇 방문을 찾아내는 방법: 사람의 방문과 어떻게 구분할까요?

AI 크롤러 종류와 구분 방법 글에서는 AI 봇이 하는 일에 따라 이름이 나뉘고, 그 이름은 서버 로그에만 남는다는 점을 다뤘습니다. 그렇다면 서버 로그를 볼 수 없는 담당자는 GA4만으로 AI 봇의 방문을 얼마나 가려낼 수 있을까요?

실제 웹사이트의 GA4에서 기술 세부정보 보고서의 화면 해상도 목록을 보다가 412x732라는 값이 눈에 띄었습니다. 활성 사용자 순으로는 19번째 줄이었는데, 참여율이 0.27%였습니다. 바로 위아래 줄의 참여율이 60~70%대인 것과 비교하면 사실상 아무도 페이지를 읽지 않은 셈입니다.

이런 숫자를 보면 AI 봇을 먼저 떠올리게 됩니다. AI가 사람 대신 웹사이트를 방문하는 일은 이미 흔해졌습니다. 오픈AI가 2026년 9월 3일 공개한 GPT-6 Astra는 온라인 폼 작성과 CRM 고객 기록 업데이트를 대표 용례로 소개했고, Aside처럼 AI 에이전트를 기본으로 넣은 브라우저도 나와 있습니다. 이 글에서는 실제 트래픽을 통해 이런 방문을 얼마나 찾아낼 수 있는지 살펴봅니다. 표준 보고서와 탐색 분석을 오가며 어떤 근거로 봇 추정 그룹을 좁혔는지, 어디서 분석을 멈출 수밖에 없었는지, 그리고 같은 확인을 우리 사이트에서 해 보는 순서를 차근차근 알아보겠습니다.

GA4에서는 봇의 이름을 볼 수 없습니다

GA4에서 직관적으로 봇의 정체를 확인하려고 하면 할 수 있는 게 없습니다. 서버 로그라면 User-Agent(방문한 브라우저나 프로그램이 요청마다 스스로 밝히는 이름 문자열)를 열어 GPTBot인지 ClaudeBot인지 읽으면 되지만, GA4에는 이 정보가 없습니다. 표준 보고서와 탐색 분석, Data API, BigQuery 내보내기 어디에도 User-Agent 원문과 IP 주소는 남지 않습니다. GA4에 남는 것은 오로지 브라우저 이름, 운영체제, 지역처럼 원본에서 뽑아낸 값뿐입니다.

GA4가 봇을 자동으로 걸러 주는 기능도 이 문제를 해결해 주지 않습니다. 구글 도움말은 이렇게 설명합니다.

알려진 봇 및 스파이더의 트래픽은 자동으로 제외됩니다. (…) 현재는 알려진 봇 트래픽 제외를 사용 중지하거나 알려진 봇 트래픽이 얼마나 제외되었는지 확인하는 것이 불가능합니다.

애널리틱스 고객센터 | 알려진 봇 트래픽 제외

즉, 이 기능은 끌 수도 없고 얼마나 걸러졌는지도 볼 수 없습니다. 구글은 걸러 낼 봇을 정할 때 자체 연구와 인터넷광고협회(IAB)가 관리하는 국제 스파이더 및 봇 목록을 함께 쓴다고 밝히고 있습니다. 다만 이 목록은 IAB 회원도 연 5,000달러부터, 비회원은 연 15,000달러를 내야 볼 수 있는 유료 자료라서, 특정 크롤러가 목록에 들어 있는지 외부에서 확인하기 어렵습니다. 걸러 내는 기준도, 남은 트래픽의 정체를 밝힐 원본 정보도 없습니다. 그래서 봇의 이름을 알아내는 대신 남은 정보로 봇을 추정하는 방법을 택했습니다.

첫 단서는 사람이 보통 쓰지 않는 화면 크기였습니다

GA4에서 기기와 관련해 볼 수 있는 측정기준은 브라우저, 운영체제, 기기 카테고리, 화면 해상도 정도입니다. 이 가운데 브라우저 이름은 봇을 구분하는 데 큰 도움이 되지 않습니다. 자동화 도구 대부분이 크롬과 같은 크로미움 엔진을 쓰기 때문에, 봇도 사람과 똑같이 크롬으로 기록되는 경우가 많습니다.

화면 해상도는 다릅니다. 사람이 쓰는 노트북과 모니터, 스마트폰은 제조사가 정한 규격으로 나오기 때문에, 해상도 목록을 사용자가 많은 순으로 정렬하면 위쪽은 익숙한 규격으로 채워집니다. 반면 자동화 도구는 창 크기를 따로 지정하지 않으면 도구의 기본값을 씁니다. 예를 들어 Puppeteer(크롬을 코드로 조작하는 도구)의 기본 화면 크기는 800x600이고, Playwright는 1280x720입니다. 기본값이 흔한 해상도와 같으면 사람의 방문과 구분하기 어렵지만, 흔하지 않은 값이면 해상도 목록에서 눈에 띕니다.

다만 해상도만 보면 흔하지 않은 기기를 쓰는 사람까지 함께 걸립니다. 그래서 참여율을 같이 봤습니다. 참여율은 10초 넘게 머물렀거나, 주요 이벤트가 발생했거나, 페이지를 2회 이상 본 세션의 비율입니다. 화면 크기가 특이한 기기를 쓰는 사람이라도 글을 읽는 행동은 다른 방문자와 비슷할 것이므로, 해상도가 낯설면서 참여율까지 0에 가깝다면 기기 때문에 생긴 차이로 보기 어렵습니다.

보고서 메뉴에서 [사용자], [기술], [기술 세부정보]를 차례로 열고, 측정기준을 화면 해상도로 바꾼 뒤 [페이지당 행 수]를 25로 늘렸습니다. 결과는 이렇게 정리됩니다.

412x732의 참여율 0.27%는 세션 370건 가운데 1건꼴로만 참여 세션 조건을 채웠다는 뜻입니다. 상위 25줄 가운데 참여율이 59%보다 낮은 줄은 412x732 하나뿐이었습니다. 412x732는 크롬 개발자 도구의 기기 목록에 2015년에 나온 스마트폰 넥서스 5X, 넥서스 6 등의 화면 크기로 오래 등록돼 있던 값입니다. 2026년 7월 개발자 도구 소스에서 이 기기들은 목록에서 빠졌습니다.

412x732가 들어 있는 실제 보고서 화면은 아래 이미지와 같습니다.

같은 기준으로 목록을 더 내려가자 1280x1280(참여율 16.1%)이 나왔습니다. 세션 수는 적지만 참여율이 한 자릿수인 1280x1200(참여율 7.1%)과 1600x1600(참여율 0%)도 함께 찾았습니다. 1600x1600은 정사각형이라 시중에서 이런 모니터를 찾기 어렵습니다. 이 네 해상도의 세션을 합치면 같은 기간 전체 세션의 0.73%입니다. 이 비율은 GA4가 알려진 봇을 이미 걸러 낸 뒤에 남은 트래픽 기준이라는 점도 함께 봐야 합니다.

Puppeteer의 기본값인 800x600도 목록에 있었지만 참여율이 26.4%로 판단하기 애매했습니다. 800x600은 국가별로 나눠 보면 성격이 달라집니다.

봇으로 보이는 방문은 하나의 그룹일까요?

다음으로 확인할 것은 이 트래픽이 하나의 그룹인지였습니다. 같은 주체가 해상도만 바꿔 가며 들어온다면 하나로 묶어서 보면 되지만, 서로 다른 주체라면 따로 봐야 합니다. 표준 보고서는 측정기준을 두 개까지만 함께 볼 수 있어서, 여기서부터는 탐색 분석의 자유 형식을 썼습니다. 행에 화면 해상도와 국가를 넣고, 값에 세션수와 참여율을 넣은 뒤, 필터에서 화면 해상도가 정규식 ^(412x732|1280x1280|1600x1600|1280x1200|800x600)$과 일치하는 행만 남겼습니다. 결과는 이렇게 정리됩니다.

412x732는 거의 모든 세션의 국가가 (not set)이었습니다. GA4가 IP 주소로 지역을 판정하지 못했다는 뜻입니다. 1280x1280은 모든 세션이 미국, 1600x1600은 모든 세션이 중국에서 들어왔습니다. 해상도마다 지역이 하나씩 짝지어지므로, 한 그룹이 해상도를 바꿔 가며 들어온다기보다 서로 다른 그룹이 따로 들어온다고 보는 편이 맞습니다. 1280x1200은 여러 나라로 흩어져 있었는데, 세션이 적어 지역만으로는 묶기 어려웠습니다.

이 부분에서 한 번 멈출 필요가 있습니다. 800x600은 국가별로 참여율이 크게 달랐습니다. 한국에서 들어온 세션은 참여율이 6%였지만, 미국과 네덜란드에서 들어온 세션은 47~69%였습니다. 같은 해상도 안에 사람과 자동화 도구가 섞여 있다는 뜻이라, 800x600 전체를 봇으로 분류하면 사람의 방문까지 함께 빠집니다. 412x732도 한국에서 들어온 소수의 세션은 참여율이 62.5%였습니다. 그래서 해상도는 후보를 찾는 데만 쓰고, 봇인지는 지역과 참여율을 함께 보고 판단했습니다.

행에 운영체제와 브라우저, 언어를 추가하면 그룹 사이의 차이가 더 분명해집니다.

412x732는 운영체제와 브라우저까지 모두 (not set)이었습니다. 화면 크기는 스마트폰인데 기기 카테고리는 데스크톱으로 기록됐습니다. 사람이 쓰는 브라우저라면 적어도 브라우저 이름은 남기 때문에, 이 조합은 사람의 방문으로 보기 어렵습니다.

그룹마다 무엇을 보러 오는지는 방문 페이지에서 어느 정도 드러납니다. 방문 페이지 경로를 개별 콘텐츠, 첫 화면, 태그 목록, 그 밖의 목록으로 묶어 비중을 비교했습니다.

412x732는 99%가 개별 콘텐츠 페이지로 들어왔습니다. 사이트 전체도 87%가 개별 콘텐츠 페이지로 들어오므로, 이 비중만으로는 이상하다고 보기 어렵습니다. 차이는 유입 경로에 있었습니다. 412x732 세션의 99.5%가 직접 유입이었습니다. 검색으로 들어오는 사람과 같은 페이지에 도착하면서도 거쳐 온 곳이 없으니, 방문할 페이지 주소를 미리 알고 들어온 것으로 보입니다. 반면 1600x1600은 42%가 태그 목록 페이지로 들어왔는데, 사이트 전체에서 태그 목록으로 들어오는 비중은 0.1%입니다. 800x600 가운데 한국에서 들어온 세션은 89%가 첫 화면으로 들어왔고, 사이트 전체의 첫 화면 비중은 1%입니다.

물론 방문 페이지만으로 봇의 의도를 단정할 수는 없습니다. 방문 페이지는 결과일 뿐 의도를 보여 주는 증거가 아니기 때문입니다. 다만 들어오는 페이지가 그룹마다 확실히 다르므로, 각 그룹이 서로 다른 방식으로 사이트를 방문한다고 볼 수 있습니다.

*주의: 탐색 분석은 속성의 데이터 보관 기간 안에 있는 데이터만 보여 줍니다. 보관 기간 기본값은 2개월이고, 이번 분석에서도 탐색 분석은 7월 26일 이후만 고를 수 있었습니다. 보관 기간을 14개월로 늘려도 이미 지난 데이터는 돌아오지 않습니다. 표준 보고서는 보관 기간과 관계없이 집계된 결과를 보여 주므로, 몇 달 단위의 추세는 표준 보고서로 확인해야 합니다.

사람의 방문이 아니라고 판단한 근거는 무엇일까요?

여기까지는 정황이라서 근거가 더 필요했습니다. 그래서 사람이라면 값이 제각각일 수밖에 없는 지표를 골랐습니다. 사람마다 읽는 페이지 수가 다르고, 사이트를 다시 찾는 주기도 다릅니다. 이런 지표가 한 값에 몰려 있다면 사람의 행동으로 보기 어렵습니다.

먼저 세션당 조회수는 네 그룹 모두 1이었습니다. 페이지 하나만 열고 그대로 나갔다는 뜻입니다. 사람이라면 마음에 드는 글은 한 페이지 더 보고 아닌 글은 바로 닫기 때문에 값이 흩어지기 마련인데, 봇 추정 그룹에는 예외가 없었습니다. 신규 사용자 비율도 99.9%였습니다. 쿠키를 저장하지 않아서 방문할 때마다 처음 온 사용자로 기록된다는 뜻으로, 몇 달 동안 꾸준히 방문하면서도 매번 새 사용자로 집계되고 있었습니다.

시간대도 비교했지만, 기대만큼 분명한 단서는 아니었습니다. 사람이 자는 시간에도 움직이는지 보려고 자정부터 오전 7시 사이의 세션 비중을 비교했는데, 봇 추정 그룹은 9.5%, 사이트 전체는 9.1%로 거의 같았습니다.

봇 추정 그룹의 시간대별 비중은 사이트 전체와 비슷했고, 오후 3시에 세션의 11.8%가 몰린 점만 달랐습니다. 다만 시간대가 사람과 비슷하다고 해서 사람의 방문이라는 근거가 되지는 않습니다. 사람이 요청할 때마다 함께 움직이는 도구라면 사람의 생활 시간을 그대로 따르기 때문입니다. 그래서 새벽 비중은 확인하되, 높지 않다는 이유로 봇 추정 그룹에서 빼지는 않았습니다.

정리하면 봇 추정 그룹은 페이지 하나만 보고, 쿠키를 저장하지 않고, 거쳐 온 곳 없이 들어오는 방문입니다. 시간대는 이 판단을 보조하는 지표로만 썼습니다.

봇 트래픽은 몇 달 사이 얼마나 늘었을까요?

이런 트래픽이 최근에 생긴 일인지도 확인했습니다. 데이터 보관 기간 때문에 탐색 분석에서는 7월 26일 이전을 볼 수 없어서, 월별 추세는 표준 보고서 기준으로 정리했습니다. 1월과 2월은 전체 세션이 적고 10월은 12일까지만 집계되어 표에서 뺐습니다.

세션 수로 보면 봇 추정 트래픽은 3월부터 9월까지 28배로 늘었습니다. 그런데 비중만 보면 2.2%에서 0.6%로 오히려 줄었습니다. 같은 기간 사이트 전체 세션이 100배 넘게 늘어나 분모가 더 빨리 커졌기 때문입니다. 비중만 보면 봇 트래픽이 줄었다고 잘못 판단할 수 있으므로, 세션 수의 변화와 비중을 함께 봐야 합니다.

그룹의 구성도 달라졌습니다. 해상도별로 처음 기록된 날짜를 찾으면 그룹이 새로 생긴 시점이 보입니다. 2월에는 한 그룹뿐이었는데, 7월까지 세 그룹이 더 생겼습니다. 1280x1280은 처음 기록된 7월보다 9월의 세션이 5.5배 많았습니다. 전체가 고르게 늘어난 것이 아니라 새로운 그룹이 하나씩 추가되면서 늘어난 셈입니다. 그룹마다 처음 기록된 날이 다르다는 점도 서로 다른 주체로 보는 근거가 됩니다. 가장 큰 그룹인 412x732는 전체 세션이 늘 때 함께 늘었지만, 늘어나는 속도는 전체보다 느렸습니다.

AI를 거쳐 들어온 사람은 따로 봐야 합니다

AI 트래픽이라는 말에는 보통 두 가지 의미가 있습니다. 사람 대신 AI가 직접 방문한 트래픽과, AI 답변을 읽은 사람이 링크를 눌러 들어온 트래픽입니다. 지금까지는 전자의 경우를 봤으니 후자의 경우도 함께 정리합니다. 보고서 메뉴의 트래픽 획득에서 세션 기본 채널 그룹을 보면 결과가 정반대로 나옵니다.

AI Assistant 채널은 전체 세션의 0.38%로 작지만, 참여율은 자연 검색과 비슷하고 세션당 평균 참여 시간은 18초 더 길었습니다. 출처별로는 제미나이(gemini.google.com)가 이 채널 세션의 58%, 챗GPT(chatgpt.com)가 25%, 클로드(claude.ai)가 9.5%, 퍼플렉시티(perplexity.ai)가 5%를 차지했습니다. GEO 전략 글에서 AI 유입의 질이 좋다는 해외 조사를 소개하며 각자 사이트에서도 같은 패턴이 나오는지 한 달만 관찰해 보라고 적었는데, 이번에 아홉 달 치 실제 데이터로 확인한 결과도 같은 방향이었습니다.

채널 분류에서 확인한 점도 있습니다. 구글 도움말은 AI 어시스턴트 채널의 예시로 챗GPT, 제미나이, 딥시크, 코파일럿, 그록을 들고 있고, 퍼플렉시티와 클로드는 없습니다. 그런데 이번 데이터에서는 두 서비스 모두 ai-assistant 매체로 분류되고 있었습니다. 도움말의 예시 목록이 실제 분류 기준의 전부는 아니라는 뜻입니다. 반대로 소스가 perplexity인데 매체가 비어 있는 세션은 AI 어시스턴트가 아니라 Unassigned로 분류됐습니다. 이 채널은 매체가 ai-assistant인 세션만 모으기 때문에, 매체 값이 비어 있으면 같은 서비스에서 들어왔더라도 빠집니다. 채널 분류 규칙은 AI 어시스턴트 채널 글에서 자세히 다룹니다.

두 결과를 함께 놓고 보면, AI를 거쳐 온 사람은 자연 검색으로 온 사람보다 오래 머물고, 사람이 아닌 방문은 몇 달 사이 28배로 늘었습니다. 둘 다 AI가 만든 변화이지만, 앞의 것은 키워야 할 유입이고 뒤의 것은 따로 떼어 봐야 할 트래픽입니다.

GA4로는 확인할 수 없는 방문

지금까지 확인한 내용을 정리하면 이렇습니다. 사람으로 보기 어려운 방문이 서로 다른 네 그룹으로 나뉘어 들어오고, 그룹마다 지역과 운영체제, 언어, 방문 페이지가 다르며, 몇 달 사이 새로운 그룹이 늘었습니다. 반면 이 방문이 AI 회사의 크롤러인지, 가격 비교나 SEO 도구의 수집기인지, 보안 점검 도구인지는 GA4로 알 수 없습니다. 처음에 말씀드린 것처럼 봇의 이름을 확인하려면 결국 User-Agent가 필요하기 때문입니다.

서버 로그에서도 User-Agent는 요청을 보내는 쪽이 마음대로 적을 수 있으므로, 로그에 남은 IP를 AI 회사가 공개한 IP 대역과 대조해야 진짜 봇인지 가려낼 수 있습니다. 이 확인 방법은 AI 크롤러 종류와 구분 방법 글에서 다뤘습니다.

그리고 이 글의 방법으로는 보이지 않는 방문도 있습니다. 사용자의 브라우저 안에서 AI가 움직이는 경우입니다. 오픈AI는 2025년 10월 21일 출시한 AI 브라우저 챗GPT Atlas를 2026년 8월 9일에 종료하고, 같은 기능을 챗GPT 데스크톱 앱과 크롬 확장 프로그램으로 옮겼습니다. 앤트로픽의 Claude in Chrome도 사용자의 크롬 안에서 페이지를 읽고 클릭하는 확장 프로그램입니다. 글 첫머리에서 언급한 Aside는 크로미움 기반의 별도 브라우저로, 사용자가 이미 로그인해 둔 웹사이트에서 그대로 작업한다는 점을 강점으로 내세웁니다. 사이트를 운영하는 입장에서는 바로 그 점 때문에 사람과 구분하기가 어렵습니다.

이런 방문은 사용자의 브라우저에서, 사용자의 로그인 상태로, 사용자의 IP로 들어옵니다. 자바스크립트가 정상적으로 실행되니 GA4 이벤트도 사람과 똑같이 기록되고, 해상도는 사용자의 모니터 크기를, 시간대는 사용자의 생활 시간을 따릅니다. 이 글에서 쓴 방법으로는 하나도 구분되지 않습니다.

AI 에이전트의 방문을 식별하려는 시도는 인프라 쪽에서 진행되고 있습니다. 챗GPT의 클라우드 브라우저는 요청마다 HTTP 메시지 서명(RFC 9421)을 붙이고, 이 서명 방식을 다루는 문서는 2026년 9월 1일 국제 인터넷 표준화 기구 IETF의 webbotauth 작업반 문서로 채택되었습니다. 문제는 이 정보가 모두 요청 헤더에 담긴다는 점입니다. GA4는 요청 헤더를 보지 못하므로, 식별 수단이 생겨도 그 결과가 GA4 보고서에는 나타나지 않습니다. 서버사이드 GTM을 쓰면 서버사이드 GTM이 받은 요청의 헤더를 읽어 판정한 뒤 결과만 짧은 값으로 GA4에 넘길 수 있지만, 원본 문자열을 그대로 보내면 일반 속성 기준 이벤트 매개변수 값의 100자 한도에 걸려 잘립니다.

AI가 사이트에 접근하는 방식별로 서버 로그와 GA4에 기록이 남는지는 이렇게 정리됩니다.

AI가 웹을 방문하는 일이 쉬워질수록 그 방문은 별도의 프로그램이 아니라 사람이 쓰던 브라우저를 통로로 삼게 되고, 그만큼 GA4에서는 사람과 같아 보입니다. 이 글의 방법으로 구분할 수 있는 범위도 그만큼 줄어듭니다.

우리 사이트에서 봇 트래픽을 확인하는 순서

이번 분석 과정을 담당자가 그대로 따라 할 수 있도록 순서대로 정리했습니다. 1~3단계는 표준 보고서, 4~9단계는 탐색 분석, 10단계는 다시 표준 보고서에서 진행합니다.

1. 보고서에서 [사용자], [기술], [기술 세부정보]를 차례로 열고 기간을 최대한 길게 잡습니다
2. 표의 측정기준을 화면 해상도로 바꾸고, [페이지당 행 수]를 25 이상으로 늘린 뒤 참여율 열을 함께 봅니다
3. 사용자가 어느 정도 있는데 참여율이 한 자릿수인 줄을 적어 둡니다
4. 탐색에서 자유 형식을 만들고, 측정기준(화면 해상도, 국가, 운영체제, 브라우저, 언어, 방문 페이지 + 쿼리 문자열, 시간)과 측정항목(세션수, 참여율, 세션당 조회수, 새 사용자 수, 총 사용자)을 가져옵니다
5. 필터에 화면 해상도를 넣고 조건을 [다음 정규 표현식과 일치함]으로 골라, 3단계에서 적어 둔 해상도만 남깁니다
6. 행을 화면 해상도와 국가로 둡니다. 해상도마다 지역이 하나로 모이면 서로 다른 그룹으로 보고, 여러 나라로 흩어지면서 참여율이 높은 나라가 섞여 있으면 해상도만으로 봇이라고 판단하지 않습니다
7. 행에 운영체제, 브라우저, 언어를 추가하고 세션당 조회수와 새 사용자 수를 봅니다. 세션당 조회수가 1이고 새 사용자 수가 총 사용자와 같으면 자동화된 방문일 가능성이 높습니다
8. 행을 방문 페이지로 바꿔 그룹마다 무엇을 보러 오는지, 유입 경로가 비어 있는지 확인합니다
9. 세그먼트에서 세션 세그먼트를 만들고 화면 해상도 조건을 정규식으로 넣은 뒤, 행을 시간으로 바꿔 사이트 전체와 시간대별 비중을 비교합니다
10. 월별 추세는 표준 보고서에서 같은 해상도를 검색해 확인합니다. 탐색 분석에서는 데이터 보관 기간보다 오래된 날짜를 고를 수 없습니다

한 걸음 더 나아가려면 내부 트래픽 규칙을 활용하는 방법이 있습니다. 일부 AI 회사는 자사 크롤러의 IP 대역을 공개하는데, 이 대역을 내부 트래픽 정의에 넣고 traffic_type 값을 ai_agent처럼 따로 지정한 뒤, 데이터 필터를 만들어 상태를 활성이 아니라 테스트로 둡니다. 그러면 해당 트래픽에 테스트 데이터 필터 이름이라는 측정기준 값이 붙어서 탐색 분석에서 따로 볼 수 있습니다. 데이터를 지우지 않고 표시만 하는 방법입니다. 다만 이름을 밝히고 들어오는 크롤러는 대개 자바스크립트를 실행하지 않아 처음부터 GA4에 기록되지 않는 경우가 많으므로, 이 방법은 클라우드 브라우저처럼 GA4에 기록되는 방문을 구분할 때 씁니다.

*주의: 필터를 활성 상태로 바꾸면 해당 데이터는 영구히 삭제되고, 필터를 만든 시점부터만 적용되며, 속성당 10개까지만 만들 수 있습니다. 내부 트래픽 필터를 설정하는 방법은 내부 트래픽 필터링 글을 참고해 주세요.

마무리

정리하겠습니다. GA4는 원본 User-Agent와 IP를 제공하지 않고 봇 제외 기준도 공개하지 않으므로, GA4에서 할 수 있는 일은 봇의 이름을 밝히는 것이 아니라 봇으로 보이는 방문을 추정하는 것입니다. 이번 분석에서는 표준 보고서에서 사람이 쓰지 않는 화면 크기로 후보를 좁혔고, 탐색 분석에서 지역과 운영체제, 언어로 네 그룹을 구분했으며, 방문 페이지로 그룹마다 보러 오는 페이지를 확인했습니다. 여기에 세션당 조회수와 신규 사용자 비율, 유입 경로를 겹쳐 자동화된 방문이라고 판단했고, 표준 보고서의 월별 추세에서는 새로운 그룹이 하나씩 늘어났습니다.

정확한 판별은 서버 로그로 해야 하지만, 로그를 열기 전에 GA4만으로도 확인할 대상을 상당히 좁힐 수 있습니다. 다만 시간대처럼 단독으로는 단서가 되지 않는 지표도 있으므로, 한 가지 지표로 판정하지 않고 여러 지표를 겹쳐 봐야 합니다.

보고서에서 이 트래픽을 어떻게 다룰지도 미리 정해 두는 것이 좋습니다. AI 어시스턴트 채널이 전체의 0.4%라고 보고서에서 빼 버리면 이 경로가 커지는지 줄어드는지 알 수 없게 됩니다. 반대로 참여율이 0%에 가까운 봇 추정 세션을 직접 유입에 그대로 섞어 두면 직접 유입의 성과가 실제보다 나빠 보입니다. AI 어시스턴트 채널은 따로 드러내고, 봇 추정 세션은 따로 떼어 보는 기준이 필요합니다.

지금 확인해 볼 만한 항목을 정리하면 다음과 같습니다.

• 화면 해상도 목록에 참여율이 한 자릿수인 줄이 있는지
• 그 줄을 국가로 나눴을 때 지역이 하나로 모이는지, 같은 해상도에 사람의 방문이 섞여 있지는 않은지
• 운영체제와 브라우저가 (not set)이거나, 화면 크기와 기기 카테고리가 맞지 않는지
• 세션당 조회수가 1이고 새 사용자 수가 총 사용자와 같은지
• 그 세션이 들어오는 페이지가 상담이나 문의처럼 중요한 페이지인지
• 새벽 시간대 비중이 사이트 전체보다 높은지, 아니면 사람의 일반적인 생활 시간을 따르는지
• 몇 달 단위로 봤을 때 세션 수와 비중이 각각 어떻게 달라지는지
• 서버 로그나 CDN 로그를 볼 수 있는지, 없다면 누구에게 요청해야 하는지

한 가지 덧붙이면, 크롤러를 차단하는 일과 GA4 데이터를 정리하는 일은 서로 다른 문제입니다. 크롤러 접근 정책은 우리 콘텐츠를 AI가 어떻게 쓰게 할지의 문제이고, 데이터 품질은 우리가 무엇을 집계하고 있는지의 문제이므로 따로 판단해야 합니다.