Deno Desktop: 런타임 전쟁이 데스크톱으로 번지다
Deno Desktop: 런타임 전쟁이 데스크톱으로 번지다
단일 명령
deno desktop main.ts가 TypeScript 프로젝트를 플랫폼별 단일 실행 파일로 묶는다. 인프로세스 채널과 듀얼 백엔드라는 무기는 Electron 과 Tauri 사이의 어느 자리를 노리는가.
도입 — 데스크톱 앱 프레임워크의 난립과 Deno 의 참전
2026 년 6 월 22 일 (KST), Deno 공식 문서에 추가된 한 페이지가 Hacker News 첫 페이지의 최상단을 차지했다. 제목은 “Deno Desktop” 이고, 1111 점과 395 개의 댓글을 받았다. 페이지 자체는 기능 소개에 가깝지만, 그 짧은 문서가 그렇게 큰 호응을 받은 까닭은 한 가지 오래된 피로 — 데스크톱 앱을 웹 기술로 만드는 방식이 너무 많고, 어느 것도 만족스럽지 않다는 피로 — 를 정확히 건드렸기 때문이다.
지난 10 년간 이 자리는 두 진영의 싸움이었다. 한쪽에는 Chromium 을 통째로 묶어 일관성을 사는 대신 100MB 가 넘는 바이너리와 무거운 메모리를 감수하는 Electron 이 있었다. VS Code, Slack, Discord 가 모두 이 길을 걸었다. 다른 한쪽에는 Rust 와 OS 네이티브 웹뷰로 수 MB 단위의 작은 바이너리를 만드는 Tauri 가 있었다. 작지만 Rust 의 학습 곡선과 플랫폼별 웹뷰 불일치라는 대가를 치렀다. Deno Desktop 은 이 두 진영의 정확히 가운데 — Tauri 의 작은 바이너리와 Electron 의 JavaScript 생태계를 동시에 — 를 노린다고 선언하며 참전했다. 런타임 전쟁이 서버를 넘어 데스크톱으로 번진 첫 신호다.
인프로세스 채널과 듀얼 백엔드 — Deno Desktop 의 기술 구조
Deno Desktop 은 Deno v2.9.0 에 포함된 CLI 도구다. 동작의 골자는 단순하다. deno desktop main.ts 라는 한 줄이 프로젝트 코드와 Deno 런타임, 그리고 웹 렌더링 엔진을 하나의 플랫폼별 실행 파일로 묶는다. 별도의 패키저, 별도의 번들러, 별도의 네이티브 빌드 단계가 보이지 않는다는 점이 이 도구가 노리는 첫 인상이다.
가장 무겁게 강조되는 기술적 주장은 통신 구조에 있다. Deno Desktop 은 백엔드 로직과 UI 사이의 통신이 “소켓 기반 IPC 가 아니라 인프로세스 채널 (in-process channel) 을 통한다” 고 명시한다. 이 한 문장이 Electron 과 Tauri 모두를 겨냥한다. Electron 은 메인 프로세스와 렌더러 프로세스가 분리되어 있고, Tauri 역시 Rust 코어와 웹뷰가 별개의 경계로 나뉘어 있다. 두 구조 모두 프로세스 경계를 넘는 메시지 전달 — 직렬화, 역직렬화, 컨텍스트 전환 — 의 비용을 치른다. Deno Desktop 은 백엔드와 UI 가 같은 프로세스 안에서 채널로 직접 대화하게 만들어 그 교차 프로세스 오버헤드 자체를 제거하겠다는 설계를 내세운다. 자주 오가는 호출이 많은 앱일수록 이 차이는 누적된다는 것이 이 주장의 핵심이다.
렌더링 백엔드는 둘 중에서 고르게 되어 있다. 기본값은 OS 네이티브 WebView 다. macOS 의 WKWebView, Windows 의 WebView2, Linux 의 WebKitGTK 를 그대로 빌려 쓰므로 바이너리가 작아진다. 다른 선택지는 Chromium 을 CEF (Chromium Embedded Framework) 로 번들하는 길이다. 이 경우 바이너리는 커지지만 모든 플랫폼에서 렌더링 결과가 동일해진다. 즉 같은 도구 안에서 “작은 바이너리 + 플랫폼 의존” 과 “큰 바이너리 + 일관성” 을 빌드 옵션으로 전환할 수 있다는 것이다. 이는 Electron 과 Tauri 가 각각 한쪽 끝에 고정해 둔 선택을 하나의 도구가 양손에 쥐겠다는 시도다.
프레임워크 자동 감지는 채택 장벽을 낮추는 쪽에 무게를 둔다. Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, Vite SSR 을 코드 수정 없이 인식한다고 문서는 밝힌다. 기존 웹 프로젝트를 그대로 가리키면 데스크톱 앱으로 감싸 준다는 약속이다. 여기에 Deno 의 Node 호환 레이어가 더해진다. 전체 npm 생태계를 작은 기본 바이너리 위에서 끌어 쓸 수 있다는 조합은, “JavaScript 생태계는 Electron, 작은 바이너리는 Tauri” 라는 종래의 양자택일을 무너뜨리려는 의도가 분명하다.
배포 측면에서도 통합을 내세운다. 단일 머신에서 macOS, Windows, Linux 세 플랫폼을 모두 크로스 컴파일할 수 있고, 그 과정에서 로컬 네이티브 백엔드 빌드를 요구하지 않는다. Tauri 가 종종 플랫폼별 빌드 환경을 강제했던 지점을 정면으로 겨눈 셈이다. 마지막으로 바이너리 디프 기반 자동 업데이트가 내장되어 있고, 실패 시 자동 롤백까지 포함한다. 업데이트 인프라를 외부 서비스나 별도 라이브러리로 떼어 두지 않고 빌더 안에 넣었다는 점이 Deno 의 “통합” 전략을 잘 보여 준다.
Electron, Tauri, Deno Desktop — 3 파전의 트레이드오프
세 도구를 같은 표 위에 올리면 차이가 선명해진다. 비교의 축은 셋이다. 바이너리 크기, 생태계, 개발자 경험 (DX).
바이너리 크기. Electron 은 Chromium 전체를 묶기 때문에 가장 작은 앱조차 100MB 를 넘기는 일이 흔하고 메모리 사용량도 크다. Tauri 는 OS 웹뷰를 빌려 수 MB 단위까지 줄인다. Deno Desktop 의 기본값 (네이티브 WebView) 은 Tauri 와 같은 진영에 선다 — 작다. 그러나 결정적 차이는 Deno 가 같은 도구에서 Chromium 번들 옵션도 제공한다는 점이다. 크기와 일관성 사이의 선택을 빌드 시점으로 미룰 수 있다는 것은, 종래에 도구 선택 시점에서 강제되던 결정을 뒤로 유예해 준다. 다만 이 유연성에는 함정이 있다. 네이티브 WebView 를 고른 순간 Deno Desktop 도 Tauri 와 똑같은 문제 — 플랫폼별 웹뷰 불일치, 특히 Linux 의 WebKitGTK 가 보이는 렌더링과 기능 격차 — 를 그대로 물려받는다. 작은 바이너리는 공짜가 아니다.
생태계. Electron 의 가장 큰 자산은 검증된 JavaScript 생태계와 방대한 npm 패키지, 그리고 VS Code 급 거대 앱이 실증한 안정성이다. Tauri 의 약점이 바로 여기다. 프론트엔드는 웹 기술로 자유롭지만, 백엔드를 Rust 로 작성해야 하므로 JavaScript 만 다루던 팀에게는 진입 장벽이 가파르다. Deno Desktop 은 이 지점을 정확히 노린다. 백엔드도 TypeScript 이고, Node 호환 레이어로 npm 을 거의 그대로 쓸 수 있다. Rust 없이 작은 바이너리를 얻는다는 약속은 Tauri 가 비워 둔 자리를 정조준한 것이다. 관건은 Node 호환의 신뢰도다. 네이티브 모듈이나 까다로운 의존성에서 호환 레이어가 어디까지 버티는지가 실전 채택의 분기점이 될 것이고, HN 댓글에서도 이 호환성의 한계가 반복해서 제기되는 의제다.
개발자 경험. Tauri 는 Rust 툴체인과 Cargo, 플랫폼별 빌드 환경을 요구하는 만큼 초기 설정의 마찰이 크다. Electron 은 JavaScript 친화적이지만 패키징, 코드 서명, 자동 업데이트를 위해 electron-builder 같은 별도 생태계를 조립해야 한다. Deno Desktop 의 차별점은 이 모든 것을 단일 명령과 단일 런타임 안으로 흡수했다는 점이다. TypeScript 우선, 단일 머신 크로스 컴파일, 내장 자동 업데이트와 롤백은 모두 “설정을 줄이고 한 도구로 끝낸다” 는 Deno 의 일관된 철학의 연장이다.
그러나 냉정한 질문이 남는다. 인프로세스 채널, 프레임워크 자동 감지, 내장 자동 업데이트 — 이 세 가지가 진짜 구조적 우위인가, 아니면 기능 평준화 (feature parity) 의 따라잡기인가. Electron 도 시간이 지나며 업데이트와 패키징 도구가 성숙했고, Tauri 도 사이드카와 플러그인으로 생태계를 메워 왔다. Deno Desktop 의 인프로세스 채널은 분명 설계상 더 깔끔하지만, 다수의 데스크톱 앱에서 IPC 오버헤드가 실제 병목인 경우는 드물다는 반론도 가능하다. “또 하나의 데스크톱 프레임워크가 정말 필요한가” 라는 HN 의 단골 회의론은 여기서 나온다. Deno Desktop 의 진짜 시험대는 벤치마크 숫자가 아니라, 기존 Tauri/Electron 앱을 옮길 만큼의 충분한 이유를 제시하느냐다.
런타임 전쟁의 큰 그림 — Node, Deno, Bun, 그리고 통합 전략
Deno Desktop 을 한 발 물러서서 보면, 이것은 데스크톱 도구 이전에 런타임 전쟁의 한 수다. 지난 몇 년간 JavaScript 런타임 시장은 Node 의 사실상 독점에서 Deno 와 Bun 이 가세하는 삼파전으로 재편되었다. Bun 은 속도와 올인원 툴링으로, Deno 는 보안 기본값과 TypeScript 일급 지원, 그리고 통합 도구 묶음으로 차별화를 시도해 왔다.
Deno 의 전략은 일관된다. 런타임 자체보다 그 위에 얹는 통합 기능으로 차별화한다는 것이다. 포매터, 린터, 테스트 러너, 번들러를 이미 단일 바이너리에 넣었고, Deno Deploy 라는 엣지 배포 서비스를 붙였으며, 이제 Desktop 으로 클라이언트 앱 영역까지 손을 뻗는다. Node 가 “최소한의 런타임 + 거대한 npm 생태계” 모델이라면, Deno 는 “런타임 + 공식 통합 도구 일습” 모델이다. Desktop 은 이 모델의 자연스러운 확장이다 — 같은 런타임으로 서버도, 엣지도, 데스크톱도 만든다는 그림.
이 통합 전략은 비즈니스 모델과 떼어 놓을 수 없다. Deno 의 수익원은 Deno Deploy 를 비롯한 호스팅과 클라우드 서비스다. 무료 오픈소스 런타임으로 생태계를 넓히고, 그 생태계가 모이는 길목에서 유료 서비스로 수익을 거두는 구조다. Desktop 같은 신규 기능은 그 자체로 직접 매출을 내지 않더라도, Deno 를 “이것만 쓰면 다 된다” 는 플랫폼으로 만들어 록인 (lock-in) 의 중력을 키운다. HN 댓글에서 Deno 의 사업 동기에 대한 의구심이 반복되는 것도 이 맥락이다 — 통합은 편리하지만, 한 회사의 도구 묶음에 얼마나 깊이 들어갈지는 별개의 판단이다.
향후 전망의 핵심 변수는 둘이다. 첫째, Node 호환 레이어가 실전 npm 의존성을 얼마나 견고하게 버티는가. 둘째, 네이티브 WebView 의 플랫폼 불일치 — 특히 Linux — 를 Deno 가 얼마나 매끄럽게 관리하느냐. 이 둘이 풀리면 Deno Desktop 은 Tauri 가 비워 둔 “Rust 없는 작은 앱” 시장을 실제로 가져갈 수 있다. 풀리지 않으면 또 하나의 흥미로운 실험으로 남는다.
결론
Deno Desktop 은 데스크톱 앱 프레임워크 경쟁의 새 변수이자, 동시에 런타임 전쟁이 서버를 넘어 클라이언트로 번졌다는 신호다. 인프로세스 채널이라는 설계상의 우아함, 듀얼 백엔드라는 유연성, 단일 명령 안에 흡수된 크로스 컴파일과 자동 업데이트는 분명 매력적인 조합이다. Tauri 의 작은 바이너리와 Electron 의 생태계 사이, 그 누구도 깔끔하게 차지하지 못한 빈자리를 정확히 겨냥한다는 점에서 전략의 좌표는 또렷하다.
그러나 좌표가 또렷하다는 것과 그 자리를 실제로 차지한다는 것은 다른 문제다. 네이티브 WebView 를 고르는 순간 Deno 도 Linux 웹뷰 불일치라는 Tauri 의 오래된 짐을 똑같이 진다. Node 호환의 신뢰도는 아직 증명 단계다. 그리고 “또 하나의 프레임워크” 라는 회의론은, 인프로세스 채널의 이점이 다수의 앱에서 체감되지 않는 한 쉽게 사라지지 않는다. 결국 진짜 질문은 이것이다 — 이것은 구조적 우위인가, 따라잡기 평준화인가. 1111 점은 그 질문에 대한 관심의 크기였지 답은 아니었다. 답은 첫 번째 진지한 프로덕션 앱이 Deno Desktop 위에서 출시되고, 그 팀이 다시 Tauri 나 Electron 으로 돌아가지 않을 때 비로소 나온다.
출처: