SvelteKit으로 PC 앱 만들 때, Tauri와 Electron 중 뭘 써야 할까

웹 프론트엔드 개발자가 PC 앱을 만들려고 할 때 가장 먼저 부딪히는 선택지 중 하나가 있다. 바로 Electron을 쓸지, Tauri를 쓸지다.

특히 SvelteKit으로 이미 웹 서비스를 만들고 있거나, 앞으로 웹과 데스크톱을 하나의 코드베이스로 최대한 묶고 싶은 팀이라면 이 선택은 더 중요해진다. 둘 다 HTML, CSS, JavaScript 기반 UI를 데스크톱 앱으로 포장할 수 있게 해 주지만, 내부 구조와 운영 감각은 꽤 다르다. Electron은 Chromium과 Node.js를 앱에 함께 싣는 방식이고, Tauri는 운영체제의 네이티브 WebView를 사용하면서 필요할 때 Rust 쪽 기능을 붙이는 구조다. 이 차이가 설치 크기, 메모리 사용, 보안 모델, 배포 경험, 유지보수 감각까지 전부 갈라놓는다.

SvelteKit 관점에서 보면 둘 다 연결은 가능하다. Tauri는 공식 문서에서 SvelteKit 연동 가이드를 별도로 제공하고 있고, 최근 v2 문서 기준으로도 SvelteKit 설정 예시가 정리되어 있다. 다만 Tauri에서 SvelteKit을 쓸 때는 일반적인 서버형 SSR 앱처럼 운용하기보다, 정적 빌드와 데스크톱 앱 패키징에 맞게 구성하는 흐름이 중요하다. 공식 가이드도 adapter-static 사용과 데스크톱 앱에 맞는 설정을 안내한다.

반면 Electron은 SvelteKit 전용 공식 가이드가 중심에 있지는 않지만, Electron 자체가 브라우저 프로세스와 렌더러 프로세스를 분리한 구조를 제공하고, Node.js 기반 메인 프로세스에서 앱 생명주기와 네이티브 기능을 제어하는 전통적인 패턴이 매우 잘 정리되어 있다. 즉 SvelteKit이든 Vite든, 결과적으로 프론트엔드 번들을 Electron renderer에 붙이는 방식으로 이해하면 된다. Electron의 공식 문서는 이 프로세스 모델과 첫 앱 구성 방식을 명확히 설명하고 있다.

먼저 결론부터 말하면

내 기준에서는 지금 SvelteKit으로 새 PC 앱을 만든다면 우선순위는 Tauri다. 그리고 그 이유는 단순히 “가볍다” 하나가 아니다.

핵심은 세 가지다.

첫째, 앱의 기본 체급이 더 작다. 둘째, 권한과 런타임 범위를 더 보수적으로 가져가기 쉽다. 셋째, AI 시대에는 Rust를 잘 몰라도 예전보다 Tauri의 진입 장벽이 훨씬 낮아졌다.

즉 예전에는 “Electron은 JS만 알면 되고, Tauri는 Rust가 필요하니 어렵다”는 인식이 강했지만, 지금은 이 구도가 많이 바뀌었다고 본다. Tauri 공식 문서도 프런트엔드 프레임워크와 Rust를 메시지 패싱으로 연결하는 구조를 설명하고 있고, 실제로 많은 앱에서는 프론트엔드와 플러그인 조합만으로도 상당 부분을 구현할 수 있다. Rust를 깊게 파지 않아도 되는 영역이 생각보다 크다.

Electron은 왜 여전히 많이 쓰이는가

Electron이 아직도 강력한 이유는 분명하다. 가장 큰 장점은 일관성과 생태계의 성숙도다.

Electron은 Chromium과 Node.js를 번들에 포함하므로, 운영체제마다 WebView 버전이 달라 생기는 차이를 상대적으로 덜 신경 써도 된다. “내가 테스트한 렌더링과 런타임이 사용자 환경에서도 거의 그대로 나온다”는 점은 여전히 강한 장점이다. 게다가 메인 프로세스가 Node.js 환경이기 때문에 파일 시스템, 프로세스 제어, 네이티브 모듈 활용 등도 웹 개발자에게 비교적 익숙한 감각으로 접근할 수 있다. Electron 공식 사이트도 이 점을 강점으로 내세우며, npm 생태계와 빠른 Chromium 보안 업데이트 동조를 강조한다.

• 특히 아래 같은 경우에는 지금도 Electron이 꽤 합리적이다.
• 팀이 전부 JavaScript/TypeScript에만 익숙할 때
• 크로스플랫폼 렌더링 일관성이 매우 중요할 때
• 이미 Electron 기반 자산이나 플러그인 생태계를 활용하고 있을 때
• 앱 크기보다 빠른 MVP와 풍부한 레퍼런스가 더 중요할 때

Electron은 문제를 “웹 기술로 데스크톱 앱 만들기” 수준에서 끝내지 않고, 그 위에 이미 수많은 실전 패턴과 도구를 축적해 왔다. 그래서 팀이 처음 데스크톱 앱을 시도할 때 시행착오를 줄이기 쉽다.

하지만 SvelteKit으로 새로 시작한다면, Tauri가 더 매력적인 이유

내가 Tauri 쪽에 더 무게를 두는 건, 지금 시점에서 새로 만드는 앱의 기본값으로 봤을 때 더 현대적인 선택처럼 느껴지기 때문이다.

1. 설치 크기와 메모리 체급이 더 작다

Tauri는 Chromium 전체를 앱마다 싣지 않는다. 대신 각 운영체제의 네이티브 WebView를 활용한다. Windows에서는 WebView2, macOS에서는 WebKit, Linux에서는 WebKitGTK 계열을 사용한다. 이 구조 때문에 기본 번들 크기와 메모리 사용량이 Electron보다 작아지는 경향이 크다. Tauri 공식 문서도 스스로를 “tiny, fast binaries”라고 소개하고 있으며, 아키텍처 문서에서도 웹뷰 기반 구조를 명시한다.

최근 비교 글들도 대체로 같은 패턴을 보여준다. 수치는 앱마다 다르지만, Electron은 Chromium 동봉 비용 때문에 설치 파일과 유휴 메모리 사용량이 커지고, Tauri는 더 가벼운 편이라는 비교가 반복적으로 나온다. 다만 이런 수치는 앱 구조, 창 수, 백그라운드 작업, 번들 옵션에 따라 크게 달라질 수 있으므로 절대값보다 경향으로 받아들이는 게 맞다.

SvelteKit은 본질적으로도 비교적 가볍고 빠른 프런트엔드 경험을 만들기 좋은 프레임워크다. 여기에 데스크톱 셸까지 더 가볍게 가고 싶다면 Tauri와의 궁합이 좋다. “웹도 가볍게, 앱 셸도 가볍게”라는 방향이 잘 맞는다.

2. 보안 기본값을 더 보수적으로 가져가기 좋다

Electron은 강력하지만, 그만큼 보안 설정을 잘못하면 위험 반경이 커질 수 있다. Electron 공식 보안 문서도 신뢰할 수 없는 콘텐츠를 표시할 때의 위험성을 강하게 경고하고 있고, Node 통합 비활성화, context isolation, 새 창 제한 등 여러 보안 수칙을 명시한다. 즉 Electron은 충분히 안전하게 만들 수 있지만, 개발자가 알아야 할 보안 체크포인트가 많다.

Tauri는 애초에 권한 범위를 더 좁게 생각하는 구조에 가깝다. 웹뷰와 시스템 기능 사이를 메시지 패싱으로 연결하고, 필요한 API만 노출하는 식으로 접근한다. 그래서 앱이 “브라우저 UI + 최소 권한 네이티브 브리지”라는 감각으로 설계되기 쉽다. 보안은 결국 구현 품질의 문제이긴 하지만, 기본 출발점만 놓고 보면 Tauri가 더 보수적인 편에 서 있다고 보는 게 자연스럽다.

3. SvelteKit 개발자에게 구조가 생각보다 잘 맞는다

SvelteKit으로 앱을 만들 때 중요한 건 “웹앱처럼 개발하되, 데스크톱 특성만 얇게 추가하는 것”이다. Tauri는 이 감각에 잘 맞는다. 프론트는 SvelteKit으로 만들고, 파일 시스템 접근이나 윈도우 제어, 업데이트, 트레이, 네이티브 기능 같은 것만 Tauri 쪽으로 넘기면 된다. 공식 구성 파일도 앱 메타데이터, 번들, 윈도우, 플러그인, 빌드 명령을 비교적 명확하게 분리해 둔다.

Electron도 물론 가능하지만, 메인 프로세스와 프리로드, 렌더러 사이의 관계를 제대로 설계해야 하고, 보안 모델을 어설프게 다루면 금방 복잡해진다. 익숙해지면 강력하지만, 새 프로젝트에서는 “웹앱에 데스크톱 기능을 덧입힌다”보다 “브라우저 엔진이 포함된 데스크톱 런타임을 설계한다”는 감각이 더 강하다.

많은 사람들이 Tauri를 망설이는 이유: “Rust 몰라도 되나?”

이 질문이 제일 크다. 결론부터 말하면, 초기 단계에서는 꽤 많이 몰라도 된다.

Tauri는 분명 Rust 기반 코어를 갖고 있고, 깊은 네이티브 확장이나 커스텀 시스템 통합을 하려면 Rust 지식이 있으면 강력하다. 하지만 모든 Tauri 앱이 Rust를 깊게 파야만 하는 건 아니다. 공식 문서 자체가 “어떤 프론트엔드 프레임워크도 연결할 수 있다”는 방향으로 설계되어 있고, 플러그인과 설정 중심으로 해결 가능한 영역이 상당하다. 파일 열기, 업데이트, 윈도우 제어, 트레이 같은 대표 기능은 이미 문서화와 플러그인 체계가 잘 되어 있다.

그리고 지금은 AI 시대다. 이 말은 단순한 유행어가 아니라, Rust를 아예 못 쓰는 팀도 필요한 범위의 Rust 코드를 생성·수정·검토하면서 Tauri를 다룰 수 있게 되었다는 뜻에 가깝다.

예전에는 “Tauri를 선택하면 Rust라는 새로운 언어를 본격적으로 배워야 한다”는 심리적 장벽이 컸다. 하지만 지금은 LLM을 활용해 Tauri 명령 추가, 파일 시스템 브리지, 간단한 네이티브 기능 연결, 설정 파일 수정 같은 작업을 훨씬 빠르게 처리할 수 있다. 물론 보안과 품질 검토는 사람이 해야 하지만, 진입 장벽 자체는 분명히 낮아졌다. 이 점 때문에 나는 오히려 AI 시대일수록 Tauri의 약점으로 여겨졌던 Rust 장벽이 빠르게 약해지고 있다고 본다. 이 부분은 공식 문서의 사실이라기보다, 최근 개발 워크플로우 변화에 대한 해석이지만 Tauri의 구조적 장점을 실제 채택으로 연결해 주는 중요한 배경이다.

그렇다고 Tauri가 무조건 정답은 아니다

여기서 한 가지는 분명히 해야 한다. Tauri가 더 낫다고 말할 때도, 모든 상황에서 절대 우위는 아니다.

가장 대표적인 변수는 플랫폼별 WebView 차이다. Electron은 Chromium을 포함하므로 렌더링 일관성이 상대적으로 높지만, Tauri는 OS WebView에 기대기 때문에 운영체제나 버전에 따라 미묘한 차이를 겪을 수 있다. 실제 커뮤니티 논의에서도 Tauri의 장점은 인정하면서도, 플랫폼별 웹뷰 차이와 렌더링 버그 가능성을 단점으로 지적하는 사례가 있다.

즉 이런 경우라면 Electron이 더 나을 수 있다.

• 아주 복잡한 렌더링 일관성이 핵심일 때

• JS/Node 생태계 의존성이 매우 클 때

• 팀이 Rust를 정말 전혀 만지고 싶지 않을 때

• 작은 설치 파일보다 빠른 생산성과 예측 가능한 런타임이 더 중요할 때

Electron은 오래 살아남은 데에는 이유가 있다. 크고 무겁다는 비판은 맞지만, 그만큼 문제를 많이 이미 겪어봤고, 그에 대한 문서와 사례도 많다.

SvelteKit으로 만들 때 실전적으로 어떻게 선택하면 좋나

내가 실무적으로 고르라면 이렇게 나눈다.

Electron을 고를 상황

“우리는 데스크톱 앱이 처음이고, 팀이 전부 JS/TS다. 런타임 일관성이 중요하고, 설치 크기는 크게 신경 안 쓴다. Node 생태계를 그대로 데스크톱에 가져오고 싶다.” 이런 조건이면 Electron이 더 안전한 선택이다. 공식 문서와 레퍼런스가 풍부하고, 예상 가능한 구조 위에서 개발할 수 있다.

Tauri를 고를 상황

“우리는 SvelteKit 기반 프런트엔드가 이미 있고, 더 가볍고 단정한 PC 앱을 원한다. 앱 크기와 메모리 사용이 중요하고, 시스템 권한은 필요한 만큼만 노출하고 싶다. 필요한 Rust는 AI 도움을 받아서라도 감당할 수 있다.” 이 조건이면 Tauri가 더 좋다. 특히 작은 유틸리티, 생산성 앱, AI 클라이언트, 노트 앱, 내부 업무툴, 멀티플랫폼 확장까지 고려하는 앱에는 Tauri의 성격이 잘 맞는다.

내 결론

지금 SvelteKit으로 새 PC 앱을 만든다면, 나는 Tauri를 먼저 본다.

그 이유는 단순히 “Electron보다 신기술이라서”가 아니다. 오히려 반대다. 지금 필요한 기준으로 봤을 때 더 납득이 간다.

• 웹 기술을 그대로 활용할 수 있고

• 기본 번들 크기와 메모리 사용에 유리하며

• 권한 구조를 더 보수적으로 가져가기 쉽고

• SvelteKit과의 연결도 공식적으로 잘 정리되어 있고

• 무엇보다 AI 시대에는 Rust 진입 장벽이 예전만큼 치명적이지 않다

예전에는 “Rust를 몰라서 Tauri는 부담”이라는 말이 강력했다면, 지금은 “필요한 범위의 Rust는 AI와 함께 처리하고, 나머지는 SvelteKit 중심으로 가져간다”는 선택지가 충분히 현실적이다. 그래서 나는 새 프로젝트의 기본값은 Tauri, 특정 조건에서만 Electron이라는 쪽에 가깝다.

한눈에 보는 요약

이 표는 공식 아키텍처와 보안/프로세스 문서, 그리고 최근 비교 자료를 바탕으로 요약한 것이다.