Electron — 도메인 홈
이 도메인이 답하는 질문: “웹앱이 이미 있는데 왜 Electron이 등장했고, Chromium + Node가 한 프로세스 트리에 어떻게 살며, 웹과 무엇이 같고 무엇이 다른가?” 한 줄 답 (Pyramid Top): “Electron은 Chromium 렌더러 + Node.js 메인을 IPC로 묶어 데스크톱 OS API에 접근 가능한 ‘확장된 브라우저’다 — 웹 표준 위에 OS 접근을 얹는 대신, 그 접근을 어디서 누가 할지(프로세스 분리·context isolation·preload bridge)를 매우 까다롭게 통제한다.”
도메인 지도 (5-레이어)
어떤 챕터가 들어 있나
| # | 챕터 | 한 줄 답 | 핵심 키워드 |
|---|---|---|---|
| 00 | 기초 | Electron은 Chromium + Node + IPC의 패키지된 런타임이다 — 웹 기술로 데스크톱을 짓되, 웹 모델을 그대로 따르지 않는다. | Atom Shell · Chromium · V8 · Node · Wikipedia: VSCode/Slack/Discord |
| 01 | 프로세스 모델 | Main 하나 + Renderer N개 + Preload N개 — 권한이 다른 프로세스를 IPC로 연결하는 멀티프로세스 구조. | main · renderer · preload · utility · GPU · zygote |
| 02 | 창과 라이프사이클 | BrowserWindow 하나가 OS 창 + webContents + 렌더러 프로세스의 묶음이다. | BrowserWindow · webContents · app.ready · before-quit · session |
| 03 | IPC & Bridge | Renderer는 OS에 직접 못 닿는다 — contextBridge로 좁은 함수만 노출하고 ipcRenderer.invoke ↔ ipcMain.handle로 요청한다. | ipcMain · ipcRenderer · contextBridge · invoke/handle · MessagePort |
| 04 | 네이티브 통합 | Node API와 OS API에 Main 프로세스가 책임지고 접근하고, 렌더러는 그 결과만 받는다. | fs · path · Tray · Menu · shell · clipboard · native module · N-API |
| 05 | 보안 모델 | 웹은 same-origin으로 격리하지만 Electron은 context isolation + sandbox + CSP + 노출 최소화의 다층 격리로 막는다. | contextIsolation · sandbox · nodeIntegration · CSP · webSecurity · remote 모듈 제거 |
| 06 | 패키징 & 배포 | URL이 아니라 binary로 배포하고 코드 서명 + 자동 업데이트가 운영 필수 인프라가 된다. | electron-builder · electron-forge · asar · code signing · notarization · Squirrel · Sparkle |
| 07 | 성능 & 메모리 | 런타임 하나가 *100MB+*에서 시작한다 — 시작 시간·메모리·번들 크기를 Electron 특유의 비용으로 인정하고 줄인다. | cold start · V8 snapshot · process per window · GPU 가속 · 메모리 leak |
| 08 | 생태계 & 대안 | Electron이 만능은 아니다 — Tauri·Wails·PWA·Capacitor가 다른 트레이드오프를 제공한다. | Tauri · Wails · Neutralino · PWA · Capacitor · React Native · webview vs bundled Chromium |
| ★ | 용어 사전 | 100+ 용어 사전. | contextBridge · webContents · asar · notarization · Squirrel · zygote |
Why — 왜 Electron 도메인을 한 묶음으로 보는가
세 가지 잘못된 직관이 거의 모든 Electron 사고의 출처다.
| 잘못된 직관 | 실제 | 어디서 다루나 |
|---|---|---|
| ”Electron은 그냥 브라우저에 Node를 끼운 것” | 프로세스 분리·격리·IPC·배포·서명이 통째로 다른 도메인이다. 웹 모델로 풀 수 없다. | 00, 01 |
| ”Renderer에서 Node API를 그냥 쓰면 편하다” | XSS 한 번에 OS 전체가 뚫린다. context isolation이 디폴트가 된 이유. | 03, 05 |
| ”패키징은 마지막 단계” | 코드 사이닝·notarization·auto-update는 설계 단계부터 같이 들어가야 한다. | 06 |
이 도메인을 5-레이어로 보면 — Process가 권한을 분리하고, Window가 그것을 OS 창에 묶고, IPC가 좁은 통로를 만들고, Native가 OS에 닿고, Security & Distribution이 그 닿음을 안전하게 운영한다. 웹과 비교축은 모든 레이어에서 함께 흐른다.
웹과 Electron — 한눈 비교
| 축 | 웹 (브라우저 안) | Electron |
|---|---|---|
| 실행 단위 | tab (origin 격리) | BrowserWindow (process per window) |
| 권한 모델 | same-origin policy + permission prompt | context isolation + preload bridge |
| OS API | sandbox 안의 Web API만 (File System Access API 등 제한적) | Node fs + Electron app/shell/Tray 등 거의 전부 |
| 멀티프로세스 | 브라우저가 내부적으로 함 (개발자 비가시) | 개발자가 직접 설계해야 함 |
| 배포 | URL — 즉시 갱신 | 서명된 binary + auto-update 서버 |
| 캐시·세션 | 브라우저가 관리 | session 객체로 내가 관리 |
| 시작 비용 | 브라우저는 이미 떠 있음 | 매번 새 Chromium + Node를 띄움 |
| 공격면 | XSS · CSRF · 클릭재킹 | 위 전부 + XSS → OS 명령 실행 위험 |
이 비교는 00에서 깊이 풀고, 챕터마다 “웹과의 차이” 박스를 둔다.
How — 어떻게 읽나
- 처음 Electron을 만나는 사람: 00 → 01 → 02 순서. 두 시간이면 왜 멀티프로세스인지가 잡힌다.
- 이미 쓰고 있는데 보안 리뷰가 걱정인 사람: 05만 깊게. 그다음 03(IPC 표면)으로.
- React 앱을 Electron으로 옮기려는 사람: 01 → 03 → 04 — 어떤 코드가 어느 프로세스에 가는지를 결정한 다음 옮긴다.
- Tauri·PWA로 갈지 결정해야 하는 사람: 00 → 07(비용) → 08(대안 비교). 한 시간 의사결정 패키지.
What — 도메인 한 페이지 요약
| 챕터 | 한 줄 결론 |
|---|---|
| 00 | Electron = Chromium + Node + IPC. 웹 기술은 같지만 모델은 다르다. |
| 01 | Main 1개 + Renderer N개 + Preload N개. 권한은 프로세스 단위로 다르다. |
| 02 | BrowserWindow는 OS 창과 webContents와 렌더러 프로세스를 한 묶음으로 추상화한 객체다. |
| 03 | contextBridge + invoke/handle은 유일한 안전한 통로다 — nodeIntegration: true 시대로 돌아가지 말 것. |
| 04 | OS·파일시스템 접근은 Main에서. 네이티브 모듈은 Electron ABI에 맞춰 빌드해야 한다. |
| 05 | context isolation · sandbox · CSP · webSecurity 네 가지가 동시에 켜져야 최소 안전선이다. |
| 06 | 코드 서명·notarization·auto-update는 셋이 하나의 운영 단위 — 하나만 빠져도 사용자 신뢰가 깨진다. |
| 07 | 메모리는 프로세스 수 × 한 프로세스 비용. 창을 늘리지 말고 재사용하는 게 1차 최적화. |
| 08 | Tauri는 작고 빠르고 OS webview, PWA는 설치 가능한 웹, Capacitor는 모바일 우선. Electron은 Chromium 통일성과 Node 생태계가 핵심 가치. |
What-if — 이 도메인을 단편적으로만 알면
- Process Model만 알고 IPC를 모르면: 메인에 모든 로직을 몰아넣어 UI freeze가 발생한다.
- IPC만 알고 Security를 모르면: 외부 URL 로딩 한 번에
ipcMain.handle('exec', ...)이 RCE 통로가 된다. - Native만 알고 Performance를 모르면: 네이티브 모듈 한 개당 프로세스 시작이 100ms씩 느려진다.
- Security만 알고 Distribution을 모르면: 사이닝 없는 빌드를 배포해 macOS Gatekeeper에서 열리지 않는다.
Insight — 한 단락 이야기
“Atom 에디터를 만들려고 GitHub이 만든 게 Electron이다 — 2013년”
Cheng Zhao가 Atom의 일부로 시작한
atom-shell은 “웹 기술로 데스크톱 앱을 어떻게 만들까”라는 GitHub 내부 문제의 답이었다. 2015년 Electron으로 개명되며 분리되었고, 같은 해 Microsoft가 Visual Studio Code를 Electron으로 출시하면서 사실상 데스크톱 웹앱의 사실상 표준이 되었다. 흥미로운 반전은 — Microsoft가 가장 큰 Electron 사용자이자 Electron의 한계(메모리·시작 시간)에 가장 많이 시달리는 회사라는 점. VS Code 팀은 그 한계를 Extension Host 분리·V8 snapshot·shared process로 풀어왔고, 그 패턴이 다시 Electron 본진에 흡수되는 호혜 루프가 십 년째 돌고 있다. 이 도메인이 흥미로운 건 — “웹을 데스크톱으로 옮긴 것”이 아니라 “웹의 한계를 데스크톱이 어떻게 메우는가”라는 역방향 질문이 매 챕터에 깔려 있다는 점이다.
Mermaid 4색 규약
이 도메인의 모든 다이어그램은 다음 색을 따른다.
색은 역할이고 모양은 의미다 — 다른 도메인과도 일관된다.
한 단락 요약
Electron은 Chromium 렌더러 + Node.js 메인을 IPC로 묶은 데스크톱 런타임이다. 그 위에 프로세스(권한 분리) · 창(OS 매핑) · IPC(통로) · 네이티브(OS 접근) · 보안과 배포(운영) 다섯 층이 쌓여 있다. 이 도메인을 끝내면 “웹앱을 Electron으로 옮길까?”라는 막연한 질문 대신 “내 코드는 어느 프로세스에 살고, OS에 어떻게 닿는가?” 라는 질문을 던지게 된다.