지문 환경이 '진짜'인지는 어떤 탐지 사이트가 준 점수로 정해지지 않습니다. 네트워크, 브라우저, 시스템, 하드웨어, 권한 신호가 서로 모순되지 않고 여러 번 재시작해도 안정적인지가 기준입니다. 이 가이드는 계층별 확인 방법, 이상 원인 표, 지문 브라우저 내부에서의 구체적인 점검 절차를 다룹니다.
지문 브라우저 환경이 진짜인지 판단하려면 어떤 탐지 사이트가 90점이나 100점을 주는지만 보면 안 됩니다. 더 유용한 기준은 다음과 같습니다. 네트워크, 브라우저, OS, 하드웨어, 권한 신호 사이에 뚜렷한 모순이 없을 것. 같은 환경이 여러 번 실행돼도 안정적일 것. 업무 사이트가 필요로 하는 기능이 정상 작동할 것.
탐지 도구가 초록색을 보여도 모든 플랫폼이 그 환경을 수용한다는 뜻은 아닙니다. 빨간색도 반드시 사용할 수 없다는 뜻은 아닙니다. 탐지 사이트는 저마다 규칙, 데이터베이스, 채점 모델을 쓰므로 구체적인 필드, 대상 사이트, 실제 업무 시나리오에 맞춰 판단해야 합니다.
브라우저 환경이 '진짜'라는 것의 의미
합리적인 환경은 보통 네 가지 조건을 충족합니다.
- 내부 일관성: 브라우저 엔진, User-Agent, OS, GPU, 언어, 시간대, 네트워크 지역이 서로 설명 가능할 것;
- 시간적 안정성: 재시작 후 핵심 파라미터가 불규칙하게 크게 변하지 않을 것;
- 기능 사용 가능: 로그인, 업로드, 화상 통화, 결제, 광고 관리 화면 등 필요한 기능이 정상 작동할 것;
- 출처 추적 가능: 팀이 이 환경이 어떤 계정, 프록시, 담당자에 연결되는지 알고 설정 변경 기록이 남을 것.
'모든 파라미터가 물리 PC와 동일해야 한다'는 필수 조건이 아닙니다. 브라우저는 프라이버시를 위해 데이터 정밀도를 의도적으로 낮춥니다. 예를 들어 MDN의 deviceMemory 설명은 이 속성이 반올림과 상하한 처리를 거친 근사 메모리 값만 반환한다고 밝힙니다. hardwareConcurrency도 기기의 논리 프로세서 수보다 작을 수 있습니다. 즉 탐지값은 하드웨어 검사 보고서와 같지 않습니다.
탐지 전에 기준선 만들기
운영 중인 중요 계정 환경에서 파라미터를 계속 바꾸지 마세요. 먼저 업무 계정에 로그인하지 않은 테스트 환경을 만들고 다음을 기록합니다.
- 지문 브라우저 버전과 Chromium 엔진;
- OS, User-Agent, 해상도;
- 프록시 유형, 출구 IP, 국가와 도시;
- 언어, 시간대, 위치 정보 설정;
- WebRTC, DNS, Canvas, WebGL, 글꼴 정책;
- 설치된 확장 프로그램과 시작 파라미터.
같은 시점에 두세 개 탐지 도구로 교차 확인하고 스크린샷이나 내보낸 결과를 저장합니다. 이후에는 한 번에 한 변수만 바꿔 기준선과 비교합니다. 그래야 이상이 프록시, 브라우저 설정, 확장 프로그램, 탐지 사이트 자체 중 어디에서 왔는지 알 수 있습니다.
1단계: 네트워크 출구 확인
먼저 HTTP 요청이 보여주는 공인 IP가 환경에 연결된 프록시 IP인지 확인하고, 그다음 DNS, WebRTC, IPv6를 점검합니다.
IP와 DNS
출구 IP, ASN, ISP, 국가, 도시, 시간대를 기록합니다. 데이터베이스마다 도시나 프록시 유형 판정이 다를 수 있습니다. 단일 도시 편차보다 국가나 ASN 수준의 충돌이 더 점검 가치가 있습니다.
DNS 요청은 로컬 네트워크를 통해 가고 페이지 접속은 프록시를 통해 간다면, 탐지 사이트가 출구 지역과 다른 DNS 지역을 보여줄 수 있습니다. 프록시가 원격 DNS를 지원하는지, 브라우저나 시스템에 별도 DNS 설정이 없는지, 확장 프로그램이 네트워크 요청을 바꾸지 않는지 먼저 확인합니다.
WebRTC
WebRTC는 P2P 연결을 위해 ICE 후보 주소를 수집합니다. RFC 8828은 이것이 추가 공인·사설 주소를 노출하거나, 프록시가 직접 연결을 허용할 때 프록시를 우회해 실제 공인 IP가 드러날 수 있음을 설명합니다.
사설 주소가 탐지됐다고 해서 실제 공인 IP가 반드시 유출되는 것은 아닙니다. 192.168.x.x, 10.x.x.x 같은 값은 단순한 LAN 주소입니다. 정작 확인할 것은 프록시 출구와 무관한 또 다른 공인 IP가 WebRTC 후보에 나타나는지입니다.
무작정 WebRTC를 비활성화하지 마세요. 화상 회의, 음성, 실시간 통신이 여기에 의존할 수 있습니다. 업무에 맞춰 WebRTC를 기본 프록시 경유로 만들거나, UDP 지원 프록시나 TURN을 쓰거나, 로컬 주소 노출을 제한하거나, 실시간 통신이 필요 없으면 끄는 방식으로 선택합니다. 변경 후에는 프라이버시 결과와 업무 기능을 모두 테스트합니다.
위치 정보
브라우저 Geolocation API의 좌표는 GPS, Wi-Fi, IP, 셀룰러 네트워크, 사용자 입력에서 비롯될 수 있습니다. W3C Geolocation 사양은 API가 기기의 실제 위치를 보장하지 않는다고 명시합니다.
따라서 IP 도시와 Geolocation 좌표가 조금 달라도 반드시 이상은 아닙니다. 국가, 시간대, 언어, 업무 지역 사이에 설명할 수 없는 충돌이 있는지, 사이트가 위치 권한을 얻었는지가 더 중요합니다.
2단계: 브라우저와 OS 확인
다음 조합을 중심으로 비교합니다.
- Chromium 엔진 버전과 User-Agent 속 브라우저 메이저 버전;
- User-Agent 속 OS와
platform, UA Client Hints, 글꼴 집합; - 브라우저 표시 언어,
Accept-Language, 시간대, 지역 형식; - 해상도, 기기 픽셀 비율, 창 크기, 터치 지원;
- 모바일 식별 정보와 화면 크기, 포인터 유형, 하드웨어 특성.
흔한 이상은 엔진이나 Client Hints를 동기화하지 않고 User-Agent만 수동으로 바꾼 경우, 또는 Windows 글꼴·GPU·조작 특성을 남겨둔 채 macOS 환경으로 적은 경우입니다.
가장 확실한 방법은 필드를 하나씩 짜내는 것이 아니라 검증된 시스템 프리셋을 사용해 엔진, UA, 플랫폼, 관련 파라미터를 한 묶음으로 갱신하는 것입니다. 엔진을 업그레이드한 뒤에는 User-Agent를 다시 생성하거나 확인하고, 명백히 낡은 버전을 오래 고정하지 않도록 합니다.
3단계: 하드웨어와 렌더링 신호 확인
Canvas, WebGL, AudioContext, 글꼴, CPU, 메모리, 미디어 기기, ClientRects 모두 환경 식별에 관여할 수 있습니다. 확인할 때는 '조합이 합리적인가', '안정적인가'에 주목하고 단일 고유 해시를 쫓지 않습니다.
WebGL과 GPU
환경이 특정 OS나 기기를 자처하는데 WebGL 벤더, 렌더러, 하드웨어 가속 상태가 동시에 성립할 수 없다면 시스템 프리셋으로 돌아가 확인합니다. 한 탐지 사이트를 통과하려고 벤더 이름을 다른 브랜드로 함부로 바꾸지 마세요. 잘못된 조합은 대개 더 많은 모순을 낳습니다.
CPU와 메모리
hardwareConcurrency는 브라우저가 사용할 수 있는 논리 프로세서 수를 뜻하며, 브라우저가 낮은 값을 능동적으로 보고할 수 있습니다. deviceMemory는 반올림된 근사값입니다. 4코어나 8GB를 봤다고 실제 하드웨어를 역산할 수 없고, 물리 PC와 다르다고 해서 즉시 바꿔서도 안 됩니다.
확인할 것은 값이 브라우저 지원 범위 안인지, 모바일·데스크톱 기기 유형과 명백히 충돌하지 않는지, 같은 환경의 재시작 후에도 합리적으로 안정적인지입니다.
Canvas와 Audio
프라이버시나 노이즈 정책 때문에 같은 물리 기기도 환경에 따라 다른 결과를 낼 수 있습니다. 하지만 같은 환경의 해시가 새로고침마다 바뀐다면 무작위화가 너무 강해서 장기 세션의 안정성이 오히려 떨어집니다.
같은 환경을 연속 새로고침, 닫았다 열기, 다음 날 시작으로 테스트합니다. 정책이 '환경 수준의 안정적 노이즈'로 설계됐다면 같은 환경에 설명 가능한 연속성이 나타나야 합니다.
4단계: 스토리지, 확장 프로그램, 시작 파라미터 확인
환경 격리는 지문 파라미터뿐 아니라 Cookie, Local Storage, IndexedDB, 캐시, Service Worker, 확장 프로그램, 다운로드 기록도 포함합니다.
두 테스트 환경에서 서로 다른 테스트 사이트에 로그인해 Cookie와 로컬 스토리지가 환경 간에 섞이지 않는지 확인하고, 캐시 삭제, Cookie 가져오기, 환경 복원 후 데이터가 예상대로인지 점검합니다.
확장 프로그램은 흔한 간섭 원인입니다. User-Agent, 프록시, 요청 헤더, Canvas, WebRTC, 페이지 스크립트를 바꿀 수 있습니다. 이상을 발견하면 먼저 테스트 복사본에서 불필요한 확장 프로그램을 모두 비활성화한 뒤 하나씩 활성화합니다. 사용자 지정 시작 파라미터도 하나씩 제외해 여러 도구가 같은 신호를 동시에 바꾸지 않도록 합니다.
흔한 이상과 처리 방법
| 이상 현상 | 가능한 원인 | 권장 처리 |
|---|---|---|
| IP 국가와 시간대 불일치 | 시간대가 로컬 값으로 고정, 또는 프록시 지역 판정 오류 | 먼저 프록시 국가를 확인하고 시간대를 IP 추종 또는 실제 업무 지역에 맞춤 |
| HTTP 출구와 WebRTC 공인 IP가 다름 | WebRTC 직접 연결, UDP 미지원 프록시, 경로 분기 | WebRTC 라우팅 정책을 조정하고 UDP/TURN과 업무 기능을 테스트 |
| UA 버전과 엔진 불일치 | 수동 UA가 낡았거나 엔진 갱신 후 미동기화 | 일치하는 프리셋을 쓰고 UA를 재생성해 UA Client Hints를 재확인 |
| macOS 식별에 Windows 글꼴/GPU | 표면 필드만 변경 | 시스템 수준 프리셋으로 돌아가 크로스 OS 수동 조합을 피함 |
| Canvas가 새로고침마다 변화 | 노이즈 무작위화가 너무 강하거나 확장 프로그램 충돌 | 환경 수준 정책으로 고정하고 충돌 확장을 비활성화한 뒤 재테스트 |
| CPU나 메모리가 빨간 표시 | 탐지 사이트가 반올림 값을 물리 하드웨어로 오해 | 먼저 브라우저 API 기준을 확인하고 실제 조합 충돌인지 판단 |
| 두 탐지 사이트의 결론이 반대 | 데이터베이스, 규칙, 갱신 주기가 다름 | 총점이 아니라 원시 필드를 비교하고 대상 업무 테스트를 기준으로 삼음 |
| 재시작 후 핵심 필드 변화 | 무작위 설정이 저장되지 않았거나 환경이 재구축됨 | 저장·동기화·무작위 지문 정책을 확인하고 환경 수준 파라미터를 고정 |
PurpleMark에서 계층별로 점검하기
위 결론이 모두 정상인데도 어떤 플랫폼이 이상을 알린다면, PurpleMark에서 해당 환경에 대해 점검을 구체화할 수 있습니다.
첫 단계는 출구 확인입니다. PurpleMark의 프록시 관리에서 현재 환경에 연결된 프록시를 확인하고 출구 IP, 지역, 시간대를 확인합니다. 탐지 사이트가 보고한 공인 IP와 비교하고, WebRTC가 출구와 무관한 다른 공인 주소를 드러내지 않는지 점검합니다.
두 번째 단계는 파라미터를 하나씩 손으로 바꾸지 말고 한 묶음으로 확인하는 것입니다. PurpleMark에서 환경을 만들 때 OS, Chromium 엔진, User-Agent, 언어, 시간대, 위치 정보를 한 번에 설정할 수 있고 WebGL, WebRTC, CPU, 메모리, Canvas 같은 지문 파라미터도 구성할 수 있습니다. 엔진, UA, OS, 글꼴이 같은 프리셋을 따르게 하면 'Windows 글꼴에 macOS 식별' 같은 모순된 결과를 피할 수 있습니다. 저장 전에 환경 미리보기를 확인해 각 필드가 합리적인 조합인지 확인합니다.
세 번째 단계는 안전하게 실험하는 것입니다. 문제 환경을 테스트 복제본으로 복사해 운영 중인 환경을 계속 바꾸지 않도록 합니다. 매번 한 변수만, 예를 들어 먼저 프록시나 WebRTC 라우팅을, 그다음 Canvas 노이즈 정책을 조정하고, 변경마다 탐지 결과를 저장합니다. 두 번 연속 재시작해 안정성을 확인한 뒤에야 대상 사이트의 실제 업무 흐름을 실행합니다. 확장 프로그램이 의심되면 복제본에서 하나씩 활성화합니다.
이런 절차로 한 설정 안에서 출구, 파라미터 조합, 안정성을 확인해 '탐지 결과가 어느 계층에서 왔는지'를 파악하기 쉬워집니다. PurpleMark는 파라미터를 일관되게 유지하고 재현 가능한 환경을 보존하는 역할을 합니다. 최종 탐지 결론은 여전히 프록시 품질, 브라우저 버전, 확장 프로그램, 네트워크 라우팅, 대상 사이트 자체의 판단 로직에 달려 있습니다.
만점을 노리다가 새 이상을 만들지 않기
탐지 사이트 점수는 단서를 찾는 데는 유용하지만 유일한 목표가 되어서는 안 됩니다. UA, GPU, Canvas, 글꼴, 시간대를 자주 바꾸면 환경이 오히려 불안정해질 수 있습니다. 남의 '만점 파라미터'를 복사해도 그 사람의 네트워크, 하드웨어, 사용 이력까지 복사되지는 않습니다.
올바른 방법은 원시 필드에서 출발해 뚜렷한 모순부터 고치고, 그다음 장기 안정성과 업무 기능을 검증하는 것입니다. 점수는 최고가 아니어도 조합이 합리적이고 지속적으로 안정적인 환경이, 테스트마다 변하는 '만점 환경'보다 대개 관리하기 쉽습니다.
