크롬도 파이어폭스도 아닌, 밑바닥부터 만드는 브라우저 '레이디버드'가 개발 방식을 바꾼다

우리가 쓰는 브라우저 엔진은 사실 딱 세 개뿐이에요

혹시 이런 생각 해보신 적 있나요? "브라우저 종류는 엄청 많은데, 속은 다 거기서 거기 아닐까?" 놀랍게도 맞는 얘기예요. 크롬, 엣지, 브레이브, 오페라는 전부 구글이 만든 블링크(Blink) 엔진을 쓰고요, 사파리는 애플의 웹킷(WebKit), 파이어폭스만 모질라의 게코(Gecko)를 써요. 사실상 웹을 그려내는 핵심 두뇌는 이 세 개가 거의 전부거든요.

그래서 누군가 "우리는 기존 엔진을 안 가져다 쓰고, 진짜 처음부터(from scratch) 새 브라우저 엔진을 만들겠다"고 하면 그건 거의 무모한 도전에 가까워요. 그런데 그걸 실제로 하고 있는 프로젝트가 바로 레이디버드(Ladybird)예요. 세르세니티OS(SerenityOS)라는 취미 운영체제를 만들던 안드레아스 클링(Andreas Kling)이 시작했고, 지금은 비영리 재단 형태로 후원을 받아 풀타임 개발자들이 매달리고 있는 독립 브라우저랍니다.

무엇이 바뀌는 걸까

이번 글의 핵심은 "레이디버드를 만들어가는 방식 자체를 손본다"는 거예요. 처음에 이 프로젝트는 전 세계 자원봉사 기여자들이 짬짬이 코드를 보내는 오픈소스 커뮤니티 모델로 굴러갔어요. 그런데 브라우저라는 게 워낙 거대하고 복잡한 물건이라, 자원봉사 방식만으로는 품질과 일관성을 유지하기가 점점 버거워진 거죠. 그래서 후원금으로 채용한 핵심 개발자들이 방향을 잡고, 기여 절차와 코드 리뷰 기준을 더 체계적으로 다듬는 쪽으로 무게 중심을 옮기고 있어요.

기술적으로 가장 흥미로운 부분은 언어 선택이에요. 레이디버드는 원래 C++로 작성됐는데, C++는 빠르지만 메모리 관리를 사람이 직접 해야 해서 보안 취약점의 단골 원인이 되거든요(이게 뭐냐면, 쓰면 안 되는 메모리 주소를 실수로 건드려서 해킹의 통로가 되는 문제예요). 그래서 새로 작성하는 코드는 메모리 안전성이 보장되는 스위프트(Swift) 같은 현대 언어로 점진적으로 옮겨가는 방향을 검토해 왔어요. 한 번에 다 갈아엎는 게 아니라, 새 코드부터 천천히 바꿔나가는 현실적인 전략이죠.

업계 흐름에서 보면

사실 "브라우저 엔진 독점" 문제는 오래된 걱정거리예요. 웹 표준을 사실상 구글이 정하게 되는 셈이니까요. 이런 상황에서 완전히 독립적인 네 번째 엔진이 등장한다는 건 그 자체로 의미가 커요. 비슷하게 러스트(Rust)로 브라우저 엔진을 실험했던 모질라의 서보(Servo) 프로젝트도 있었지만, 우여곡절을 겪었죠. 레이디버드는 "실제로 일반 사용자가 쓸 수 있는 정식 브라우저"를 목표로 잡고 1.0 출시를 향해 가고 있다는 점에서 결이 조금 달라요.

한국 개발자에게

당장 실무에 레이디버드를 도입할 일은 거의 없을 거예요. 하지만 이 프로젝트가 주는 교훈은 분명해요. 첫째, 거대한 레거시 코드베이스를 메모리 안전 언어로 점진 이전하는 전략은 우리 회사 코드에도 그대로 적용할 수 있는 실전 패턴이에요. 둘째, 오픈소스 프로젝트가 자원봉사 모델에서 지속 가능한 후원/조직 모델로 진화하는 과정은, 사이드 프로젝트를 키우려는 분들에게 좋은 참고서가 되고요. 무엇보다 "이미 다 있는데 굳이?" 싶은 영역에 정면으로 도전하는 모습 자체가 자극이 되지 않나요?

마무리

웹의 미래를 한 회사가 좌우하지 않으려면, 누군가는 이런 무모해 보이는 도전을 해야 하는지도 몰라요. 여러분은 어떻게 생각하세요? 독립 브라우저 엔진은 정말 살아남을 수 있을까요, 아니면 결국 거대 기업의 자본력 앞에서 또 한 번 무릎 꿇게 될까요?