Deno, 웹 프로젝트를 데스크톱 앱으로 묶는 `deno desktop` 공개

• Deno가 deno desktop을 공개함. 한 줄로 말하면 Deno 프로젝트를 플랫폼별 데스크톱 앱 바이너리로 묶어주는 기능임.

  • 대상은 꽤 넓음. TypeScript 파일 하나짜리 앱부터 Next.js 같은 풀스택 웹 프로젝트까지 포함됨.
  • 결과물에는 앱 코드, Deno 런타임, 웹 렌더링 엔진이 함께 들어감.
  • macOS, Windows, Linux용으로 각각 재배포 가능한 바이너리를 만드는 그림임.

• 단, 지금 당장 안정 버전 기능은 아님. Deno v2.9.0 canary에 들어간 상태임.

  • 써보려면 deno upgrade canary로 canary 빌드를 설치해야 함.
  • CLI 명령, 설정 키, TypeScript API는 안정화 전까지 바뀔 수 있다고 못 박아둠.
  • 실서비스 빌드 파이프라인에 바로 박아 넣기보다는, 지금은 구조와 방향성을 보는 단계에 가까움.

• Deno가 노리는 포지션은 꽤 명확함. Electron, Tauri, Electrobun 계열의 장단점을 다시 조합하겠다는 쪽임.

  • Electron은 웹 기술을 그대로 쓰기 좋지만 바이너리가 크다는 이미지가 강함.
  • Tauri류는 작은 바이너리를 노리지만 생태계나 플랫폼 지원, 업데이트, 프레임워크 연동에서 신경 쓸 게 생김.
  • Deno는 “작게 시작하되 npm 생태계와 Node 호환성은 가져간다”는 식으로 각을 잡음.

• 기본 렌더링 백엔드는 운영체제 내장 WebView를 씀. 그래서 기본값은 작은 바이너리를 지향함.

  • macOS, Windows, Linux에 이미 있는 웹뷰를 활용하는 방식이라 Chromium 전체를 매번 들고 다니는 구조가 아님.
  • 그래도 npm 생태계는 Deno의 Node 호환 레이어를 통해 쓸 수 있다고 설명함.
  • 반대로 모든 플랫폼에서 동일한 렌더링 결과가 중요하면 CEF 기반 Chromium 백엔드를 선택할 수 있음.

• 웹 프레임워크 자동 감지가 꽤 공격적임. 기존 웹앱을 데스크톱으로 가져가는 흐름을 정면으로 겨냥함.

  • 문서에 언급된 대상은 Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, Vite SSR 등임.
  • release 모드에서는 프로덕션 서버를 실행하고, 개발 모드에서는 --hmr로 dev server와 hot reload를 붙임.
  • 핵심은 “기존 웹 프로젝트를 바꾸지 않고 desktop으로 돌린다”는 주장임. 이게 진짜 잘 되면 내부툴이나 개발자용 앱 만들 때 꽤 편해짐.

• UI와 백엔드 통신도 흥미로운 지점임. 소켓 기반 IPC 대신 인프로세스 바인딩을 쓴다고 함.

  • WebView에서 bindings.<name>() 형태로 Deno 코드를 호출하는 모델이 문서에 등장함.
  • 값은 경계를 넘을 때 여전히 인코딩되지만, 별도 프로세스 사이를 왕복하는 구조는 아니라는 게 포인트임.
  • 데스크톱 웹앱에서 자주 나오는 “프론트와 백엔드 사이 호출 비용”을 줄이려는 설계로 읽힘.

• 가장 작은 예제는 진짜 작음. Deno.serve()로 HTML을 반환하고 deno desktop main.ts를 실행하면 창이 뜸.

  • 예제는 new Response("<h1>Hello, desktop</h1>")를 반환하는 단일 파일 앱임.
  • 컴파일된 바이너리는 로컬 HTTP 서버를 가리키는 창을 열고, 사용자는 ./main 또는 Windows의 main.exe를 실행하면 됨.
  • Deno.serve()가 WebView가 이동하는 주소에 자동으로 바인딩되기 때문에 포트나 호스트를 직접 넘기지 않아도 된다고 설명함.

• 배포 쪽 기능도 단순 패키징에서 끝나지 않음. 자동 업데이트를 런타임 레벨에서 제공하려는 게 큼.

  • latest.json 매니페스트 하나와 bsdiff 패치를 배포하면 런타임이 polling, patch 적용, 실패한 실행 후 rollback까지 처리하는 구조임.
  • 데스크톱 앱에서 업데이트는 늘 귀찮은 부분인데, 이걸 기본 스토리로 넣겠다는 건 꽤 실용적임.
  • Electron 앱이든 Tauri 앱이든 업데이트 파이프라인에서 삽질한 팀이면 이 부분에 바로 눈이 갈 만함.

• 문서상 기능 범위는 데스크톱 앱에서 기대하는 기본 부품을 꽤 많이 포함함.

  • 창 생명주기와 다중 창은 Deno.BrowserWindow 쪽에서 다룸.
  • 애플리케이션 메뉴, 컨텍스트 메뉴, 트레이, macOS dock, 네이티브 dialog도 범위에 들어감.
  • prompt(), alert(), confirm()을 네이티브 팝업으로 연결하고, Web Notification API로 OS 알림도 보낼 수 있음.
  • Deno 런타임과 WebView 양쪽에 붙는 통합 DevTools, 에러 리포팅, installer와 output format까지 문서 섹션이 잡혀 있음.

• 결론적으로 deno desktop은 “Deno로 Electron 대체재 하나 더 나왔네” 정도로 넘기기엔 조금 더 야심이 큼.

  • 작은 기본 바이너리, npm 호환성, 웹 프레임워크 자동 감지, 인프로세스 바인딩, 크로스 컴파일, 자동 업데이트를 한 묶음으로 제시함.
  • 아직 canary라 당장 승부가 난 건 아니지만, Deno가 서버 런타임을 넘어 앱 배포 런타임으로 확장하려는 신호로 보기엔 충분함.
  • 한국 개발자 입장에선 웹 기술로 사내툴, 운영툴, 개발자용 GUI를 만드는 팀들이 특히 체크할 만한 뉴스임.

---

기술 맥락

• 여기서 Deno가 고른 핵심 선택은 기본값을 OS WebView로 두는 거예요. 왜냐하면 데스크톱 웹앱에서 가장 많이 까이는 지점이 바이너리 크기인데, Chromium을 기본으로 번들링하면 시작부터 Electron과 비슷한 부담을 안고 가거든요.

• 대신 CEF 백엔드를 옵션으로 남긴 것도 중요해요. WebView는 작고 편하지만 운영체제별 렌더링 차이가 생길 수 있어서, 화면 일관성이 제품 요구사항이면 Chromium을 앱에 포함하는 쪽이 더 맞을 수 있어요.

• 프레임워크 자동 감지는 기존 웹앱을 거의 그대로 데스크톱으로 가져오려는 선택이에요. Next.js, Astro, Remix, Nuxt, SvelteKit 같은 프로젝트를 감지해서 release에서는 production server, 개발 중에는 --hmr dev server를 돌리기 때문에 마이그레이션 비용을 줄이려는 의도가 보여요.

• 인프로세스 바인딩은 UI와 백엔드 사이 호출 구조를 단순하게 만들기 위한 장치예요. 소켓 기반 IPC처럼 프로세스를 오가며 통신하는 모델보다 호출 경로가 짧아서, Deno 코드와 WebView가 자주 대화하는 앱에서 체감 차이가 날 수 있어요.

• 자동 업데이트를 latest.json과 bsdiff 기반으로 넣은 건 배포 운영까지 런타임이 책임지겠다는 뜻이에요. 데스크톱 앱은 설치보다 업데이트가 더 까다로운 경우가 많아서, 실패 시 rollback까지 기본 흐름에 넣은 점이 개발팀 입장에선 꽤 큰 차이예요.