Chromium 구조 분석 (1) — 저장소를 직접 읽는다

Chromium 구조 분석 — 전체 4편 중 2편 공개. 3~4편은 준비 중이다.

1. 저장소를 직접 읽는다 — 분석 환경, 계층 구조, 프로세스 모델, IPC ← 지금 글
2. 주소에서 픽셀까지 — navigation, document lifecycle, compositing
3. 자바스크립트가 실행되는 자리 — 바인딩, 이벤트 루프, 태스크 큐 (준비 중)
4. 엔진 심층 — V8의 네 단계 티어, Wasm, 디옵티마이제이션 (준비 중)

서론

문제 제기

개발자로서 브라우저 위에 실행되는 웹 프로그램을 만들고 있지만, 내부 원리, 로직에 대해서는 2차 가공 글로만 학습을 해왔습니다. 사실 코드도 공개되어있는 오픈 소스 프로젝트인데, 관심이 너무 없었던 것 같습니다. 이를 문제라고 인지하고, LLM을 이용해서 직접 소스 코드를 분석해보려고 시도했고, 학습하면서 정리도 할 겸, 블로그 글을 작성해보려고 합니다.

접근

이 시리즈는 2차 자료를 경유하지 않는다. 근거는 두 종류만 사용한다.

• 1차 자료: Chromium 및 V8 저장소의 소스 코드, 그리고 저장소 안에 함께 배포되는 설계 문서(docs/, 각 모듈의 README.md)
• 2차 자료: V8 공식 블로그. 날짜와 버전 확인, 그리고 설계 의도의 공식적 진술이 필요한 경우에만 인용한다

모든 주장에는 파일:행 형태의 근거를 붙인다. 각 편 마지막의 참조 절에 고정 커밋 기준 퍼머링크를 본론 절 번호별로 정리해 두었다.

분석 대상

코드는 계속 변경되므로 분석 시점의 커밋을 고정한다.

이 글의 모든 인용은 위 커밋에서 재현된다.

https://github.com/chromium/chromium/blob/<커밋>/<경로>#L<행>

https://source.chromium.org/chromium/chromium/src/+/<커밋>:<경로>;l=<행>

git checkout fca8b75c7d7962742759debada81051bc99e3eb3

범위

1편이 다루는 것은 분석 환경 구성, 저장소의 계층 구조, 계층 간 경계 규칙, 프로세스 모델, 격리의 집행 방식, 프로세스 간 통신이다. 렌더링 파이프라인은 2편, 자바스크립트 실행은 3편, V8 내부는 4편에서 다룬다.

본론

1. 분석 환경 구성

Chromium 공식 체크아웃은 depot_tools와 gclient를 사용하며, 빌드까지 고려하면 수십 GB의 디스크를 요구한다. 코드를 읽는 것만이 목적이라면 이 비용은 불필요하다.

Git의 두 기능을 조합하면 필요한 디렉터리만 받을 수 있다.

git clone --filter=blob:none --no-checkout --depth 1 \
    https://github.com/chromium/chromium.git .
git sparse-checkout init --cone
git sparse-checkout set content third_party/blink/renderer cc mojo base \
    docs services gpu net
git checkout main

위 구성의 실측 결과는 다음과 같다.

전체                 869M  (.git 250M 포함)

third_party/blink/renderer   186M   19,025 파일
content                      165M   16,965 파일
net                           93M    5,699 파일
docs                          40M    1,075 파일
base                          38M    4,131 파일
services                      37M    3,867 파일
gpu                           18M    1,230 파일
cc                            17M    1,165 파일
mojo                          12M    1,693 파일

V8은 별도 저장소이며, 동일한 방식으로 받을 경우 75MB(.git 14MB 포함)에 불과하다. 이유는 4편에서 다룬다.

2. 저장소는 네 계층으로 나뉜다

최상위 디렉터리의 역할 구분은 추측할 필요가 없다. docs/source_tree_overview.md가 직접 분류한다.

문서는 //content를 “the core multi-process rendering engine abstraction”으로 규정하고, “It encapsulates the sandbox and the browser/renderer process model”이라고 명시한다. //third_party/blink는 “where the open web platform is implemented”이며 “runs inside the sandboxed renderer process”다.

의존 방향은 위에서 아래로만 흐른다. content/README.md는 이를 다음과 같이 서술한다.

A module can include code directly from lower modules. However, a module can not include code from a module that is higher than it. This is enforced through DEPS rules.

즉 //content는 //chrome을 참조할 수 없다. 이것은 관례가 아니라 빌드 단계에서 검사되는 제약이다.

3. 경계의 규칙 — //content와 //chrome

계층 구분이 의미를 갖는 것은 경계가 명시적으로 정의되어 있기 때문이다. content/README.md는 어떤 기능이 //content에 들어갈 수 있는지를 세 조건으로 규정한다.

Generally, a feature belongs in this category if and only if all of the following are true:

• Its launch is tracked on the https://chromestatus.com/ dashboard.
• It has an associated spec.
• It is going through the feature development lifecycle.

세 조건을 모두 만족해야 한다. 문서는 이어서 만족하지 않는 기능의 목록을 제시한다 — Extensions, SpellCheck, Autofill, Sync, Safe Browsing, Translate.

이 기능들은 모든 현대 브라우저가 제공하지만 웹 플랫폼의 일부가 아니므로 //chrome에 구현된다. //content는 이들이 필요한 사건을 구독할 수 있도록 확장 지점만 제공한다.

문서는 이 분리의 동기를 다음과 같이 밝힌다.

As the Chromium code has grown, features inevitably hooked into the wrong places, causing layering violations and dependencies that shouldn’t exist.

파일 수를 보면 이 분리의 실질적 효과가 드러난다. //chrome은 51,795개 이상, //components는 41,789개다. 두 디렉터리를 합치면 9만 개를 넘는다. 반면 웹 플랫폼의 핵심인 //content와 blink/renderer는 합계 36,000개 수준이다.

브라우저의 동작 원리를 파악하려는 목적이라면 //chrome과 //components는 읽을 필요가 없다. 전체 코드의 과반이 제품 기능이며, 구조와 무관하다. 이것이 분석에서 가장 먼저 확보해야 할 판단이다.

4. 저장소에 없는 것

“Chromium을 읽는다”는 표현은 부정확하다. 분석에 필요한 구성 요소 상당수가 이 저장소에 존재하지 않는다.

최상위 디렉터리 목록에 v8이 있지만, 체크아웃 결과는 빈 디렉터리다. 최상위 DEPS의 3362행이 그 이유를 보여준다.

'src/v8':

V8은 독립 저장소이며 gclient가 해당 위치로 가져온다. Skia(DEPS:3095), ANGLE(DEPS:2038), Dawn(DEPS:2125), PDFium(DEPS:2840), WebRTC(DEPS:3289)도 동일하다.

자바스크립트 엔진, 2D 그래픽 엔진, OpenGL ES 변환 계층, WebGPU 구현, PDF 렌더러, 실시간 통신 스택이 모두 외부 저장소다. 이 시리즈가 4편에서 V8을 별도로 다루는 것은 임의의 구성이 아니라 저장소 구조를 따른 것이다.

5. 프로세스 모델 — 무엇을 하나의 단위로 볼 것인가

docs/process_model_and_site_isolation.md는 580행의 문서이며, 프로세스 분할의 설계 근거를 다룬다. 서두의 문제 정의는 다음과 같다.

First, the process model must identify which parts of a “program” on the web need to coexist in a single process. Somewhat surprisingly, a program on the web is not a single document plus its subresources, but rather a group of same (or similar) origin documents that can fully access each other’s contents.

즉 분할의 단위는 문서가 아니다. 서로의 내용에 완전히 접근할 수 있는 문서들의 집합이다. 이들을 분리된 프로세스에 두면 데이터 경쟁이나 교착이 발생한다.

문서는 세 단계의 추상을 정의한다.

Security Principal (content/browser/site_info.h). 보안 용어에서 principal은 특정 권한을 가진 주체다. Chromium은 실행 컨텍스트에 principal을 연결하여, 그 프로세스가 접근할 수 있는 데이터를 추적한다. 통상 site(스킴 + eTLD+1)가 principal이 된다. origin이 아니라 site인 이유는 document.domain 조작을 통해 same-site 문서 간 접근이 가능하기 때문이다.

Principal Instance (content/public/browser/site_instance.h). 프로세스 모델의 핵심 단위다. 같은 browsing context group 안에서 같은 principal을 갖는 두 문서는 반드시 같은 프로세스에 있어야 한다. 문서는 그 이유를 명확히 한다.

This access includes cross-document scripting and synchronous communication through shared memory (e.g., SharedArrayBuffer). If such documents were in different processes, data races or deadlocks would occur if they concurrently accessed objects in their shared DOM or JavaScript heaps.

Browsing Context Group (content/browser/browsing_instance.h). 서로에 대한 참조를 가진 탭과 프레임의 묶음이다. 같은 페이지 안의 프레임, window.opener 참조를 가진 팝업 등이 해당한다. 이 그룹 안에서는 이름으로 서로를 찾을 수 있으므로, 같은 principal을 가진 문서가 같은 프로세스에 있어야 한다는 제약이 발생한다.

Site Isolation은 항상 완전하게 적용되지 않는다. 문서는 세 가지 모드를 구분한다.

• Full Site Isolation (site-per-process): 모든 site가 전용 프로세스를 가진다
• Partial Site Isolation: 일부 site만 격리한다. 메모리 제약이 있는 Android가 해당한다
• No Site Isolation

6. 격리는 어떻게 집행되는가

프로세스를 분리하는 것만으로는 보호가 완성되지 않는다. 렌더러 프로세스가 침해된 상황을 가정해야 한다. 문서는 집행 수단을 두 축으로 정리한다.

• Locked Renderer Processes: A renderer process can be limited to documents and workers from a single web site or origin, even if such documents are in iframes.
• Browser-Enforced Restrictions: The privileged browser process can monitor IPC messages from renderer processes to limit their actions or access to site data.

두 번째 축이 다시 두 종류로 나뉜다.

• “Jail” checks: Ensure that a process locked to a particular site can only access data belonging to that site. If all processes are locked, this is sufficient protection.
• “Citadel” checks: Ensure that unlocked processes cannot access data for sites that require a dedicated process. This adds protection in cases where full Site Isolation is not available, such as Android.

이 두 검사는 구현에 그대로 반영되어 있다. content/browser/security/cpsp/child_process_security_policy_impl.cc의 2543행에 PerformJailAndCitadelChecks가 정의되어 있고, 2689행과 2756행의 주석이 각각의 역할을 설명한다.

2689:  // Jail-style enforcement - a process with a lock can only access data
2756:  // Citadel-style enforcement - an unlocked process should not be able to

구현 파일은 4,380행이다. 프로세스 분리라는 설계가 실제로는 “렌더러가 요청할 수 있는 것의 목록을 브라우저 프로세스가 일일이 검사한다”는 형태로 구현되어 있음을 분량이 보여준다.

/// This block defines the Foreign Function Interface for C++ code to call the
/// specified Rust functions. The functions operate on a
/// ChildProcessSecurityPolicyImpl singleton defined further below.
#[cxx::bridge(namespace = "content::rust::child_process_security_policy")]
mod ffi {

7. 프로세스 간 통신 — Mojo

프로세스를 분리하면 통신 수단이 필요하다. Chromium은 Mojo를 사용한다. docs/mojo_and_services.md(576행)가 기본 개념을 정의한다.

A message pipe is a pair of endpoints. Each endpoint has a queue of incoming messages, and writing a message at one endpoint effectively enqueues that message on the other (peer) endpoint. Message pipes are thus bidirectional.

인터페이스는 .mojom 파일로 선언한다. 문서는 이를 protobuf에 대응시킨다.

A mojom file describes interfaces, which are strongly-typed collections of messages. Each interface message is roughly analogous to a single proto message, for developers who are familiar with Google protobufs.

파이프의 두 끝에는 역할이 부여된다.

Given a mojom interface and a message pipe, one of the endpoints can be designated as a Remote and is used to send messages described by the interface. The other endpoint can be designated as a Receiver and is used to receive interface messages.

문서는 이를 한 문장으로 요약한다.

a Remote makes calls on a remote implementation of its interface associated with a corresponding remote Receiver.

실제 .mojom 파일의 형태는 다음과 같다. third_party/blink/public/mojom/browser_interface_broker.mojom이다.

interface BrowserInterfaceBroker {
    // Asks the browser to bind |receiver| to its remote implementation
    // in the browser process.
    GetInterface(mojo_base.mojom.GenericPendingReceiver receiver);
};

메서드 하나뿐이지만 역할이 중요하다. 렌더러가 브라우저 프로세스의 임의 인터페이스를 직접 얻는 것이 아니라, 브로커를 통해 요청하고 브라우저가 바인딩 여부를 결정한다. 5절과 6절에서 확인한 불신의 구조가 통신 계층에도 동일하게 적용되어 있다.

이 시리즈의 체크아웃 범위 안에 .mojom 파일은 833개가 존재한다.

8. 저장소를 읽는 방법

앞 일곱 절의 근거는 대부분 저장소 안의 문서에서 나왔다. 이 사실 자체가 분석 방법의 핵심이다.

첫째, 설계 문서가 코드와 함께 배포된다. docs/ 디렉터리에는 1,075개의 파일이 있고, 각 모듈에도 README.md가 놓여 있다. blink/renderer 아래에만 40개 이상의 README.md가 존재한다. 외부 블로그를 찾기 전에 해당 디렉터리의 문서를 확인하는 것이 순서다.

둘째, 학습 순서가 문서에 명시되어 있는 경우가 있다. content/README.md에는 //content의 최상위 OWNER가 되기 위해 숙지해야 할 항목이 열거되어 있다.

- Render(Frame|FrameProxy|Process|Widget|View)Host
- Render(Frame|Widget|Thread)
- WebContents and WebContentsObserver
- FrameTree and FrameTreeNode
- RenderFrameHostManager
- NavigationHandle and NavigationRequest, their ownership and lifetime
- Page vs RenderFrameHost vs blink's Document
- SiteInstance and BrowsingInstance, SiteInfo
- NavigationController, NavigationEntry vs FrameNavigationEntry
- ChildProcessSecurityPolicy
- BrowserContext, StoragePartition
- ContentBrowserClient

이 목록은 리뷰어 자격 요건으로 작성된 것이지만, 결과적으로 //content를 이해하는 데 필요한 클래스의 목록으로 기능한다. 어떤 클래스가 중요한지를 외부에서 추정할 필요가 없다.

셋째, 열거형과 정적 단정문이 설계를 직접 서술한다. 이 시리즈에서 반복적으로 활용하는 방법이다. 상태 기계는 enum으로, 불변 조건은 static_assert로 코드에 박혀 있는 경우가 많다. 산문으로 된 설명보다 정확하고, 코드와 어긋날 수 없다. 2편의 document lifecycle, 3편의 태스크 유형, 4편의 컴파일러 티어가 모두 이 형태로 확인된다.

넷째, 주석을 그대로 신뢰하지 않는다. 주석은 코드보다 느리게 갱신된다. 2편 8절의 사례가 이에 해당한다 — docs/life_of_a_frame.md는 커밋 중 메인 스레드가 블록된다고 서술하지만, 현재 구현은 입력 응답을 담는 프레임 외에는 블록하지 않는다. 주석에서 얻은 주장은 호출부를 grep으로 확인하는 절차가 필요하다.

결론

확인된 사실

1. 저장소는 네 계층으로 분류되어 있고, 의존 방향이 빌드 단계에서 강제된다. 분류는 docs/source_tree_overview.md에 명시되어 있으며, DEPS 규칙으로 집행된다.

2. 웹 플랫폼과 제품 기능의 경계가 세 조건으로 정의되어 있다. chromestatus 추적, 스펙 존재, 기능 출시 절차. 자동완성·확장·번역 등은 이를 만족하지 않으므로 //chrome에 있다. 전체 코드의 과반이 여기에 속하며, 구조 분석 대상이 아니다.

3. 분석 대상의 상당 부분이 이 저장소에 없다. V8, Skia, ANGLE, Dawn, PDFium, WebRTC는 모두 외부 저장소이며 DEPS로 연결된다.

4. 프로세스 분할의 단위는 문서가 아니라 principal instance다. 동기적으로 서로의 내용에 접근할 수 있는 문서들은 같은 프로세스에 있어야 한다. 이는 성능 선택이 아니라 데이터 경쟁을 피하기 위한 제약이다.

5. 격리는 jail 검사와 citadel 검사로 집행된다. 전자는 잠긴 프로세스가 자기 site의 데이터만 접근하게 하고, 후자는 잠기지 않은 프로세스가 전용 프로세스를 요구하는 site의 데이터에 접근하지 못하게 한다. 구현은 4,380행이며, 현재 Rust로 이식되는 중이다.

6. 프로세스 간 통신은 타입이 지정된 양방향 파이프 위에서 이루어진다. 렌더러는 브라우저의 인터페이스를 직접 얻지 않고 브로커에 요청하며, 바인딩 여부는 브라우저가 결정한다.

이 분석의 한계

샌드박스 자체의 구현(//sandbox)은 다루지 않았다. 운영체제별 기법이 크게 다르며, 이 시리즈의 범위를 넘는다. 네트워크 스택(//net, 5,699 파일)도 다루지 않았다. 또한 코드를 읽었을 뿐이며, 빌드하여 동작을 측정하지는 않았다.

다음 편

2편은 이 구조 위에서 하나의 요청이 흐르는 경로를 추적한다. 주소창 입력부터 화면에 픽셀이 나타나기까지이며, 중심 자료는 docs/navigation.md, core/dom/document_lifecycle.h, docs/how_cc_works.md다.

3~4편은 작성을 마쳤으나 아직 공개하지 않았다. 본문의 “3편에서 다룬다” 형태의 참조는 공개 시점에 링크로 연결된다.

참조

저장소

공식 코드 검색: source.chromium.org · 공식 Git 호스팅: chromium.googlesource.com

1차 자료 — 본론 절별

2절 · 저장소의 계층 구조

• docs/source_tree_overview.md — 최상위 디렉터리 4계층 분류
• third_party/blink/README.md — Blink 디렉터리 구조, common/public/renderer 구분

3절 · //content와 //chrome의 경계

• content/README.md — 입주 조건 3항, 제외 기능 목록, 분리의 동기
• content/shell/ — content_shell, //content만으로 구성된 최소 브라우저

4절 · 저장소에 없는 것

• DEPS — 외부 저장소 정의. ANGLE 2038행 · Dawn 2125행 · PDFium 2840행 · Skia 3095행 · WebRTC 3289행 · V8 3362행

5절 · 프로세스 모델

• docs/process_model_and_site_isolation.md — 전문(580행). Abstractions and Implementations 75행에 principal 3단 정의
• content/browser/site_info.h — Security Principal 구현
• content/public/browser/site_instance.h — Principal Instance 구현
• content/browser/browsing_instance.h — Browsing Context Group 구현

6절 · 격리의 집행

• docs/process_model_and_site_isolation.md#L60 — jail 검사와 citadel 검사의 정의
• child_process_security_policy_impl.cc#L2543 — PerformJailAndCitadelChecks. jail 주석 2689행 · citadel 주석 2756행
• child_process_security_policy_impl.rs — Rust 이식, cxx::bridge FFI
• content/browser/security/cpsp/ — 디렉터리 전체. C++ 구현 4,380행, Rust 2개 파일, shim 2개 파일

7절 · Mojo

• docs/mojo_and_services.md — 전문(576행). Mojo Terminology 15행에 message pipe·Remote·Receiver 정의
• browser_interface_broker.mojom#L11 — BrowserInterfaceBroker 인터페이스
• mojo/README.md — Mojo 디렉터리 구조

8절 · 저장소를 읽는 방법

• docs/ — 설계 문서 디렉터리(1,075 파일)
• content/README.md OWNER 요건 목록 — 핵심 클래스 열거

2차 자료

• Content not Chrome — Chromium Blog, 2008-10. //content 분리의 명칭 유래. content/README.md가 인용하는 원문
• 브라우저는 어떻게 동작하는가? — NAVER D2. 서론에서 다룬 선행 자료
• HTML Standard — Agent clusters — 5절의 principal instance가 대응하는 스펙 개념
• HTML Standard — Site — 5절의 security principal 단위

관련 공식 문서

• Chromium Docs 목차 — 저장소 내 문서 전체 색인
• Get the Code — depot_tools를 사용한 공식 체크아웃 절차. 본론 1절의 sparse checkout은 읽기 전용 대안
• Site Isolation — 6절 주제의 개요
• compromised-renderers.md — 침해된 렌더러를 가정한 방어 설계