요약
디스코드가 Rust로 새로 만든 앱은 Electron 앱보다 먼저 뜨고, 계정 두 개를 켜고도 메모리를 290MB만 씁니다.
윈도스 레이티스트의 편집자가 디스코드 CTO 스타니슬라프 비시넵스키가 X에 올린 비교 영상을 프레임 단위로 살펴봤습니다. 필자는 큰 채팅 앱도 내장 브라우저 없이 만들 수 있음이 드러났으니 메타와 마이크로소프트도 핑계가 줄었다고 주장했습니다.
왜 중요한가
- 누구나 늘 켜 두는 대형 채팅 앱이 Electron(크로미움 브라우저를 통째로 싣는 데스크톱 앱 틀)을 버린 사례입니다.
- 필자는 AI 수요로 메모리 값이 오르면서 앱의 메모리 사용량을 줄이라는 압박이 커졌다고 봤습니다.
- WebView2로 감싼 WhatsApp(최대 1.2GB)과 대기 중에도 963MB를 쓰는 Microsoft Teams가 다음 비교 대상으로 꼽혔습니다.
핵심 내용
- 새 앱은 Zed 편집기 개발사의 GPUI(HTML 없이 GPU로 화면을 직접 그리는 Rust 프레임워크)로 만들었습니다.
- 꺼진 상태에서 켜는 영상에서 1.5초 늦게 실행한 새 앱이 '시작 중' 화면 없이 먼저 친구 목록을 띄웠습니다.
- 계정 두 개 로그인 상태에서 290.2MB였고, 필자는 디스코드가 밝힌 1GB 미만보다 약 70% 적다고 계산했습니다.
- 모바일 앱은 React Native를 버리고, 웹 앱은 로직을 WebAssembly로 옮기되 화면은 HTML로 그립니다.
- 초기 빌드의 수치이고 같은 조건의 비교는 공개되지 않았으며, 출시일도 정해지지 않았습니다.
HN 반응
- Electron이 개발자 시간만 아끼고 사용자 경험을 망쳤다는 비판과, 하나의 코드로 윈도·맥·리눅스를 지원하게 해 준 현실적 선택이라는 옹호가 맞섰습니다.
- 늘 켜 두는 채팅 앱들이 합쳐서 엄청난 메모리를 차지한다는 지적이 나왔고, 데스크톱 앱 대신 브라우저에서 Slack이나 디스코드를 쓴다는 이용자도 여럿이었습니다.
이 페이지에서 Electron을 옹호하는 말이 이렇게 많은 걸 보니, 소프트웨어 개발자들이 소프트웨어를 설계할 자격을 갖출 만큼의 공감 능력이 없는 경우가 얼마나 많은지 새삼 씁쓸해집니다.
UI가 있는 건 정의상 사람이 쓰라고 만든 물건입니다. Electron은 프로그래머 인건비를 아낀다는 관점에서만 말이 되는 선택이고, 그 결과 한 세대 더 새롭고 빠른 컴퓨터가 옛날의 느린 컴퓨터 속도로 끌려 내려갔으며 사용자 경험은 비참해졌습니다.
어쨌든 이건 좋은 소식입니다. 특히 Discord가 이런 결정을 내릴 거라고는 전혀 생각하지 못했습니다.
굉장히 절대주의적인 이념처럼 들리는데, 마치 경험적 사실인 것처럼 말씀하시네요.
반례 하나를 들자면 Slack이 있습니다. Slack은 이미 존재하던 소프트웨어 분야인 업무용 커뮤니케이션을 더 나은 설계와 경험으로 뒤바꿔 놓았는데, Electron 위에서 만들어졌습니다.
추가: 게다가 지금 이 댓글은 Discord 소식에 달린 건데, Discord는 일반 소비자용 채팅을 뒤바꿔 놓은 Electron 앱입니다.
Slack이 UI가 좋아서 이긴 건 절대 아닙니다.
기업 영업 방식이 좋았고, 기업 시스템과의 연동 기능이 좋았던 거죠.
낚시 댓글인가요, 아니면 XMPP 광신자인가요?
Slack이 Lync/Communicator를 이겨서 마이크로소프트가 경쟁 제품을 처음부터 새로 만들게 했는데, 그게 기업 영업을 더 잘해서였다는 말씀이세요?
말의 절반을 무시하면 그렇게 되죠.
그리고 Slack 이전의 경쟁 상대는 Lync 같은 게 아니라 메일, 재버(Jabber), 회사가 허락하지 않은 채팅(WhatsApp 등)이었습니다.
이쯤 되면 누구랑 논쟁하시는 건지 모르겠네요. Slack UI 얘기를 꺼낸 건 그쪽이잖아요.
저는 정반대 극단에 있습니다. Electron을 버리고, 앱을 전부 네이티브 같은 느낌으로 돌릴 수 있을 만큼 잘 통합된 브라우저를 써야 합니다. 같은 엔진을 재사용하는 거죠(OS에 딸린 허술한 웹뷰 말고 완전한 엔진으로요). 그러면 메모리 오버헤드가 해결되고, Electron 앱마다 들어 있는 패치 안 된 크로미움이나 잘못 설정된 크로미움 문제도 해결되며, 이식성도 얻고 웹 개발 기술도 재사용할 수 있습니다. 또 권한과 보안을 그것에만 집중하는 계층이 관리할 수 있게 되니, 네이티브 앱이 뭘 할 수 있는지 걱정하지 않아도 됩니다. (OS 권한과 샌드박싱은 바이브 코딩으로 쏟아지는 무한한 소프트웨어를 위해 만들어진 게 아니고, 앞으로도 따라잡지 못할 겁니다.) 성능을 비롯한 다른 주장들은 전부 사실이 아닙니다. 잘 만든 웹앱은 특히 긴 스크롤 목록에서 네이티브 앱보다 성능이 더 좋은 경우가 많고, 접근성이나 확장 기능 같은 건 말할 것도 없습니다. 저는 Discord나 Spotify가 제 컴퓨터에서 네이티브로 뭔가를 실행하는 걸 절대 믿지 않을 거고, 다른 누구도 그래서는 안 됩니다.
잘 만든 웹앱이 잘 만든 네이티브 앱보다 성능이 더 좋을 수는 절대 없습니다. JavaScript라는 추상화 때문에 원천적으로 불가능합니다.
JavaScript에 비용이 드는 건 맞지만, Chrome의 텍스트 렌더러는 정말 말도 안 되게 최적화되어 있어서 OS의 리스트 뷰보다 분명히 더 빠를 수 있습니다. 얼마 전에 HN에 올라온 글에서 다룬 적이 있어요.
문제는 GTK/Cocoa/WinUI를 이길 수 있느냐가 아니라, Discord가 쓰고 있는 GPUI 같은 다른 리테인드 모드 렌더러보다 빠르냐는 겁니다.
또 브라우저 탭 하나만 띄워도, 탭마다 OS에서 실제 바이너리를 돌릴 때보다 메모리 오버헤드가 훨씬 큽니다. 개발자가 JavaScript를 한 줄 쓰기도 전에 처음부터 낭비되는 메모리입니다.
Chrome이 Skia를 쓰는 거 아닌가요? 그건 직접 만드는 네이티브 앱에서도 쓸 수 있잖아요.
맞아요! 그리고 쓸 수 있죠. 그런데 Skia는 위젯 라이브러리가 아니라 즉시 모드 렌더러예요. 위젯 계층 전체를 직접 짜야 합니다. Chrome은 바로 그걸 제공하는 거고요(HTML이라는 아주 유명한 위젯 라이브러리와 묶여서요).
링크가 있으시거나 뭐라고 불렸는지 기억하세요?
https://skia.org
문제는 그게 어떤 비용을 치르고 얻는 거냐는 것과, 둘 다 최적 수준이 되면 사용자에게 그 차이가 의미가 있는지, 아니면 구분이 안 되는지입니다. 네이티브가 맞는 앱은 언제나 1% 있을 거고, 저는 나머지 99%의 애플리케이션 얘기를 하고 있습니다.
공평하게 말씀드리면, 위쪽 글에서 "앱을 전부"라고 분명히 쓰셨으니 읽는 사람이 99%가 아니라 100%를 뜻한다고 받아들일 수도 있습니다.
그럼 JavaScript 추상화를 고치면 되죠. 저는 요즘 dart-wasm으로 더 좋은 성과를 보고 있어서, 누군가 표준을 마무리해 주기를 기다리고 있습니다.
네이티브 워크플로와 통합하려는 경우라면 여기서 보안 경계를 긋기가 어렵습니다.
외관과 사용감을 그대로 베낀 가짜 웹사이트를 관리하기도 어렵고요. 사람들을 속여서 접근 권한이나 비밀번호를 넘기게 만드니까요.
믿을 만한 출처에서 한 번 설치하는 네이티브 앱이 더 안전하다고 생각합니다.
저는 Discord를 그냥 브라우저에서 씁니다.
네이티브 앱은 데스크톱에 열려 있는 창 제목을 읽는데, 그 밖에 뭘 더 하는지는 하느님만 아시겠죠.
(사실 지금은 Discord를 아예 안 쓰지만, 데스크톱 앱은 일부러 한 번도 안 썼습니다.)
화면 공유를 가능하게 하려는 거겠죠? 그래서 앱 안에서 창 제목을 볼 수 있게요. 물론 OS가 그건 샌드박스로 막아야 하겠지만요.
제가 알아본 바로는, 지금 하고 있는 일을 상태 표시에 띄우려고 그러는 겁니다.
Electron을 왜 그렇게 싫어하는지 이해가 안 됩니다. 여기 계신 분들 대부분은 크로스 플랫폼 앱을 출시해 본 적이 없고, 여러 플랫폼에 걸쳐 유지보수해 본 적은 더더욱 없는 것 같아요. 이건 재정적인 결정입니다. Electron은 (AI 이전 시대에) 거인의 어깨 위에 서서 하나의 코드베이스로 여러 OS에서 믿을 만한 제품을 만들 수 있게 해 줬습니다. Java가 약속했던 걸 Electron이 대부분의 최종 사용자용 앱에서 실제로 해냈죠. 구글이 Electron의 기반을 빠르고 안정적이며 버그 없게 만드는 데 수십억 달러를 쏟아부었고요. 그리고 Electron 덕분에 원래라면 나오지 않았을 앱의 리눅스 포팅이 많이 나왔습니다.
가장 좋은 예가 vscode입니다.
Electron 앱이 네이티브보다 낭비가 심하냐고요? 물론입니다. 하지만 저는 Electron을 택하고 윈도, 맥, 리눅스가 모두 지원되는 쪽에 서겠습니다.
어느 정도는 맞습니다. 제로섬이라는 말씀은 옳아요.
하지만 제작사가 강제하는 Electron 애플리케이션(즉 서드파티 클라이언트는 명시적으로 금지되어 있고 EULA 위반이라 플랫폼에서 쫓겨날 수도 있는 경우)은 분명히 문제입니다.
요즘 AI 때문에 전 세계 RAM 위기를 말하지만, Teams/Slack과 Discord가 전부 합쳐서 RAM을 얼마나 쌓아 두고 있는지는 생각하고 싶지도 않습니다. 이 앱들은 모든 사람이 백그라운드에서 켜 두라고 만들어진 것들이라, 사람들이 이 중 하나 이상은 돌리고 있을 게 확실하니 1인당 최소 2GiB는 됩니다.
1.5GiB * 일하는 사람 수 = 뭐... 유럽에서만 150페타바이트의 RAM이라고요? 채팅 때문에요?
저는 Slack을 브라우저에서 쓰는데, 다른 방식으로 쓰는 사람이 있다는 게 이해가 안 되네요.
그게 정말 Electron 잘못인가요?
vscode의 메모리와 CPU 사용량을 그 전에 쓰던 IDE와 비교해 보세요. 아마 자릿수가 하나 다를 만큼 효율적일 겁니다.
저는 vscode를 안 쓰는 vim 사용자지만, vscode 리모트가 공용 서버의 디스크를 기가바이트 단위로 낭비하는 걸 보면 끔찍합니다.
VS Code는 IDE가 아니라 Sublime에 더 가깝습니다.
Sublime과 비교하면 실제로 더 느리고 자원도 더 비효율적이지만, 무료이고 쓸 만합니다.
모든 게 기술적 순수성으로 귀결되지는 않습니다. 중요한 다른 요소들도 있어요.
예전에는 그 말이 맞았지만, 플러그인이 붙으면서 vscode가 대부분의 사람들에게 IDE 워크플로 전체를 집어삼켰습니다.
Sublime Text도 마찬가지고, vim도 그렇습니다.
어떤 것이 다른 무언가로 바뀔 수 있다고 해서 비교가 무의미해지는 건 아닐지 모르지만, 어떤 것의 기반이 그것이 진화해서 될 수 있는 그것이라는 뜻은 아닙니다.