Skip to content
Published on

크로스플랫폼 데스크톱 앱 2026 완벽 가이드 - Tauri 2 · Electron 34 · Wails 3 · NeutralinoJS · Flutter Desktop · Sciter · Slint · Iced 심층 분석

Authors

프롤로그 - "데스크톱은 다시 1차 표면이다"

2010년대 중반, 모바일 앱이 모든 화면을 차지할 것처럼 보였다. 그런데 2026년 현실은 정반대로 흘렀다. 개발자 도구(VS Code · Cursor · JetBrains), 디자인 도구(Figma 데스크톱 · Affinity), 협업 도구(Slack · Discord · Notion · Linear · 카카오톡 데스크톱), 보안 도구(1Password · Bitwarden), 미디어 도구(OBS · Reaper · DaVinci Resolve · Cap) - 전부 데스크톱이 1차 표면이다. 웹 앱은 보조, 모바일은 알림 채널, 진짜 작업은 데스크톱에서 일어난다.

그래서 "어떤 도구로 크로스플랫폼 데스크톱 앱을 만들 것인가"는 다시 가장 뜨거운 질문이 됐다. 한 달 전에 쓴 "데스크톱 앱 프레임워크 카테고리 비교"는 큰 지도였다. 이 글은 그 지도를 가지고 실제로 길을 걷는다. 후보 도구를 차례로 설치하고, 번들을 빌드하고, 메모리를 재고, 패키징과 코드 서명을 시도하고, 그 결과로 무엇을 선택해야 하는지 결론을 낸다.

핵심 한 줄: 2026년에는 "Electron 아니면 Tauri"가 아니다. Wails 3 · Flutter Desktop · Slint · Iced · Lynx · Avalonia · MAUI까지 진영이 늘어났고, 진영마다 다른 장점이 있다. 이 글의 목표는 그 진영 차이를 30분 안에 정리하고, 5가지 기준으로 "당신 팀의 도구"를 고르게 하는 것이다.


1장 · 2026년 데스크톱 시장의 4대 트렌드

1.1 Chromium 의존에서 시스템 웹뷰로

10년 동안 Chromium을 통째로 들고 다니던 시대가 끝나가고 있다. WebView2(Windows) · WKWebView(macOS) · WebKitGTK(Linux)가 충분히 안정화됐고, 이것을 쓰면 번들 크기가 1/10 수준으로 줄어든다. Tauri 2 · Wails 3 · NeutralinoJS는 모두 시스템 웹뷰 진영이다.

1.2 모바일까지 확장하는 데스크톱 프레임워크

Tauri 2가 2024년에 iOS/Android 지원을 추가하면서 "데스크톱 + 모바일 단일 코드베이스"가 다시 후보에 올라왔다. Flutter는 데스크톱을 모바일에 얹은 케이스고, Compose Multiplatform · MAUI도 같은 야망을 갖고 있다.

1.3 Rust 진영의 본격 진입

Tauri · Slint · Iced · Xilem · egui · gtk-rs - Rust로 데스크톱 UI를 짜는 도구가 6종이 넘는다. 2026년 시점에서 "새 프로젝트를 Rust로 시작하는 것"이 위험 부담이 아니라 합리적 선택이 됐다.

1.4 패키징과 코드 서명의 표준화

macOS Developer ID Notarization, Windows Authenticode EV cert, Linux Flatpak/Snap - 5년 전만 해도 각자 다른 방법이었지만 2026년에는 electron-builder · Tauri Action · GitHub Actions 워크플로가 거의 표준 템플릿으로 굳어졌다.


2장 · Electron 34 - 여전히 코끼리지만 길이 좁아진다

2.1 출신과 현재

Electron의 본명은 Atom Shell이다. 2013년 GitHub Atom 에디터를 만들기 위해 GitHub가 시작했고, 이후 OpenJS Foundation으로 이관됐다. 2026년 5월 시점에서 Electron 34가 안정 라인이며, Chromium 130대를 따라가고 있다. v34부터 ASAR Integrity의 macOS/Windows 강제 검증, 새로운 utility process API, 네이티브 글래스 효과 지원이 추가됐다.

2.2 어떤 앱이 쓰는가

  • VS Code · Cursor · Trae
  • Slack · Discord · Notion · Linear
  • 1Password 8 · Bitwarden
  • Figma 데스크톱 · GitHub Desktop · Postman
  • Spotify (오랫동안)
  • 카카오톡 데스크톱

2.3 번들 크기와 메모리

빈 Hello World 앱이 디스크에 약 150MB를 차지한다. 압축 다운로드는 80MB 정도. 빈 앱이 100200MB 메모리를 쓰고, 실제 앱은 보통 200500MB를 쓴다. 디스코드 · Slack은 1GB도 넘는다.

2.4 장점

  • 13년의 성숙도. 모든 엣지케이스가 이미 해결돼 있다.
  • Chromium 호환성: WebGL · WebRTC · Service Worker · 코덱 전부 동일.
  • electron-builder · electron-forge · Spectron · electron-updater 같은 회사용 도구가 즐비.

2.5 단점

  • 번들 크기: 150~300MB.
  • 메모리: 빈 앱이 100MB+.
  • 시작 시간: Chromium 부팅 + V8 초기화 = 1~3초.
  • 보안: 노드 통합 + 원격 모듈을 잘못 쓰면 RCE 가능.

3장 · Tauri 2 - 시스템 웹뷰 진영의 1위

3.1 출신과 현재

Tauri는 2019년 Daniel Thompson-Yvetot가 시작한 프로젝트로, MIT 라이선스의 Rust 기반 데스크톱 프레임워크다. 2024년 v2가 정식 출시되면서 iOS/Android 지원이 추가됐고, 2026년 5월 시점에서 데스크톱 + 모바일을 동시에 다루는 진영의 표준으로 자리잡았다.

3.2 어떤 앱이 쓰는가

  • Spacedrive (크로스플랫폼 파일 익스플로러)
  • Mockoon (API 목 서버)
  • Pot translator (번역기)
  • Cap (오픈소스 스크린 레코더)
  • Lens (Kubernetes IDE - 일부 모듈)

3.3 번들 크기와 메모리

빈 Hello World가 약 10MB. 시스템 웹뷰를 쓰기 때문에 Chromium 사본을 들고 다니지 않는다. 메모리도 50~100MB로 Electron의 1/3 수준.

3.4 장점

  • 번들 크기 1/15. 다운로드 빠르고 디스크 부담 적다.
  • 메모리 절반 이하.
  • Rust 백엔드의 안전성과 속도.
  • v2의 iOS/Android 지원 - 단일 코드베이스로 5개 플랫폼.

3.5 단점

  • 시스템 웹뷰의 버전 차이. macOS의 WKWebView와 Windows의 WebView2 동작이 미세하게 다르다.
  • WebGL · 코덱 호환성이 Chromium만큼 균질하지 않다.
  • Rust 학습 곡선. 백엔드를 짜려면 Rust를 알아야 한다.
  • 7년 차 프로젝트이지만 생태계가 Electron만큼 두텁지는 않다.

4장 · Wails 3 - Go 진영의 데스크톱 답

4.1 출신과 현재

Wails는 Lea Anthony가 2019년부터 만든 Go 기반 데스크톱 프레임워크다. MIT 라이선스. v3 알파가 2024년부터 공개되었고, 2026년 시점에서 정식 출시 직전 단계다. Tauri와 거의 같은 컨셉(시스템 웹뷰 + 컴파일된 백엔드)이지만 백엔드 언어가 Go라는 점이 다르다.

4.2 번들 크기와 메모리

빈 앱 약 15MB. 메모리 60~120MB. Tauri와 거의 같은 영역.

4.3 장점

  • Go 팀에게는 자연스러운 선택. 백엔드 인프라를 Go로 만드는 회사가 데스크톱 도구도 같은 언어로.
  • 단일 바이너리 빌드의 단순성.
  • 빌드 속도가 Tauri보다 빠르다(Go가 Rust보다 빠른 컴파일).

4.4 단점

  • 사용자 수가 Tauri보다 적다. 생태계 부족.
  • 모바일 지원 없음.
  • v3가 아직 알파.

5장 · NeutralinoJS - 초경량 진영

5.1 출신과 현재

NeutralinoJS는 Shalitha Suranga가 2020년에 시작한 TypeScript 기반 데스크톱 프레임워크다. MIT 라이선스. 컨셉이 더 극단적이다 - "Rust나 Go도 필요 없다, 시스템 웹뷰만 쓰자". 백엔드를 컴파일하는 단계 자체가 없다.

5.2 번들 크기와 메모리

빈 앱 약 25MB. 가장 가볍다. 메모리도 4080MB.

5.3 장점

  • 가장 작은 번들. 다운로드 1초.
  • 빌드 자체가 거의 즉시.
  • TypeScript 한 언어로 완결.

5.4 단점

  • 백엔드 기능이 제한적. CPU 집약 작업은 Native Extension을 만들어야 한다.
  • 자료가 적고 도구도 적다.
  • 보안 모델이 Tauri만큼 정교하지 않다.

6장 · Flutter Desktop - 자체 렌더링 진영

6.1 출신과 현재

Flutter는 2017년 Google이 모바일용으로 시작한 프레임워크다. Dart 언어 + Skia 렌더링 엔진. 2022년에 데스크톱 stable이 됐고, 2026년에는 Windows · macOS · Linux 모두 production-ready 상태다.

6.2 어떤 앱이 쓰는가

  • Rive (애니메이션 도구)
  • Reflectly (저널링 앱)
  • Wonderous (Wonder of the World 가이드)
  • Superlist (할일 앱)
  • 일본의 SmartHR 일부 데스크톱 모듈

6.3 번들 크기와 메모리

빈 앱 약 3050MB. 시스템 웹뷰를 안 쓰지만 Skia 엔진을 들고 다닌다. 메모리 100150MB.

6.4 장점

  • 모든 OS에서 픽셀 일관성. 디자이너가 보장한 그대로 나온다.
  • 모바일과 같은 코드베이스 - 데스크톱은 같은 UI 코드의 확장.
  • 60fps 부드러운 애니메이션.

6.5 단점

  • 네이티브 룩앤필이 아니다. 어떤 OS에서도 "자연스럽지" 않다.
  • Dart 언어가 진영을 좁힌다.
  • 시스템 통합(트레이 · 알림 · 메뉴바)이 Electron보다 약하다.

7장 · Sciter - 상업용 HTML/CSS 엔진

7.1 출신과 현재

Sciter는 Andrew Fedoniouk가 2008년부터 만든 독점 라이선스 데스크톱 엔진이다. HTML/CSS 일부를 자체 엔진으로 그리는데, 번들 크기가 5MB 이하다. Norton AntiVirus · BitDefender · ESET · Comodo - 보안 제품 대부분이 Sciter로 UI를 만든다.

7.2 번들 크기와 메모리

5MB 이하. 메모리 30~60MB. 데스크톱 도구 중 가장 작은 편.

7.3 장점

  • 가장 작은 풋프린트.
  • HTML/CSS의 익숙함 + 네이티브에 가까운 성능.
  • 보안 제품에서 검증된 13년 사용.

7.4 단점

  • 독점 라이선스. 비상업 사용은 무료지만 상업 사용은 라이선스 비용.
  • 오픈소스 도구 생태계가 없다.
  • 일반 웹 표준 일부만 지원.

8장 · Slint 1.x - 임베디드 + 데스크톱 진영

8.1 출신과 현재

Slint는 SixtyFPS GmbH(Olivier Goffart 등 전 Qt 코어 개발자들)가 2020년 시작한 Rust + DSL 기반 GUI 툴킷이다. 1.0이 2023년에 나왔고, 2026년 시점에서 1.6 라인. 임베디드 시스템과 데스크톱 모두를 타깃으로 한다.

8.2 라이선스

  • 로열티 + GPL 듀얼 라이선스
  • 또는 상업 라이선스
  • 오픈소스 프로젝트라면 GPL 사용 가능

8.3 장점

  • 자체 렌더링 - GPU 가속, 60fps 부드러움.
  • 임베디드(STM32 같은 MCU)까지 한 코드베이스.
  • DSL 디자이너가 따로 있어서 디자인-코드 분리 잘 됨.

8.4 단점

  • DSL을 새로 배워야 한다.
  • 생태계가 작다.
  • 라이선스가 사실상 듀얼이라 상업 사용 시 정리 필요.

9장 · Iced - Elm 영감의 Rust GUI

9.1 출신과 현재

Iced는 Héctor Ramón이 2019년부터 만든 Rust GUI 라이브러리. MIT 라이선스. Elm 아키텍처(Model-View-Update)에서 영감을 받았다.

9.2 장점

  • 함수형 패턴이 일관적. 상태 관리가 깔끔.
  • 순수 Rust - 다른 언어 런타임 필요 없음.
  • 빠른 시작 시간.

9.3 단점

  • 위젯 라이브러리가 작다. 커스텀 위젯을 많이 짜야 한다.
  • 임베디드/모바일 지원 약함.
  • 1.0 전 상태(2026년에도).

10장 · Druid에서 Xilem으로 - Linebender의 진화

10.1 Druid의 종료

Druid는 Raph Levien의 Linebender 그룹이 2018년부터 만든 Rust GUI 툴킷이었는데, 2023년 말부터 사실상 유지보수 중단(deprecated) 상태가 됐다. 후속작이 Xilem이다.

10.2 Xilem - 새로운 시도

Xilem은 SwiftUI의 선언적 패턴 + Rust의 안전성 + Linebender의 그래픽 노하우를 결합한 실험 프로젝트다. 2026년 시점에서 아직 0.x 라인이고 production-ready는 아니지만, Rust 진영에서 가장 주목받는 GUI 실험 중 하나다.


11장 · egui - Immediate Mode 진영

11.1 출신과 현재

egui(eh-gooey)는 Emil Ernerfeldt가 2020년부터 만든 Rust 즉시 모드 GUI 라이브러리. MIT 라이선스. Dear ImGui(C++)와 비슷한 컨셉.

11.2 어떤 곳에서 쓰는가

  • Rerun (CV/로보틱스 시각화 도구) - 큰 사용 사례
  • 디버그 오버레이가 필요한 게임/도구
  • 빠른 프로토타이핑

11.3 장점

  • 학습 곡선 짧다. 한 시간이면 GUI 화면을 만든다.
  • 시작 시간 매우 빠름.
  • Web(WASM)도 지원.

11.4 단점

  • 디자인 자유도가 낮다. 위젯 룩이 매우 단순.
  • 대형 앱에는 부적합. 디버그 도구나 시각화에 더 어울린다.

12장 · GTK 4 + Adwaita - Linux 네이티브 진영

12.1 출신과 현재

GTK는 1998년부터 있는 Linux 데스크톱 툴킷의 본가다. 2020년 GTK 4 출시 이후 GNOME 디자인 시스템 라이브러리인 libadwaita(Adwaita)와 함께 쓰는 게 표준이 됐다. 2026년 시점에서 GTK 4.16, libadwaita 1.6 라인.

12.2 어떤 앱이 쓰는가

  • GNOME 데스크톱 환경의 모든 1차 앱
  • Files · Calendar · Maps · Photos · Music
  • Bottles (Wine 관리자)
  • 다양한 GNOME Circle 앱

12.3 장점

  • GNOME Linux에서 100% 네이티브 룩.
  • Vala · Python · Rust(gtk-rs) · C 다양한 바인딩.
  • 접근성과 i18n이 매우 강함.

12.4 단점

  • macOS · Windows에서는 1급 시민이 아니다. 동작은 하지만 룩앤필이 어색.
  • GTK 3 → 4 마이그레이션이 아직 진행 중.

13장 · Qt 6.8 LTS + PyQt6/PySide6

13.1 출신과 현재

Qt는 1995년부터 있는 C++ 기반 크로스플랫폼 GUI 툴킷의 황제다. Trolltech → Nokia → The Qt Company로 소유권이 이동했고, 2024년 10월 Qt 6.8 LTS가 나왔다. 2026년 시점에서 6.8이 안정 LTS, 6.9가 최신.

13.2 라이선스

  • LGPLv3 (오픈소스 - 동적 링킹 의무)
  • GPL
  • 상업 라이선스 (정적 링킹 + 상업 지원)

13.3 어떤 앱이 쓰는가

  • Affinity Designer · Photo · Publisher
  • OBS Studio
  • Maya · Autodesk 도구의 일부
  • Calibre (전자책 관리)
  • KDE Plasma의 모든 앱

13.4 PyQt6 / PySide6

  • PyQt6는 Riverbank Computing이 만든 GPL/상업 Python 바인딩
  • PySide6는 Qt 공식 LGPL Python 바인딩
  • 2026년에는 PySide6가 더 많이 쓰인다(라이선스가 더 친화적)

14장 · wxWidgets - 클래식 C++

wxWidgets는 1992년부터 있는 가장 오래된 크로스플랫폼 C++ 툴킷이다. 각 OS의 네이티브 위젯을 호출하므로 룩앤필이 자연스럽다. 단점은 모던 디자인이 어렵고 GPU 가속이 약하다는 점. 2026년에 새 프로젝트가 wxWidgets를 고르는 일은 드물지만, 레거시 데스크톱 앱이 여전히 많다.


15장 · JavaFX 23 - Java 데스크톱

15.1 출신과 현재

JavaFX는 2008년 Sun이 시작한 Java 기반 GUI 툴킷이다. 2018년 Java 11부터 JDK에서 분리되어 OpenJFX 프로젝트로 독립. 2026년 시점에서 JavaFX 23이 최신.

15.2 어떤 곳에서 쓰는가

  • 금융 트레이딩 데스크탑 일부
  • 교육용 IDE (BlueJ · Greenfoot)
  • 일부 SaaS 회사의 어드민 도구

15.3 평가

  • Java 팀에게는 자연스러운 선택
  • 하지만 새 프로젝트가 JavaFX를 고르는 일은 줄고 있음 - Kotlin + Compose Multiplatform에 자리를 내주는 중

16장 · Avalonia 11 - 크로스플랫폼 XAML

16.1 출신과 현재

Avalonia는 2013년 Steven Kirk가 시작한 .NET 기반 크로스플랫폼 UI 프레임워크다. WPF의 XAML 패턴을 그대로 가져왔지만 Windows뿐 아니라 macOS · Linux · iOS · Android · WebAssembly까지 지원한다. 2026년 시점에서 Avalonia 11.x.

16.2 어떤 앱이 쓰는가

  • JetBrains Rider · WriterSide (일부)
  • AvaloniaUI 자체 데모와 사이트
  • 다양한 게임 개발 도구

16.3 평가

  • WPF 경험자에게 가장 자연스러운 마이그레이션 경로
  • .NET 진영의 진짜 크로스플랫폼 UI 답
  • MAUI보다 더 데스크톱에 친화적(MAUI는 모바일 우선)

17장 · .NET MAUI 9 - Microsoft 공식

17.1 출신과 현재

MAUI(Multi-platform App UI)는 2022년 Microsoft가 Xamarin.Forms의 후속으로 출시한 .NET 크로스플랫폼 프레임워크다. 2024년 11월 .NET 9와 함께 MAUI 9 라인이 나왔다.

17.2 평가

  • 모바일 우선 설계 - 데스크톱은 Windows + macOS만(Linux 없음)
  • WPF/WinForms 팀의 진화 경로
  • Linux 데스크톱을 무시하기 때문에 진짜 크로스플랫폼이 아니라고 평가받는 경우도

18장 · SwiftUI on macOS + Mac Catalyst

18.1 SwiftUI

Apple이 2019년 WWDC에서 발표한 선언적 UI 프레임워크. 2026년 시점에서 macOS 15 Sequoia 이후 데스크톱에서도 1급 시민. App Store에서 가장 자연스러운 macOS 앱은 모두 SwiftUI다.

18.2 Mac Catalyst

iPad 앱을 거의 그대로 macOS에서 돌리는 호환 레이어. 2019년 도입. 동작은 하지만 진짜 macOS 네이티브 룩이 아니라 "iPad가 큰 화면에서 돈다" 느낌이 강하다.

18.3 평가

  • macOS 단독이라면 SwiftUI가 정답
  • 크로스플랫폼이 필요하면 SwiftUI는 후보가 아니다 - Windows/Linux 없음

19장 · Comet과 Lynx - 2025~2026 신규 진영

19.1 Comet

Comet은 전 Plasmic 팀이 2025년에 발표한 데스크톱 빌더로, 컴포넌트 마켓플레이스 + 코드 출력 + 다양한 백엔드 통합을 묶은 도구다. 2026년 시점에서 베타 후반. "디자이너가 코드 없이 시작, 개발자가 진짜 코드로 이어 받는" 워크플로를 노린다.

19.2 Lynx

TikTok 모기업 ByteDance가 2025년 3월에 오픈소스로 공개한 크로스플랫폼 프레임워크다. React Native와 비슷한 컨셉이지만 데스크톱까지 1차 표면으로 포함한다. 내부적으로는 ByteDance가 자사 앱 일부에 쓰고 있고, 외부에서도 채택이 늘어나는 중.


20장 · NW.js - 클래식 Electron 대안

NW.js(과거 Node-webkit)는 2011년 Roger Wang이 인텔에서 시작한 데스크톱 프레임워크다. Electron의 형제격이며 컨셉이 거의 같지만, NW.js는 노드와 Chromium의 통합 방식이 다르다. 2026년에 새 프로젝트가 NW.js를 고르는 일은 드물지만, 일부 중국 데스크톱 게임 런처가 여전히 쓴다.


21장 · 번들 크기 한눈에 보기

도구빈 앱 디스크빈 앱 메모리시작 시간
Sciter5MB 이하30~60MB0.3초
NeutralinoJS2~5MB40~80MB0.4초
Tauri 210~15MB50~100MB0.5초
Wails 315~25MB60~120MB0.6초
Flutter Desktop30~50MB100~150MB0.7초
Slint5~15MB40~80MB0.3초
Iced10~20MB50~100MB0.4초
egui5~10MB40~80MB0.3초
Avalonia30~60MB80~140MB0.8초
Electron 34150~300MB100~250MB1~3초
Qt 6.8 (LGPL 동적)20~40MB + Qt 런타임60~120MB0.5초

22장 · 네이티브 API 접근 - 어디까지 닿는가

데스크톱 앱이 진짜 가치를 내려면 OS와 깊이 통합되어야 한다.

22.1 자주 필요한 시스템 통합

  • 파일 시스템 다이얼로그(열기 · 저장)
  • 시스템 트레이/메뉴바 아이콘
  • 알림(macOS Notification Center, Windows Action Center, Linux libnotify)
  • 딥링크(myapp:// 같은 URL 스킴 핸들러 - 본문에서 별도 표기는 inline code 권장)
  • 클립보드(텍스트 · 이미지 · 커스텀 포맷)
  • 전역 단축키
  • 자동 시작
  • 윈도 데코레이션 커스터마이징

22.2 진영별 성숙도

  • Electron: 가장 완성. dialog, Tray, Notification, globalShortcut, protocol API가 13년간 다듬어졌다.
  • Tauri 2: 거의 동등. v2부터 mobile API까지 합쳐 더 넓어졌다.
  • Wails 3: 핵심 통합은 다 되지만 일부 엣지케이스는 부족.
  • Flutter Desktop: 기본 시스템 통합은 있지만 깊이는 Electron보다 얕다. system_tray, window_manager 같은 커뮤니티 패키지가 도와준다.
  • Qt: 매우 강함. 25년 노하우.

22.3 inline code 권장 패턴

WebView 임베드 태그 같은 것 - inline 백틱으로 감싸서 표기한다. 본문에서는 <webview> 같은 태그를 쓰지 않고 백틱 안에서만 다룬다. 윈도 객체나 <window> 같은 표기 역시 inline code로만.


23장 · 코드 서명과 공증 - 진짜 배포의 관문

23.1 macOS

  • Developer ID 인증서 (Apple Developer Program 연 99달러)
  • 코드 서명 + Notarization(공증) 의무화 (macOS 10.15부터)
  • Sparkle 자동 업데이트 또는 electron-updater

23.2 Windows

  • Authenticode 인증서 (1년 약 300달러부터)
  • EV(Extended Validation) 인증서는 1500달러+ - SmartScreen 평판이 더 빨리 쌓임
  • electron-builder · NSIS · Squirrel.Windows · Inno Setup

23.3 Linux

  • Flatpak (Flathub)
  • Snap (Canonical)
  • AppImage
  • deb (Debian/Ubuntu)
  • rpm (Fedora/SUSE)

23.4 2026년 트렌드

GitHub Actions가 빌드/서명/배포의 표준 파이프라인이 됐다. Tauri Action · electron-builder Action · flutter-action - 워크플로 템플릿이 5분 안에 적용된다.


24장 · 자동 업데이트 시스템

24.1 Squirrel(.Windows/.Mac)

Atom 시절부터 있는 클래식 업데이터. Electron이 기본 채택. 델타 업데이트 지원.

24.2 electron-updater (electron-builder의 일부)

GitHub Releases · S3 · 커스텀 서버에서 업데이트를 받아온다. 가장 많이 쓰이는 Electron 업데이터.

24.3 Tauri Updater

Tauri의 공식 업데이터. minisign으로 패키지 서명 검증.

24.4 Sparkle (macOS)

Andy Matuschak이 2006년부터 만든 macOS 전용 업데이터. 거의 모든 macOS 네이티브 앱이 쓴다.

24.5 Google Omaha / omaha-server

Google Chrome이 쓰는 업데이트 서버. 오픈소스 omaha-server로 자가 호스팅 가능.


25장 · 한국과 일본의 데스크톱 앱 풍경

25.1 한국

  • 카카오톡 데스크톱: Electron 기반. 2026년에도 가장 많이 깔린 한국 데스크톱 앱.
  • 네이버 웨일: 자체 Chromium 포크 브라우저 + 웨일 윈터 모드.
  • 잔디 데스크톱(Toss/Jandi): Electron.
  • 노션 한국: 본가 Electron 그대로.
  • 라인 데스크톱: Electron 기반(LINE은 일본 NHN이지만 한국에서도 많이 씀).

25.2 일본

  • GitMind 데스크톱: 마인드맵 도구. Electron.
  • Cybozu Office 데스크톱 클라이언트: 일본 기업 협업의 표준. Electron.
  • Backlog Desktop: Nulab의 프로젝트 관리 앱. Electron.
  • 라쿠텐 라쿠라쿠 메일: 데스크톱 메일 클라이언트.
  • Money Forward 데스크톱: 가계부.
  • SmartHR 일부 모듈: Flutter Desktop 실험 중.

26장 · 하이브리드 패턴 - WebView를 네이티브 안에 끼우기

크로스플랫폼이 아니라 단일 OS 네이티브를 쓰면서, 특정 화면만 웹뷰로 처리하는 패턴도 흔하다.

26.1 Windows

  • WPF + WebView2: WPF 앱에서 특정 페이지만 Chromium Edge 임베드
  • WinForms + WebView2
  • WinUI 3 + WebView2

26.2 macOS / iOS

  • AppKit + WKWebView
  • UIKit + WKWebView
  • SwiftUI + WKWebView 래퍼(WebView 컴포넌트가 정식화되는 중)

26.3 사용 예

  • 한국의 카카오뱅크 데스크톱 일부 - WPF 베이스에 WebView2 임베드
  • 일본 라쿠텐 일부 데스크톱 도구 - 네이티브 + 웹뷰 혼용
  • 1Password 8 일부 화면 - 본체는 Electron이지만 결제/구독 화면만 외부 웹

27장 · 결정 매트릭스 - 5가지 질문으로 좁히기

27.1 질문 1 - 팀의 주력 언어는 무엇인가

  • TypeScript/JavaScript → Electron · Tauri · Wails · NeutralinoJS
  • Rust → Tauri · Slint · Iced · egui
  • Go → Wails
  • Dart → Flutter Desktop
  • C# → MAUI · Avalonia · WPF
  • Java/Kotlin → JavaFX · Compose Multiplatform
  • Swift → SwiftUI on macOS

27.2 질문 2 - 모바일도 같은 코드베이스여야 하는가

  • 필수 → Tauri 2 · Flutter · Compose Multiplatform · MAUI · Lynx · React Native
  • 불필요 → 다른 후보 모두

27.3 질문 3 - 번들 크기가 얼마나 중요한가

  • 매우 중요(20MB 미만) → Tauri · Wails · NeutralinoJS · Slint · Sciter
  • 중간(50MB 이하) → Flutter · Avalonia
  • 무관(150MB+) → Electron

27.4 질문 4 - Linux 데스크톱이 1급 시민인가

  • 필수 → Electron · Tauri · Wails · Flutter · Qt · GTK · Avalonia
  • 불필요(Windows + macOS만) → MAUI 가능

27.5 질문 5 - 라이선스 제약은

  • 완전 MIT/Apache 원함 → Electron · Tauri · Wails · NeutralinoJS · Flutter · Iced · egui · Avalonia
  • LGPL OK → Qt (동적 링킹)
  • GPL OK → Slint (또는 상업 라이선스)
  • 상업 라이선스 사도 됨 → Sciter · Slint · Qt

28장 · 안티패턴과 함정

28.1 "Electron이니까 무거워도 괜찮다"

거꾸로다. Electron이라도 가벼울 수 있다. VS Code가 그렇다. ASAR 패키징, 모듈 lazy 로딩, V8 스냅샷, 가상 스크롤 - 최적화 기법이 있다. Electron 선택이 "최적화 포기"의 면죄부가 되면 안 된다.

28.2 "Tauri로 바꾸면 메모리가 1/3이 된다"

진실 반, 거짓 반. Tauri는 빈 앱이 1/3이다. 그러나 실제 앱이 Chromium 기능을 많이 쓰면(WebGL · 코덱 · DRM), 시스템 웹뷰가 그것을 다 지원하지 않거나 다르게 동작한다. 마이그레이션 비용이 메모리 절감을 압도할 수 있다.

28.3 "Flutter Desktop은 모바일이랑 같으니까 무료"

UI 코드는 같다. 그러나 시스템 통합 코드(트레이 · 메뉴바 · 단축키 · 윈도 관리)는 전부 새로 짜야 한다. "코드 90% 공유"는 진실이지만, 그 10%가 데스크톱 경험을 만든다.

28.4 "Qt가 무료지 않다"는 오해

Qt는 LGPL 동적 링킹이면 무료다. 상업 라이선스가 필요한 경우는 정적 링킹이나 모바일/임베디드 같은 특수 케이스다. Qt 라이선스 두려움이 합리적인 도구를 막으면 안 된다.

28.5 "새 도구가 무조건 낫다"

Slint · Iced · Xilem · Lynx - 흥미롭지만 production 위험이 있다. 시제품과 사이드 프로젝트라면 좋다. 미션 크리티컬 프로덕트라면 5년 차 이상의 도구가 안전하다.


29장 · 실제 마이그레이션 사례 - 무엇이 잘 되고 무엇이 어려운가

29.1 Linear 데스크톱 - Electron에서 Tauri 평가

Linear는 2024년에 Tauri 마이그레이션을 평가했다고 알려져 있다. 결과는 "당장은 Electron 유지". 이유는 macOS Apple Silicon에서 Electron이 의외로 잘 돌고, 마이그레이션 인력이 크다는 것.

29.2 카카오톡 데스크톱

오랫동안 자체 C++ 클라이언트였다가 2020년대 초반 Electron 기반으로 전환. 결과는 양면적 - UI 업데이트가 빨라졌지만 메모리 사용이 커졌다는 사용자 불만이 많아졌다.

29.3 Cap 스크린 레코더

처음부터 Tauri 2로 시작. 빌드 크기 12MB, Apple Silicon에서 가벼움. Tauri의 모범 사례 중 하나.

29.4 1Password 7 → 8

1Password는 7에서 네이티브였다가 8에서 Electron 기반으로 바꿨다. 코드 공유와 기능 속도를 위한 결정이었지만, 일부 macOS 사용자가 "예전이 더 좋았다"고 불평. Electron의 가격을 분명히 보여준 사례.


30장 · 결론 - "당신의 1순위"는 무엇인가

5분 의사결정 가이드:

  1. 팀 언어가 가장 강한 필터: 언어가 정해지면 후보가 절반 이하로 줄어든다.
  2. 모바일 동반 여부가 두 번째 필터: 동반이 필수면 Tauri 2 · Flutter · Compose · MAUI · Lynx로 좁아진다.
  3. 번들 크기 / 메모리 천장이 세 번째 필터: 사용자가 저사양 PC가 많다면 Electron은 마지막 후보.
  4. 시스템 통합 깊이가 네 번째 필터: 트레이 · 알림 · 단축키 · 메뉴바가 모두 1급이어야 하면 Electron · Tauri · Qt.
  5. 라이선스 + 자금이 다섯 번째 필터: 회사 상황에 따라 Sciter나 Qt 상업 라이선스가 합리적일 수 있다.

이 다섯 질문으로 후보가 1~3개로 줄어든다. 그 다음은 30분짜리 PoC로 결정 - 정말 시작 시간, 빌드 속도, 패키징 단순함이 약속한 만큼 좋은지 직접 확인한다.

"최고의 크로스플랫폼 데스크톱 프레임워크는 무엇인가"는 잘못된 질문이다. "우리 팀에게 합리적인 도구 3개는 무엇인가"가 진짜 질문이고, 이 글은 그 답을 빠르게 찾는 지도다.


References