- 원격 페어 프로그래밍을 위한 초저지연 리모트 컨트롤 앱을 개발 중에 앱 프레임워크로 Tauri를 채택
- 선택한 이유는 성능, 메모리 효율, 사이드카 지원 등
- Rust 기반 백엔드 + 시스템 WebView 사용으로 Electron 대비 앱 크기와 메모리 사용량이 훨씬 작음
-
Tauri v2에서 기능 격차도 빠르게 해소 중, 자동 업데이트, 사이드카 등 핵심 기능이 내장됨
- Electron은 여전히 강력하지만, Hopp의 특수한 요구사항에는 Tauri가 더 적합
Hopp가 Tauri를 선택한 이유
배경: 크로스 플랫폼 앱 프레임워크 선택
- Hopp는 Windows, macOS, Linux에서 동일하게 동작하는 고성능 데스크탑 앱이 필요
- Electron과 Tauri는 대표적인 선택지로, 각각 장단점이 뚜렷하게 존재
- Hopp 팀은 장기 유지보수성과 퍼포먼스를 중시하여 선택함
Tauri vs. Electron: 구조적 차이
-
Electron 구조
-
Node.js 런타임 포함 필요 → 앱 용량 증가
- 각 창은 별도 렌더러 프로세스 (Chromium 엔진) 사용 → 메모리 소비 큼
- 시스템과의 깊은 통합은 별도 프로세스 필요
-
Tauri 구조 요약
- 백엔드는 Rust 기반 네이티브 바이너리 → 별도 런타임 불필요
-
시스템 WebView 사용 (Windows: WebView2, macOS: WKWebView, Linux: WebKitGTK)
- 창 수에 따라 메모리 효율이 좋음, 다만 브라우저 엔진 불일치 이슈 관리 필요
핵심 기능 비교
-
시작 시간은 Tauri와 Electron 모두 빠른 편이며, 체감상 큰 차이가 없음
-
메모리 사용량에서는 Tauri가 훨씬 적음
- Tauri는 약 172MB 정도의 메모리를 사용한 반면
- Electron은 약 409MB로, 거의 2배 이상 더 많은 메모리를 소비
-
렌더링 엔진 측면에서는
- Tauri는 운영체제에 내장된 WebView를 사용하여 앱 크기가 작고 경량
- Electron은 Chromium 엔진을 앱에 직접 포함하므로 더 많은 리소스를 사용
-
백엔드 언어는
- Tauri가 Rust를 사용해 고성능 네이티브 코드를 작성 가능
- Electron은 JavaScript(Node.js) 기반으로 웹 개발자에게 친숙하지만 성능은 상대적으로 낮음
-
초기 빌드 시간은
- Tauri는 Rust 컴파일이 포함되어 초기 빌드가 느림
- Electron은 JS 기반이라 초기 빌드가 빠름
-
앱 용량 비교에서는
- Tauri는 약 8.6MiB로 매우 가볍고
- Electron은 약 244MiB로, 약 28배 더 큼
Hopp가 Tauri를 선택한 결정적 이유
-
1. 고성능 Rust 백엔드
-
WebRTC 기반 초저지연 영상 스트리밍 구현 필요
- Electron에서는 별도 프로세스를 띄워야 하지만, Tauri는 Rust 백엔드에 직접 구현 가능
-
2. 사이드카(Sidecar) 프로세스 지원
- 스트리밍 및 입력 처리를 별도 바이너리로 분리하여 관리
- Tauri는 사이드카를 공식 지원 → 수명 주기 및 통신 관리 간편
- 향후 커서 렌더링을 위해 Tauri egui로의 확장도 고려 중
-
3. 빠르게 진화하는 기능 지원
-
Tauri v2는 자동 업데이트 등 핵심 기능을 내장
- Electron보다 상대적으로 신생이지만, 보안과 성능 중심의 비전이 Hopp와 부합
결론: 어떤 프레임워크가 더 나은가?
-
Electron과 Tauri 모두 훌륭한 데스크탑 앱 프레임워크
- 프로젝트 성격에 따라 선택이 달라질 수 있음
- Electron: 빠른 개발, JS 친화적, 넓은 생태계
- Tauri: 더 작고 가볍고 빠르며, Rust 기반 퍼포먼스에 최적화
- Hopp는 퍼포먼스 중심의 기술 스택과 별도 프로세스 구성 필요로 인해 Tauri를 채택