✍️ 필사 모드: 브라우저 엔진 2026 — Chromium·Gecko·WebKit·Servo·LadyBird, 누가 진짜로 웹을 그리고 있나

프롤로그 — 세 엔진이 웹을 그린다

당신이 지금 이 페이지를 보고 있는 화면 뒤에는 렌더링 엔진이 있다. HTML을 파싱해 DOM 트리를 만들고, CSS를 매칭해 스타일 트리를 만들고, 둘을 합쳐 박스 트리·레이어 트리·페인트 트리로 내려간 다음, GPU에 텍스처를 던지는 — 수십만 줄짜리 C++ 더미. 우리는 이걸 매일 쓰지만 거의 본 적이 없다.

2026년 5월 기준 데스크톱·모바일·태블릿을 모두 합쳐 보면, 세계 웹의 렌더링은 세 엔진이 거의 다 한다.

• Blink (Chromium 계열) — 약 81%. Chrome, Edge, Brave, Arc, Opera, Vivaldi, Samsung Internet, 그리고 Electron으로 묶인 거의 모든 데스크톱 앱.
• WebKit (Apple) — 약 14%. Safari, 그리고 — 적어도 EU 밖에서는 — iOS의 모든 브라우저 (Chrome·Firefox·Edge for iOS 포함, App Store 정책으로 WebKit 강제).
• Gecko (Mozilla) — 약 3%. Firefox와 그 파생들. 마지막 남은 — 진정한 의미에서 — 비-Chromium·비-Apple 메이저 엔진.

이게 끝이다. 셋이 99%를 가져가고, 나머지 1%는 Pale Moon의 Goanna, Ekioh의 GPU 엔진 Flow, 그리고 — 가장 흥미로운 — 처음부터 다시 쓰고 있는 두 야심작 Servo(Mozilla Rust)와 LadyBird(Andreas Kling, 독립)가 나눠 가진다.

이 글은 그 세 엔진과 — 그 너머에서 부활을 시도하는 — 두 인디 엔진의 2026년 현주소를 정리한다. 그리고 묻는다.

우리는 정말 한 엔진이 80% 넘는 웹을 견딜 수 있는가? 세 엔진이 다양성의 마지노선인가? 그리고 — Servo와 LadyBird가 진짜 프로덕션에 도달할 수 있는가?

1장 · 왜 세 엔진이 남았나 — 30년 압축 역사

웹 엔진의 역사는 짧고도 굵다. 압축하면 이렇다.

1.1 1993–2003: Mosaic, Netscape, IE, 그리고 KHTML

• Mosaic (1993) — 최초의 그래픽 웹 브라우저. NCSA에서 시작해 Netscape로 분기.
• Netscape Navigator (1994) — Mosaic 출신들이 만든 상용 브라우저. 엔진은 자체 개발. 1998년 오픈소스로 풀리면서 Mozilla 프로젝트가 시작됐고, 거기서 Gecko가 태어났다.
• Internet Explorer (1995–) — Microsoft가 Mosaic을 라이선스해 Trident 엔진 개발. 1990년대 말 90% 넘는 점유율로 사실상 웹을 좌우.
• KHTML (1998) — KDE 프로젝트의 Konqueror 브라우저 엔진. 가볍고 깨끗한 C++ 코드베이스. 2003년 Apple이 이걸 포크해 WebKit을 만든다.

1.2 2003–2013: WebKit이 등장하고, Chrome이 모든 걸 바꾼다

• WebKit (2003) — Apple이 KHTML을 포크. Safari 1.0과 함께 출시.
• Chrome (2008) — Google이 WebKit을 포크해 자체 V8 자바스크립트 엔진과 결합. 멀티프로세스 아키텍처로 안정성 점프.
• Blink (2013) — Google이 WebKit에서 갈라져 나와 자체 엔진 시작. 이때 Opera도 자체 Presto 엔진을 버리고 Blink로 옮긴다.

1.3 2013–2020: 단조화의 가속

• Microsoft Edge (2015) — IE 종료, 자체 EdgeHTML 엔진. 그러나 점유율 회복 실패.
• Edge → Chromium (2020) — Microsoft가 EdgeHTML을 버리고 Chromium 기반으로 재출발. 이 시점에 데스크톱 엔진은 사실상 세 개로 압축.
• Servo (2012–2020) — Mozilla가 Rust로 시작한 차세대 엔진. 2020년 Mozilla 대규모 정리해고 때 외부로 이관. 잠시 동면.

1.4 2020–2026: 부활과 균열

• Servo (2023) — Linux Foundation Europe(LFE)으로 이관, 활성 개발 재개. 2026년 임베디드 데모와 자체 브라우저 셸 시연.
• LadyBird (2022–) — Andreas Kling(전 Apple WebKit 엔지니어, SerenityOS 창시자)이 SerenityOS 브라우저를 독립 프로젝트로 분기. 2024년 비영리 LadyBird Browser Initiative 설립, Shopify·GitHub 창업자 등으로부터 자금 확보. 첫 Alpha 출시 목표: 2026년 7월 (Linux/macOS). Windows·Android는 더 늦게.
• iOS WebKit 강제 해제 (2024 EU DMA) — Apple이 EU 한정으로 iOS에서 비-WebKit 엔진을 허용. Chrome iOS의 Blink 기반 버전이 시범 적용. 실제 사용은 더디지만 — 기둥 하나가 흔들리기 시작한 사건.
• DOJ vs Google 판결 (2024 8월) — 미국 법원이 Google이 검색 시장에서 독점을 유지한다고 판결. 2025년 구제책 단계에서 DOJ가 Chrome 매각을 권고. 2026년 항소 진행 중. 만약 강제되면 — 웹 엔진 지형이 다시 한 번 흔들린다.

이 챕터의 핵심: 3개 엔진은 "안정 상태"가 아니라 누적된 합병의 결과다. 1990년대에는 4–5개가 있었고, 2010년대 중반에 압축됐고, 2020년대 중반부터는 다시 — 작지만 — 발산이 시작되고 있다.

2장 · 엔진별 정밀 해부

2.1 Chromium / Blink — 사실상의 표준

소유자: Google (BSD 라이선스, 오픈소스이지만 사실상 단일 회사가 방향 결정)

자바스크립트 엔진: V8

렌더 파이프라인: Blink → cc(컴포지터) → Viz(GPU 프로세스) → Skia/Dawn

채택 브라우저:

• Chrome (Google)
• Edge (Microsoft, 2020년 전환)
• Brave (사생활 강조)
• Arc / Arc Search (The Browser Company)
• Opera (2013년 전환)
• Vivaldi
• Samsung Internet
• Yandex Browser
• Naver Whale
• 그 외 수십 개의 마이너 포크
• Electron 기반 데스크톱 앱 전부 (VS Code, Slack, Discord, Notion, Figma desktop 등)
• Tauri의 일부 옵션 (기본은 OS WebView지만 Bundled Chromium 옵션도 있음)

강점:

• 가장 빠른 표준 채택. Container Queries, View Transitions, Anchor Positioning 같은 최신 기능을 가장 먼저 출시.
• 개발자 도구가 산업 표준.
• WebGPU, WebRTC, 미디어 코덱 지원이 가장 광범위.

약점:

• 단일 회사가 사실상의 표준을 정의하는 구조. "Blink가 지원하면 표준" 압력.
• 메모리 사용량이 큼. 탭 하나당 수백 MB.
• Manifest V3 같은 확장 API 변경에서 사생활/광고 차단 측면 논란.

거버넌스: 형식적으로는 오픈소스이지만 커밋의 거의 100%가 Google 직원. Microsoft가 Edge 채택 이후 일부 기여 (특히 Windows·접근성). Igalia(스페인 컨설팅)가 외부 컨트리뷰터로 의미 있는 비중 차지 — Container Queries, MathML 같은 기능 다수.

2.2 WebKit — Apple의 정원

소유자: Apple (LGPL/BSD 혼합)

자바스크립트 엔진: JavaScriptCore (JSC)

렌더 파이프라인: WebCore → WebKit2 (멀티프로세스) → Metal/CoreAnimation

채택 브라우저/플랫폼:

• Safari (macOS, iOS, iPadOS, visionOS)
• iOS의 거의 모든 브라우저 — App Store 정책으로 WebKit 강제 (Chrome iOS, Firefox iOS, Edge iOS, Brave iOS 모두 WebKit 래퍼)
• 2024년 EU DMA 이후 EU 한정 iOS에서 비-WebKit 허용, 실제 적용은 점진적
• macOS의 SwiftUI WebView, AppKit WKWebView
• PlayStation 5 시스템 브라우저
• Amazon Kindle, BlackBerry, Tizen 등 일부 임베디드

강점:

• macOS·iOS에서 GPU·미디어 통합이 우수 (Metal 백엔드).
• 에너지 효율 — 노트북·모바일 배터리 최적화.
• 사생활 보호 — Intelligent Tracking Prevention(ITP) 선도.

약점:

• 표준 채택이 느린 경우 다수. WebGPU·WebRTC·OffscreenCanvas·Service Worker 같은 기능에서 Blink/Gecko 대비 1–2년 늦었음.
• iOS의 WebKit 강제는 진정한 의미에서 — 적어도 EU 밖에서는 — 사용자에게 엔진 선택권을 주지 않음.
• 개발자 도구가 Blink·Gecko 대비 약함.

거버넌스: Apple 직원이 거의 모든 커밋. Igalia가 외부 기여 의미 있음 (특히 WPE WebKit이라는 임베디드 변종). Sony가 PlayStation 브라우저 관련 일부 기여.

2.3 Gecko — 마지막 비-Chromium 깃발

소유자: Mozilla Foundation / Mozilla Corporation (MPL 2.0)

자바스크립트 엔진: SpiderMonkey

렌더 파이프라인: Gecko → WebRender (Rust 기반 GPU 컴포지터) → Direct3D/Metal/OpenGL

채택 브라우저:

• Firefox (데스크톱, Android)
• Firefox ESR (장기 지원)
• LibreWolf (사생활 강화 포크)
• Waterfox (오래된 확장 호환)
• Tor Browser (Firefox ESR 기반)

강점:

• 가장 강한 사생활 보호. 추적 차단·핑거프린팅 방지가 기본.
• WebRender — Rust로 다시 쓴 GPU 컴포지터. 합성 단계에서 효율적.
• 표준 위원회에서 — 비록 작아도 — 균형추 역할.

약점:

• 인력과 자원이 작음. Mozilla는 2020년·2024년에 큰 정리해고를 거쳤고 2026년 현재 풀타임 엔진 엔지니어는 한 자릿수 후반/두 자릿수 초반.
• 표준 채택이 종종 Blink보다 6–12개월 늦음. WebGPU는 2025년 후반에야 안정화.
• 모바일 점유율이 매우 작음 (Android에서 한 자릿수 초반, iOS는 WebKit 래퍼라 실질 점유 0).

거버넌스: Mozilla 단일 회사 주도. 외부 기여가 있긴 하지만 비중 작음. 2024년 이후 — Mozilla가 광고·AI로 사업 다각화를 시도하면서 — "엔진 투자가 줄고 있는 것 아닌가" 하는 논란이 커지는 중. 이른바 "Mozilla의 사명 표류" 논쟁.

2.4 Servo — Rust로 다시 쓰는 미래

소유자: 현재는 Linux Foundation Europe (LFE) 산하 프로젝트 (2023년 이관)

자바스크립트 엔진: SpiderMonkey (Gecko에서 가져옴)

렌더 파이프라인: Rust 풀스택. 병렬 레이아웃·병렬 페인트 — 멀티코어 활용이 설계 핵심.

역사:

• 2012년 Mozilla Research에서 시작. Rust 언어 자체가 Servo를 위해 진화한 측면이 있음.
• 일부 Servo 컴포넌트(스타일 시스템, WebRender)는 Gecko로 통합되어 Firefox에 사용됨.
• 2020년 Mozilla 정리해고로 거의 동면.
• 2023년 LFE가 운영을 맡고 — Igalia·Huawei·자원봉사자가 기여 — 활성 개발 재개.

2026년 현주소:

• Linux/macOS에서 단순한 페이지·CSS·JS는 렌더링 가능.
• 자체 미니 브라우저 셸이 데모 가능.
• 임베디드 사용 사례에 집중 — 자동차 인포테인먼트, 키오스크, 가전제품 UI 등.
• Tauri의 실험적 백엔드 옵션으로 검토 중.

프로덕션 도달 거리: 데스크톱 일반 사용자용 브라우저로 도달하려면 — 여전히 멀다. 사이트 호환성 작업이 어마어마하다.

2.5 LadyBird — 가장 흥미로운 인디

소유자: LadyBird Browser Initiative (501(c)(3) 비영리, 2024 설립)

자바스크립트 엔진: LibJS (자체)

언어: C++23 (이전엔 SerenityOS의 LibWeb 컴포넌트로 시작)

역사:

• 2019년 Andreas Kling이 SerenityOS 부속 컴포넌트로 시작.
• 2022년 독립 프로젝트로 분기.
• 2024년 LadyBird Browser Initiative 비영리 설립. 초기 자금 GitHub·Shopify 창업자(특히 Chris Wanstrath, Tobi Lütke), 그리고 후속 후원자들로부터 수백만 달러 규모.
• 풀타임 엔지니어 10명 안팎.

2026년 현주소:

• 첫 Alpha 출시 목표: 2026년 7월 — Linux/macOS.
• Web Platform Tests 통과율이 빠르게 상승 중 (2024년 중반 약 80% → 2026년 초 90%+ 일부 영역).
• HTTPS, HTML5, 대부분 CSS, JavaScript ES2022 수준, 일부 Web API. 멀티프로세스 아키텍처 — 탭마다 ProcessIsolation.
• WebGPU·WebRTC·미디어 코덱은 아직 미지원 또는 초기 단계.

철학:

• 독립성 우선 — 광고 수익·VC·검색 거래 받지 않음. 기부와 후원으로만 운영.
• 밑바닥부터 다시 — 기존 엔진 포크 아님. 100% 새 코드.
• 표준 준수 — 사용자 트래킹 없음. 사이트 호환성 우선.

프로덕션 도달 거리: Alpha는 "기술적 가능성 증명". 일반 사용자 일일 사용은 — 낙관적으로 봐도 — 2028년 이후. 그러나 30년 만에 처음으로 새 메이저 엔진이 등장하고 있다는 사실 자체가 의미가 크다.

2.6 Flow — 상용 인디

소유자: Ekioh (영국 케임브리지 소재)

언어: C++, 자체 GPU 가속 라이브러리

용도: 임베디드·키오스크·셋톱박스·차량 인포테인먼트 등 — 일반 소비자 브라우저 아님.

특징:

• 모든 것을 GPU에서 합성 — CPU 부담 최소화.
• 멀티스레드 레이아웃.
• 표준 채택은 선택적 — 클라이언트 요구에 맞춰.

왜 흥미로운가: "독립적으로 메이저 사이트 일부를 렌더링 가능한" 두 번째 인디 엔진이라는 점. LadyBird와 함께 — 인디 엔진이 가능하다는 — 살아 있는 증거.

2.7 Goanna — 보존주의자의 깃발

소유자: Moonchild Productions (Pale Moon 개발사)

기원: 2015년 Gecko에서 분기. XUL 확장 같은 — Firefox가 버린 — 기능을 유지하려는 의도.

용도: Pale Moon, Basilisk 브라우저.

현실: 점유율 0.1% 미만. 표준 채택이 매우 느림. 모던 웹사이트의 상당수가 작동하지 않음. 그러나 — 마지막 진정한 의미의 "사용자 통제"를 추구하는 — 작은 커뮤니티가 유지.

3장 · 기능 커버리지 매트릭스

엔진별 기능 지원을 한눈에 보자. O = 안정 지원, △ = 부분/플래그, X = 미지원, − = 적용 불가.

Web Platform Tests 통과율 (대략, 2026년 1분기 기준 — 발표 수치 참조):

LadyBird의 WPT 통과율이 빠르게 오르고 있다는 점이 — 작은 팀이 6년 만에 만든 엔진치고는 — 인상적이다.

4장 · 어떤 사이트가 어디서 깨지나 — 실전 호환성

표준 표는 깨끗하지만 현실은 그렇지 않다. 실제로 어떤 사이트가 어떤 엔진에서 깨지는가 — 2026년 5월 기준으로 정리하면.

4.1 Safari/WebKit에서 자주 깨지는 패턴

• <input type="date"> 인터랙션 차이 — iOS Safari가 네이티브 피커 강제, 데스크톱 Safari는 비표준 UI.
• 강제 PWA 제약 — Add to Home Screen은 가능하지만 Service Worker 캐시 용량·푸시 알림에서 제약. 2024년 EU 정책 변화 이후에도 흔적 남음.
• IndexedDB 트랜잭션 타이밍 차이 — Safari의 IDB는 다른 엔진보다 더 자주 — 미묘한 — 락 충돌을 보임.
• WebRTC ICE candidate 협상에서 가끔 — 특히 모바일 — 비대칭 NAT에서 더 자주 실패.
• 미디어 코덱 — VP9·AV1 데스크톱은 지원하지만 모바일에서 제한적. H.264·HEVC는 우대.
• File System Access API 부재 — 데스크톱 앱 수준의 파일 워크플로우 불가.

4.2 Firefox/Gecko에서 자주 깨지는 패턴

• 일부 광고/추적 차단이 — 의도적으로 — 사이트 자체를 깨뜨림. 사이트가 트래커 의존이면 빈 화면.
• WebGPU·OffscreenCanvas는 안정화됐지만 — Blink보다 6–12개월 지연 — 그 기간의 사이트가 가끔 깨짐.
• 모바일 Firefox(Android) 점유율이 작아 사이트가 거의 테스트하지 않음. 종종 — Chromium 전용 CSS를 — 그냥 안 처리.
• DRM 콘텐츠는 — Widevine을 별도 모듈로 로드 — 일부 환경에서 비활성.

4.3 Chromium에서도 깨질 수 있다

이건 자주 잊힌다. "Chrome이면 무조건 된다"는 거짓말이다.

• Manifest V3 이후 확장 API 변경으로 일부 확장이 — 특히 컨텐츠 차단·고급 자동화 — 기능 저하.
• Origin Trials로만 활성화된 기능을 코드가 가정하면 — 트라이얼 만료 후 갑자기 — 깨짐.
• ChromeOS·Android WebView·Electron 사이의 미묘한 행동 차이.
• Edge·Brave·Opera 등 파생 브라우저가 — 광고·추적 차단을 — 끼워 넣은 결과 사이트가 깨짐.

4.4 호환성 테스트 매트릭스 (현실판)

작은 팀이 합리적으로 테스트할 수 있는 최소 매트릭스를 정하자면.

Servo·LadyBird는 — 2026년 기준 — 일반 사이트 호환성 테스트 대상이 아니다. 그건 — 엔진 쪽이 사이트에 맞춰야지 — 사이트가 엔진에 맞출 단계가 아니다.

5장 · 정치 — DOJ, DMA, 그리고 Mozilla의 사명 표류

5.1 DOJ vs Google — Chrome 분리가 될까?

2024년 8월, 미국 연방법원이 Google이 검색 시장에서 — 셔먼 법 2조를 위반해 — 독점을 유지했다고 판결했다. 2025년 구제책 단계에서 DOJ는 다음을 권고했다:

1. Chrome 매각 — Google이 Chrome 브라우저 사업을 분리해 매각.
2. 검색 거래 금지 — Apple과 — 매년 200억 달러 — 기본 검색 거래 금지.
3. 데이터 공유 — 검색 인덱스·랭킹 시그널 일부를 경쟁사에 — 일정 조건으로 — 공유.

Google은 항소했고, 2026년 5월 현재 항소법원 단계에서 진행 중이다. 결과는 — 가장 빨라도 2027년 — 나올 가능성이 크다.

만약 Chrome 매각이 강제된다면:

• Chromium 오픈소스 거버넌스가 흔들린다. Google이 운영비를 댔던 부분을 — 새 주인이 — 어떻게 처리할 것인가?
• V8·Blink의 발전 속도가 — 단기적으로는 — 느려질 수밖에.
• Microsoft Edge가 — 이미 Chromium 기반이라 — 영향을 적게 받음. 사실상 — 표준 이전이 Microsoft 쪽으로 — 일부 이동 가능성.
• 다양성에는 — 역설적으로 — 좋은 신호일 수 있다. 단일 주체의 통제가 약해진다.

5.2 EU DMA — iOS WebKit 강제의 종말?

2024년 3월, EU의 Digital Markets Act (DMA)가 발효되면서 Apple은 — EU 한정으로 — iOS에서 비-WebKit 엔진 브라우저를 허용해야 했다.

2026년 현주소:

• Chrome iOS의 Blink 기반 버전이 EU 사용자에게 단계적 배포 중. 그러나 — 광고처럼 — 메인 앱이 아니라 별도 SKU로 배포되고, 사용자의 자발적 선택 필요.
• Firefox iOS의 Gecko 기반 버전은 — 2025년 시범 — 2026년 EU 정식 배포.
• Apple은 — DMA 규정을 — 가능한 한 빡빡하게 해석. WebKit 시작 화면, JIT 컴파일러 제약, 데이터 보안 모델 차이 등으로 비-WebKit 엔진의 초기 사용 경험이 — 의도적으로 — 거칠다는 비판.
• EU 밖(미국·아시아·일본 등)은 변화 없음. 미국 의회의 비슷한 법안은 표류 중.

이건 — 적어도 EU 안에서는 — 엔진 다양성의 작은 승리다. 그러나 실제 사용자 점유율 변화는 — 2026년 현재 — 의미 있는 수치까지 도달하지 못했다.

5.3 Mozilla의 사명 표류 논쟁

Mozilla는 — 비-Google·비-Apple 엔진을 유지하는 — 사실상 유일한 메이저 기관이다. 그러나 2020년대 들어 — 다음 패턴이 — 반복되며 비판이 커지는 중이다.

• 2020년 정리해고 — Servo 팀 포함 대규모 감원.
• 2022년부터 AI·광고·사생활 도구 신사업 강조 — Mozilla.ai 설립, AI 광고 서비스 Anonym 인수.
• 2024년 추가 정리해고 (약 60명) — 표준 위원회 참여 일부 축소.
• 2026년 현재 풀타임 Gecko 엔진 엔지니어 — 2010년대 중반 수백 명에서 — 한 자릿수 후반 / 두 자릿수 초반으로 축소된 것으로 추정.

지지자의 입장: "수입원을 다각화해야 — Google 검색 거래 — 의존을 줄일 수 있다." Mozilla의 수입 80%+는 Google과의 검색 기본 거래에서 나온다. 이 거래가 위 DOJ 판결로 금지될 수 있는 상황에서 — 다각화는 필수.

비판자의 입장: "엔진 투자가 마이너스인데 AI에 투자할 여력이 있는가? 사명이 '인터넷이 모두를 위한 공공자산'인 단체가 광고 회사를 인수하는 게 맞는가?"

이건 — 단순한 옳고 그름이 아니라 — 자원 배분의 어려운 질문이다. 그러나 분명한 건: Gecko 엔진은 — 한 회사 하나에 — 너무 많이 의존하고 있다.

6장 · 왜 다양성이 중요한가 — 단조 경관의 위험

"Chromium이 충분히 잘 한다" — 흔한 반론이다. 표준 채택은 빠르고, 개발자 도구는 좋고, 오픈소스고. 굳이 다른 엔진이 필요한가?

답: 그래도 필요하다. 이유 몇 가지.

6.1 한 회사가 표준을 정의하면 표준이 아니다

W3C·WHATWG 표준 작성에 Blink가 — 사실상 — 거부권을 가진다. Blink가 구현하지 않은 기능은 — 실질적으로 — 표준이 아닌 것과 같다. 반대로 Blink가 시작하면 — 다른 엔진이 — 따라가야 할 압박.

이건 IE 시대의 반복이다. 1990년대 말 IE가 90% 점유율이었을 때 — 마이크로소프트가 — ActiveX·VBScript·HTC 같은 — 사실상 표준이 아닌 — 자체 기술을 표준처럼 밀었다. 결과는 — 웹 전체가 — IE에 묶였고, 다른 브라우저는 — 깨졌다.

지금 Blink가 — 의도적으로 그런다는 게 아니라 — 구조적으로 그 위치에 있다. 그건 — 좋고 나쁨을 떠나 — 위험하다.

6.2 광고·추적 모델 단일화

Manifest V3는 — 합법적 이유가 — 있다. 그러나 결과적으로 광고 차단 확장의 기능을 — 일부 — 저하시켰다. 이건 — Google의 — 주요 수익원이 광고라는 사실과 — 충돌할 수밖에 없다.

Gecko가 — 점유율이 작아도 — 다른 신호를 보낸다. uBlock Origin이 Firefox에서 — Manifest V3가 아닌 — 더 강력한 API로 동작한다. 그게 — 신뢰성 — 면에서는 다양성의 가치다.

6.3 보안 단일 장애점

CVE 하나가 Blink에 있으면 — Chrome·Edge·Brave·Arc·Electron 앱 전부에 영향. 2022년 Chromium의 V8 0-day가 발견됐을 때 — 패치 적용 전 — 사실상 데스크톱의 거의 모든 사용자가 노출.

엔진 다양성은 — 보안 측면에서 — 정확히 — 자연 생태계의 — 종 다양성과 같다. 한 병원체에 모두가 — 동시에 — 쓰러지지 않는다.

6.4 혁신은 경쟁에서

WebKit이 Service Worker를 늦게 받아들였을 때 — Blink와 Gecko가 — 빠르게 구현 — 결국 Apple도 따라옴. Gecko의 WebRender가 — 합성 효율을 — 새로운 수준으로 — Blink가 일부 차용. 경쟁이 없으면 — 누구든 — 정체한다.

7장 · Servo와 LadyBird가 프로덕션까지 가려면

그래서 — 진짜 — 새로운 엔진이 메이저가 될 수 있을까? 두 인디 엔진을 — 정직하게 — 평가하자.

7.1 Servo

남은 일:

• 사이트 호환성 — 실제 웹의 — 99%를 처리하려면 무수한 엣지 케이스. WPT 통과율이 78%에서 95%까지 — 마지막 — 17%가 가장 어렵다.
• DOM·CSS·JS 표면적 풀 커버. 일부 API(WebRTC, WebAuthn, Service Worker 등) 미구현.
• 개발자 도구.
• 확장 시스템 — 또는 의도적으로 — 안 만들기.
• 자금. LFE 산하에 있지만 풀타임 엔지니어 수가 한 자릿수.

기회:

• 임베디드 우선 전략 — 자동차·키오스크·가전이 — 일반 브라우저보다 — 사이트 호환성 요구가 낮다.
• Rust 생태계의 다른 컴포넌트와 결합 — Tauri·다른 임베디드 프레임워크.

현실적 일정: 데스크톱 일반 브라우저 = 5+년. 임베디드 일부 채택 = 2027–2028.

7.2 LadyBird

남은 일:

• Alpha를 출시(2026년 7월 목표). 그 후 사이트 호환성·성능·안정성 — 모두 — 빠르게 — 끌어올려야 한다.
• WebGPU·WebRTC·미디어 코덱 — 인디 팀이 직접 만들기엔 — 어마어마한 — 작업량. 라이브러리 재사용 전략 — Skia·FFmpeg 등 — 검토 중.
• Windows·Android 포팅. iOS는 — 적어도 — 정책상 어려움.
• 자금 지속성. 2024년 시드 자금이 — 몇 년 — 운영을 보장하지만 그 이후?

기회:

• 진정한 의미의 독립. 광고·검색 거래·VC 압력 없음. 오로지 — 사용자 경험 — 기준으로 결정.
• 30년 만의 첫 진정한 새 엔진이라는 — 상징성·홍보 — 효과.
• LadyBird 코드베이스가 — 의도적으로 — 깨끗. 기여 진입 장벽 낮음.

현실적 일정: Alpha = 2026 7월. Beta(일반 사용 가능, 알려진 한계 있음) = 2027–2028. 일반 사용자 일일 사용 = 2028–2030.

7.3 둘 다 — 실패한다 해도

설령 둘 다 — 메이저 — 점유율에 도달하지 못해도 — 의미가 크다. 이유.

• 표준 위원회에 새로운 목소리 — 인디 엔진 한 명이 있다는 사실만으로도 — 논의가 — 더 신중해진다.
• Chromium에 압력 — Chrome이 — 단조 경관의 유일한 — 옵션이 아니라는 — 사회적 인식.
• 다음 세대를 위한 학교 — Servo의 Rust·LadyBird의 C++23로 새 엔지니어가 길러진다.
• 임베디드·특수 환경의 대안 — 차량·키오스크·임베디드는 — 라이선스·제어권 — 면에서 인디 엔진이 매력적.

8장 · 실무자 — 무엇을 해야 하나

이 글을 읽는 당신이 — 웹 개발자라면 — 무엇을 — 다르게 해야 할까?

8.1 다중 엔진 테스트를 — CI에 — 포함

GitHub Actions나 다른 CI에서 — Playwright가 Chromium·WebKit·Firefox를 — 모두 자동 실행한다. 무료다. 핑계가 없다.

# .github/workflows/test.yml (예시 — 코드 블록 안에서만)
name: cross-browser-tests
on: [push, pull_request]
jobs:
  test:
    strategy:
      matrix:
        browser: [chromium, webkit, firefox]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install ${{ matrix.browser }} --with-deps
      - run: npx playwright test --project=${{ matrix.browser }}

8.2 기능 사용은 — Baseline 기준으로

web.dev/baseline 또는 caniuse — 어떤 기능이 — 세 엔진 모두에서 — 안정 채택됐는지 — 확인.

Baseline 2024+에 들어간 기능은 — 안전하게 — 사용. Baseline 미만은 — 폴리필 / 프로그레시브 인핸스먼트 — 또는 사용 보류.

8.3 Origin Trials는 — 차분히

Chromium의 Origin Trials는 — 코드를 — 새 기능에 의존하게 만든다. 트라이얼이 만료되면 — 그 기능을 사용하던 모든 사이트가 — 갑자기 — 깨진다. 가능하면 — 안 쓰거나 — 폴리필을 — 강제.

8.4 사용자 점유율이 작은 엔진도 — 무시하지 말 것

Firefox가 3%라고 — 무시하면 — 일부 사용자가 — 일부 기능 — 사용할 수 없다. 작은 노력으로 — 큰 차이.

8.5 표준 — 우선

벤더 프리픽스 (-webkit-, -moz-) 사용 시 — 표준 버전을 항상 — 함께 쓰기. 사이트가 — 한 엔진에 — 묶이는 — 패턴을 — 피하기.

에필로그 — 30년 만의 분기점

웹 엔진의 역사를 — 압축해 보면 — 분기점은 — 드물게 — 온다. 1994년 Netscape, 2003년 WebKit, 2008년 Chrome, 2013년 Blink — 그리고 2026년 — 어떤 식으로든 — 다음 페이지가 — 열리고 있다.

LadyBird의 Alpha, Servo의 부활, DOJ의 Chrome 매각 권고, EU DMA의 iOS 엔진 강제 해제, Mozilla의 사명 표류 — 어느 하나도 — 즉시 — 결과를 — 만들지는 않는다. 그러나 — 누적되면 — 2030년대의 웹은 — 2020년대와는 — 다르게 — 그려질 수 있다.

체크리스트

• 우리 사이트는 Chrome·Safari·Firefox에서 — 회귀 없이 — 동작하는가?
• Playwright 또는 동등한 도구로 — 세 엔진 — CI 자동 테스트를 — 운영하는가?
• Baseline 미만의 기능은 — 폴리필 또는 — 프로그레시브 인핸스먼트로 — 감싸는가?
• 벤더 프리픽스 옆에 — 표준 — 버전을 — 함께 — 작성하는가?
• Origin Trials에 — 코드가 — 의존하지 않는가?
• 사이트의 — 핵심 기능이 — JS 없이도 — 동작하는가?

안티패턴

• "Chrome에서만 테스트한다" — 다른 엔진에서 — 알게 모르게 — 깨지고 있을 가능성.
• "user-agent로 분기 처리" — 거의 항상 — 미래에 — 깨진다.
• "Service Worker가 있다고 가정" — Safari/iOS의 — 미묘한 — 차이 무시.
• "내 사용자 통계상 Firefox는 작으니 — 무시" — Firefox는 — 호환성 — 카나리.
• "Manifest V3 확장이 — Manifest V2와 동일하다" — 거짓.

다음 글 예고

다음 글에서는 — 이 엔진들을 — 임베드해 데스크톱 앱을 만드는 — Electron·Tauri·WebView 비교를 — 깊이 파고들 예정. Chromium을 통째로 번들할 것인가 (Electron), OS WebView를 빌려 쓸 것인가 (Tauri), 새 길을 갈 것인가 (WebView2 / WKWebView 직접) — 그리고 — 각각의 — 보안·메모리·번들 크기 트레이드오프.

참고 / References

• State of the browser engines (web.dev) — Baseline 기준 기능 추적.
• Web Platform Tests — 엔진별 표준 통과율.
• Chromium — 공식 사이트.
• WebKit — Apple 엔진.
• Mozilla Gecko docs — Gecko 문서.
• Servo — Linux Foundation Europe.
• LadyBird Browser — 인디 엔진.
• Ekioh Flow — 상용 인디.
• Pale Moon (Goanna) — 보존주의 포크.
• DOJ vs Google (2024 ruling summary) — 미국 법무부.
• EU DMA — Apple iOS browser engine — EU Digital Markets Act.
• caniuse.com — 기능별 엔진 지원 표.
• Web Almanac — 매년 발행되는 웹 트렌드 통계.
• Igalia Chats — 외부 컨트리뷰터의 엔진 작업.
• Andreas Kling's blog — LadyBird 개발자 블로그.