데스크톱 애플리케이션을 새로 만들기로 하면 곧바로 갈림길이 나온다. 화면은 웹 기술로 만들고 운영체제 자원은 다른 언어로 다룰 것인가, 아니면 화면까지 하나의 언어로 통일할 것인가. 이 질문의 양 끝에 Tauri와 Compose Multiplatform이 서 있다. 둘 다 "한 번 작성해 여러 플랫폼에 낸다"는 목표를 내걸지만, 결과물의 무게와 요구되는 역량은 상당히 다르다.
결론부터 정리하면 이렇다. 웹 프런트엔드 자산이 이미 있고 설치 파일 크기가 제품 경쟁력이라면 Tauri가 유리하다. 안드로이드 앱을 이미 운영하고 UI까지 한 언어로 묶고 싶다면 Compose Multiplatform이 유리하다. 판단 기준은 결국 "우리 팀이 이미 무엇을 갖고 있는가"로 수렴한다.
Tauri는 웹 기술로 화면을 만들고 Rust로 시스템 자원을 다룬다.출발점이 다르다: 웹뷰 조합 vs 단일 UI 툴킷
Tauri는 운영체제에 이미 설치된 웹뷰를 그대로 쓴다. 윈도우는 WebView2, 맥은 WKWebView, 리눅스는 배포판이 제공하는 웹뷰를 불러온다. 앱에 브라우저 엔진을 통째로 넣지 않으니 껍데기가 가볍다. 화면은 웹뷰가, 파일·프로세스·알림 같은 시스템 기능은 Rust 코어 프로세스가 맡고, 둘은 메시지 전달(IPC)로 대화한다.
"최소 구성의 Tauri 앱은 600KB 미만일 수 있다." — Tauri 공식 문서
Compose Multiplatform은 반대로 화면을 직접 그린다. JetBrains가 만든 이 프레임워크는 구글의 Jetpack Compose를 기반으로 하며, 스키아 그래픽 엔진 위에 UI를 렌더링한다. 안드로이드·iOS·데스크톱이 같은 방식으로 그리기 때문에 플랫폼 간 결과가 거의 같다. 대신 렌더링 엔진과 런타임을 앱에 포함해야 한다.
Compose Multiplatform은 1.8.0에서 iOS 지원을 정식 안정화했다.숫자로 보는 차이: 크기와 메모리
Tauri의 기본 바이너리는 수백 KB에서 시작하고, 실제 앱도 프런트엔드 번들에 따라 수 MB 선에 머무는 경우가 많다. 운영체제 웹뷰를 빌려 쓰는 구조의 이점이다.
Compose Multiplatform 데스크톱은 JVM 기반 패키징을 쓰면 수십 MB에서 100MB를 넘나든다. 공개된 비교 사례에서도 단순 앱이 48~70MB, 런타임 포함 배포판이 100MB를 웃도는 경우가 흔하다. 반면 iOS는 Kotlin/Native로 컴파일되어 사정이 다르다. JetBrains는 1.8.0 발표에서 동일한 UI·자산의 네이티브 앱 대비 약 9MB 오버헤드라고 밝혔다.
메모리도 같은 논리다. Tauri는 웹뷰 프로세스와 Rust 코어가 기본 골격이라 가볍게 출발한다. Compose 데스크톱은 JVM 힙과 그래픽 파이프라인을 함께 안고 가 유휴 상태에서도 수백 MB를 쓰는 사례가 보고된다.
UI 일관성과 네이티브 감성
Compose Multiplatform의 강점은 일관성이다. 모든 컴포넌트를 캔버스에 직접 그리므로 운영체제가 업데이트되어도 화면이 흔들리지 않는다. 애니메이션과 상태 전환이 많은 화면, 커스텀 디자인이 강한 제품에서 힘을 발휘한다. 1.12.0에서는 데스크톱 창·다이얼로그 제어 API 2세대가 실험 기능으로 추가됐고, Compose Hot Reload에는 AI 에이전트가 실행 중인 앱을 확인하고 수정하는 MCP 서버가 붙었다.
Tauri는 반대다. UI가 결국 웹이므로 운영체제별 웹뷰 엔진 차이가 드러난다. 특히 리눅스는 배포판마다 웹뷰 버전이 달라 렌더링과 입력이 미묘하게 어긋날 수 있다. 대신 웹 생태계의 UI 라이브러리를 그대로 쓰고, 웹 버전과 데스크톱 화면을 맞추기도 쉽다.
Compose Multiplatform은 Kotlin 코드 한 벌로 UI까지 공유한다.모바일·웹 확장과 보안 모델
Tauri 2는 2024년 10월 정식 버전을 내며 데스크톱과 모바일을 한 코드베이스로 묶었다. 안드로이드·iOS 빌드를 같은 프로젝트에서 뽑을 수 있고, 플러그인에는 Swift와 Kotlin 바인딩도 제공된다. 다만 모바일에서는 웹뷰 기반 UI의 한계가 더 뚜렷해 제스처와 접근성이 네이티브와 미세하게 달라질 수 있다.
Compose Multiplatform은 이 지점에서 성숙도가 높다. 안드로이드·iOS·데스크톱이 모두 안정 단계이고 웹은 Wasm 기반 베타다. 2026년 10월 기준 최신 안정판은 1.12.1이며 1.13.0 알파가 이미 배포됐다.
보안은 기본값이 다르다. Tauri는 2.0부터 권한(capabilities) 체계를 도입해 어떤 창과 웹뷰에 어떤 명령을 허용할지 파일로 선언하고, 목록에 없는 기능은 빌드 단계에서 제거할 수 있다. Compose Multiplatform은 JVM 또는 네이티브 바이너리 위에서 동작해 웹뷰 기반 도구의 스크립트 주입 표면이 상대적으로 작다. 대신 네이티브 상호운용 지점과 외부 의존성 관리가 보안의 중심이 된다.
팀과 인력: 결국 무엇을 갖고 있느냐
Tauri는 프런트엔드 개발자에게 익숙하다. React, Vue, Svelte 중 무엇이든 그대로 올릴 수 있고 Rust는 명령 단위로 조금씩 붙이면 된다. 다만 시스템 프로그래밍 경험이 없는 팀이 Rust 오류와 씨름하는 시간은 생각보다 길다. Compose Multiplatform은 안드로이드 개발자에게 유리하다. Jetpack Compose 경험이 컴포넌트 모델과 상태 관리로 그대로 이어진다. 반대로 웹 출신 팀에는 Kotlin과 Gradle 구조가 낯설고, iOS 빌드에는 맥과 Xcode가 필요하다.
프레임워크 선택은 화면 구현 방식과 배포 크기에서 갈린다.상황별 선택 가이드
| 상황 | 권장 | 이유 |
|---|---|---|
| 웹 서비스가 있고 데스크톱 앱 추가 | Tauri | 프런트엔드 재사용, 설치 파일 최소화 |
| 안드로이드 앱을 iOS·데스크톱으로 확장 | Compose Multiplatform | UI까지 공유, 모바일 안정성 |
| 설치 파일 10MB 이하가 요구사항 | Tauri | 시스템 웹뷰 사용으로 용량 우위 |
| 복잡한 애니메이션·커스텀 디자인 | Compose Multiplatform | 캔버스 기반 일관 렌더링 |
| OS 네이티브 감성·접근성 최우선 | 둘 다 재검토 | 순수 네이티브가 여전히 우위 |
시스템 설정, 파일 관리자처럼 운영체제 통합이 제품 가치의 핵심인 앱이라면 두 프레임워크 모두 타협이 생긴다.
크기가 아니라 수명으로 판단하라
Tauri는 이미 있는 웹 자산을 가장 얇게 포장하는 도구이고, Compose Multiplatform은 모바일까지 포함한 제품 UI를 한 언어로 유지하는 도구다. 3년 뒤 유지보수 비용을 결정하는 것은 팀이 쓰는 언어와 생태계다.
실무적으로는 두 가지를 권한다. 첫째, 실제 화면 하나를 각각 만들어 보라. 빌드 시간과 디버깅 난이도, 배포 파이프라인의 마찰이 여기서 드러난다. 둘째, 배포 대상 운영체제 조합을 먼저 확정하라. 리눅스 비중이 높다면 웹뷰 버전 편차를, iOS와 데스크톱을 함께 노린다면 렌더링 일관성과 빌드 환경을 확인해야 한다. 프레임워크 선택은 유행이 아니라 인력 구조와 배포 전략의 함수다.