02 — Tauri

한 줄 답: Tauri는 Rust 백엔드 + OS의 webview(macOS WKWebView · Windows WebView2 · Linux WebKitGTK)를 묶어 번들 5~15MB · 메모리 절반을 달성한다. Electron의 “무거운 Chromium을 통째 번들”을 OS가 이미 가진 webview에 위임으로 풀었다. 그러나 그 위임의 대가가 Chromium 통일성 부재 — 같은 코드가 세 OS에서 조금씩 다르게 동작한다. 그 차이를 production에서 사용자별 버그로 받아들일 수 있느냐가 Tauri를 선택할 수 있는지의 진짜 기준이다.

Why — 왜 Tauri가 등장했나

Electron이 *“무겁다”*는 비판은 십 년째 같았다. Chromium 통째(~150MB)를 매 앱이 복사해서 들고 다니는 모델 — Chrome 탭이 수십 개 열려 있는 사용자에게는 이중 비용이다.

사용자 머신:
  Chrome 본체: 200MB
  + Electron 앱 A: Chromium 150MB + 앱 50MB
  + Electron 앱 B: Chromium 150MB + 앱 30MB
  + Electron 앱 C: Chromium 150MB + 앱 40MB
  = Chromium 4개 + 각 앱 = ~770MB

각 Chromium은 버전이 다르다. 보안 패치도 각자 따로 배포해야 한다. 공유되지 않는다.

Tauri의 통찰은 — macOS는 이미 WKWebView를, Windows는 WebView2를, Linux는 WebKitGTK를 갖고 있다. 그것을 OS가 관리하는 공유 webview로 쓰자. 앱은 Rust 백엔드 + HTML/JS 프론트만 번들. 결과는:

Tauri 앱 A: ~10MB  (OS webview 사용)
Tauri 앱 B: ~8MB
Tauri 앱 C: ~12MB
+ OS의 공유 webview 1세트
= ~30MB + 공유분

20배 차이. 데스크톱 메모리·디스크 절약이라는 약속.

How — Tauri의 구조

핵심 구성

1. Rust 백엔드 — Electron의 main 프로세스에 해당. tauri::command로 함수를 노출하고, 프론트엔드는 @tauri-apps/api의 invoke('command_name')로 호출.
2. OS webview — 프론트엔드 렌더링. 번들되지 않고 OS가 관리.
3. Tauri Runtime — 그 둘을 잇는 brigde + 라이프사이클 관리. Rust로 작성.
4. WRY — Tauri의 webview 추상화 라이브러리. macOS의 WKWebView, Windows의 WebView2, Linux의 WebKitGTK를 통일된 API로 감싼다.
5. TAO — 윈도우 관리 라이브러리. Electron의 BrowserWindow에 해당.

코드 예시 (Electron vs Tauri)

// Electron — main process
const { ipcMain, app } = require('electron');
const fs = require('fs/promises');
 
ipcMain.handle('read-file', async (event, path) => {
  return fs.readFile(path, 'utf-8');
});

// Tauri — Rust backend
#[tauri::command]
async fn read_file(path: String) -> Result<String, String> {
    tokio::fs::read_to_string(path)
        .await
        .map_err(|e| e.to_string())
}
 
fn main() {
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![read_file])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

// 프론트엔드 — 동일하게 비동기 호출
// Electron
const text = await window.api.readFile('/path/to/file');
 
// Tauri
import { invoke } from '@tauri-apps/api/tauri';
const text = await invoke('read_file', { path: '/path/to/file' });

→ 프론트엔드는 거의 같지만, 백엔드가 Rust. 팀의 Rust 학습 비용이 최대 함정이다.

What — Electron vs Tauri 실측 비교

번들 크기

메모리

주의: Tauri가 절반인 건 사실이지만 — OS webview의 메모리는 공유되므로 사용자 머신 전체로 보면 더 큰 절약.

시작 시간 (Cold Start)

→ 시작 시간은 체감 차이가 가장 큼. 메뉴바 앱·CLI 도구처럼 자주 켜고 끄는 앱에서 Tauri가 압도적.

CPU (Idle)

→ 배터리 절약에서도 Tauri가 유리. 노트북 사용자에게 유의미.

개발 생산성

→ 생산성은 여전히 Electron이 우위. Rust 팀이라면 Tauri가 빨라지지만, 보통 팀은 느려진다.

OS webview 차이 — Tauri의 최대 함정

이게 Tauri를 선택할 때 진짜 위험이다.

차이 매트릭스

→ 기능이 다른 게 아니라 같은 기능이 다르게 동작. 이게 production에서 사용자별 버그로 돌아온다.

실제 문제 사례

WKWebView (macOS):

• 세로 스크롤 관성 동작이 다름 (overflow: auto 안에서)
• :focus-visible이 키보드 vs 마우스 구분 다르게 동작 (Safari 버전에 따라)
• iOS-style 클릭 효과가 macOS에서 원치 않게 적용

WebView2 (Windows):

• Edge 버전에 따라 다름 — 사용자 머신마다 다른 Edge
• 기업 환경에서 Edge가 수동 패치 — 몇 년 전 버전인 경우
• DPI scaling이 모니터 두 개 환경에서 글리치

WebKitGTK (Linux):

• 가장 오래된 엔진 — 종종 2년 전 Safari 수준
• WebGL 확장이 Mesa 드라이버에 따라 불안정
• distribution별로 버전이 다름 — Ubuntu 22.04 vs Fedora 39 vs Arch가 모두 다른 WebKitGTK
• font rendering이 한글에서 깨지는 경우 다수

대응 전략

→ 셋 다 production에서 본 회사들의 결론은 — 간단한 UI는 Tauri, 복잡 UI는 Electron. 매트릭스가 복잡할수록 Tauri의 QA 비용이 폭증.

What-if — Tauri를 잘못 도입하면

1) 복잡 UI에 Tauri 도입

→ 세 OS webview의 미묘한 차이가 사용자별 버그. 재현 어렵고 디버깅 시간 폭증. 6개월 뒤 Electron 검토. 대응: Tauri는 간단~중간 UI에 한해. 복잡 UI는 Electron.

2) Rust 팀 없이 Tauri 도입

→ 처음 Hello World는 빠르지만, 복잡한 OS API나 별도 worker 스레드가 필요할 때 Rust 학습 절벽. 3개월 뒤 Rust 잘 아는 사람 채용 또는 Electron 회귀. 대응: 팀에 Rust 사용 경험자 2명 이상. 아니면 Electron.

3) Linux 사용자가 많은데 Tauri

→ WebKitGTK의 distribution별 차이가 지원 비용 폭증. Linux 사용자 한 명당 다른 환경. 대응: Linux 중심이면 Electron. Tauri는 Windows/macOS 중심.

4) 고급 웹 feature 의존 (WebGPU, 최신 CSS)

→ WKWebView·WebKitGTK가 늦게 지원. 사용자가 macOS 13/Ubuntu 20.04면 기능 자체가 없음. 대응: 최신 feature 필수면 Chromium 통일 — Electron.

5) 모바일까지 같은 코드 기대

→ Tauri 2.0의 모바일 지원은 2024년 GA이지만 생태계 빈약. 모바일은 별도 작업이 거의 필수. 대응: 모바일 주력이면 Capacitor/RN. Tauri는 데스크톱 우선.

Tauri가 잘 맞는 자리

적합 예시

• 개발자 도구 (Bruno API client — Tauri로 작성)
• 메뉴바 시계·할 일 (cross-platform 메뉴바 앱)
• 암호 관리자 (1Password가 일부 컴포넌트를 Tauri로 검토)
• 간단 채팅 클라이언트
• 사내 어드민 도구 (작은 팀, Rust 사용)

부적합 예시

• IDE (VS Code 같은 — Chromium 깊이 의존)
• 디자인 툴 (Figma 같은 — WebGL critical)
• 복잡 협업 (Notion·Slack — 기능 추가 속도 critical)
• 모바일이 주력인 앱

Insight — 흥미로운 이야기

”Tauri의 출발점 — npm install 절약”

Tauri의 창시자 Daniel Thompson-Yvetot는 Electron의 디스크 점유를 가장 큰 문제로 봤다. 유저 한 명이 Slack + VS Code + Discord + 1Password를 깔면 Chromium 4개. 그것을 OS가 이미 가진 webview로 풀자는 단순한 아이디어가 시작.

흥미로운 건 — Tauri의 번들 절약은 유저당 디스크 GB 단위로 측정되지만, 기업 IT 입장에서는 각 앱이 다른 Chromium 버전을 들고 다니지 않으니 패치 통제 용이라는 부가 가치가 더 컸다.

”WebView2의 변신”

Microsoft가 2020년경 WebView2를 Edge Chromium 기반으로 재설계한 건 Tauri를 위해서가 아니라, Windows 자체의 웹 콘텐츠(WPF의 WebBrowser 컨트롤 등)를 현대화하기 위해서였다. 그 부산물로 Tauri의 Windows 지원이 Edge 수준이 되었다 — Linux WebKitGTK와 현격한 격차가 여기서 생겼다.

”Linux Tauri의 짐”

Tauri 커뮤니티에서 가장 자주 토론되는 주제가 Linux WebKitGTK의 미래다. WebKitGTK 자체가 정체되어 있고, 대체로 Servo(Mozilla의 차세대 엔진)나 Chromium-based WebView가 거론되지만 아직 정착되지 않음. Linux Tauri의 진짜 매력은 그 짐을 감수할 가치가 있는가에 달려 있다.

”1Password의 Tauri 검토”

1Password는 2018년 Electron 전환 후 2021년 Rust 네이티브 코어로 재설계했고, 2023년 이후 Tauri를 일부 도구·확장에 적용. 같은 회사가 시기마다 다른 답을 골랐다 — Electron(빠른 출시) → Rust(보안) → Tauri(둘의 절충). 한 회사의 역사가 데스크톱 기술 생태계의 축소판이다.

”한국 — Tauri 도입 사례”

한국 IT에서 Tauri는 2022~2023년 검토 시작 → 2024년 일부 사내 도구. 카카오·네이버 등의 작은 사내 도구(빌드 모니터, 로그 뷰어 등)에 적용 사례가 있지만 외부 공개 앱에는 아직 신중. Electron의 성숙도와 Tauri의 미래성 사이에서 기다리는 분위기.

요약 + 다이어그램

Tauri는 데스크톱 메모리·시작 시간을 극적으로 개선한다 — Electron의 ~5-15배 작은 번들, ~2배 적은 메모리, ~3배 빠른 시작. 그 대가는 Chromium 통일성 부재 — macOS·Windows·Linux의 세 webview가 미묘하게 다르게 동작하고, 이 차이가 production에서 사용자별 버그로 돌아온다. 간단~중간 UI + Rust 팀 + Linux 비중 낮음 — 이 셋이 맞으면 Tauri가 압승. 복잡 UI · 모든 OS QA 어려움 · Linux 중심 — 이 중 하나라도 강하면 Electron이 옳다.

다음 문서: 03-wails-and-neutralino.md — Tauri만 대안이 아니다. Go(Wails)·C++(Neutralino) 등 다른 언어 스택의 답.