Electron

Concept

• OpenJS Foundation 산하에서 유지·관리되는 오픈소스 프레임워크
• 목적: 데스크톱 앱을 웹 기술(HTML/CSS/JS/TS) 로 개발하고, 크로스플랫폼(Windows/macOS/Linux) 으로 배포
• 핵심 구성
  • UI 렌더링: Chromium
  • 애플리케이션 런타임/시스템 작업: Node.js
• 역사
  • 최초에는 GitHub의 Atom을 위해 만들어짐
  • 이후 GitHub Desktop, Light Table, WordPress Desktop 등 다양한 데스크톱 앱에서 사용

---

Architecture (구조)

• Electron 앱은 “앱 내부에 Chromium + Node.js 런타임을 포함”하는 형태
• 큰 흐름
  • Chromium: 화면 렌더링과 웹 플랫폼 실행(HTML/CSS/SVG/JS)
  • Node.js: 파일/네트워크/프로세스 등 시스템 작업 수행
  • Native layer & bindings: 실제 OS API 호출을 담당하는 네이티브 코드(C++/Objective-C 등) + JS 바인딩

개발자가 실제로 개발하는 영역

• 일반적인 앱 개발자는 Electron App 영역(Main/Renderer + 필요 시 preload) 의 JS/TS 코드를 작성한다.
• Native layer & bindings는 보통 Electron 프레임워크 내부 구현(플랫폼별 네이티브 코드 + JS 바인딩)이라 앱 개발자가 직접 수정하지 않는다.
• 예외적으로 개발자가 Native 쪽을 다룰 수 있는 경우

1. Electron/Node로는 부족한 기능이 있어 네이티브 확장(Native Node Addon, 네이티브 모듈) 을 직접 만들거나 붙일 때
2. Electron 자체에 컨트리뷰션/포크하여 프레임워크 레벨을 수정할 때

---

Process model (프로세스)

• Main / Renderer 프로세스 모델을 사용

Main process

• 앱 생명주기와 시스템 연동의 “중앙”
• 창 생성/관리, 메뉴/트레이/다이얼로그 등 OS 연동 기능을 주로 담당
• BrowserWindow로 Renderer 프로세스를 생성/관리
• Renderer와는 IPC로 통신 (ipcMain 등)

Renderer process

• 각 창(웹 페이지) 단위로 실행되는 프로세스
• Chromium에서 UI(HTML/CSS/SVG)를 렌더링하고, 프론트엔드 로직을 실행
• Main과 IPC로 통신 (ipcRenderer 등)

참고: Node 통합 여부(예: nodeIntegration)와 보안 옵션은 설정에 따라 달라질 수 있다.

---

API / 구현 방식

• 개발자가 사용하는 Electron API는 대부분 JavaScript로 노출되지만,
• 내부 구현은 플랫폼별로 C++ / Objective-C(특히 macOS) 등 네이티브 코드로 작성되고 JS 바인딩을 통해 제공된다.
• 즉, 개발자는 JS/TS로 API를 호출하고, 실제 OS API 호출은 네이티브 레이어가 수행한다.

---

Mermaid 시각화 (Top: Electron → Bottom: OS)

flowchart TB

subgraph E[Electron App]
  direction TB

  subgraph MP[Main process]
    direction TB
    MJS[App logic JS TS]
    EAPI[Electron JS API\napp BrowserWindow ipcMain]
    MNode[Node runtime\nfs net child_process]
    MJS --> EAPI
    MJS --> MNode
  end

  subgraph RP[Renderer process]
    direction TB
    UI[UI HTML CSS SVG]
    RJS[Renderer logic JS TS]
    Chromium[Chromium renderer and V8]
    IPC[IPC bridge\nipcRenderer to ipcMain]
    UI --> Chromium
    RJS --> Chromium
    RJS <--> IPC
  end

  IPC <--> MP
end

subgraph NL[Native layer and bindings]
  direction TB
  NativeModules[Native modules\nC++ and Objective-C\nJS bindings]
end

subgraph OS[Operating system]
  direction TB
  Win[Windows APIs]
  Mac[macOS APIs]
  Lin[Linux APIs]
end

EAPI --> NativeModules
MNode --> NativeModules
NativeModules --> Win
NativeModules --> Mac
NativeModules --> Lin

Usage

• Electron은 다양한 데스크톱 애플리케이션에서 사용됨
• (Wikipedia “Usage” 섹션 기준) 예시:
  • Slack
  • Discord
  • GitHub Desktop
  • WordPress Desktop
  • Light Table
  • (그 외 다수)

참고: 특정 앱이 “현재도” Electron을 쓰는지 여부는 시간이 지나며 바뀔 수 있어, 필요하면 최신 공식 발표/문서로 교차 확인하는 것이 안전함.

---

Reception (평가) — 자주 언급되는 장/단점

구분	내용	뉘앙스/비고
장점	웹 기술(HTML/CSS/JS/TS) 기반으로 빠른 개발	웹 개발자 친화, 생산성 높음
장점	크로스플랫폼 단일 코드베이스	배포/유지보수 효율
장점	Chromium 기반 렌더링/웹 생태계 활용	UI 구현/표현력 유리
장점	Node.js 런타임으로 시스템 작업 가능	파일/네트워크/프로세스 등
단점	단순 앱에도 Chromium 번들 포함 → 용량/메모리/CPU 증가(software bloat)	“무겁다” 비판이 흔함
단점	Linux에서 리소스 사용량/네이티브 통합성 부족 불만	테마/다이얼로그/트레이 등
단점	기능 집합이 커 공격 표면이 넓다는 지적	소스 JS 변경 가능 환경 전제
단점	Chromium 업데이트가 항상 최신이 아닐 수 있음	대안으로 PWA 추천 의견 존재

---

참고문서

• https://en.wikipedia.org/wiki/Electron_(software_framework)