03. Installer — Windows·macOS·Linux 포맷 지도

“빌드 끝났으니 zip으로 주세요”는 Electron에는 통하지 않는다. 각 OS는 고유의 installer 포맷과 권한 모델, 갱신 메커니즘, 스토어 정책을 요구한다. 이 문서는 9개 주요 포맷의 지도를 그린다.

한 줄 답

Electron의 installer 포맷은 OS × 배포 채널의 교차표다 — Windows: nsis · Squirrel · MSIX · MSI / macOS: dmg · pkg · zip(+notarize) · mas / Linux: AppImage · deb · rpm · snap · flatpak. 어디서 누구에게 배포하는지가 포맷을 결정한다.

Why — 한 포맷으로 끝나지 않는 이유

How — Windows 포맷

NSIS — 사실상 표준 (electron-builder 기본)

• Nullsoft Scriptable Install System — Winamp 시절(1999)의 오픈소스 installer.
• *.exe 단일 파일 — 더블클릭 → 설치 위치 선택 → 진행.
• 시스템 폴더(Program Files)에 설치하면 관리자 권한 필요. 사용자 폴더는 무권한.
• oneClick: true 옵션 — 옵션 화면 없이 즉시 설치 (Slack 모델).

# electron-builder
win:
  target: nsis
nsis:
  oneClick: false             # true = 설치 마법사 생략
  perMachine: false           # false = 사용자 폴더 (관리자 불필요)
  allowToChangeInstallationDirectory: true
  createDesktopShortcut: always
  createStartMenuShortcut: true
  shortcutName: "MyApp"
  uninstallDisplayName: "MyApp ${version}"

Squirrel.Windows — Slack/Discord 모델

• .exe 형태지만 Slack 스타일 — 마법사 없이 바로 설치 + 자동 업데이트가 기본.
• 항상 사용자 폴더 (%LOCALAPPDATA%) — 관리자 권한 0.
• 단점: Program Files에 못 깐다, 기업의 software inventory에서 안 잡힘.
• electron-builder에서는 target: squirrel 또는 forge의 MakerSquirrel 사용.

MSIX — Microsoft Store의 새 포맷

• Windows 10+ 전용. .appx의 후속.
• 완전 샌드박스 — 파일시스템·레지스트리가 virtualize됨.
• Microsoft Store 배포 필수, 또는 직접 사이드로딩 (코드 서명 필수).
• electron-builder target: appx 또는 msi-appx.
• 함정: 샌드박스로 인해 기존에 동작하던 native 모듈이 실패할 수 있음 (registry write 등).

MSI — 기업용 GPO 배포

• Windows Installer의 native 포맷. msiexec /i app.msi /quiet로 대량 배포.
• 기업 IT의 Group Policy로 수천 대에 push 설치 — 그래서 MSI 필수 요구가 종종 들어옴.
• electron-builder target: msi. 대신 auto-update는 까다로워짐 (MSI 자체는 self-update 모델이 아님).

Windows 비교표

How — macOS 포맷

dmg — 사실상 표준 (직접 배포)

• Disk Image — 더블클릭 → 가상 디스크 mount → 사용자가 .app을 Applications로 드래그.
• macOS UX 관례 (background 이미지에 드래그 화살표 그림).
• 서명·notarization 필수 — 안 그러면 Gatekeeper 차단.

# electron-builder
mac:
  target:
    - target: dmg
      arch: [x64, arm64]
    - target: zip          # auto-update에 필요
      arch: [x64, arm64]
dmg:
  background: build/dmg-background.png
  iconSize: 100
  contents:
    - x: 130, y: 220, type: file
    - x: 410, y: 220, type: link, path: /Applications
  window:
    width: 540
    height: 380

pkg — 기업용 / 시스템 설치

• Apple의 flat package. installer -pkg app.pkg -target / 로 비대화형 설치.
• 기업 MDM(Jamf, Kandji) 배포에 필요.
• pre/post install 스크립트 실행 가능 — 권한 상승이 가능.
• mac Developer ID Installer 인증서로 별도 서명 필요 (Application 인증서와 다름).

zip — auto-update의 운반체

• 단순 zip이지만 electron-updater가 macOS auto-update에 zip을 요구한다 (dmg가 아니라).
• Squirrel.Mac이 zip을 다운로드 → 압축 해제 → .app 교체.
• 그래서 mac 배포는 dmg + zip 둘 다 빌드하는 게 일반적.

mas — Mac App Store

• 완전 다른 인증서 (Mac App Distribution + Mac Installer Distribution).
• 강제 샌드박스 — com.apple.security.app-sandbox entitlement.
• 몇몇 Electron API가 막힌다 (autoUpdater, 일부 process API).
• Apple 리뷰 (수일~수주). 대신 signing/notarization은 Apple이 알아서.

macOS 비교표

How — Linux 포맷

AppImage — 가장 portable

• 단일 실행 파일. 설치 없이 더블클릭만으로 실행.
• FUSE 마운트로 읽기 전용 가상 파일시스템 노출.
• desktop integration이 약함 — .desktop 파일이 자동 등록되지 않음 (사용자가 직접 추가 / AppImageLauncher 사용).
• electron-updater 호환. electron-builder 기본.

deb — Debian/Ubuntu

• dpkg -i app.deb 또는 apt install ./app.deb.
• /usr/lib/myapp 같은 시스템 경로에 설치 → 관리자 권한.
• .desktop 등록, MIME 연결 자동.
• signing이 까다로움 (apt repository signing key 별도).

rpm — Fedora/RHEL/SUSE

• rpm -i app.rpm 또는 dnf install ./app.rpm.
• deb과 거의 동일한 모델, 패키지 메타데이터 포맷만 다름.

snap — Canonical (Ubuntu)

• 완전 샌드박스 + 자동 업데이트가 OS 레벨.
• snap store에 publish (또는 사이드로딩).
• 단점: 시작 시간 느림 (squashfs 마운트), interface 권한 명시 필요.

flatpak — Red Hat 진영

• snap의 경쟁자. Flathub가 사실상 표준 스토어.
• runtime을 공유 — Chromium/Electron 자체를 flatpak runtime이 제공할 수도 (앱은 더 작아짐).
• 샌드박스. portal API로 OS 자원 요청.

Linux 비교표

실전 추천: 일반 사용자 대상이면 AppImage 한 개로 시작. 기업/Linux 데스크톱 점유율이 높은 곳에 배포한다면 deb + rpm도 추가. 스토어 노출을 원하면 snap + flatpak.

What — 포맷 결정 체크리스트

실전 추천 매트릭스

What-if — 흔한 함정

Insight — 흥미로운 이야기

“Slack은 Windows에서 Program Files에 안 들어간다 — 일부러”

Slack은 사용자 권한 0으로 설치되어야 했다 (회사 IT가 막아도 사용자가 깔 수 있도록). 그래서 Squirrel.Windows 모델 — %LOCALAPPDATA%\slack에 설치되고 Program Files에는 흔적 없음. 부작용: 기업 IT가 Slack을 software inventory에서 못 잡는다 — 보안팀 입장에선 곤란. 그래서 Slack은 별도 MSI 배포도 제공한다.

“AppImage는 Linus Torvalds가 직접 칭찬한 거의 유일한 desktop packaging”

2014년 DebConf에서 Linus가 “Linux 데스크톱이 안 되는 이유 중 하나가 패키징 지옥” 이라고 말하며 AppImage 비슷한 모델을 직접 옹호했다. 단일 파일, 더블클릭 실행 — 윈도우와 동등한 UX. 그런데도 snap/flatpak이 더 주류가 된 이유는 — 스토어와 자동 업데이트라는 두 가지를 AppImage가 표준화하지 못해서다.

“Mac App Store에서 Electron 앱은 2급 시민이다”

Apple의 MAS 정책은 sandbox + 제한된 entitlements를 요구하는데 — Electron의 일부 기능(예: globalShortcut, 외부 binary spawn, 일부 autoUpdater 흐름)이 그 제약에 막힌다. 그래서 동일 코드의 mas 빌드는 대체로 기능이 일부 빠진 변종이다. 결국 많은 Electron 앱이 MAS 대신 직접 dmg 배포만 선택한다 (Signal, Discord 등).

요약 + Mermaid

Installer는 OS × 배포 채널의 교차표다. 일반 소비자 / 기업 IT / Store의 셋이 각각 다른 포맷을 요구한다. Windows는 NSIS와 Squirrel이 사실상 양대 표준, macOS는 dmg(+zip)가 거의 항상 필수, Linux는 AppImage가 가장 portable. Store 배포는 샌드박스 제약 때문에 동일 코드의 변종이 필요할 수 있다.