시간순이 프레임워크 선택 — Tauri를 고른 이유

 

지난 글에서 시간순이의 정체와 만들 이유를 정리했습니다. 이번 글은 그 다음 단계 — "이걸 뭘로 만들 것이냐"에 관한 의사결정 기록입니다.

 

평가 기준부터

후보를 좁히기 전에 평가 기준 세 개를 먼저 못 박았습니다.

가벼울 것. 한국 프리웨어 전통이 그렇습니다. 다들 1MB 안팎, 손바닥 안에 들어오는 크기예요. 사진 정리 유틸을 100MB 넘게 받게 하는 건 어울리지 않아요.

이쁠 것, 혹은 단순할 것. 둘 중 하나는 잡고 싶었습니다. 단순하면서 이쁘면 베스트지만, 적어도 한쪽은 분명해야 한다고 봤어요.

AI가 잘 다루는 스택일 것. 코드는 제가 아니라 AI가 씁니다. 그러니 제 학습 곡선은 큰 변수가 아니에요 — 대신 AI가 그 스택을 얼마나 능숙하게 다루느냐가 중요합니다. AI도 헤매는 생태계라면 디렉팅 자체가 막히니까요.

 

후보 셋 (그리고 하나 더)

세 가지를 깊게 봤습니다. Avalonia, Tauri, Electron. 윈도우 전용으로 좁히면 WPF도 후보였고요.

Electron — 탈락

장점은 명확합니다. 학습 자료가 압도적이고(VS Code, Slack, Discord, Notion이 다 Electron 위에 올라가 있죠), 웹 디자인의 자유도가 그대로 들어오니까 이쁜 UI를 만들기도 쉽습니다.

문제는 무게입니다. Electron은 크롬 엔진을 통째로 묶기 때문에, 빈 앱도 보통 100MB가 넘습니다. 사진 이름 좀 바꾸는 유틸을 150MB 받으라고 하는 건 — 가벼움이라는 첫 번째 기준과 정면 충돌입니다. 첫 기준에서 걸려서 탈락.

Avalonia / WPF — 안전하지만 미관이 아쉽다

C# 기반의 .NET XAML UI 프레임워크들입니다. 단일 .exe로 묶을 수 있고, 네이티브에 가까워 가볍습니다. WPF는 윈도우 전용이지만 자료가 많고, Avalonia는 크로스플랫폼이면서 모던한 편이에요.

학습 곡선도 무리는 없습니다. C#은 친절한 언어고, AI 코딩 도구가 워낙 .NET을 잘 다뤄서 디렉팅하기 좋습니다.

다만 미관이 걸렸습니다. 두 프레임워크 모두 디폴트 룩은 "윈도우 앱" 분위기에서 크게 벗어나기 어렵습니다. 모던한 느낌(리니어, 레이캐스트, 노션 같은 결)을 내려면 XAML과 스타일 시스템을 깊이 파고 들어가야 해요. 가능은 한데 비용이 큽니다. "이쁘거나 단순하거나"라는 기준에서 이쁨 쪽 점수가 낮았어요.

Tauri — 가볍고 이쁘다

Tauri는 Rust 백엔드 + 웹 프론트엔드 조합입니다. 핵심은 시스템 웹뷰(윈도우의 WebView2 등)를 쓴다는 점이에요. 크롬을 묶지 않으니 바이너리가 보통 5~20MB 사이에 들어옵니다. Electron의 1/10 이하 크기죠.

그리고 프론트엔드가 HTML/CSS라 — 웹 디자인의 자유도가 그대로 들어옵니다. "가볍다 + 이쁘다"는 정확히 Tauri가 노리는 정체성이에요. 첫 두 기준을 한 번에 잡습니다.

물론 공짜는 아닙니다. 시스템 웹뷰를 쓴다는 건, 뒤집으면 WebView2가 없는 PC에서는 앱이 안 뜬다는 뜻이에요. Windows 11과 최신 Windows 10에는 기본 탑재라 대부분 문제없지만, 업데이트가 안 된 구형 Win10은 런타임을 따로 설치해야 하고, Windows 7/8은 아예 지원되지 않습니다.

그래서, Rust는?

새 기준에 비추면 Tauri에도 약점이 하나 있었습니다. 백엔드가 Rust라는 점. 제가 직접 짜진 않더라도, AI가 Rust를 매끄럽게 다뤄주지 못하면 디렉팅이 헛돌 테니까요. 처음엔 이게 걸렸어요.

그런데 좀 더 들여다보니 기우였습니다. 이유 세 가지.

 

첫째, Tauri 패턴상 앱 로직의 대부분은 프론트엔드(JS)에 삽니다. Rust는 파일 시스템, 네이티브 API, 보안 같은 부분만 담당합니다. 시간순이의 경우 Rust 쪽에 들어갈 건 "폴더 읽기 + EXIF 파싱 + 파일 이름 바꾸기" 정도라, Rust 표면적이 정말 좁아요.

 

둘째, Rust 생태계에 필요한 부품이 다 있습니다. EXIF 파싱은 kamadak-exif 같은 크레이트로 해결됩니다. 직접 바이트 단위로 파싱할 일은 없어요.

 

셋째 — 그리고 이게 결정적이었는데 — 클로드 코드가 Rust를 꽤 잘 다룹니다. 거기에 Rust 컴파일러의 에러 메시지가 워낙 친절해서, 뭐가 잘못됐는지 정확히 짚어주니 AI가 스스로 고쳐나가기도 좋고요. "AI가 잘 다루는 스택일 것"이라는 기준에 Rust는 오히려 잘 들어맞았습니다.

 

대신 안정성은 만드는 방식으로 확보하려고 합니다. 코드를 AI가 쓰는 만큼, 한 번에 와르르 만들어놓고 "되겠지" 하는 건 위험해요. 그래서 작업을 잘게 쪼개 한 단계씩 — 구현하고, 동작을 확인하고, 그게 단단해지면 다음으로 — 이렇게 쌓아 올릴 생각입니다. 폴더 읽기가 확실해지면 EXIF 파싱으로, 그게 확실해지면 이름 바꾸기로. 특히 파일 이름을 바꾸고 되돌리는, 틀어지면 사진이 망가지는 대목일수록 이 검증을 촘촘히 하려고 해요. 지난 글에서 안전이 가장 중요하다고 못 박았으니까요.

 

결론: Tauri

세 기준을 다 따져본 결과 — Tauri로 갑니다.

Tauri는 프론트엔드를 자유롭게 고를 수 있는데, 우선은 바닐라 HTML/CSS/JS로 시작합니다. 진행하다가 한계가 보이면 그때 Svelte 정도를 고민하기로 했습니다.

 

다음 글

다음은 환경 세팅과 첫 화면 띄우기입니다.