데스크톱 앱 프레임워크 2026 — Tauri · Electron · Wails · Compose · MAUI · Flutter · Qt · Slint 카테고리 전수 비교

프롤로그 — "데스크톱은 죽었다"는 말은 틀렸다

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

그래서 "데스크톱 앱을 어떻게 만들 것인가"는 다시 뜨거운 질문이다. 선택지가 너무 많아서 더 뜨겁다. Electron · Tauri · Wails · Neutralino · Compose Multiplatform · .NET MAUI · Flutter 데스크톱 · Qt/PySide · Slint · Lazarus · GTK + 다양한 바인딩 — 카테고리 안에 11개가 살아 있고, 각자 다른 트레이드오프를 고집한다.

이 글은 그 카테고리 전체를 한 화면에 놓는다. 한 달 전에 쓴 "Tauri 2 vs Electron 단일 비교" 글이 있지만, 그것은 두 프레임워크 사이의 결투였다. 이 글은 그보다 넓은 지도다 — 웹 기술 vs 네이티브 기술의 진영 차이, 단일 OS vs 멀티 OS의 야망, 팀 언어가 만드는 자연선택, 그리고 "Linear/Cursor/Bitwarden/Affinity는 왜 다 다른 도구를 골랐는가"의 답.

핵심 한 줄: "최고의 데스크톱 프레임워크"는 없다. 팀 언어, 타깃 OS, 성능 요구, 번들 예산 네 축이 교차하는 지점에 "당신에게 가장 적합한 도구"가 있다. 그 교차점을 빠르게 찾는 것이 이 글의 목표다.

---

1장 · 진짜 선택 축은 무엇인가

프레임워크 비교 글이 종종 실패하는 이유는 "어떤 것이 더 좋다"는 1차원 비교에 매달리기 때문이다. 데스크톱 프레임워크의 실제 선택은 최소 4차원이다.

1.1 네이티브 vs 웹뷰 렌더링

UI를 어떻게 그리느냐가 첫 번째 분기점이다.

• 웹뷰 기반: HTML/CSS/JS로 그리고, OS의 웹뷰(Chromium · WebView2 · WebKit) 또는 번들된 Chromium이 픽셀을 찍는다. Electron · Tauri · Wails · Neutralino가 여기에 속한다.
• 네이티브 렌더링: OS의 네이티브 위젯(Win32 · Cocoa · GTK)이나 자체 렌더러(Skia · Qt 자체 엔진)가 픽셀을 찍는다. Qt · Compose · MAUI · Flutter · Slint · Lazarus가 여기에 속한다.

웹뷰는 웹 개발자 풀을 그대로 쓸 수 있고 UI 변경이 빠르다. 네이티브는 시작 시간 · 메모리 · 키보드 단축키 · 접근성 · 트레이 통합에서 우위다. "둘 다 한다"는 도구는 없다 — 골라야 한다.

1.2 팀 언어가 만드는 자연선택

장기적으로 가장 강한 힘은 "팀이 이미 쓰는 언어"다.

• TypeScript/JavaScript 팀 → Electron · Tauri · Wails(프런트는 웹) · Neutralino · React Native macOS/Windows
• Rust 팀 → Tauri · Slint · gtk-rs · Iced · egui
• Go 팀 → Wails · Fyne · gioui
• C# 팀 → .NET MAUI · WinUI 3 · Avalonia · Uno Platform
• Kotlin/Java 팀 → Compose Multiplatform · JavaFX · Swing(레거시)
• Dart 팀 → Flutter 데스크톱
• C++/Python 팀 → Qt · PySide · wxWidgets
• Pascal 팀 → Lazarus / Free Pascal

언어를 바꾸면 채용도 도구도 빌드 파이프라인도 다 바뀐다. 그래서 "기존 팀이 1주일 안에 빌드를 돌릴 수 있는가"가 사실상 가장 강한 필터다.

1.3 타깃 플랫폼의 범위

• Windows만 → WinUI 3 · WPF · Win32(레거시). 가장 좁고 가장 빠르다.
• macOS만 → SwiftUI · AppKit. App Store 인증, 시스템 API 친화.
• 데스크톱 3종(Win/macOS/Linux) → Electron · Tauri · Wails · Qt · Compose · Flutter · MAUI(Linux는 약함).
• 데스크톱 + 모바일 → Tauri 2 · Flutter · Compose Multiplatform · MAUI · React Native + Capacitor.
• 임베디드까지 → Slint · Qt · LVGL(전혀 다른 영역).

"데스크톱과 모바일 동시 출시"가 요구사항이면 후보가 좁아진다. Tauri 2, Flutter, Compose Multiplatform, MAUI 정도다.

1.4 번들 크기 vs 성능 천장 vs 일관성

서로 트레이드오프되는 세 가지를 동시에 만족시키는 도구는 없다.

이 매트릭스가 첫 번째 화살표다. "우리는 무엇을 가장 중요하게 보는가" — 이 한 질문이 후보군을 3개 이하로 줄인다.

---

2장 · 웹 기술 진영 — Chromium의 짐을 짊어진 자들

웹뷰를 쓰는 4종을 같은 자리에 놓고 비교한다.

2.1 Electron — 여전히 코끼리

Electron은 2013년 GitHub Atom 에디터에서 시작했다. 그 시점부터 13년이 지난 2026년에도 데스크톱 앱 시장에서 가장 많이 쓰이는 프레임워크다. VS Code · Discord · Slack · Notion · Postman · 1Password · Obsidian · Linear · Figma 데스크톱 — 이 9개 중 8개가 Electron이다(Linear는 Tauri 평가 중이라고 알려져 있다).

장점:

• 성숙도: 13년의 버그 수정, 13년의 패키지, 13년의 StackOverflow.
• 호환성: Chromium을 통째로 들고 다니니까 어디서나 똑같이 보인다. CSS · WebGL · WebRTC · Service Worker · 코덱 전부 동일.
• 거대한 생태계: electron-builder · electron-forge · spectron · auto-updater — 회사용 수준의 도구가 즐비.

단점:

• 번들 크기: 150~300MB. 디스코드 90MB는 압축본이고 디스크에 200MB+가 풀린다.
• 메모리: Chromium 사본이 통째로 메모리에 올라온다. 빈 앱이 100MB.
• 시작 시간: Chromium 초기화 + V8 부팅 = 1~3초.

2026년 Electron은 v33~34 라인이고, Chromium 130대를 따라가고 있다. 안정적인 분기 릴리스, ASAR 패키징, 새로운 macOS 코드 서명 통합이 들어왔다.

2.2 Tauri 2 — 시스템 웹뷰 진영의 1위

2024년 10월 Tauri 2.0 GA 이후 1년 반이 지났다. 2026년 현재 Tauri는 시스템 웹뷰 진영에서 가장 큰 점유율을 가진다. Slack 같은 빅테크는 안 옮겨왔지만, 새 프로젝트의 30~40%가 Tauri를 고른다는 통계(불완전하지만)가 있다.

핵심 차별점:

• 시스템 웹뷰 사용: Windows는 WebView2(Edge), macOS는 WKWebView(Safari), Linux는 WebKitGTK. Chromium을 번들하지 않는다.
• 번들 크기: 10~40MB. Electron의 1/10.
• Rust 코어: 백엔드 명령은 Rust로 작성. IPC 경계가 명확.
• 모바일 지원: 2.0부터 iOS · Android. 단 모바일은 아직 1.x 데스크톱만큼 성숙하지 않다.

진짜 그늘:

• 웹뷰 파편화: Linux의 WebKitGTK는 Windows의 Edge/Chromium보다 한참 뒤처진다. CSS 신기능, 코덱, JS 엔진 모두.
• Rust 학습 곡선: 백엔드를 Rust로 짜야 하는 순간이 온다. 프런트엔드 팀에게 부담.
• 생태계 깊이: Electron 13년치 패키지를 따라잡지 못한다.

자세한 비교는 이전 글 "Tauri 2 vs Electron 단독 비교"에 있다 — 이 글에서는 카테고리 안의 한 선수로 다룬다.

2.3 Wails — Go의 답

Wails는 Go로 백엔드를 짜고 프런트엔드는 웹 기술을 쓰는 프레임워크다. Tauri의 Go 버전이라고 부르는 사람도 있지만, 차이는 분명하다.

• 언어: Tauri는 Rust, Wails는 Go. Go의 빌드 속도와 단순함이 강점.
• 시스템 웹뷰: Wails도 Tauri와 같은 전략. WebView2 · WKWebView · WebKitGTK.
• 2026 버전: Wails v2가 안정, v3가 알파/베타. v3는 다중 윈도우, 새 메뉴 API, 더 좋은 IPC.
• 번들: 10~30MB, Tauri와 비슷.

Go 팀에게는 자연스러운 선택이다. 백엔드 인프라가 Go로 짜여 있고, 같은 언어로 데스크톱 클라이언트를 짜고 싶다면 Wails다.

2.4 Neutralino — 가장 가벼운 옵션

Neutralino는 Node.js조차 번들하지 않는다. C++ 기반의 작은 런타임만 띄우고, JS 코드는 웹뷰가 직접 실행한다.

• 번들: 2~5MB. 카테고리 최소.
• 백엔드: 별도 백엔드 언어가 없다. 시스템 API는 Neutralino가 제공하는 JS 함수로 호출.
• 타깃: Win/macOS/Linux/Chrome OS.

진짜 가볍지만, 백엔드 무게가 필요한 앱(파일 인덱싱, 암호화, 로컬 DB)에는 어색하다. 작은 도구나 시스템 트레이 유틸리티에 적합.

2.5 웹 진영 비교

---

3장 · 네이티브 기술 진영 — 픽셀을 직접 그리는 자들

웹뷰를 안 쓰고 자체 렌더러나 OS 네이티브 위젯으로 그리는 도구들. 이 진영은 성능 천장이 높고 시작이 빠르지만, 학습 곡선이 가파르다.

3.1 Qt / PySide — 30년 묵은 거인

Qt는 1991년에 시작했다. 35년차. C++로 짜여 있고, Python 바인딩(PySide6, PyQt6)이 있다. 데스크톱 네이티브 진영의 사실상 1위.

사용 예: Affinity Photo/Designer/Publisher(전부 Qt), VirtualBox, KDE 데스크톱 환경 전체, Tesla 차량 클러스터 UI, 어도비 Substance Painter 일부, Maya 인터페이스, OBS Studio.

장점:

• 성숙도: 35년. 모든 OS, 임베디드, 모바일까지.
• 위젯 라이브러리: Qt Widgets · Qt Quick(QML) · Qt 3D — 어떤 UI도 만들 수 있다.
• 성능: 자체 렌더러. CPU/GPU 가속 모두 가능.
• 상업 지원: The Qt Company의 유료 라이선스 + LTS.

단점:

• 라이선스: GPL/LGPL/상업 듀얼. 상업 라이선스는 1인당 연 수천 달러.
• C++ 진입 장벽: PySide로 우회 가능하지만 UI 빌드는 결국 Qt 위젯 패러다임.
• 번들 크기: 30~80MB, 동적 링킹시 더 작음.

2026년 Qt 6.8 LTS 시점. QML이 점점 표준, Qt for Python(PySide6)이 안정.

3.2 Compose Multiplatform — JetBrains의 답

JetBrains가 Kotlin Multiplatform 위에 만든 UI 프레임워크. 안드로이드의 Jetpack Compose를 데스크톱과 iOS까지 확장한다. 2024~2025년 데스크톱 안정 GA, iOS는 베타에서 안정으로 이행 중.

장점:

• 언어: Kotlin. Android 개발자가 그대로 데스크톱으로 옮길 수 있다.
• 선언형 UI: React 같은 패러다임. UI = 함수.
• 렌더러: Skia 기반. 모든 OS에서 같은 픽셀.
• JetBrains 자체 사용 예: IntelliJ 일부, Toolbox.

단점:

• JVM 의존: 런타임 번들 시 50~150MB. GraalVM 네이티브 이미지로 줄이는 길이 있지만 까다롭다.
• 데스크톱 위젯 자연스러움 약함: Material 디자인 기본. 데스크톱 네이티브 룩이 약함.
• iOS는 아직 베타: 데스크톱만큼 성숙하지 않다.

Kotlin 팀에게는 의심할 여지 없는 선택. 다른 팀에게는 채용 난이도가 변수.

3.3 .NET MAUI — Xamarin의 후계

Microsoft가 Xamarin.Forms의 후속으로 만든 크로스 플랫폼 UI 프레임워크. 2022년 GA, 2023~2024년에 안정성 확보, 2025년부터 본격 채택.

장점:

• 언어: C#. Microsoft 생태계 깊이.
• 타깃: Windows · macOS · iOS · Android. (Linux는 공식 미지원, 커뮤니티 백엔드 있음.)
• XAML UI: WPF 출신 개발자 친화.
• Visual Studio: 디버깅/디자인 통합.

단점:

• macOS 지원 약함: Mac Catalyst를 통한 우회, 네이티브가 아님.
• Linux 미지원: 데스크톱 3종을 다 노릴 수 없다.
• 버그 안정화 시간: GA 후 2~3년간 베타 같은 시기.

Windows 중심 + 모바일 동시 출시가 목표이면 합리적. Linux 데스크톱 사용자가 중요하면 탈락.

3.4 Flutter 데스크톱 — Google의 야망

Flutter는 모바일에서 시작해 데스크톱까지 확장했다. 2022년 데스크톱 안정, 2023년부터 진지하게 받아들여지기 시작.

장점:

• 단일 코드베이스: iOS · Android · Web · Windows · macOS · Linux 전부.
• Skia 렌더러: 픽셀 단위 일관성.
• 개발 속도: Hot Reload, 강력한 위젯 라이브러리.
• Dart 언어: 학습 곡선 낮음, AOT 컴파일.

단점:

• 데스크톱 UX 어색함: 모바일에서 출발해서 데스크톱 단축키, 메뉴 바, 다중 윈도우가 약하다.
• 번들 크기: 30~80MB. 작지 않다.
• 데스크톱 패키지 부족: 모바일에 비해 데스크톱용 플러그인이 적다.

사용 예: BMW의 차량 인포테인먼트, 일부 사내 도구. 본격적인 컨슈머 데스크톱 앱은 아직 적다.

3.5 Slint — Rust 네이티브 UI

Slint는 Rust(과거 SixtyFPS)로 짜인 네이티브 UI 프레임워크. 2024년 1.0, 2025~2026년 1.x 안정화. 임베디드와 데스크톱 양쪽을 노린다.

장점:

• 번들: 1~5MB. 카테고리 최소급.
• 성능: 60fps 60FPS 보장, GPU 가속.
• Slint 언어: 자체 DSL로 UI를 선언. Rust/C++/JS와 바인딩.
• 임베디드 친화: 미세 RAM 환경에서도 작동.

단점:

• 생태계 작음: Qt의 1/100.
• 라이선스: GPL/Royalty-Free/Ambassador/Commercial. 상업 사용은 라이선스 협의.
• 위젯 빈약: 풍부한 위젯 라이브러리는 아직.

작은 데스크톱 도구, 임베디드 UI, 또는 Rust 일관성을 원하는 팀에게 적합.

3.6 Lazarus / Free Pascal — 살아남은 자

Pascal로 짠 Delphi의 오픈소스 후예. 1999년 시작. 2026년에도 활발히 개발 중.

장점:

• 단일 바이너리: 5~15MB, 의존성 없음.
• 속도: 네이티브 컴파일, 시작 즉시.
• 호환성: Delphi 코드 거의 그대로 빌드.
• 모든 OS: Win · macOS · Linux · BSD.

단점:

• Pascal 채용 어려움: 신규 인력이 적다.
• UI 트렌드 뒤처짐: VCL 계열, 현대적 디자인 시스템 부족.
• 커뮤니티 작음: 활발하지만 작다.

레거시 Delphi 코드를 이식하거나, 작은 데스크톱 도구, 또는 Pascal 팀이 있다면 합리적.

3.7 GTK + 바인딩 (gtk-rs · Vala · PyGObject)

GTK는 GIMP에서 출발한 GNOME의 위젯 라이브러리. 30년 묵었다. Rust 바인딩(gtk-rs), Vala, Python(PyGObject) 등 다양한 언어로 쓸 수 있다.

장점:

• GNOME 통합: Linux에서 네이티브 룩.
• 작은 번들: GTK가 시스템에 깔려 있다면 더 작음.
• 다양한 바인딩: Rust · Vala · Python · C.

단점:

• macOS/Windows 어색함: 룩앤필이 그 OS에 맞지 않는다.
• GTK4 마이그레이션 진행 중: GTK3에서 GTK4로 옮기는 중이라 생태계가 혼란.

리눅스 우선 도구라면 자연스러운 선택. 크로스 플랫폼은 어색.

3.8 그 외 카테고리

• Avalonia (.NET): WPF 비슷한 XAML, 크로스 플랫폼. MAUI보다 Linux 지원이 좋다.
• Uno Platform (.NET): WinUI XAML을 모든 OS로. WebAssembly까지.
• Iced/egui (Rust): 작은 도구용 Rust UI.
• Fyne/gioui (Go): Go 진영의 네이티브 UI.
• wxWidgets: C++ 기반, OS 네이티브 위젯 래핑.

이 카테고리에 들어가는 후보가 너무 많아서 다 다루지 못한다. 위 12개 정도가 2026년에 진지하게 검토할 만한 도구다.

---

4장 · 결정 매트릭스 — 어디가 누구에게 맞는가

11개 후보를 4축에 놓고 시각화하면 다음과 같다.

읽는 법: "팀이 쓸 줄 아는 언어" 한 열, "타깃 OS" 한 열을 골라서 교차점이 비어 있지 않은 행이 후보다. 보통 2~3개로 좁혀진다.

---

5장 · 실제 사례 — 큰 앱들은 무엇을 골랐는가

5.1 VS Code · Cursor · Windsurf · Zed

• VS Code: Electron. Code OSS 베이스. Microsoft가 자체적으로 매우 무거운 최적화.
• Cursor: Electron + VS Code OSS 포크. Electron을 골랐다기보다 VS Code 코드베이스를 그대로 쓰는 선택.
• Windsurf (Codeium): Electron + VS Code OSS 포크. 같은 이유.
• Zed: 자체 Rust + GPUI 프레임워크. Electron을 거부하고 처음부터 자체 GPU 가속 UI를 짰다.

교훈: VS Code 코드베이스를 재사용하면 Electron이 필연. 처음부터 짜면 자유.

5.2 Discord · Slack · Teams

• Discord: Electron. 13년 전부터.
• Slack: Electron. macOS 전용 네이티브 시도(2020~2021)는 실패하고 Electron으로 복귀.
• Teams: Electron + WebView2. 마이크로소프트가 React Native 데스크톱으로 옮긴다는 소문이 있었지만 결국 안 옮겼다.

교훈: 큰 회사의 큰 앱은 마이그레이션 비용이 너무 크다. 일단 Electron이면 계속 Electron.

5.3 1Password · Bitwarden

• 1Password: 8.x 버전부터 Electron. (이전 7.x는 네이티브.)
• Bitwarden: Electron 데스크톱 + 웹 vault + 네이티브 모바일.

교훈: 보안 앱조차 Electron을 골랐다. 호환성과 개발 속도가 보안 인식보다 무겁다.

5.4 Linear · Figma · Notion

• Linear: Electron 데스크톱. Tauri 평가 중이라는 이야기가 2025년에 있었다. 결과는 미정.
• Figma 데스크톱: Electron 래퍼. 본질은 웹 앱.
• Notion: Electron 데스크톱 + Notion Calendar(과거 Cron)도 Electron.

교훈: 웹 우선 회사들은 Electron이 자연스럽다. 같은 코드를 그대로 데스크톱에.

5.5 Affinity · Adobe · DaVinci

• Affinity Photo/Designer/Publisher: Qt. 모든 OS 동일 코드베이스.
• Adobe: 자체 C++ 프레임워크. (각 앱마다 다름. Photoshop은 자체, 일부는 CEF/Electron.)
• DaVinci Resolve: 자체 C++ + Qt 일부.

교훈: 픽셀 성능이 중요한 그래픽 도구는 Qt나 자체 네이티브를 고집.

5.6 OBS · Reaper · Audacity

• OBS Studio: Qt.
• Reaper: 자체 C++ 프레임워크 (WDL/IPlug). 극단적으로 작은 번들과 빠른 시작.
• Audacity: wxWidgets.

교훈: 미디어 도구는 성능/지연 시간 때문에 네이티브 진영을 고른다.

5.7 새로운 앱들의 선택

• Linear Insights · Granola (2024~2025): Tauri 검토.
• Warp Terminal: 자체 Rust + Metal/Vulkan.
• Raycast: macOS 네이티브 Swift.
• Mailtrap의 사내 도구: Tauri.
• SilentKeys · Voxly: Tauri로 처음부터.

교훈: 2024년 이후 새 프로젝트는 Tauri를 진지하게 검토한다. 큰 회사 큰 앱은 안 옮긴다.

---

6장 · 타깃 플랫폼별 고려사항

6.1 Windows만 노린다면

• WinUI 3 + .NET: Microsoft 1차 권장. 네이티브 룩, 빠른 시작, 작은 번들.
• WPF: 레거시지만 안정. 큰 기업 내부 도구의 표준.
• Win32 + C++: 극단적 성능. Office, AutoCAD 같은 거인.
• Avalonia: WPF 비슷하면서 크로스 플랫폼 옵션 열어둠.

Windows 전용이면 Electron/Tauri는 사실 과한 선택이다.

6.2 macOS만 노린다면

• SwiftUI: 2026년에는 거의 성숙. macOS 13+ 타깃이면 자연스러움.
• AppKit: 전통. SwiftUI에서 누락된 API가 있을 때 보완.
• Catalyst: iPad 앱을 mac으로. 결과물의 macOS 자연스러움은 미묘.

macOS App Store, 코드 서명, 노타리제이션을 진지하게 통과하려면 네이티브 진영이 편하다.

6.3 Linux만 노린다면

• GTK + Rust/Vala: GNOME 환경에 가장 자연스러움.
• Qt: KDE와 친화. Linux에서도 가장 안정적인 크로스 데스크톱 환경.
• Flutter: 가능하지만 Linux 패키징은 거칠다.

Linux는 패키징(deb · rpm · flatpak · snap · AppImage)이 별도 일거리다.

6.4 데스크톱 3종 + 모바일

데스크톱과 모바일 동시 출시를 진지하게 노린다면 후보는 좁다.

• Tauri 2: 한 코드베이스, 모바일은 별도 모듈, 웹뷰 일관성.
• Flutter: 진짜 단일 코드베이스. 데스크톱 어색함은 감수.
• Compose MP: Kotlin 진영. 데스크톱과 안드로이드 자연스러움.
• MAUI: Windows 중심 + 모바일. macOS는 Catalyst.
• React Native + Capacitor 조합: 모바일 RN + 데스크톱 Capacitor/Electron.

어느 것도 완벽하지 않다. "어디서 데스크톱이 더 중요한가, 어디서 모바일이 더 중요한가"를 솔직히 답하면 선택이 좁혀진다.

---

7장 · 미래에 거는 베팅 — 2026 이후

7.1 시스템 웹뷰의 일관성 개선

WebView2(Windows)와 WKWebView(macOS)는 점점 안정화되고 있다. 문제는 Linux의 WebKitGTK다. Linux의 시스템 웹뷰가 Chromium 수준으로 좋아지지 않으면 Tauri/Wails는 영원히 Linux에서 약점을 안고 간다.

대안 시도: Servo(Rust 브라우저 엔진)를 Tauri가 임베드한다는 RFC가 2025년에 나왔다. 진행은 느리다.

7.2 Compose Multiplatform iOS의 안정화

2026년 후반에 안정 GA 예상. 안정화되면 Kotlin 한 언어로 데스크톱 + 모바일을 다 노릴 수 있다. Flutter의 강력한 경쟁자.

7.3 Flutter의 데스크톱 UX 보강

데스크톱 단축키, 메뉴, 다중 윈도우 API가 2025~2026년에 빠르게 채워지고 있다. 진지한 데스크톱 앱이 Flutter를 채택할 가능성이 늘고 있다.

7.4 Rust 네이티브 UI 진영의 성장

Slint, egui, Iced, GPUI(Zed의 프레임워크) — Rust로 짠 네이티브 UI 프레임워크가 늘고 있다. 작은 도구와 성능 우선 앱에서 점유율이 커질 것.

7.5 AI 통합이 데스크톱 르네상스를 부추긴다

코딩 에이전트, 음성 비서, 로컬 LLM 도구 — 모두 데스크톱에서 가장 잘 작동한다. 데스크톱 프레임워크 카테고리는 향후 5년 동안 더 활발해질 것이다.

---

에필로그 — 선택 체크리스트와 안티패턴

선택 전 체크리스트

• 팀의 1차 언어는 무엇인가 — 그 언어 진영부터 본다.
• 타깃 OS는 몇 개인가 — Linux를 포함하는가, 모바일도 같이 가는가.
• 번들 크기 예산이 있는가 — 사용자 환경(저사양 PC)이 변수인가.
• 시작 시간이 중요한가 — 명령어 도구는 즉시성이 핵심.
• UI가 자주 바뀌는가 — 그렇다면 웹뷰 진영이 빠르다.
• 픽셀 성능이 중요한가 — 그래픽/미디어/에디터면 네이티브 진영.
• App Store 배포가 필요한가 — Apple/Microsoft 인증 통과 부담.
• 모바일을 같이 출시하는가 — 후보가 4개로 좁혀진다.
• 채용 가능한 인력 풀이 충분한가 — 너무 작은 진영이면 다음 사람이 못 들어온다.
• 5년 후에도 이 프레임워크가 살아 있는가 — 활동성, 커미터 수, 큰 후원자 여부 확인.

흔한 안티패턴

• "가벼우니까 Tauri" — 팀에 Rust를 쓸 수 있는 사람이 없는데 시작 → 백엔드 명령 추가할 때마다 멈춤.
• "단일 코드베이스니까 Flutter" — 데스크톱 UX 검토 없이 시작 → 단축키/메뉴 부재로 사용자 불만.
• "Microsoft니까 MAUI" — Linux 사용자가 핵심인 도구인데 MAUI 선택 → 출시 후 Linux 미지원 비난.
• "Qt는 진짜 네이티브" — 상업 라이선스 비용 미확인 → 출시 직전 라이선스 협상에서 멈춤.
• "Electron은 무겁다"는 일반론 — 사용자가 16GB RAM PC를 쓰는 환경인데 200MB 번들을 두려워해서 Tauri 선택 → Rust 학습으로 6개월 지연.
• "Compose는 멋지니까" — Android 개발자 없는 팀에서 시작 → Kotlin/Gradle 빌드 시스템과 씨름.
• "우리 팀은 다 가능" — 채용 시장에 후보가 없는 진영 선택 → 다음 채용에서 비용 폭증.

1주일 안에 답해야 할 질문 4개

1. 누가 만드는가 — 팀 언어
2. 누가 쓰는가 — 타깃 OS와 사용자 환경
3. 무엇을 만드는가 — UI 변경 빈도와 성능 요구
4. 얼마나 오래 가는가 — 5년 후 채용/유지 보수 시나리오

이 4개에 정직하게 답하면 후보가 보통 2~3개로 좁혀진다. 거기서부터 PoC 1주, 결정 1주, 이후 본격 개발.

다음 글 예고

• 데스크톱 앱 자동 업데이트의 모든 것: 코드 서명, 노타리제이션, 델타 업데이트, Squirrel · Tauri Updater · Sparkle.
• 데스크톱 앱 보안 모델 비교: Electron의 컨텍스트 격리, Tauri의 capabilities, Qt의 SBOM, macOS sandboxing.
• 데스크톱 앱 배포 채널 전략: 직접 다운로드 · Microsoft Store · Mac App Store · Snap · Flatpak · Homebrew.
• 데스크톱 앱 성능 측정: 시작 시간 · 메모리 · 프레임 시간 · 입력 지연 — 어떻게 재고 어떻게 비교하는가.

데스크톱은 죽지 않았다. 더 살아 있다. 도구는 11개이고, 정답은 팀마다 다르다. 4축으로 자르고, 후보 2~3개로 좁히고, PoC 1주로 결정하라.

---

참고 / References

• Electron 공식: electronjs.org
• Electron 릴리스 노트: github.com/electron/electron/releases
• Tauri 공식: tauri.app
• Tauri 2.0 발표: tauri.app/blog/tauri-20
• Wails 공식: wails.io
• Wails v3 로드맵: v3alpha.wails.io
• Neutralino 공식: neutralino.js.org
• Qt 공식: qt.io
• Qt 6.8 LTS 발표: qt.io/blog/qt-6.8-lts-released
• PySide6 / Qt for Python: doc.qt.io/qtforpython
• JetBrains Compose Multiplatform: jetbrains.com/compose-multiplatform
• Compose iOS 진행 상황: github.com/JetBrains/compose-multiplatform
• .NET MAUI 공식: dotnet.microsoft.com/apps/maui
• Flutter Desktop: docs.flutter.dev/platform-integration/desktop
• Slint UI: slint.dev
• Slint 1.0 발표: slint.dev/blog/2023-04-03-announcing-slint-1-0
• Lazarus IDE: lazarus-ide.org
• Free Pascal: freepascal.org
• GTK + Rust(gtk-rs): gtk-rs.org
• GTK 공식: gtk.org
• Vala: vala.dev
• Avalonia: avaloniaui.net
• Uno Platform: platform.uno
• Iced (Rust): iced.rs
• egui (Rust): egui.rs
• Zed Editor — GPUI: zed.dev
• Fyne (Go): fyne.io
• gioui (Go): gioui.org
• VS Code Electron 사용 사례: code.visualstudio.com/docs
• Discord Electron 사용 사례 (블로그): discord.com/blog
• Slack 네이티브 macOS 실패 이야기: slack.engineering
• Linear 데스크톱 앱 변경 이야기: linear.app/blog
• Notion 데스크톱 Electron: notion.so
• 1Password 8.x 디자인 결정 (Electron): 1password.community
• Bitwarden 데스크톱 아키텍처: bitwarden.com/help
• Affinity (Qt 사용): affinity.serif.com
• OBS Studio (Qt): obsproject.com
• Reaper 데스크톱 프레임워크: reaper.fm
• BMW + Flutter 사례: flutter.dev/showcase
• 이전 글: Tauri 2 vs Electron 단독 비교 (이 블로그)