안티디텍트 브라우저 신뢰성 검증 방법: 체크리스트와 채점표

지문 감지 사이트가 '통과'를 표시한다고 해서 브라우저가 신뢰할 수 있는 것은 아닙니다. 이 글은 지문 일관성, 환경 격리, WebRTC/DNS/IPv6 유출, 프록시 연결 끊김, 커널 업데이트, 권한, 복구, 데이터 관리까지 아우르는 반복 가능한 테스트 방법을 제공합니다.

안티디텍트 브라우저를 검증하는 일은 감지 사이트 하나를 열고 초록색 표시를 보는 것으로 끝나서는 안 됩니다. 감지 페이지는 자신이 구현한 필드만 관찰할 수 있습니다. 환경이 장기적으로 안정적인지, 서로 다른 환경이 데이터를 섞지 않는지, 프록시 연결이 끊길 때 로컬 네트워크를 노출하지 않는지, 팀 권한·실수 삭제 복구·업그레이드 호환성이 건전한지 증명할 수 없습니다.

제품이 신뢰할 수 있는지는 다섯 가지 질문으로 나누어야 합니다. 같은 환경을 여러 번 실행해도 일관적인가? 서로 다른 환경이 설계대로 분리되어 있는가? 네트워크 출구와 WebRTC, DNS, IPv6가 프록시 정책과 일치하는가? 실제 비즈니스 웹사이트와 호환되는가? 팀 데이터, 권한, 복구가 통제 가능한가? 이 다섯 범주의 테스트를 반복하고 결과를 저장해야만 비교 가능한 결론을 얻을 수 있습니다.

'한 단계 검증'으로는 왜 부족한가?

지문 감지 제3자 사이트만으로 판단하면 '올그린' 인터페이스에 설득당하기 쉽습니다. 문제는 다음과 같습니다.

감지 사이트마다 수집하는 필드가 달라 커버리지가 일치하지 않습니다.
'유출 없음'을 표시해도 프록시가 끊길 때의 안전을 보장하지 않습니다.
한 번의 결과로는 재시작과 업그레이드를 아우르는 안정성을 알 수 없습니다.
무작위 생성된 필드는 한 번은 타당해 보여도 장기적으로는 자주 바뀔 수 있습니다.
감지 페이지는 대상 플랫폼의 리스크 관리 모델을 알지 못합니다.
구성원 권한, 클라우드 데이터, 백업, 감사 로그를 볼 수 없습니다.
기술적으로 정상인 환경도 허위 프로필, 스팸 콘텐츠, 비정상 활동을 보완할 수 없습니다.

즉, 제3자 감지 페이지는 측정 도구이지 보안 인증서가 아닙니다. 최종 답이 아니라 관찰 가능한 신호의 원천으로 사용하세요.

먼저 '신뢰할 수 있는'의 수용 기준을 정의하세요

테스트 전에 요구사항을 관찰 가능한 결과로 작성합니다.

차원	합격 기준 예	실패 증상
지문 일관성	같은 환경을 재시작해도 안정 필드가 동일	Canvas, GPU, 언어가 이유 없이 바뀜
매개변수 정합성	UA, 커널, OS, 폰트가 서로 타당	macOS를 주장하지만 명백히 Windows 조합
환경 격리	Cookie, 로컬 스토리지, 확장 기능이 환경을 넘지 않음	A의 로그인 상태가 B에 나타남
네트워크 출구	IP, WebRTC, DNS, IPv6가 정책과 일치	프록시 IP와 로컬 출구가 동시에 나타남
장애 처리	프록시 실패 시 명확한 차단 또는 경고	조용히 로컬 네트워크로 폴백
호환성	핵심 사이트, 업로드, 결제, 동영상이 동작	페이지 크래시, 인증 루프, 확장 기능 손상
복구 가능성	삭제·기기 변경·업그레이드를 정해진 절차로 복구	설정이나 세션이 영구히 유실
팀 거버넌스	최소 권한, 로그, 퇴사 시 박탈이 실행 가능	모두가 관리자 계정 사용

'모든 필드가 다른 것'은 합격 기준이 아닙니다. 지문은 사전 설정된 환경과 정합해야 하며, 같은 환경이 변화를 위해 매번 무작위로 재구성되어서는 안 됩니다.

재현 가능한 테스트 랩을 준비하세요

테스트 대상

최소한 다음을 준비합니다.

네이티브 브라우저 기준 환경 1개.
안티디텍트 브라우저 환경 A와 B.
지역 또는 프로토콜이 다른 테스트용 프록시 2개.
기기 전환 테스트용 주 기기 1대와 예비 기기 1대.
자체 사이트 전용 테스트 계정. 고객의 운영 계정은 사용하지 않습니다.

여기서 핵심은 '테스트 대상 환경'이 언제든 재구축하고 명확히 이름을 붙일 수 있는 테스트용 워크스페이스여야 한다는 점입니다. PurpleMark 웹 앱에서 워크스페이스를 만들 때 플랫폼이나 계정별로 환경 그룹을 구성하고, 테스트 환경 A·B, 테스트 프록시, 전용 테스트 계정을 한 그룹에 모은 뒤 각 환경에 명시적인 OS, 언어, 시간대를 할당하면 나중에 어떤 설정이 차이를 만들었는지 특정하기 쉽습니다.

기록 시트

각 테스트에서 날짜, 제품 버전, 브라우저 커널, OS, 환경 ID, 프록시, 감지 사이트, 결과 스크린샷, 이상을 기록합니다. 스크린샷은 필요한 필드만 남기고 IP, 계정, 키, 기기 식별자를 가립니다.

4개 시점에서 반복합니다. 첫 생성 직후, 닫고 다시 연 후, PC 재시작 후, 제품 또는 커널 업그레이드 후입니다. 한 번만 테스트해서는 시간에 따른 안정성 문제를 발견할 수 없습니다.

1단계: 네이티브 브라우저 기준선을 구축하세요

먼저 일반 Chrome, Firefox, Edge에서 감지를 실행해 이 기기가 평소 노출하는 필드를 파악합니다. 기준선은 '정답'이 아니라, 안티디텍트 브라우저가 사전 설정 항목을 실제로 변경했는지, 명백한 로컬 특성을 남기지 않는지 식별하는 데 도움이 됩니다.

EFF의 Cover Your Tracks는 트래커가 브라우저를 어떻게 보는지 보여 주고 가장 식별력 높은 특성의 개요를 제공합니다. 고유성과 추적 보호를 관찰하기에 좋지만, 결과는 방문자 집단, 브라우저 버전, 테스트 시기에 영향을 받으므로 '고유성이 낮을수록 안전하다'고 단순히 읽지 마세요.

다음 필드를 기록합니다.

브라우저와 커널 버전.
OS와 아키텍처.
화면 크기, 색상 심도, 줌.
시간대, 언어, 지역.
폰트와 미디어 기기 노출.
Canvas, WebGL, Audio 등 요약.
Client Hints, 터치 포인트, 하드웨어 동시성.
원격 IP, IPv6, WebRTC 후보 주소.

2단계: 같은 환경의 시간적 일관성을 테스트하세요

환경 A에서 순서대로 다음을 실행합니다.

시작하고 첫 감지를 완료합니다.
환경을 닫고 다시 시작해 감지합니다.
PC를 재시작한 후 다시 감지합니다.
환경 설정을 바꾸지 않고 네트워크를 전환한 뒤 감지합니다.
제품 또는 커널을 업그레이드한 후 다시 감지합니다.

결과를 범주별로 비교합니다.

안정해야 하는 항목: 환경 이름, 사전 설정 OS, 언어, 폰트 전략, 화면, Canvas/WebGL 전략.
네트워크와 함께 변할 수 있는 항목: 공인 IP, 네트워크 위치, 지연 시간.
버전과 함께 변할 수 있는 항목: 커널, UA, Client Hints. 단 변화는 업그레이드와 정합해야 합니다.
설명이 필요한 항목: 설정 변경 없이 튀는 GPU, 폰트, 기기 이름, 시간대.

신뢰할 수 있는 제품은 변화를 '예측 가능하고 설명 가능하며 감사 가능'하게 만들어야 합니다. 실행할 때마다 무작위 필드가 바뀐다면 벤더에 설계 의도를 확인하고, 대상 비즈니스에서 반복 인증이 발생하지 않는지 테스트합니다.

PurpleMark에서 테스트한다면 이 단계의 초점은 '같은 이름의 환경을 두 번 열었을 때 사전 설정 매개변수가 유지되는지'를 검증하는 것입니다. 같은 환경을 닫고 다시 열었을 때 OS, 언어, 시간대, WebRTC 등 설정 항목이 매번 새 지문을 생성하는 대신 이상적으로는 그대로 유지되어야 합니다. 설명할 수 없는 튐이 보이면 감지 사이트 탓을 하지 말고 해당 환경의 지문·기기 설정 페이지를 확인합니다.

3단계: 서로 다른 환경 간 격리와 정합성을 비교하세요

환경 A와 B는 모든 필드가 달라야 할 필요는 없지만, 공유하면 안 되는 데이터를 공유해서는 안 됩니다. 테스트합니다.

A에서 테스트 사이트에 로그인한 후 B는 여전히 로그아웃 상태인가?
A가 Cookie, 로컬 스토리지, IndexedDB를 쓰면 그 데이터가 B에서 보이지 않는가?
A가 확장 기능을 설치하거나 북마크를 추가하면 B는 설정대로 독립을 유지하는가?
A가 프록시·언어·시간대를 변경하면 B는 영향을 받지 않는가?
두 환경을 동시에 실행할 때 클립보드, 다운로드 디렉터리, 파일 접근 경계가 명확한가?
팀이 A를 공유할 때 B의 리소스도 실수로 공유되지 않는가?

AmIUnique는 브라우저 지문을 브라우저, OS, 화면, 아키텍처, 폰트, 플러그인, 마이크, 카메라 등의 정보를 체계적으로 수집해 브라우저 지문 다양성을 연구하는 것으로 정의합니다. 이 사이트는 데이터와 Cookie 처리 방식을 설명합니다. 테스트 전에 개인정보 고지를 읽고, 민감한 비즈니스 데이터를 담은 환경에서 무작정 제출하지 마세요.

환경 간 비교에서는 해시가 다른지가 아니라 '조합이 타당한지'에 주목합니다. 두 해시가 달라도 무관한 한 필드의 변화를 반영한 것일 수 있습니다. 두 해시가 같아도 모든 세션 데이터가 공유된다는 뜻은 아닙니다.

A와 B가 PurpleMark의 두 독립 환경이라면 로그인 상태, Cookie, 로컬 데이터가 분리된 채 유지되고, 하나를 열어도 다른 하나의 세션이 나타나지 않는지도 확인할 수 있습니다. 이것이 바로 환경과 데이터 격리 수용에서 묻는 부분입니다.

4단계: IP, WebRTC, DNS, IPv6를 확인하세요

네트워크 테스트는 최소 네 가지 상황을 다룹니다. 프록시 정상, 프록시 끊김, 프록시 전환, 시스템 네트워크 변경입니다.

공인 IP

원격 페이지가 보는 공인 주소는 사전 설정된 프록시와 일치해야 합니다. IPv4와 IPv6를 모두 기록합니다. 프록시가 IPv4만 처리한다면 시스템 IPv6가 또 다른 출구를 형성할 수 있습니다.

WebRTC

BrowserLeaks의 WebRTC 테스트는 원격 IP, WebRTC 지원, 후보 주소, 미디어 기기 권한을 보여 줍니다. 노출되면 안 되는 로컬 또는 공인 주소가 나타나는지, 브라우저 설정이 비활성화·교체·중계·프록시 추종 중 무엇인지 확인합니다.

'주소가 나타나지 않는 것'이 WebRTC 기능이 반드시 사용 가능함을 뜻하지는 않습니다. 화상 회의 비즈니스에서는 카메라, 마이크, 실시간 연결까지 테스트해 개인정보 정책이 필요한 기능을 망가뜨리지 않았는지 확인해야 합니다.

DNS

도메인 해석이 프록시 경유인지, 기업 DNS인지, 로컬 네트워크인지 확인합니다. 프록시 IP가 대상 지역에 있어도 DNS 요청이 다른 지역에서 오면 불일치가 됩니다. 정확한 정책은 프록시 유형과 비즈니스 요구에 따라 다릅니다.

프록시 연결 끊김

이것은 가장 중요하면서도 가장 간과되기 쉬운 테스트입니다.

환경을 시작하고 프록시 IP를 확인합니다.
테스트 페이지에서 네트워크 상태를 계속 새로고침합니다.
프록시를 적극적으로 중지하거나 잘못된 자격 증명을 입력합니다.
페이지가 오프라인이 되는지, 명확한 경고를 내는지, 로컬 출구로 돌아가는지 관찰합니다.
프록시를 복원한 후 이전 연결이 다시 수립되는지 확인합니다.
시간, 로그, 스크린샷을 저장합니다.

중요한 비즈니스에서는 조용한 직접 연결보다 실패 시 차단(페일클로즈) 또는 명확한 경고를 선택하는 것이 보통 적절합니다. PurpleMark에서는 프록시를 먼저 독립 리소스로 관리한 뒤 환경에 바인딩합니다. 끊김 테스트에서는 먼저 프록시 목록에서 그 프록시의 출구 IP를 확인하고, 중지시킨 뒤 테스트 대상 환경이 경고를 내며 오프라인 상태로 유지되는지, 조용히 로컬 네트워크로 전환되지는 않는지 관찰합니다. 이를 통해 프록시 리소스와 환경 간 바인딩 관계가 명확한지도 검증됩니다.

5단계: 지문 매개변수가 서로 모순되지 않는지 확인하세요

일반적인 이상 조합은 다음과 같습니다.

UA가 특정 브라우저 버전을 주장하지만 실제 커널 능력이 명백히 일치하지 않음.
OS, 폰트, 스크롤바, 시스템 컨트롤이 정합하지 않음.
시간대, 언어, 지리적 위치가 프록시 지역에 비추어 타당한 설명이 없음.
화면 해상도가 기기 유형과 일치하지 않음.
WebGL 렌더러와 OS 조합이 이상함.
모바일 기기를 주장하면서 데스크톱 전용 동작을 노출함.
Client Hints와 User-Agent가 불일치.

모든 필드를 수동으로 '가장 희귀한' 조합으로 바꾸지 마세요. 제품이 제공하는 정합적 템플릿을 우선 사용하고, 비즈니스에 정말 필요한 항목만 조정합니다. 맞춤 설정마다 변경 기록을 남겨 롤백할 수 있게 합니다. PurpleMark에서 환경을 만들 때 제공되는 OS, Chromium 커널, UA, 시간대, 언어, 지리적 위치, WebRTC, UDP 옵션은 이 매개변수들을 자기 정합적으로 유지하기 위한 것입니다. 테스트할 때 정합적인 기본 설정에서 시작해 비즈니스가 요구하는 필드만 변경하고, 먼저 원래 값을 기록해 비교·롤백할 수 있게 합니다.

6단계: 실제 비즈니스 호환성 테스트를 하세요

감지 사이트는 실제 작업을 대신할 수 없습니다. 기업 자체 테스트 계정으로 다음을 검증합니다.

로그인, 로그아웃, 2단계 인증.
이미지, 동영상, 파일 업로드.
카메라, 마이크, WebRTC.
결제 샌드박스 또는 테스트 결제.
지도, 시간대, 현지화.
확장 기능, 비밀번호 관리자, 클립보드.
장시간 실행, 절전 해제, 비정상 종료.

페이지 오류, 반복 CAPTCHA, 성능, 리소스 사용량을 기록합니다. 계정 제한을 자동으로 지문 탓으로 돌리지 마세요. 먼저 프로필, 네트워크, 결제, 콘텐츠, 행동, 권한, 플랫폼 정책을 배제합니다.

7단계: 업데이트, 복구, 탈퇴를 테스트하세요

신뢰성에는 장애 후 복구도 포함됩니다.

비운영 테스트 환경을 복제합니다.
클라이언트 업그레이드와 커널 업데이트를 시뮬레이션합니다.
Cookie, 확장 기능, 프록시, 탭이 유지되는지 확인합니다.
실수 삭제를 시뮬레이션하고 휴지통에서 복구합니다.
예비 기기에서 환경을 인계받습니다.
내보내기가 허용된 설정과 비즈니스 기록을 내보냅니다.
계정을 닫은 뒤 클라우드 데이터 삭제 흐름을 검증합니다.

벤더가 '생성 성공'만 보여 주고 백업, 롤백, 마이그레이션 질문에 답하지 못한다면 중요한 비즈니스를 맡기에 적합하지 않습니다. PurpleMark에서 검증할 때는 먼저 실수로 삭제한 테스트 환경을 휴지통에서 복구할 수 있습니다(휴지통의 데이터는 일정 기간 보관 후 자동 삭제되므로 단기 복구 훈련에는 적합하지만 영구 백업은 아닙니다). 그다음 주 기기와 예비 기기에서 같은 환경을 정상적으로 인계할 수 있는지, 설정과 로그인 상태가 이어지는지 확인합니다.

8단계: 팀 권한과 감사를 테스트하세요

관리자, 운영자, 외주 세 유형의 테스트 구성원을 만들고 항목별로 검증합니다.

누가 프록시 비밀번호를 볼 수 있는가?
누가 지문과 네트워크 설정을 수정할 수 있는가?
누가 Cookie나 데이터를 내보낼 수 있는가?
누가 환경을 삭제·이전·공유할 수 있는가?
핵심 작업이 구성원, 시간, 대상을 기록하는가?
퇴사 시 세션, 키, 환경 접근을 즉시 박탈할 수 있는가?

여러 사람이 관리자 비밀번호를 공유하는 것은 기술 지문이 좋아도 신뢰할 수 있는 기업 솔루션이 아닙니다. 이때 PurpleMark의 구성원, 역할, 인가 그룹, 운영 로그가 유용합니다. 먼저 다른 유형의 구성원에게 다른 역할과 인가를 할당하고, 다음으로 누가 프록시 비밀번호를 보고 누가 네트워크 설정을 바꿀 수 있는지 검증한 뒤, 마지막으로 운영 로그에서 핵심 작업이 구성원·시간·대상을 기록했는지 확인하고 퇴사하는 구성원의 환경 접근 박탈을 시뮬레이션합니다.

100점 채점표

항목	점수	채점 방법
같은 환경의 시간적 일관성	20	5회 테스트에서 안정 필드에 설명할 수 없는 튐 없음
환경 간 데이터 격리	15	Cookie, 스토리지, 확장 기능, 설정 공유 없음
매개변수 정합성	15	UA, 커널, OS, 언어, 시간대, GPU가 타당
네트워크·유출 처리	20	IP, WebRTC, DNS, IPv6가 정책과 일치, 끊김 시 조용한 직접 연결 없음
실제 사이트 호환성	10	핵심 흐름과 미디어 기능 통과
업데이트·복구·마이그레이션	10	업그레이드, 실수 삭제, 기기 변경, 내보내기 가능
권한·로그·박탈	10	최소 권한과 퇴사 흐름이 실행 가능

소규모 파일럿 진입 문턱으로 80점을 정할 수 있지만, 프록시 끊김 시 직접 연결, 환경을 넘는 세션, 구성원 권한을 박탈할 수 없는 것은 거부권 사항으로 삼아야 하며 다른 점수로 상쇄해서는 안 됩니다.

감지 결과 오판을 피하려면?

원리가 다른 감지 도구를 최소 두 개 사용해 교차 확인합니다.
확장 기능이나 리소스 간섭을 피하려고 감지 페이지를 동시에 많이 열지 않습니다.
같은 네트워크 조건에서 반복하고, 한 번에 한 변수만 바꿉니다.
'통과/실패' 색상만이 아니라 원본 필드를 저장합니다.
제품, 커널, OS 버전을 기록합니다.
테스트 도구가 업데이트되면 기준선을 다시 구축합니다.
감지 사이트의 개인정보 및 데이터 보존 고지를 읽습니다.
테스트 환경에서는 실제 고객 백엔드에 로그인하지 않습니다.

자주 묻는 질문

지문 감지 사이트가 모두 정상이어도 운영에 투입할 수 있나요?

아니요. 반복 실행, 환경 간 격리, 프록시 끊김, 실제 사이트, 업그레이드 복구, 권한 테스트를 완료하고 소수의 비핵심 계정으로 파일럿해야 합니다.

Canvas 해시가 다르면 환경 격리가 성공한 것인가요?

반드시 그런 것은 아닙니다. 해시는 렌더링 결과의 일부만 나타냅니다. Cookie, 로컬 스토리지, 확장 기능, 네트워크, 시간대, 팀 공유 경계를 계속 확인해야 합니다.

WebRTC를 완전히 비활성화해야 하나요?

비즈니스에 따라 다릅니다. 화상 회의 같은 기능은 WebRTC를 필요로 합니다. 목표는 나타나면 안 되는 주소 노출을 피하면서 필요한 호환성을 유지하는 것이지, 전부 끄는 것이 아닙니다.

얼마나 자주 다시 테스트해야 하나요?

제품이나 커널의 주요 업데이트, OS 업그레이드, 프록시 제공자 변경, 권한 모델 변경 후에는 즉시 다시 테스트합니다. 안정기에는 최소 분기별로 샘플링하고 버전 비교를 보존합니다.

맺음말

안티디텍트 브라우저의 신뢰성을 검증하는 것은 '한 가지 비법'이 아니라 재현 가능한 일련의 실험입니다. 제3자 페이지는 필드를 관찰하는 데 도움이 됩니다. 실제로 비즈니스에 쓸 수 있는지를 결정하는 것은 시간적 일관성, 환경 격리, 네트워크 장애 처리, 매개변수 정합성, 실제 사이트 호환성, 복구와 마이그레이션, 팀 거버넌스입니다.

먼저 기준선을 구축하고, 한 번에 한 변수만 바꿉니다. 초록색 표시만 보지 말고 원본 결과를 저장합니다. 문턱에 도달하면 비핵심 계정으로 파일럿하고 지속적으로 다시 테스트합니다. 그래야 마케팅 주장이 검증 가능한 기술적 결론이 됩니다. 시작할 준비가 되면 먼저 PurpleMark 웹 앱에서 테스트 전용 독립 환경을 만들어 첫 라운드를 실행할 수 있습니다. 로컬 브라우저 기능이 필요하면 다운로드 페이지에서 설치를 완료하세요. 테스트는 특정 버전·기기·프록시·시점에서의 성능만 반영합니다. PurpleMark도 다른 브라우저 환경 도구도 신분 위장, 트래픽 부풀리기, 대량 스팸 마케팅, 플랫폼 제재 회피에 사용해서는 안 되며, 계정과 콘텐츠 컴플라이언스를 대신할 수 없습니다.