Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 파편화 감수와 엔진 동봉 사이
2025년 3월 — Tauri가 Verso를 실험하다
2026년 7월의 Verso — 공식적으로 멈춤
같은 기간 Servo 본체 — 월간 릴리스 트레인과 crates.io
LTS 0.1.x — 약속의 내용과, 약속이 아닌 것
그래서 파편화 문제는 풀렸나 — 아니요, 셈법이 바뀌었을 뿐
지금 무엇을 고르나 — 판단 기준
마치며
참고 자료

들어가며 — 파편화 감수와 엔진 동봉 사이

웹 기술로 데스크톱 앱을 만들 때의 셈법은 오래전부터 둘 중 하나였습니다. Electron처럼 Chromium을 앱에 통째로 동봉하면 모든 OS에서 같은 엔진이 돌아 렌더링이 일관되지만, 앱마다 브라우저 하나씩을 배포하는 크기·메모리 비용을 냅니다. 반대로 Tauri는 wry를 통해 OS에 이미 깔린 웹뷰를 빌려 씁니다 — wry 문서 기준으로 Linux는 WebKitGTK(GTK 필요), Windows는 Edge Chromium 기반 WebView2, macOS는 WKWebView입니다. 바이너리는 작아지지만, 같은 프론트엔드 코드가 세 개의 서로 다른 엔진 위에서 돌게 됩니다.

이 "세 개의 엔진"이 실무에서 웹뷰 파편화라고 부르는 문제입니다. CSS·JS 기능 지원 시점이 엔진마다 다르고, 업데이트 주기도 OS에 묶여 제각각이라, 결국 세 엔진 모두에서 테스트해야 합니다. Tauri 진영이 이 문제를 몰랐던 게 아닙니다 — 그래서 2025년에 나온 실험이 Servo 기반 웹뷰 Verso였고, 이 글은 그 실험이 2026년 7월 현재 어디에 서 있는지를 저장소와 레지스트리 기록으로 직접 확인한 결과입니다. 요약하면 이렇습니다. Verso는 공식적으로 멈췄고, 정작 Servo 본체의 임베딩은 그사이 훨씬 현실이 됐습니다.

Tauri 2 자체에 대한 일반론은 Tauri 2 심층 분석 편에서, 브라우저 엔진 지형은 브라우저 엔진 2026 편에서 이미 다뤘으므로, 여기서는 2025년 이후의 변화만 좁혀서 봅니다.

2025년 3월 — Tauri가 Verso를 실험하다

타임라인의 출발점은 Tauri 팀이 2025년 3월 17일 올린 Experimental Tauri Verso Integration입니다. 요지는 이렇습니다.

Servo의 임베딩 API는 너무 저수준이라 복잡한 API에 겁먹고 포기한 사람이 많았고, 글쓴이 자신도 솔직히 그중 하나였다고 적었습니다. 그래서 Verso가 그 위에 고수준 API를 얹고, Tauri는 기본 런타임 tauri-runtime-wry 대신 끼울 수 있는 커스텀 런타임 tauri-runtime-verso로 Verso를 붙인다.
당시 이미 작동한 것: tauri-cli 워크플로, React + Vite CSS 핫리로드, 공식 log·opener 플러그인, 창 크기·위치·최대화·최소화·닫기 등 윈도잉, data-tauri-drag-region 속성.
다만 "프로덕션에서 쓰는 기존 백엔드만큼 기능이 풍부하지는 않다"고 명시했습니다.

이 작업의 돈줄도 기록으로 남아 있습니다. NLnet의 NGI Assure 펀드가 Servo Webview for Tauri(2022-08 ~ 2024-03)와 Servo improvements for Tauri(2024-04 ~ 2024-08) 두 건의 그랜트를 집행했습니다. 즉 Verso는 취미 프로젝트가 아니라, 기한이 있는 그랜트로 굴러가던 실험이었습니다 — 이 사실이 뒤의 결말을 이해하는 열쇠입니다.

같은 블로그 글의 "future works"에는 눈여겨볼 문장이 하나 있습니다. 장기 목표로 Windows의 WebView2처럼 시스템에 한 번 깔리고 여러 앱이 공유하는 에버그린 Verso를 언급하면서, 그래야 "앱 안에 브라우저를 동봉하지 않아 번들 크기를 크게 줄일 수 있다"고 적었습니다. 뒤집어 읽으면 — Verso 방식은 그 에버그린 배포가 실현되기 전까지는 Electron과 같은 부류의 "엔진 동봉" 비용을 낸다는 것을, Tauri 팀 스스로 인정한 셈입니다.

2026년 7월의 Verso — 공식적으로 멈춤

이제 저장소 기록을 봅니다. 날짜는 전부 GitHub/GitLab API와 crates.io 레지스트리에서 직접 확인한 값입니다.

시점	사건	근거
2024-07-13	개발자 Wu Yu Wei의 Verso 0.1 소개 글	wusyong.github.io
2025-03-13	GitLab `verso-browser/verso` 프로젝트 생성 — 개발 본진이 GitLab로 이동, GitHub은 미러로 전환	GitLab API `created_at`
2025-06-17	GitLab `main` 브랜치 마지막 커밋	GitLab commits API
2025-07-10	GitLab 프로젝트 마지막 활동	GitLab API `last_activity_at`
2025-09-27	프리빌트 `versoview` 마지막 릴리스 v0.0.9 (Servo 커밋 19da3bc 고정)	tauri-apps/verso releases
2025-10-03	`tauri-runtime-verso` 마지막 커밋 (트러블슈팅 문서 추가)	GitHub commits API
2025-10-08	GitHub 미러에 아카이브 공지 커밋(PR #312) 후 저장소 아카이브	versotile-org/verso

아카이브된 GitHub 미러의 README 공지는 정중하고 솔직합니다. 요지를 옮기면 — Verso는 현재 더 이상 유지보수되지 않는다. 이 프로젝트는 Servo가 성숙한 브라우저로 자라기 위해 무엇이 필요한지 확인하려는 시도였고, 주요 기여 여럿이 Servo 본체에 통합됐다(개발 비하인드 글, 2025-05-13). 그러나 Servo에 큰 개정판이 연달아 릴리스되는 동안 "제한된 인력과 자금 때문에 그 속도를 따라가지 못했고", 당분간 저장소를 아카이브하며 되살릴 기회를 기다린다.

GitLab 쪽 README에는 더 실용적인 문장이 남아 있습니다 — "현시점에는 Servoshell(Servo의 데모 브라우저)이 더 나은 사용자 경험을 제공할 것"이라고, Verso 저장소가 스스로 적어 두었습니다.

몇 가지 세부도 짚어 둘 가치가 있습니다. 첫째, tauri-runtime-verso는 crates.io에 아예 올라간 적이 없습니다 — README의 설치법이 지금도 git 의존성입니다. 둘째, 프리빌트 versoview 바이너리는 x64 Linux/Windows/macOS와 arm64 macOS 네 종뿐이고, 마지막 버전 0.0.9가 고정한 Servo는 2025년 9월 시점 커밋입니다. 즉 지금 이 실험을 돌려 보면 10개월 묵은 Servo 위에서 돌게 됩니다. 셋째, Tauri 조직의 포크 tauri-apps/verso에 2026년 5월 4일 푸시가 있긴 했지만, 내용을 열어 보면 CI 로그 색상과 GitHub Actions 버전 경고 정리 — 유지보수 재개가 아니라 저장소 청소입니다. 마지막으로, 이주가 커뮤니티에 무엇을 남기는지 보여주는 숫자 하나 — 이 글 시점(2026-07-17) 기준으로 아카이브된 GitHub 미러는 별 5,404개, 본진이 된 GitLab 프로젝트는 별 29개입니다.

같은 기간 Servo 본체 — 월간 릴리스 트레인과 crates.io

Verso가 멈추는 동안 Servo 본체에는 정반대 방향의 일이 일어났습니다. 임베딩이 "저장소를 클론해서 어떻게든 링크하는 것"에서 "레지스트리에서 받는 것"으로 바뀐 겁니다.

2025-10-20, Servo가 GitHub 릴리스 v0.0.1을 시작으로 월간 릴리스에 들어갔습니다(v0.0.2 2025-11, v0.0.3 2025-12, v0.0.4 2026-01, v0.0.5 2026-02, v0.0.6 2026-03).
2026-04-13, 공식 블로그 Servo is now available on crates.io와 함께 servo 크레이트 0.1.0이 crates.io에 올라왔습니다. Servo를 라이브러리로 쓰는 첫 crates.io 릴리스입니다(rc1은 4월 4일). 데모 브라우저 servoshell은 crates.io에 올릴 계획이 없다고 못 박았습니다.
이후 월간 트레인이 그대로 굴러갑니다 — 0.2.0(2026-06-05), 0.3.0(2026-06-15), 그리고 이 글을 쓰기 하루 전인 2026-07-16에 0.4.0이 crates.io에 올라왔습니다(같은 시점 GitHub 릴리스 노트는 아직 없는데, 이 프로젝트는 크레이트를 먼저 올리고 노트를 나중에 다는 패턴이 있습니다).

블로그 글의 자기 평가는 절제돼 있습니다 — 버전 숫자에서 보이듯 1.0이 아니고, "1.0이 Servo에 무엇을 의미하는지에 대한 논의조차 아직 끝나지 않았다"고 적었습니다. 올라간 버전 숫자는 임베딩 API에 대한 "커지는 자신감"의 표현이라는 것이 공식 표현입니다.

월간 업데이트가 어떤 밀도로 도는지는 최신 월간 글인 May in Servo(2026-06-30 게재)에서 확인됩니다 — 0.3.0에 5월 한 달치 커밋 391개가 담겼고(3월은 534개), 임베딩 API 항목으로 최소 지원 Rust 버전이 1.86.0에서 1.88.0으로 올라간 것, 쿠키·환경설정·진단 API 작업, SpiderMonkey 140.10.1로의 업데이트에 포함된 메모리 안전성 수정이 명시돼 있습니다. 임베더 관점의 굵직한 기능(예: 멀티 윈도우, 프록시 지원)은 December in Servo부터 월간 글마다 꾸준히 등장합니다.

LTS 0.1.x — 약속의 내용과, 약속이 아닌 것

crates.io 버전 목록을 보면 순서가 이상한 릴리스가 둘 있습니다 — 0.3.0(6월 15일) 뒤에 나온 0.1.2(7월 5일). 이것이 Servo의 LTS 라인입니다. 0.1.0과 함께 발표된 LTS 정책은 Servo Book의 LTS 문서에 명시돼 있습니다.

6개월마다 당시 최신 정기 릴리스를 기반으로 새 LTS 브랜치를 만들고, 지원 기간은 다음 LTS로 갈아탈 시간을 포함해 9개월을 예상한다.
LTS 브랜치는 보안 수정만 받는다. 패치 릴리스는 필요할 때 나오며 고정 일정이 없다.
범위는 servo 라이브러리와 그 의존성뿐이고, servoshell은 명시적으로 제외된다.
LTS 브랜치에서는 최소 지원 Rust 버전을 올리지 않는다.
crates.io 게시는 "가능하면"이다 — 하위 크레이트의 CVE 수정이 구버전에 백포트되지 않으면 git 의존성이 필요할 수 있다고 미리 경고한다.

이 약속이 종이 약속이 아니라는 건 릴리스 기록이 보여줍니다. v0.1.1 (LTS)는 SpiderMonkey를 ESR 140.10으로 올린 의존성 패치였고(5월 25일 crates.io 게시), v0.1.2(7월 초)는 SpiderMonkey를 ESR 140.12로 올려 Mozilla 보안 권고 MFSA 2026-48·2026-58의 수정을 태우고, 보안 관련 변경 24건을 LTS에 백포트했다고 릴리스 노트에 적었습니다. JS 엔진의 보안 패치를 임베더가 따라받을 수 있는 경로가 생겼다는 뜻이고, 이것이야말로 "웹 엔진을 앱에 동봉"할 때 가장 무서운 운영 비용을 건드리는 변화입니다.

다만 같은 문서의 한계 조항을 원문 취지 그대로 옮겨 둡니다 — Servo는 있는 그대로(AS IS) 제공되며 보안을 포함해 어떤 보증도 없고, LTS는 관심 있는 커뮤니티 구성원들의 최선 노력(best-effort)이며(현재 명시된 유지관리자는 한 명입니다), 1.0 이전이므로 프로덕션 사용은 신중히 평가해야 한다. 특히 이 문장이 핵심입니다 — 알려진, 신뢰된 콘텐츠를 렌더링하는 앱에 Servo를 쓰는 것과, 임의의 콘텐츠를 렌더링하는 브라우저로 쓰는 것은 리스크 프로파일이 전혀 다르다. 데스크톱 앱 임베딩은 대체로 전자에 해당하고, Servo 팀 스스로 그 구분선을 그어 준 셈입니다.

그래서 파편화 문제는 풀렸나 — 아니요, 셈법이 바뀌었을 뿐

솔직한 결산을 하면 이렇습니다.

오늘의 Tauri는 여전히 wry입니다. tauri 크레이트는 2026년 7월 1일의 2.11.5가 최신이고, 기본 런타임은 변함없이 OS 웹뷰를 빌려 쓰는 tauri-runtime-wry입니다. WebKitGTK·WKWebView·WebView2 세 엔진에서 테스트해야 하는 현실은 2026년 중반에도 그대로입니다. Verso 런타임은 그 대안이 되지 못한 채 멈췄습니다.

Servo 경로는 파편화를 없애는 대신 동봉 비용을 되살립니다. Servo를 임베드한 앱은 어느 OS에서든 같은 엔진으로 렌더링하지만, 그 엔진을 앱과 함께 배포해야 합니다 — Tauri 팀이 에버그린 공유 Verso를 장기 과제로 꼽았던 이유가 정확히 이것입니다. 크기가 얼마나 불어나는지에 대해서는, tauri-runtime-verso로 만든 앱의 크기·메모리 실측치를 공개한 자료를 저는 찾지 못했습니다 — 숫자를 지어내는 대신 "공표된 측정치가 없다"고 적어 두는 쪽이 정확합니다. 확실한 것은 방향뿐입니다. OS 웹뷰를 빌리면 작아지고, 엔진을 실으면 커집니다.

성숙도 격차는 숫자가 아니라 종류의 문제입니다. WebKit·Chromium은 수십 년의 웹 호환성 작업이 쌓인 엔진이고, Servo는 아직 1.0의 정의조차 논의 중인 엔진입니다. 월간 릴리스마다 브레이킹 체인지가 예상된다고 공식 문서가 말하는 API 위에 제품을 얹으려면, 6개월 주기 LTS에 앉거나 업그레이드 노동을 상시 예산에 넣어야 합니다.

지금 무엇을 고르나 — 판단 기준

오늘 프로덕션 데스크톱 앱을 배포해야 한다면 — 선택지는 2025년과 같습니다. 크기·메모리가 우선이면 Tauri + wry로 가되 세 엔진 테스트 비용을 CI에 반영하고, 렌더링 일관성이 협상 불가면 Electron류의 엔진 동봉을 받아들이는 것입니다. 이 비교의 일반론은 크로스플랫폼 데스크톱 앱 2026 편에 있습니다.
Tauri + Servo 조합이 궁금하다면 — tauri-runtime-verso는 여전히 클론해서 돌려 볼 수 있지만, 2025년 9월의 versoview 0.0.9에 고정된, 커밋이 멈춘 실험이라는 사실을 알고 만지십시오. 여기에 제품을 얹는 것은 현재로선 근거가 없습니다.
자기 앱의 신뢰된 콘텐츠만 렌더링하는 임베더라면 — 이번에 진짜로 지켜볼 가치가 생긴 쪽은 servo 크레이트 자체입니다. crates.io에서 받아지고, LTS 브랜치가 보안 백포트를 실제로 하고 있으며, 월간 글로 임베딩 API 변경이 공지됩니다. 프로토타입을 LTS(0.1.x)에 앉혀 두고 반년 뒤 다음 LTS로의 이주 비용을 재 보는 것이 현실적인 첫걸음입니다.
쓰지 말아야 할 곳 — 임의의 웹을 렌더링하는 용도(Servo 문서가 그은 바로 그 선), 웹 호환성 이슈를 감당할 여력이 없는 팀, 그리고 안정된 API 위에서만 굴러가는 조직입니다. 1.0 이전이라는 말은 장식이 아닙니다.

마치며

2025년 봄의 그림 — "Verso가 Servo를 감싸고, Tauri가 Verso를 실어, OS 웹뷰 파편화에서 벗어난다" — 은 실현되지 않았습니다. 인력과 자금이 그랜트 종료와 함께 빠지자 래퍼 계층이 먼저 멈췄고, 그 사실을 저장소들이 담담하게 기록하고 있습니다. 대신 예상 밖의 진전이 아래층에서 왔습니다. Servo 본체가 월간 릴리스와 crates.io 게시, 그리고 보안 백포트가 실제로 도는 LTS까지 갖추면서, "Rust 앱에 웹 엔진을 라이브러리로 넣는다"는 문장이 2026년에는 문자 그대로 cargo add servo가 됐습니다.

파편화 문제 자체는 풀리지 않았습니다. 지금 고를 수 있는 것은 여전히 "세 엔진에서 테스트"와 "엔진을 싣고 다니기" 사이의 트레이드오프뿐이고, Servo는 후자의 비용 구조를 바꿀 수 있는 후보로 이제 막 레지스트리에 등장했을 뿐입니다. 다음 확인 시점은 명확합니다 — 첫 LTS의 9개월 지원이 끝나는 2027년 초, 두 번째 LTS 브랜치가 약속대로 나오는지. 그때 이 실험이 인프라가 됐는지를 다시 셈해 보면 됩니다.