Rust로 만든 Servo 웹브라우저 사용 후기

• 전 세계적으로 크로미엄(Chromium) 기반 브라우저의 점유율이 높아지면서, 웹 표준의 다양성과 오픈 웹의 미래에 우려가 커짐
• Rust로 개발된 서보(Servo) 엔진은 멀티스레드 성능과 메모리 안전성이라는 두 가지 강점을 지니며, 웹 렌더링 엔진 분야에서 새로운 대안으로 주목받음
• 아직 초기 단계이기에 대부분의 웹사이트에서 렌더링 버그가 존재하지만, 일부 데모 페이지나 위키피디아 등의 간단한 사이트에서는 정상적인 작동을 보임
• 서보 프로젝트는 과거 Mozilla 주도로 시작되었으나, 현재 Linux Foundation Europe이 관리하며, 기술적 독립성과 커뮤니티 중심의 의사결정 구조를 갖춤
• 브라우저 엔진 단일화 흐름 속에서 Gecko, Servo 등 대안 엔진의 지속적 개발이 웹 생태계 다양성을 지키는 데 중요하다는 시사점이 있음

---

웹 엔진의 과점화와 그 위험성

• 1990년대~2000년대 초에는 Internet Explorer의 Trident, Opera의 Presto, Netscape의 Gecko, Konqueror의 KHTML 등 다양한 웹 브라우저 엔진이 공존함
• 시간이 흐르면서 KHTML은 WebKit, Presto와 Trident(및 Tasman)는 Blink(Chromium 엔진)로 통합 또는 대체됨
• 현대의 주요 브라우저(Chrome, Edge, Opera 등) 가 거의 모두 Chromium/Blink 기반이 되면서, 구현체가 곧 표준이 되어가는 현상 발생
• 보안 취약점, 확장성 제한 등 한 엔진에 의존할 때 전체 웹 생태계가 함께 영향을 받는 문제점이 부각됨

Servo 엔진의 등장

• Servo는 Rust로 처음부터 새롭게 개발된 브라우저 렌더링 엔진임
• Rust의 장점인 멀티스레드 처리와 메모리 안전성을 바탕으로, 기존 C/C++ 기반 엔진이 가지는 취약점(예: 메모리 버그)을 구조적으로 줄이려는 시도임
• Servo의 주요 목표는 임베드형 웹 렌더링 엔진으로, 독립형 브라우저 외에도 Electron이나 Android WebView의 대체재로 활용될 수 있음
• Linux Foundation Europe 산하에서 기술적 의사결정이 대기업이 아닌 기술위원회 중심으로 운영됨
• 10여 년 만에 처음 등장한 완전히 새로운 웹 브라우저 엔진으로, 완성도 향상을 위해 기존 주류 엔진의 경험을 반영하고 있음

서보(Servo)의 사용 경험 및 현황

• 공식 사이트에 공개된 나이틀리 빌드(Windows, macOS, Android, Linux용)로 Servo를 체험할 수 있음
• 북마크, 확장 기능, 데이터 동기화 등 기본 브라우저 기능 미지원 상태임
• 대부분의 웹사이트에서 렌더링 버그가 나타나고, Google 검색이나 일부 사이트는 레이아웃이 깨지거나 크래시 발생
• Wikipedia, CNN Lite 등 단순 구조의 페이지는 정상적으로 작동함
• Servo 데모 페이지에서 그래픽 성능 시연이 가능하며, Particle Physics 등 벤치마크에서 최신 MacBook Pro(x86 에뮬레이션) 기준 55~60FPS의 결과를 확인하였음
• Acid3 테스트에서는 83/100점으로, 주류 브라우저(95점 수준)보다 낮은 점수임
• 향후 Shadow DOM, CSS Grid 등 주요 웹 표준 지원을 로드맵에 포함, 웹 호환성 개선에 중점 두고 있음

Servo의 역사와 주요 전환점

• Servo는 2012년 Mozilla에서 시작, 2013년에는 Samsung이 개발에 합류함
• 원래 목표는 안정화 이후 Gecko 엔진의 대체까지 고려하였으나, 현실적으로 Gecko의 각 부분을 Servo 코드로 점진적으로 대체하는 전략으로 선회함
• Firefox 57(Quantum) 업데이트를 통해 CSS 엔진(Quantum CSS, Stylo)을 Servo 코드로 대체, 성능과 메모리 효율에서 두드러진 개선 효과 확인
• 2020년 Mozilla의 대규모 구조조정(Servo 개발자 포함), 이후 Servo는 Linux Foundation 산하로 이관 및 자금 지원 재확보, Igalia 등 오픈소스 기업의 후원 하에 현재 커뮤니티 중심 개발 지속 중

브라우저 생태계의 미래 가능성

• 미국 법무부가 Google의 독점적 지위(Chrome, Android) 에 대한 소송에서 승리함에 따라, Chrome 매각 및 타사 브라우저와의 검색 계약 금지 조치 논의 중
• Mozilla는 Firefox의 기본 검색 배치 수익 의존도 높음(Gecko 개발 유지에 필수적)으로, 이러한 조치에 반대 의견 표명
• 만약 Mozilla가 Google 수익을 상실하게 되면, Firefox가 개발 비용 절감을 위해 WebKit이나 Chromium/Blink로 전환할 가능성 존재
• 그럴 경우 Gecko 코드의 포크 및 커뮤니티 운영 가능성, 혹은 Gecko의 점진적 쇠퇴 가능성 등 다양한 시나리오가 예상됨
• Servo와 Gecko 등 대체 엔진의 존립이 웹 플랫폼의 다양성과 균형 유지에 중요 요소로 다시 부상함

마무리 및 시사점

• 주류 브라우저 엔진의 통일 현상 속에서도 Servo와 같은 혁신적 대체재의 등장이 웹 생태계의 다양성과 건강성을 지키는 데 중요한 역할임
• 단기간 내 실사용 브라우저로 완성되기는 어렵지만, 기술적 실험과 발전이 지속적으로 이루어지고 있음
• 서보의 향후 발전 방향과 업계 내 파급 효과에 대해 많은 기대감 형성

[iolothebard]

Hurd 프로젝트가 자꾸 떠오르는 건… 저만의 착각이겠죠?

[3ae3ae]

rust가 servo 개발하기 위해 만든 언어라고 들었는데.. servo 잘 됐으면 좋겠네요

[GN⁺]

Hacker News 의견

• 현재 로드맵에 Shadow DOM과 CSS Grid가 우선순위로 잡혀 있음, 나는 CSS Grid 지원 작업을 하고 있고, 곧 "named grid lines and areas" 지원이 추가될 예정임, 이것으로 더 많은 웹사이트 레이아웃이 제대로 동작할 거라 기대함, 내 프로젝트라서 편파적일 수도 있지만, Servo가 CSS Grid를 구현하는 방식이 꽤 멋있다고 생각함, 핵심 구현이 외부 라이브러리(Taffy, GitHub 링크)로 분리되어 있고, 이 라이브러리는 Rust UI 생태계에서 폭넓게 사용되고 있음, 예시로 Blitz(링크) 웹 엔진, Zed(링크) 텍스트 에디터, 그리고 Bevy(링크) 게임 엔진에서 Flexbox, Block layout 등 다양한 역할로 쓰임, Servo가 Stylo, html5ever 등의 모듈형 라이브러리 개발 경험을 바탕으로, 독립적 모듈과 공개 API로 웹 엔진을 쪼개는 방식을 취하고 있는 점이 앞으로 웹 엔진 개발자 진입 장벽을 낮게 해주고, 신규 웹엔진 개발자에게 큰 도움이 될 거라 희망함

  • Blitz에 대해 처음 들어봄, 상당히 흥미롭고 야심찬 프로젝트로 보임, 마치 진짜 '숨은' 웹 엔진 같은 느낌을 받음, Servo는 Rust가 처음 나왔을 때부터 널리 알려졌지만, Blitz는 그에 못지않게 인상적임

  • 웹 브라우저 엔진 기능을 직접 구현한 경험이 HTML이나 CSS 작성 방식에 영향을 주는지 궁금함, 여전히 한 주에 세 번씩 "css grid cheatsheet"를 검색하는지도 묻고 싶음

  • 기능을 쪼개서 모듈화하는 접근이 오히려 기능 과잉이나 단편화로 이어지지 않을까 걱정됨, 구글에 맞서려면 집중력 있는 전략이 중요한데 이 부분이 염려됨

  • taffy를 활용해서 내 작은 Rust 기반 이잉크 달력에서 레이아웃 잡고 있음, 이런 소식이 매우 재미있게 들림

  • 웹 엔진을 독립적으로 사용 가능한 공개 API 모듈로 나누는 방식을 정말 좋아함, 예전에 WebRTC를 살펴보면서 왜 허접한 Skype 짝퉁을 만드는 게 50줄짜리 JavaScript 또는 일주일짜리 크로미엄 C++ 빌드 악몽 둘 중 하나여야 할까 생각했었음, 이제 WebRTC Rust crate도 생겼으니 웹 앱만 이런 투자의 수혜를 보는 건 아니어서 다행임

• Mozilla가 Xerox처럼 "미래 기술을 만들었다가 무심코 경쟁자에게 빼앗긴 기업" 명예의 전당에 들어갈 것 같은 느낌임, Rust와 Servo로 브라우저 개발에서 한때 구글을 앞질렀지만, 결국 계속 추진하지 않은 것이 정말 이해가 되지 않음

  • Mozilla는 Xerox와 다름, 만약 누군가가 새로운 Xerox라면 오히려 Google임, 구글은 엄청난 자금으로 사업 계획 없는 연구개발 부문에 투자하고 있음, 대표적 예로 트랜스포머 모델—사실상 LLM을 구글이 먼저 만들었음에도 OpenAI에게 결국 뒤처짐, Mozilla의 성공은 언제나 넷스케이프, Firefox 등 웹 브라우저에 집중되어 있었음, Rust 역시 본질적으로 브라우저를 위해 만들어진 언어임, 그게 다른 데서 유용하게 쓰이는 건 좋은 부수적 효과일 뿐임

  • 구글이 2006년부터 Mozilla의 주요 수입원이었음, Mozilla가 존속하려면 구글을 만족시키면 됨, 이는 충돌의 소지가 있지만 Mozilla 입장에서는 꽤 괜찮은 거래임

  • Mozilla는 이제 끝이라 생각함, 구글에 너무 의존했고 그것마저 잃을 상황임, Servo와 Ladybird가 앞으로의 미래가 될 것이고, Ladybird가 소수 인원으로 빠르게 발전하는 모습이 정말 인상적임

  • 만약 Mozilla가 Gecko를 포기한다면, 그때는 하드 포크와 Mozilla에서의 탈출을 감행해야 할 시점임, 참고로 말하는 Gecko 포기는 Servo가 아니라 Chromium으로 전환하는 걸 뜻함

  • 사람들이 브라우저에 비용을 내는 일은 어렵다는 느낌임, 10유로 맥주에는 돈을 잘 쓰지만, WhatsApp 평생 0.99 유로 라이선스를 피해가려는 사람들이 내 주변에 많았음

• Mozilla가 Firefox 기술적 미래를 포기한 게 여전히 이해가 안 됨, 그런데 Mozilla를 바라볼 때 결국 자금 흐름을 보면 여러 가지가 이해됨

  • Pocket 서비스 종료도 슬픈 사례임, 만우절 농담으로 Mozilla가 Firefox를 단종하고 핵심 사업에 집중하겠다고 발표하면 어떨까 상상해봄, 인기 많은 제품을 아름답게 단종시키는 '플라토닉 아이디어'가 진짜 핵심 사업인 것 같다는 씁쓸한 농담임

  • 여러 이탈과 커뮤니케이션 방식을 봤을 때, Mozilla는 당시 극도로 정치적인 회사였던 것 같음, Servo는 워낙 소통이 활발했고 Rust도 분위기가 좋았으니, 오히려 그것 때문에 위쪽에서 신경이 쓰였을지도 모른다고 생각함, Mozilla는 여전히 구 인사들이 중심적으로 운영하고 있고, 최고경영진 실수 탓이 크다고 여겨짐

  • 아직도 Servo가 크롬/크로미움 독점에 실질적 대항마가 될 수 있다고 강하게 믿음, Mozilla가 왜 이걸 포기했는지, Linux Foundation이 왜 지원을 거의 하지 않는지 잘 모르겠음

  • Mozilla의 전략을 장기적으로 Google 자금의 독립이라는 관점에서 보면 논리가 있음, 실제 비 Google 수입이 2022년 8천만 달러에서 2023년 1.5억 달러로 증가했음, 총 자산도 매년 1억 달러씩 늘어나서 2023년에는 10억 달러에 이름, Google 자금의 비중은 2020년 90%에서 2023년 75%로 낮아지는 등, 완벽히 독립적이진 않지만 방향성이 있음, 사람들이 흔히 말하는 것과 달리 자금흐름만 보면 결론이 다를 수 있음, 사람들이 Servo를 이어갔어야 한다고 비판하지만, 사실 Quantum 이후 Firefox에 Servo가 큰 역할을 한 건 아니라고 생각함

  • Mozilla 수입 대부분이 Firefox에서 온다는 게 맞는지 질문함

• Blink 독점에 도전할 Ladybird(공식 홈페이지)도 있음, 앞으로 어떻게 될지 확실하진 않지만 기대 중임

  • Ladybird의 목적을 잘 모르겠음, 전임 엔지니어도 있고 기부금도 모으는 등 단순한 취미 프로젝트가 아님은 분명함, 그런데 기능, 보안, 성능 면에서 Blink, Webkit, Gecko와 경쟁이 가능할지 상상이 잘 안 됨, 원체 대규모 팀들이 아니라서 대중적 채택이 없으면 엔진만 만드는 게 큰 효과가 없다고 생각함, 이런 부분은 Servo에도 해당되지만 Servo는 기술적 목표가 좀 더 설득력이 있음, Ladybird에는 그런 명확한 정보가 잘 안 보임

  • 기술적으로만 보면 Ladybird의 매력을 잘 모르겠음, 기본적으로 C++로 짜여 있어서 Gecko, Blink와 차별성이 없어 보임, Servo는 보안, 병렬성 등 명확한 기술적 설계 차별점이 있어서 매력이 있음

  • Ladybird가 성공하길 바라고 있음, 이제 직접 후원도 가능해져서 의미 있다고 생각함, Mozilla와 달리 모인 기부금은 전적으로 브라우저 개발에 쓰일 것이라 확신함

  • Ladybird가 Swift로 전환 시도 중인지 궁금함, C++로 브라우저 엔진을 개발한다면 별로 마음에 들진 않지만 현실적이고 결과물에 집중한 느낌임, Rust라면 미래지향적인 느낌이라 그 점을 인정하겠음, 하지만 Swift 등 다른 언어로 엔진을 만드는 건 회사 내부 정치적인 결정 같아 보임, 지원 생태계가 아직 부족한 언어를 굳이 선택하는 점에 의문이 듦 (참고 트윗)

• Dogemania 테스트가 M4 Pro MacBook Pro에서 400장 이미지까지는 부드럽게 60 FPS로 동작함, 그런데 Chrome에서는 1400장까지 60 FPS가 유지되었고, 그 이상은 진행이 귀찮아 닫아버림

  • 나도 같은 실험을 해봤는데, Firefox와 Chromium의 차이가 실망스럽게 큼, Chromium에서는 1000장 넘어서도 100 FPS가 계속 나왔는데, Firefox로는 500장 넘어서 바로 60 FPS 아래로 떨어짐, 완전히 공정한 테스트는 아니었겠지만(Chromium엔 애드온도 없고 잘 안 쓰는 브라우저) 비교 성능을 확인하는 데 많은 걸 느꼈음

  • dogemania에서 이미지가 애니메이션 이후 가만히 있다면, 정말 쉽게 최적화할 수 있는 사례 아닌가 궁금함, Amiga 같은 예전 컴퓨터도 무한정 이 정도를 처리할 수 있을 것 같은 생각이 듦

• Servo를 '새로운' 엔진이라고 부르는 건 좀 억지임

  • 그래도 나머지 엔진보다 늦게 시작했고, 아직도 경쟁 엔진에 없는 좋은 아이디어가 많아 보임

• 나는 Rust가 웹 브라우저 Servo를 위해 만들어졌다고 알고 있었음

• “표준의 유일한 구현체가 하나만 남으면 그게 곧 표준이 되는 위험이 있다”는 의견에 대해, 그게 왜 문제인지 잘 모르겠음, 구현체가 오픈소스고 여러 주체가 관리하는 위원회에서 사양을 정한다면 괜찮다고 여김, 지금처럼 리소스를 쏟아부어 여러 엔진 만드는 상황이 오히려 낭비임, 브라우저 엔진도 리눅스 커널처럼 하나만 두고 배포판만 다양한 방식이 효율적이라고 생각함

  • 아무리 의도가 좋아도 구현에는 버그와 사소한 결함이 남음, 두 번째 독립 구현체가 없으면 결국 “모두 된다”면서 버그 자체가 표준이 되어버림, 웹 페이지가 이런 버그에 의존하면 결국엔 사양이 아니라 특정 구현의 세부 결함에 따라 움직이게 됨, MS Windows에 구버전 UI가 여러 레이어로 쌓이고 호환성 유지가 악몽이 된 이유가 이것임, 여러 독립적 구현이 있으면 표준이 실제로 유지/진화 가능하고 최적화도 쉬워짐

  • 이론적으로는 괜찮지만, 실제로는 단일 개발자가 유저와 이익이 항상 일치하지 않아서 독점이 바람직하지 않다고 생각함, 특히 최근 Blink 기반의 manifest v2 폐기도 유저들이 싫어했음

  • 브라우저 엔진이 많을수록 보안 취약점이 하나에 몰아치는 위험이 줄어듦, 메모리 안전 언어라도 논리적 실수는 피해를 줄 수 있으니 다양성이 중요함

  • “하나의 엔진에 여러 배포판” 전략을 얘기하셨는데, BSD 환경이나 ZFS 등에 익숙한 사람에게는 오히려 예전 방식을 벗어나 봤을 때 안정감과 완성도가 확연히 느껴짐

  • 이미 구글이나 그쪽 인맥의 의견이 표준화에 크게 반영되고 있음, 모든 것이 Chromium에 의해 굴러가면 상황이 더 악화될 것, 어쩌면 정말 파국이 와야 W3C, WHATWG 같은 곳의 한계를 다들 인정할 것임

• “대부분 웹사이트가 약간의 렌더링 버그를 가지고 있고 일부는 완전히 작동하지 않는다, 구글 검색결과엔 겹치는 요소가 많고 MacRumors 홈은 스크롤 후 크래시가 난다, 그러나 Wikipedia, CNN Lite, 개인 사이트, NPR 텍스트 등은 완벽하게 동작” — 이런 관찰을 봤을 때, 구글이나 MacRumors 쪽을 Servo에 맞게 고쳐야 한다고 말하는 사례를 거의 본 적 없음, 대신 Servo가 크롬/크로미움처럼 동작해야 한다는 결론만 나오곤 해서 아쉬움이 큼, 그렇게 되면 (a) 결국 광고기업이 표준을 정하게 되고, (b) 웹페이지 만든 사람들이 잘못된 동기를 가지게 됨, 위키백과나 CNN Lite 처럼 쉬운 쪽으로 맞추는 게 오히려 간편함, 나는 '표준' 브라우저가 인기순이 아니라 진짜 표준에 가까운 걸 지향해야 한다고 생각함, unpopular 브라우저와 popular 브라우저 모두에서 돌아가게 하는 게 진짜 표준임, 결국 답은 웹 브라우저가 아니라 웹 페이지를 고치는 데 있다고 주장함, 나는 아직도 w3c의 원조 libwww 라이브러리와 도구로 실험하고 있음, 약간만 수정하면 지금도 텍스트 기반 웹 페이지 최적화 용도로 30년 넘게 잘 동작함, 인터넷은 공공재인데 오늘날 브라우저와 페이지는 광고 최적화, 개인정보 수집 쪽으로 너무 치우쳐서 아쉬움, 진정으로 www 유저를 위한 페이지/브라우저가 우선이어야 의미 있다고 생각함, 아래는 libwww로 정적 바이너리 빌드하는 간단 스크립트임

  • (이전 Python 스크립트에 역슬래시 누락된 걸 바로잡음, libww도 libwww로 오타 정정함)

• Mozilla가 경쟁적인 브라우저 회사에서 점점 활동가 느낌의 조직으로 변해가는 모습이 정말 안타까움, 그래서 핵심 제품이 점점 약해진 것 같아 씁쓸함