명세와 테스트로 브라우저 엔진을 생성하는 Bez

AI 요약

브라우저 엔진을 처음부터 직접 만들려면 수백 명의 엔지니어와 여러 해가 필요합니다. Bez는 웹 명세에서 후보 코드를 만들고 Chromium, Firefox, WebKit의 결과와 대조해 엔진을 생성하려는 프로젝트입니다. 통과한 코드는 일반 Rust 코드로 저장합니다. 목표는 브라우저 전체를 구현하는 데 그치지 않습니다. 특정 사이트나 앱이 쓰는 기능만 분석해 바이너리에서 나머지를 제외하는 콘텐츠 범위 엔진도 설계하고 있습니다.

생성과 검증 방식

생성 절차는 명세 문장을 입력으로 받아 모델이 여러 구현 후보를 만들고, 후보를 엔진에서 실행한 뒤 세 브라우저의 출력과 비교하는 순서입니다. 결과가 다르면 후보를 다시 만들고, 일치하면 코드로 채택합니다. 레이아웃 검증은 브라우저별로 상자와 위치가 같은지 확인합니다. 프로젝트는 명세 변경이나 테스트 변경이 생겼을 때 관련 코드를 손으로 다시 쓰는 대신 재생성하고 재검증하는 것을 지향합니다.

현재 구현 범위

2026년 9월 25일 기준, browser-compat-data 8.0.4의 기능 항목 17,259개를 기준으로 전체 기능 중 생성된 비율은 0.6%입니다. 직접 작성한 기능은 0.3%, 연결된 기능은 0.5%이며, 테스트 기준만 마련된 항목은 5.7%입니다. 아직 손대지 않은 항목은 93.0%입니다. CSS만 보면 생성된 기능이 2.5%, 직접 작성한 기능이 1.1%입니다. HTML, JavaScript, SVG, WebAssembly, HTTP, MathML은 아직 생성된 항목이 없습니다.

DOM, 스타일, 상자 트리와 조각 트리는 crates/dom과 crates/layout에 직접 작성했고 브라우저 결과와 대조하는 검사를 통과했습니다. CSS 2.1 레이아웃 규칙 9개를 생성 코드에 넣었습니다. 그중 8개는 모델이 작성한 후보가 세 브라우저의 투표를 통과했습니다. 블록 높이 규칙은 모델 후보가 기존 수기 구현보다 나아지지 않아 직접 작성한 구현을 유지합니다. 이 규칙들은 레시피 테스트 227개와 사용할 수 있는 WPT 일반 흐름 페이지 11개를 통과했습니다.

브라우저 비교와 테스트 오라클

프로젝트는 문서 235개에서 브라우저 쌍별 결과 705건을 비교했습니다. 699건은 일치했고, 불일치 6건은 모두 12단계로 중첩된 백분율 계산에서 발생했습니다. 매번 다수 의견은 Firefox를 예외로 지목했습니다. 이 차이는 Gecko가 길이를 1/60픽셀 단위로 반올림하고 Blink와 WebKit은 1/64픽셀 단위를 쓰는 데서 비롯됩니다. 그 결과 Firefox에서만 flex 항목이 줄바꿈되거나 offsetWidth가 1픽셀 달라지는 사례가 나왔습니다. Slack, Google Store, Samsung에서 재현한 문제는 Mozilla가 진단한 호환성 버그와도 맞아떨어졌습니다.

WPT 전체에서는 세 엔진 중 둘 이상이 동의한 테스트·하위 테스트 키가 2,282,301개 중 2,162,676개로 94.8%입니다. 테스트 종류에 따라 쓸 수 있는 오라클의 비율은 다릅니다. Canvas는 82.6%이며 잠정 테스트를 빼면 92.7%입니다. Khronos WebGL과 dEQP는 99.7%, Web Audio는 74.4%이며 잠정 테스트 제외 시 85.6%입니다. WebGPU CTS는 검증 테스트의 약 85%, 수치 실행 테스트의 약 50%를 오라클로 쓸 수 있습니다. 프로젝트는 엔진에 필요한 호환성 항목 가운데 약 55~60%는 자동 오라클과 생성 가능한 명세 설명을 갖췄고, 약 8~18%는 둘 다 없다고 추산합니다.

댓글 반응

• @fouc — 모든 면을 프로그래밍으로 제어할 수 있는 완전한 브라우저가 나오는 날을 기다립니다. 잘되면 Chromium/Blink 기반 브라우저는 도도새처럼 사라지겠지요.
  • @Tade0 — 내부 구조는 여전히 Chromium/Blink처럼 생길까 걱정됩니다.
• @nicoburns — 브라우저 엔진을 처음부터 구현하는 일을 3년째 전업으로 하고 있습니다. CSS 스타일·레이아웃·렌더링 테스트 약 20만 개 중 절반가량을 통과하는 구현을 만들었는데, 세심하게 방향을 잡아주지 않으면 AI는 아직 이 일을 해내기 어렵습니다. 테스트는 통과해도 방식이 터무니없고 너무 느리며, 아키텍처도 잘못 잡아 나중에 개선하기 어렵습니다.
• @warkdarrior — 속도는 웹 표준 명세의 요구사항이 아닐 수 있습니다. 소프트웨어 아키텍처도 마찬가지입니다. 다만 웹 보안 명세는 여기에 영향을 줄 수 있습니다.
  • @nsagent — 이건 현재 모델의 한계이며 최적화하기도 어렵습니다. 구체적인 최적화 목표가 없는 항목은 사실상 제약이 없어서 모델이 우연히 학습하지 않는 한 맞추기 어렵습니다. Meta의 RL-XAR 같은 기법은 검증하기 어려운 소프트웨어 아키텍처 지표도 강화학습 보상 모델로 최적화하려는 시도입니다.
• @hnlmorg — 브라우저에는 표준을 따르지 않는 코드도 표준에 맞는 것처럼 렌더링하는 예외가 꽤 있습니다. 사이트가 사용자 눈에 제대로 표시되지 않으면 웹 개발자가 아니라 브라우저를 탓하기 때문입니다.
  • @nicoburns — 그런 일은 있지만 요즘은 해당 동작을 명세와 테스트에 추가하는 편입니다. 브라우저 공급자들은 실제 구현이 불가능한 내용을 명세하는 데 지쳐 WHATWG가 W3C의 표준화 과정을 사실상 넘겨받기도 했습니다.
• @kazinator — 북마크 도구 모음과 메뉴를 어떻게 구성할지, Shift-Ctrl-T로 닫은 탭을 복원할지 같은 사양은 웹 표준 어디에 있나요?
  • @looperhacks — 브라우저 엔진 이야기입니다. 브라우저 껍데기는 여기서 중요하지 않습니다.
  • @fabrice_d — 보안 인프라의 일부는 단순한 일이 아니며 표준에도 없습니다. 다중 프로세스 구조와 샌드박싱이 엔진 설계에 미치는 영향을 생각해 보세요.
• @mircerlancerous — 웹 앱을 네이티브 앱으로 만들면서 웹뷰에 없는 네이티브 기능도 더할 수 있는 흥미로운 아이디어입니다.
  • @nicoburns — 저는 앱용 브라우저 엔진인 Dioxus Blitz를 구현하고 있습니다. 현재는 HTML/CSS만 지원하며, 빠른 증분 렌더링을 목표로 설계했습니다. GPU 렌더링을 쓰면 바이너리 크기는 약 8MB부터 시작하고, SQLite와 HTTP 캐시 라이브러리 등을 포함한 브라우저 앱은 20MB입니다. 기본 메모리 사용량은 약 100MB이며 그래픽 스택이 대부분을 차지합니다. 사용하다 보면 300~400MB까지 늘어나는 문제도 아직 조사 중입니다.
• @esprehn — 아이디어는 좋지만 아직 갈 길이 멉니다. 명세의 모호한 부분을 발견하면 W3C에 버그로 보고하면 좋겠습니다. 명세는 관찰 가능한 동작을 정의하며, 브라우저에 맡긴 동작도 많습니다. 실제 웹 호환성을 얻으려면 Chrome이 하는 방식과 맞춰야 하는 경우도 있습니다.
  • @cyberrock — 명세의 버그와 모호성을 찾는 일은 지금 W3C가 할 수 있는 가장 가치 있는 일일 수 있습니다. Flexbox Level 1은 첫 초안이 나온 지 17년이 지났는데도 여전히 모호한 부분이 있고, 후보 권고 단계에서 벗어나지 못했습니다.

원문: Bez / 번역·요약: Trawling