로컬에서는 잘 동작하던 스크립트가 배포 후 CAPTCHA, 403, 로그인 실패를 만날 수 있습니다. 대개 플랫폼이 특정 도구 자체를 알아보는 것이 아니라 프로토콜, 런타임, 지문, 네트워크, 행동 타이밍에서 자동화가 남기는 관찰 가능한 차이를 평가하기 때문입니다.
반복해서 나타나는 상황이 있습니다. 로컬에서는 스크립트가 잘 동작하지만 배포한 뒤에는 사람 확인, 403, 로그인 실패를 만나기 시작합니다. 가장 먼저 떠올리는 원인은 사용한 도구가 식별되었다는 것입니다.
하지만 플랫폼이 정확히 어떤 도구를 사용했는지 직접 알아내는 데 집중하는 경우는 많지 않습니다. 플랫폼이 보는 것은 이번 방문과 실제 사용자의 방문 사이에 어떤 차이가 있는지입니다. Playwright는 브라우저를 제어합니다. Playwright가 띄운 환경이 사람이 평소 사용하는 브라우저 환경과 눈에 띄게 다르면 자동화된 접근으로 분류될 수 있습니다. 이런 차이는 여러 계층에 걸쳐 있으므로 계층별로 나눠 보면 원인을 더 쉽게 파악할 수 있습니다.
페이지가 렌더링되기 전부터 프로토콜 계층은 말하고 있다
프로토콜 계층에서 보이는 것은 페이지 내용이 아니라 요청 자체의 형태입니다. 요청 헤더 조합, UA Client Hints에 담긴 브라우저 버전과 플랫폼 아키텍처, 연결을 맺는 과정에서의 파라미터 순서 등이 포함됩니다.
자동화 환경은 이런 지점에서 지나치게 깨끗하거나 지나치게 규칙적으로 보일 수 있습니다. 있어야 할 헤더가 빠져 있거나, 각 값이 너무 고정되어 오래 사용된 실제 사용자 기기처럼 보이지 않을 수 있습니다. 이 계층은 판단 비용이 낮고 페이지가 렌더링되기 전에 결론을 낼 수 있어 널리 사용됩니다.
런타임 변수는 두 번째 계층이다
페이지 스크립트가 실행되기 시작하면 또 다른 환경 변수를 읽을 수 있습니다. WebDriver 표준에 따르면 브라우저가 자동화 도구에 의해 제어될 때 navigator.webdriver는 일반적으로 true를 반환합니다. 같은 범주의 신호로는 실행 인자의 자동화 플래그, window.chrome 존재 여부, navigator.plugins와 navigator.permissions의 완전성, headless 모드 여부, 플러그인이나 확장 목록이 비어 있는지 등이 있습니다.
실제 브라우저에는 보통 몇 가지 기본 항목이 있으므로 빈 목록 자체가 특징이 될 수 있습니다. 초기 탐지 방식은 관찰하기 쉽다는 이유로 이 계층에 많이 집중했습니다. 지금은 단일 속성만 보는 플랫폼이 드물고, 대개 여러 값을 함께 평가합니다.
지문은 개별 값보다 서로의 일관성을 본다
그다음은 기기 측 파라미터입니다. Canvas와 WebGL 렌더링 결과, AudioContext 처리 차이, 글꼴 목록, 화면 파라미터, 시간대, 언어, 하드웨어 정보 등이 여기에 해당합니다. 각 값을 따로 보면 문제가 없더라도 함께 조합하면 비교적 안정적인 기기 프로필이 됩니다.
수상해 보일 수 있는 지점은 두 가지입니다. 첫째, 파라미터끼리 맞지 않는 경우입니다. 예를 들어 렌더링 결과는 특정 GPU 계열처럼 보이는데 글꼴 구성은 다른 운영체제처럼 보일 수 있습니다. 둘째, 여러 환경이 완전히 동일한 경우입니다. 모든 작업이 같은 설정으로 시작되면 지문도 모두 같아집니다. 이때 플랫폼은 100대의 기기를 보는 것이 아니라 같은 기기가 100번 방문한 것으로 볼 수 있습니다.
네트워크 출구와 지리 정보는 강한 제약이다
네트워크 측 요소는 브라우저 자체와 큰 관련이 없습니다. IP가 데이터센터인지 가정용 회선인지, 프록시 주소가 대규모로 악용된 적이 있는지, ASN이 클라우드 사업자 소유인지 통신사 소유인지, DNS 설정과 IP 지역이 일치하는지, IP가 국가 사이를 자주 이동하는지 등이 해당합니다.
시간대는 미국인데 네트워크 출구가 독일인 요청은 고급 탐지 기술 없이도 쉽게 눈에 띕니다. 지리적 모순은 전체 체계에서 비용이 가장 적게 들면서도 가장 쉽게 발견되는 불일치 중 하나입니다.
행동 타이밍은 시간이 지나며 누적된다
사람의 조작은 불규칙합니다. 클릭 전에 잠깐 멈추기도 하고 입력 속도도 달라지며, 가끔은 돌아가서 내용을 수정합니다. 반면 스크립트는 정확하고 반복적인 리듬을 보이기 쉽고, 이동 경로가 고정되어 있으며, 목표 밖의 행동을 하지 않고, 요청 밀도도 사람보다 뚜렷하게 높을 수 있습니다.
지난 2년 동안 판정 방식도 계속 바뀌었습니다. 2026년에는 일부 보안 업체가 지속형 행동 검증 엔진을 도입해 첫 방문 때 한 번만 판단하지 않도록 했습니다. 대신 세션 전체에서 마우스 이동, 클릭 리듬, 스크롤 궤적, 페이지 체류 시간을 계속 수집하고 실시간으로 서버에 보내 위험 점수를 계산합니다. 페이지를 새로고침하거나 다음 페이지로 이동해도 이미 쌓인 행동 특성은 0으로 초기화되지 않고 계속 누적됩니다. 이제 한 번의 페이지 로드에서 나온 특징만으로는 충분하지 않으며, 행동은 하나의 과정으로 평가됩니다.
플랫폼이 이런 차이를 위험 신호로 보는 이유
플랫폼의 관점에서 중요한 것은 방문자가 어떤 도구를 썼는지가 아니라 이번 접근이 실제 사람이 서비스를 정상적으로 사용하는 모습과 비슷한지입니다. 스팸 가입, 대량 스크래핑, 악성 요청은 플랫폼에 비용을 발생시키므로 어떤 차원에서든 모순이 생기면 위험 점수가 올라갈 수 있고, 여러 모순이 겹치면 더 분명해집니다.
반대로 특징을 단순히 지우는 것도 방향이 아닙니다. 실제 기기의 지문은 완전하고 내부적으로 일관되어 있습니다. 일부 특징을 의도적으로 제거한 지문 역시 이상하게 보일 수 있습니다. 현실에 가까운 기준은 세 가지입니다. 특징이 충분히 완전한가, 파라미터끼리 일관되는가, 서로 다른 환경 사이에 합리적인 차이가 있는가입니다.
원인 분석과 우회는 다르다
원인을 이 수준까지 나누는 목적은 문제가 어느 계층에 있는지 알아내기 위한 것이지, 보호 장치를 우회하기 위한 것이 아닙니다. 기술적으로 탐지 가능성을 낮춘다고 해서 데이터 수집이나 자동화 권한을 얻는 것은 아닙니다. 경계는 명확합니다. 대상 사이트의 robots 규칙과 서비스 약관을 따르고, 개인정보를 수집하지 않으며, 기술적 보호 조치를 우회하지 않고, 요청 빈도를 제어하고, 상대 서비스의 정상 운영에 영향을 주지 않아야 합니다. 이 원칙은 기술적 접근 방식과 별개지만 가장 높은 우선순위를 가집니다.
