평소처럼 안드로이드 개발을 하고 있던 어느 날, 회사 업무 때문에 갑자기 "PC용 데스크톱 앱을 개발해야 한다"는 미션을 받게 되었습니다.

제 머릿속에 남아있는 데스크톱 앱 개발 지식이라곤 대학 시절 과제로 겨우겨우 짰던 투박한 Java Swing으로 만든게 전부였습니다. "지금 당장 C++이나 C#을 배워서 WPF나 MFC를 공부해야 하나?" 생각만 해도 막막했습니다. 새로운 언어와 생소한 윈도우 API를 익히기엔 시간도, 자신도 부족했습니다.

그렇게 지푸라기라도 잡는 심정으로 조사를 하던 중, 웹 개발 기술만으로 데스크톱 앱을 만들 수 있는 기술을 발견했습니다. 바로 Electron(일렉트론)입니다.

현업에 계신 많은 개발자분들도 이 Electron에 대해 잘 모르시는 경우가 많았습니다. (저도 몰랐습니다..) 아무튼, 저처럼 갑작스럽게 데스크톱 앱을 만들어야 하는 개발자분들을 위해, Electron이 도대체 무엇이며 어떤 매력이 있는지 쉽게 소개해 보고자 합니다.

Electron이 도대체 뭔가요?

Electron은 JavaScript(또는 TypeScript), HTML, CSS를 사용하여 데스크톱 애플리케이션을 개발하는 프레임워크이다. Electron은 Chromium과 Node.js를 바이너리에 내장하여 하나의 JavaScript(TypeScript) 코드베이스를 유지하고 Window, MacOS, Linux에서 작동하는 데스크탑용 크로스플랫폼 앱을 개발할 수 있도록 지원한다.

기술적으로는 쉽게 말해 "크롬 브라우저와 Node.js를 합쳐놓은 실행기"입니다.

기존 방식의 장벽

과거에는 Windows용 앱을 만들기 위해 C#(.NET)을, macOS용 앱을 위해 Swift나 Objective-C를 사용해야 했습니다.

높은 진입 장벽: 저 같은 모바일/웹 개발자가 C++ 계열의 시스템 레벨 언어를 새로 배우는 건 엄청난 부담입니다.
플랫폼 파편화: 윈도우용을 만들고 나니 맥용도 만들어 달라고 하면, 코드를 처음부터 다시 짜야 합니다.

Electron이라는 해답

Electron은 "Chromium 브라우저(화면)"와 "Node.js(시스템)"를 합친 프레임워크입니다. 우리가 매일 쓰는 VS Code, Slack, Discord, Notion 등 이 모두 이것으로 만들어졌습니다.

웹 기술 활용: HTML, CSS, JavaScript(TypeScript)만 알면 됩니다.
크로스 플랫폼: 코드 하나로 Windows, macOS, Linux 앱을 동시에 뱉어냅니다.
안드로이드 개발자가 느끼는 장점: 복잡한 윈도우 API 문서를 뒤지는 대신, 익숙한 비동기 처리와 UI 로직에 집중할 수 있습니다.

작동 원리(간단히)

Electron을 이해하려면 이 앱이 두 가지 서로 다른 역할의 프로세스로 나뉘어 돌아간다는 점을 알아야 합니다. 마치 식당에 비유할 수 있습니다.

① Main Process (주방장 & 지배인)

정체: Node.js 환경
역할: 앱이 켜지면 가장 먼저 실행되는 '대장'입니다. 사용자의 눈에는 보이지 않지만, 창(Window)을 새로 띄우거나, 파일을 컴퓨터에 저장하고, 앱을 종료하는 등 시스템의 핵심 권한을 쥐고 있습니다.

② Renderer Process (손님 테이블)

정체: Chromium (웹 브라우저)
역할: Main Process가 띄운 창(Window) 하나하나가 바로 Renderer입니다. 우리가 흔히 보는 화면 UI를 담당합니다. 여기서 React나 Vue 같은 웹 프레임워크가 돌아갑니다.

핵심 구조도 설명 (Main과 Renderer의 관계)

Gemini로 만든 Electron 구조도 입니다. ~~잘 만들어주네...~~

Main Process (상단 박스)
- 앱의 시작점(App Launch): 화살표가 가리키듯, 앱 아이콘을 더블 클릭하면 가장 먼저 이 녀석이 깨어납니다.
- Node.js & OS Native API: 박스 안의 '톱니바퀴(설정)'와 '폴더(파일)' 아이콘이 보이시나요? 이는 Main Process가 운영체제의 설정이나 파일 시스템 같은 하드웨어 영역을 직접 제어한다는 뜻입니다. 안드로이드 시스템 서비스와 같은 역할을 하죠.
IPC (중간 연결선)
- 위아래 박스를 연결하는 화살표가 바로 IPC(프로세스 간 통신)입니다.
- Main(시스템)과 Renderer(화면)는 사는 세계가 다릅니다. 그래서 서로 직접 대화할 수 없고, 반드시 이 IPC라는 통로를 통해서만 데이터를 주고받습니다.
Renderer Process 1, 2 ... n (하단 박스들)
- Chromium & Web Page: 아래쪽 박스들은 실제 사용자 눈에 보이는 창입니다.
- 다중 프로세스: 그림에
  
  Process 1
  
  ,
  
  Process 2
  
  ,
  
  Process n
  
  이라고 되어 있죠? 크롬 브라우저에서 탭을 여러 개 띄우듯, Electron 앱도 여러 개의 창을 동시에 띄울 수 있다는 것을 의미합니다.
- 웹 콘텐츠: 이곳이 HTML/CSS로 그려지는 웹페이지 영역임을 나타냅니다.

Electron은 크롬에서 다중 프로세스 아키텍처를 물려받아, 프레임워크가 현대 웹 브라우저와 매우 유사하다.

❔왜 단일 프로세스가 없을까?

웹 브라우저는 매우 복잡한 어플리케이션이다. 웹 콘텐츠를 표시하는 주요 기능 외에도 여러 창(또는 탭)을 관리하고 타사 확장 프로그램을 로드하는 등 많은 보조 작업이 있기 때문이다.

예전에는 브라우저가 이 모든 기능에 대해 일반적으로 단일 프로세스를 사용했었습니다. 이러한 패턴은 탭을 열 때마다 오버헤드가 줄어들었지만, 웹사이트가 다운되거나 걸려있는 경우 전체 브라우저에 영향을 미치기도 했습니다.

이를 다중 프로세스 모델을 채택한 이유이다.

애플리케이션 생명주기

Main Process 는 Electron의 앱 모듈을 통해 애플리케이션의 수명 주기를 제어합니다. 이 모듈은 사용자 지정 애플리케이션 동작을 추가하는 데 사용할 수 있는 다양한 이벤트와 메서드를 제공합니다(예: 애플리케이션 프로그램 종료, 애플리케이션 독 수정 또는 정보 패널 표시).

Electron의 앱 생명주기 흐름은 다음과 같습니다.

앱 초기화

                        tsx
                    
1
2
3
4
5
import { app } from 'electron';

app.whenReady().then(() => {
  // 여기서 BrowserWindow 열고 렌더러 시작
});

모든 창이 닫혔을 때 앱 종료 (Windows/Linux 기준)

                        tsx
                    
1
2
3
app.on('window-all-closed', () => {
  if (process.platform !== 'darwin') app.quit();
});

macOS에서 웹 아이콘을 눌렀을 때 재실행(macOS용 생명주기 대응)

                        tsx
                    
1
2
3
app.on('activate', () => {
  // 창이 없을 경우 새로 열어주기
});

종료 이벤트 처리

                        tsx
                    
1
2
3
app.on('before-quit', () => {
  console.log("앱이 종료되기 직전입니다.");
});

창(Winodw)단위 생명주기

                        tsx
                    
1
2
3
4
5
6
const win = new BrowserWindow({ width: 800, height: 600 });

win.on('focus', () => console.log('창이 활성화됨'));
win.on('blur', () => console.log('창이 비활성화됨'));
win.on('close', () => console.log('창이 닫히려는 중'));
win.on('closed', () => console.log('창이 닫힘'));

이와 마찬가지로 Electron도 앱/창 단위로 생명주기를 관리할 수 있는 API가 제공되며,

앱 시작 → 종료, 창 열림 → 포커스 이동 → 닫힘 등 Android와 유사한 흐름이 존재한다.

Renderer Process에 대해 더 살펴보자

“왜 Electron은 렌더러 → 메인 간 요청을 IPC 통신으로 구현해야만 할까?”

“왜 Android는 이런 구조 안 쓰는데 왜 Electron은 그렇게 복잡해?”

⇒ Electron은 내부적으로 크롬 브라우저 구조를 따라가기 때문입니다.

역할	이름	설명
🎮 게임 본체	메인 프로세스	앱을 관리하고 전체 로직/창을 컨트롤
📺 모니터 화면	렌더러 프로세스	사용자에게 보여지는 화면 (HTML, React, UI 등)

렌더러가 파일 저장을 요청하고 → 메인이 처리하고 → 결과를 다시 렌더러에 알려주는 방식!
이건 IPC (Inter-Process Communication) 로 구현된다.

즉, 렌더러 프로세스는 Electron 앱에서 “브라우저처럼 보이는 모든 화면”을 구성하는 UI 담당 영역입니다.

메인 프로세스가 창을 만들면, 그 창 안에서 렌더러가 실제 화면을 그리는 역할입니다.

⚙️ 핵심 이유: 프로세스 분리 구조 때문

왜 분리했을까?

보안성과 안전성 위해!(단순)

렌더러는 웹페이지처럼 sandbox된 공간

→ Electron은 보안 사고를 막기 위해 렌더러에서 Node 접근을 차단하고, preload를 통한 제한된 브리지 구조를 권장합니다.

Node.js 기능은 메인에서만 허용

→ 예: 파일 시스템 접근, DB 연동, 알림, 네이티브 API 등

📮 그래서 등장한 것이 IPC

IPC(Inter-Process Communication) = 프로세스 간 통신

→ 렌더러가 메인에 “이 작업 해줘”라고 메세지를 보내는 방식

보안상 이득도 크다.

Electron은 최근 몇 년간 보안 이슈로 인해 렌더러에서 Node.js 접근을 원천 차단하는 구조를 권장합니다.

                        tsx
                    
1
2
3
4
webPreferences: {
  nodeIntegration: false, // 렌더러에서 Node 접근 금지
  contextIsolation: true, // 메인과 격리
}

즉, Electron은 웹 환경(렌더러)과 시스템 접근 환경(메인)이 분리되어 있기 때문에, 이 둘의 보안성과 안정성을 유지하기 위해 IPC 통신이 반드시 필요합니다.

⚠️ 보안: 웹 기술이라고 얕보면 큰일 납니다!

중요한 점은 "웹 기술로 만드니까 그냥 웹사이트 만들듯이 하면 되겠지?" 라고 생각했다간 큰코다칩니다. Electron은 웹페이지에 '내 컴퓨터를 조작할 수 있는 권한'을 주는 것이기 때문에 보안이 생명입니다.

안드로이드 앱이 권한(Permission) 설정 잘못하면 스토어에서 거절당하듯, Electron도 개발자가 반드시 지켜야 할 보안 수칙이 있습니다.

Electron을 사용할 때는 Electron이 웹 브라우저가 아니라는 점을 이해하는 것이 가장 중요하다. Electron을 사용하면 익숙한 웹 기술을 사용하여 기능이 풍부한 PC 애플리케이션을 개발할 수 있지만, 코드는 훨씬 더 강력한 기능을 제공한다!

JavaScript(또는 TypeScript)는 파일 시스템, 사용자 셸 등에 접근할 수 있다. 이를 통해 고품질 네이티브 애플리케이션을 개발할 수 있지만, 코드에 부여된 추가 권한에 따라 권한에 따라 내재된 보안 위험이 증가할 수 밖에 없다.

이 점을 염두에 두고, 신뢰할 수 없는 출처의 임의 콘텐츠를 표시하는 것은 Electron이 처리하도록 설계되지 않은 심각한 보안 위험을 초래한다는 점에 유의해야 합니다.

실제로 가장 인기 있는 Electron 앱(Atom, Slack, VsCode 등)은 주로 로컬 콘텐츠(또는 Node.js 통합 없이 신뢰할 수 있고 안전한 원격 콘텐츠)를 표시합니다. 애플리케이션에서 온라인 소스의 코드를 실행하는 경우, 해당 코드가 악성 코드가 아닌지 확인하는 것은 사용자의 책임이기 때문입니다.

(보안적인 부분은 글 하나에 설명을 전부 담지 못하므로 위에서 언급한 내용을 간단히 설명하고 넘어갑니다.)

🚫 1. Node Integration 금지 (`nodeIntegration: false`)

화면(Renderer)에서 Node.js 기능을 직접 쓰게 하면 절대 안 됩니다. 만약 해커가 게시판 글 속에 악성 스크립트를 심었는데(

XSS 공격

), 그 스크립트가

require('fs').deleteAll()

같은 명령어를 실행한다면? 사용자 컴퓨터의 파일이 몽땅 날아갈 수 있습니다.

🛡️ 2. Context Isolation 사용 (`contextIsolation: true`)

앱의 내부 로직과 외부 웹 콘텐츠를 철저히 격리해야 합니다. 이를 위해 Preload Script라는 것을 사용합니다. 이는 마치 렌더러와 메인 사이의 '검문소' 역할을 하여, 허용된 기능만 통과시키고 나머지는 차단합니다.

잠깐 Preload가 뭐냐면...

Electron에서 렌더러 프로세스가 시작되기 전에 실행되는 JavaScript 파일이 있습니다.

이 파일을 통해 렌더러와 메인 프로세스 사이를 안전하게 연결할 수 있습니다.

기본적으로 Electron에서는 렌더러(React UI)가 Node.js의 API(fs, child_process, os 등)에 직접 접근하면 안됩니다.

→ 보안 문제(RCE, 파일 유출, 악성 코드 실행 등)가 생길 수 있기 때문입니다.

그래서 Electron은 보안 강화를 위해 아래 두 가지를 권장합니다.

                        tsx
                    
1
2
3
4
5
6
// BrowserWindow 설정 시
webPreferences: {
  contextIsolation: true,  // ✅ 렌더러와 Node 환경 격리
  nodeIntegration: false,  // ✅ 렌더러에서 Node.js API 차단
  preload: path.join(__dirname, 'preload.js') // ✅ 안전한 API 브릿지 파일
}

→ 여기서 등장하는 게 바로 preload.js 이다!

🧠 preload의 역할 요약

역할	설명
✅ 안전한 API 브릿지	메인 프로세스 기능(Node.js)을 간접적으로 노출
✅ 보안 유지	렌더러가 직접 Node에 접근하지 않음
✅ IPC 연결	렌더러 ↔ 메인 간 메시지 교환 설정

📦 예시: preload.ts

                        tsx
                    
1
2
3
4
5
6
import { contextBridge, ipcRenderer } from 'electron';

contextBridge.exposeInMainWorld('electronAPI', {
  readFile: (path: string) => ipcRenderer.invoke('file:read', path),
  writeFile: (path: string, data: string) => ipcRenderer.invoke('file:write', path),
});

🖥️ 렌더러에서 사용하는 방법

                        tsx
                    
1
const data = await window.electronAPI.readFile('user.txt');

→ 렌더러는 window.electronAPI.readFile()처럼 안전하게 제한된 API만 사용할 수 있게 됩니다.

단, fs.readFileSync() 같은 메서드는 사용은 금물이다! 아래 코드처럼 사용하게 되면…

                        tsx
                    
1
import fs from 'fs'; // ❌ 보안 위협

사용자가 .html, .js 파일을 바꿔치기해서 시스템 파일 접근 시도가 가능해지고 크로스 사이트 스크립팅(XSS) 등 보안 취약점이 발생합니다.

그래서 Electron은 nodeIntegration: false, contextIsolation: true 상태에서 Node.js API는 preload를 통해서만 사용할 수 있게 만든 것입니다.

🔐 preload는 보안의 중심축이다!

항목	설명
위치	src/preload.ts 또는 preload.js
브라우저 설정	BrowserWindow.webPreferences.preload = ...
구성 방식	contextBridge.exposeInMainWorld()
노출 제한	오직 필요한 기능만 expose (예: 파일 읽기, 설정 저장 등)

🎯 결론

preload은 Electron의 보안 게이트웨이로, Node.js API를 렌더러에 안전하게 노출하는 중간 계층이자 렌더러 ↔ 메인 IPC 통신의 설정 장소이기도 하다.

처음엔 C++이나 C#을 피하려고 선택한 '도망처'였지만, 직접 개발해 보니 Electron은 생각보다 훨씬 강력하고 생산적인 도구였습니다.

물론 네이티브 앱보다 메모리를 조금 더 쓰고 용량이 크다는 단점은 있습니다. 하지만 우리가 아는 자바스크립트 지식만으로, 윈도우와 맥을 동시에 정복할 수 있다는 건 개발자로서 엄청난 축복이었습니다. ~~(플러터??)~~

혹시 저처럼 갑작스럽게 PC 앱 개발을 맡게 된 모바일 개발자나 웹 개발자가 계신가요?

npm install electron

을 입력해 보세요. 멋진 데스크톱 앱을 만드실 수 있을 겁니다!

처음 작성하는 글이라 많은 지적 부탁드립니다!

reference)

https://www.electronjs.org/docs/latest/