2021년, 1Password가 네이티브를 버렸다
1Password 8이 2021년에 베타로 공개됐을 때, 1Password 커뮤니티 포럼과 Hacker News는 폭발했다. 이유는 하나였다. 10년 넘게 "Mac에서 가장 잘 만들어진 네이티브 앱 중 하나"로 꼽히던 1Password가 Electron으로 다시 쓰여서 나왔다는 것.
사용자 반응은 격렬했다. AppleInsider는 "유저들이 1Password에 Electron 버전을 포기하라고 로비하고 있다"는 기사를 냈다. Six Colors의 Jason Snell은 "충분히 중요하지 않았다: 1Password가 네이티브 Mac 앱을 포기하다"라는 제목의 글을 올렸다. 1Password 공식 포럼에는 "10년 썼는데 이번에 옮긴다"는 이탈 선언이 쌓였다.
그리고 5년이 지났다. 2026년 4월 현재, 1Password는 여전히 Electron이다. 그사이 회사는 엔터프라이즈 시장으로 전환해 ARR이 두 배 가까이 늘었고(2024년 약 $331M에서 2025년 10월 $400M 돌파), 네이티브로 돌아가자는 운동은 포럼 아카이브에 묻혔다. 매출이 Electron 덕분에 늘었다는 얘기는 아니다. 다만 Electron으로 옮긴 결정이 사업의 장애물이 되지 않았다 는 점은 분명하다.
이건 Electron 논쟁의 축소판이다. 비판은 있었고, 결국 아무 일도 일어나지 않았다.
Electron이 이미 집어삼킨 목록
데스크톱 앱 시장에서 많이 쓰이는 생산성 도구를 세어보자.
VSCode (2015년 공개), Slack, Discord, Notion, Obsidian, Postman, GitHub Desktop. 거의 전부 Electron이다. Figma Desktop은 Electron 껍데기에 자체 C++ 캔버스 엔진을 WebGL과 WASM으로 얹은 하이브리드이고, 나머지는 순수한 Electron이다. 1Password처럼 네이티브에서 옮겨온 예외도 있지만, 대부분은 처음부터 Electron이었다. 이 차이가 핵심이다.
예외가 하나 있다. Microsoft Teams는 2023년에 Electron을 떠났다. 이 이탈은 테제의 반례처럼 보이지만 뒤에서 다시 본다.
처음부터 Electron이었던 앱의 사용자는 "이게 Electron이다"라는 사실 자체를 인지하지 못한다. Slack을 쓰는 영업팀은 자기 Slack이 Chromium 한 벌을 메모리에 올리고 있다는 걸 모른다. 그냥 "Slack이 좀 무거운 앱"이라고 생각할 뿐이다. Discord 사용자도 마찬가지다. 게이머들은 "Discord가 RAM을 먹는다"고 말하지만, 그걸 "그러니까 Electron 대안이 필요하다"로 번역하는 사람은 거의 없다.
반면 1Password처럼 네이티브에서 Electron으로 옮겨간 앱의 유저는 비교 대상을 가지고 있다. "예전 1Password는 이렇지 않았다"고 말할 수 있다. 그래서 분노가 생긴다.
비판은 기준선이 있을 때만 발생한다. 기준선이 없으면, 앱은 그냥 앱이다.
Hacker News에만 사는 문제
"Electron 앱은 무겁다"는 문장이 일상 대화에서 나오는 경우를 떠올려보자. 거의 없다. 이 문장은 Hacker News 댓글, 기술 블로그, X의 개발자 계정에 주로 산다.
물론 완전히 비가시적인 문제는 아니다. Mac 사용자는 배터리 상태를 볼 때 Slack이나 Discord가 "에너지 영향: 높음"으로 뜨는 걸 알아챈다. Windows 작업 관리자에서 Teams가 메모리를 먹는 것도 보인다. 그래서 배터리와 발열은 사용자에게도 만져지는 문제다.
그런데 여기서 중요한 비약이 있다. 사용자가 "내 노트북이 뜨겁다"에서 "이건 Electron 때문이다, Tauri 기반 대체재를 찾아서 설치하자"로 이어지는 경우는 거의 없다. 원인이 Electron 번들인지, Chrome 탭 40개인지, 백그라운드의 Spotify 때문인지는 대부분 구분되지 않는다. 문제는 감지되지만 귀속되지 않는다. 그리고 귀속되지 않는 문제는 구매 결정을 바꾸지 않는다.
개발자는 번들 120MB와 메모리 300MB를 수치로 센다. 사용자는 "앱이 열리는가, 빠른가, 원하는 일이 되는가"만 센다. 이 둘 사이에 몇 층의 추상이 있다. 그래서 Electron 대안 프로젝트들은 수치 단위에서 이기지만, 의사결정 단위에서는 싸우지 않는다. Tauri가 번들을 10MB 아래로 줄여도, 그 차이가 사용자의 제품 선택에 반영되는 경로는 너무 길다.
Tauri가 자처한 함정
Tauri의 기술적 접근은 깔끔하다. Chromium 번들 대신 OS가 제공하는 시스템 WebView를 쓴다. Windows에선 WebView2, macOS에선 WKWebView, Linux에선 WebKitGTK. 번들은 10MB 아래, 메모리는 30-50MB 수준이 된다. 숫자만 보면 압승이다.
그런데 이 접근에는 숨겨진 비용이 있다. 웹 엔진이 세 갈래로 쪼개진다. WebView2는 Chromium이지만, WKWebView와 WebKitGTK는 Safari 계보의 WebKit이다. 같은 WebKit이라도 macOS의 WKWebView와 Linux의 WebKitGTK는 버전, 렌더링 세부, 지원하는 최신 API가 다르게 관리된다.
그래서 Tauri 앱을 만든다는 건 웹 엔진 세 개에 대해 따로 테스트한다는 뜻이다. CSS Grid의 특정 기능이 macOS에선 되는데 Linux에선 깨지거나, 최신 CSS 속성이 WebKitGTK에선 지원되지 않거나, 폰트 렌더링이 플랫폼마다 미묘하게 다르거나. Tauri 개발자 대부분이 한 번은 겪는 일이다.
Electron은 이 문제를 한 방에 치웠다. Chromium을 번들한다. 어디서 실행되든 같은 엔진, 같은 렌더링, 같은 동작. 번들이 150MB인 대신 테스트 매트릭스가 하나다.
"번들 크기 100MB 감소"의 대가가 "테스트 매트릭스 3배"다. 이 교환을 받아들일 팀은 많지 않다.
Chromium 독점이 Electron을 지킨다
더 구조적으로 보면 이 상황은 Chromium 독점의 부산물이다.
오늘날 웹에서 "작동한다"의 암묵적 기준은 Chromium이다. Edge는 Chromium이고, Brave는 Chromium이고, Opera도 Chromium이다. Safari는 남아있지만 점유율이 작고, Firefox는 데스크톱에서 3% 전후에 머문다. 웹 개발자가 "이 사이트는 작동한다"고 말할 때 암묵적으로 테스트한 엔진은 거의 언제나 Chromium이다.
이 세계에서 Chromium을 번들하는 것은 가장 안전한 선택 이다. 앱이 Chromium에서 작동한다면 그게 최종이다. 다른 엔진에서 돌아가는지 확인할 필요가 없다. WebView2, WKWebView, WebKitGTK의 미묘한 차이를 추적할 필요가 없다.
Tauri 같은 대안은 정확히 반대 방향을 주장한다. "OS WebView를 쓰자, 그게 더 효율적이다." 원리적으로는 맞다. 그런데 Chromium 독점이 공고한 세계에서 OS WebView를 쓰는 팀은 시장 표준이 아닌 엔진들에 대한 호환성 부담을 혼자 떠안는다.
독점은 독점에 반대하는 도구를 쓰는 비용을 올린다. Chromium이 없었다면 Tauri의 접근이 훨씬 쉬웠을 것이다. Chromium이 있는 세계에서 Tauri는 "의도는 맞지만 비용이 비싼" 선택이 된다.
Teams 이탈이 규칙을 확증한다
이제 앞에서 미뤘던 Microsoft Teams 이야기를 하자. 2023년, Microsoft는 새 Teams 클라이언트를 공개하면서 Electron을 떠났다. 그 자리를 WebView2가 차지했다. Windows뿐 아니라 Mac 버전도 WebView2로 갈아탔고, 구 Electron 기반 "Classic Teams"는 2025년 7월 1일에 공식 단종됐다. Microsoft의 발표 수치는 "메모리 사용량 절반, 로딩 두 배 빠름" 이었다.
수억 명이 쓰는 앱이 Electron을 떠났다. 이건 "Electron 대안이 진다"는 테제에 대한 정면 반례로 보인다. 그런데 자세히 보면 반대다.
Teams가 떠날 수 있었던 유일한 이유는 Microsoft가 WebView2를 소유하기 때문 이다. WebView2는 Microsoft Edge 기반이고, Windows 11에 기본 탑재되며, 유지보수와 업데이트 주기를 Microsoft가 통제한다. Mac 버전의 WebView2도 Microsoft가 Edge를 포팅하면서 만든 부산물이다. 즉 Teams는 Electron을 떠나 "남의 Chromium 번들"에서 "우리 Chromium 번들"로 이사한 것이다. 번들된 웹 런타임을 포기한 게 아니다. 소유한 런타임으로 갈아탄 것이다.
Slack이 같은 이동을 할 수 있을까. 못 한다. Slack에게 WebView2는 Electron과 마찬가지로 "남의 번들"인데, 크기 이점이 충분히 크지도 않고, 플랫폼 간 일관성 이점도 Electron보다 떨어진다. Discord도, Notion도, Linear도 같은 벽 앞에 있다. 이들이 WebView2로 옮기는 건 아무 이득이 없다.
지난 10년간 Electron을 떠난 거대 앱의 예외는 Microsoft 제품 계열이 사실상 전부다. 이건 규칙의 반례가 아니라 규칙의 조건을 드러내는 사례 다. 번들된 웹 런타임의 세계에서 독립은 브라우저 엔진 보유자에게만 허용된다. Microsoft는 그걸 가졌기 때문에 움직일 수 있었다. 다른 회사들은 못 가졌기 때문에 못 움직인다.
Linear의 자기 모순
여기서 Linear 이야기가 의미심장해진다.
Linear는 craft와 네이티브 감수성을 공격적으로 강조하는 회사다. UI는 macOS 디자인 언어를 노골적으로 차용하고, 디자이너 출신 CEO Karri Saarinen은 "제품은 세부 사항에서 완성된다"는 철학을 공개적으로 말한다. 그런 Linear의 데스크톱 앱도 Electron이다.
그리고 그게 맞다. Linear 정도 규모의 회사가 네이티브 macOS 앱과 네이티브 Windows 앱을 따로 만드는 건 경제적으로 성립하지 않는다. 웹 팀의 React 코드베이스를 그대로 데스크톱에 가져오는 게 훨씬 싸고, 버그 수정이 한 곳에서 일어나고, 기능 개발이 세 배 빠르다.
"Electron은 별로다"라는 감수성과 "그런데 우리 제품은 Electron이다"라는 현실 사이에 모순이 있다. 이 모순은 Linear만의 것이 아니다. Electron을 공개적으로 비판하는 엔지니어 대다수가 쓰는 에디터는 VSCode다. 메시지는 Slack으로 보낸다. 디자인은 Figma Desktop으로 한다.
비판은 담론 층위에 있고, 실행은 구조 층위에 있다. 둘은 만나지 않는다.
대안이 없다는 말의 의미
10년 동안 "Electron 대안"이라 불린 프로젝트를 세어보자. NW.js, Tauri, Wails, Neutralino, Proton Native, Revery, Sciter. 이름만 알려진 더 작은 것들까지 합하면 더 많다. 그중 어느 것도 "Electron을 대체했다"고 말할 규모에 도달하지 못했다.
이건 기술적 실패가 아니다. Tauri는 잘 만들어진 도구다. Rust 코어는 견고하고, API는 정돈돼 있고, 문서는 꼼꼼하다. 그런데 Electron을 못 이긴다. 이유는 단순하다.
Electron은 푼 문제가 있다. "웹 팀으로 데스크톱 앱을 만들고 싶다." 이 문제를 Electron이 풀었고, 지금도 가장 저렴하게 풀고 있다.
Tauri가 풀려는 문제는 다르다. "데스크톱 앱의 번들과 메모리를 줄이고 싶다." 이 문제는 사용자가 가지고 있지 않다. 개발자가 가지고 있다. 그리고 개발자는 제품 선택을 하지 않는다. 회사가 한다. 회사는 "웹 팀으로 데스크톱 앱을 만들고 싶다"의 답을 산다.
문제가 서로 다르다. 같은 카테고리 안의 경쟁처럼 보이지만, 실제로는 다른 고객을 보고 있다.
Electron은 이기지 않았다
결론을 다시 쓰자. Electron은 경쟁에서 이긴 게 아니다. 경쟁자들이 풀려던 문제가 사용자의 문제가 아니었을 뿐이다.
"데스크톱 앱은 가벼워야 한다"고 말할 때, 그 주어는 항상 개발자다. 사용자는 그 주장에 가담하지 않는다. Electron 비판의 청중은 결국 다른 개발자다. 그리고 그 개발자들은 Electron을 비판하면서 Electron으로 제품을 출시한다.
우리가 이기려던 건 대체로 우리 자신의 전문가적 불편이었다. 그 불편은 10년이 지나도 Hacker News 댓글로 남고, 그동안 Electron은 1Password를 집어삼키고, Figma를 집어삼키고, Notion과 Slack과 Discord와 VSCode의 기본값이 됐다. 떠난 예외는 WebView2를 소유한 Microsoft 제품 한 줄기뿐이다.
대안이 없는 게 아니다. 대안을 원할 사용자가 없었던 것이다.