Discord, Electron 버리고 Rust로 갈아타더니 메모리 70% 줄었다
Every Windows 11 app should kill Electron, and Discord just showed why

Discord가 Electron 기반 데스크톱 앱을 Rust와 GPUI로 다시 만들었다. CTO Stanislav Vishnevskiy가 공개한 영상에서 새 클라이언트는 콜드 스타트에서도 구버전이 로딩 화면을 벗어나기 전에 친구 목록을 띄웠고, 계정 두 개를 동시에 로그인한 상태에서 RAM 사용량은 290MB로 기존 1GB 안팎 대비 약 70% 줄었다. 'Starting' 화면 없이 백그라운드에서 자동 업데이트하며, 모바일 앱의 React Native와 웹의 JavaScript도 각각 Rust와 WASM으로 대체한다.
새 Discord 클라이언트가 RAM을 덜 쓰는 건 이야기의 일부일 뿐이다. 여기저기 눌러보면 즉각 반응해서 이제 예전으로 돌아갈 수가 없다. 부팅 시간을 한번 보라.
HN 토론
107- cheschire
이건 Electron 초창기부터 알려져 있던 사실이라고 확신합니다. VS Code가 처음 출시됐을 때 주요 불만 중 하나이기도 했죠.
Electron의 가치 제안은 항상 하나의 팀이 최소한의 추가 노력으로 여러 플랫폼에서 지원되는 하나의 앱을 만드는 것이었습니다.
이 기사는 그 점을 전혀 다루지 않습니다.
- ezst
그게 네이티브/비웹 프레임워크로 UI를 완전히 다시 작성한 건가요? 그게 아니라면 여전히 브라우저에서 실행되는 것이고, 즉 Electron의 비대함 요인의 80% 정도에 해당하며, 더 빨라진 이유는 아마도(주로?) 일반 클라이언트에서 볼 수 있는 만큼 많은 기능을 아직 추가하지 않았기 때문일 겁니다.
Discord는 서버 측 프로토콜입니다(클라이언트는 서버가 규정한 상태를 표시하는 것 외에는 별로 하는 일이 없습니다). 거기서 실행되는 로직/연산은 매우 적어서 엄청난 차이를 설명할 수 없습니다.
- LaurensBER
Electron은 작은 팀이 기존 웹 기술 스택을 사용해 괜찮은 GUI 앱을 만들 수 있게 해준다는 점에서 꽤 훌륭하지만, 이제는 더 나은 무언가가 나올 때가 된 것 같습니다.
RAM 가격이 미친 수준인 지금, 단순한 작업(예: Discord의 경우 90%가 메시지 읽기/쓰기)을 위해 몇 GB를 잡아먹는 앱 여러 개를 실행해야 한다는 건 꽤 답답합니다. 다른 사람들은 더 고급 기능(음성 채팅 등)을 사용할 수도 있다는 걸 이해하지만, 이런 기능은 필요할 때 로드할 수 있습니다.
512MB RAM(방금 확인해보니 40% 여유 있음!)으로 전체 Linux 스택(+ Podman, 모니터링, 알림 및 여러 서비스)을 편안하게 실행할 수 있다는 게 제게는 좀 미친 것 같습니다. 그런데 제 Windows PC는 데스크톱을 표시하는 데만 5.5GB가 필요합니다! 현실적으로 기본적인 웹 브라우징을 위해 8GB에서 16GB 사이가 필요하고, 심지어 Discord 같은 앱 몇 개를 백그라운드에서 실행하면 느려질 수 있습니다.
- mococa
이런 멍청함을 이해할 수 없습니다. 모든 OS, 심지어 BSD까지도 Qt로 단일 코드베이스를 유지하는 건 매우 쉽습니다(저 혼자서도 여러 번 해봤습니다).
사람들이 엄청 게을러진 것 같습니다... "아, RAM 몇백 MB 차지하겠지, 문제없어, 출시하자."
수십억, 심지어 수조 달러 규모의 회사들이 Electron으로 쓰레기를 출시하고 있습니다.
- smusamashah
요즘 우리는 앱 시작이 느린 것에 너무 익숙해진 것 같습니다. 최근에 Task Slinger[1]를 사용하기 시작했는데, 부팅할 때마다 이미 실행 중이었고 창만 나타난 것 같은 느낌이 듭니다. 모든 현대 소프트웨어가 이랬으면 좋겠습니다.
- bemtevi
저는 Electron 앱을 거의 좋아한 적이 없습니다. 성능 때문이기도 하고, 더 나은 표현이 없지만 비대함이라는 느낌을 조장하는 것 같아서요. VS Code를 시도했지만 AI를 너무 많이 넣고 복잡성이 너무 커지기 시작했을 때 그만뒀습니다. Sublime이 훨씬 낫습니다.
모르겠습니다... 모든 Electron 앱에는 뭔가 불쾌한 점이 있는 것 같습니다.
- EddieRingle
제 생각에 Discord는 여기서 따라야 할 모델이 아닙니다. 그들은 네이티브 Android 앱을 죽이고 React Native로 옮겼고, 이제 React Native를 버리고 있습니다(CTO의 트윗에 따르면 모바일은 어떻게든 "네이티브 UI"를 유지한다고 합니다). 코드 재사용을 극대화하고 기능 개발을 가속화하려면 대신 Kotlin Multiplatform을 고려했어야 했고, 그러면 React Native 우회 없이 실제로 플랫폼에 네이티브한 앱을 만들 수 있었을 겁니다. (Rust와 그 불협화음 같은 UI 프레임워크들은 제가 알기로 어디에서도 진정한 플랫폼 네이티브가 아닙니다. Pop OS 정도는 있을지 모르지만, 그것을 특별히 대상으로 하는 사람은 모릅니다.)
이 부분은 분명히 주관적이지만, Rust는 언어로서 사람들이 적용하려는 많은 사용 사례, 특히 UI 개발에 충분히 인체공학적이지 않습니다. 지금까지 본 대부분의 Rust UI 라이브러리는 더 명령형 스타일을 사용하거나 Compose UI나 SwiftUI 같은 더 선언적인 접근 방식을 모방하려 하지만, 읽고 쓰기 쉽게 만드는 멋진 언어 미학이 없습니다. 그리고 여기에 대한 반론이 LLM이 이런 것들을 읽고 쓰게 하자는 것이라면, 그것은 완전히 다른 문제입니다: (1) 보조금 받는 추론 시대는 빠르게 끝나가고 있고 (2) 어차피 LLM을 사용한다면, 왜 각 플랫폼에 최대한 네이티브한 앱을 유지하지 않겠습니까?
- azuanrb
Electron은 항상 더 높은 메모리 사용량과 잠재적으로 더 나쁜 성능을 대가로 크로스 플랫폼 앱을 빠르게 출시하는 것에 초점을 맞춰왔습니다. LLM이 있든 없든 핵심 가치 제안은 동일합니다. LLM은 단순히 프레임워크의 기존 강점을 증폭시킬 뿐입니다.
원래 네이티브 macOS 런처였던 Raycast는 최근 하이브리드 아키텍처를 사용한 v2를 출시했습니다. Electron은 아니지만 Spotify 데스크톱 앱과 유사한 접근 방식으로, 네이티브 셸 내부에 웹 기술을 사용합니다.
메모리 사용량은 여전히 상당합니다. 유휴 상태에서 약 350~450MB를 사용하며 워크로드에 따라 때때로 1~2GB에 도달할 수 있습니다. 장점은 이제 macOS와 Windows에서 대부분의 코드를 공유하고 단순한 앱 런처 이상으로 발전할 수 있다는 것입니다.
항상 트레이드오프의 문제였고, LLM이 그것을 근본적으로 바꾸지는 않습니다.