봇 탐지 신호, 점수 반영 전에 관찰한다…Cloudflare Monitor 모드 추가

봇 탐지 설정을 바꾸면서 정상 고객의 로그인이나 결제까지 막히지는 않을지, 운영자는 먼저 확인하고 싶습니다. Cloudflare가 2026년 10월 19일 추가한 Precursor의 Monitor 모드는 이때 사용할 수 있는 관찰 모드입니다. 방문자의 세션 행동에서 신호를 수집하되 그 신호를 봇 점수와 검증 통과 상태(Challenge clearance)에 반영하지 않습니다. 다만 별도로 설정하는 방문자 확인 화면까지 사라지는 것은 아닙니다. 공식 변경 안내

탐지와 적용 사이에 ‘먼저 관찰’이 생겼습니다

Precursor는 방문자가 한 번 검증을 통과했는지만 보는 대신, 브라우저에서 이어지는 행동을 세션 단위로 평가하는 기능입니다. 이번 발표는 Precursor 자체의 첫 출시가 아니라 Monitor 모드 추가입니다. Cloudflare는 지난 7월 출시 설명에서 이를 Enterprise Bot Management의 기능으로 소개했습니다. 이번 변경 안내에는 요금제 확대나 추가 비용에 관한 별도 발표가 없으므로, 모든 계정에서 무료로 쓸 수 있게 됐다고 해석해서는 안 됩니다. 기존 출시 설명

공식 운영 문서는 세 모드를 구분합니다. Off에서는 Precursor가 동작하지 않습니다. Monitor에서는 신호를 수집하되 봇 점수와 Challenge clearance를 바꾸지 않습니다. Arm에서는 그 신호가 점수와 검증 상태에 영향을 줄 수 있습니다. 기존 JavaScript Detections(JSD)를 사용하고 있다면 Monitor에서 JSD는 계속 동작합니다. 즉, 관찰 모드를 켠다고 기존 탐지까지 중단하는 것은 아닙니다. 모드별 동작

Monitor를 켜도 확인 화면은 따로 봐야 합니다

실무에서 놓치기 쉬운 부분은 Precursor Interstitial입니다. 방문자가 사이트로 넘어가기 전에 거치는 확인 화면으로, 이번 변경에서는 모드와 별도로 설정합니다. 사이트 전체 기본값은 Show Interstitial로 정하고, Interstitial Rules로 특정 경로의 동작을 달리할 수 있습니다. 공식 예시는 대부분의 페이지에서는 끄고 결제 경로인 /checkout에서는 확인 절차를 요구하는 방식입니다. 설정 변경 내용

이 설정은 Monitor와 Arm 모두에서 중요합니다. 공식 문서는 확인 화면을 켰을 때 비브라우저 클라이언트의 API 호출이나 쿠키를 보내지 않는 브라우저 API 요청에 영향을 줄 수 있다고 설명합니다. 서버 간 작업과 모바일 백엔드, 브라우저 페이지가 같은 사이트를 쓴다면 각각의 경로를 구분해야 합니다. API 운영 시 주의사항

따라서 ‘점수에 반영하지 않는다’와 ‘방문자에게 아무 영향도 없다’는 같은 말이 아닙니다. Monitor를 선택했더라도 별도 확인 화면과 기존 보안 규칙의 동작은 함께 점검해야 합니다.

무엇이 달라지고, 무엇은 아직 확인해야 할까요?

현재 확인된 변화는 Precursor를 이용하는 운영자가 새 신호의 수집과 점수 반영을 분리할 수 있게 됐다는 점입니다. 로그인·가입·결제를 운영하면서 봇 대응 정책을 조정하는 팀에는 적용 전 검토 단계가 하나 더 생긴 셈입니다.

VECTORLOG는 이를 ‘더 강한 차단’보다 ‘적용을 결정하기 전에 구분해서 살펴볼 여지’로 봅니다. 탐지 신호와 고객의 실제 이용 흐름을 함께 검토하면, 보안 정책을 바꿀 때 무엇을 비교해야 하는지 더 명확해질 수 있습니다.

다만 정상 고객의 불편이나 부정 이용이 얼마나 줄어드는지는 이번 발표만으로 알 수 없습니다. 공식 문서는 탐지 내용을 확인하는 경로로 Security → Analytics → Traffic → Bot analysis를 안내합니다. 다만 Monitor 신호를 해당 계정에서 어느 수준까지 구분해 볼 수 있는지와 기존 규칙의 영향을 어떻게 해석할지는 실제 화면에서 확인해야 합니다. 분석 화면 안내 전환율 개선이나 보안 효과는 실제 운영 시험 없이 단정할 수 없습니다.

운영팀은 ‘켜기’보다 비교 기준부터 정하세요

다음은 공식 동작 설명을 바탕으로 VECTORLOG가 제안하는 점검 순서입니다. 직접 도입해 측정한 결과는 아닙니다.

• 먼저 현재 설정을 남겨두세요. JSD 사용 여부, 주요 보안 규칙, 로그인·가입·결제·API 경로와 되돌릴 설정을 기록합니다.
• 계정에서 Precursor 제공 여부를 확인하세요. 대시보드의 Security → Settings에서 기능과 모드를 확인하되, 계약 조건이나 비용은 별도로 검토합니다.
• Monitor와 Show Interstitial을 따로 확인하세요. 페이지를 관찰하려는 목적과 특정 경로에 확인 화면을 요구하는 목적을 섞지 않습니다. API 경로의 예외도 함께 검토합니다.
• 정상 사용 흐름을 먼저 시험하세요. 로그인 유지, 결제 진입, 모바일·서버 간 API 요청이 계속 동작하는지 확인하고 기존 상태와 비교합니다.
• Arm 전환은 관찰 결과를 검토한 뒤 판단하세요. 봇 점수 하나만 보지 말고 정상 요청의 실패, 추가 확인 빈도, 고객 문의 등 자신이 확인할 수 있는 지표를 함께 비교합니다. 이상이 생겼을 때 되돌릴 기준과 담당자도 정합니다.

자동화 트래픽이 늘면서 달라지는 웹사이트 운영 기준에서도 살폈듯, 자동화된 방문을 모두 같은 대상으로 볼 수는 없습니다. 이번 기능을 검토할 때도 중요한 것은 버튼을 켰다는 사실이 아니라, 누구의 어떤 이용을 보호하고 어떤 자동화를 제한할지 설명할 수 있는 기준입니다.