Deno Desktop으로 만드는 webview 기반 단일 바이너리 데스크톱 앱

TypeScript 프로젝트를 데스크톱 바이너리로 묶는 `deno desktop`

Deno 2.9에 들어온 deno desktop 서브커맨드는 단일 TypeScript 파일부터 Next.js 프로젝트까지 webview 기반의 자체 포함형 크로스플랫폼 데스크톱 앱으로 컴파일한다. UI는 webview가 담당하고 비즈니스 로직은 Deno 런타임에서 실행된다. 결과물에는 코드와 에셋이 함께 임베드된 단일 실행 바이너리가 포함된다.

Deno v2.9.0은 2026년 6월에 탑재됐지만, 현재 deno desktop은 실험적 상태이며 stable 릴리스에는 포함되지 않는다. 시험하려면 deno upgrade canary로 canary 빌드를 설치해야 한다.

스크립트 또는 웹 프레임워크 프로젝트를 대상으로 실행하면 네이티브 데스크톱 앱을 생성한다. 기반은 deno compile과 같으며, 코드와 에셋을 포함한 standalone 바이너리를 만든다. 인자 없이 deno desktop을 실행하거나 deno desktop .을 실행하면 현재 디렉터리에서 Next.js, Astro, Fresh 등 지원 프레임워크를 감지해 코드 변경 없이 빌드한다.

단일 파일: deno desktop main.ts
프로젝트: deno desktop .
백엔드 선택: deno desktop --backend cef .
크로스 컴파일: deno desktop --target x86_64-pc-windows-msvc .

UI 렌더링과 런타임을 나누는 구조

Deno Desktop은 UI를 webview에, 로직을 Deno V8 isolate에, 배포 단위를 단일 바이너리에 맡긴다. Electron의 메인 프로세스와 렌더러 프로세스 구도와 닮았지만, 런타임은 Node가 아니라 Deno다.

--backend 플래그로 렌더링 엔진을 지정할 수 있다. 기본값인 webview는 macOS의 WebKit, Windows의 WebView2, Linux의 WebKitGTK처럼 OS가 제공하는 네이티브 webview를 사용한다. 이 경우 바이너리 크기는 약 40MB 수준이다.

cef 백엔드는 Chromium Embedded Framework를 번들로 포함한다. Chrome, Electron, Slack을 구동하는 동일 엔진을 .app 또는 앱 디렉터리에 탑재하므로 macOS·Windows·Linux에서 픽셀 단위로 같은 렌더링을 보장한다. 모던 CSS, ES 모듈, WebGPU, WebRTC 등 풀 웹 플랫폼이 필요한 경우에 맞는다.

기본 webview 백엔드로 크기를 줄이더라도 Deno의 Node 호환 계층을 통해 핸들러와 바인딩에서 npm: 임포트를 그대로 사용할 수 있다. 작은 바이너리와 npm 생태계 호환을 함께 가져가는 방식이다.

⤢✕

권한을 바이너리 배포 단위까지 가져가는 방식

deno desktop은 deno run과 같은 런타임 및 권한 플래그를 수용한다. --allow-net, --allow-read 같은 기존 Deno 권한 모델을 데스크톱 앱에도 적용할 수 있다.

컴파일할 때 부여한 권한은 산출 바이너리에 baked-in된다. 배포 후 임의로 확장할 수 없으므로 공급망 위험을 줄이는 방향이다. 파일시스템이나 네트워크에 접근할 때 런타임 권한 프롬프트를 제공할 수도 있어, 최소 권한 원칙을 데스크톱 샌드박싱에 반영할 수 있다.

Electron은 렌더러에 Node 전권을 노출할 위험이 있지만, Deno는 deny-by-default 철학에서 화이트리스트 권한만 허용한다는 점이 다르다.

빌드와 업데이트 파이프라인에서 확인할 지점

기본 webview 백엔드는 약 40MB 바이너리를 만든다. Electron의 80~~200MB와 비교하면 절반 이하이며, OS webview를 공유하므로 Electron의 유휴 200~~300MB보다 메모리 부담도 가볍다.

--target으로 임의 플랫폼을 크로스 컴파일할 수 있고, --all-targets를 사용하면 전 플랫폼 빌드를 한 번에 수행한다. 단일 Linux CI 러너나 개발자 노트북에서 Windows·macOS·Linux 바이너리를 일괄 생산하는 흐름이 가능하다.

Windows .msi, Linux .deb·.rpm 인스톨러는 순수 Rust로 작성돼 플랫폼별 패키징 툴체인 없이 어떤 호스트에서도 생성할 수 있다. macOS notarization과 Windows Authenticode 서명은 별도로 적용해야 하지만, 인스톨러 생성 단계가 단순해져 서명 파이프라인과 통합할 부담은 줄어든다.

자동 업데이트도 내장돼 있다. latest.json 매니페스트와 bsdiff 패치를 배포하면 런타임이 폴링과 적용을 수행하고, 실행에 실패하면 자동 롤백한다.

⤢✕

Electron과 Tauri 사이에서의 선택

Electron은 Chromium과 Node를 함께 번들하므로 렌더링 일관성을 확보하기 쉽지만, 대용량·고메모리라는 비용이 따른다. 기존 Electron 툴링, 서명, CI가 갖춰진 팀에는 여전히 적합하다.

Tauri는 Rust 백엔드와 OS webview를 결합해 크기와 메모리를 최소화한다. 다만 Rust 학습 부담이 있으며, 크기와 모바일이 최우선인 경우에 우위가 있다.

Deno Desktop은 OS webview 기반의 작은 크기와 Deno 런타임의 TypeScript-native 개발 경험, npm 호환을 결합한다. Electron의 비대함과 Tauri의 Rust 요구 사이에 놓인 선택지다. 렌더링의 픽셀 일관성이 필수라면 Electron 또는 deno desktop --backend cef를, 절대적인 크기와 모바일을 우선한다면 Tauri를 검토할 수 있다. TypeScript 단일 언어 스택과 빠른 도입이 목적이라면 Deno Desktop이 맞는다.

항목	deno desktop	Electron	Tauri
렌더링 엔진	OS webview (기본) / CEF (선택)	Chromium 번들	OS webview
백엔드 런타임	Deno (V8 isolate)	Node.js	Rust
바이너리 크기	약 40MB (webview)	80~200MB	2~10MB
메모리 풋프린트	webview 공유 (경량)	120~300MB	30~50MB
주 작성 언어	TypeScript	JS/TS	Rust + JS/TS
권한 모델	Deno deny-by-default	수동 구성 필요	Rust capability
자동 업데이트	내장 (bsdiff)	electron-builder 등 외부	플러그인
크로스 컴파일	`--all-targets` 단일 명령	플랫폼별 빌드	부분 지원
성숙도 (2026)	실험적 (canary)	성숙·검증	성숙·성장

canary 단계에서의 도입 판단

2.9.0에서는 명시적으로 pre-stable canary로 표기된다. API 표면이 안정화 중이고 일부 플랫폼 기능도 계속 추가되고 있어, 현 시점에서 운영 환경에 바로 투입하기에는 이르다.

전략적으로는 TypeScript 단일 스택에서 백엔드 로직과 데스크톱 배포를 통합하려는 흐름으로 볼 수 있다. 내부 도구, 프로토타입, Deno 기반 기존 프로젝트의 데스크톱화부터 우선 검토할 만하다. 미션 크리티컬 상용 배포는 stable 릴리스 이후로 유보하는 편이 적절하다.

Deno Desktop은 웹 기술을 단일 바이너리 데스크톱 앱으로 가져가는 선택지다. 기본 OS webview에서는 약 40MB 수준의 가벼운 바이너리를 만들고, CEF 백엔드에서는 렌더링 일관성을 택할 수 있다. 다만 2.9.0에서는 실험적 canary 단계이므로 안정화 일정, 코드 서명, 생태계 성숙도를 함께 검토해야 한다.