02 — History & Ecosystem

이 문서가 답하는 질문: “Electron은 어떻게 시작했고, 누가 어떻게 표준으로 만들었으며, 지금 누가 쓰는가? 그리고 Chromium에 매여 있다는 사실이 어떤 운영적 결과를 만드는가?” 한 줄 답 (Pyramid Top): “Electron은 2013년 Atom 에디터의 셸로 태어나 2015년 분리·개명되며 표준화됐고, Microsoft가 같은 해 VS Code를 이 위에 올리면서 ‘데스크톱 웹앱의 사실상 표준’이 됐다. 그 결과 Chromium 업스트림 동기화가 Electron의 보안·수명·정체성을 동시에 결정한다.”

Why — 왜 역사·생태계를 따로 보는가

기술 선택 회의에서 “Electron은 안 죽었나?”라는 질문이 매번 나온다. 답은 살아있다지만, 더 정확히는 Microsoft·Slack·Discord·Figma·Notion이 못 버리는 한 못 죽는다는 것이다. 이 사실을 데이터로 보면 — Electron은 플랫폼 위험이 아니라 Chromium 위험에 더 가깝다는 게 드러난다. Chromium이 깨지면 Electron도 깨지고, Chromium이 보안 패치를 내면 Electron도 N일 안에 내야 한다.

이 챕터는 Atom Shell → Electron → VS Code 시대 → Microsoft 영향 → OpenJS Foundation 이관까지의 흐름을 연표 + 생태계 지도로 정리한다.

How — 어떻게 표준이 됐는가

연표 한 장

1) 2013 — atom-shell의 탄생

Cheng Zhao가 GitHub의 Atom 팀에 합류해 만든 첫 결과물이 atom-shell이다. 당시 비슷한 시도였던 node-webkit(현 NW.js)이 Renderer에 Node를 통째로 노출하는 길을 갔다면, atom-shell은 Main과 Renderer를 분리하고 IPC로 묶는 길을 갔다. 이 분리가 향후 보안 모델의 기초가 된다.

2) 2015 — Electron으로 개명, VS Code 출시

2015년 4월, atom-shell이 Electron으로 개명되며 Atom 의존성에서 분리됐다. 같은 달, Microsoft가 Visual Studio Code를 Electron 위에 출시했다. 이 두 사건이 한 달 안에 일어났다는 게 결정적 — Electron은 시작부터 단일 앱(Atom)에 묶인 게 아니라 여러 거대 앱이 같이 쓰는 런타임으로 자리잡았다.

3) 2016 — Electron 1.0

API 안정성을 약속하는 1.0이 나오면서 enterprise 채택이 폭발한다. 이 시기 Slack·Discord(2016 출시)·WhatsApp Desktop·Skype 데스크톱 재작성 등이 모두 Electron 위로 옮긴다.

4) 2018 — Microsoft의 GitHub 인수

업계 우려는 *“Microsoft가 인수했으니 Atom과 Electron이 정리되지 않을까?”*였다. 답은 반대였다. Microsoft는 이미 Electron의 최대 사용자(VS Code·Teams·Skype·Visual Studio Code Insiders)였고, 못 죽인다. Atom은 2022년에 정리됐지만 Electron은 별개 거버넌스로 남았다.

5) 2019 — OpenJS Foundation 이관

Electron 프로젝트가 OpenJS Foundation(Node·jQuery·webpack 등이 속한 비영리)으로 이관됐다. GitHub/Microsoft 단일 소유에서 다중 이해관계자 모델로 옮겨졌다는 신호. 언어를 만든 회사가 손을 떼는 순간 그 언어가 표준이 된다는 패턴이 여기서도 반복된다 (Node·GraphQL과 같은 길).

6) 2022 이후 — Chromium 6주 주기 동기화

Electron은 Chromium 새 stable의 1주 안을 목표로 메이저 버전을 출시한다. Chromium이 6주마다 새 stable을 내므로 Electron도 사실상 6주 주기. 동시에 Node.js·V8도 같이 따라간다.

→ 같은 시점에 세 개 메이저가 동시에 보안 패치를 받는다. 어떤 메이저를 쓰든 9개월 안에는 다음 메이저로 옮겨야 한다는 압박이 생태계 전반의 공통 운영비용.

What — 누가 쓰고 무엇으로 쓰는가

대표 Electron 앱 (2024 기준)

Electron이 아닌 데스크톱 웹앱들 (비교)

→ Electron의 시장 점유는 데스크톱 웹 기반 앱의 80~90% 수준이라는 게 업계 통념. 정확한 통계는 없지만, 주요 IDE·메신저·디자인 툴·노트 앱에서 Electron이 디폴트.

VS Code가 끌어온 표준 패턴

VS Code 팀은 Electron의 한계에 가장 많이 시달리는 사용자이자 그 한계를 푸는 패턴의 원천이다. 다음 패턴은 거의 모두 VS Code에서 시작해 생태계 전체로 확산했다.

생태계의 핵심 도구

이 도구 분포가 생태계가 살아있다는 가장 강한 신호다 — 한 도구만 살아남으면 fork 위험이 있지만, 둘 이상이 경쟁하면 사용자 선택이 작동한다.

Chromium 동기화의 운영적 의미

브라우저(웹)였다면 Chrome이 자동 업데이트되며 끝났을 사건이, Electron 앱에서는 내 책임이 된다. 사용자가 Electron 28 기반의 우리 앱을 쓰고 있으면, 그 안의 Chromium 120이 Chrome 120 직후의 패치를 받지 않는다 — 내가 사인해서 푸시해야 받는다. 이게 06-packaging-distribution이 별도 챕터인 이유.

What-if — 잘못 쓰면

1) Electron 메이저 업그레이드를 미루면

증상: 1년 묵힌 Electron 26 위에서 Chromium 116의 RCE CVE가 살아있다. 사용자 환경에서 XSS 한 번에 OS 명령 실행 가능. 원인: Electron N-2까지만 보안 패치. 그 이전은 상류 패치 없음. 대응: Electron 업그레이드를 분기 단위 정기 작업으로 둔다. CI에 electron@latest 호환성 시험.

2) “VS Code가 쓰니까 우리도 같은 패턴” 추종

증상: 작은 앱에 Extension Host 분리·V8 snapshot·Shared Process를 다 도입 → 운영 복잡도 폭발. 원인: VS Code의 패턴은 수십 MB 확장이 수백 개 도는 규모에서 필요. 200KB 앱에는 과잉. 대응: 패턴 도입은 *데이터(메모리·시작시간)*가 정당화할 때만.

3) “Atom 에디터가 죽었으니 Electron 도입 보류”

증상: 기술 선택 회의에서 오해된 신호로 Electron 탈락. 원인: Atom과 Electron의 거버넌스 분리를 모름. 대응: OpenJS Foundation 산하 거버넌스·Microsoft VS Code/Teams 의존성·생태계 도구 분포로 살아있음을 데이터로 보인다.

Insight — 흥미로운 이야기

”Cheng Zhao — 한 사람이 시작한 인프라”

atom-shell의 첫 커밋은 Cheng Zhao 한 사람의 결정에서 나왔다. 당시 GitHub은 small team, big tooling의 문화였고, “Atom용 셸을 만들자”는 작은 결정이 십 년 뒤 데스크톱 웹앱의 사실상 표준이 됐다. 한 명의 엔지니어가 시점과 추상 수준을 맞춰 도구를 만들면 어떤 일이 일어나는지의 reference 사례.

”Microsoft의 모순 — 최대 사용자이자 최대 비판자”

Microsoft는 Electron의 최대 사용자(VS Code·Teams·Skype·GitHub Desktop)이자 Electron의 한계에 가장 많이 시달리는 회사다. 2023년 new Teams는 Edge WebView2 위로 재작성됐는데, 이는 Electron이 Chromium을 번들하는 비용을 피하기 위해 OS에 깔린 Edge를 재사용하는 전략. 흥미로운 점은 같은 Microsoft 안에서 VS Code 팀은 여전히 Electron을 쓴다는 것 — 두 길이 공존하는 제국 내부의 트레이드오프 실험.

”Chromium 동기화 — 보안과 수명을 동시에 결정한다”

Electron이 6주마다 새 메이저를 내는 진짜 이유는 마케팅이 아니라 보안이다. Chromium의 V8·Skia·net stack에 발견된 취약점이 바로 Electron 앱에 영향이므로, Electron은 상류 패치를 빠르게 흡수하는 것 외에 선택지가 없다. 이 동기화 압박이 Electron을 살아있는 프로젝트로 유지하는 동시에 사용자 앱의 운영 비용을 매 분기마다 발생시킨다. 공짜 보안은 없다 — Chromium의 보안성을 빌리는 대신 그 패치를 따라가는 책임을 받는다.

”Atom의 죽음이 Electron을 더 자유롭게 만들었다”

Atom 에디터가 2022년에 sunset된 것은 Electron의 죽음이 아니라 Electron의 해방이었다. Atom이 살아 있던 시절 Electron의 API 결정에는 Atom의 사용 사례가 늘 가중치를 가졌다. Atom이 사라지자 Electron 코어 팀은 어떤 단일 앱의 사용 사례에도 매이지 않게 됐고, 공통 인프라로서의 정체성이 더 분명해졌다. 같은 패턴 — Node가 npm Inc.에서 독립한 뒤 더 안정됐다, GraphQL이 Facebook에서 Foundation으로 옮긴 뒤 더 표준이 됐다.

요약

Electron은 2013년 Atom 에디터의 셸로 태어났지만, 진짜 표준화는 Microsoft VS Code의 채택과 OpenJS Foundation 이관에서 일어났다. 그 결과 Electron의 수명은 Chromium 동기화와 Microsoft의 자체 사용에 묶여 있고, 6주 주기의 보안 패치는 생태계 전체의 공통 운영비용이다.

다음 문서: 03-vs-web-vs-native — 웹과 네이티브 사이에서 Electron이 정확히 어느 자리에 있는가.