거대한 배포 파일과 작별하기
일렉트론 앱을 실행할 때마다 수백 메가바이트의 크로미움 바이너리를 함께 배포하는 것은 비효율적이다. 1인 개발자에게 배포 파일 크기는 설치율과 직결된다. 데노 데스크탑은 운영체제 네이티브 웹뷰를 사용한다. 기존 180MB 규모의 앱을 19MB 수준으로 줄일 수 있다. 단순한 기술 변경이 아니라 운영 환경의 무게를 덜어내는 작업이다.
마이그레이션 스프린트 체크리스트
10일 안에 리팩토링을 끝내려면 기존 구조를 버려야 한다.
- package.json의 복잡한 의존성 대신 deno.lock을 사용해 캐시 관리 체계를 단순화한다.
- 일렉트론 빌더와 asar 같은 무거운 툴을 제거하고 데노 내부 빌드 엔진을 설정한다.
- ipcMain과 ipcRenderer 통신 레이어를 삭제하고 win.bind() 메서드로 프로세스 제어권을 통합한다.
이 작업을 마치면 빌드 프로세스 시간을 40% 단축할 수 있다.
플랫폼별 웹뷰 차이 제어하기
맥과 윈도우, 리눅스는 웹 엔진이 다르다. WKWebView와 WebView2는 렌더링 결과가 제각각이다. CSS 명세를 해석하는 방식조차 다르다. 특히 리눅스의 구형 WebKitGTK는 레이아웃을 자주 깨뜨린다.
플랫폼별 이질감을 줄이려면 보정 스크립트를 배포 파이프라인에 넣어야 한다.
- CSS 리셋 코드로 모든 브라우저의 기본 여백을 0으로 강제한다.
- 부트스트랩 단계에서 bindings.getPlatformMetadata()를 호출해 실행 중인 운영체제를 판별한다.
- macOS에서는 프레임리스 모드 시 신호등 영역을 고려해 28px 높이의 여백을 래퍼 div로 확보하고, 윈도우는 다크 모드 감지 여부에 따라 CSS 클래스를 주입한다.
이 방식을 적용하면 운영체제마다 일일이 UI를 수정하는 비용이 줄어든다.
네이티브 API 호출 보안 래퍼 구현
일렉트론의 IPC 채널은 보안 사고가 잦다. 데노 데스크탑은 다이렉트 바인딩으로 데이터를 전달해 보안성을 높인다. OS 기능을 안전하게 제어하려면 래퍼 클래스를 직접 구현해야 한다.
- 파일 입출력은 반드시 샌드박스 경로인 /app_sandbox_storage 내부로 제한한다.
- 클래스 생성자에 Path Traversal 방지 로직을 포함해 경로 내 .. 문자를 즉시 차단한다.
- 알림 등 시스템 기능을 호출할 때는 인자로 전달된 리소스가 화이트리스트에 있는지 확인하고 base64 인코딩 데이터만 사용한다.
깃허브 액션으로 배포 자동화
OS별로 환경을 설정하며 빌드하지 마라. 깃허브 액션의 행렬 전략을 쓰면 한 번의 커밋으로 윈도우 msi, 리눅스 AppImage, 맥 dmg 파일을 동시에 뽑아낸다.
- ubuntu-latest 환경에서 윈도우와 리눅스를, macos-14에서 맥 바이너리를 빌드한다.
- deno desktop --target 명령어에 --compress=xz 옵션을 추가해 최종 파일 용량을 줄인다.
- 리눅스 결과물은 xvfb-run을 실행해 가상 환경에서 실제 구동 여부를 테스트한다.
이 파이프라인을 구축하면 수동 빌드보다 배포 사이클이 2배 빨라진다. 데노로의 전환은 가벼운 바이너리와 샌드박스 보안이라는 두 가지 이득을 준다.
