맥 Electron 앱을 Rust로 다시 작성함

Hacker News 의견

• Rust와 egui를 이용해서 데스크톱 앱을 만들고 있는데, Rust도 데스크톱 개발도 처음이라 한꺼번에 너무 많은 개념을 배우는 게 어렵다는 생각임. 내 분야는 기계공학 분석 툴이라서 백엔드는 고성능이 필요하고 프론트엔드는 데이터 시각화가 요구됨. Tauri를 사용할 때 rust, js, html 등 여러 스택을 같이 관리하는 게 힘들지는 않았는지 궁금함

• 최근에 Tauri에서 Electron으로 프로젝트를 옮긴 경험이 있음. 여러 플랫폼에서 사용되는 웹뷰의 렌더링 차이 때문에 골치가 아팠음. 혹시 크로스 플랫폼으로 UI 버그를 겪은 적이 있는지 궁금함. UI 요구사항은 단순하고 계산은 복잡해서 QA 비용이 있더라도 그 값어치가 충분하다고는 생각함. 내 경험이 특이했던 건지, 아니면 렌더링 차이가 정말 흔한 문제인지 궁금함. 그리고 Tauri를 1.0으로 썼는지 2.0으로 썼는지 궁금함. 2.0은 내가 v1에서 바꾸는 중에 정식 버전이 나왔는데, 마이그레이션은 악몽이었고 문서도 정말 부족했음. 지금은 문서화가 잘 되었는지 궁금함

  • 우리는 kreya.app에서 시스템 웹뷰를 직접 구현해서 쓰고 있는데(즉, Tauri는 아님) 플랫폼 차이가 실제로는 거의 문제되지 않음. 폴리필로 대부분 해결되고 리눅스에서 end to end 자동화 테스트를 돌려서 대부분의 문제를 찾아냄. 제일 힘든 점은 유저의 웹뷰 버전이 얼마나 뒤처져 있는지 파악하는 일임. 리눅스와 맥에서 이 문제가 크고, 윈도우는 WebView2 덕분에 훨씬 나은 편임
  • 사실 Tauri 버전으로 아직 크로스플랫폼을 배포하지는 않아서 앞으로 확인할 예정임. 다행히 UI 요구는 단순함. Tauri에서 무슨 렌더링 차이들을 겪었는지 궁금함. 앱에서 어느 플랫폼이 제일 잘 되거나 문제를 보였는지 궁금함. 우리도 윈도우 지원을 원함. Electron 버전에서는 맥 인텔칩에서 번들된 바이너리 실행에 문제가 있었고, 이게 워낙 골치 아파서 Tauri로 리빌드 할 때는 Mac(Apple chip) 한 플랫폼에 우선 집중하기로 함. Tauri 1.4로 진행했고 아직 문제 없음. 2.0 마이그레이션 문서도 앞으로 확인할 예정임
  • 크로스 플랫폼 UI 버그를 겪었냐는 질문에 대해, 당연히 아직은 Mac만 지원하기 때문에 해당 없음. 만약 윈도우와 리눅스까지 지원하려 했다면 이 글도 나올 수 없었을 거라고 생각함. 크로스플랫폼 UI는 진짜 어렵고, 같은 UI와 기능셋을 유지하면서 온라인 버전까지 염두에 두면 더더욱 어려워짐. 그래서 다들 네이티브에서 Qt, 웹스택으로 옮겨갔음. 내 경험상 수백만 유저가 있는 크로스플랫폼 데스크탑 앱을 개발하는 회사에서 일하고 있는데, 다른 방법으로는 상상도 못할 것 같음
  • 내가 6개월 전쯤 Tauri V2를 썼을 때 문서가 완전히 엉망이었음. 프로젝트 자체는 유망하지만, 참고할 게 없어서 제대로 구현하기가 정말 고역이었음
  • 최근 Tauri에서 이런 소식을 발표함: 올해 CEF와 SERVO 기반 웹뷰 등 신기술을 선보일 예정이라고 디스코드에서 공지함

• 나도 비슷한 길을 밟아본 경험이 있음. USB 현미경용으로 최적화된 간단한 웹캠 뷰어를 만들었는데, 기존에는 괜찮은 게 없어서 직접 만듦. 거의 모든 기능을 렌더러에 구현함. 앱스토어 제출을 준비하다가 500mb 짜리 웹캠 뷰어가 맞나 싶어서, Tauri V2로 포팅해서 용량을 15mb 가까이 줄임

  • Tauri와 Electron의 차이점에 대해 궁금함. 내가 이해한 바로는 둘 다 렌더링에 브라우저를 쓰지만, Electron은 자체 브라우저 전체를 동봉하고 Tauri는 시스템에 이미 있는 브라우저를 이용함
  • 정말 대단하다고 생각함. 어떤 제품인지 궁금함. 우리도 이번 주에 앱스토어 제출 준비 중임

• 이 앱의 취지가 정말 마음에 듦. 이 분야의 다른 앱들은 너무 굼뜨고 불편한 경우가 많아서, 리라이트에 관심이 큼. 다만 사진작가다 보니 미디어 중 많은 부분이 RAW 포맷인데, 그게 지원되는지 확실하지 않음(혹은 “모든 주요 이미지·비디오 포맷”에서 RAW가 빠진 걸 보면 아마 아닐지도). 이런 세부사항을 확인할 수 있는 공식 문서, 사용자 포럼, 그 밖의 채널이 있는지 궁금함

• 나는 Mac 사용자도 아니고 우리 팀도 Rust로의 리라이트는 고려하지 않지만, 이 글이 무척 반가움. “Show HN”에서 딱 이 정도 분량의, 현실 문제를 해결하는 데 필요한 기술 트레이드오프를 요약해주는 글을 기대함. 고마움

  • 경험을 공유할 수 있어 기쁨. 이미 작동은 하는 걸 리빌드한다는 결정이 쉽진 않았는데, 결과적으로 만족함

• Tauri, Flutter, Electron, React Native, 기타 현대 크로스플랫폼 프레임워크를 비교하는 최신 벤치마크 자료가 있으면 정말 좋을 것 같음. 주요 지표로는 번들 크기, 메모리 사용량(RAM), 시작 시간, 부하 상황에서의 CPU 사용, 디스크 점유량 등이 있을 것임. 특히 Tauri처럼 웹뷰 버전에 따라 렌더링, 퍼포먼스가 달라지는 프레임워크라면, 플랫폼별(WebView2, WKWebView 등) 호환성 매트릭스도 함께 실으면 좋겠다는 생각임. 이런 차이를 시각적으로 표로 정리하면 개발자가 훨씬 나은 선택을 할 수 있을 것임

  • 2주 전에 올라온 최신 비교 자료가 있음. web-to-desktop-framework-comparison에서 확인 가능함. Electron이 런타임 성능에서 꽤 경쟁력 있음. 디스크 공간보다는 메모리 사용에 더 신경을 써야 한다는 생각임.
    • 윈도우(x64) 메모리 사용량(싱글 윈도우, 릴리스 빌드):
    1. Electron: 약 93MB
    2. NodeGui: 약 116MB
    3. NW.JS: 약 131MB
    4. Tauri: 약 154MB
    5. Wails: 약 163MB
    6. Neutralino: 약 282MB
    • 맥(arm64):
    1. NodeGui: 약 84MB
    2. Wails: 약 85MB
    3. Tauri: 약 86MB
    4. Neutralino: 약 109MB
    5. Electron: 약 121MB
    6. NW.JS: 약 189MB
    • 리눅스(x64):
    1. Tauri: 약 16MB
    2. Electron: 약 70MB
    3. Wails: 약 86MB
    4. NodeGui: 약 109MB
    5. NW.JS: 약 166MB
    6. Neutralino: 약 402MB
  • 이런 비교 자료를 더 보고 싶음

• 예전 회사에서는 윈도우와 맥용 데스크톱 Electron 앱을 유지보수했었음. 앱이 너무 무거웠고, Squirrel로 업데이트하는 게 고역이었음.
  결국 GUI는 웹 SPA (Inferno 기반)로 두고, 웹뷰 로딩 등은 각각 작은 네이티브 앱(C#과 Swift)으로 교체함. 덕분에 다운로드 용량과 메모리 사용이 약 90% 줄고, 각 플랫폼 앱스토어를 통한 배포-업데이트로 전환함. 최고의 결정이었다고 생각함

  • 네이티브 앱스토어를 통한 배포/업데이트를 칭찬한 사람은 거의 처음 봄.
    업데이트 승인 시간과 불확실성이 걱정인데 Squirrel로부터 네이티브로 옮기면서 개선된 점이 궁금함
  • 전환에 얼마나 시간이 걸렸는지 궁금함

• 최종 앱이 맥이라면 왜 Rust/Tauri를 택하고 Swift/SwiftUI 대신 쓰지 않았는지 정말 궁금함

  • 확인해줘서 감사함. Desktop Docs의 목표는 크로스플랫폼임. 윈도우 지원 요청이 많아서, 향후 윈도우 버전을 대비해 Rust를 선택하게 됨
  • 나도 같은 질문을 하고 싶었음. Swift가 꽤 괜찮은 언어이고, Rust와 비슷한 장점이 많다고 생각함. CLIP 통합 얘기도 궁금하고, 포팅이야기도 아주 좋았음
  • 나 역시 궁금함. 곧 데스크톱 앱을 만들려고 하는데 Swift를 쓴지 오래됐고 Rust도 초큼 밖에 모름. Tauri가 아주 매력적으로 보임. Electron 앱들은 아무리 빠른 PC에서도 너무 느리게 시작함. 인사이트를 준 점에 감사함

• Tauri를 egui 대신 선택하게 된 계기가 궁금함. Electron 경험 때문인지? 나도 Python Qt앱을 Rust로 포팅하려고 하는데, 아직은 Rust의 GUI 라이브러리들이 Qt만큼 충실하지 않아서 결국 가다가 막힐까봐 걱정임

  • 근본적으로 포팅을 고민하게 된 계기가 무엇인지 궁금함

• 메인 랜딩페이지의 "Try" 버튼을 보면 사용자들이 체험판이 있을 것처럼 느끼는데, 실제로는 바로 구매로 이어짐. 짧게라도 1주일 체험판이 있으면 좋겠음.
  영구 사용 백업 라이선스 정책은 팬임. $99는 꽤 높은 진입장벽이지만 크리에이터/스튜디오 쪽을 타겟으로 한다면 그럴 만하고, 일반 소비자라면 $20-$25가 괜찮을 것 같음.
  성능을 글에서는 강조하지만, 랜딩페이지에는 전혀 언급이 없음. 38분짜리 동영상처럼, 각종 벤치마크, 병렬작업, vram 요구사항 같은 정보도 중요함. 수백~수천시간의 미디어를 처리할 때 실제로 어떤지 궁금함.
  electron이 10~14분 걸리던 작업이 Tauri로 3분이 된 게 신기함. electron이 CLIP과 ffmpeg를 단지 orchestration 했을 뿐인데 어디서 저런 오버헤드가 나오는지 궁금함.
  예전에 나도 Electron으로 영상 트랜스크립션 기반 미디어 검색 툴을 만들었는데 성능 문제는 별로 없었음.
  보통 Electron이나 Tauri를 선택하는 이유가 크로스플랫폼 때문인데, 애초에 왜 맥 전용인지 궁금함(특히 대용량 미디어 처리라면 nvidia 활용도 가능한데).
  나도 최근 10년 만에 Swift를 다시 써서 Tauri와 고민하다가 Swift를 택했는데(새 프로젝트), 2014년 무렵에 비해 엄청 발전해서 거의 쾌적했음.
  활성 유저 관련 섹션이 사실이라면 이미 나름 성공을 거두신 것 같은데, 기존에 스튜디오/크리에이터 업계에서 네트워크나 오디언스가 있었는지 궁금함. 마케팅 부분도 듣고 싶음

  • 피드백 고마움. 인프라상 아직 체험판을 구현하지 못했지만 미래에는 고려할 계획임.
    비슷한 툴을 직접 만드셨다고 했는데, 출시하지 않은 이유가 궁금함.
    윈도우, 리눅스 버전도 앞으로 수요 있으면 몇달 내 출시 예정임.
    유저는 HN, reddit 런치, 일부 linkedin 홍보로 확보했음. 대부분 입소문임.
    electron과 영상 처리 성능 이야기는 더 깊게 들어가면 할 얘기가 많음. 나도 electron 전문가가 아니라, 우리가 worker를 제대로 못 써서 병목이 생겼던 것 같기도 함.
    rust로 넘어가면서 씬 탐지(scene detection)도 도입해서 색인할 프레임 수를 줄이는 등, 처리 부하를 크게 낮췄음. ffmpeg의 GPU 가속 옵션도 추가해서 성능이 꽤 향상되었음. 이미지 임베딩 생성도 배치처리로 최적화했음. 다만 너무 무리하면 모델 인스턴스가 크래시날 수도 있음