Cloudflare Precursor, 클릭 한 번이 아닌 세션 전체에서 봇을 찾는다

브라우저 자동화는 이제 JavaScript를 실행하고 CAPTCHA도 통과해요. 로그인이나 결제 화면에서 한 번 확인하는 방식만으로는 사람과 자동화를 가르기 어려워졌어요. Cloudflare는 포인터와 키보드 활동을 세션 전체에서 이어서 보는 Precursor를 공개했어요. 1
핵심 요약
| 구분 | 내용 | 확인할 점 |
| 탐지 범위 | 로그인·가입·결제 같은 지점이 아니라 방문 세션 전체를 분석해요 | 개별 CAPTCHA를 통과한 자동화도 이후 행동에서 드러날 수 있어요 |
| 수집 신호 | 포인터 이동, 키보드 활동 시점, 포커스, 페이지 표시 상태를 모아요 | 실제 키 입력값은 수집하지 않는다고 밝혔어요 |
| 처리 방식 | HTML에 경량 JavaScript를 넣고 엣지에서 여러 평가 결과를 합쳐요 | 기존 봇 점수와 Challenge 정책에 바로 반영할 수 있어요 |
| 운영 영향 | 애플리케이션 코드를 바꾸지 않고 관찰 모드나 Challenge 강제 모드를 고를 수 있어요 | 오탐과 접근성 사용자의 불편을 함께 살펴야 해요 |
1. 봇 탐지의 단위가 요청에서 사용자 여정으로 넓어졌어요
Cloudflare Turnstile은 로그인, 가입, 결제처럼 위험이 큰 지점에서 사용자를 확인해요. 회사 발표에 따르면 Turnstile은 하루 약 30억 회 실행돼요. 하지만 검증 지점과 다음 검증 지점 사이에서 어떤 행동이 이어졌는지는 충분히 보기 어려웠어요. Precursor는 이 빈 구간을 포함해 세션 전체의 행동 신호를 연속으로 모아요. 2
현대적인 자동화 도구는 실제 브라우저를 띄우고 JavaScript를 실행해요. 짧은 순간만 보면 정상 사용자처럼 보일 수 있어요. 반면 한 세션 내내 사람다운 속도와 방향, 망설임, 작은 보정을 일관되게 재현하려면 자동화 구현이 훨씬 복잡해져요. Precursor는 바로 이 연속성을 판별 자료로 써요.
사람의 움직임에는 물리적인 흔적이 남아요
사람은 마우스를 완벽한 직선으로만 움직이지 않아요. 손목의 회전 범위 때문에 경로가 휘고, 목표를 조금 지나친 뒤 되돌아오기도 해요. 화면을 인지하고 클릭하기까지 짧은 지연도 생겨요. 손떨림과 속도 변화도 일정하지 않아요.
단순 자동화는 직선 보간이나 매끈한 베지어 곡선을 쓰고, 비슷한 속도와 지나치게 정확한 클릭을 반복하는 경향이 있어요. 무작위 흔들림을 추가하더라도 포인터, 포커스, 페이지 표시 상태, 키보드 활동이 세션 내내 자연스럽게 맞물려야 해요. Cloudflare는 마우스 움직임을 여러 신호 가운데 하나로 설명해요. 특정 동작 하나만으로 판정하는 구조는 아니에요. 2
경량 스크립트와 엣지 평가기가 신호를 연결해요
Precursor를 켜면 Cloudflare를 거치는 HTML 응답에 동적으로 조립된 JavaScript가 삽입돼요. 이 스크립트는 포인터 이동과 키보드 활동 시점, 포커스 변화, 페이지가 실제로 보이는지를 기록해요. 이벤트를 압축해 메모리에 잠시 보관한 뒤 평가 계층으로 보내요.
엣지에서는 여러 평가기가 신호를 교차 확인해요. 페이지가 보이지 않는데 포인터 이벤트가 계속 생기는지, 입력창에 포커스가 없는데 키보드 활동이 잡히는지 같은 관계를 볼 수 있어요. 평가 결과는 세션 범위로 누적돼요. 페이지를 새로 고치거나 Challenge를 다시 시작해도 앞선 행동 맥락이 바로 사라지지 않아요.
이 결과는 기존 봇 점수와 보안 규칙에 합쳐져요. 운영팀은 백그라운드에서 관찰만 하거나, 검증되지 않은 세션에 Challenge를 요구하는 방식으로 강도를 조절할 수 있어요. Enterprise Bot Management 고객에게 먼저 제공되고 있으며, Cloudflare는 2026년 말 정식 출시 전까지 무료로 제공할 계획이라고 밝혔어요. 2
개인정보 보호와 접근성은 별도로 확인해야 해요
Cloudflare는 실제 키 값을 저장하지 않고 입력의 타이밍과 리듬만 수집한다고 설명해요. 행동 신호를 사용자 계정이나 로그인 신원, 영구 프로필과 연결하지 않으며 고객 대시보드에도 원시 행동 데이터를 직접 보여주지 않는다고 밝혔어요. 2
수집 항목을 줄였다고 해서 운영 위험이 없어지는 건 아니에요. 트랙볼, 트랙포인트, 스위치 입력 장치, 화면 읽기 도구처럼 일반적인 마우스와 다른 입력 방식은 행동 분포도 달라질 수 있어요. 보안팀은 탐지율만 보지 말고 입력 장치별 오탐률, Challenge 이탈률, 고객 문의를 함께 확인해야 해요. 관찰 모드에서 기준 데이터를 먼저 쌓은 뒤 차단 강도를 조정하는 편이 안전해요.
왜 중요한가요
웹 서비스의 봇 방어 기준이 한 번의 정답 확인에서 행동의 연속성으로 옮겨가고 있어요. 계정 탈취, 가짜 가입, 결제 사기, 대량 스크래핑을 막는 팀은 요청별 규칙만으로 놓쳤던 패턴을 세션 단위에서 찾을 수 있어요. 자동화 도구를 만드는 쪽은 클릭 한 번을 그럴듯하게 꾸미는 수준을 넘어 전체 방문 흐름을 맞춰야 해요. 2
서비스 운영자는 탐지 점수의 근거와 오탐 대응 절차도 준비해야 해요. 접근성 도구를 쓰는 정상 사용자가 반복해서 Challenge를 받으면 보안 기능이 서비스 이용을 막는 장벽이 돼요. 처음에는 차단보다 관찰을 우선하고, 세션 유형과 입력 환경별 결과를 비교해야 해요. 차단 임계값을 바꿀 때는 전환율과 부정 사용률을 같이 봐야 실제 효과를 판단할 수 있어요.
참고 자료
'IT & AI' 카테고리의 다른 글
| 27B 모델을 3.9GB에 담은 Bonsai 27B, 휴대폰 로컬 AI의 새 실험 (0) | 2026.07.15 |
|---|---|
| 과거 커밋을 안전하게 고치는 git history, fixup·reword·split 사용법 (0) | 2026.07.15 |
| lobste.rs는 왜 서버 DB를 MariaDB 대신 SQLite로 옮겼을까요 (0) | 2026.07.15 |
| WebAssembly 파일을 IDE에서 분석하는 Hexana, JetBrains와 VS Code를 함께 지원해요 (0) | 2026.07.15 |
| Papermake, Typst 템플릿을 사내 PDF API로 바꿔줘요 (0) | 2026.07.14 |