조건은 짐작이 아니라 방문자를 설명합니다
규칙은 “그리고”로 묶인 조건의 묶음이며, 가장 먼저 일치하는 규칙이 결과를 정합니다. 조건은 실제로 여러분이 머릿속에서 따지는 바로 그것들입니다. 방문자가 어느 국가, 어느 지역, 어느 도시에 있는지, 자율 시스템 번호로 본 어느 네트워크에서 왔는지, 그 네트워크가 데이터센터인지 상용 VPN인지 공개 프록시인지 TOR 출구 노드인지 웹 익명화 서비스인지, 방문자 분류기가 그를 어떻게 판단했고 품질 점수를 얼마나 낮게 매겼는지, 스스로 밝힌 크롤러가 진짜인지, 그리고 기기, 언어, 유입 경로, user agent 패턴, 캠페인 태그의 유무, 현지 시각, 요일, 첫 방문인지 재방문인지입니다.
이 가운데 둘은 따로 짚어 둘 만합니다. 경쟁 제품이 내놓지 못하는 조건이기 때문입니다. 네트워크 종류는 user agent 차단 목록이 아니라 주소 대역으로 정리된 프록시 데이터베이스에서 나옵니다. 그래서 스스로를 Chrome이라고 밝히는 스크래퍼도 데이터센터로 인식됩니다. 그리고 “검증된 크롤러”는 이름 확인이 아니라 주소 확인입니다. 가정용 인터넷 회선에서 Googlebot을 자처하는 요청은 Googlebot이 아니며, 규칙 엔진은 그 차이를 압니다.
조건이 세 가지 값을 갖는 것은 의도한 설계입니다. 조건은 충족될 수도, 충족되지 않을 수도, 데이터가 없어 답할 수 없을 수도 있으며, “답할 수 없음”은 결코 일치로 세지 않습니다. 조건을 뒤집으면 확실한 답만 뒤집히므로, “독일을 제외한 전부”라고 쓴 규칙이 국가를 판별하지 못한 방문자에게 조용히 걸리는 일은 없습니다.
- 분류기가 내놓는 방문자 종류, 검증 결과, 품질 점수
- 네트워크 종류 — 데이터센터, VPN, 공개 프록시, TOR, 웹 프록시
- 국가, 지역, 도시, 자율 시스템 번호, 주소 또는 서브넷
- 기기, 언어, 유입 경로, user agent 패턴, 캠페인 태그
- 현지 시각 구간, 요일, 첫 방문과 재방문의 구분
- 재사용하는 주소 목록 — 목록 하나를 여러 규칙에서 참조
다섯 가지 결과, 그리고 그중 막다른 길은 없습니다
일치한 규칙은 방문을 그대로 통과시키면서 규칙이 걸렸다는 사실만 기록할 수도 있고, 404나 410으로 링크를 이용할 수 없다고 응답할 수도 있고, 이 방문자만 다른 목적지로 보낼 수도 있고, 직접 쓴 문구를 담은 브랜드 안내 페이지를 보여 줄 수도 있고, 목적지는 그대로 둔 채 방문을 의심스러운 것으로 표시할 수도 있습니다.
“통과시키고 기록하기” 동작이 있는 이유는, 확인할 수 없는 필터는 신뢰할 수 없는 필터이기 때문입니다. 규칙이 걸릴 때마다 규칙 식별자와 적용된 동작이 클릭 이벤트에 기록되므로, 필터링 분류는 “이 규칙이 트래픽을 얼마나 막았고, 막아야 할 트래픽을 막았는가”라는 질문에 답합니다. 동작이 식별자와 함께 저장되기 때문에 그 뒤에 수정하거나 삭제한 규칙까지 포함해서 답합니다.
404 차단은 일부러 평범한 페이지 없음 화면을 응답합니다. 차단된 링크는 애초에 존재한 적 없는 링크와 구분되지 않아야 합니다. 그 밖의 어떤 응답이든, 링크를 찔러 보는 사람에게 찔러 볼 만한 것을 찾았다고 알려 주는 셈이기 때문입니다.
링크 하나를 위한 규칙, 워크스페이스 전체를 위한 규칙
정책은 대개 링크 하나에 관한 이야기가 아닙니다. 워크스페이스 전체 규칙 묶음은 고객이 가진 모든 링크에 적용되고 해당 링크 자체의 규칙 다음에 평가되므로, 링크 하나가 일반적인 금지 위에 예외를 얹을 수 있습니다. 워크스페이스 수준에서는 “데이터센터에서 오는 것은 모두 막기”, 모니터링이 지켜보는 그 링크에서는 “우리 모니터링은 통과”와 같은 식입니다. 링크마다 공용 묶음을 아예 적용하지 않도록 정할 수도 있습니다.
규칙을 실제로 적용하기 전에 가상의 방문자로 시험해 볼 수 있습니다. 국가, 기기, 네트워크 종류, 시각을 정하면 어떤 규칙이 걸리고 방문자가 어디에 도착하는지 그대로 보여 줍니다. 이 미리보기는 다시 구현한 것이 아니라 엣지 워커가 호출하는 것과 동일한 순수 함수를 호출하며, 종단 간 테스트가 그 답을 실제 리디렉션의 Location 헤더와 대조합니다.
규칙의 비용은 나중에 생각할 문제가 아니라 설계 제약입니다
필터링은 리디렉션으로 가는 경로에서 일어납니다. 밀리초가 사람 눈에 그대로 드러나는 유일한 지점입니다. 그래서 엔진은 해당 링크의 규칙이 실제로 필요로 하는 데이터만 요청합니다. 국가 조건은 지역 조회를 부르고, 프록시 종류 조건은 주소 대역 묶음을 불러오며, 검증된 크롤러 조건은 캐시 항목을 읽습니다. 규칙이 없는 링크는 추가 읽기를 단 한 번도 수행하지 않으며, 이는 기대가 아니라 호출 횟수를 세는 테스트로 확인합니다.
규칙이 실제로 가져온 데이터는 클릭 이벤트를 조립하는 백그라운드 작업에 그대로 넘겨지므로, 같은 조회 비용을 두 번 치르는 일은 없습니다.
자주 묻는 질문
필터링 때문에 리디렉션이 느려집니까?
규칙이 없는 링크는 아무 영향도 받지 않습니다. 추가 조회가 전혀 일어나지 않습니다. 규칙이 있는 링크는 그 조건이 요구하는 것만 가져오며, 조회는 원격 데이터베이스가 아니라 엣지를 위해 만들어진 자료 구조를 대상으로 수행됩니다. 규칙 평가 자체는 이미 가져온 값을 다루는 순수 함수입니다.
차단한 트래픽은 어떻게 됩니까? 보고서에서 사라집니까?
아닙니다. 차단된 방문도 규칙 식별자와 적용된 동작과 함께 클릭 이벤트로 기록되며, 필터링 분류에 나타납니다. 방문자는 404나 410, 또는 여러분의 안내 페이지를 받고, 여러분은 필터가 동작하고 있다는 증거를 받습니다.
IP 주소로 필터링할 수 있습니까?
가능합니다. 개별 주소와 서브넷 모두 지원하며, 목록 하나에 최대 1,000개 항목까지 담습니다. 목록은 재사용합니다. “사무실 네트워크”를 한 번 정의해 두고 원하는 만큼 많은 규칙에서 참조하면 됩니다. 리디렉터는 요청 시점에 목록을 가져오지 않습니다. 저장할 때 목록이 링크의 캐시된 설정 안으로 펼쳐집니다.
이것은 봇 탐지와 같은 기능입니까?
봇 탐지는 입력 가운데 하나입니다. 분류기는 이 방문자가 어떤 종류인지 판단하고, 트래픽 규칙은 그에 대해 무엇을 할지 정합니다. 데이터센터만 차단하고 검증된 검색 크롤러는 통과시킬 수도 있고, 품질이 낮은 트래픽을 아예 막는 대신 안내 페이지로 보낼 수도 있습니다.