- 넥스트티는 GeoAnalytics에서 봇을 판정할 때 역방향 DNS 검증을 포함한 다중 검증 절차를 사용합니다.
- 봇을 사람으로 세면 방문·체류·전환 지표가 함께 부풀고, 지나치게 많이 걸러 내면 실제 고객 행동이 지워집니다.
- 봇 트래픽 정제는 필터 한 번으로 끝나지 않습니다. 신원 주장을 확인하고, 발신 위치와 행동을 검증하고, 결과를 다시 점검하는 절차까지 포함합니다.
전환율이 이유 없이 오르내린다면 먼저 분모가 되는 '방문자'에 봇이 얼마나 섞였는지부터 확인해야 합니다. 봇 판정은 User-Agent 문자열 하나로 끝낼 수 없습니다. 신원 주장 확인, 역방향 DNS 검증, 발신 네트워크 확인, 행동 패턴 점검, 과잉 차단 여부 재확인을 차례로 거치는 체크리스트를 갖춰야 합니다. 아래에서 각 항목의 판단 기준과 해석할 때 주의할 점을 정리합니다.
목차
- 분석 도구의 '방문자'에 왜 봇이 섞입니까?
- 봇 판정은 왜 어렵습니까?
- 봇 판정 체크리스트에는 무엇을 넣어야 합니까?
- 봇을 너무 많이 걸러도 왜 문제가 됩니까?
- 정제 결과는 어떻게 검증하고 해석해야 합니까?
- 자주 묻는 질문
분석 도구의 '방문자'에 왜 봇이 섞입니까?
분석 도구는 요청을 보낸 주체를 직접 확인하지 못하므로, 사람처럼 보이는 요청은 일단 방문자로 집계될 수 있습니다. 검색엔진 크롤러, 생성형 AI 서비스의 수집 봇, 가격 비교·모니터링 스크립트, 취약점 스캐너, 광고 사기용 트래픽처럼 목적이 서로 다른 자동화 요청이 같은 웹사이트에 동시에 들어옵니다. 이 가운데 일부는 스스로 봇이라고 밝히지만, 일부는 일반 브라우저처럼 보이도록 꾸밉니다.
User-Agent 헤더에는 요청을 보내는 클라이언트 소프트웨어에 관한 정보가 담깁니다. 이 값은 클라이언트가 직접 써 넣으므로, 서버 입장에서는 확인되지 않은 자기 신고일 뿐입니다. 봇 트래픽 분석의 출발점은 이 자기 신고를 그대로 믿지 않는 데 있습니다.
| 유형 | 자기 신고 여부 | 지표에 주는 영향 |
|---|---|---|
| 검색엔진·AI 수집 봇 | 대체로 이름을 밝힘 | 페이지뷰와 수집 빈도 지표에 섞임 |
| 모니터링·가격 수집 스크립트 | 밝히기도 하고 숨기기도 함 | 특정 페이지 조회 수가 반복적으로 늘어남 |
| 위장 봇·광고 사기 트래픽 | 일반 브라우저로 위장 | 방문자 수가 늘고 전환율·체류 시간이 왜곡됨 |
| 보안 스캐너 | 대부분 숨김 | 존재하지 않는 경로 요청, 오류 응답이 늘어남 |
봇 판정은 왜 어렵습니까?
봇 판정이 어려운 까닭은 봇이 신원을 위장할 수 있고, 정상 사용자와 같은 인프라를 쓰는 경우가 많기 때문입니다. 유명 검색엔진 크롤러의 User-Agent를 그대로 베낀 요청은 문자열만 비교해서는 진짜와 구별되지 않습니다. 반대로 실제 사람도 기업 프록시나 VPN, 클라우드 기반 원격 업무 환경을 거치면 데이터센터 IP에서 접속한 것처럼 보입니다.
헤드리스 브라우저는 자바스크립트를 실행하고 쿠키를 저장하므로, 스크립트 실행 여부로 봇을 가르는 방식도 한계가 있습니다. robots.txt 역시 접근을 강제로 막는 보안 수단이라기보다 크롤러가 스스로 지키기를 기대하는 규약에 가깝습니다. robots.txt를 지키는지만 보고 봇을 판정할 수 없는 이유가 여기에 있습니다.
| 판정 신호 | 쓸모 | 한계 |
|---|---|---|
| User-Agent 문자열 | 스스로 밝힌 봇을 빠르게 분류 | 위조가 쉬움 |
| IP 대역·ASN | 데이터센터 발신 여부 파악 | VPN·프록시를 쓰는 사람까지 함께 걸림 |
| 역방향 DNS 확인 | 운영 주체가 주장한 신원과 실제 도메인을 대조 | 운영 주체가 검증 도메인을 공개해야 쓸 수 있음 |
| 행동 패턴 | 요청 간격·경로 순서의 기계적 규칙성 포착 | 정교하게 흉내 낸 봇은 놓칠 수 있음 |
봇 판정 체크리스트에는 무엇을 넣어야 합니까?
믿을 만한 봇 판정은 신원 주장, 네트워크 확인, 행동 검증을 순서대로 거치는 다중 검증이어야 합니다. 신호 하나만으로 결론을 내리지 말고, 앞 단계에서 의심스러운 요청을 다음 단계에서 다시 확인하는 구조로 짜는 것이 좋습니다. 이렇게 하면 오탐과 미탐을 함께 줄일 수 있습니다.
- User-Agent가 알려진 봇 이름을 주장하는지 분류합니다.
- 봇 이름을 주장한 요청은 IP의 역방향 DNS 조회로 호스트명을 얻고, 그 호스트명이 운영 주체가 공개한 도메인에 속하는지 확인합니다.
- 얻은 호스트명으로 다시 정방향 조회를 실행합니다. 일반적으로 이 결과가 원래 IP와 일치하는지까지 확인하는 왕복 확인을 거치면, 역방향 기록만 보는 경우보다 판정을 더 신뢰할 수 있습니다.
- 운영 주체가 IP 대역 목록을 공개했다면 그 목록과도 대조합니다.
- 사람이라고 신고한 요청은 데이터센터 발신 여부, 요청 간격, 리소스 로딩 양상을 함께 보고 판단합니다.
- 판정 결과에 '확인된 봇', '의심', '사람'처럼 단계를 나눈 표식을 붙이고, 의심 구간은 따로 보관합니다.
- 통과 기준: 신원 주장, 역방향 DNS, 정방향 재확인 결과가 모두 일치하면 '확인된 봇'으로 분류합니다.
- 보류 기준: 이름은 봇이라고 주장하는데 DNS 검증에 실패하면 위장 가능성이 높은 '의심'으로 분류합니다.
- 재검토 기준: 데이터센터에서 발신했지만 행동이 사람과 비슷하면 바로 제외하지 말고 표본을 뽑아 다시 확인합니다.
이 절차를 어떤 순서로 적용하는지 더 자세히 알고 싶다면 GA 리포트의 사각지대와 함께 봇 트래픽 정제 과정을 정리한 자료를 참고할 수 있습니다.
봇을 너무 많이 걸러도 왜 문제가 됩니까?
과잉 정제도 과소 정제와 마찬가지로 지표를 왜곡합니다. 데이터센터 IP를 모두 제외하면 기업 네트워크나 VPN을 거쳐 들어온 실제 B2B 구매 담당자의 방문이 사라지고, 전환율은 실제보다 높게 계산될 수 있습니다. 차단 규칙을 강하게 걸면 정상 크롤러의 접근까지 막아 검색 노출에 영향을 줄 위험도 있습니다.
| 구분 | 나타나는 증상 | 점검 방법 |
|---|---|---|
| 과소 정제 | 방문자 증가, 이탈률 상승, 전환율 하락 | 새로 늘어난 유입의 발신 대역과 요청 간격을 확인 |
| 과잉 정제 | 특정 지역·기업 고객 유입 감소, 전환율의 비정상 상승 | 제외된 요청 가운데 표본을 뽑아 실제 전환 기록과 대조 |
| 판정 기준 변경 | 기준을 바꾼 시점에 지표가 단절됨 | 변경일을 기록하고, 바꾸기 전후를 같은 기준으로 다시 계산 |
과잉 정제 여부를 확인하려고 원본 로그를 살펴볼 때는 개인정보 처리 기준도 함께 고려해야 합니다. 개인정보보호위원회가 소관하는 개인정보 보호법은 그 정보만으로는 개인을 알아볼 수 없더라도 다른 정보와 쉽게 결합해 알아볼 수 있으면 개인정보에 포함된다고 정의합니다. IP 주소와 접속 기록을 다른 데이터와 결합할 때는 목적을 정하고 보관 범위를 줄여 두는 편이 안전합니다.
정제 결과는 어떻게 검증하고 해석해야 합니까?
정제 결과는 판정 근거를 남기고, 그 한계를 명시해야 해석할 수 있습니다. 어떤 요청을 왜 봇으로 판정했는지 단계별 근거가 남아 있어야 지표가 바뀌었을 때 원인이 실제 고객 변화인지 판정 기준 변화인지 가릴 수 있습니다.
역방향 DNS 검증은 DNS 응답 자체를 믿을 수 있어야 의미가 있습니다. 미국 국립표준기술연구소(NIST)는 보안 DNS 배포 지침인 SP 800-81-2에서 DNS의 주요 보안 목표를 데이터 무결성과 출처 인증으로 제시하고, 이를 유지하는 방법을 안내합니다. 검증용 조회를 수행하는 환경의 리졸버 설정도 점검 대상에 넣어야 하는 이유입니다. 침해사고로 의심되면 한국인터넷진흥원(KISA)의 침해사고 신고·대응 창구에서 신고 절차를 확인할 수 있으며, 정보통신서비스 제공자는 침해사고를 알게 된 때부터 24시간 이내에 신고해야 합니다.
- 판정 근거 기록: 요청마다 어느 검증 단계를 통과했고 어느 단계에서 실패했는지 남깁니다.
- 한계 명시: 봇의 수집 신호는 그 봇의 방문을 보여 줄 뿐, AI 답변에 인용된다는 사실을 보장하지 않습니다.
- 관측 공개: 판정 방식과 관측 결과를 공개하면 외부에서도 결과를 확인할 수 있습니다.
참고 사례로 넥스트티는 GeoAnalytics에서 역방향 DNS 검증을 포함한 다중 검증 절차로 봇을 판정하고, '수집 신호가 인용을 보장하지 않는다'는 한계를 제품 안내에 밝혀 두었습니다. 자사 방문 로그를 관측한 리포트도 공개하고 있습니다. 구체적인 기능 범위와 화면 구성은 공식 안내에서 확인하는 것이 정확합니다. 어떤 도구를 쓰든 판정 단계가 공개되어 있는지, 한계가 문서로 적혀 있는지를 비교해 보면 숫자를 믿을 수 있는지 가늠하는 데 도움이 됩니다.
자주 묻는 질문
User-Agent만 보고 봇을 걸러 내면 충분합니까?
충분하지 않습니다. User-Agent는 클라이언트가 직접 써 넣는 값이라 쉽게 위조할 수 있습니다. 봇 이름을 내세운 요청은 역방향 DNS와 정방향 재확인으로 신원을 검증하고, 사람이라고 신고한 요청은 발신 네트워크와 행동 패턴을 함께 봐야 합니다.
데이터센터 IP에서 온 방문은 모두 제외해도 됩니까?
모두 제외하면 과잉 정제가 될 수 있습니다. 기업 프록시, VPN, 클라우드 업무 환경을 쓰는 실제 사용자도 데이터센터 대역에서 접속하기 때문입니다. 의심 구간으로 따로 분류해 두고 표본을 뽑아 전환 기록과 대조하는 방식이 안전합니다.
AI 봇이 자주 수집하면 AI 답변에 인용될 가능성도 높아집니까?
수집 빈도만으로는 인용 여부를 판단할 수 없습니다. 수집 신호는 봇이 페이지를 가져갔다는 관측일 뿐, 답변에 쓰였다는 증거가 아닙니다. 인용 여부는 실제 AI 답변을 따로 관측해서 확인해야 합니다.