원문 : https://felixrieseberg.com/things-people-get-wrong-about-electron/

저는 웹 기술과 데스크톱 앱을 더욱 긴밀히 연결하기 위해 수년간 노력했습니다. 이러한 맥락에서 가장 최신이자 성공적인 프로젝트는 제가 지난 10년간 몸담았던 Electron입니다.

오픈소스 프로젝트로서 우리는 사람들이 Electron을 사용하도록 "설득"할 필요가 없었습니다. 그래서 저는 왜 사용자 인터페이스를 구축하는 데 웹 기술에 투자하는지, 또는 왜 렌더링 엔진을 번들링하는 것을 선호하는지에 대해 따로 시간을 들여 설명하지 않았습니다.

Electron의 선택들, 특히 웹 기술로 인터페이스를 구축하는 것과 이를 렌더링하기 위해 크로미움의 상당 부분을 탑재한다는 아이디어는 논란의 여지가 없지 않았습니다. 합리적인 사람들이라면 우리가 왜 그러한 선택을 했는지에 대해 의문을 가질 수 있습니다. 운영체제는 이미 사용자 인터페이스 라이브러리를 갖고 있으니까요. 또한 그 라이브러리에는 일반적으로 Blink(Windows) 또는 Webkit(macOS, 많은 Linux 배포판)을 기반으로 하는 일종의 웹뷰도 있습니다. 그럼에도 왜 크로미움의 일부를 번들링하는 수고를 감수하는 걸까요? 그리고 그러한 수고를 감수하더라도 왜 그렇게 많은 앱(Visual Studio Code, Slack, Discord, Figma, ChatGPT, Claude, Notion, 1Password, Docker Desktop 등)이 이 길을 택할 걸까요?

저는 우리의 선택들에 대한 논거를 설명하기 위해 이제는 시간을 할애해 볼까 합니다. 이와 관련된 문서를 Electron 홈페이지에서도 확인하실 수 있습니다. 이 문서로 흔히 발생하는 오해를 미리 바로잡고자 합니다. 이 글은 해당 문서와 짝을 지어 오늘날 인터넷에서 사람들이 Electron에 대해 가장 잘못 알고 있는 몇 가지 사항을 설명하는 글입니다.

Electron은 자바스크립트와 네이티브 코드를 경쟁시킨다

오해: 자바스크립트가 모든 것에 적합한 선택은 아니다. 네이티브가 더 낫다. Electron은 네이티브가 아니다.

이 오해는 Electron의 메인테이너 팀, 특히 저의 잘못일 가능성이 높습니다. Electron 초창기 제가 했던 대부분의 강연에서 자바스크립트로 운영체제와 상호작용할 수 있는 기능을 강조했습니다.

하지만 Electron의 전체적인 요점은 사용자들이 그들의 웹 앱을 C++, Object-C 또는 Rust와 같은 어떠한 네이티브 코드와도 결합할 수 있다는 것입니다. 몇몇 앱은 네이티브 UI 컴포넌트를 사용하고 싶거나, 프로세스 집약적인 작업을 위임하거나, SQLite와 같은 네이티브 종속성을 사용해야 할 때만 네이티브 코드를 사용합니다. 1Password와 같은 다른 앱들은 대부분의 코드가 Rust로 작성되어 있습니다.

Electron이 하려는 일은 개발자의 믹스 앤 매치를 돕는 것입니다. 주로 OS 네이티브 UI 라이브러리를 사용하는 앱을 개발할 때는 XCode나 Visual Studio를 사용하는 것이 더 재미있고 생산적이지만, Electron의 진정한 강점은 UI를 위한 HTML과 원하는 만큼의 네이티브 코드를 결합할 수 있다는 점입니다.

데모는 긴 단계별 튜토리얼보다 더 따라하기 쉬운 경우가 많기 때문에 Swift, Objective-C, Objective-C++ 및 C++를 사용하여 SwiftUI, GTK 및 Win32로 구현된 간단한 “todo 앱 인터페이스”를 제공하는 예제 리퍼지토리를 생성했습니다.

웹 앱은 별로다

오해: 모든 네이티브 앱은 모든 웹 앱보다 낫다. 어떠한 웹 앱이든 네이티브 앱으로 만드는 것이 더 나을 것이다.

분명 그렇게 느낄 수 있지만, 시장은 이러한 정서를 반영하지 않습니다. 소프트웨어가 세상을 지배했고, 웹이 소프트웨어를 지배했습니다. 별로인 앱들은 정말 별로고 당연히 별로인 웹 앱도 많습니다. 하지만 가장 많이 사용되고, 구입되고, 사랑받는 앱 중에 분명히 웹 앱도 있습니다.

개인적으로 웹 기술은 오늘날 가장 성공적이고 다재다능하며 유능한 UI 스택을 구성하고 있다고 생각합니다. 다음은 제가 작성한 왜 Electron인가 문서에서 직접 발췌한 내용입니다. "NASA의 미션 컨트롤은 실제로 웹 기술로 작성되어 있습니다. 모든 금융 기관에서 볼 수 있는 컴퓨터 시스템인 블룸버그 터미널도 웹 기술로 작성되었고 크로미움 내에서 구동됩니다. 이는 사용자당 연간 25,000달러의 비용이 듭니다. 세계 최대의 식품 소매업체인 맥도날드의 주문 키오스크는 전적으로 크로미움으로 만들어졌습니다. SpaceX의 Dragon 2 space capsule은 인터페이스를 표시하기 위해 크로미움을 사용합니다."

트레이드오프가 없는 것은 없습니다. 웹 기술도 완벽하지 않으며, 운영체제의 네이티브 UI 라이브러리를 사용하여 잘 구축된 네이티브 애플리케이션도 충분히 훌륭할 수 있습니다. 하지만, 웹 앱은 본질적으로 열등하며 네이티브 기술을 배우지 못한 사람들이 작성하는 것이라는 주장은 기껏해야 무식함을 드러낼 뿐이고, 최악의 경우 요구 사항과 제약 조건, 그리고 선택권을 가진 최종 사용자에 대한 공감 부족을 드러내는 것입니다.

운영체제의 웹뷰가 더 성능이 좋다

오해: macOS, Windows, 그리고 대부분의 리눅스 배포판에는 기본적으로 웹뷰가 내장되어 있다. 이러한 웹뷰가 최신 버전의 크로미움보다 더 "낫다".

Slack이 최종적으로 Electron으로 전환하기 전, 데스크톱 앱의 첫번째 버전은 MacGap이라는 프레임워크를 통해 macOS의 빌트인 웹뷰를 사용했습니다. 이는 훌륭해 보였고 실제로도 시대를 앞서 나간 것이었습니다.

이러한 앱은 OS X의 웹뷰에서 실행되며 Webkit 기술의 이점을 활용합니다. MacGap은 네이티브 알림을 표시하거나, 파일에 데이터를 기록하는 등 OS X 통합을 위한 자바스크립트 api를 제공합니다. MacGap은 매우 가볍고 민첩하며, 빈 애플리케이션의 무게는 1MB 미만입니다.

모든 UIWebViews는 단일 프로세스에서 동작하며, Electron과 직접적으로 비교했을 때 CPU와 메모리를 더 적게 사용합니다. 하지만, 실제로 Slack 웹 앱을 실행했을 때, 사용자들은 느린 속도에 불만을 표했습니다. 사용자들이 무엇을 원하든 간에 크롬에서는 더 빠를 것입니다. Apple은 결국 크롬에서 대중화된 유틸리티 프로세스를 공유하는 다중 프로세스 아키텍처로 전환했으며, 이 모든 것이 WKWebView를 통해 이뤄졌습니다. 이 "따라잡기" 게임은 여전히 진행 중이며, 최고의 웹 앱 렌더링 엔진과 런타임은 최고의 브라우저에서 찾을 수 있습니다. 운영체제의 웹뷰가 결국에 크로미움을 따라잡겠지만, 저는 현재까지 웹뷰가 크로미움을 앞선 사례를 보진 못했습니다.

다시 말해, 저는 빌트인 웹뷰가 크로미움보다 성능이 좋다는 걸 증명하는 데이터를 보지 못했습니다. 순진하게도 대부분의 펀딩이 브라우저 최적화에 이뤄지는 한, 운영체제 번들 렌더러가 현존하는 최고의 렌더러 코드를 능가하는 일은 없을 것 같습니다. 상상할 수 없는 일은 아닙니다. Apple, Microsoft 또는 다른 운영체제 제공 기업이 결국에는 크로미움을 능가하는 브라우저 스택을 구축할 수도 있습니다.

이론적으로 운영체제는 웹뷰를 통해 모든 애플리케이션 간에 일부 자원을 공유할 수 있습니다. 실제로는 많은 자원이 주로 보안상의 목적으로 각각의 앱에 엄격하게 격리되어 있습니다. 결론적으로 저는 대화형 앱(Gmail, Notion, Figma, Loom, Slack 등)이 최신 버전의 크로미움보다 빌트인 웹뷰에서 더 나은 성능을 보인다는 벤치마크를 아직 보지 못했습니다.

그러나 많은 Electron 개발자가 번들된 엔진을 선호하는 주된 이유가 성능 때문이 아니라는 것을 알면 놀라실 수도 있습니다. 주된 이유는 개발자가 운영체제와 밀접하게 연결되어 있어서 제어하기 어려운 웹뷰와 독립적으로 애플리케이션의 안정성, 보안 및 신뢰성을 제어할 수 있기 때문입니다.

번들 크기가 중요하다

오해: 최종 사용자들은 200MB 앱보다 5MB인 앱을 더 선호한다.

대부분 Electron 앱의 용량은 100~300MB 정도입니다. 첫 번째 원칙은 작을수록 명백히 더 좋다는 것입니다. 아무도 용량이 큰 앱이 작은 앱보다 더 좋다고 주장할 수 없을 것입니다.

하지만, 소비자와 비즈니스 영역의 사용자 모두는 이를 신경 쓰지 않습니다. 넷플릭스 4K 한 시간의 용량은 대략 7GB이며, Call of Duty의 일반적인 업데이트는 정기적으로 300GB 이상입니다. 실제로 최종 사용자가 엔지니어링팀이 시간을 할애할 수 있는 다른 모든 작업보다 바이너리 크기에 더 관심을 갖는 것을 본 적은 없습니다.

Electron 물리치기

과거에 저는 데스크톱 앱 개발에 열정을 가진 소수의 사람이 자신들이 만들고 싶은 종류의 앱을 만들 수 있도록 하는 프레임워크를 만들어야 한다고 생각했기 때문에 Electron이 존재한다는 글을 작성한 적이 있습니다. 명백히 최종 목표는 프레임워크가 아닌 데스크톱 앱을 제작하는 것이었습니다. 이는 아직도 유효합니다.

Electron은 누구와 경쟁하기 위해 존재하는 것이 아닙니다. Electron은 간극을 메우기 위한 무료 오픈소스 커뮤니티 노력의 산물입니다. 만약 Electron을 물리치고 싶다면 당신이 이 간극을 메워야 할 것입니다. 그리고 오늘날 Electron이 하고 있는 일, 즉 좋은 경험을 제공하는 일에서 지금보다 더 잘해야 할 것입니다. 많은 Electron 메인테이너들은 사용자들이 사랑하는 데스크톱 앱을 만들기 위해 현재 이곳에 있습니다. 만약 당신이 더 나은 플랫폼을 구축하여 메인테이너의 어려운 과제를 해결하도록 돕는다면, 그들은 웃으며 악수를 청하고 고마워할 것입니다.