Electrobun v1 — Bun으로 14MB짜리 데스크톱 앱을 만든다
Electron의 번들 크기 문제를 Bun 런타임과 네이티브 웹뷰로 해결하려는 새 프레임워크 Electrobun v1이 출시됐다.
Electron으로 만든 앱을 설치해본 적이 있다면, "왜 이 간단한 앱이 200MB나 되지?"라고 생각해본 적이 있을 것이다. Electron은 Chromium 전체를 번들에 포함하기 때문이다. Electrobun은 이 문제를 정면으로 겨냥한다. Bun 런타임 + OS 네이티브 웹뷰 조합으로 데스크톱 앱의 번들 크기를 14MB까지 줄였다.
Electrobun이 뭔가
Electrobun은 TypeScript로 크로스 플랫폼 데스크톱 애플리케이션을 만드는 프레임워크다. 아키텍처의 핵심은 두 가지다.
- 백엔드: Chromium 대신 Bun 런타임을 사용한다
- 렌더러: Chromium 대신 OS 네이티브 웹뷰를 사용한다 (필요시 CEF로 대체 가능)
비유하면 Electron이 "집을 지을 때 벽돌 공장까지 같이 배송"하는 방식이라면, Electrobun은 "이미 현장에 있는 벽돌(OS 웹뷰)을 가져다 쓰는" 방식이다.
[💡 잠깐! 이 용어는?] 네이티브 웹뷰: macOS의 WKWebView, Windows의 WebView2, Linux의 WebKitGTK처럼 운영체제가 기본 제공하는 웹 렌더링 엔진이다. 앱에 별도의 브라우저 엔진을 포함하지 않아도 되므로 번들 크기가 크게 줄어든다.
숫자로 보는 차이
| 항목 | Electron | Tauri | Electrobun |
|---|---|---|---|
| 번들 크기 | ~200MB | ~3–10MB | 14MB |
| 업데이트 크기 | ~200MB | 가변 | 14KB |
| 시작 시간 | 1–3초 | 0.5–1초 | <50ms |
| 백엔드 런타임 | Node.js | Rust | Bun |
| 렌더러 | Chromium (번들) | OS 웹뷰 | OS 웹뷰 (+ CEF 옵션) |
| 언어 | JavaScript/TS | Rust + JS/TS | TypeScript |
Tauri와 비교하면 번들 크기는 Electrobun이 더 크다. Tauri는 Rust로 작성된 백엔드가 바이너리 크기 면에서 유리하다. 하지만 Electrobun의 차별점은 업데이트 크기다. bsdiff 기반의 커스텀 업데이트 메커니즘으로 업데이트 패치가 14KB 수준이다. 비유하면 전체 택배를 다시 보내는 게 아니라 변경된 페이지만 교체하는 것과 같다.
[💡 잠깐! 이 용어는?] bsdiff: 두 바이너리 파일의 차이점만 추출하는 알고리즘이다. 전체 파일을 다시 다운로드하지 않고 변경된 부분만 패치로 적용할 수 있어서 업데이트 크기를 극단적으로 줄일 수 있다.
코드로 보기
프로젝트 생성
bunx electrobun init my-app
cd my-app
bun run dev윈도우 생성
import { BrowserWindow } from "electrobun/bun";
const win = new BrowserWindow({
title: "My App",
url: "views://mainview/index.html",
});Electron을 써본 개발자라면 익숙한 구조다. BrowserWindow API가 Electron과 의도적으로 유사하게 설계되어 있어서 학습 곡선이 낮다.
네이티브 기능
Electrobun은 C++, Objective-C, Zig로 작성된 네이티브 바인딩을 제공한다. 메뉴 바, 시스템 트레이, 컨텍스트 메뉴, 드래그 가능 영역 같은 네이티브 데스크톱 기능을 TypeScript API로 제어할 수 있다.
import { ApplicationMenu, MenuItem } from "electrobun/bun";
const menu = new ApplicationMenu([
new MenuItem({
label: "File",
submenu: [
new MenuItem({ label: "New", accelerator: "CmdOrCtrl+N" }),
new MenuItem({ label: "Quit", role: "quit" }),
],
}),
]);왜 Bun인가
Electrobun이 Node.js가 아닌 Bun을 선택한 이유는 명확하다.
| 기준 | Node.js | Bun |
|---|---|---|
| 시작 시간 | 수십~수백 ms | 수 ms |
| 빌트인 번들러 | 없음 (webpack/vite 별도) | 내장 |
| TypeScript 실행 | ts-node 필요 | 네이티브 지원 |
| 바이너리 크기 | ~80MB | ~30MB |
데스크톱 앱에서 시작 시간은 특히 중요하다. 사용자가 아이콘을 더블 클릭하고 창이 뜰 때까지의 체감 시간이 앱의 첫인상을 결정한다. Bun의 빠른 시작 시간(<50ms)은 이 부분에서 Electron 대비 확실한 이점이다.
Electron을 버리고 갈아타야 하나
결론부터 말하면, 아직은 아니다. Electrobun은 v1이 막 출시된 단계이고, 생태계가 Electron에 비해 현저히 작다.
| 기준 | Electron 추천 | Electrobun 고려 |
|---|---|---|
| 생태계/플러그인 필요 | 수천 개의 서드파티 패키지 | 기본 API 위주 |
| 팀 규모 | 대규모 팀, 검증된 도구 필요 | 소규모 팀, 실험 가능 |
| 번들 크기 민감 | 상관없음 | 핵심 요구사항 |
| 업데이트 빈도 높음 | 일반적 | 14KB 패치가 큰 이점 |
| Chromium 일관성 필요 | 필수 (금융, 의료 등) | OS 웹뷰 차이 허용 가능 |
Electron의 가장 큰 강점은 Chromium 번들이라는 역설이다. 번들에 포함되어 있으니 모든 사용자가 동일한 렌더링 엔진을 쓴다. 반면 OS 웹뷰는 사용자 환경에 따라 버전이 다를 수 있어서, 금융이나 의료처럼 렌더링 일관성이 법적으로 중요한 분야에서는 Electron이 더 안전하다.
정리
- Electrobun은 Bun + OS 네이티브 웹뷰로 14MB 번들, <50ms 시작, 14KB 업데이트를 달성한 데스크톱 앱 프레임워크다
- Electron과 유사한 API 설계로 학습 곡선이 낮다
- C++/Objective-C/Zig 네이티브 바인딩으로 메뉴 바, 시스템 트레이 등 데스크톱 기능을 지원한다
- 번들 크기와 업데이트 크기가 핵심 요구사항인 프로젝트에서 가장 빛을 발한다
- Electron을 대체하기보다는 가벼운 데스크톱 앱이 필요한 새 프로젝트에서 시도해볼 만하다
참고:
- Electrobun 공식 문서: https://blackboard.sh/electrobun/docs/
- JavaScript Weekly #773: https://javascriptweekly.com/issues/773
- Bun: https://bun.sh/
같은 카테고리 · Tooling
비슷한 주제의 최신 글
태그가 겹치는 글
공통 태그가 많을수록 위에 보인다