CrispLoginChrome 계정 전환
한국어
Chrome에 추가 Edge에 추가

하나의 Chrome 창에서 여러 격리 작업 공간을 돌리는 방법

약 1357 단어 최종 수정

세션 격리컨테이너 단위 프록시Manifest V3

단일 창 격리는 세 계층의 중첩입니다. 세션·스토리지 계층, 네트워크 경로 계층, 수명 주기 관리 계층이며 커널 가상화가 아닙니다. 지문은 바꾸지 않습니다.

왜 창을 여러 개 띄우는 것이 여러 계정 동시 로그인이 아닌가

먼저 직관 하나를 걷어냅니다. 창은 격리 단위가 아닙니다. 같은 프로필에서 창을 열 개 띄워도 쿠키 저장소와 localStorage, HTTP 캐시를 하나씩 공유하며 사이트가 보는 세션도 하나입니다. 시크릿 창은 저장소가 분리되어 있지만 하나뿐이고 창을 닫으면 사라지므로 계정 열 개를 담을 수 없습니다. 진짜 단위는 ‘세션 컨테이너’입니다. 독립된 쿠키 집합과 스토리지 네임스페이스, 그리고 안정적인 소유 관계 표가 필요합니다. Chrome에는 컨테이너 API가 없습니다(Firefox의 contextualIdentities가 예외). 그래서 확장 프로그램이 세션 계층에서 직접 만듭니다. 어느 탭이 어느 컨테이너에 속하는지 기록하고, 요청과 페이지 두 면에서 그 표대로 나눕니다. CrispLogin도 이 방식이며, 컨테이너는 확장 프로그램이 유지하는 소유 기록이지 Chrome의 기본 기능이 아닙니다. 격리의 단위는 ‘프로세스’가 아니라 ‘세션’입니다.

첫 번째 계층: 쿠키는 왜 섞이지 않는가

계정이 섞이지 않는 이유는 ‘가상 쿠키 항아리 + 탭 단위 요청 헤더 재작성’입니다. 각 컨테이너는 확장 프로그램 안에 자기 쿠키 기록을 따로 가집니다. 요청이 나가기 전에 declarativeNetRequest의 session rule이 condition.tabIds로 탭을 찾아 cookie 요청 헤더를 그 컨테이너의 값으로 통째로 set합니다. 응답이 오면 webRequest로 Set-Cookie를 관찰해 해당 항아리에 되씁니다. 항아리의 쿠키는 path 길이와 생성 시각 순으로 직접 정렬해 직렬화해야 브라우저가 원래 보냈을 헤더와 일치합니다.

놓치기 쉬운 것은 수명입니다. tabIds는 session rule에서만 동작하고, session rule은 브라우저 종료와 확장 프로그램 업데이트 때 지워집니다. 그래서 시작할 때마다 규칙을 다시 설치해야 하며, 이를 빠뜨리면 “재시작 후 모든 작업 공간이 같은 계정이 된다”는 증상이 나옵니다. 페이지 스토리지도 별개의 면입니다. document.cookie는 실제 쿠키 저장소를 읽고 localStorage 네임스페이스도 하나뿐이라, MAIN world 스크립트가 컨테이너 단위로 읽기와 쓰기를 대행해야 합니다. 이 계층은 애플리케이션 계층 격리입니다. 같은 사이트의 두 계정은 나누지만 커널 지문은 건드리지 않습니다.

두 번째 계층: 프록시는 어떻게 작업 공간을 따라가는가

Chrome에는 ‘탭 단위 프록시 설정’ API가 없습니다. chrome.proxy.settings의 범위는 프로필 전체이고, PAC의 FindProxyForURL(url, host)에는 tabId가 전달되지 않습니다. declarativeNetRequest는 헤더를 바꾸고 리다이렉트할 수 있지만 ‘상위 프록시를 고르는’ 동작은 없습니다. 그래서 확장 프로그램이 할 수 있는 일은 ‘작업 공간 → 출구’ 표를 유지하고, 앞에 있는 탭이 바뀔 때 이 전역 설정을 다시 쓰는 것입니다.

PAC은 도메인으로 나눌 수 있지만 판단 근거가 URL이지 탭이 아닙니다. 같은 사이트를 두 작업 공간에서 열면 PAC은 하나의 답만 냅니다. 따라서 “열 개 작업 공간이 각자 터널을 동시에 탄다”는 확장 프로그램에서는 성립하지 않고, 보장되는 것은 “지금 앞에 있는 작업 공간의 출구가 살아 있다”입니다. 작업 공간을 바꿀 때 한 번 재연결이 보이는 것도 같은 이유입니다. 프록시 설정이 바뀌면 이미 열린 연결을 다시 만들어야 합니다. 경계: 이 계층이 바꾸는 것은 출구 IP와 요청 경로이며 TCP/TLS 지문(JA3/JA4)은 그대로입니다. WebRTC는 chrome.privacy.network.webRTCIPHandlingPolicy로 프록시를 거치지 않는 UDP를 막을 수 있지만, 그것은 브라우저 전체 정책이라 작업 공간 단위가 아닙니다.

세 번째 계층: 탭을 닫거나 브라우저를 재시작해도 연결은 남는가

MV3의 백그라운드는 서비스 워커입니다. 이벤트가 30초 없으면 종료되고 모듈 수준 변수와 클로저의 Map이 함께 사라집니다. 그래서 ‘어느 탭이 어느 작업 공간인가’는 메모리에 둘 수 없고 chrome.storage.session에 넣어야 합니다. 이 영역은 확장 프로그램이 로드된 동안 메모리에 상주하고 워커가 회수되었다 다시 깨어나도 남지만, 브라우저를 재시작하면 지워집니다. 기본적으로 콘텐츠 스크립트에 노출되지 않는다는 점도 주의해야 합니다. 페이지 쪽에서 소유 관계를 읽으려면 setAccessLevel을 명시적으로 호출합니다.

여기서 데이터가 둘로 갈립니다. 실행 중 바인딩은 session에, 작업 공간 목록·프록시 설정·스냅샷 색인처럼 재시작을 넘겨야 하는 것은 storage.local에 둡니다. 인과는 단순합니다. 바인딩이 변수가 아니라 session에 있기 때문에 워커가 다시 깨어나도 확장 프로그램은 각 탭의 소유자를 알고 있고, 한 작업 공간의 쿠키를 다른 페이지에 붓지 않습니다. 메모리에만 두면 워커가 잠드는 순간 다음 요청에는 주인이 없어 그룹 중복과 스냅샷 오주입으로 나타납니다.

네 번째 계층: 사이트 스냅샷은 무엇을 저장하고 무엇을 되돌리는가

스냅샷은 다른 문제를 풉니다. 로그인 상태의 이동성이지 실행 중 격리가 아닙니다. 목록의 네 번째에 있지만 격리 자체의 일부는 아닙니다. 한 사이트의 쿠키와 그 사이트의 스토리지를 한 컨테이너 안에서 직렬화해 저장하고, 복원할 때 그 컨테이너의 네임스페이스로 되돌립니다. 둘은 직교합니다. 격리는 두 작업 공간이 동시에 있어도 간섭하지 않음을 보장하고, 스냅샷은 다시 로그인하지 않고 어떤 상태로 돌아감을 보장합니다. 단위는 브라우저 전체가 아니라 사이트이며, 같은 컨테이너의 두 사이트는 서로 무관한 두 레코드입니다.

그래서 스냅샷은 컨테이너에 속해야 합니다. A의 로그인 상태를 B에 부으면 두 계정이 하나로 섞입니다. 하지 않는 일도 적어야 합니다. 되돌리는 것은 애플리케이션 계층의 세션 상태이고 커널 수준 지문이 아니며, 플랫폼의 위험 통제나 기기 검증을 우회하겠다는 약속도 아닙니다. 사용법은 【내부 링크: 사이트 스냅샷의 실제 사용법】을 보십시오.

‘프로필 여러 개’와 무엇이 다른가

Chrome의 다중 프로필은 저장소 루트 디렉터리 수준의 물리적 분할입니다. 프로필마다 쿠키 저장소와 스토리지, 확장 프로그램, 캐시가 따로 있어 격리가 철저합니다. 대가는 네 차원에 나타납니다. 메모리는 프로필마다 자체 네트워크 컨텍스트와 렌더러 프로세스를 가져 세 개면 상주 비용도 대략 세 배입니다. 프로세스는 트리가 각각 따로입니다. 창은 프로필당 하나라 전환이 곧 창 전환입니다. 지문은 프로필끼리 커널과 하드웨어를 공유해 UA와 Canvas, 글꼴이 기본적으로 동일합니다. 조용한 비용도 있습니다. 북마크와 확장 프로그램, 방문 기록이 공유되지 않아 세 개를 넘으면 제각기 흘러갑니다.

확장 프로그램 방식은 반대입니다. 같은 프로필, 같은 창, 프로세스와 커널을 공유해 단일 창 병렬과 거의 0에 가까운 증분 비용을 얻는 대신 커널 지문 계층에는 닿지 못합니다. 같은 것의 두 등급이 아니라 격리 입도를 다르게 자르는 두 방식입니다. 자세한 비교는 【내부 링크: Chrome 다중 프로필과 확장 프로그램 격리 비교】에 있습니다.

능력의 경계: 확장 프로그램이 덮는 계층과 덮지 못하는 계층

지금까지의 경계를 표 하나로 압축합니다. 읽는 법은 ‘플랫폼이 무엇을 보는가’입니다. 세션과 출구를 본다면 가운데 열, 지문 일관성을 본다면 오른쪽 열입니다. 다시 강조하면 확장 프로그램이 하는 일은 세션 계층 격리이며 지문 브라우저와 같은 등급의 격리가 아닙니다. ‘더 가벼운 지문 브라우저’로 보면 위험을 잘못 읽습니다.

확장 프로그램 기반 세션 격리의 능력 경계(2026년 11월 기준)
계층확장 프로그램이 덮는 범위덮지 못하는 것, 또는 대가
쿠키와 로그인 상태컨테이너 단위 분리, 스냅샷으로 직렬화 가능커널은 컨테이너를 모른다. 헤더 재작성 의존이라 규칙을 잃으면 섞인다
페이지 스토리지localStorage와 IndexedDB는 컨테이너 단위 접두사·프록시 가능Service Worker, SharedWorker 등 별도 컨텍스트는 따로 덮어야 한다
출구 IP작업 공간에 묶여 앞 창을 바꾸면 출구도 바뀐다동시에 쓸 수 있는 출구는 하나. 터널 병행 불가
WebRTC프록시를 거치지 않는 UDP 차단 가능(브라우저 전역 정책)작업 공간 단위가 아니며 미디어 경로가 프록시를 우회할 수 있다
TLS 지문불가JA3/JA4는 커널과 네트워크 스택이 결정한다
Canvas / WebGL / Audio불가렌더링은 커널에서 일어나며 확장 프로그램에 재작성 API가 없다
글꼴 열거불가페이지 JS 패치뿐이고 탐지 가능하다
HTTP 캐시불가캐시는 프로필 단위라 컨테이너끼리 공유된다

이 표는 상한의 위치도 보여 줍니다. 확장 프로그램이 대체하는 것은 ‘로그인만 나누려고 클라이언트를 사는’ 동기이지 클라이언트 자체가 아닙니다. 어느 노선을 고를지는 별개의 질문이며, 항목별 비교는 【내부 링크: 확장 프로그램과 지문 브라우저 노선 비교】에 있습니다.

자주 묻는 질문

확장 프로그램의 쿠키 격리는 Chrome의 Partitioned Cookie와 같은 것인가요

아닙니다. Partitioned Cookie는 최상위 사이트로 키를 잡아 한 사이트가 최상위 페이지마다 하나씩만 가집니다. cookies API의 partitionKey는 그것을 읽고 쓰는 키일 뿐이며 구성 요소가 topLevelSite 하나뿐이라 새 구획을 만들 수 없습니다. 작업 공간의 항아리는 컨테이너 단위라 같은 사이트를 얼마든지 가질 수 있고 장부는 확장 프로그램이 관리합니다. 전자는 브라우저의 프라이버시 구획, 후자는 확장 프로그램의 세션 추상입니다.

탭을 닫으면 작업 공간 상태가 남나요

세 가지로 나뉩니다. 탭이 사라지면 바인딩도 사라집니다. 작업 공간 정의(이름, 프록시, 스냅샷 색인)는 재시작을 넘겨야 하는 종류의 데이터라 보통 storage.local에 둡니다. 로그인 상태는 스냅샷을 저장했을 때만 복원되고 아니면 다시 로그인해야 합니다. storage.session의 내용은 브라우저를 닫으면 지워지므로 영속 계층으로 취급하지 마십시오.

단일 창 방식은 브라우저 성능에 영향을 주나요

증분은 격리 장치가 아니라 탭에서 옵니다. 두 번째 브라우저를 띄우지 않고 커널도 복제하지 않으며, 비용은 규칙 매칭과 헤더 재작성으로 요청 한 번당 상수입니다. 실제 비용은 탭 수와 페이지 자체에 있습니다. 작업 공간을 스무 개 열면 느려지는 것은 렌더링이지 격리 계층이 아닙니다.

두 작업 공간이 동시에 다른 출구 IP를 쓸 수 있나요

없습니다. 프록시 설정은 프로필 단위이고 확장 프로그램은 탭이 바뀔 때만 그것을 다시 쓸 수 있으므로, 어느 시점에든 자기 출구를 쓰는 것은 앞에 있는 작업 공간뿐입니다. 뒤에 있는 작업 공간은 규칙에 막히거나 직접 연결됩니다. 진짜 병행 터널은 독립 네트워크 스택을 가진 클라이언트가 필요합니다.

출처와 최종 수정

API 동작에 관한 부분은 공식 문서를 따릅니다. 확장 프로그램의 능력 경계는 Chrome 버전에 따라 달라지므로 도입 전에 해당 시점 문서로 다시 확인하십시오.

최종 수정: 2026년 11월 11일. 여기 적은 것은 이런 확장 프로그램의 일반적인 구현 경로이며, 제품마다 쓰는 API와 데이터 위치가 다를 수 있습니다. 개별 제품의 내부 구조는 그 제품의 문서를 따릅니다.