Electrobun v1 — Bun으로 14MB짜리 데스크톱 앱을 만든다
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/
관심 있을 만한 포스트
Bun이 빠른 건 맞다 — 그런데 당신의 이벤트 루프가 문제다
Bun으로 바꿔도 p99가 개선되지 않는 이유. 런타임 선택보다 먼저 봐야 할 진짜 병목 지점들.
달리는 차의 엔진을 바꾸다 — Nx 모노레포에서 Bun 도입까지의 여정
Nx 18에서 21까지 버전 업그레이드와 Bun 패키지 매니저 도입을 동시에 진행한 컬리의 마이그레이션 전략과 실전 이슈를 정리한다.
Bun vs Node.js vs Deno — 뭐가 다른지, 그래서 뭘 쓰면 좋은지 (2026 기준)
런타임 3대장 비교: 호환성(Node), 속도/번들(Bun), 올인원/보안(Deno). 팀/프로덕트 상황별 선택 기준과 체크리스트까지 정리.
AI 코딩의 맹점 — Artifacts 없이 에이전트는 기억을 잃는다
PRD, ADR, TDD가 AI 코딩 워크플로우에서 왜 선택이 아닌 필수인지, 실전 구조와 함께 살펴본다.
Next-Translate 3.0 — Turbopack과 App Router를 위한 i18n 재건
1년간 공백 후 돌아온 Next-Translate 3.0이 Turbopack 지원, 비동기 params, App Router 안정화를 한 번에 처리하는 방법.
V8 WasmGC 투기적 최적화 — 가상 메서드를 인라인으로 만드는 법
V8이 WasmGC의 가상 메서드 디스패치에 투기적 인라이닝을 도입해 Dart와 Java 앱에서 최대 8% 성능을 끌어낸 방법.
Vinext — Vite 위에서 Next.js를 1주일 만에 다시 만든 이야기
Cloudflare가 AI와 함께 단 일주일, $1,100의 API 비용으로 Next.js 호환 프레임워크를 Vite 위에 구축한 과정.
Tsonic — TypeScript를 네이티브 바이너리로 컴파일하는 실험
TypeScript → C# → NativeAOT 파이프라인으로 네이티브 실행 파일을 만드는 Tsonic. 어떻게 동작하고, 어떤 한계가 있는지 살펴봤다.