Electrobun v1 — Bun으로 14MB짜리 데스크톱 앱을 만든다

8 min read
ElectrobunBun데스크톱 앱ElectronTauri
Electrobun v1 — Bun으로 14MB짜리 데스크톱 앱을 만든다

Electron으로 만든 앱을 설치해본 적이 있다면, "왜 이 간단한 앱이 200MB나 되지?"라고 생각해본 적이 있을 것이다. Electron은 Chromium 전체를 번들에 포함하기 때문이다. Electrobun은 이 문제를 정면으로 겨냥한다. Bun 런타임 + OS 네이티브 웹뷰 조합으로 데스크톱 앱의 번들 크기를 14MB까지 줄였다.

Electrobun이 뭔가

Electrobun은 TypeScript로 크로스 플랫폼 데스크톱 애플리케이션을 만드는 프레임워크다. 아키텍처의 핵심은 두 가지다.

  1. 백엔드: Chromium 대신 Bun 런타임을 사용한다
  2. 렌더러: Chromium 대신 OS 네이티브 웹뷰를 사용한다 (필요시 CEF로 대체 가능)

비유하면 Electron이 "집을 지을 때 벽돌 공장까지 같이 배송"하는 방식이라면, Electrobun은 "이미 현장에 있는 벽돌(OS 웹뷰)을 가져다 쓰는" 방식이다.

[💡 잠깐! 이 용어는?] 네이티브 웹뷰: macOS의 WKWebView, Windows의 WebView2, Linux의 WebKitGTK처럼 운영체제가 기본 제공하는 웹 렌더링 엔진이다. 앱에 별도의 브라우저 엔진을 포함하지 않아도 되므로 번들 크기가 크게 줄어든다.


숫자로 보는 차이

항목ElectronTauriElectrobun
번들 크기~200MB~3–10MB14MB
업데이트 크기~200MB가변14KB
시작 시간1–3초0.5–1초<50ms
백엔드 런타임Node.jsRustBun
렌더러Chromium (번들)OS 웹뷰OS 웹뷰 (+ CEF 옵션)
언어JavaScript/TSRust + JS/TSTypeScript

Tauri와 비교하면 번들 크기는 Electrobun이 더 크다. Tauri는 Rust로 작성된 백엔드가 바이너리 크기 면에서 유리하다. 하지만 Electrobun의 차별점은 업데이트 크기다. bsdiff 기반의 커스텀 업데이트 메커니즘으로 업데이트 패치가 14KB 수준이다. 비유하면 전체 택배를 다시 보내는 게 아니라 변경된 페이지만 교체하는 것과 같다.

[💡 잠깐! 이 용어는?] bsdiff: 두 바이너리 파일의 차이점만 추출하는 알고리즘이다. 전체 파일을 다시 다운로드하지 않고 변경된 부분만 패치로 적용할 수 있어서 업데이트 크기를 극단적으로 줄일 수 있다.


코드로 보기

프로젝트 생성

electrobun-init.sh
bunx electrobun init my-app
cd my-app
bun run dev

윈도우 생성

src/main.ts
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로 제어할 수 있다.

src/menu.ts
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.jsBun
시작 시간수십~수백 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을 대체하기보다는 가벼운 데스크톱 앱이 필요한 새 프로젝트에서 시도해볼 만하다

참고:

관심 있을 만한 포스트

Bun이 빠른 건 맞다 — 그런데 당신의 이벤트 루프가 문제다

Bun으로 바꿔도 p99가 개선되지 않는 이유. 런타임 선택보다 먼저 봐야 할 진짜 병목 지점들.

BunNode.js

달리는 차의 엔진을 바꾸다 — Nx 모노레포에서 Bun 도입까지의 여정

Nx 18에서 21까지 버전 업그레이드와 Bun 패키지 매니저 도입을 동시에 진행한 컬리의 마이그레이션 전략과 실전 이슈를 정리한다.

NxBun

Bun vs Node.js vs Deno — 뭐가 다른지, 그래서 뭘 쓰면 좋은지 (2026 기준)

런타임 3대장 비교: 호환성(Node), 속도/번들(Bun), 올인원/보안(Deno). 팀/프로덕트 상황별 선택 기준과 체크리스트까지 정리.

BunNode.js

AI 코딩의 맹점 — Artifacts 없이 에이전트는 기억을 잃는다

PRD, ADR, TDD가 AI 코딩 워크플로우에서 왜 선택이 아닌 필수인지, 실전 구조와 함께 살펴본다.

AI 코딩Artifacts

Next-Translate 3.0 — Turbopack과 App Router를 위한 i18n 재건

1년간 공백 후 돌아온 Next-Translate 3.0이 Turbopack 지원, 비동기 params, App Router 안정화를 한 번에 처리하는 방법.

Next.jsi18n

V8 WasmGC 투기적 최적화 — 가상 메서드를 인라인으로 만드는 법

V8이 WasmGC의 가상 메서드 디스패치에 투기적 인라이닝을 도입해 Dart와 Java 앱에서 최대 8% 성능을 끌어낸 방법.

V8WebAssembly

Vinext — Vite 위에서 Next.js를 1주일 만에 다시 만든 이야기

Cloudflare가 AI와 함께 단 일주일, $1,100의 API 비용으로 Next.js 호환 프레임워크를 Vite 위에 구축한 과정.

VinextNext.js

Tsonic — TypeScript를 네이티브 바이너리로 컴파일하는 실험

TypeScript → C# → NativeAOT 파이프라인으로 네이티브 실행 파일을 만드는 Tsonic. 어떻게 동작하고, 어떤 한계가 있는지 살펴봤다.

TypeScriptNativeAOT