데스크톱 앱은 웹사이트를 창 안에 넣는 일보다 범위가 넓습니다. 설치 파일을 만들고, 운영체제 권한을 다루고, 업데이트를 배포하고, 파일과 장치에 접근해야 합니다.
기술 선택도 화면을 무엇으로 만들지에 그치지 않습니다. Windows와 macOS 중 어디를 지원하는지, 오프라인으로 작동해야 하는지, 코드 서명과 자동 업데이트를 누가 운영하는지가 비용과 일정에 더 큰 영향을 줍니다.
이 글은 Electron, Tauri, Windows·macOS 네이티브를 비교하고, 제품 요구에 맞춰 선택하는 순서를 정리합니다.
프레임워크 버전과 운영체제 배포 정책은 착수 전에 다시 확인해야 합니다.
먼저 결정할 여섯 가지
기술 이름을 비교하기 전에 다음 질문에 답해야 합니다.
- Windows, macOS, Linux 중 어디를 지원하는가
- 인터넷이 끊겨도 어떤 기능이 동작해야 하는가
- 파일, 프린터, 시리얼 포트, USB, 블루투스를 사용하는가
- 기존 웹 화면과 JavaScript·TypeScript 코드를 재사용해야 하는가
- 설치 파일, 코드 서명과 자동 업데이트를 누가 운영하는가
- 고객사 내부망, 앱스토어, 웹 다운로드 중 어떻게 배포하는가
같은 관리자 도구라도 브라우저에서 충분하면 웹으로 만드는 편이 운영하기 쉽습니다. 데스크톱 앱은 로컬 기능, 오프라인, 설치형 배포가 실제 요구일 때 선택해야 합니다.
Electron
Electron은 Chromium과 Node.js를 묶어 HTML, CSS, JavaScript로 Windows·macOS·Linux 앱을 만듭니다.
잘 맞는 경우
- 기존 웹 프런트엔드와 TypeScript 자산을 재사용해야 할 때
- 운영체제별로 비슷한 화면을 빠르게 제공할 때
- Chromium 버전을 앱에 포함해 렌더링 차이를 줄이고 싶을 때
- 필요한 네이티브 기능을 Node.js 모듈이나 별도 프로세스로 연결할 수 있을 때
확인할 점
Electron은 메인 프로세스와 렌더러 프로세스의 역할을 나눕니다. 공식 프로세스 모델에 따라 파일 시스템과 운영체제 권한을 가진 메인 프로세스의 기능을 렌더러에 직접 노출하지 않아야 합니다.
Chromium과 런타임을 함께 배포하므로 설치 용량과 메모리 사용이 Tauri나 네이티브보다 커질 수 있습니다. 제품 규모와 화면 수만 보고 판단하지 말고, 실제 기기에서 시작 시간과 메모리, 장시간 실행 상태를 측정해야 합니다.
Tauri
Tauri는 웹 UI를 사용하지만 브라우저 엔진을 앱마다 포함하지 않고 운영체제의 WebView를 활용합니다. Rust 기반 코어가 운영체제 기능을 처리하고, 웹 화면은 허용된 명령을 통해 기능을 호출합니다.
잘 맞는 경우
- 웹 UI를 활용하면서 설치 용량을 줄이고 싶을 때
- 파일 처리와 로컬 데이터처럼 필요한 권한 범위를 명확히 제한할 수 있을 때
- 팀이 Rust 코드와 운영체제별 WebView 차이를 관리할 수 있을 때
확인할 점
운영체제 WebView를 사용하므로 환경에 따라 렌더링 엔진과 버전이 달라질 수 있습니다. Windows, macOS와 Linux에서 같은 기능이 실제로 동작하는지 테스트해야 합니다.
Tauri가 작다는 이유만으로 항상 개발비가 낮아지는 것은 아닙니다. 필요한 플러그인이 없거나 Rust 코어를 직접 작성해야 하면 초기 구현과 디버깅 범위가 커질 수 있습니다. 공식 보안 문서에 따라 WebView가 호출할 수 있는 명령과 권한을 좁혀야 합니다.
Windows·macOS 네이티브
Windows 전용 앱은 C#·C++과 WinUI 3 같은 Windows 기술을, macOS 전용 앱은 Swift·SwiftUI·AppKit을 검토할 수 있습니다.
잘 맞는 경우
- 한 운영체제만 지원하고 해당 플랫폼 기능을 깊게 사용할 때
- 창, 메뉴, 접근성, 백그라운드 서비스와 장치 연동이 제품의 핵심일 때
- 장기간 운영하면서 새 OS 기능과 정책을 빠르게 반영해야 할 때
- 성능과 메모리 사용을 세밀하게 제어해야 할 때
확인할 점
두 운영체제를 모두 지원하면 UI와 플랫폼 연결 코드를 따로 관리할 가능성이 큽니다. 공통 데이터 처리와 서버 API를 공유하더라도 설치, 권한, 업데이트와 QA는 플랫폼별로 남습니다.
한눈에 정리한 선택 기준
- 기존 웹 자산과 프런트엔드 인력을 활용하고, 여러 운영체제에서 같은 렌더링을 원한다면 Electron을 먼저 검토합니다.
- 웹 UI를 활용하되 설치 용량과 권한 표면을 줄이고, Rust와 WebView 차이를 관리할 수 있다면 Tauri를 검토합니다.
- 한 운영체제의 기능과 사용성을 깊게 다루거나 높은 성능 제어가 필요하다면 네이티브를 검토합니다.
- 설치할 이유가 약하고 서버 연결이 기본이라면 데스크톱 앱보다 웹을 먼저 검토합니다.
이 기준은 출발점입니다. 특정 장치 SDK가 C#만 지원하거나, 고객사의 보안 정책이 내장 브라우저를 제한하면 선택이 달라집니다.
기술보다 먼저 견적에 넣어야 할 운영 항목
설치 파일과 배포 채널
Windows에서는 설치 프로그램 형식과 관리자 권한, 기업 보안 정책을 확인합니다. macOS에서는 앱스토어 배포와 웹 다운로드의 절차가 다릅니다. 고객사 내부망에 배포한다면 인터넷 없이 설치하고 업데이트하는 방법도 필요합니다.
코드 서명과 공증
코드 서명은 설치 파일과 앱의 배포 주체를 확인하는 절차입니다. macOS 웹 배포에서는 Apple의 서명과 공증 절차를 검토해야 하고, Windows에서도 서명되지 않은 앱은 신뢰 경고와 기업 보안 정책의 영향을 받을 수 있습니다.
인증서와 개발자 계정의 소유자는 납품 전에 정해야 합니다.
자동 업데이트
업데이트에는 새 버전을 확인하는 서버, 패키지 서명, 다운로드 실패 복구와 롤백이 필요합니다. Electron에는 자동 업데이트 공식 안내가 있지만, 모듈을 추가했다고 운영이 끝나는 것은 아닙니다.
고객사 내부망이나 폐쇄망에서는 자동 업데이트 서버에 접근할 수 없을 수 있습니다. 이 경우 관리자용 오프라인 패키지와 버전 확인 절차가 필요합니다.
로컬 데이터와 백업
오프라인 앱은 데이터를 어디에 저장하고 어떻게 복구할지 정해야 합니다. 사용자별 저장 경로, 암호화, 데이터베이스 마이그레이션, 자동 백업과 손상 복구를 포함합니다.
로컬에 저장한다고 보안 문제가 사라지지 않습니다. 운영체제 계정을 함께 쓰거나 노트북을 분실할 때 누가 데이터를 읽을 수 있는지 확인해야 합니다.
권한과 보안 경계
웹 화면에서 파일 시스템과 셸 명령을 직접 호출하게 만들면 입력값 하나가 시스템 권한으로 이어질 수 있습니다. 화면이 요청할 수 있는 명령을 제한하고, 파일 경로와 인자를 검증해야 합니다.
Electron에서는 메인·렌더러 프로세스와 IPC 경계를, Tauri에서는 capability와 command 범위를 검토합니다. 외부 URL을 앱 내부에서 열지, 기본 브라우저로 보낼지도 보안 정책에 포함합니다.
프로젝트 유형별 예시
사내 데이터 관리 도구
브라우저에서 해결할 수 있고 인터넷 또는 사내망 연결이 기본이라면 웹이 단순합니다. 대용량 로컬 파일 처리나 장치 연결이 필요해질 때 Electron이나 Tauri를 검토합니다.
제조 장비 제어 프로그램
시리얼 포트, USB, 실시간 데이터와 특정 Windows 드라이버가 핵심이면 Windows 네이티브가 유리할 수 있습니다. 웹 UI를 쓰더라도 장치 제어 모듈과 장애 복구는 별도 설계가 필요합니다.
문서·미디어 편집 도구
대용량 파일, 미리보기, 백그라운드 변환과 GPU 사용이 중요합니다. 기술 이름만 정하지 말고 대표 파일로 성능 시험을 먼저 해야 합니다. UI는 Electron으로 만들고 변환 엔진은 네이티브 프로세스로 분리하는 구성도 가능합니다.
여러 고객사에 배포하는 B2B 앱
고객사마다 프록시, 보안 프로그램, 설치 권한과 업데이트 정책이 다를 수 있습니다. 기능 개발보다 배포·로그 수집·원격 지원 범위가 커질 수 있으므로 파일럿 고객 환경에서 설치부터 먼저 검증합니다.
기술 선택 전에 만드는 짧은 검증판
데스크톱 앱은 대표 위험을 작은 검증판으로 확인한 뒤 기술을 확정하는 편이 안전합니다.
- 가장 큰 실제 파일을 열고 저장합니다.
- 필요한 장치나 운영체제 API를 한 번 연결합니다.
- Windows와 macOS 설치 파일을 만듭니다.
- 서명된 패키지를 테스트 기기에 설치합니다.
- 업데이트와 실패 복구를 실행합니다.
- 장시간 실행 후 메모리와 로그를 확인합니다.
화면 한 장을 예쁘게 만드는 검증보다 설치, 권한, 장치, 업데이트 중 가장 위험한 항목을 먼저 다뤄야 합니다.
선택 결과는 프레임워크 이름이 아니라 운영 범위다
Electron, Tauri와 네이티브는 모두 데스크톱 앱을 만들 수 있습니다. 선택의 차이는 누가 어떤 런타임과 운영체제 차이를 책임지는지에 있습니다.
견적서에는 화면과 기능 외에도 지원 OS 버전, 설치 프로그램, 인증서와 계정 소유권, 업데이트 방식, 로그, 데이터 백업과 장애 대응이 들어가야 합니다. 이 항목이 빠지면 첫 설치 파일을 만든 뒤에 별도 프로젝트가 시작됩니다.
데스크톱 앱의 기술 검증과 배포 범위를 함께 정해야 한다면 프로젝트 문의에 지원 운영체제, 로컬 기능과 배포 환경을 알려주세요. 첫 버전에 필요한 범위와 운영 준비를 나눠 답하겠습니다.