TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 24 READS

명세와 테스트로 브라우저 엔진을 '생성'한다는 실험, Bez

명세와 테스트로 브라우저 엔진을 '생성'한다는 실험, Bez
SOURCE IMAGE · HACKER NEWS

웹 브라우저의 렌더링 엔진은 현대 소프트웨어에서 가장 만들기 어려운 부류에 속한다. 처음부터 손으로 구현하려면 수백 명의 엔지니어와 수년의 시간이 든다. 그래서 자체 엔진을 가진 조직은 손에 꼽을 정도이고, 결과적으로 '웹이 어떻게 동작하는가'를 정의하는 권한도 소수 기업에 집중돼 있다. Bez는 이 구조 자체에 질문을 던지는 프로젝트다. 엔진을 사람이 직접 짜는 대신, 명세(specification)로부터 엔진을 생성하겠다는 발상이다.

핵심 아이디어는 생성과 검증의 분리에 있다. Bez는 CSS·DOM 같은 웹 표준 명세를 입력으로 삼아 구현 후보를 만들고, 이를 세 개의 실제 출시 브라우저와 WPT(Web Platform Tests)로 검증한다. 세 브라우저를 서로 대조해 기대 동작의 기준점을 잡고, 표준 테스트 스위트로 적합성을 확인하는 방식이다. 이렇게 한 번 파이프라인이 완성되면, 추가로 또 다른 엔진을 만드는 비용은 매우 작아진다는 것이 이 프로젝트가 증명하려는 명제다. 엔진을 일회성 산출물이 아니라 재생산 가능한 결과물로 바꾸겠다는 셈이다.

지금까지 생성된 부분과 손으로 짠 부분

현재 상태는 전면 자동화와는 거리가 있고, 그 경계가 비교적 솔직하게 공개돼 있다. DOM, 스타일, 박스 트리(box tree), 프래그먼트 트리(fragment tree)는 crates/dom과 crates/layout에 사람이 직접 작성했으며, 브라우저 대조 검사를 통과한다. 프로젝트 로드맵에서 'Phase 1 — Engine bootstrap'으로 분류된 토대에 해당한다. 즉 엔진의 뼈대는 아직 수작업 영역이고, 생성 실험은 그 위에서 특정 레이아웃 규칙에 집중돼 있다.

생성의 성과가 드러나는 지점은 CSS 2.1 레이아웃 규칙이다. crates/layout/src/generated에는 아홉 개의 레이아웃 규칙이 들어 있는데, 이 중 여덟 개는 모델이 작성했고 '세 브라우저 투표(three-browser vote)'를 통과해 채택됐다. 흥미로운 예외는 블록 높이(block height) 규칙으로, 어떤 모델 후보도 기존 수작업 규칙을 넘어서지 못해 손으로 쓴 버전이 그대로 유지됐다. 모델 생성물이 무조건 채택되는 것이 아니라, 기존 구현과 경쟁해 더 나을 때만 들어온다는 점에서 검증 기준이 실제로 작동하고 있음을 보여준다.

숫자로 본 현재 커버리지

수치는 2026년 9월 25일 기준 browser-compat-data 8.0.4에 대해 계산됐다. 이 데이터셋은 1만 7259개의 리프 키(leaf key)를 담고 있고, docs/feature-map.json에는 74개의 규칙이 정의돼 있다. 생성·수작업 규칙을 합친 레이아웃 구현은 227개 레시피 케이스 전부와, 사용 가능한 11개의 WPT 일반 흐름(normal-flow) 페이지 전부를 통과한다. 다만 리프 키가 1만 7천 개를 넘는다는 사실과 통과한 페이지가 11개라는 사실을 나란히 놓고 보면, 지금 단계가 전체 웹 플랫폼의 극히 일부를 다루는 개념 검증(proof of concept) 성격임이 분명해진다.

실무자 관점에서 이 프로젝트의 의미는 '당장 쓸 수 있는 엔진'이 아니라 '엔진 제작의 경제학을 바꾸는 방법론'에 있다. 엔진이 소수 기업에 독점될 때 생기는 문제는 성능이나 보안만이 아니라, 표준의 해석 권한이 집중된다는 데 있다. 명세와 공개 테스트로부터 엔진을 재생산할 수 있다면, 적어도 이론적으로는 진입 장벽이 낮아지고 표준 준수 여부를 기계적으로 대조할 길이 열린다. 세 브라우저를 교차 검증의 기준으로 삼은 설계 역시, 어느 한 구현의 버그를 정답으로 굳히지 않으려는 방어선으로 읽을 수 있다.

한계도 프로젝트 스스로 '미해결 질문'으로 열어두고 있다. 규칙 하나를 손으로 만드는 실제 비용은 얼마인지, 한 기능에서 생성이 담당해야 할 범위는 어디까지인지, 자바스크립트 없이 도달 가능한 WPT의 비중은 얼마나 되는지, 그리고 IDL 기반 생성 코드가 어디서 끝나야 하는지 등이다. 특히 자바스크립트 의존 영역은 현재 접근법으로는 닿기 어려운 큰 공백으로 남는다. 영역별 상세 상태는 docs/platform-areas.md에, 명제 증명의 조건은 로드맵 문서에 정리돼 있다.

정리하면 Bez는 아직 완성된 브라우저가 아니라, '엔진을 생성할 수 있는가'라는 질문에 한정된 범위에서 '부분적으로는 그렇다'고 답하는 초기 단계의 공개 실험이다. 모델이 쓴 규칙이 세 브라우저 투표를 통과한 사례와, 사람이 쓴 규칙이 끝내 이긴 사례가 공존한다는 점이야말로 이 프로젝트가 과장 없이 자신의 현재 위치를 드러내는 대목이다. 웹 엔진 생태계의 다양성에 관심 있는 개발자라면, 결과물보다 그 검증 파이프라인의 설계를 눈여겨볼 만하다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://tangled.org/burrito.space/bez
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...