Chrome Browser Process

Browser7 / 24 단계

멀티 프로세스 아키텍처

최상위 브라우저 프로세스가 주소창·탭·네트워크를 관리하고, 탭마다 별도 렌더러 프로세스를 띄운다.

크롬(Chromium)은 하나의 거대한 프로세스가 아니라 역할별로 분리된 여러 OS 프로세스로 구성된 멀티 프로세스 아키텍처(multi-process architecture)를 채택한다. 최상위에 특권을 가진 브라우저 프로세스(browser process, 흔히 main process)가 있고, 그 아래로 탭 안의 웹 콘텐츠를 실행하는 샌드박스된 렌더러 프로세스(renderer process), 그래픽을 담당하는 GPU 프로세스, 네트워크·오디오·스토리지 등 위험한 작업을 격리한 유틸리티 프로세스(utility process), 그리고 (레거시) 플러그인 프로세스로 나뉜다. 이렇게 나누는 핵심 이유는 안정성(한 탭이 죽어도 다른 탭은 살아있음)과 보안(신뢰할 수 없는 웹 콘텐츠를 최소 권한의 샌드박스에 가둠), 성능 격리다. 프로세스 간 통신은 과거의 레거시 IPC를 대체하는 Mojo라는 IPC 프레임워크로 이뤄지며, scoped/typed 인터페이스로 권한을 좁게 제한한다. 사이트 격리(Site Isolation)가 켜지면 렌더러 프로세스는 한 번에 오직 하나의 사이트(site) 문서만 담고, cross-site iframe은 별도 프로세스(OOPIF)로 분리되어 Spectre 같은 사이드채널 공격으로부터 사이트 간 데이터를 보호한다. 단점은 프로세스마다 V8 등 공통 인프라 사본을 갖게 되어 메모리 오버헤드가 크다는 점이며, 크롬은 기기 사양에 따라 프로세스 수를 제한하고 같은 사이트 탭을 합치는 방식으로 이를 완화한다.

내부 구성

브라우저 프로세스 (Browser / Main Process)

가장 높은 권한을 가진 조정자. 크롬 UI 렌더링, 네비게이션, 네트워크·파일·스토리지 접근 정책, 다른 프로세스 생성·관리, 입력 라우팅을 담당한다

UI 스레드 (UI Thread)

브라우저 프로세스 내부의 스레드로 주소창·탭·버튼 등 브라우저 크롬 UI를 그리고 사용자 입력을 받아 적절한 렌더러로 전달한다

스토리지/네트워크 담당부 (Storage & Network)

쿠키, 캐시, IndexedDB 등 스토리지 파티셔닝과 네트워크 요청을 관장한다. 데스크톱에서는 네트워크가 별도 유틸리티 프로세스(Network Service)로 분리된다

렌더러 프로세스 (Renderer Process)

탭 안 웹 콘텐츠(HTML/CSS/JS 파싱·실행, 레이아웃, 페인트)를 담당한다. 샌드박스로 격리되며 사이트별로 하나씩 생성될 수 있다

GPU 프로세스 (GPU Process / Viz)

OS 그래픽 API에 특권 접근하여 여러 렌더러의 컴포지터 프레임을 합성·래스터하고 화면에 표시한다. GPU 드라이버 크래시를 격리한다

네트워크 서비스 (Network Service)

DNS·소켓·TLS·HTTP 처리를 담당하는 //net 래퍼. 데스크톱은 별도 유틸리티 프로세스로, 안드로이드는 기본 in-process로 동작한다

유틸리티 프로세스 (Utility Process)

오디오, 스토리지, 데이터 디코딩 등 특정 위험 작업을 각각 격리해 실행하는 범용 격리 프로세스다

플러그인 프로세스 (Plugin Process)

Flash 등 서드파티 플러그인을 격리 실행한다. 현대 크롬에서는 거의 폐기(레거시)되었다

Mojo IPC

프로세스 간 통신 프레임워크. 타입 안전한 scoped 인터페이스로 권한을 좁게 부여하며 레거시 Chromium IPC를 대체한다

사이트 격리 (Site Isolation)

렌더러 하나에 하나의 site 문서만 담도록 강제하고 cross-site iframe을 OOPIF 별도 프로세스로 분리하는 보안 경계다

샌드박스 (Sandbox)

렌더러 등 신뢰 불가 프로세스가 OS 자원(파일·네트워크·시스템콜)에 직접 접근하지 못하도록 OS 수준에서 제약하는 격리 계층이다

핵심 포인트

브라우저 프로세스는 유일하게 높은 권한을 가지며 UI(주소창·탭·북마크), 네비게이션, 네트워크/파일 접근, 스토리지 정책, 프로세스 생성을 총괄한다
렌더러 프로세스는 신뢰할 수 없는 웹 콘텐츠를 실행하므로 강한 샌드박스에 갇혀 있고 파일/네트워크에 직접 접근하지 못한다
IPC는 레거시 Chromium IPC에서 Mojo로 대체 중이며, 인터페이스 단위로 권한을 좁게 부여(capability-based)한다
사이트 격리(Site Isolation)는 렌더러 하나에 하나의 site만 담고 cross-site iframe을 OOPIF 별도 프로세스로 분리해 Spectre류 공격을 방어한다
멀티 프로세스의 이점은 안정성(크래시 격리), 보안(샌드박스), 성능 격리이고 대가는 메모리 중복(프로세스마다 공통 인프라 사본)이다
크롬은 기기 메모리에 따라 프로세스 개수 상한을 두고, 같은 사이트의 여러 탭을 한 렌더러로 통합해 오버헤드를 줄인다
GPU·네트워크·오디오 등 위험도가 높은 작업은 유틸리티/GPU 프로세스로 out-of-process 격리한다

심화

면접에서 자주 나오는 포인트는 '왜 site(스킴+eTLD+1)를 기준으로 격리하는가'이다. 크롬은 origin(스킴+호스트+포트)이 아니라 site 단위로 프로세스를 나누는데, 이는 document.domain 같은 레거시 same-origin 완화 기능과의 호환성 때문이며, 그래서 정확히는 'origin isolation'이 아니라 'site isolation'이다. 또한 Site Isolation의 결정적 계기는 2018년 Spectre/Meltdown이었다. 사이드채널 공격은 같은 주소공간(프로세스) 안이라면 이론상 임의 메모리를 읽을 수 있으므로, JS 샌드박스만으로는 cross-site 데이터 유출을 막을 수 없다. 따라서 '메모리 자체를 다른 프로세스로 분리'하는 것이 근본 방어책이 되었고, 이는 SharedArrayBuffer 재활성화 조건인 COOP/COEP cross-origin isolation과도 직결된다. 또 하나 깊은 지점은 프로세스 모델의 유연성이다. 크롬은 항상 탭당 하나의 프로세스를 쓰는 것이 아니라 process-per-site-instance를 기본으로 하되, 메모리가 부족하면 같은 사이트의 탭들을 한 프로세스로 병합한다. OOPIF(out-of-process iframe)는 하나의 탭(프레임 트리)이 여러 렌더러 프로세스에 걸쳐 존재할 수 있음을 의미하며, 이때 프레임 트리는 브라우저 프로세스가 소유하고 각 프레임은 프록시(RenderFrameProxy)로 연결된다. 이 구조 덕분에 한 iframe이 크래시해도 부모 문서는 유지된다.

쉽게 말하면 신문사(브라우저)가 기사(탭)마다 별도 작업실(렌더러)을 둬, 한 방에 불이 나도 회사는 계속 돌아감.

면접 예상 질문

#멀티 프로세스#Site Isolation#GPU 프로세스#IPC