왜 대시보드 확인만으로는 부족한가

앞선 편에서 다룬 체류시간·이탈률 이상 신호 진단은 이미 발생한 트래픽을 사후에 읽어내는 방법입니다. 문제는 가짜 트래픽이 자사몰 서버에 이미 도달한 뒤라는 점입니다. 서버 자원을 소모시키고, 실측 데이터를 오염시키고, 심할 경우 서버 응답 속도까지 느려지게 만듭니다. 사후 진단만으로는 이런 피해를 막을 수 없기 때문에, 요청이 서버에 닿기 전에 걸러내는 인프라 단 방어가 필요합니다.

Cloudflare 같은 CDN·보안 서비스는 우리 서버 앞단에서 모든 요청을 먼저 받아, 정상 트래픽만 통과시키고 의심 트래픽은 차단하거나 추가 인증을 요구하는 구조로 동작합니다.

Cloudflare 봇 점수는 어떻게 작동하나

Cloudflare Bot Management는 도메인으로 들어오는 모든 요청에 실시간으로 1~99 사이의 봇 점수(cf.bot_management.score)를 부여합니다. 점수가 낮을수록 봇일 가능성이 높다고 판단하며, 30 미만이면 일반적으로 봇 트래픽으로 간주됩니다. 이 점수는 요청 헤더, 접속 패턴, TLS 핑거프린트 등 여러 신호를 종합해 산출되며, 단순히 User-Agent 하나만 보는 방식보다 훨씬 정교합니다.

중요한 것은 이 점수가 '검증된 봇'과 '의심스러운 봇'을 구분한다는 점입니다. 검색엔진 크롤러처럼 우리 사이트에 필요한 정상 봇은 verified_bot 변수로 따로 표시돼, 방어 규칙을 만들 때 이런 정상 크롤러까지 실수로 차단하지 않도록 설계할 수 있습니다.

WAF 규칙으로 실시간 차단은 어떻게 연결되나

봇 점수 자체는 숫자일 뿐이고, 실제 차단은 WAF(Web Application Firewall)의 커스텀 규칙을 통해 이뤄집니다. 예를 들어 "봇 점수가 10 미만이면서 특정 페이지(결제, 리뷰 작성 등)에 접근하는 요청은 차단한다"는 식의 조건식을 규칙 엔진에 등록하면, 조건에 맞는 요청이 들어오는 즉시 자동으로 차단되거나 추가 인증(챌린지) 화면을 거치게 만들 수 있습니다. 사람이 매번 로그를 보고 수동으로 IP를 막는 방식과 달리, 이 방식은 조건만 설정해두면 24시간 자동으로 작동합니다.

이런 실시간 차단은 매크로 트래픽이 대시보드 지표를 오염시키기 전에 원천 차단한다는 점에서, 사후 진단·소명보다 근본적인 대응에 가깝습니다.

이 기능은 누구나 바로 쓸 수 있나

Bot Management는 Cloudflare의 Enterprise 요금제에 포함되는 부가 기능으로, 무료·프로 플랜에서는 더 제한된 수준의 기본 봇 차단 기능만 제공됩니다. 즉 소규모 사업자가 곧바로 이 정교한 봇 점수 시스템을 무료로 쓸 수 있는 것은 아니라는 점을 감안해야 합니다. 예산이나 트래픽 규모에 따라 이 기능이 적합한지, 아니면 다른 수준의 방어(예: 기본 WAF 규칙, IP 대역 차단)로 충분한지 판단이 필요합니다. 정확한 요금 구간은 Cloudflare 영업 채널을 통해 직접 확인하는 것이 정확합니다.

인프라 방어가 못 하는 것은 무엇인가

Cloudflare 같은 인프라 단 방어는 우리 서버로 들어오는 트래픽을 걸러줄 뿐, 이미 포털(네이버·구글) 쪽에 남아 있는 어뷰징 이력이나 페널티 판정을 되돌려주지는 못합니다. 즉 포털 검색 결과·플레이스 페이지에서 발생하는 클릭·조회 어뷰징은 포털 자체의 부정클릭 방지 시스템·조사요청 절차로 대응해야 하고, 자사몰 서버로 직접 몰려드는 트래픽은 Cloudflare 같은 인프라로 막는 식으로 방어 대상이 나뉜다는 점을 이해해야 합니다.

다른 인프라 방어 수단과는 어떻게 조합하나

Cloudflare Bot Management 하나만으로 모든 위협을 막을 수는 없습니다. WAF의 일반 규칙(특정 국가 대역 차단, 요청 빈도 제한 등)과 함께 쓸 때 방어력이 높아집니다. 예를 들어 결제·회원가입처럼 민감한 엔드포인트에는 봇 점수 조건과 함께 '동일 IP에서 1분 내 5회 이상 요청'같은 속도 제한(Rate Limiting) 규칙을 겹쳐 적용하면, 봇 점수만으로 걸러지지 않는 트래픽까지 추가로 방어할 수 있습니다.

또한 캡차나 챌린지 페이지(Cloudflare Turnstile 등)를 봇 점수가 애매한 구간(예: 10~30점)에 배치해, 완전 차단 대신 사람인지 한 번 더 확인하는 완충 단계를 두는 방식도 실무에서 자주 쓰입니다. 완전 차단은 정상 이용자를 잘못 막을 위험이 있으므로, 점수 구간별로 대응 강도를 다르게 설계하는 것이 안전합니다.