블로그로 돌아가기

브라우저 4가지 유형 선택법: 로컬, 안티디텍트, 클라우드, 자동화 전용

브라우저를 로컬, 안티디텍트, 클라우드 폰/클라우드 브라우저, 자동화 전용의 네 범주로 나눠 각각의 역할과 한계를 정리합니다. 먼저 계정 정체성을 어떻게 관리할지 정하고, 그다음 작업을 어디서 실행할지 결정하면 됩니다.

브라우저를 고를 때 질문부터 잘못되는 경우가 많습니다. “어떤 브라우저가 더 좋은가?”보다 “이 브라우저에서 어떤 일을 해야 하는가?”가 더 유용한 질문입니다. 역할을 기준으로 보면 실용적인 선택지는 네 가지입니다. 내 컴퓨터에서 쓰는 일반 브라우저, 계정 정체성을 관리하는 안티디텍트 브라우저, 클라우드에서 실행되는 클라우드 폰 또는 클라우드 브라우저, 그리고 스크립트와 AI가 호출하는 자동화 전용 브라우저입니다.

로컬 브라우저: 가장 간단하지만 가장 먼저 한계에 닿는다

일상적인 웹 사용, 자료 조사, 본인 소유의 몇 개 계정에 로그인하는 정도라면 로컬 브라우저가 가장 간단합니다. 개인정보 보호 확장 프로그램을 설치하고 불필요한 동기화를 끄면 추가 비용도 거의 없습니다.

문제는 계정 수가 늘어난 뒤부터 생깁니다. 여러 프로필을 쓰면 Cookie가 섞이는 것은 막을 수 있지만, 기기의 기반 특성은 그대로입니다. Proxy도 보통 전체 설정만 가능해 프로필마다 별도의 출구를 지정하기 어렵습니다. 프로필이 많아지면 그룹과 라벨이 없어 찾는 것도 번거로워집니다. 더 중요한 것은 정체성의 일관성입니다. 여러 계정이 한 대의 기기와 하나의 환경에 몰려 있으면 플랫폼 관점에서는 같은 운영 주체의 활동으로 보이기 쉬워집니다.

이런 도구의 목적은 무작위성을 늘리고 fingerprint의 entropy를 낮춰 추적을 어렵게 만드는 것입니다. 반대로 멀티 계정 운영은 장기적인 안정성과 서로 맞아떨어지는 파라미터가 필요합니다. 목표가 서로 반대이므로 한 방식이 다른 방식을 대체할 수는 없습니다.

안티디텍트 브라우저: 계정마다 일관된 정체성 하나

안티디텍트 브라우저는 계정마다 독립된 환경을 만듭니다. IP, 시간대, User-Agent, Canvas, WebGL, 오디오 fingerprint, 폰트 fingerprint, 미디어 기기 ID 같은 항목을 한 세트로 생성한 뒤 고정합니다. Cookie와 로컬 저장소도 서로 격리됩니다. 환경을 만든 뒤에는 파라미터가 바뀌지 않기 때문에 다음 로그인에서도 같은 기기처럼 보입니다.

Proxy는 환경별로 연결되므로 각 환경이 자체 출구를 사용하고 HTTP, HTTPS, SOCKS5 같은 주요 프로토콜을 지원합니다. Proxy를 연결한 뒤 시간대와 언어도 함께 맞출 수 있어, 미국 IP인데 언어와 시간대는 다른 지역인 식의 불일치를 줄일 수 있습니다. 플랫폼이 환경을 실제 사용자처럼 판단할 때 보는 것은 IP 하나뿐이 아닙니다.

관리 기능도 중요한 가치입니다. 그룹, 라벨, 메모, 일괄 가져오기/내보내기, 일괄 설정 변경, 일괄 시작/중지를 지원할 수 있습니다. 환경의 생성과 회수도 API를 통해 처리하면 스크립트와 AI가 직접 호출할 수 있습니다.

한계도 분명합니다. 일반적인 일상 웹 사용을 위한 도구가 아니며 복잡성과 비용이 더 높습니다. 장기적으로는 브라우저 코어가 플랫폼의 위험 관리 업데이트 속도를 따라가는지도 중요합니다. 제품을 고를 때 변경 로그를 살펴보고 구체적으로 무엇을 바꿨는지 설명하는지, 아니면 일반적인 표현만 반복하는지 확인할 만합니다.

클라우드 폰과 클라우드 브라우저: 기기를 클라우드로 옮긴다

두 유형의 공통점은 실행 위치를 로컬 기기에서 클라우드로 옮긴다는 것입니다. 클라우드 폰은 클라우드에 모바일 기기를 제공하므로 실제 기기 환경이나 App 설치가 필요한 모바일 작업에 적합합니다. 클라우드 브라우저는 클라우드에 브라우저 인스턴스를 제공해 로컬 기기의 메모리와 연산 자원 부담을 줄입니다.

대가는 명확합니다. 시간 기준 과금이므로 오래 실행하고 인스턴스를 많이 띄울수록 비용이 거의 비례해 늘어납니다. 네트워크 왕복으로 인한 지연은 정밀한 상호작용이 필요한 작업에 불리하고, 로컬 파일은 먼저 업로드해야 합니다. 대신 여러 기기와 위치에서 쉽게 접속할 수 있고, 팀의 여러 사람이 같은 클라우드 기기에 연결할 수 있습니다.

자주 놓치는 점도 있습니다. 클라우드 인스턴스는 보통 실행 장소일 뿐입니다. 계정 정체성이 그 위에 자동으로 생기는 것은 아니므로 정체성과 격리 방식은 별도로 설계해야 합니다.

자동화 전용 브라우저: 스크립트와 AI를 위한 실행기

이 유형의 목표는 하나뿐입니다. 워크플로를 제대로 실행하는 것입니다. 프로그래밍 제어를 지원하고 CDP 프로토콜을 통해 외부 프레임워크와 연결할 수 있으며, AI 도구가 인터페이스를 통해 호출해 페이지 조작, 스크린샷, 콘텐츠 읽기, 폼 입력 등을 수행할 수도 있습니다.

데이터 수집, 회귀 테스트, 대량 반복 작업에 적합합니다. 자체적으로 계정 정체성을 제공하지는 않습니다. 멀티 계정 환경에서는 기존의 격리 환경에 연결하는 방식이 일반적입니다. 실행은 실행 계층이 맡고, 정체성은 정체성 계층이 맡습니다.

한계는 비즈니스 판단이 없다는 점입니다. 페이지가 개편되거나 요소가 사라지면 스크립트가 실패합니다. 실행 전 판단과 실행 후 예외 처리는 여전히 사람이 해야 합니다.

작업 특성에 따라 선택하기

먼저 여러 계정의 정체성을 장기간 안정적으로 유지해야 하는지 묻습니다. 그렇다면 안티디텍트 브라우저를 검토합니다. 아니라면 다음으로 넘어갑니다.

그다음 실제 기기 환경이나 모바일 App이 반드시 필요한지 확인합니다. 필요하면 클라우드 폰을 봅니다. 단지 로컬 기기에서 부하를 떼어내고 싶다면 클라우드 브라우저를 봅니다.

다음으로 작업이 스크립트나 AI로 구동되고 같은 흐름을 반복하는지 확인합니다. 그렇다면 자동화 전용 브라우저를 사용하되, 계정 정체성은 환경 계층에 맡기고 실행기를 그 환경에 연결합니다.

세 조건이 모두 아니라면 개인정보 보호 설정을 적용한 로컬 브라우저면 충분합니다. 무거운 도구를 쓸 필요가 없습니다.

按多身份、移动应用、云端算力和脚本或 AI 工作流要求选择指纹浏览器、云手机、云浏览器、自动化浏览器或本地浏览器

실제 프로젝트에서는 이 유형들을 겹쳐 쓰는 경우가 많습니다. 환경 계층에서는 안티디텍트 브라우저가 정체성을 관리하고, 실행 계층에서는 자동화 브라우저가 워크플로를 수행하며, 실제 기기나 원격 접속이 필요한 부분은 클라우드로 옮깁니다. 대규모 멀티 계정 환경에서는 PurpleMark 같은 환경 관리 도구가 바로 이 환경 계층을 담당해 각 계정의 정체성과 세션을 분리하고, 상위 실행기가 이를 제어할 수 있게 합니다.

한 문장으로 정리하면, 먼저 정체성을 어떻게 관리할지 정하고 그다음 작업을 어디서 실행할지 결정하면 됩니다.