Hacker News나 Reddit에서 충분히 시간을 보내다 보면 결국 같은 비판을 보게 된다. Electron은 비대하고, 메모리를 너무 많이 사용하며, 제대로 된 데스크톱 애플리케이션은 네이티브로 만들어야 한다는 것이다.
그 비판에는 어느 정도 진실이 있다. Electron 애플리케이션은 Chromium과 Node.js를 함께 배포하기 때문에 일반적으로 기본적인 리소스 사용량이 더 크다. 세심하게 설계한 네이티브 애플리케이션은 메모리를 덜 사용하고, 더 빠르게 실행되며, 운영체제와 더 깊이 통합될 수 있다.
하지만 이 논쟁은 컴퓨터에 지나치게 집중하고, 소프트웨어를 만드는 회사에는 충분히 주목하지 않는다.
대부분의 사용자에게 애플리케이션에 사용된 기술은 거의 중요하지 않다. 사용자는 제대로 작동하는지, 반응이 빠른지, 버그가 수정되는지, 유용한 기능이 계속 추가되는지를 중요하게 여긴다. 따라서 소프트웨어 회사에 기술 스택의 가장 중요한 특성 중 하나는 벤치마크 표에 거의 등장하지 않는 질문이다. 팀이 얼마나 빠르게 제품을 만들고, 출시하고, 배우고, 개선할 수 있는가?
많은 현대적인 데스크톱 애플리케이션에서 Electron은 이 점에 특히 뛰어나다.
희소한 자원은 개발 시간이다
이상적인 네이티브 데스크톱 소프트웨어 회사에는 뛰어난 macOS 팀이 있고, Windows 애플리케이션을 만드는 별도의 팀이 있으며, 어쩌면 Linux를 지원하는 또 다른 팀도 있을 것이다. 모든 애플리케이션은 각 플랫폼에 맞게 세심하게 최적화되어 있고, 모든 개발자는 자신이 담당하는 운영체제를 깊이 이해한다.
대부분의 회사에는 그런 여유가 없다.
데스크톱 제품의 개발자가 다섯 명일 수도 있다. 두 명일 수도 있다. 이 개발자들이 기능을 만들고, 버그를 수정하고, 성능을 개선하고, 고객에게 대응하고, 인프라를 유지 관리하고, 운영체제의 변화에 대처하면서 제품을 계속 발전시켜야 한다.
네이티브 개발은 이를 더 어렵게 만든다. macOS, Windows, Linux는 실제로 서로 다른 플랫폼이기 때문이다. UI 프레임워크, API, 권한 시스템, 애플리케이션 수명 주기 동작, 설치 프로그램, 업데이트 방식, 알림 시스템, 창 관리, 접근성 API가 다르고, 오랜 세월 누적된 플랫폼별 특이 사항도 다르다.
Electron은 이 방정식을 바꾼다. Chromium, Node.js, 데스크톱 API를 결합해 macOS, Windows, Linux에서 공통으로 사용할 수 있는 애플리케이션 모델을 제공한다. 한 명의 TypeScript 개발자가 인터페이스부터 애플리케이션 로직까지 기능을 구현하고, 모든 데스크톱 플랫폼에 출시할 수 있는 경우가 많다. 정말 필요한 경우에는 여전히 네이티브 코드를 사용할 수 있지만, 이는 제품의 기반이 아니라 예외가 된다. Electron 자체도 이를 핵심 장점 중 하나로 설명한다. 하나의 JavaScript 코드베이스로 세 가지 주요 데스크톱 플랫폼을 지원한다는 것이다.
그 차이는 수년에 걸쳐 누적된다. 중요한 기능마다 Mac과 Windows용 구현을 따로 만들어야 한다면, 회사는 플랫폼별로 발생하는 추가 비용을 반복해서 지불해야 한다. 모든 기능, 디자인 개편, 실험, 버그 수정, 접근성 개선, 성능 최적화 때마다 그렇다.
Electron을 사용하면 그 작업의 상당 부분을 한 번만 하면 된다.
Electron은 반복적인 개선 속도에 최적화되어 있다
제품이 훌륭해지는 이유는 첫 구현이 완벽해서인 경우가 드물다. 제품은 반복적인 개선을 통해 훌륭해진다.
팀이 무언가를 출시한다. 고객이 사용한다. 팀이 배운다. 기능을 바꾼다. 더 많은 사람이 사용한다. 또 다른 문제가 드러난다. 팀이 다시 개선한다.
아이디어, 구현, 피드백, 개선으로 이어지는 순환이 짧을수록 제품은 더 빠르게 좋아진다.
Electron은 이 순환을 단축하는 데 특히 뛰어나다. 소프트웨어 회사들이 이미 곳곳에서 사용하는 기술인 JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js, npm을 중심으로 구축되어 있기 때문이다.
이는 회사가 소스 코드보다 훨씬 더 많은 것을 공유할 수 있다는 뜻이다. 웹 제품과 데스크톱 제품 사이에서 개발자, UI 컴포넌트, 도구, 라이브러리, 인프라, 테스트 방식, 조직에 축적된 지식을 공유할 수 있다.
회사에 Windows 클라이언트 개발을 도울 사람이 필요하다고 해서 프런트엔드 개발자가 갑자기 쓸모없어지는 것은 아니다. 데스크톱 개발자는 웹 애플리케이션에 기여할 수 있다. 풀스택 TypeScript 개발자는 우선순위가 바뀌면 제품 간에 이동할 수 있다.
중소 규모 회사에는 이런 유연성이 RAM 100MB를 절약하는 것보다 훨씬 더 큰 가치가 있을 수 있다.
실제로 누가 Electron을 사용하는지 살펴보자
Electron은 때때로 ‘제대로 된’ 데스크톱 애플리케이션에 투자할 의지가 없는 회사들이 택하는 지름길로 묘사된다. 하지만 Electron으로 만든 제품들을 보면 그 주장을 유지하기가 점점 어려워진다.
Electron 프로젝트는 Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom, Canva 같은 제품을 대표 사례로 소개한다. 이들은 단순한 유틸리티가 아니다. 상당수는 세계에서 가장 정교하고 널리 사용되는 생산성 애플리케이션에 속한다.
Visual Studio Code는 특히 유용한 사례다. Microsoft는 자사의 대표 코드 편집기를 사실상 원하는 어떤 Windows 기술로도 만들 수 있었지만, VS Code는 Windows, macOS, Linux에서 Electron을 사용한다. 터미널, 디버깅, 언어 서버, Git 통합, 원격 개발, 노트북, 확장 기능, 고도로 맞춤화된 편집기를 포함한다.
흥미로운 질문은 Microsoft가 네이티브 버전 세 개를 따로 만들어 메모리를 절약할 수 있었느냐가 아니다. 물론 가능했을 것이다.
더 나은 질문은 주요 기능마다 여러 개의 별도 구현이 필요했다면 VS Code가 지금처럼 빠르게 발전하고, 플랫폼 간 일관성을 유지하며, 이렇게 큰 생태계를 형성할 수 있었겠느냐는 것이다.
ChatGPT와 Claude는 접근 방식의 차이를 보여준다
ChatGPT와 Claude의 대비도 시사하는 바가 있다.
OpenAI는 처음에 ChatGPT를 위한 전용 네이티브 macOS 애플리케이션을 만들었다. 반면 Anthropic은 Claude Desktop을 Electron으로 구축했고, 처음부터 플랫폼 간에 공유할 수 있는 데스크톱 기반을 갖췄다.
제품이 확장되면서 그 차이는 더 중요해졌다. Claude Desktop은 MCP 통합, 확장 기능, Claude Code 같은 기능을 동일한 크로스 플랫폼 애플리케이션에 계속 추가할 수 있었다. Anthropic은 이제 여러 로컬 및 원격 세션을 포함해 데스크톱 환경 안에서 Claude Code를 직접 지원한다.
이후 OpenAI도 새로운 크로스 플랫폼 데스크톱 개발 방향을 Electron 쪽으로 전환했고, 현재 Electron은 ChatGPT와 Claude를 모두 주요 Electron 애플리케이션으로 소개한다.
Electron만으로 제품 개발 속도의 차이를 설명할 수 있다고 주장하는 것은 지나치다. 팀 규모, 우선순위, 제품 전략, 내부 조직 모두 중요하다. 하지만 아키텍처의 이점은 명확하다. 공통의 크로스 플랫폼 기반이 있으면 별도의 구현을 유지하지 않고도 여러 운영체제에 기능을 출시하기가 쉬워진다.
이는 데스크톱 제품이 성장할수록 가치가 더 커지는 바로 그런 이점이다.
Evernote는 별도 클라이언트를 유지하는 비용을 배웠다
Evernote는 이 문제를 보여주는 가장 명확한 역사적 사례 중 하나다.
수년 동안 Evernote는 Mac, Windows, 모바일, 웹에서 서로 다른 애플리케이션을 유지했다. 시간이 흐르면서 이 제품들에는 서로 다른 동작, 렌더링 차이, 과거 설계의 전제, 동기화 문제가 누적되었다.
2020년 Evernote는 공통 코드베이스를 중심으로 Windows와 Mac 애플리케이션을 다시 만들었다. 회사는 새로운 기반을 통해 앱의 안정성을 높이고, 버그를 더 빠르게 수정하고, 기능을 더 자주 출시하며, 플랫폼 간 동기화를 개선할 수 있을 것이라고 밝혔다.
그 전환에는 어려움이 있었고, 일부 오랜 사용자는 초기에 플랫폼별 기능이 사라진 것을 달가워하지 않았다. 하지만 Evernote가 그렇게 비용이 많이 드는 재작성을 추진한 이유는 전환 과정의 문제 자체보다 더 흥미롭다.
제품에 풍부한 기능을 갖춘 편집기, 오프라인 저장소, 검색, 첨부 파일, 협업, 작업 관리, 캘린더, 복잡한 동기화가 들어가면 여러 독립적인 구현을 유지하는 비용은 점점 커진다. 버그의 양상이 다르다. 렌더링도 다르다. 동기화 로직은 서로 다른 로컬 아키텍처와 상호작용한다. 의미 있는 제품 변경 사항은 모두 여러 클라이언트에 반영되어야 한다.
공통 아키텍처가 어려운 문제를 없애주는 것은 아니다. 더 많은 문제를 한 번만 해결할 수 있게 해준다.
Linux는 Electron의 가장 저평가된 장점일 수 있다
Linux를 생각하면 Electron의 장점은 더욱 뚜렷해진다.
Linux를 제대로 지원하기는 어렵다. macOS나 Windows와 달리 ‘Linux 데스크톱’은 엄격하게 통제되는 하나의 플랫폼이 아니다. 개발자는 서로 다른 배포판, 패키지 형식, 데스크톱 환경, 그래픽 스택, 시스템 라이브러리, 디스플레이 프로토콜을 다뤄야 한다.
많은 소프트웨어 회사에서 합리적인 사업적 결정은 단순히 Linux를 지원하지 않는 것일 수 있다.
Electron은 이 비용 구조를 바꾼다.
Electron은 macOS, Windows, Linux에서 공통 런타임을 제공하므로, 별도의 네이티브 Linux 구현을 유지하는 것보다 Linux 지원을 추가하기가 훨씬 쉬울 수 있다. 오늘날 Linux 사용자가 과거 같았으면 공식 Linux 클라이언트가 아예 나오지 않았을 여러 주요 데스크톱 애플리케이션을 사용할 수 있는 이유 중 하나가 이것이다.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian을 비롯한 많은 도구는 완전히 별개의 GTK나 Qt 애플리케이션을 유지하지 않고도 Linux를 지원할 수 있다.
Electron은 애플리케이션 개발자를 대신해 Linux 특유의 복잡성도 상당 부분 떠안는다. X11에서 Wayland로의 전환이 좋은 예다. Electron 유지 관리자는 Chromium의 Wayland 전환이 사실상 Electron 애플리케이션도 함께 전환시켰고, 그 덕분에 각 애플리케이션 팀이 독자적으로 해야 하는 디스플레이 스택 작업이 줄었다고 설명한 바 있다.
Electron 같은 프레임워크가 없다면 많은 회사는 네이티브 Linux 클라이언트를 만들지 않을 것이다. 그저 macOS와 Windows만 지원하고, Linux 사용자에게는 브라우저 탭만 남겨둘 것이다.
Electron은 아마도 사람들이 인정하는 것보다 상용 Linux 데스크톱 소프트웨어에 훨씬 더 크게 기여했을 것이다.
Microsoft조차 점점 더 웹 기술을 선택한다
Microsoft는 제대로 된 Windows 소프트웨어라면 항상 네이티브 Windows UI 프레임워크를 사용해야 한다는 생각에 대한 가장 강력한 반례일 것이다.
Microsoft는 Windows를 관리한다. Win32, .NET, WinUI, WebView2와 개발자들이 기반으로 삼는 플랫폼의 상당 부분도 관리한다. 완전한 네이티브 Windows 개발이 언제나 명백한 정답이라면, Microsoft는 이를 모든 곳에 적용하기에 가장 유리한 위치에 있을 것이다.
하지만 그렇게 하지 않는다.
Visual Studio Code는 Electron을 사용한다. Teams는 Microsoft가 Electron을 더 최적화된 WebView2 호스트로 교체한 뒤에도 여전히 React, TypeScript, Chromium을 중심으로 구축되어 있다. 새로운 Windows용 Outlook 역시 웹 기술에 크게 의존하며, Microsoft는 이 아키텍처를 민첩성을 높이고, 기능을 더 빠르게 제공하며, 더 일관된 경험을 만드는 방법이라고 명시적으로 설명한다.
Teams는 특히 시사하는 바가 크다. Microsoft는 성능을 개선하고 리소스 소비를 줄이기 위해 아키텍처를 바꿨다. 하지만 UI를 전통적인 Windows 네이티브 애플리케이션으로 다시 작성하지는 않았다.
웹 스택을 유지한 채 그 주변을 최적화했다.
이 차이는 중요하다. Microsoft는 성능을 적극적으로 개선하면서도 React, TypeScript, Chromium이 제공하는 조직적 이점은 유지할 가치가 있다고 판단했다.
여기에는 또 다른 교훈도 있다. Microsoft 자체가 수년 동안 Win32, WPF, UWP, WinUI 등 여러 세대의 Windows 애플리케이션 기술을 도입해 왔다. ‘네이티브 Windows’를 선택하는 회사가 반드시 시대를 초월하는 플랫폼을 선택하는 것은 아니다. Microsoft가 선호하는 프레임워크의 특정 세대에 베팅하는 경우가 많다.
다소 역설적으로, 웹 플랫폼은 현재 선택할 수 있는 더 안정적인 애플리케이션 실행 기반 중 하나가 되었다.
채용도 아키텍처의 일부다
프레임워크 선택은 누구를 채용할 수 있는지도 결정한다.
JavaScript와 TypeScript 개발자는 업계에서 가장 큰 개발 인재 풀 중 하나를 이룬다. Electron으로 제품을 만드는 회사는 숙련된 macOS, Windows, Linux 전문가들로 별도 팀을 구성할 필요 없이 그 인재 풀에서 채용할 수 있다.
네이티브 전문가는 여전히 가치가 있다. 본격적인 데스크톱 제품에는 운영체제를 깊이 이해하는 개발자가 여전히 필요하다. 하지만 Electron은 필요한 전문가의 수를 바꾼다.
애플리케이션 대부분을 플랫폼 전문가가 만들어야 하는 대신, 비교적 적은 양의 네이티브 통합 코드를 유지하고 팀의 대다수가 공통 제품을 개발하도록 할 수 있다.
회사가 이미 웹 애플리케이션을 가지고 있다면 이는 더욱 중요하다. React 컴포넌트를 공유할 수 있는 경우가 있다. TypeScript 라이브러리를 재사용할 수 있다. 제품 로직을 웹과 데스크톱 사이에서 옮길 수 있다. 개발자는 완전히 다른 생태계를 배우지 않고도 팀을 옮길 수 있다.
인력 운영의 취약성도 줄어든다. 네이티브 Windows 클라이언트를 깊이 이해하는 유일한 개발자가 퇴사하면 그 전문성을 대체하기 어려울 수 있다. Electron을 사용하면 코드베이스의 훨씬 더 많은 부분이 조직의 다른 구성원에게도 익숙한 기술을 사용한다.
따라서 프레임워크는 단순히 인터페이스를 어떻게 렌더링할지만 결정하는 것이 아니다. 개발 조직 자체를 어떻게 구성할 수 있는지에도 영향을 준다.
네이티브라고 자동으로 더 좋은 소프트웨어가 되는 것은 아니다
개발자들은 종종 ‘네이티브’를 거의 ‘빠르다’의 동의어처럼 사용한다.
하지만 둘은 같지 않다.
네이티브 API는 개발자에게 매우 효율적인 애플리케이션을 만들 기회를 제공한다. 최종 제품이 실제로 그 효율성을 달성하는지는 아키텍처, 팀, 예산, 회사가 감당할 수 있는 최적화 작업의 양에 달려 있다.
네이티브 애플리케이션도 느리고, 버그가 많고, 메모리를 많이 쓰고, 일관성이 없거나 유지 관리가 부실할 수 있다.
더 중요한 점은 제한된 인력을 여러 네이티브 구현에 나눠 배치하면 각 구현에 투입되는 개발 시간이 줄어든다는 것이다.
회사가 데스크톱 제품에 투입할 수 있는 개발자가 여섯 명이라고 가정해 보자. 한 가지 선택은 이들을 Mac과 Windows에 나눠 배치하고, 어쩌면 Linux는 지원하지 않는 것이다. 다른 선택은 여섯 명 거의 전부를 세 플랫폼을 모두 지원하는 하나의 공통 Electron 애플리케이션에 투입하는 것이다.
어느 접근 방식이 시작 시간을 개선하고, 메모리 누수를 수정하고, 상호작용을 다듬고, 접근성을 개선하고, 비정상 종료를 줄이고, 사용자에게 대응하는 데 더 많은 개발 역량을 확보하게 해줄까?
네이티브 애플리케이션이 더 나은 제품을 만들어낸다고 단정할 수는 없다.
이는 흥미로운 역설을 낳는다. 컴퓨터 리소스를 조금 더 소비하는 프레임워크가 개발 리소스를 훨씬 덜 소비하기 때문에, 회사가 더 잘 최적화된 제품을 만들 수 있게 해줄 수 있다.
Electron은 통제 가능한 플랫폼을 제공한다
Electron에는 놓치기 쉬운 또 다른 장점이 있다. 애플리케이션을 만들고 테스트할 때 사용한 Chromium 런타임을 함께 배포한다는 것이다.
이는 크로스 플랫폼 개발에서 큰 변수 하나를 제거한다.
운영체제의 웹뷰를 기반으로 하는 프레임워크는 더 작은 애플리케이션을 만들 수 있지만, 그 대신 동일한 프런트엔드가 Windows에서는 WebView2, macOS에서는 WKWebView, Linux에서는 WebKitGTK에서 실행될 수 있다. 이 엔진들은 기능, 버그, 릴리스 일정, 렌더링 동작이 서로 다르다.
Electron은 다른 절충안을 택한다. 런타임을 함께 묶어 애플리케이션의 일부로 만드는 것이다.
그렇다. 여기에는 디스크 공간이 든다.
하지만 개발자에게 매우 다른 세 운영체제 전반에서 훨씬 더 일관된 실행 환경을 제공한다.
일관성은 개발 측면에서 엄청난 가치가 있다.
Electron만으로 부족할 때는 여전히 네이티브를 사용할 수 있다
Electron을 선택한다고 해서 네이티브 기능에 대한 접근을 포기하는 것은 아니다.
Electron 애플리케이션은 필요할 때 네이티브 모듈과 플랫폼별 코드를 사용할 수 있다. 이는 아키텍처 선택이 사실 다음 둘 중 하나가 아니라는 뜻이다.
100% 네이티브 또는 100% JavaScript.
많은 제품에는 다음과 같은 모델이 더 낫다.
애플리케이션 대부분을 공유하되, 운영체제가 정말로 요구하는 부분에만 소량의 네이티브 코드를 사용한다.
네이티브 코드는 제품 전체의 기반이 아니라 필요할 때 사용할 수 있는 탈출구가 된다.
많은 회사에 이는 개발 노력을 훨씬 더 잘 배분하는 방식이다.
사용자가 신경 쓰는 것은 프레임워크가 아니라 제품이다
활성 상태 보기를 열고, Chromium 프로세스 여러 개를 발견한 뒤, 애플리케이션이 Electron을 사용한다며 곧바로 불평하는 기술에 정통한 사용자가 소수 있다.
대부분의 사용자는 그렇지 않다.
그들은 Slack이 Electron을 사용한다는 사실에 신경 쓰지 않는다. VS Code가 웹 기술로 만들어졌다는 사실에도 신경 쓰지 않는다. Claude가 어떤 프레임워크를 사용하는지도 모른다. 그들이 중요하게 여기는 것은 소프트웨어가 자신의 일을 끝내는 데 도움이 되는지다.
애플리케이션이 충분히 빠르게 실행되고, 반응이 빠르며, 비정상 종료가 드물고, 사용자의 문제를 해결한다면 구현 기술은 사실상 눈에 띄지 않는다.
반대도 마찬가지다. 네이티브 애플리케이션이 Swift나 WinUI를 사용한다고 해서 자동으로 좋은 제품이 되는 것은 아니다.
소프트웨어는 프레임워크 수준이 아니라 제품 수준에서 경쟁한다.
바이너리만이 아니라 회사도 최적화하라
Electron에는 실제 비용이 따른다. 디스크 공간을 더 많이 사용한다. 기본 메모리 사용량도 보통 작은 네이티브 애플리케이션보다 높다. 이런 비용 때문에 Electron이 잘못된 선택이 되는 제품도 분명히 있다.
아주 작은 메뉴 막대 유틸리티에는 아마 Chromium이 필요하지 않을 것이다. 장치 드라이버에는 확실히 필요하지 않다. 게임, 전문 오디오 소프트웨어, 지연 시간에 극도로 민감한 애플리케이션은 요구 사항이 다르다. 그리고 제품이 앞으로도 오직 하나의 운영체제에서만 실행될 예정이라면 네이티브 개발을 선택할 근거가 훨씬 강해진다.
하지만 현대적인 데스크톱 소프트웨어의 상당수는 이런 범주에 속하지 않는다.
이들은 클라우드 서비스에 연결된 복잡한 인터페이스로 이루어져 있다. Windows와 macOS에서 실행되어야 하고, 사용자들은 점점 더 Linux 지원도 기대한다. 지속적으로 발전해야 한다. 매주 변경 사항을 출시하는 제품들과 경쟁한다. 그리고 대개 개발자 수가 한정된 회사가 만든다.
이런 제품에서 개발자 생산성은 애플리케이션 성능의 일부다.
Electron을 사용하면 회사는 훨씬 더 큰 인재 풀에서 채용하고, 웹과 데스크톱 사이에서 개발자를 공유하고, 여러 애플리케이션 대신 하나의 주 애플리케이션을 유지하고, JavaScript 생태계를 재사용하고, 여러 운영체제에 더 일관되게 기능을 출시할 수 있다. 또한 그렇지 않으면 타당성을 설명하기 어려웠을 비용 수준으로 Linux를 지원하고, 병렬로 존재하는 구현들을 유지하는 대신 제품을 개선하는 데 더 많은 개발 시간을 쓸 수 있다.
Electron의 비용은 메가바이트 단위로 쉽게 측정할 수 있다.
다른 선택에 따르는 비용은 눈에 잘 보이지 않는다. 추가 개발자, 중복 구현, 더 긴 릴리스 주기, 플랫폼별 버그, 채용의 어려움, 조직 간 칸막이, 지원받지 못하는 Linux 사용자, 모두에게 제공되기까지 몇 달이 더 걸리는 기능의 형태로 나타난다.
이런 비용은 활성 상태 보기에 나타나지 않는다.
하지만 소프트웨어를 만드는 회사에는 훨씬 더 큰 비용일 수 있다.
소프트웨어 개발의 목표는 가장 작은 바이너리를 만드는 것이 아니다.
조직이 출시하고, 유지 관리하고, 지속적으로 개선할 수 있는 최고의 제품을 만드는 것이다.
놀라울 만큼 폭넓은 데스크톱 애플리케이션에서 Electron은 여전히 바로 그 목표를 달성하는 가장 효율적인 방법 중 하나다.