05 — When to Choose Electron
이 문서가 답하는 질문: “언제 Electron을 고르고 언제 다른 도구로 가야 하는가? PWA로 충분한가? Tauri가 더 맞는 자리는 어디인가? React Native·Capacitor·진짜 네이티브와는 어떻게 비교되는가?” 한 줄 답 (Pyramid Top): “Electron은 OS API 접근·오프라인·Chromium 통일성이 가치 있고 메모리·시작시간·번들 사이즈를 받아들일 수 있을 때 고른다. PWA로 풀리면 PWA가, 작은 binary가 핵심이면 Tauri가, 진짜 네이티브 룩이면 Cocoa/WPF가 정답이다.”
Why — 왜 선택 기준을 따로 다루는가
기술 선택은 가장 흔하게 잘못 내려지는 결정이다. 이유는 보통 셋 중 하나.
| 잘못된 선택 이유 | 결과 |
|---|---|
| ”다들 Electron 쓰니까” | 200KB 웹앱을 200MB binary로 배포해 사용자가 받기를 거부 |
| ”binary가 커서 Tauri로” | Rust로 짠 OS API 어댑터가 매 OS마다 깨지는 운영 부담 |
| ”네이티브가 최고니까” | macOS·Windows·Linux 세 코드베이스를 3명이 짜다 1.5명만큼만 만들어짐 |
이 챕터는 적합한 자리 / 적합하지 않은 자리를 체크리스트와 결정 트리로 정리한다. 답이 언제나 Electron인 게 아니라는 사실을 데이터로 보여주는 게 목적이다.
How — 어떻게 결정하는가
각 질문의 답이 결정에 어떻게 들어가는지는 What 절에서 풀어쓴다.
What — 구체 기준과 비교
적합한 자리 (Electron이 이긴다)
| 자리 | 왜 Electron이 좋은가 | reference 사용자 |
|---|---|---|
| IDE·코드 편집기 | 자식 프로세스(tsc·eslint)·임의 파일 시스템·git·네이티브 모듈 모두 필요 | VS Code · Atom (지나간) |
| 메신저·협업 도구 | 알림·트레이·글로벌 단축키·오프라인 큐 | Slack · Discord · Teams (이전) |
| 노트·DB 앱 | 로컬 파일 저장·동기화·플러그인 (fs + child_process) | Notion · Obsidian |
| 디자인·그래픽 (특정) | WebGL/WASM이 충분하고 플러그인 생태계가 자산 | Figma desktop |
| API/DB 클라이언트 | 네이티브 드라이버 모듈·시스템 키체인·certificate store | Postman · DBeaver-like |
| 자체 호스팅 어드민 도구 | 같은 회사 도구들이 웹과 데스크톱 코드 공유 | GitHub Desktop · 1Password |
공통점은 셋:
- OS API에 깊이 닿는다 — 파일·자식 프로세스·트레이·단축키
- 오프라인이 자연스러워야 한다 — 로컬 작업이 메인
- Chromium 렌더링 통일성이 가치 — 모든 OS에서 같은 화면이 나와야 함
적합하지 않은 자리
| 자리 | 더 나은 도구 | 이유 |
|---|---|---|
| 단순 정보 사이트·블로그·SaaS 대시보드 | 웹 / PWA | OS API 거의 안 씀. 배포·갱신 비용이 무용 |
| 게임·고성능 그래픽 | 네이티브 (Unity·Unreal) 또는 Tauri + GPU 직접 | Electron의 GPU 추상화가 손해 |
| 모바일이 우선·데스크톱은 부수적 | React Native + 데스크톱 어댑터 또는 Capacitor | Electron은 모바일에서 안 돈다 |
| OS 네이티브 룩이 제품 가치 (예: 시스템 설정 비슷한 톤) | Swift/Cocoa · WPF · Qt · WinUI | Chromium HTML은 결국 웹 룩 |
| binary 크기가 핵심 (배포 환경·기업 정책) | Tauri · Wails · OS webview wrapper | Electron는 binary ~150MB+ |
| 시스템 트레이만 필요한 작은 유틸 | 네이티브 또는 Tauri | Electron 200MB로 트레이 아이콘 하나 |
대안 도구 비교
| 도구 | 렌더 엔진 | 백엔드 언어 | binary 크기 | 메모리 | 장점 | 단점 |
|---|---|---|---|---|---|---|
| Electron | 번들된 Chromium | Node.js (JS/TS) | ~100MB+ | OS 통일성·Node 생태계·풍부한 API | 큼·시작 시간·메모리 | |
| Tauri | OS webview (WebKit/WebView2/WebKitGTK) | Rust | 작음·빠름·Rust 안전성 | OS별 webview 차이·JS↔Rust IPC 학습 | ||
| Wails | OS webview | Go | 작음·Go 친화 | Tauri보다 생태계 작음 | ||
| Neutralino | OS webview | (없음 — JS 백엔드) | 매우 작음 | API가 좁음·실험적 | ||
| PWA | 사용자 브라우저 | (없음 — 클라이언트만) | 0 | 브라우저와 공유 | 즉시 갱신·설치 가능 | OS API 좁음·iOS 지원 부족 |
| Capacitor | OS webview | Native bridge (Swift/Kotlin) | OS 앱 사이즈 | OS 앱 메모리 | 모바일 친화·웹 코드 공유 | 데스크톱은 부수적 |
| React Native (Windows/macOS) | 네이티브 렌더 | JS bridge | 진짜 네이티브 위젯 | Windows/macOS는 Microsoft가 별도 유지 | ||
| Cocoa / WPF / WinUI / Qt | OS 네이티브 | Swift/C#/C++ | 진짜 네이티브 | OS별 코드 |
Tauri와의 trade-off — 가장 자주 비교되는 자리
결정 기준 —
| 묻는 것 | Tauri가 이김 | Electron이 이김 |
|---|---|---|
| binary 크기·메모리가 제품 가치 | yes | no |
| 모든 OS에서 픽셀까지 같음 보장 | no | yes |
| 작은 팀·작은 앱 (예: 트레이 유틸) | yes | no |
| 대형 앱·복잡한 플러그인 생태계 | no | yes |
| Rust 친화 팀 | yes | (덜 중요) |
| Node npm 생태계가 자산 | no | yes |
| DevTools를 지금 그대로 쓰고 싶음 | (부분) | yes |
→ 제품 단계에 따라 정답이 바뀌기도 한다. MVP는 Electron으로 빠르게, 성숙기에 메모리가 문제면 Tauri로 부분 이주, 같은 경로를 1Password가 1Password 8에서 일부 갔다.
PWA로 끝낼 수 있는가 — 체크리스트
| 필요한가? | 항목 |
|---|---|
| ☐ | 임의 경로 파일 읽기·쓰기 (File System Access API의 prompt + handle 모델로 충분한가?) |
| ☐ | 시스템 트레이 아이콘 (PWA는 없음) |
| ☐ | 글로벌 단축키 (PWA는 없음) |
| ☐ | 자식 프로세스 실행 (PWA는 없음) |
| ☐ | 네이티브 모듈 (PWA는 없음) |
| ☐ | OS 알림 (PWA는 OK) |
| ☐ | 푸시 알림 (PWA는 OK, iOS는 제한) |
| ☐ | 오프라인 동작 (PWA는 Service Worker로 OK, 단 데이터 동기화는 별도 설계) |
| ☐ | 카메라/마이크 (PWA는 OK) |
| ☐ | 시스템 정보 (OS 버전·아키텍처 — PWA는 좁음) |
→ 위 항목 중 PWA로 풀 수 없는 게 1~2개 미만이면 PWA가 정답. 그 이상이면 Electron이나 Tauri 후보.
React Native / Capacitor와의 비교 — 모바일이 같이 있나
| 시나리오 | 권장 |
|---|---|
| 데스크톱이 메인, 모바일 무 | Electron |
| 데스크톱과 모바일 대등하게 같이 | React Native (Windows/macOS for desktop) |
| 모바일 메인, 데스크톱은 미러 | Capacitor (Electron 어댑터 있음) |
| 모바일과 데스크톱이 다른 제품 가치 | 두 코드베이스 — 각각 적합한 도구 |
→ Slack·Discord는 데스크톱은 Electron, 모바일은 React Native. 두 코드베이스 전략. 코드 공유는 비즈니스 로직 라이브러리 수준에서.
의사결정 시 시그널 비트 5개
| 시그널 | Yes면 | No면 |
|---|---|---|
| 1. 임의 파일 시스템에 닿아야 함 | Electron / Tauri / 네이티브 | 웹 / PWA |
| 2. 자식 프로세스 실행해야 함 | Electron / 네이티브 | 다른 거 다 OK |
| 3. binary가 50MB 이하 여야 | Tauri / 네이티브 | Electron OK |
| 4. 모든 OS 픽셀 통일 필요 | Electron | Tauri / 네이티브 |
| 5. 팀이 Rust 친화 | Tauri 검토 | Electron 디폴트 |
5개 비트의 조합으로 2^5 = 32가지가 나오지만, 실무에서는 (1,2,4)=YES → Electron, (1,3)=YES → Tauri가 가장 흔한 답이다.
What-if — 잘못 골랐을 때
1) PWA로 충분한 앱에 Electron을 골랐다
증상: 사용자가 200MB 다운로드를 거부. 설치 전환율 폭락. 원인: 웹 정보 사이트·간단한 SaaS·대시보드는 OS API 거의 안 쓴다. Electron의 비용을 벌지 못한다. 대응: PWA로 다시 빌드. Service Worker + Web App Manifest + 일부 Web Platform API.
2) 작은 유틸에 Electron을 골랐다
증상: 트레이 아이콘 + 약간의 텍스트 변환을 200MB binary로 배포. 사용자가 비교 가능한 네이티브 앱과 비교해 Electron 거부감. 원인: Chromium 비용을 정당화할 만큼의 기능이 없다. 대응: Tauri나 네이티브 토킷.
3) 진짜 네이티브 룩이 필요한데 Electron을 골랐다
증상: macOS의 NSSidebar·NSInspector·NSToolbar를 HTML/CSS로 흉내내려다 어색함이 누적. 1.0 출시 후 *Mac 사용자들이 “Mac 앱처럼 느껴지지 않는다”*고 평가. 원인: HTML/CSS는 결국 웹 룩. 픽셀 단위로 진짜 NSWindow가 그리는 것과 같아질 수 없다. 대응: 네이티브 토킷으로 다시 짜거나, 부분만 네이티브로 (예: 트레이만 네이티브 wrapper).
4) Tauri로 갔는데 OS별 webview 차이에 시달린다
증상: macOS WebKit에선 잘 동작하던 CSS가 Windows WebView2에선 조금 다르게 그려짐. Linux WebKitGTK에선 입력 메서드가 깨짐. 원인: Tauri는 OS webview를 쓴다. WebKit·WebView2·WebKitGTK는 서로 다른 엔진이고 서로 다른 시점의 W3C 준수. Electron의 Chromium 통일성이 이걸 막아주는 것. 대응: Chromium 통일성이 필수면 Electron으로 돌아간다. 또는 OS별 분기를 받아들인다.
5) “Electron 메이저를 업그레이드 안 해도 되겠지”
증상: 1년 묵힌 Electron 26에 Chromium 116의 보안 패치가 안 들어와 있어 XSS → OS 명령 위험. 원인: Electron은 N-2까지만 보안 패치. 그 이전은 상류 패치 안 받는다. 대응: 분기 단위 업그레이드를 운영 계획에 둔다. Electron 선택 = 이 비용을 받아들이는 것. 자세히는 02-history-and-ecosystem.
Insight — 흥미로운 이야기
”Electron은 기본값이지 정답은 아니다”
데스크톱 웹앱 시장의 80~90%가 Electron 위에 산다. 이 사실은 Electron이 무조건 옳다는 게 아니라 디폴트 트레이드오프가 맞는 자리가 많다는 뜻이다.
VS Code 정도의 대형 IDE는 Electron이 정답에 가깝다 — Node 생태계·DevTools·Chromium 통일성이 모두 가치를 만든다. 하지만 트레이 시계 앱에 Electron을 쓰는 건 과잉. 제품 사이즈에 비례해 적합한 도구가 달라진다.
업계가 “Electron이 메모리 먹는 괴물”이라고 자주 비판하지만 — 같은 비판이 1Password·VS Code·Slack에는 받아들여진 비용이다. 이는 비용이 가치보다 작으면 사용자는 신경 안 쓴다는 일반 법칙의 사례다.
”Tauri의 폭발과 현실 점검”
2022년 Tauri 1.0이 나오면서 “Electron 끝장” 류의 글이 줄을 이었다. 3년이 지난 2025년 현재 — Tauri는 작은 앱 자리에서 성공했고 큰 앱 자리에서는 Electron이 굳건하다.
이유는 Chromium 통일성의 진짜 가치가 드러나지 않은 채로 일하고 있기 때문이다. Electron 개발자는 OS별 webview 차이를 볼 일이 없다 — 그 비용을 Electron이 흡수해서. Tauri로 옮기면 그 비용이 내 차지가 된다. 작은 앱은 그 비용이 작아서 괜찮고, 큰 앱은 그 비용이 폭발한다.
이 비대칭은 기술 선택이 제품 사이즈에 비례한다는 원리의 사례. MVP는 작아서 Tauri OK, 성숙 제품은 커서 Electron이 합리적.
”결정 한 번이 평생 가는 게 아니다 — Migration 경로”
Slack은 전체를 한 번에 새로 짠 적이 없다. Electron 4 → 28까지 점진적으로 메이저 업그레이드했고, 그 사이 프로세스 모델·보안 모델·번들러를 조금씩 바꿨다. 큰 결정은 작은 단계로 옮겨간다.
Microsoft Teams도 Electron → Edge WebView2로 옮길 때 전체를 다시 안 짰다. 비즈니스 로직은 React 그대로, 셸만 WebView2로. 이 분리가 가능했던 건 원래부터 셸과 로직을 분리해서 짜둔 덕.
기술 선택의 진짜 비용은 지금의 선택이 평생 가는가가 아니라 나중에 옮길 수 있는 구조로 짜뒀는가다. Electron API를 직접 부르지 말고 인터페이스로 감싸라는 패턴이 그래서 의미가 있다.
”기술이 아니라 팀의 의지력이 결정한다”
기술 선택 회의에서 가장 자주 무시되는 변수는 팀의 의지력. 1년 뒤 지치지 않을 도구를 골라야 한다.
- Tauri는 Rust 학습을 강요한다. 팀이 Rust에 친하지 않으면 1년 뒤 지친다.
- Electron은 Node·JS/TS 생태계에 산다. 팀이 이미 풀스택이면 지치지 않는다.
- 네이티브는 Swift·C#·C++ 동시 운영. 팀이 그만큼 크지 않으면 지친다.
기술의 우수성과 팀의 의지력은 다른 변수다. 후자가 더 강한 신호일 때가 많다.
요약
Electron은 기본값이지 정답은 아니다. OS API·오프라인·Chromium 통일성이 가치 있고 메모리·시작시간·번들 사이즈를 받아들일 수 있을 때 고른다. PWA로 풀리면 PWA, 작은 binary가 핵심이면 Tauri, 네이티브 룩이면 Cocoa/WPF. 결정의 진짜 변수는 5개 시그널과 팀의 의지력이며, 결정은 평생 가는 게 아니라 옮길 수 있게 짜는 것이 더 중요하다.
챕터 종료. 이제 01-process-model로 — Electron을 골랐다면, 그 안의 권한이 다른 프로세스를 어떻게 묶는가가 다음 챕터.