이 문제는 Electron 초기부터 알려져 있었고, VS Code가 처음 나왔을 때도 주요 비판 중 하나였음. Electron의 가치는 언제나 한 팀이 하나의 앱을 만들어 최소한의 추가 작업으로 여러 플랫폼을 지원하는 데 있었는데, 이 글은 그 부분을 전혀 다루지 않음.
데스크톱 개발에서 큰 골칫거리는 의존성 관리이며, 특히 C++이나 네이티브 코드로 개발하면 더 심함. 2010년대에 웹캠을 쓰는 간단한 앱을 만들더라도 Chrome에는 HTML5 실행 환경이 갖춰져 있었지만, 다른 도구에서는 사용자 환경에 없을 수도 있는 별도 라이브러리가 필요했음.
당시 Linux, macOS, Windows에서 같은 코드를 배포하려면 사실상 Qt나 JVM 같은 선택지가 필요했음. JVM 데스크톱 UI는 보기 좋지 않았고 Java의 평판도 나빴으며, 웹캠·마이크·멀티미디어를 쓰려면 동적 라이브러리까지 배포해야 했음. Qt 역시 외부 라이브러리가 끼면 특별한 패키징 역량이 필요했는데, Electron은 방대한 API를 가진 Chrome을 통째로 묶어 이 부담을 없애줌.
지금은 Rust 같은 언어의 패키지 관리 환경이 많이 달라짐. 여러 DLL을 짜 맞추는 대신 의존성을 정적으로 컴파일할 수 있고, Cargo와 Rust가 앱에 필요한 것을 포함하는 작업을 잘 처리해 줌. 다른 언어에도 비슷하게 유용한 도구가 생김.
글이 적어도 간접적으로는 그 부분을 다루고 있음. Electron 출시 당시에는 선택할 만한 크로스 플랫폼 UI 프레임워크가 지금보다 적었음.
비교표를 보면 GPUI가 Electron을 대체해 데스크톱 UI의 여러 플랫폼 지원을 맡고, React Native 대신 WebAssembly를 사용해 모바일까지 Rust를 주력 언어로 삼는 구조임. Discord의 새 구조는 꽤 깔끔해 보이며, 처음 출시할 당시에는 불가능했던 구성임.
이 Discord의 Windows 11용 Rust 앱은 Mint, AOSP, iPad에서 실행되지 않으며, 상당한 이식 작업 없이는 지원하기 어려움. 잘 구현하는 것은 가능하지만, 저렴하거나 유연하거나 시장 변화에 민첩하게 대응하는 방식은 아니며 예전에도 그랬음.
HTML/CSS/JS를 선호하는 데는 충분한 이유가 있고, 그에 따른 절충도 받아들여 온 것임. 이제 상당 부분을 바이브 코딩으로 이식할 수 있다면 달라질지도 모르겠지만, 지켜봐야 함.
문제는 그 선택이 모두의 삶을 더 나쁘게 만들었다는 것임.
Electron의 가치는 결국 “Chrome을 함께 배포하기만 하면 단일 페이지 애플리케이션의 크로스 플랫폼 호환성을 얻을 수 있음”이라는 뜻임.
Discord는 따라갈 만한 모범이 아니라고 봄. 네이티브 Android 앱을 없애고 React Native로 옮겼다가 이제는 그것도 버리면서, CTO의 트윗에 따르면 모바일은 어쨌든 “네이티브 UI”를 유지한다고 함. 코드 재사용과 기능 개발 속도가 목표였다면 Kotlin Multiplatform을 검토해 React Native라는 우회로 없이 플랫폼 네이티브 앱을 만들 수 있었을 것임. 내가 아는 한 Rust와 난립하는 UI 프레임워크는 어느 플랫폼에서도 진정한 네이티브가 아님. Pop!_OS는 예외일 수도 있지만, 그곳만 겨냥하는 개발자는 본 적이 없음.
주관적인 부분이지만, Rust는 사람들이 적용하려는 여러 용도, 특히 UI 개발에 충분히 편리한 언어가 아니라고 봄. 지금까지 본 Rust UI 라이브러리는 명령형에 가깝거나 Compose UI·SwiftUI의 선언형 접근을 흉내 내지만, 읽고 쓰기 쉽게 만드는 언어 차원의 간결함은 부족함.
LLM이 코드를 읽고 쓰면 된다는 반론도 별개의 골칫거리를 만듦. 보조금으로 저렴한 추론을 제공하는 시대는 빠르게 끝나가고 있고, 어차피 LLM을 쓴다면 플랫폼별로 최대한 네이티브인 앱을 유지하지 않을 이유가 무엇인지 모르겠음.
Electron은 소규모 팀이 기존 웹 개발 역량으로 괜찮은 GUI 앱을 만들게 해준다는 점에서 훌륭하지만, 이제 더 나은 대안이 필요한 시점처럼 느껴짐. RAM 가격이 이렇게 비싼데 기본 작업 때문에 수 GB씩 먹는 앱을 여러 개 실행해야 하는 것은 답답함. Discord에서는 사용의 90%가 메시지를 읽고 쓰는 일이고, 음성 채팅 같은 고급 기능은 필요할 때 불러올 수도 있음.
나는 512MB RAM으로 Linux 전체 구성에 Podman, 모니터링, 알림, 여러 서비스까지 편하게 돌리며, 방금 확인해 보니 메모리가 40%나 남아 있음. 반면 Windows PC는 바탕화면만 띄워도 5.5GB가 필요함. 기본적인 웹 탐색에도 현실적으로 8~16GB가 필요하고, Discord 같은 앱 몇 개가 백그라운드에 있으면 그마저 느리게 느껴질 수 있음.
네이티브 앱과 비교해서 괜찮다고 할 만한 Electron GUI 앱을 보여줄 수 있나요? 직접 나열한 메모리 문제만 봐도 답이 드러나며, 앱이 메모리를 많이 쓰는 이유가 Electron임. 웹 앱의 축소된 GUI보다 운영체제의 네이티브 앱처럼 동작하는 UI를 선호함.
Qt로 모든 운영체제에서 쓰는 단일 코드베이스를 만드는 것은 정말 쉬움. BSD까지 포함해 혼자 여러 번 해봤음. 그런데 수백 MB쯤 더 써도 괜찮다며 그냥 출시하는 태도는 너무 게으르다고 봄. 수십억, 수조 달러 규모의 기업들까지 Electron으로 형편없는 제품을 내놓는 이유를 이해하기 어려움.
경력 내내 간간이 Qt 앱 개발을 해왔지만, Qt 앱도 Electron 앱만큼 원하지 않음. 해법은 플랫폼 고유 도구로 만드는 네이티브 앱이나 성숙한 크로스 플랫폼 도구 모음임.
요즘은 개발에 노력을 덜 들일수록 좋다는 식으로 접근하는 듯함. 나도 wxWidgets와 OpenGL 기반 3D 게임 도구를 결합해 세 플랫폼에서 돌아가는 시각화 코드를 작성했음. 대부분의 2D 컨트롤은 wxWidgets의 OnPaint 처리기로 직접 그려 해당 플랫폼에서 네이티브로 렌더링했으며, 이 부분은 혼자 만들고 동료 한 명이 네트워크 코드와 원격 장치 펌웨어를 맡았음.
내 기준에서는 다른 선택이 순전히 게으름으로 보임. 이제 LLM이 UI 코드 대부분을 작성할 수 있으니 변명할 여지는 더 줄어듦.
주력 UI가 웹이라면 Qt 단일 코드베이스가 그렇게 쉬운 선택은 아님.
사람들이 Telegram을 쓰기 시작한 이유가 궁금했다면, 이런 문제가 큰 부분을 차지함.
요즘은 느린 앱 시작에 너무 익숙해진 것 같음. 최근 Task Slinger를 쓰기 시작했는데, 실행할 때마다 이미 실행 중이던 앱의 창만 나타난 듯한 느낌이 듦. 모든 현대 소프트웨어가 이랬으면 좋겠음. https://taskslinger.net/
내 프로그램의 로딩 시간을 설계할 때는 옛 System Shock 2에서 영감을 얻음. 게임을 실행하면 마지막 저장 상태가 배경에 일시 정지된 채 바로 주 메뉴가 나타나고, Play를 누르면 실제로는 일시 정지가 풀림. 플레이어 입장에서는 로딩 시간도 절차도 없는 셈임.
어떤 기술 구성을 쓰는지 아시나요? 웹사이트에는 자체 Direct3D 렌더러만 나와 있음.
현대적인 앱은 원래 다 이렇게 동작함. 오히려 Electron 앱이 전부 구식임.
Electron의 장점 하나는 접근성과 비영어권 입력기(IME) 를 제대로 지원한다는 것임. 덕분에 모든 Electron 앱은 기본적으로 웹 앱에 준하는 괜찮은 접근성을 갖춤.
적어도 2025년 기준으로 대부분의 Rust GUI 도구 모음은 접근성이나 IME 지원이 그만큼 좋지 않았음. https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-....
지금은 개선됐기를 바라며, 새 Discord 클라이언트가 이 부분에서 퇴보하지 않았으면 함.
성능도 그렇고 앱이 비대해지는 느낌도 있어서 Electron 앱을 좋아한 적이 거의 없음. VS Code를 써봤지만 AI와 복잡성이 너무 많이 들어오기 시작하면서 그만뒀고, Sublime이 훨씬 나음. Electron 앱에는 전반적으로 뭔가 불쾌한 구석이 있는 듯함.
메뉴에 접근하는 네이티브 UI 컨트롤이 없고, 키보드로 우클릭 메뉴를 여는 등의 작업에서 포커스 추적이 제대로 되지 않아 사용하기 어려움. 모든 작업에 마우스를 써야 함.
VS Code를 한동안 썼지만, 일상적인 사용 속도가 훨씬 빠르다는 이유만으로 Qt Creator로 돌아옴.
Electron은 데스크톱 개발에 일어난 최악의 일에 가깝다고 보기에 전적으로 동의함. 관련해서 궁금한 점도 있음. 인기 있는 오픈 소스 LLM 하네스는 pi, hermes, opencode, paseo처럼 거의 모두 JS나 Python으로 작성된 듯하고, 내가 써본 비공개 제품인 DeepSeek과 ChatGPT도 비슷해 보임.
왜 Go, Rust, 심지어 C 대신 JS나 Python으로 하네스 애플리케이션을 구현하는지 궁금함. 1년 전이라면 이해하겠지만, 지금은 특히 LLM 기업에 사실상 무제한 토큰이 있으니 Go나 Rust로 재작성하는 일도 간단해야 하지 않을까요? RAM이 비싸고 부족한 요즘에는 많은 사람에게 도움이 될 것임.
인터프리터 언어를 깎아내리려는 게 아니라 진심으로 궁금함. 컴파일 언어가 더 빠르고 RAM을 덜 쓴다는 것은 보편적인 사실이어야 하는데, 왜 아무도 하지 않는 걸까요?
좋은 이유 하나는 확장성임. Pi는 매우 자유롭게 바꿀 수 있는데, Rust로 작성했다면 그만큼 유연하게 만들기 어려웠을 것임. 내가 쓰는 하네스의 자원 사용량은 Electron 앱과 비교하면 미미하고, RAM 몇 MB를 아끼는 것보다 쉽게 맞춤화하는 편이 더 중요함.
최근 정확성과 ‘기억’의 개선 대부분이 하네스에서 나오기 때문에, 가장 빠르게 발전하고 제품 차별화에도 기여하는 소프트웨어를 빠르게 수정하고 시험하려는 것이라고 추측함. 하네스가 ‘완성’되면 컴파일 언어로 최적화할 수도 있음. 특정 용도의 하네스는 완성이 가능하겠지만, 코딩용은 아마 끝이 없을 것임.
제안한 언어들이 인터프리터 언어가 아니라 컴파일 언어라는 점도 이유일 수 있음. 세 개 이상의 플랫폼에 맞춰 컴파일하고 바이너리를 배포하는 작업은 사소해 보여도, 개발을 훨씬 어렵게 느끼게 할 만큼 복잡성과 마찰을 더함.
거의 아무도 신경 쓰지 않는 성능 개선을 얻으려고 훨씬 큰 개발 비용을 들여야 했기 때문임.
LLM 응답을 기다리는 시간에 비하면 하네스 자체의 실제 실행 시간은 극히 작은 비중이기 때문임.