Ladybird 브라우저 4월 업데이트: 독립 브라우저 엔진은 어디까지 왔나

또 하나의 브라우저, 진짜 필요할까?

요즘 우리가 쓰는 브라우저 엔진은 사실상 두 개뿐이에요. 구글 Chrome, MS Edge, 네이버 웨일, 삼성 인터넷이 다 쓰는 Blink(크로미움) 와, Firefox가 쓰는 Gecko, 그리고 Safari의 WebKit. 그런데 WebKit도 원래 Apple이 KHTML에서 갈라져 나와 만든 거고, Blink도 WebKit에서 다시 갈라진 거라서, 큰 줄기로 보면 인터넷의 거의 모든 페이지가 사실상 한두 회사의 코드 위에서 렌더링된다고 해도 과언이 아니에요.

이런 상황에서 Ladybird는 "우리 처음부터 다시 만들어 보자"고 나선 프로젝트예요. SerenityOS라는 취미 프로젝트에서 시작했다가, 지금은 별도 비영리 재단으로 독립해서 풀타임으로 개발 중이에요. 4월 뉴스레터를 보면 어디까지 진행됐는지 꽤 구체적으로 나오는데, 이게 단순히 "또 하나의 토이 프로젝트"가 아니라 진짜 의미 있는 진척을 보이고 있어서 한번 짚어볼 만해요.

4월에는 뭐가 달라졌나

뉴스레터에는 한 달간 머지된 수백 개의 패치가 정리돼 있어요. 핵심만 추려보면, 우선 JavaScript 엔진(LibJS) 쪽 진척이 눈에 띄어요. 최신 ECMAScript 사양에 새로 들어간 기능들을 차곡차곡 구현하고 있고, Temporal API처럼 날짜·시간을 새로 다루는 표준도 작업 중이에요. Temporal이 뭐냐면, 자바스크립트의 악명 높은 Date 객체를 대체하려고 만들어지고 있는 새 표준인데, 시간대(timezone)나 일정 처리를 훨씬 깔끔하게 다룰 수 있게 해주는 거예요.

CSS 렌더링도 큰 발전이 있었어요. subgrid 같은 비교적 최신 그리드 기능이 들어갔고, 폰트 처리와 텍스트 셰이핑(여러 언어의 글자를 올바르게 그리는 작업)도 개선됐어요. 한국어처럼 표의문자나 복잡한 조합형 문자가 있는 언어에는 텍스트 셰이핑이 굉장히 중요한 부분이거든요.

그리고 네트워크 스택 쪽에서는 자체 구현한 HTTP 클라이언트와 TLS 처리 코드가 꾸준히 다듬어지고 있어요. 보통 새 브라우저를 만들 때 OpenSSL이나 BoringSSL 같은 기존 라이브러리에 기대는 게 일반적인데, Ladybird는 "의존성을 최소화하자"는 철학이라서 직접 만드는 부분이 많아요. 위험해 보이지만 동시에 학습용으로는 정말 좋은 코드베이스가 되는 거죠.

기술 스택과 아키텍처

Ladybird는 흥미롭게도 최근에 C++에서 Swift로의 점진적 이전을 발표했어요. 메모리 안전성 때문이에요. 브라우저는 인터넷에서 받은 임의의 데이터를 파싱해야 하는 특성상 메모리 안전 버그가 곧 보안 취약점으로 직결되거든요. Chrome이나 Firefox도 비슷한 이유로 Rust 도입을 늘리고 있는데, Ladybird는 Apple이 시스템 프로그래밍용으로 발전시키고 있는 Swift를 선택했다는 게 독특한 지점이에요.

구조적으로는 다중 프로세스 아키텍처를 채택했어요. 탭마다 별도의 프로세스에서 렌더링이 돌아가고, 네트워크 처리, 이미지 디코딩 같은 위험한 작업도 각자 격리된 프로세스에서 돌아가요. 이러면 한 탭의 페이지에서 크래시가 나도 브라우저 전체가 죽지 않고, 악성 페이지가 다른 탭의 데이터를 훔쳐 보기도 어려워지는 거죠. Chrome이 2008년에 도입해서 표준이 된 이 모델을 Ladybird도 처음부터 잘 따르고 있어요.

다른 독립 브라우저 시도들과 비교

비슷한 시도가 아예 없었던 건 아니에요. Servo는 Mozilla가 Rust로 새 엔진을 만들어보려던 프로젝트인데, 한때 중단됐다가 최근에 Linux Foundation 산하로 옮기면서 다시 활발해졌어요. Flow라는 상용 브라우저도 Servo의 일부 기술을 가져다 쓰고 있고요. 다만 Servo는 "엔진 자체"에 가깝고, 일반 사용자가 쓸 만한 완성된 브라우저로는 Ladybird가 더 가까이 가고 있어요. 알파 버전 출시를 2026년 안에 목표로 하고 있다고 하거든요.

한국 개발자에게 주는 시사점

웹 개발하는 분들 입장에서는 "독립 브라우저 엔진이 또 생겨봐야 호환성 테스트만 늘어나는 거 아냐?" 싶을 수 있어요. 맞는 걱정이에요. 하지만 거꾸로 생각하면 표준 준수가 더 엄격해진다는 의미이기도 해요. Chrome에서만 잘 돌아가는 비표준 동작에 의존하던 코드들이 Ladybird에서는 깨질 수 있고, 이게 결과적으로 "진짜 표준에 맞는 코드"를 쓰도록 유도하는 압력이 되거든요.

또 코드베이스가 비교적 깔끔하고 작아서, 브라우저 내부 구조를 공부하기에 정말 좋은 교재예요. "브라우저는 어떻게 HTML을 파싱하지?", "CSS의 cascading은 코드로 어떻게 표현되지?" 같은 궁금증이 있다면 Ladybird 소스를 직접 읽어보는 게 Chrome 소스를 보는 것보다 훨씬 현실적인 선택이에요. Chrome은 너무 거대해서 어디부터 봐야 할지조차 막막하거든요.

마무리

인터넷이 한두 회사 엔진에 의존하는 게 위험하다는 건 다들 알지만, 실제로 새 엔진을 만들어내는 건 또 다른 문제예요. Ladybird는 그 어려운 길을 한 발씩 가고 있어요. 여러분은 브라우저 엔진의 다양성이 정말 중요하다고 생각하시나요, 아니면 표준만 잘 지켜진다면 엔진은 한두 개여도 괜찮다고 보시나요?