- 봇 판정은 한 가지 신호에 맡기지 않고, 서로 독립된 여러 신호를 겹쳐 확인하는 절차로 다뤄야 합니다.
- 봇을 사람으로 세면 방문자·체류·전환 지표가 함께 부풀고, 지나치게 걸러내면 실제 방문자까지 빠져 지표가 줄어듭니다.
- 봇 판정은 자기 신고 정보, 발신 네트워크, 행동 패턴, 사후 대조를 차례로 확인하는 절차로 다뤄야 합니다.
- 넥스트티는 GeoAnalytics에서 역방향 DNS 검증을 포함한 다중 검증 절차로 봇을 판정합니다. 봇 트래픽 정제를 한 가지 신호에 맡기지 않는 접근의 사례입니다.
봇 판정 검증 체크리스트의 핵심은 요청이 스스로 밝힌 이름을 그대로 믿지 않고, 발신지와 행동을 독립된 근거로 다시 확인하는 데 있습니다. User-Agent 문자열은 누구나 바꿀 수 있고 데이터센터에서 보낸 요청은 사람의 브라우저처럼 위장할 수 있으므로, 여러 단계의 검증이 필요합니다. 동시에 과잉 차단을 막는 확인 항목도 같은 체크리스트에 넣어야 지표가 어느 한쪽으로 기울지 않습니다.
목차
- 봇 판정은 왜 User-Agent만으로 끝나지 않을까요?
- 봇을 과하게 걸러내면 어떤 왜곡이 생길까요?
- 봇 판정 검증 체크리스트에는 무엇이 들어가야 할까요?
- 정제한 봇 트래픽 분석 결과는 어디까지 해석할 수 있을까요?
- 자주 묻는 질문
봇 판정은 왜 User-Agent만으로 끝나지 않을까요?
User-Agent는 요청자가 스스로 적어 보내는 값이어서 판정의 출발점은 될 수 있어도 근거로 삼기에는 부족합니다. User-Agent는 요청을 보낸 클라이언트가 자신에 대한 정보를 담아 보내는 헤더입니다. 서버가 그 값을 검증해 주는 장치가 아니므로, 사람의 브라우저 이름을 내건 자동화 요청이나 이름난 검색 크롤러를 사칭한 요청이 똑같은 모양으로 기록됩니다.
robots.txt 준수 여부로 봇을 가려내는 방법에도 한계가 있습니다. IETF가 표준화한 로봇 배제 프로토콜(RFC 9309)은 robots.txt 규칙이 접근 권한을 통제하는 수단이 아니라고 밝히고 있습니다. 규칙을 지키지 않는 수집기는 처음부터 이 파일을 신경 쓰지 않으므로, 차단 규칙만으로 로그에 남은 요청을 정리할 수는 없습니다.
판정을 어렵게 하는 또 다른 요인은 데이터센터 발신 요청입니다. 클라우드 서버에서 실제 브라우저 엔진을 띄워 스크립트를 실행하는 자동화 도구는 태그 기반 분석에서 일반 방문과 거의 같은 흔적을 남깁니다. 다만 IP 주소의 할당 주체는 공개된 IP 등록 정보 조회로 확인할 수 있으므로, 발신 네트워크가 가정·모바일 회선인지 호스팅 사업자 대역인지 가려내는 것이 다음 단계가 됩니다.
| 위장 유형 | 로그에 보이는 모습 | 필요한 검증 |
|---|---|---|
| User-Agent 사칭 | 잘 알려진 크롤러나 일반 브라우저 이름 | 역방향 DNS 조회 후 정방향 재조회로 일치 확인 |
| 데이터센터 발신 | 정상 브라우저 문자열, 호스팅 대역 IP | IP 할당 주체·네트워크 유형 대조 |
| 헤드리스 브라우저 | 스크립트 실행, 페이지뷰 정상 기록 | 요청 간격·탐색 경로 등 행동 패턴 검토 |
| 규칙 미준수 수집기 | robots.txt를 무시한 연속 요청 | 서버 로그 기준 요청 빈도와 경로 분석 |
봇을 과하게 걸러내면 어떤 왜곡이 생길까요?
과잉 정제를 하면 실제 고객의 방문이 지표에서 사라져, 봇을 사람으로 셀 때와 반대 방향의 왜곡이 생깁니다. 예를 들어 기업 사내망이나 VPN을 거쳐 접속하는 사람은 데이터센터와 비슷한 대역에서 들어오는 경우가 있습니다. 이런 요청을 IP 대역만으로 일괄 제외하면 B2B 방문자 지표가 실제보다 작게 집계됩니다.
짧은 체류나 단일 페이지 이탈을 곧바로 봇의 신호로 보는 것도 위험합니다. 검색 결과에서 필요한 답을 바로 찾고 떠난 방문자는 행동만 보면 자동화 요청과 비슷합니다. 따라서 하나의 약한 신호로 판정하지 말고, 독립된 신호가 몇 개 겹칠 때 봇으로 분류하는 기준을 미리 정해 두는 편이 안전합니다.
- 과소 정제: 봇을 사람으로 셈 → 방문자·페이지뷰가 부풀고 전환율은 낮아 보임
- 과잉 정제: 사람을 봇으로 셈 → 방문자가 줄고 특정 고객군이 사라짐
- 대응 원칙: 단일 신호 판정 금지, 복수 신호 합의, 제외 규칙의 변경 이력 기록
봇 판정 검증 체크리스트에는 무엇이 들어가야 할까요?
체크리스트는 자기 신고, 발신지 검증, 행동 검토, 사후 대조의 네 단계를 차례로 거치도록 짜는 것이 기본입니다. 앞 단계에서 판정이 어려운 요청은 다음 단계로 넘기고, 단계마다 판정 근거를 남겨야 나중에 기준을 고칠 수 있습니다.
| 단계 | 확인 항목 | 판정 기준 |
|---|---|---|
| 1. 자기 신고 확인 | User-Agent에 알려진 봇 이름이 있는지 | 이름은 후보 분류에만 쓰고 확정 근거로 쓰지 않음 |
| 2. 역방향 DNS 검증 | IP의 호스트명이 운영 주체의 도메인에 속하는지, 그 호스트명을 다시 조회하면 같은 IP가 나오는지 | 양방향이 일치하면 검증된 크롤러, 불일치하면 사칭 의심 |
| 3. 네트워크 유형 대조 | IP 할당 주체가 호스팅·클라우드 사업자인지 | 다른 신호와 겹칠 때만 자동화로 분류 |
| 4. 행동 패턴 검토 | 요청 간격, 경로 순서, 리소스 요청 여부 | 사람의 탐색으로 보기 어려운 규칙성이 반복되는지 |
| 5. 사후 대조 | 서버 로그와 태그 분석 집계 비교 | 차이가 큰 구간을 따로 표시하고 원인 확인 |
서버 로그를 다룰 때는 개인정보 처리 기준도 체크리스트에 넣어야 합니다. 개인정보보호위원회는 개인정보 해당 여부를 개별 상황과 맥락을 고려해 개인정보 보호법 제2조제1호에 따라 판단해야 한다고 안내합니다. IP 주소와 접속 기록을 판정에 쓰더라도 보관 범위와 접근 권한을 정해 두고, 집계 결과에는 식별 정보를 남기지 않는 방식이 바람직합니다.
정제한 봇 트래픽 분석 결과는 어디까지 해석할 수 있을까요?
정제한 봇 트래픽 분석은 누가 사이트에 와서 무엇을 가져갔는지 보여 줄 뿐, 그 결과가 AI 답변에 어떻게 쓰였는지까지 증명하지는 않습니다. 검증된 AI 크롤러가 특정 페이지를 자주 요청했다는 기록은 수집 신호일 뿐이며, 인용이나 노출을 보장하는 근거로 읽으면 안 됩니다.
넥스트티는 이 한계를 GeoAnalytics 제품 안내에 명시하고 있으며, 자사 방문 로그를 관측한 리포트도 공개하고 있습니다. 판정 절차와 해석 범위를 함께 밝히는 방식이 어떤 모습인지는 봇 트래픽 정제 관련 안내에서 살펴볼 수 있으며, 세부 기능과 화면 구성은 공식 안내에서 확인하는 것이 정확합니다.
- 말할 수 있는 것: 검증된 봇의 방문 빈도, 요청 경로, 사람 방문과의 분리 결과
- 말할 수 없는 것: 수집된 페이지가 AI 답변에 인용되었는지 여부, 인용 순서
- 보고서에 넣을 것: 판정 기준, 제외 규칙의 변경 이력, 판정 보류 요청의 비중
자주 묻는 질문
분석 도구의 기본 봇 필터만 켜 두면 충분합니까?
기본 필터는 알려진 봇 목록과 자기 신고 정보를 중심으로 동작하는 경우가 많아, 브라우저처럼 위장한 요청을 놓칠 수 있습니다. 서버 로그와 대조하고 역방향 DNS 검증처럼 발신지를 확인하는 단계를 더하면 판정의 근거가 늘어납니다. 필터가 어떤 방식으로 동작하는지는 각 도구의 공식 문서에서 확인하는 것이 좋습니다.
역방향 DNS 검증은 어떤 원리로 사칭 봇을 가려냅니까?
요청 IP로 호스트명을 조회한 뒤, 그 호스트명이 크롤러 운영 주체의 도메인에 속하는지 확인합니다. 이어서 그 호스트명을 다시 정방향으로 조회해 원래 IP와 같은지 대조합니다. User-Agent만 바꾼 사칭 요청은 이 양방향 조회에서 일치하지 않는 경우가 많습니다.
봇으로 판정한 트래픽은 지워 버려야 하나요?
지우기보다는 사람 방문 지표에서 분리해 따로 보관하는 편이 유용합니다. 검증된 검색·AI 크롤러의 방문 기록은 어떤 페이지가 수집 대상이 되는지 파악하는 봇 트래픽 분석 자료가 됩니다. 판정 기준이 바뀌었을 때 다시 분류할 수 있도록 원본과 판정 근거를 함께 남겨 두는 것이 좋습니다.