스펙과 테스트로 브라우저 엔진을 생성하는 Bez, 해커뉴스 댓글은 회의적

모든 걸 프로그램으로 제어할 수 있는 브라우저가 나왔으면 좋겠다. 크로미움/블링크 기반은 전부 사라졌으면 하는데.

내부를 뜯어보면 결국 또 크로미움/블링크처럼 생겼을 걸.

웹 표준 코퍼스가 어마어마하니까 이론상 스펙에서 브라우저를 생성하는 게 말이 된다. 사람이 스펙 구현에 쓰는 시간을 더 좋은 스펙 작성에 돌리면 생성 품질도 올라가지 않을까. 물론 지금 실무 단계 얘기는 아니고 희망 섞인 얘기임.

아니다. 그 스펙 대부분은 사람이 읽는 기술 언어지 기계 판독 가능한 스펙이 아니다. 게다가 웹 스펙은 이미 사용자 영역에서 굳어진 용어를 수십 년 뒤에 와서 새로 정의하는 일이 많다.

3년째 브라우저 엔진을 풀타임으로 만들고 있는데 지금 20만 개 CSS 테스트 중 절반 정도 통과한다. AI는 옆에서 계속 잡아주지 않으면 이걸 못 한다. 테스트는 통과하는 코드를 주긴 하는데 말도 안 되는 방식이라 너무 느리고, 아키텍처가 틀려서 더 나은 해법으로 수렴하지도 않는다.

브라우저 성능과 보안 개선은 이 복잡도 규모에서 예술이자 공학이다. 이런 게 가능했다면 기존 브라우저에서 먼저 결과가 나왔을 거다. 그래도 이 프로젝트 자체는 흥미롭다.

브라우저가 비표준 코드도 스펙대로 렌더링한 것처럼 받아주는 엣지 케이스가 꽤 있다. 사이트가 깨져 보이면 사용자는 웹 개발자가 아니라 브라우저를 탓하니까.

북마크 툴바랑 메뉴를 어떻게 구성할지, Shift-Ctrl-T로 닫은 탭을 되살린다는 규칙이 웹 표준 어디에 있나.

이거 웹 앱을 네이티브 앱으로 만드는 새 경로가 열리는 것 같다. 웹뷰에서 못 쓰는 네이티브 기능도 붙일 수 있고.

그 용도로 만든 구현이 이미 있다. DioxusLabs/blitz인데 바이브 코딩한 물건 아니고, 지금은 HTML/CSS만 지원하지만 빠른 증분 렌더링을 목표로 설계해서 JavaScript 지원을 얹기는 쉽다.

스펙에서 모호한 부분을 찾으면 꼭 버그로 올려줬으면 좋겠다. 스펙은 관찰 가능한 동작을 정의하는 문서라 UA가 정하는 모호함이 많고, 실제 웹과 호환되려면 결국 크롬이 하는 대로 해야 한다. 대신 3대 엔진 소스와 Ladybird를 AI 에이전트에 비교시켜 최적화를 찾을 수 있다는 건 좋은 점이다.

스펙 버그와 모호성 찾기가 지금 W3C에 가장 가치 있는 일이라고 본다. Flexbox Level 1은 첫 초안이 나온 지 17년이 지났는데도 모호성이 계속 나오고, 아직 Candidate Recommendation(4단계 중 2단계)을 못 벗어났다.

MacOS나 iOS도 같은 방식으로 만들 수 있나? 리눅스 안에서 돌려보고 싶다.

솔직히 그렇게 만든 코드를 사람이 이해할 수 있긴 하냐.