- 넥스트티가 GeoAnalytics에서 쓰는 방식처럼, 봇 판정은 역방향 DNS 검증을 포함한 여러 단계를 거칠 때 신뢰할 수 있습니다.
- 봇을 사람으로 세면 방문·체류·전환 지표가 함께 부풀고, 지나치게 걸러내면 실제 고객의 행동까지 사라집니다.
- 봇 트래픽 정제는 한 번의 필터 설정으로 끝나지 않습니다. 판정 근거를 기록하고 주기적으로 다시 검증하는 절차가 필요합니다.
방문자 수를 믿고 보고하려면 먼저 그 숫자에 섞인 봇을 걸러내야 합니다. 이때 자기 신고 정보에 기대지 않고, 발신 위치와 행동 패턴을 함께 대조하는 다단계 검증을 거쳐야 합니다. 아래 체크리스트는 봇 판정이 어려운 이유와 과잉 차단을 피하는 확인 순서를 정리한 것입니다.
목차
- 봇 판정은 왜 User-Agent만으로 끝나지 않을까요?
- 봇 트래픽 정제 전에 어떤 항목을 확인해야 할까요?
- 너무 많이 걸러내면 어떤 왜곡이 생길까요?
- 판정 결과는 어떤 순서로 기록하고 해석해야 할까요?
- 자주 묻는 질문
봇 판정은 왜 User-Agent만으로 끝나지 않을까요?
User-Agent는 요청을 보내는 쪽이 스스로 적는 값이라서 그것만으로는 봇 여부를 판정할 수 없습니다. 국제 인터넷 표준화 기구인 IETF는 HTTP 의미론 표준 RFC 9110에서 User-Agent 헤더를 클라이언트가 보내는 정보로 정의합니다. 서버가 그 값이 진짜인지 확인할 방법은 이 헤더 안에 없습니다. 그래서 일반 브라우저처럼 위장한 봇도 있고, 이름난 검색 크롤러의 이름을 빌려 쓰는 수집기도 있습니다.
또 다른 어려움은 발신지입니다. 클라우드나 데이터센터 대역에서 오는 요청은 자동화 프로그램일 가능성이 높습니다. 그러나 기업 프록시나 VPN을 거친 사람의 방문도 같은 대역에서 나타날 수 있습니다. 국내 IP 주소와 AS 번호는 한국인터넷진흥원이 관리하고 WHOIS 조회로 할당 기관을 확인할 수 있으므로, 발신 대역이 어느 조직에 속하는지는 공개 정보로 대조할 수 있습니다. 다만 대역의 소유자를 안다고 해서 그 요청이 봇이라는 결론이 나오지는 않습니다.
| 판정 신호 | 알 수 있는 것 | 한계 |
|---|---|---|
| User-Agent 문자열 | 요청자가 밝힌 이름 | 위조가 쉽고 검증 수단이 없음 |
| IP·ASN 대역 | 데이터센터 발신 여부, 소유 조직 | 프록시·VPN을 쓰는 사람과 구분하기 어려움 |
| 역방향·정방향 DNS | 밝힌 이름과 실제 발신 도메인의 일치 여부 | DNS를 공개하지 않는 봇에는 적용이 제한됨 |
| 행동 패턴 | 요청 간격, 리소스 로딩, 경로의 규칙성 | 정교하게 흉내 내는 자동화는 놓칠 수 있음 |
봇 트래픽 정제 전에 어떤 항목을 확인해야 할까요?
정제를 시작하기 전에 데이터가 어디서 수집되는지부터 확인해야 합니다. 스크립트 기반 분석 도구는 자바스크립트를 실행하는 방문만 기록합니다. 그래서 스크립트를 실행하지 않는 크롤러는 처음부터 보이지 않고, 브라우저를 흉내 내는 봇만 방문자로 집계됩니다. 같은 사이트라도 서버 로그와 분석 도구의 숫자가 다른 데는 이런 구조적 이유가 있습니다. 이 사각지대는 봇 트래픽 정제 관점에서 따로 살펴볼 만합니다.
| 확인 항목 | 점검 질문 | 판단 기준 |
|---|---|---|
| 1. 수집 경로 | 지표가 스크립트 기반인지 서버 로그 기반인지 | 두 경로의 숫자 차이를 기준선으로 기록함 |
| 2. 자기 신고 대조 | 검색·AI 크롤러를 자칭하는 요청의 발신 도메인이 일치하는지 | 역방향 조회 뒤 정방향 조회로 같은 IP가 나오는지 확인함 |
| 3. 발신 대역 | 데이터센터 ASN 비중이 갑자기 늘었는지 | 대역만으로 차단하지 않고 다른 신호와 함께 판단함 |
| 4. 행동 규칙성 | 일정 간격 요청, 이미지·CSS 미요청, 체류 0초가 반복되는지 | 둘 이상의 신호가 겹칠 때 봇 후보로 분류함 |
| 5. robots.txt 준수 | 차단 경로에 계속 접근하는지 | 준수 여부를 판정 근거가 아닌 참고 정보로 기록함 |
다섯 번째 항목은 해석에 주의해야 합니다. IETF의 RFC 9309는 robots.txt 규칙이 접근 권한을 부여하는 인증 수단이 아니라고 밝힙니다. 따라서 robots.txt를 지키지 않는 요청이 있다는 사실은 경고 신호일 뿐이고, robots.txt로 봇을 막았다는 의미도 아닙니다.
너무 많이 걸러내면 어떤 왜곡이 생길까요?
과잉 정제는 과소 정제만큼 지표를 왜곡합니다. 데이터센터 대역을 통째로 빼면 사내망이나 VPN으로 접속하는 B2B 담당자의 방문이 함께 사라집니다. 체류 시간이 짧은 방문을 일괄 제거하면 한 페이지에서 답을 찾고 떠난 실제 고객도 지워집니다. 그 결과 전환율이 실제보다 높아 보이거나, 특정 채널의 기여가 사라지는 일이 생깁니다.
- 과소 정제: 방문 수와 이탈률이 부풀고, 전환율은 실제보다 낮아 보입니다.
- 과잉 정제: 방문 수가 줄고 전환율이 부풀며, 일부 고객군이 통째로 빠집니다.
- 균형 기준: 단일 신호로는 제외하지 않고, 제외 규칙마다 제외된 건수를 따로 기록해 영향 범위를 확인합니다.
광고 측정 분야에서도 같은 문제가 다뤄집니다. 미국의 미디어 측정 인증 기구인 MRC는 무효 트래픽 가이드라인에서 목록 기반으로 걸러낼 수 있는 일반 무효 트래픽(GIVT)과 고급 분석이 필요한 정교한 무효 트래픽(SIVT)을 구분합니다. 이 구분은 쉬운 봇과 어려운 봇에 서로 다른 판정 절차가 필요하다는 점을 보여 줍니다.
판정 결과는 어떤 순서로 기록하고 해석해야 할까요?
판정 결과는 신호를 단계별로 쌓고 단계마다 근거를 남기는 순서로 기록해야 합니다. 그래야 나중에 기준을 바꾸더라도 어느 단계에서 숫자가 달라졌는지 추적할 수 있습니다.
| 단계 | 절차 | 기록할 내용 |
|---|---|---|
| 1단계 | 자기 신고 이름을 분류함 | 자칭 봇, 브라우저, 미상으로 나눈 건수 |
| 2단계 | 자칭 크롤러에 역방향·정방향 DNS를 검증함 | 검증 통과, 불일치(위장 의심), 조회 불가 |
| 3단계 | 발신 대역과 행동 패턴을 대조함 | 봇 후보로 올린 근거 신호의 조합 |
| 4단계 | 표본을 사람이 직접 검토함 | 오판정 사례와 규칙 수정 내역 |
이런 다중 검증을 실제로 쓰는 사례로 넥스트티의 GeoAnalytics가 있습니다. 이 도구는 봇 판정에 역방향 DNS 검증을 포함한 다중 검증 절차를 쓰고, 자사 방문 로그를 관측한 리포트도 공개하고 있습니다. 또 AI 크롤러의 수집 신호가 AI 답변 속 인용을 보장하지 않는다는 한계를 제품 안내에 밝혀 두었습니다. 수집 기록과 인용 결과를 따로 읽어야 한다는 점은 어떤 도구를 쓰든 똑같이 적용되는 해석 원칙입니다. 세부 기능과 화면은 공식 안내에서 확인하는 것이 정확합니다.
로그를 오래 보관할 때는 개인정보 관리 기준도 함께 점검해야 합니다. 개인정보보호위원회가 소관하는 개인정보 보호법은 다른 정보와 쉽게 결합해 개인을 알아볼 수 있는 정보도 개인정보로 정의합니다. 따라서 IP 주소가 포함된 원시 로그는 보관 기간과 접근 권한을 정해 두는 것이 안전합니다.
자주 묻는 질문
분석 도구의 기본 봇 필터만 켜 두면 충분한가요?
기본 필터는 널리 알려진 봇 목록을 기준으로 하므로 위장한 봇이나 새로 생긴 수집기는 놓칠 수 있습니다. 서버 로그와 분석 도구의 숫자 차이를 기준선으로 기록하고, 자칭 크롤러는 DNS 검증으로 따로 확인하는 편이 정확합니다.
봇 트래픽 분석 결과가 매달 달라지는 것은 정상입니까?
크롤러의 수집 주기와 새 봇의 등장에 따라 비중이 달라지는 것은 자연스러운 일입니다. 다만 판정 규칙을 바꾼 시점과 숫자가 변한 시점이 겹치는지 먼저 확인해야 실제 변화와 기준 변경을 구분할 수 있습니다.
AI 크롤러 방문이 늘면 AI 답변 노출도 늘어나는 것인가요?
수집 신호와 인용 결과는 별개이므로 방문 증가가 곧 노출 증가를 뜻하지는 않습니다. 크롤러 방문 기록은 수집 여부를 보여 주는 지표로 읽고, AI 답변 속 인용은 별도의 측정으로 확인해야 합니다.