08-ecosystem-alternatives — 생태계와 대안

이 챕터가 답하는 질문: Electron이 사실상 표준이지만 유일한 답은 아니다. 어떤 자리에서 어떤 대안이 더 맞는가, 그리고 Electron이 여전히 최선인 자리는 어디인가? 한 줄 답 (Pyramid Top): “Electron은 Chromium 통일성 + Node 생태계가 핵심 가치다. 그 둘이 필요 없다면 Tauri(번들 ~5MB, OS webview)가 가볍고, 데스크톱 설치가 필수 아니라면 PWA가 충분하고, 모바일 우선이면 Capacitor/React Native가 자연스럽고, 고도 그래픽이면 Flutter/네이티브가 옳다.”

한 문장 답 (Pyramid Top)

*“Electron vs Tauri”*라는 프레임은 반쯤만 맞다 — Tauri는 번들 사이즈와 메모리에서 압승이지만, Chromium 통일성을 잃는다. macOS WKWebView · Windows WebView2 · Linux WebKitGTK 셋이 조금씩 다르게 동작하고, 그 차이는 production에서 사용자 별로 다른 버그로 돌아온다. 한 회사의 답은 보통 Electron 또는 Tauri 둘 중 하나가 아니다 — VS Code는 Electron(Chromium 통일성·확장성), 1Password는 Electron→Rust→Tauri로 변천(보안·번들 크기), Figma Desktop은 Electron(WebGL 호환성), Notion은 Electron(빠른 기능 추가). 어느 회사가 왜 어느 것을 골랐는가가 진짜 의사결정 자료다. 이 챕터는 그 7가지 대안을 같은 축에 줄 세우고 — 적합한 자리·부적합한 자리·실제 회사들의 선택을 정리한다.

챕터 지도 (Mermaid)

대안 비교 한눈 (Mermaid)

Why — 왜 이 챕터가 마지막에 오나

00~07을 따라오면서 Electron이 무엇이고 어떻게 작동하는지는 충분히 다뤘다. 그러나 production에 올리기 직전 모든 팀이 같은 질문을 다시 만난다.

“우리 케이스에 진짜 Electron이 맞나? Tauri가 가볍다던데? PWA로 안 되나? 모바일도 같이 가야 하는데?”

이 질문에 *“Electron은 무조건 좋다”*고 답하는 자료는 거의 영업 자료다. 현실의 답은 항상 “어떤 축에서 무엇과 비교하느냐” 부터 정리해야 풀린다. 이 챕터의 7개 문서는 그 축을 하나씩 그어준다.

• 결정 트리: 01 — Electron이 맞는 자리, 안 맞는 자리
• 가장 큰 경쟁자: 02 — Tauri의 약속과 한계
• 다른 언어 스택: 03 — Wails(Go), Neutralino(C++)
• 데스크톱이 아닌 답: 04 — PWA, Tauri Mobile
• 모바일과 같이 갈 때: 05 — Capacitor, React Native
• 네이티브로 가는 길: 06 — Flutter, .NET MAUI, Qt, Swift
• 실제 회사들의 선택: 07 — VS Code · 1Password · Figma · Notion

How — 어떻게 읽나

세 가지 경로가 있다.

대안 비교 매트릭스 (한 페이지 요약)

한 회사는 이 매트릭스의 여러 도구를 동시에 쓰는 게 보통이다 — 어디서 어떤 도구를 쓰느냐가 진짜 결정.

What — 한 페이지 요약 (모든 문서의 핵심 한 줄)

What-if — 잘못된 선택의 비용

1) “가벼우니 Tauri”만 보고 갔는데 Chromium 통일성이 필요했음

• 사용자별 webview 버그 — macOS는 되는데 Windows에서만 깨짐. CSS feature, WebGL 호환성, font rendering이 셋 다 다르다.
• QA 비용 3배. 어떤 기능은 Linux WebKitGTK가 너무 옛 버전이라 polyfill 불가.
• → 6개월 뒤 Electron으로 역이주. 실제로 2022~2023년 일부 startup에서 발생한 패턴.

2) “PWA로 충분”이라 믿었는데 iOS 사용자가 많았음

• iOS Safari는 Service Worker 캐시 7일 제한, push notification 없음(2023년까지), background sync 없음.
• “설치 가능”이라 했지만 사용자가 Home에 추가하지 않음 — 채택률 < 10%.
• → 모바일은 Capacitor나 네이티브로 다시 빌드.

3) “Capacitor면 데스크톱도 보너스”라 믿었는데 데스크톱이 주력

• Capacitor의 데스크톱은 Electron wrapper다 — Electron보다 가벼워지지 않는다. 모바일에 최적화된 부품·플러그인이 데스크톱에선 어색.
• → 데스크톱은 전용 Electron으로 분리. 코드 공유는 React 컴포넌트 레벨에서만.

4) “네이티브가 빠르니 Swift+AppKit”인데 Windows 사용자가 많았음

• macOS 80% 가정으로 시작했다가 Windows 사용자 비중이 30%로 늘면 — 처음부터 다시 작성 (.NET MAUI나 WPF).
• 크로스 플랫폼 부담을 처음부터 인정하지 않은 비용.

5) “Electron 메모리가 무거우니 다른 거”로 결정했는데 실제로는 문제가 아니었음

• “Electron 100MB” 신화 — 사실 Chrome 탭 3~4개 비용. 충분히 메모리가 많은 데스크톱에서는 문제가 안 됨.
• 그 신화를 따라가다 생태계 빈약·기능 추가 속도 저하 — 더 큰 비용.

Insight — 한 단락 이야기

“1Password의 10년 — Electron → Rust 네이티브 → Tauri”

1Password는 2018년경 macOS 네이티브 앱에서 Electron으로 전환했다(v7). 이유는 Windows·Linux 지원과 팀의 웹 기술 통합. 그러나 보안 회사인 그들에게 Electron의 공격면은 점점 부담이 되었다. 2021년 Rust로 백엔드를 다시 작성했고, 2023년경부터 Tauri를 적극 검토·일부 컴포넌트 적용. 같은 회사가 세 번 다른 답을 골랐다 — 시기에 따라 다른 트레이드오프가 옳았기 때문.

한편 VS Code는 10년째 Electron이다. Microsoft가 Tauri로 갈 능력이 없어서가 아니라 — VS Code Extension API 생태계와 Chromium 기반 Monaco Editor가 Electron이라는 기반에 깊이 묶여 있어서다. 바꿀 수 있는 회사와 바꿀 수 없는 회사의 구분은 기술적 우월성이 아니라 기존 자산의 형태에서 온다.

이 챕터가 흥미로운 건 — “어느 도구가 좋은가”가 아니라 “당신의 회사가 어느 시기에 어떤 자산을 갖고 있는가”가 진짜 질문이라는 점이다.

한 단락 요약

Electron은 Chromium 통일성 + Node 생태계가 핵심 가치인 도구다(01). 그 둘이 필요 없다면 Tauri(02) · Wails/Neutralino(03)가 가볍고, 데스크톱 설치가 필수 아니라면 PWA·Tauri Mobile(04)이 답이고, 모바일 우선이면 Capacitor·RN(05), 네이티브 OS 깊은 통합이 필요하면 Flutter·.NET·Qt·Swift(06)다. 실제 회사들의 선택은 기술적 우월성이 아니라 그 회사의 기존 자산과 시기에서 온다(07) — VS Code는 Electron을 못 떠나고, 1Password는 세 번 바꿨다. 이 챕터를 끝내면 *“Electron이 좋은가”*가 아니라 *“우리 자리에 어느 도구가 맞는가”*를 묻게 된다.