Electron이란 무엇인가

Electron은 Chromium을 Node.js와 함께 하나의 런타임 (runtime)으로 패키징합니다. HTML, CSS, JavaScript로 앱을 작성하고 이를 Windows, macOS, Linux용 네이티브 데스크톱 실행 파일로 배포할 수 있습니다. VS Code, Slack, Figma의 데스크톱 클라이언트 — 이 모두가 Electron으로 만들어졌습니다.

세 가지 핵심 파일

my-electron-app/
├── index.html    ← 앱 창에서 렌더링되는 UI
├── main.js       ← Node.js 메인 프로세스 (main process) — 창 관리, 앱 라이프사이클 (lifecycle)
...

빠른 설정:

mkdir my-electron-app && cd my-electron-app
npm init -y
npm install --save-dev electron

package.json에 추가:

{ "scripts": { "start": "electron ." } }

최소한의 main.js:

const { app, BrowserWindow } = require('electron');
const path = require('path');

...

npm start를 실행하면 — 창이 열리고 앱이 실행됩니다. 이것이 다른 모든 것들이 구축되는 기초입니다.

메인 프로세스 vs 렌더러 프로세스 (Main vs. Renderer Process)

메인 프로세스 (Main process) — 앱당 하나가 존재하며, Node.js에서 실행됩니다. 창을 생성하고, OS API (파일 시스템, 트레이, 알림)를 처리하며, 앱의 라이프사이클 (lifecycle)을 관리합니다.

렌더러 프로세스 (Renderer process) — 창당 하나가 존재하며, Chromium에서 실행됩니다. 이곳에서 HTML과 프론트엔드 JS가 실행됩니다. 기본적으로 Node.js로부터 샌드박스 (sandboxed) 처리되어 격리되어 있습니다.

IPC — 프로세스들이 서로 통신하는 방식입니다. ipcMain과 ipcRenderer가 프로세스 간에 메시지를 전달합니다. 업데이트 UI를 연결하려면 이것이 필요할 것입니다.

// main.js — 렌더러 메시지 수신
const { ipcMain } = require('electron');
ipcMain.on('check-for-updates', () => autoUpdater.checkForUpdates());
...

패키징 (Packaging)

배포하기 전에 앱은 플랫폼별 설치 파일로 패키징되어야 합니다. 두 가지 도구가 주를 이룹니다:

• electron-forge — 공식적으로 권장되며, 설정이 더 간단하고 빌드(build) + 패키지(package) + 게시(publish)를 하나의 워크플로우 (workflow)로 처리합니다.
• electron-builder — 설정이 더 자유로우며, 복잡한 서명(signing)/배포 요구 사항에 더 적합합니다.

특별한 이유가 없다면 새로운 프로젝트는 electron-forge로 시작하세요.

코드 서명 (Code Signing)

macOS와 Windows 모두 코드 서명 (Code Signing)이 필요합니다. 이를 건너뛰면 사용자에게 보안 경고가 표시되며, macOS에서는 앱 실행이 완전히 차단될 수 있습니다.

macOS — 패키징 시점에 Apple 개발자 인증서 (Apple Developer certificate)로 서명합니다. Catalina 버전 이후부터는 공증 (Notarization, Apple의 보안 스캔)도 필수입니다.

Windows — 배포 가능한 설치 프로그램 (installer)에 서명합니다. DigiCert, Sectigo 또는 유사한 업체로부터 인증서를 발급받아 빌드 설정에 구성하세요.

두 도구 모두 환경 변수 (environment variables)에서 서명 자격 증명을 읽어옵니다. 자격 증명을 코드베이스에 포함하지 마세요.

자동 업데이트 설정 (Auto-Update Setup)

Electron의 자동 업데이트는 무료이며 내장되어 있습니다. 네 가지 요구 사항이 있습니다:

1. 앱이 macOS 또는 Windows에서 실행됨
2. GitHub 저장소 (repo)가 존재함 (공개 저장소 = 추가 설정 불필요, 비공개 저장소 = GH_TOKEN 설정 필요)
3. 빌드 결과물이 GitHub Releases에 게시됨
4. 빌드 결과물에 코드 서명이 되어 있음

electron-forge를 사용하는 경우

npm install --save-dev @electron-forge/publisher-github

forge.config.js:

module.exports = {
  publishers: [
    {
...

package.json 스크립트:

{ "scripts": { "publish": "electron-forge publish" } }

electron-builder를 사용하는 경우

npm install --save-dev electron-builder

package.json:

{
  "build": {
    "appId": "com.yourcompany.yourapp",
...

앱 내 업데이트 이벤트 연결 (Wiring Update Events in the App)

const { autoUpdater } = require('electron-updater');

app.whenReady().then(() => {
...

렌더러 (Renderer) 측:

ipcRenderer.on('update-available', (event, version) => {
  const userConfirmed = confirm(`Version ${version} is ready. Restart to install?`);
  if (userConfirmed) ipcRenderer.send('install-update');
...

항상 사용자에게 확인을 요청하세요. 세션 도중에 강제로 종료해서는 안 됩니다.

GitHub Actions CI

모든 버전 태그 (version tag)에 대해 릴리스를 자동화하세요:

name: Release

on: 
...

릴리스 태그를 생성하면 (git tag v1.2.0 && git push --tags), 워크플로 (workflow)가 실행되어 양쪽 플랫폼용 빌드를 수행하고, 서명한 뒤 GitHub Release를 생성합니다. 실행 중인 인스턴스는 다음 체크 시점에 자동으로 업데이트됩니다.

배포 전 알아두면 좋은 사항들

전체 업데이트 vs. 델타 업데이트 (Full vs. delta updates) — 기본적으로 매 업데이트마다 전체 설치 프로그램 (full installer)을 다운로드합니다. 앱의 크기가 큰 경우, 다운로드 크기를 줄이기 위해 델타 업데이트 (delta updates)를 구성하십시오.

업데이트 채널 (Update channels) — GitHub의 프리릴리스 (pre-releases)와 electron-updater의 channel 옵션을 사용하여, 모든 사용자에게 배포하기 전에 beta 채널을 운영할 수 있습니다.

macOS 공증 (macOS notarization) — Catalina 버전 이후부터 필수 사항이며, CI (지속적 통합) 시간에 몇 분을 추가하고 Apple Developer 계정 설정이 필요합니다. 이를 사전에 계획하십시오.

강제 재시작 금지 — quitAndInstall()은 즉시 실행됩니다. 사용자에게 항상 작업 내용을 저장할 기회를 먼저 주십시오.

Electron으로 데스크톱 앱을 빌드하시나요?

Innostax에서는 두 가지 방식을 모두 사용하여 빌드합니다. 선택은 우리가 선호하는 것이 아니라, 프로젝트가 실제로 무엇을 필요로 하는지에 따라 결정됩니다. electron-forge와 electron-builder 중 어느 것이 더 적합한지는 실제 배포 요구 사항에 따라 달라집니다.

현재 구축 중인 프로젝트에 적합한 스택을 고민하고 있다면, innostax.com/contact에서 상담을 시작하는 것이 좋습니다.

원문은 Innostax Engineering Blog에 게시되었습니다.