electron 사용 전 알아보기
이번 사이드 프로젝트에서 사용하기로 한 크로스 플랫폼 프레임워크 electron에 대해 알아보자..
electron을 사용하기로 한 이유는 OS 접근이 가능해 네이티브 기능 사용이 가능하다는 것, 사용자가 설치해서 사용하면 더 편리하지 않을까..라는 단순한 이유였다. 이왕 쓰기로 한 거 언제 왜 써야 하는지, 그리고 주요 구조와 흐름을 이해하며 사용하기 위해 정리하게 되었다.
👀 Electron
- Electron을 통해 웹 기술(HTML, CSS, JavaScript)을 기반으로 Windows, macOS, Linux를 모두 지원하는 PC 데스크탑 애플리케이션을 만들 수 있다.
- Chromium + Node.js 구조 덕분에 하나의 실행 환경 안에서 웹 UI와 OS 네이티브 기능을 함께 사용할 수 있다.
- 대표적인 일렉트론 기반 앱으로 VS Code, Slack, Discord, Notion, Figma desktop 등이 있다! 👀👍
✅ 메인 프로세스 & 렌더러 프로세스
Electron은 Chrome의 멀티 프로세스 구조를 참고해, Node.js로 실행되는 메인 프로세스와 Chromium 기반의 렌더러 프로세스로 역할을 분리해 사용한다.
기본적으로 하나의 메인 프로세스(중앙 관리자)가 있고, 그 아래에 각각의 렌더러 프로세스가 독립적으로 여러 개 생성되는 구조를 가진다.
이렇게 독립된 랜더러 프로세스를 여러 개로 나누기 때문에 다음과 같은 장점을 가진다.
- 안정성. 렌더러 하나가 멈춰도, 나머지 창이나 탭에 영향이 가지 않는다.
- 보안. 각 렌더러는 서로 직접 접근할 수 없고, 권한이 분리되기 때문에 악성 코드나 버그가 다른 창으로 쉽게 퍼지지 않는다.
- 성능. 프로세스를 여러 개로 나누어, 각 렌더러가 별도의 프로세스로 독립적으로 실행된다. 한 렌더러가 무거워져도 다른 렌더러에 영향을 주지 않는다.
- 중앙 통제 구조. 중앙에서 전체 리소스를 관리할 수 있는 권한이 메인에 있으며, 모든 중요한 작업이 메인 프로세스를 거치기 때문에 관리가 용이하다.
✅ 두 프로세스로 역할을 나눈 이유
메인 프로세스 & 렌더러 프로세스 이렇게 두 프로세스로 역할을 나눈 이유는 다음과 같다.
1. Node.js를 통해 샌드박스를 벗어나 OS 접근이 가능하게 하기 위해
→ 브라우저는 사용자 PC를 보호하기 위해 샌드박스(Sandbox) 안에서 동작하기 때문에, 로컬 파일 시스템이나 네이티브 기능 등 OS와 직접 연결되는 기능을 제한한다.
2. Node.js는 서버 환경이라 화면(UI)을 직접 렌더링 할 수 없기 때문
따라서 메인 프로세스를 통해 네이티브 기능을 담당하고, 렌더러 프로세스는 UI를 렌더링하는 역할을 맡아 두 역할이 결합되어 하나의 애플리케이션으로 동작한다.
🤔 그렇다면 독립적인 두 프로세스는 어떻게 데이터를 주고받는가..
위에서 알아본 것과 같이 렌더러 브라우저(Chromium)는 샌드박스(Sandbox) 안에서 동작하기 때문에 로컬 OS 기능에 접근할 수 없다. → 따라서 렌더러가 OS 작업이나 Electron의 네이티브 API에 접근해야 할 땐, 메인 프로세스를 통해서만 가능하다. 반대로 메인(Node.js)은 OS 기능은 처리할 수 있지만 UI를 직접 렌더링할 수는 없다. 그리고 렌더러/메인은 별도의 프로세스이기 때문에 직접 데이터를 공유할 수 없다.
→ 두 프로세스가 서로 필요한 작업을 주고받기 위해서는 IPC(Inter-Process Communication)를 사용해 통신해야 한다.
✅ IPC(Inter-Process Communication)
IPC stands for inter-process communication. Electron uses IPC to send serialized JSON messages between the main and renderer processes.
Electron은 렌더러가 직접 못 하는 OS 작업을 메인에게 대신 요청하고 결과를 받아올 때, IPC를 통해 데이터를 주고받는다. 이 과정에서 렌더러는 ipcRenderer를, 메인 프로세스는 ipcMain을 사용해 서로 메시지를 주고받는다.
| 구분 | 메인 프로세스 (Main Process) | 렌더러 프로세스 (Renderer Process) |
|---|---|---|
| 역할 | Electron 백그라운드, 시스템 제어 → 앱 관리 | UI 렌더링, 사용자 인터랙션 → 화면 |
| 기능 | - 애플리케이션 생명 주기 관리 - 창 (BrowserWindow) 생성 및 제어 - OS 기능 처리 - 렌더러 프로세스 관리 |
- UI 표시 - 사용자 이벤트 처리 - 메인 프로세스와 통신 |
| 기술 | Node.js | HTML, CSS, JS, React, Next.js 등 |
| 환경 | Node.js 환경에서 실행 | Chromium 기반 브라우저 환경 |
| 통신 | ipcMain | ipcRenderer |
| 수 | 기본적으로 메인 프로세스는 하나만 존재 | 창/탭/webview마다 각각 따로 여러 개 생성 |
✅ electron과 일반 웹의 차이점
고렇다면 일반 웹과 설치형 다중 프로세스 Electron 앱은 어떤 차이점이 있는가 짚고 넘어가자
| 구분 | Electron 앱 | 웹 |
|---|---|---|
| 실행 환경 | 데스크톱 앱 (Windows, macOS, Linux) | 브라우저 안에서 실행 |
| 접근 권한 | 로컬 파일 시스템, OS API 직접 접근 가능 (Node.js 사용) | 보안상 제한적 (샌드박스) |
| 네트워크 연결 | 오프라인 지원 가능 | 기본적으로 네트워크 연결 필요 |
| 보안 책임 | 개발자가 직접 모든 보안 설계 책임 🫥 | 브라우저 샌드박스 + 보안 기능 기본 제공 |
| 크로스 플랫폼 | Windows, macOS, Linux 모두 지원 | OS/브라우저 따라 일부 동작 다를 수 있음 |
| 배포 | .exe, .dmg 등 실행 파일로 배포 |
도메인 URL로 배포 (브라우저로 접근) |
알아보니 Electron의 가장 큰 단점은 Chromium을 함께 번들링하기 때문에 무겁다는 것, 보안 설계를 개발자가 직접 책임져야 한다는 점인데 이렇게 보면 electron은 웹 기술만으로는 할 수 없는 OS 접근이 꼭 필요한 앱에서는 의미가 있겠지만, 단순히 ‘설치형이 더 편할 것 같다’ 정도로 사용하기에는 리스크가 많은 것 같다는 생각이 들었다
가장 큰 장점이 OS 사용, 파일 시스템 접근, 오프라인 작동이 가능하다는 점인데 우리 프로젝트에는 이미 패키징했으니 사용하기로 한 OS 알림 외에 일부러라도 더 활용할 방법이 있을지 고민해볼 필요가 있을 것 같다🤔
댓글남기기