자체 브라우저를 함께 가져오는 앱
Electron의 핵심 문제는 단순합니다. 모든 앱이 자체 브라우저를 함께 가져온다는 점입니다. Electron은 웹 기술(HTML, CSS, JavaScript)을 시스템 상호작용을 위한 Node.js.js와 함께 번들로 묶고, 이를 전용 Chromium runtime으로 감쌉니다. 이러한 아키텍처 때문에 각 Electron 앱은 운영 체제의 네이티브 브라우저와 무관한 자체 완결형 웹 환경이 됩니다.
이러한 설계는 시스템 리소스에 큰 부담을 줍니다. macOS의 Claude를 예로 들면, 앱 전체 618 MB 중 Electron Framework만 286 MB를 차지합니다. 한 Mac에서는 22개의 Electron 앱이 중복된 Chromium 사본으로만 총 6.5 GB를 차지했습니다. 또한 Chromium 인스턴스마다 메모리가 필요합니다. Claude는 단순히 열려 있기만 한 상태에서도 11개 프로세스에 걸쳐 약 600 MB의 RAM을 사용했습니다.
이 수치는 Better Stack 영상에서 가져온 것으로, 그 부담을 보여 줍니다. 다만 이는 특정 사례일 뿐 보편적인 벤치마크가 아니라는 점에 유의해야 합니다. 앱의 최종 크기와 메모리 사용량은 번들된 도구, 특정 라이브러리, 실제 작업 부하에 따라 크게 달라지지만, 격리된 Chromium 인스턴스라는 근본적인 비효율은 그대로 남아 있습니다.
대안이 공짜 이득이 아닌 이유
Electron 비판론자들은 네이티브 개발을 당연한 대안으로 내세우곤 하지만, 그 길은 늘어나는 작업량으로 가득합니다. 예를 들어 Mac용으로 SwiftUI를 사용해 개발하면 픽셀 단위로 완벽한 경험을 제공할 수 있지만, Windows와 Linux에는 완전히 별도의 구현이 필요해 엔지니어링 및 유지보수 부담이 크게 늘어납니다. 1Password는 Electron으로 통합하기 전에 네 개의 별도 팀이 필요했던 적이 있습니다.
Tauri와 Wails 같은 대안은 macOS의 WebKit, Windows의 WebView2, Linux의 WebKitGTK와 같이 운영 체제에 이미 있는 웹뷰를 활용하고, 네이티브 시스템 상호작용은 Rust 또는 Go가 처리함으로써 Electron의 비대함을 해결합니다. 이 방식은 훨씬 가벼운 앱을 만들어 냅니다. 빈 Tauri 앱은 Mac에서 약 5 MB인 반면, Electron의 일반적인 기본 런타임은 268 MB입니다.
그러나 이러한 효율성에는 호환성이라는 중요한 트레이드오프가 따릅니다. 시스템 웹뷰에 의존하면 앱의 렌더링이 플랫폼마다 달라질 수 있고, 개발자가 통제할 수 없는 OS 수준의 버그나 불일치를 그대로 물려받게 됩니다. 예를 들어 Slack은 처음에 macOS에 내장된 Safari 엔진을 사용했지만, 이전 macOS 버전에서 해결할 수 없는 렌더링 문제를 겪은 뒤 Electron으로 전환했습니다.
결국 더 가벼운 대안이라는 "공짜 이득"처럼 보이는 것은 일관성과 통제권을 대가로 얻는 것입니다. Tauri와 Wails는 인상적인 크기 감소를 제공하지만, Electron이 극복하려고 설계된 바로 그 파편화를 다시 불러와 개발자가 성능과 예측 가능한 사용자 경험 사이에서 균형을 잡도록 만듭니다.
대규모에서는 우아함보다 일관성이 앞섭니다
Electron의 진정한 강점이자 가장 짜증스러운 결점은 자체 완결적인 특성에 있습니다. 네이티브 앱은 macOS의 Safari 엔진이나 Windows의 Edge처럼 예측하기 어려운 시스템 웹뷰에 의존하는 반면, Electron은 자체 Chromium runtime을 함께 포함합니다. 이를 통해 Windows, macOS, Linux 전반에서 일관된 렌더링 환경이 보장되며, 개발자는 플랫폼별 예기치 못한 문제를 겪지 않아도 됩니다.
그러나 이러한 통제권에는 대가가 따릅니다. Slack이 처음에 macOS에 내장된 Safari 엔진을 사용했을 때, Safari 버그가 있는 이전 OS 버전에서는 손쓸 방법이 없었습니다. Electron으로 전환하면서 통합된 코드베이스와 직접 수정 사항을 배포할 수 있는 자율성을 얻었습니다. 이러한 트레이드오프 때문에 Tauri와 같은 더 새로운 프레임워크조차 Chromium 번들링을 고려하고 있으며, 이는 Electron의 핵심 강점을 인정하는 것입니다. 자세한 기능은 Electron: Build Cross-Platform Desktop Apps에서 확인하세요.
하지만 이러한 자율성은 광범위한 업데이트 문제를 낳습니다. 모든 Electron 앱이 자체 Chromium 사본을 가지고 있으므로, Electron이나 Chromium 자체에 대한 수정 사항은 각 앱 공급업체가 업데이트를 배포한 후에야 사용자에게 도달합니다. 예를 들어 작년 macOS 업데이트 이후, Electron 버그가 Apple의 비공개 UI 코드를 덮어쓰면서 Electron 앱에서 시스템 전반의 지연이 발생했습니다. 이 수정은 영향을 받은 모든 앱을 통해 개별적으로 전파되어야 했으며, 이는 이러한 분산형 업데이트 모델의 극심한 비효율성을 보여 줍니다. 우아함보다 일관성을 택한 이 접근 방식은 개발을 단순화하지만 사용자 경험을 파편화합니다.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
AI 앱에서는 하나의 코드베이스가 세 개보다 나을 수 있습니다
빠르게 변화하는 AI 제품에서 Electron의 매력은 부인할 수 없습니다. 웹과 데스크톱 간에 코드를 공유하면 팀이 중복 작업을 줄이면서 Mac, Windows, Linux 전반에 기능을 적용할 수 있어 Anthropic의 Claude와 OpenAI의 Codex 같은 제품의 개발이 간소화됩니다. 이는 엔지니어링상의 트레이드오프일 뿐, Electron에 대한 보편적인 지지를 뜻하는 것은 아닙니다.
예를 들어 OpenAI는 네이티브 ChatGPT Mac 앱을 Electron 기반 Codex 클라이언트로 교체했습니다. 기존 네이티브 앱은 159 MB였지만 새 Electron 버전은 1.7 GB로 커졌으며, 그중 상당 부분은 Codex 도구를 포함하고 있습니다. 이는 통합 코드베이스가 요구하는 리소스 비용을 보여 줍니다.
고급 AI 코딩 도구를 사용하더라도 네이티브 클라이언트의 부담이 사라지지는 않습니다. 코딩 에이전트는 초기 구현을 생성하는 데는 뛰어나지만, 여러 플랫폼별 앱을 테스트하고 수정하고 지원하는 일은 여전히 큰 과제이며 버그 수와 유지보수 작업을 배가시킵니다. Claude Code의 한 개발자는 \"앱이 세 개면 수정하고 지원해야 할 버그도 세 배입니다\"라고 말했습니다.
실용적인 경험 법칙은 여전히 유효합니다. 크기가 중요한 소규모 유틸리티에는 macOS에서 5 MB 정도로 작은 앱을 만들 수 있는 Tauri나 Wails를 고려하세요. 일관된 동작과 Mac, Windows, Linux 전반의 빠른 릴리스를 우선시하는 복잡한 크로스 플랫폼 제품에는 Electron이 여전히 더 안전하고 예측 가능한 선택입니다.
자주 묻는 질문
Electron 앱은 왜 메모리를 그렇게 많이 사용하나요?
각 Electron 앱은 Chromium을 함께 포함하고 자체 프로세스를 실행하므로, 앱이 유휴 상태일 때도 오버헤드가 발생합니다.
기업들은 왜 여전히 Electron을 선택하나요?
일관된 Chromium 환경을 제공하며, 팀이 Mac, Windows, Linux 그리고 흔히 웹 전반에서 코드를 공유할 수 있게 해 줍니다.
Tauri는 항상 Electron보다 작은가요?
Tauri는 보통 운영 체제의 웹뷰를 사용하기 때문에 앱 번들이 훨씬 작을 수 있지만, 렌더링은 플랫폼에 따라 달라질 수 있습니다.
팀은 언제 네이티브 개발을 선택해야 하나요?
플랫폼별 성능과 사용자 경험이 별도 구현을 유지할 만한 가치가 있을 때 네이티브는 적합한 선택이 될 수 있습니다.