"웹 주소를 입력하면 텍스트·이미지·동영상·버튼이 가득한 화면으로 바꿔 주는, 수천만 줄짜리 소프트웨어 한 벌"입니다. 우리가 매일 쓰는 브라우저는 사실 운영체제급으로 복잡한 프로그램입니다. HTML을 읽어 구조를 만들고, CSS로 모양을 입히고, JavaScript를 실행하고, 서버와 안전하게 통신하고, 그 결과를 GPU로 화면에 그려 냅니다. Firefox 저장소는 이 모든 일을 하는 코드의 완전한 원본입니다.
Firefox의 심장은 Gecko라는 브라우저 엔진입니다. 엔진이란 "웹 표준(HTML/CSS/JS 등)을 해석해 실제 화면으로 만드는 부품"을 말합니다. 크롬·엣지·사파리가 쓰는 Blink/WebKit과 경쟁하는, 세상에 몇 안 남은 독립 브라우저 엔진이 바로 Gecko입니다. 그래서 이 저장소는 "앱 하나의 코드"가 아니라 웹 플랫폼 그 자체를 구현한 참조 구현물에 가깝습니다.
보통 앱 저장소가 "완성된 자동차 한 대"라면, Firefox 저장소는 엔진 공장·변속기 공장·차체 공장·조립 라인·품질검사장이 전부 모인 거대한 단지입니다. JS 엔진(SpiderMonkey)은 엔진 공장, 렌더링(WebRender)은 도색 라인, 네트워크(Necko)는 연료 공급 라인, 보안(NSS)은 안전벨트·에어백 공장입니다.
그래서 "Firefox를 읽는다"는 건 차 한 대를 분해하는 게 아니라, 웹이라는 산업 전체가 어떻게 돌아가는지를 들여다보는 일입니다. 입문자에게 벅차 보이지만, 바로 그 점이 이 저장소를 최고의 교재로 만듭니다.
"Firefox가 갑자기 GitHub 트렌딩에?"라고 의아할 수 있습니다. 이 저장소는 신생 프로젝트가 아니라 수십 년 된 코드인데도 주목받는 이유가 셋 있습니다.
가장 큰 사건은 2025년 Firefox 개발이 Mercurial에서 Git/GitHub로 옮겨 간 것입니다. 모질라는 2023년 11월에 이주를 예고했고, 2025년 4월 30일 이 저장소를 공식 진실의 원천으로 선언했습니다. 그 전까지 Firefox 소스는 Mercurial로만 받을 수 있어 클론에 몇 시간이 걸렸지만, Git으로는 몇 분이면 됩니다. "세상에서 가장 큰 오픈소스 중 하나가 GitHub로 들어왔다"는 상징성 때문에 개발자들 사이에서 화제가 됐습니다.
저장소가 GitHub에 있다고 해서 "PR 보내면 되겠네"가 아니다. 모질라는 PR을 받지 않으며, 기존 워크플로를 그대로 유지한다 — 이슈는 Bugzilla, 코드 리뷰는 Phabricator, 코드 착지(landing)는 Lando, CI는 Taskcluster로 한다. GitHub는 "공식 거울 + 빠른 클론 + 코드 열람" 용도다. 기여 흐름은 README가 가리키는 contribution_quickref 문서를 따라야 한다.
오늘날 웹의 대부분은 구글 Blink 계열(크롬·엣지·오페라·브레이브…)이 점유합니다. 사파리의 WebKit, 그리고 Firefox의 Gecko가 사실상 남은 비(非)Blink 엔진의 전부입니다. 엔진이 하나로 수렴하면 "구글이 사실상 웹 표준을 정한다"는 우려가 생깁니다. 그래서 Gecko는 단순한 경쟁 제품이 아니라 웹의 다양성과 표준 견제 장치로 여겨집니다. 학습자에게는 "크롬과 다른 방식으로 같은 웹 표준을 구현한 코드"를 비교해 볼 수 있는 귀한 자료입니다.
흥미롭게도 이 저장소 최상위에는 AGENTS.md, CLAUDE.md, .mcp.json, .claude/, .codex/, .agents/skills/ 같은 AI 코딩 에이전트용 설정 파일이 들어 있습니다. 세계 최대급 코드베이스마저 "에이전트가 코드를 읽고 작업하도록" 가이드를 정비하기 시작했다는 뜻으로, 2026년 개발 트렌드를 상징적으로 보여 줍니다.
| 관점 | Firefox / Gecko의 의미 |
|---|---|
| 웹 표준 | Blink·WebKit과 독립적으로 HTML/CSS/JS 표준을 구현한 참조 구현 |
| 다중 언어 대규모 시스템 | C++·Rust·JS·Python·Kotlin이 한 빌드에서 협력하는 보기 드문 사례 |
| Rust 실전 투입 | Stylo(CSS 엔진)·WebRender(렌더러)를 Rust로 다시 짠 산업계 최대 Rust 도입 사례 |
| 프로세스 격리 보안 | Fission(사이트 격리)로 탭·사이트를 별도 프로세스로 분리하는 현대 보안 설계 |
| 프라이버시 철학 | 비영리 조직이 만드는, 추적 차단을 기본 가치로 둔 브라우저 |
트렌딩 이유는 "거대 코드가 GitHub로 이사 왔다"는 사건성이지만, 진짜 가치는 그 안에 있다. Firefox 저장소는 웹 브라우저라는 가장 복잡한 데스크톱 소프트웨어를 처음부터 끝까지 열어 둔 교과서다. 크롬으로는 못 보는 "엔진의 속살"을 합법적으로, 통째로 볼 수 있다.
Firefox는 "하나의 언어로 짠 앱"이 아니라 여러 언어가 각자 잘하는 일을 맡아 협력하는 연합체입니다. 성능이 중요한 엔진 코어는 C++/Rust, UI와 동작 로직은 JS/HTML, 빌드·자동화는 Python, 안드로이드 앱은 Kotlin이 맡습니다.
| 언어 | 비중 | 주로 맡는 영역 |
|---|---|---|
| JavaScript | 약 29% | 브라우저 UI(chrome), 동작 로직, 내장 페이지, 테스트, devtools |
| C++ | 약 27% | Gecko 코어 — DOM·레이아웃·미디어·IPC·SpiderMonkey 엔진 |
| HTML | 약 22% | UI 마크업 + 방대한 테스트 케이스(web-platform-tests 포함) |
| C | 약 11% | 저수준 라이브러리, NSPR, 일부 미디어·암호 코드 |
| Kotlin | 약 3% | Firefox for Android(Fenix)·GeckoView 안드로이드 레이어 |
| Python | 약 3% | mach 빌드 시스템·moz.build·자동화 스크립트 |
| Rust | (Other에 포함) | Stylo(CSS 엔진)·WebRender(렌더러)·인코딩 등 — 비중은 작아 보여도 핵심부 |
JS 비중이 가장 큰 건 UI(브라우저의 버튼·메뉴·탭 자체가 HTML/JS로 만들어진다)와 엄청난 양의 테스트 코드 때문이다. 정작 "웹페이지를 해석하는 엔진"의 무게중심은 C++와 Rust에 있다. 즉 바깥 껍데기는 웹기술, 속 알맹이는 시스템 언어라는 이중 구조다.
| 부품 | 언어 | 하는 일 |
|---|---|---|
| Gecko | C++/Rust | 브라우저 엔진 전체의 통칭 (DOM+레이아웃+렌더+JS 연결) |
| SpiderMonkey | C++/Rust | JavaScript·WebAssembly 엔진 (js/) — 파싱·JIT 컴파일·GC |
| Stylo (Quantum CSS) | Rust | CSS 스타일 계산을 여러 코어에서 병렬로 — Servo에서 가져옴 |
| WebRender | Rust | 화면 그리기를 GPU로 — 게임 엔진처럼 렌더 (gfx/wr) |
| Necko | C++ | 네트워크 스택 (netwerk/) — HTTP/HTTPS·캐시·DNS·쿠키 |
| NSS | C | Network Security Services — TLS·암호·인증서 (security/nss) |
| XPCOM | C++ | Cross-Platform COM — 컴포넌트를 조립·연결하는 접착제 |
| GeckoView | Kotlin/C++ | 안드로이드에서 Gecko를 임베드하는 래퍼 (mobile/) |
mach가 지휘한다일반적인 npm install이나 cmake가 아니라, Firefox는 자체 빌드 도구 mach(Python)로 모든 걸 합니다. 각 폴더의 moz.build 파일(Python 문법)이 "이 디렉토리는 무엇을 컴파일하는지"를 선언하고, configure.py가 환경을 점검한 뒤, 거대한 빌드 그래프를 만들어 컴파일합니다.
# Firefox 빌드의 큰 흐름 ./mach bootstrap # 1) 의존성·도구체인 자동 설치 (Rust, clang 등) ./mach build # 2) moz.build 그래프 → C++/Rust/JS 컴파일 (수십 분~수 시간) ./mach run # 3) 방금 빌드한 내 Firefox 실행 ./mach test path/ # 4) 해당 영역 테스트 (mochitest·reftest·wpt 등)
| 도구 | 역할 |
|---|---|
mach | 모든 작업의 단일 진입점(빌드·실행·테스트·린트·포맷) |
moz.build | 폴더별 빌드 정의(소스 목록·컴파일 옵션) — Python 문법 |
Cargo.toml / Cargo.lock | Rust 부품(Stylo·WebRender 등)의 의존성 관리 |
| Taskcluster | 모질라 자체 CI — 푸시마다 수만 개 테스트를 분산 실행 |
| Phabricator + Lando | 코드 리뷰 → 자동 착지(머지) 파이프라인 |
| ESLint·clang-format·Prettier | JS·C++ 코드 스타일 자동 검사/정렬 |
Firefox 아키텍처는 두 축으로 이해하면 됩니다. 하나는 "웹페이지 한 장이 픽셀이 되기까지의 흐름"(렌더링 파이프라인), 다른 하나는 "브라우저가 여러 프로세스로 쪼개진 방식"(멀티프로세스/Fission)입니다.
주소창에 URL을 넣고 엔터를 치면, 다음 공정이 순서대로 돌아갑니다. 각 단계가 위 디렉토리 지도의 어느 폴더에 해당하는지 함께 적었습니다.
요리에 비유하면, 네트워크는 장보기(재료 배달), 파싱은 재료 손질(DOM 트리), 스타일은 양념 정하기, 레이아웃은 접시에 담을 자리 잡기, 페인트/합성은 실제로 플레이팅해 손님상에 내는 단계다. JavaScript는 중간에 "역시 간을 다시 맞추자"고 끼어드는 셰프여서, 한 번 바꿀 때마다 뒷 공정이 다시 돌 수 있다 — 이게 "JS가 느리면 화면이 버벅인다"의 정체다.
옛날 브라우저는 한 프로세스에서 모든 탭을 돌렸습니다. 탭 하나가 죽으면 브라우저 전체가 죽었죠. Firefox는 Electrolysis(e10s)로 UI(부모 프로세스)와 웹 콘텐츠(자식 프로세스)를 분리했고, 이후 Fission으로 한 걸음 더 나아가 사이트(출처)마다 별도 프로세스에 가뒀습니다. 한 페이지 안에 광고 iframe이 끼어 있어도, 그 광고는 자기만의 프로세스에 격리됩니다.
콘텐츠 프로세스는 샌드박스(sandbox)라는 감옥에 갇혀, 파일·네트워크·키보드에 직접 손대지 못합니다. 위험한 작업은 모두 부모 프로세스에 IPC 메시지로 요청해야 합니다. 악성 웹페이지가 JS 엔진의 버그를 뚫더라도, 샌드박스 때문에 사용자 PC를 바로 장악하지 못하게 막는 방어 심층화(defense in depth) 설계입니다.
Gecko는 수많은 부품을 XPCOM이라는 규약으로 조립합니다. 각 부품은 인터페이스(XPIDL로 정의)를 공개하고, 다른 부품은 그 인터페이스를 통해서만 호출합니다. 덕분에 C++ 코드와 JS 코드가 서로의 함수를 호출할 수 있습니다(브라우저 UI가 JS인데 엔진은 C++인 이유). 자바의 인터페이스, COM(윈도우)과 비슷한 발상의 크로스플랫폼 버전입니다.
2017년 'Quantum' 프로젝트로 모질라는 병렬화·메모리 안전성이 절실한 부품부터 Rust로 다시 썼습니다. CSS 엔진을 Stylo(여러 코어로 스타일 병렬 계산)로, 렌더러를 WebRender(GPU 합성)로 바꿨습니다. "거대 C++ 코드를 한 번에 갈아엎지 않고, 안전한 언어로 한 조각씩 바꿔 끼운다"는 현실적 현대화 전략의 대표 사례입니다.
ipc/)최상위에 70개가 넘는 폴더가 있어 압도적이지만, 대부분은 "엔진의 한 부품"에 1:1로 대응합니다. 이름과 역할을 알면 "이 기능은 어디 있겠다"가 바로 잡힙니다. 아래는 학습에 중요한 폴더만 추린 지도입니다.
세 가지가 핵심입니다. 첫째, "UI 폴더"와 "엔진 폴더"가 분리돼 있습니다. browser/·toolkit/·devtools/는 브라우저 제품의 껍데기(JS/HTML)이고, dom/ js/ layout/ gfx/ netwerk/는 Gecko 엔진의 알맹이(C++/Rust)입니다. 둘째, Rust 부품이 servo/·gfx/wr에 모여 있습니다 — "신문물은 여기"라고 보면 됩니다. 셋째, testing/과 taskcluster/가 거대한데, 이는 "테스트와 CI가 코드만큼 중요한 1급 시민"이라는 모질라 문화의 반영입니다.
이 저장소는 docs/ 폴더의 내용을 firefox-source-docs.mozilla.org로 공개한다. "어느 폴더가 뭐 하는지", "빌드는 어떻게 하는지", "Fission이 뭔지"가 잘 정리돼 있다. 96만 커밋짜리 코드를 무작정 열기보다, 먼저 source-docs에서 해당 주제 문서를 읽고 → 거기서 가리키는 폴더로 들어가는 순서가 압도적으로 빠르다.
"HTML이 어떻게 화면이 되는가"는 프론트엔드 성능 최적화의 뿌리입니다. 이 저장소는 그 전 과정의 실제 구현을 보여 줍니다. 실습: 간단한 페이지를 만들고 devtools의 Performance 패널로 Style→Layout→Paint 단계를 측정한 뒤, JS로 DOM을 자주 바꿔 보며 리플로우가 늘어나는 걸 눈으로 확인하기.
JS가 어떻게 파싱·JIT 컴파일·가비지 컬렉션되는지를 js/에서 볼 수 있습니다. 실습: SpiderMonkey 셸(js)을 빌드해 --ion-info 같은 옵션으로 JIT가 어떤 코드를 최적화하는지 관찰하고, 핫 루프가 Baseline→Ion으로 승격되는 과정을 따라가기.
Fission(사이트 격리)과 샌드박스는 현대 보안 설계의 교과서입니다. 실습: about:processes 페이지를 열어 탭·사이트별 프로세스가 어떻게 갈리는지 보고, 같은 페이지 안의 cross-origin iframe이 별도 프로세스로 잡히는지 확인하기.
Stylo·WebRender는 "대규모 C++ 코드에 Rust를 점진 도입"한 산업계 최고의 사례입니다. 실습: servo/의 Stylo 코드를 열어 "스타일 계산을 어떻게 여러 스레드로 나누는지" 주석과 함께 읽고, C++↔Rust 경계(FFI)가 어디서 그어지는지 찾아보기.
mach·moz.build는 "수만 개 파일을 어떻게 한 번에 빌드하는가"의 모범 답안입니다. 실습: ./mach build faster나 부분 빌드를 시도하고, moz.build 한 파일을 열어 소스 목록이 어떻게 선언되는지 보기. ./mach try로 일부 테스트만 CI에 올려 보기.
testing/web-platform/에는 모든 브라우저가 공유하는 표준 적합성 테스트(wpt)가 들어 있습니다. 실습: 특정 Web API(예: fetch)의 wpt를 찾아 읽고, "표준이 어떤 동작을 요구하는지"를 테스트 케이스로 역추적하기. 크롬과 Firefox의 wpt 통과율 차이를 비교해 보기.
remote/의 WebDriver BiDi·CDP 구현은 브라우저 자동화(테스트·크롤링)의 토대입니다. 실습: Marionette나 WebDriver로 방금 빌드한 Firefox를 스크립트로 조종해 페이지를 열고 클릭하는 자동화 만들어 보기.
Firefox 실행은 평범한 PC면 충분하지만, 소스에서 빌드하는 건 완전히 다른 이야기입니다. 코드가 워낙 커서 디스크·메모리·시간을 많이 먹습니다.
| 항목 | 권장 사양 (빌드 기준) |
|---|---|
| 대상 OS | Linux · macOS · Windows (모두 공식 지원) / Android는 별도 빌드 |
| 디스크 | 최소 40GB 이상 여유 (소스 + 빌드 산출물 + 도구체인) |
| 메모리 | 16GB 이상 권장 (8GB는 가능하나 매우 느림) |
| CPU | 코어가 많을수록 좋음 — 병렬 컴파일이 핵심 (빌드 수십 분~수 시간) |
| 필수 도구 | Python 3, Rust(rustup), C++ 컴파일러(clang) — ./mach bootstrap이 대부분 자동 설치 |
| 인터넷 | 초기 클론·bootstrap에서 수 GB 다운로드 |
| 코드 검색 | searchfox.org 사용 권장 — 빌드 없이 전체 소스를 색인·탐색 |
전체 빌드는 입문자에게 진입장벽이 높다(디스크·시간). 코드를 이해하는 게 목적이라면 빌드 없이도 충분히 공부할 수 있다. searchfox.org는 Firefox 전체 소스를 웹에서 검색·점프할 수 있게 해 주고, firefox-source-docs는 아키텍처를 설명해 준다. 빌드는 "직접 코드를 고쳐 실행해 봐야 할 때" 가서 하면 된다. 처음부터 96만 커밋을 클론해 빌드하려다 지치는 게 가장 흔한 실패 패턴이다.
지금 쓰는 Firefox에서 about:processes(프로세스 분리), about:memory(메모리 사용), about:support(그래픽·기능 상태)를 열어 본다. "탭마다 프로세스가 나뉘는구나", "WebRender가 켜져 있구나"를 직접 확인하며 4장의 구조와 연결하기.
searchfox.org에서 fetch나 HTMLImageElement 같은 키워드를 검색해, "이 Web API가 실제로 어느 C++ 파일에 구현돼 있는지" 찾아본다. 빌드 없이 96만 커밋 코드를 탐험하는 가장 쉬운 방법.
리스트 1000개를 그리는 페이지를 만들고, devtools Performance로 Style/Layout/Paint를 측정한다. transform 애니메이션(합성 단계)과 top/left 애니메이션(리플로우 유발)을 비교해 "왜 transform이 부드러운가"를 데이터로 설명하기.
source-docs에서 "Fission"과 "Graphics(WebRender)" 문서를 읽고, 본문에 등장하는 개념을 이 저장소의 실제 폴더(ipc/, gfx/wr, dom/)와 연결하는 나만의 지도를 그린다. 거대 코드를 "문서 → 코드" 순으로 읽는 습관 들이기.
git clone → ./mach bootstrap → ./mach build → ./mach run으로 내 Firefox를 띄운다. browser/의 JS 한 곳(예: 새 탭 문구)을 바꿔 다시 빌드해 변화를 확인하며 "UI가 JS로 돼 있다"를 체감하기.
testing/web-platform/에서 실패하거나 미구현된 작은 테스트를 골라 ./mach wpt로 돌려 보고, 표준이 요구하는 동작과 현재 구현의 차이를 분석한다. 실제 기여로 이어질 수 있는, 가장 현실적인 오픈소스 입문 경로.
| 주차 | 학습 주제 | 실천 목표 |
|---|---|---|
| 1주차 | 브라우저 큰 그림 | 엔진/UI 분리, Gecko vs Blink/WebKit, 멀티프로세스 개념 이해 |
| 2주차 | 렌더링 파이프라인 | 파싱→스타일→레이아웃→페인트 흐름을 devtools로 측정·체득 |
| 3주차 | DOM & Web API | searchfox로 특정 API의 구현 위치 추적, 표준 명세와 대조 |
| 4주차 | JS 엔진(SpiderMonkey) | 파싱·JIT·GC 개념, 셸 빌드해 최적화 단계 관찰 |
| 5주차 | 멀티프로세스·Fission | 샌드박스·IPC·사이트 격리, about:processes 실측 |
| 6주차 | 그래픽(WebRender)·Rust | GPU 렌더링 개념, Stylo/WebRender 코드와 Rust FFI 경계 읽기 |
| 7주차 | 네트워크·보안(Necko·NSS) | HTTP 스택·TLS·인증서 흐름, 캐시·쿠키 처리 코드 훑기 |
| 8주차 | 빌드·테스트·기여 | mach 빌드, wpt/mochitest 실행, Bugzilla 'good-first-bug' 도전 |
js/). 세계 최초의 JS 엔진 계보를 잇는다. 파싱·여러 단계의 JIT 컴파일·가비지 컬렉션을 담당한다.gfx/wr). 웹페이지를 게임처럼 GPU로 그려 부드러운 화면을 만든다. Quantum 프로젝트의 대표 산출물.servo/가 그 흔적.netwerk/). HTTP/HTTPS 요청·응답, 캐시, DNS, 쿠키, 프록시를 처리한다.security/nss). HTTPS 연결의 안전을 책임진다. C로 작성됐고 다른 프로젝트에서도 쓰인다../mach build·run·test·lint 등 모든 작업의 단일 진입점이다.mobile/). Firefox for Android(Fenix)가 이걸 통해 Gecko로 웹을 렌더한다.testing/web-platform/). "이 브라우저가 표준을 얼마나 정확히 지키는지"를 객관적으로 측정한다.| 링크 | 설명 |
|---|---|
| GitHub 저장소 | 공식 소스 전체. browser/·dom/·js/·docs/가 출발점 |
| Firefox Source Docs | 아키텍처·빌드·Fission 등 1차 문서 — 코드보다 먼저 읽을 것 |
| searchfox.org | 전체 소스 웹 검색·점프 — 빌드 없이 코드 탐험 |
| Contribution Quick Reference | 기여 흐름(Bugzilla·Phabricator·mach) 빠른 안내 |
| Bugzilla | 이슈 추적기 — 'good-first-bug'로 입문 과제 찾기 |
| MDN Web Docs | 웹 표준(HTML/CSS/JS·Web API) 레퍼런스 |
| TrendShift 페이지 | 트렌딩 추이(일간 21위, 2026-06-10) |
| Mercurial→Git 이주 기사 | 2025년 GitHub 전환 배경(DevClass) |
| Gecko (위키백과) | 엔진의 역사·구조 개관 |