@electron packages on npm will require Node.js 22 LTS. Read more on our blog.Important announcements about the Electron project
View All Tags
Electron 프로젝트는 2024년 12월 한 달 동안 휴식기를 갖고, 2025년 1월부터 다시 본격적으로 진행될 예정이다.
2025년에 뵙겠습니다!
Electron 프로젝트는 2023년 12월 한 달 동안 잠시 중단될 예정이며, 2024년 1월에 다시 본격적으로 진행될 예정이다.
조용한 기간 실험을 진행한 지 이제 3년 차가 되었다. 지금까지 한 달간의 휴식과 그 후 정상적인 릴리즈 주기를 유지하는 데 있어서 많은 성과를 거두었다. 따라서 이제 이 실험을 정규 릴리즈 캘린더의 일부로 정기화하기로 결정했다. 매년 마지막 안정 버전 릴리즈 시에 여전히 알림을 추가할 예정이다.
2024년에 다시 만나자!
electron/electron 저장소에 첫 커밋이 이루어진 날은 2013년 3월 13일이었다1.
10년이 지나고, 1192명의 기여자가 27,147개의 커밋을 추가한 후, Electron은 현재 데스크톱 애플리케이션을 구축하는 가장 인기 있는 프레임워크 중 하나가 되었다. 이번 마일스톤은 지금까지의 여정을 돌아보고, 그동안 배운 것을 공유하며 축하할 수 있는 완벽한 기회다.
프로젝트에 시간과 노력을 기울여 기여한 모든 사람들이 없었다면 오늘의 Electron은 존재할 수 없었다. 소스 코드 커밋이 항상 가장 눈에 띄는 기여이지만, 버그를 보고하고, 사용자 모듈을 유지보수하며, 문서와 번역을 제공하고, 온라인 공간에서 Electron 커뮤니티에 참여한 사람들의 노력도 인정해야 한다. 모든 기여는 유지보수자로서 우리에게 귀중하다.
이 글을 계속하기 전에: 감사합니다. ❤️
Atom Shell은 GitHub의 Atom 에디터를 위한 핵심 기술로 개발되었다. 2014년 4월 공개 베타로 출시된 Atom 에디터는 당시 웹 기반 데스크톱 프레임워크(node-webkit과 Chromium Embedded Framework)의 대안으로 처음부터 새롭게 구축되었다. Atom Shell의 주요 특징은 Node.js와 Chromium을 내장해 웹 기술을 위한 강력한 데스크톱 런타임을 제공하는 것이었다.
출시 후 1년도 채 되지 않아 Atom Shell은 기능과 인기 면에서 급격한 성장을 이루었다. 대기업, 스타트업, 개인 개발자들이 모두 이 플랫폼을 사용해 앱을 개발하기 시작했고, Slack, GitKraken, WebTorrent 등이 초기 사용자로 포함되었다. 이 프로젝트는 Electron이라는 이름으로 재탄생했다.
그 이후로 Electron은 빠르게 성장하며 멈추지 않았다. npmtrends.com의 데이터를 통해 시간에 따른 주간 다운로드 수를 살펴보면 다음과 같다:
Electron v1은 2016년에 출시되었으며, API 안정성 강화와 더 나은 문서 및 도구 제공을 약속했다. Electron v2는 2018년에 출시되며 시맨틱 버저닝을 도입해 개발자들이 릴리스 주기를 더 쉽게 추적할 수 있게 했다.
Electron v6부터는 Chromium의 릴리스 주기에 맞춰 12주 단위의 정기적인 메이저 릴리스 주기로 전환했다. 이 결정은 프로젝트의 사고방식 변화를 의미했으며, "최신 Chromium 버전 유지"를 선택 사항에서 우선순위로 끌어올렸다. 이를 통해 업그레이드 간 기술 부채를 줄이고, Electron을 최신 상태로 유지하며 보안을 강화하는 것이 더 쉬워졌다.
그 이후로 Electron은 잘 정비된 기계처럼 작동하며, Chromium 안정 버전이 출시되는 날마다 새로운 Electron 버전을 릴리스했다. 2021년 Chromium이 릴리스 주기를 4주로 단축했을 때, Electron도 어깨를 으쓱하며 릴리스 주기를 8주로 조정할 수 있었다.
현재 Electron v23(그 이상)까지 출시되었으며, 여전히 크로스 플랫폼 데스크톱 애플리케이션을 구축하기 위한 최고의 런타임을 만들기 위해 노력하고 있다. 최근 몇 년간 JavaScript 개발자 도구가 급격히 증가했음에도 불구하고, Electron은 데스크톱 앱 프레임워크 분야에서 안정적이고 검증된 강자로 자리 잡았다. 이제 Electron 앱은 어디서나 찾아볼 수 있다: Visual Studio Code로 프로그래밍하고, Figma로 디자인하고, Slack으로 소통하고, Notion으로 메모를 작성하는 등 다양한 용도로 활용된다. 이 성과를 이루기 위해 노력한 모든 이들에게 깊은 감사를 표한다.
10년이라는 시간 동안 우리는 길고도 복잡한 여정을 걸어왔다. 이 과정에서 대규모 오픈소스 프로젝트를 지속 가능하게 운영하는 데 도움이 된 몇 가지 핵심 요소를 정리해본다.
Electron이 처음으로 인기를 끌기 시작했을 때, 우리가 극복해야 했던 과제 중 하나는 프로젝트의 장기적인 방향성을 어떻게 관리할지였다. 여러 회사와 국가, 시간대에 걸쳐 분산된 수십 명의 엔지니어로 구성된 팀을 어떻게 효율적으로 운영할 수 있을까?
초기에는 Electron의 메인테이너 그룹이 비공식적인 협업 방식을 사용했다. 이 방식은 작은 규모의 프로젝트에서는 빠르고 가볍게 동작하지만, 더 넓은 협업으로 확장하기에는 한계가 있었다. 2019년, 우리는 공식적인 책임 영역을 가진 다양한 작업 그룹(Working Group, WG)으로 구성된 거버넌스 모델로 전환했다. 이 모델은 프로세스를 간소화하고 프로젝트 소유권의 일부를 특정 메인테이너에게 할당하는 데 중요한 역할을 했다. 현재 각 작업 그룹의 책임은 다음과 같다:
우리가 거버넌스 모델로 전환한 시기와 거의 동시에, Electron의 소유권도 GitHub에서 OpenJS Foundation으로 이전했다. 원래의 코어 팀은 여전히 Microsoft에서 근무하고 있지만, 이제는 Electron 거버넌스를 구성하는 더 큰 협력자 그룹의 일부일 뿐이다.2
이 모델이 완벽하지는 않지만, 전 세계적인 팬데믹과 지속적인 거시경제적 어려움 속에서도 우리에게 잘 맞아왔다. 앞으로 우리는 Electron의 두 번째 10년을 이끌어갈 수 있도록 거버넌스 헌장을 개선할 계획이다.
더 자세한 내용을 알고 싶다면 electron/governance 저장소를 확인해 보자!
오픈소스의 커뮤니티 부분은 쉽지 않다. 특히 아웃리치 팀이 '커뮤니티 매니저'라는 이름의 트렌치코트를 입은 소수의 엔지니어들로 구성되어 있을 때는 더욱 그렇다. 하지만 대규모 오픈소스 프로젝트로서 우리는 많은 사용자를 보유하고 있으며, 이들의 에너지를 활용해 Electron을 위한 사용자 중심의 생태계를 구축하는 것은 프로젝트의 건강을 유지하는 데 중요한 부분이다.
그렇다면 우리는 커뮤니티 존재감을 강화하기 위해 어떤 노력을 기울이고 있을까?
우리는 2019년부터 매년 Hacktoberfest를 기념해 왔다. Hacktoberfest는 DigitalOcean이 주관하는 오픈소스 연례 행사로, 매년 수십 명의 열정적인 기여자들이 오픈소스 소프트웨어에 자신의 흔적을 남기기 위해 참여한다.
2020년에는 Google Season of Docs의 첫 번째 버전에 참여했으며, @bandantonio와 함께 Electron의 신규 사용자 튜토리얼 흐름을 개선하는 작업을 진행했다.
2022년에는 처음으로 Google Summer of Code 학생을 멘토링했다. @aryanshridhar는 Electron Fiddle의 핵심 버전 로딩 로직을 리팩토링하고, 번들러를 webpack로 마이그레이션하는 훌륭한 작업을 수행했다.
현재 Electron 프로젝트에는 약 30명의 활발한 메인테이너가 있다. 이 중 절반 미만이 풀타임 기여자이기 때문에, 처리해야 할 작업이 상당히 많다. 모든 것이 원활하게 돌아가도록 유지하는 비결은 무엇일까? 우리의 모토는 "컴퓨터는 저렴하지만, 인간의 시간은 비싸다"이다. 전형적인 엔지니어의 방식대로, 우리는 작업을 더 쉽게 하기 위해 다양한 자동화 지원 도구를 개발했다.
Electron의 핵심 코드베이스는 C++로 이루어진 거대한 규모를 자랑하며, 빌드 시간은 버그 수정과 새로운 기능을 빠르게 배포하는 데 항상 걸림돌이었다. 2020년, 우리는 Google의 분산 컴파일러 서비스인 Goma을 위한 커스텀 백엔드인 Not Goma을 배포했다. Not Goma는 인증된 사용자의 머신에서 컴파일 요청을 처리하고, 이를 백엔드의 수백 개의 코어에 분산시킨다. 또한 컴파일 결과를 캐싱하여 동일한 파일을 컴파일하는 다른 사용자가 미리 컴파일된 결과만 다운로드하면 되도록 한다.
Not Goma를 도입한 이후, 메인테이너들의 컴파일 시간은 몇 시간에서 몇 분으로 크게 단축되었다. 이제는 안정적인 인터넷 연결만 있으면 누구나 Electron을 컴파일할 수 있게 되었다!
오픈소스 기여자라면 Electron Build Tools를 통해 기본적으로 제공되는 Not Goma의 읽기 전용 캐시를 사용해 볼 수 있다.
지속적 인증(CFA)은 npm의 2단계 인증(2FA) 시스템을 자동화한 레이어로, semantic-release와 결합하여 다양한 @electron/ npm 패키지의 안전하고 자동화된 릴리즈를 관리한다.
semantic-release는 이미 npm 패키지 배포 과정을 자동화하지만, 2단계 인증을 비활성화하거나 이 제한을 우회하는 비밀 토큰을 전달해야 한다.
CFA는 npm 2FA를 위한 시간 기반 일회용 비밀번호(TOTP)를 임의의 CI 작업에 제공하도록 설계되었다. 이를 통해 semantic-release의 자동화 기능을 활용하면서도 2단계 인증의 추가 보안을 유지할 수 있다.
CFA는 Slack 통합 프론트엔드와 함께 사용되며, 유지 관리자는 TOTP 생성기가 있는 한 Slack이 설치된 모든 기기에서 패키지 배포를 검증할 수 있다.
CFA를 직접 프로젝트에서 사용해보고 싶다면, GitHub 저장소나 문서를 확인해보자. CircleCI를 CI 프로바이더로 사용한다면, CFA를 빠르게 설정할 수 있는 편리한 orb도 제공한다.
Sheriff는 GitHub, Slack, Google Workspace의 권한 관리를 자동화하기 위해 개발한 오픈소스 도구다.
Sheriff의 핵심 가치는 권한 관리를 투명한 프로세스로 만드는 데 있다. 이 도구는 단일 YAML 설정 파일을 사용해 위에 언급한 모든 서비스의 권한을 지정한다. Sheriff를 사용하면 리포지토리에 협력자로 추가되거나 새로운 메일링 리스트를 만드는 작업이 PR을 승인하고 병합하는 것만큼 간단해진다.
또한 Sheriff는 Slack에 감사 로그를 전송해 Electron 조직 내에서 의심스러운 활동이 발생할 때 관리자에게 경고를 보낸다.
GitHub는 풍부한 API 확장성을 제공하며, 공식적인 봇 애플리케이션 프레임워크인 Probot을 지원한다. 우리가 더 창의적인 업무에 집중할 수 있도록, 다양한 작은 봇들을 개발해 반복적인 작업을 자동화했다. 몇 가지 예를 살펴보자:
이러한 봇들은 개발자 생산성을 크게 향상시켰다. 작은 봇들이 모여 큰 효율을 만들어낸 셈이다.
Electron 프로젝트가 두 번째 10년을 맞이한 지금, 여러분은 Electron의 미래가 어떻게 펼쳐질지 궁금할 것이다.
우리는 Chromium의 릴리스 주기에 맞춰 Electron의 새로운 주요 버전을 8주마다 출시할 계획이다. 이를 통해 웹 플랫폼과 Node.js의 최신 기술을 Electron 프레임워크에 반영하면서도, 엔터프라이즈급 애플리케이션에 필요한 안정성과 보안을 유지할 것이다.
구체적인 계획이 확정되면, 우리는 이를 공식적으로 발표할 예정이다. 앞으로의 릴리스, 새로운 기능, 그리고 프로젝트 업데이트에 대한 최신 정보를 받아보고 싶다면 Electron 블로그를 읽거나, 소셜 미디어 프로필(Twitter 및 Mastodon)을 팔로우하면 된다.
이는 사실 electron-archive/brightray 프로젝트의 첫 번째 커밋이다. 이 프로젝트는 2017년 Electron에 통합되었고, Git 기록도 병합되었다. 하지만 누가 숫자를 세겠는가? 오늘은 우리의 생일이니, 우리만의 규칙을 만들겠다! ↩
흔히 알려진 것과 달리, Electron은 더 이상 GitHub이나 Microsoft 소유가 아니며, 현재는 OpenJS Foundation의 일부이다. ↩
Electron은 Electron 23부터 Windows 7, Windows 8, Windows 8.1에 대한 지원을 중단한다.
Chromium의 지원 중단 정책에 따라, Electron은 Electron 23부터 Windows 7, Windows 8, Windows 8.1에 대한 지원을 종료한다. 이는 Microsoft가 Windows 7 ESU와 Windows 8.1 extended에 대한 지원을 2023년 1월 10일에 종료한 것과 일치한다.
Electron 22는 Windows 10 이전 버전을 지원하는 마지막 주요 버전이 된다. Electron 23 및 이후 주요 버전에서는 Windows 7/8/8.1을 더 이상 지원하지 않는다. 이전 버전의 Electron은 Windows 7에서 계속 작동하며, 2023년 5월 30일까지 Electron 22.x 시리즈에 대한 패치를 계속 제공할 예정이다. 이 날짜는 지원 타임라인에 따라 Electron이 22.x에 대한 지원을 종료하는 시점이다.
Electron은 Chromium의 지원 중단 정책을 따르며, Chromium 109부터 지원이 중단된다. Chromium 110을 포함하는 Electron 23은 이전 버전의 Windows를 더 이상 지원하지 않는다.
Chromium 108을 포함하는 Electron 22는 따라서 마지막 지원 버전이 된다.
다음은 계획된 지원 중단 일정이다:
이것이 개발자에게 의미하는 바는 다음과 같다:
2023/02/16: Windows Server 2012 지원 업데이트
지난달, Google은 Chrome 109이 Windows Server 2012 및 Windows Server 2012 R2에 대한 중요한 보안 수정 사항을 2023년 10월 10일까지 계속 제공할 것이라고 발표했다. 이에 따라 Electron 22(Chromium 108)의 지원 종료 예정일은 2023년 5월 30일에서 2023년 10월 10일로 연장된다. Electron 팀은 2023년 10월 10일까지 이 프로그램의 일부인 보안 수정 사항을 Electron 22에 백포트할 계획이다.
단, Windows 7/8/8.1에 대한 추가 보안 수정 사항은 제공하지 않는다. 또한, 이전에 발표한 대로 Electron 23(Chromium 110)은 Windows 10 이상에서만 작동한다.
궁금한 점이나 문의사항이 있다면 info@electronjs.org로 편하게 연락해 주세요. 또한 공식 Electron Discord에서 커뮤니티 지원을 받을 수 있습니다.
Electron 프로젝트는 2022년 12월 한 달 동안 휴식기를 갖고, 2023년 1월에 다시 본격적으로 재개될 예정이다.
12월에는 새로운 안정판(Stable) 릴리스가 없습니다. 또한 12월 마지막 2주 동안은 Nightly와 Alpha 릴리스도 중단됩니다.
몇 가지 예외를 제외하고 풀 리퀘스트 리뷰나 머지는 진행되지 않습니다.
모든 저장소에서 이슈 트래커 업데이트가 중단됩니다.
유지 관리자들이 Discord에서 디버깅 도움을 제공하지 않습니다.
소셜 미디어 콘텐츠 업데이트가 이루어지지 않습니다.
2021년 12월 Quiet Month의 성공적인 경험을 바탕으로, 2022년에도 이를 다시 시행하기로 결정했다. 대부분의 기업들에게 12월은 여전히 조용한 시기이기 때문에, 우리는 유지보수 담당자들이 충전할 수 있는 기회를 제공하고 싶었다. 모두가 2023년을 기대하고 있으며, 좋은 일들이 있을 것으로 예상한다! 다른 프로젝트들도 비슷한 조치를 고려해 보길 권장한다.
지난달, Electron의 메인테이너 그룹이 캐나다 밴쿠버에서 모여 2023년 및 그 이후의 프로젝트 방향을 논의했다. 4일간의 회의실에서 코어 메인테이너와 초대된 협력자들이 새로운 계획, 유지 관리의 어려움, 프로젝트 전반적인 상태에 대해 이야기를 나눴다.
단체 사진! @groundwater가 촬영.
앞으로도 팀은 정기적이고 빠른 Chromium 업그레이드, 버그 수정, 그리고 모든 사용자를 위해 Electron을 더 안전하고 성능 좋게 만드는 데 전념할 계획이다. 또한 커뮤니티와 공유하고 싶은 몇 가지 흥미로운 프로젝트도 진행 중이다!
Electron 프로젝트에서 합의가 필요한 주요 API 제안은 Request for Comments(RFC) 프로세스를 거친다. 이 과정은 API 작업 그룹 멤버들의 리뷰를 받는다.
올해 우리는 Electron 앱의 새로운 가능성을 열어줄 두 가지 주요 제안을 추진했다. 이 제안들은 아직 실험적이지만, 앞으로 어떤 변화가 예상되는지 미리 살펴보자!
이 제안은 앱 개발자가 Electron의 내부 리소스와 상호작용하는 네이티브 Node 애드온을 직접 작성할 수 있도록 하는 새로운 Electron C API 계층을 설명한다. 이는 Node의 Node-API와 유사한 방식으로 동작한다. 제안된 새로운 API에 대한 더 자세한 정보는 여기에서 확인할 수 있다.
많은 Electron 앱은 Chromium 내부와 직접 상호작용하기 위해 자체 포크를 유지한다. 이러한 리소스는 일반(수정되지 않은) Electron에서는 접근할 수 없다. C API 계층에서 이러한 리소스를 노출함으로써, 이 코드는 Electron과 함께 네이티브 모듈로 존재할 수 있다. 이는 앱 개발자의 유지보수 부담을 줄이는 데 도움이 된다.
크롬의 사용자 인터페이스(UI) 중 웹사이트가 아닌 부분, 예를 들어 툴바, 탭, 버튼 등은 Views라는 프레임워크로 구축된다. Views API 제안은 이 프레임워크의 일부를 Electron에서 JavaScript 클래스로 제공하는 것을 목표로 한다. 이를 통해 개발자는 Electron 애플리케이션에 웹 기반이 아닌 UI 엘리먼트를 추가할 수 있게 된다. 이는 앱이 웹 콘텐츠를 임시로 조합해야 하는 상황을 방지할 것이다.
이 새로운 API 세트를 가능하게 하기 위한 기반 작업이 현재 진행 중이다. 가까운 미래에 기대할 수 있는 몇 가지 기능은 다음과 같다.
WebContentsView로 윈도우 모델 리팩토링하기첫 번째로 계획한 변경 사항은 Chrome의 WebContentsView를 Electron API로 노출시키는 것이다. 이는 기존 BrowserView API를 대체할 예정이다. BrowserView는 이름과 달리 Chromium Views와 무관한 Electron 전용 코드였다. WebContentsView를 노출함으로써 웹 콘텐츠를 표시할 수 있는 재사용 가능한 View 객체를 확보하게 되며, 이를 통해 BrowserWindow 클래스를 순수 JavaScript로 만들고 코드 복잡성을 더욱 줄일 수 있다.
이 변경 사항은 앱 개발자에게 새로운 기능을 크게 제공하지는 않지만, 내부적으로 많은 코드를 제거하는 대규모 리팩토링이다. 이를 통해 Chromium 업그레이드가 간소화되고 주요 버전 간 새로운 버그 발생 위험이 줄어든다.
앱에서 BrowserViews를 사용하는 Electron 개발자라면 걱정하지 말자. 기존 BrowserView 클래스를 WebContentsView에 대한 셰임(shim)으로 만들어 새로운 API로 전환할 수 있는 완충 장치를 제공할 계획이다.
참고: electron/electron#35658
ScrollView를 이용한 스크롤 가능한 웹 콘텐츠Stack의 개발자들은 Chromium의 ScrollView 컴포넌트를 Electron API에 노출시키는 프로젝트를 진행하고 있다. 이 새로운 API를 사용하면 자식 View 컴포넌트를 가로 또는 세로로 스크롤 가능하게 만들 수 있다.
이 API는 단일 기능을 제공하지만, 팀의 궁극적인 목표는 더 복잡한 비 HTML 인터페이스를 구축할 수 있는 유틸리티 View 컴포넌트 세트를 만드는 것이다.
이 API 제안에 관심이 있는 Electron 앱 개발자라면, 지금 바로 참여할 수 있다. 비록 추가 RFC를 받을 준비가 완벽히 되지는 않았지만, 앞으로 더 자세한 내용이 공개될 예정이니 계속 지켜봐 주길 바란다!
Electron 프레임워크가 처음 등장한 이래로, 빌드 도구 생태계는 주로 커뮤니티 주도로 발전해 왔다. 이 과정에서 electron-winstaller, electron-packager, electron-notarize, electron-osx-sign 등과 같은 단일 목적의 작은 패키지들이 많이 등장했다. 이러한 도구들은 잘 작동하지만, 사용자들이 이를 조합해 동작하는 빌드 파이프라인을 구성하는 것은 부담스러운 일이었다.
Electron 개발자들에게 더 친숙한 경험을 제공하기 위해, 우리는 기존의 모든 도구를 단일 인터페이스로 통합한 올인원 솔루션인 Electron Forge를 개발했다. Forge는 2017년부터 개발되어 왔지만, 지난 몇 년 동안 프로젝트가 잠정 중단된 상태였다. 그러나 Electron의 빌드 도구 상태에 대한 커뮤니티 피드백을 바탕으로, 우리는 차세대 안정 버전인 Forge의 주요 버전을 출시하기 위해 열심히 작업했다.
Electron Forge 6은 퍼스트클래스 TypeScript 및 Webpack 지원과 함께, 개발자가 자신만의 플러그인과 설치 프로그램을 만들 수 있도록 확장 가능한 API를 제공한다.
Forge를 활용해 프로젝트를 구축하거나 Forge의 확장 가능한 서드파티 API를 사용해 템플릿이나 플러그인을 개발하는 데 관심이 있다면, 이번 달 중 예정된 Forge v6 안정판 출시에 대한 공식 발표를 기대해 주세요!
위에서 언급한 내용 외에도, 팀은 항상 앱 개발자와 최종 사용자를 위해 Electron 경험을 개선할 수 있는 다양한 탐구 프로젝트를 고민하고 있다. 업데이터 도구, API 리뷰 프로세스, 그리고 향상된 문서화 작업도 현재 실험 중인 부분이다. 가까운 미래에 더 많은 소식을 전할 수 있기를 기대한다!
Electron 21부터 V8 메모리 케이지가 활성화되며, 이로 인해 일부 네이티브 모듈에 영향을 미칠 수 있다.
Electron 21 이상에서 네이티브 모듈 사용에 대한 논의를 확인하려면 electron/electron#35801을 참고하라.
Electron 21에서는 Chrome 103에서와 마찬가지로 V8 샌드박스 포인터를 활성화할 예정이다. 이로 인해 네이티브 모듈에 일부 영향을 미칠 것이다. 또한, Electron 14에서 포인터 압축이라는 관련 기술을 이미 활성화한 바 있다. 당시에는 자세히 언급하지 않았지만, 포인터 압축은 V8 힙의 최대 크기에 영향을 미친다.
이 두 기술은 활성화될 경우 보안, 성능, 메모리 사용 측면에서 상당한 이점을 제공한다. 그러나 단점도 존재한다.
샌드박스 포인터를 활성화할 때의 주요 단점은 외부("오프 힙") 메모리를 가리키는 ArrayBuffer가 더 이상 허용되지 않는다는 점이다. 이는 V8에서 이 기능에 의존하는 네이티브 모듈이 Electron 20 이상에서 동작하려면 리팩토링이 필요함을 의미한다.
포인터 압축을 활성화할 때의 주요 단점은 V8 힙의 최대 크기가 4GB로 제한된다는 점이다. 이에 대한 세부 사항은 다소 복잡하다. 예를 들어, ArrayBuffer는 V8 힙과 별도로 계산되지만 자체적인 제한이 있다.
Electron 업그레이드 워킹 그룹은 포인터 압축과 V8 메모리 케이지의 이점이 단점을 상쇄할 만큼 크다고 판단했다. 이 결정에는 세 가지 주요 이유가 있다:
마지막으로, 더 큰 힙 크기가 필요한 앱을 위한 해결책도 있다. 예를 들어, 포인터 압축이 비활성화된 Node.js를 앱에 포함시키고 메모리 집약적인 작업을 자식 프로세스로 이동할 수 있다. 다소 복잡하지만, 특정 사용 사례에 맞게 포인터 압축이 비활성화된 커스텀 버전의 Electron을 빌드하는 것도 가능하다. 또한, 머지않아 wasm64가 도입되면 웹과 Electron에서 WebAssembly로 빌드된 앱이 4GB 이상의 메모리를 사용할 수 있게 될 것이다.
Electron 20 이상 버전에서는 외부 메모리를 ArrayBuffer로 감싸려고 하면 런타임 중에 충돌이 발생합니다.
앱에서 네이티브 Node 모듈을 사용하지 않는다면 안전합니다. 순수 JavaScript로는 이 충돌을 유발할 방법이 없기 때문입니다. 이 변경 사항은 V8 힙 외부에 메모리를 할당하고(예: malloc 또는 new 사용) 그 외부 메모리를 ArrayBuffer로 감싸는 네이티브 Node 모듈에만 영향을 미칩니다. 이는 상당히 드문 사용 사례이지만, 일부 모듈은 이 기법을 사용하며, Electron 20 이상 버전과 호환되려면 이러한 모듈을 리팩토링해야 합니다.
렌더러 프로세스에서는 performance.memory.usedJSHeapSize를 사용해 V8 힙 사용량을 바이트 단위로 확인할 수 있다. 메인 프로세스에서는 process.memoryUsage().heapUsed를 사용해 비슷한 정보를 얻을 수 있다.
일부 문서에서는 이를 "V8 샌드박스"라고 부르기도 하지만, 이 용어는 크로미움에서 사용되는 다른 종류의 샌드박싱과 혼동하기 쉽기 때문에 여기서는 "메모리 케이지"라는 용어를 사용하겠다.
V8에서 자주 발생하는 공격 유형은 다음과 같다:
V8 메모리 케이지는 이러한 종류의 공격을 근본적으로 방지하기 위한 기술이다. 이를 위해 V8 힙 내부에 어떤 포인터도 저장하지 않는다. 대신, V8 힙 내부의 다른 메모리를 참조할 때는 예약된 영역의 시작점에서의 오프셋으로 저장한다. 이렇게 하면 공격자가 V8의 타입 혼동 오류를 악용해 ArrayBuffer의 기본 주소를 손상시키더라도, 최악의 경우 케이지 내부의 메모리만 읽고 쓸 수 있다. 이는 이미 할 수 있었던 일일 가능성이 높다.
V8 메모리 케이지가 어떻게 동작하는지에 대해 더 많은 정보가 있지만, 여기서는 더 자세히 다루지 않겠다. 가장 좋은 시작점은 크로미움 팀의 고수준 설계 문서를 참고하는 것이다.
Electron 21+에서 네이티브 모듈을 리팩터링하려면 V8 메모리 케이지를 지원하도록 코드를 수정해야 한다. 이를 위한 두 가지 주요 방법이 있다.
첫 번째 방법은 외부에서 생성된 버퍼를 JavaScript로 전달하기 전에 V8 메모리 케이지로 복사하는 것이다. 이 방법은 일반적으로 간단하지만, 버퍼가 클 경우 속도가 느려질 수 있다. 두 번째 방법은 JavaScript로 전달할 메모리를 V8의 메모리 할당자를 사용해 할당하는 것이다. 이 방법은 더 복잡하지만, 복사를 피할 수 있어 대용량 버퍼에서 성능이 향상된다.
구체적인 예시로, 외부 배열 버퍼를 사용하는 N-API 모듈을 살펴보자.
// 외부에서 할당된 버퍼 생성
// |create_external_resource|는 malloc()을 통해 메모리를 할당한다.
size_t length = 0;
void* data = create_external_resource(&length);
// 버퍼로 감싸기. 메모리 케이지가 활성화되면 실패한다!
napi_value result;
napi_create_external_buffer(
env, length, data,
finalize_external_resource, NULL, &result);
이 코드는 메모리 케이지가 활성화된 상태에서 충돌을 일으킨다. 데이터가 케이지 외부에서 할당되었기 때문이다. 데이터를 케이지로 복사하도록 리팩터링하면 다음과 같다.
size_t length = 0;
void* data = create_external_resource(&length);
// V8이 할당한 메모리로 데이터를 복사해 새 버퍼 생성
napi_value result;
void* copied_data = NULL;
napi_create_buffer_copy(env, length, data, &copied_data, &result);
// 새로 복사된 데이터에 접근해야 한다면 |copied_data|를 사용한다.
이 코드는 데이터를 V8 메모리 케이지 내부의 새로 할당된 영역으로 복사한다. 필요에 따라 N-API는 새로 복사된 데이터에 대한 포인터를 제공할 수도 있다.
V8의 메모리 할당자를 사용하도록 리팩터링하는 방법은 조금 더 복잡하다. create_external_resource 함수를 수정해 malloc 대신 V8이 할당한 메모리를 사용해야 하기 때문이다. 이는 create_external_resource의 정의를 수정할 수 있는지 여부에 따라 달라진다. 먼저 napi_create_buffer를 사용해 버퍼를 생성한 후, V8이 할당한 메모리에 리소스를 초기화한다. 리소스의 수명 동안 Buffer 객체에 대한 napi_ref를 유지하는 것이 중요하다. 그렇지 않으면 V8이 Buffer를 가비지 컬렉션할 수 있으며, 이는 use-after-free 오류를 유발할 수 있다.
Electron이 주요 S3 버킷을 변경하고 있다. 여러분의 빌드 스크립트를 업데이트해야 할 수도 있다.
Electron의 빌드 아티팩트 상당량이 gh-contractor-zcbenz라는 S3 버킷에 업로드되어 있다. 2020년부터 시작된 인프라/소유권 이전 작업의 일환으로, 기존에 gh-contractor-zcbenz를 사용하던 모든 것을 S3에서 새로운 스토리지 시스템인 https://artifacts.electronjs.org로 이전한다. 또한 대부분의 리소스가 사용하는 경로 접두사도 약간 변경된다. 아래에 예제를 확인할 수 있다.
이전: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/dist/v17.0.0/node.lib
이후: https://artifacts.electronjs.org/headers/dist/v17.0.0/node.lib
여기서 중요한 변화는 호스트명이 변경되었고, /atom-shell 접두사가 바뀌었다는 점이다. 디버그 심볼에 대한 또 다른 예제를 살펴보자.
이전: https://gh-contractor-zcbenz.s3.amazonaws.com/atom-shell/symbols/path/to/symbol.pdb
이후: https://artifacts.electronjs.org/symbols/path/to/symbol.pdb
이번에도 호스트명이 변경되었고, /atom-shell 접두사가 사라졌다.
대부분의 개발자는 electron-rebuild, electron-packager, @electron/get 같은 표준 빌드 도구를 사용하기 때문에 별도의 조치가 필요 없다. 이 경우가 일반적인 상황이다.
하지만 S3 버킷을 직접 참조하고 있다면, 호스트명을 업데이트하고 경로도 함께 수정해야 한다.
gh-contractor-zcbenz 버킷에 있던 대부분의 데이터는 새로운 스토리지 시스템으로 복제되었다. 모든 디버그 심볼과 헤더 파일이 복사되었다. 만약 해당 버킷에 있던 데이터 중 복사되지 않은 것이 있다면, electron/electron에 이슈를 등록해 알려주기 바란다.
현재 gh-contractor-zcbenz S3 버킷은 즉시 삭제되지 않는다. 하지만 이 버킷이 얼마나 오래 유지될지 보장할 수 없다. 가능한 한 빨리 새로운 버킷을 사용하도록 업데이트하는 것을 강력히 권장한다.
Electron 프로젝트는 2021년 12월 한 달 동안 잠시 휴식기에 들어간 후, 2022년 1월부터 다시 전속력으로 운영될 예정이다.
간단히 말해, 프로젝트 관리자들은 여전히 프로젝트에 열정적이고 적극적으로 참여하고 있지만, 세상은 지쳐 있다. 12월은 대부분의 회사에서 조용한 시기이기 때문에, 우리는 관리자들이 재충전할 기회를 제공하고자 한다. 다른 프로젝트들도 비슷한 조치를 고려해 보길 권한다.
아니다. 우리가 이 단계를 밟을 수 있는 이유는 프로젝트가 안정적인 상태이기 때문이다. 모두가 2022년을 기대하고 있으며, 좋은 일들이 일어날 것으로 예상한다!
2021년 9월부터 Electron은 8주마다 새로운 주요 안정 버전을 출시할 예정이다.
2019년에 Electron은 Chromium의 6주 릴리스 주기에 맞추기 위해 12주 릴리스 주기로 전환했다. 최근 Chrome과 Microsoft가 발표한 변경 사항으로 인해 Electron의 현재 릴리스 주기를 재고하게 되었다:
Chromium은 2021년 9월 21일 Chrome 94부터 4주마다 새로운 마일스톤을 출시할 계획이다. 이 릴리스 주기는 8주마다 모든 보안 업데이트를 포함한 Extended Stable 옵션도 추가한다.
Microsoft 스토어는 Chromium 기반 앱이 최대 2개 주요 버전 이내여야 한다는 규정을 시행한다. 예를 들어, Chromium의 최신 주요 버전이 85라면, Chromium 기반 브라우저는 최소 Chromium 버전 83 이상이어야 한다. 이 규칙은 Electron 앱에도 적용된다.
2021년 9월부터 Electron은 Chromium의 8주 Extended Stable 릴리스에 맞춰 8주마다 새로운 주요 안정 버전을 출시할 예정이다.
Chromium Extended Stable과 함께 출시될 첫 번째 버전은 2021년 9월 21일의 Electron 15이다.
릴리스 주기 변경이 다른 하위 애플리케이션에 영향을 미칠 수 있음을 알고, 개발자 커뮤니티에 가능한 한 빨리 알리고자 한다. 2021년 릴리스 일정에 대한 자세한 내용은 계속 읽어보자.
원래 Electron 15 릴리스는 Chromium의 Extended Stable 버전이 아닌 버전을 타겟으로 했다. Chromium의 Extended Stable 버전은 짝수 번호 버전을 기반으로 하기 때문이다. 이를 위해 원래 목표 릴리스 날짜를 변경해야 했다. 하지만 Electron 앱이 Microsoft Store에 등록되려면 최신 2개의 Chromium 메이저 버전을 사용해야 한다는 조건이 있어, 두 버전을 기다리는 것은 현실적으로 불가능했다.
이 두 가지 요구사항으로 인해 우리 팀은 타이밍 문제에 직면했다. Electron 15에 Chromium M94를 포함시키면 앱 개발자들이 Chromium의 첫 번째 Extended Stable 버전을 사용할 수 있다는 장점이 있다. 하지만 이 경우 베타에서 안정화까지의 주기가 단 3주로 줄어든다는 단점이 있었다.
이러한 전환을 돕기 위해 Electron 팀은 Electron 15 릴리스에 한해 임시 알파 빌드를 제공하기로 결정했다. 이 알파 빌드는 개발자들이 Electron 15 릴리스를 테스트하고 준비할 수 있는 더 많은 시간을 제공하며, 현재의 나이틀리 빌드보다 더 안정적인 버전이다.
알파 채널 빌드는 2021년 7월 20일에 Electron 15로 출시될 예정이다. 이후 2021년 9월 1일에 베타 릴리스로 전환되며, 안정화 릴리스는 2021년 9월 21일을 목표로 한다. 이후 Electron 릴리스에는 알파 버전이 제공되지 않을 예정이다.
2021년 출시 일정은 다음과 같다:
| Electron | Chrome | Alpha 출시 | Beta 출시 | Stable 출시 | Stable 주기 (주) |
|---|---|---|---|---|---|
| E13 | M91 | - | 2021-03-05 | 2021-05-25 | 12 |
| E14 | M93 | - | 2021-05-26 | 2021-08-31 | 14 |
| E15 | M94 | 2021-07-20 | 2021-09-01 | 2021-09-21 | 9 (알파 포함) |
| E16 | M96 | - | 2021-09-22 | 2021-11-16 | 8 |
| E17 | M98 | - | 2021-11-17 | 2022-02-01 | 11 |
알파 채널을 추가함으로써 Electron 15 출시 전 개발 기간이 3주에서 9주로 확장된다. 이는 Windows 스토어 제출 요건을 충족하면서도 새로운 8주 주기에 더 가깝게 맞춘 것이다.
앱 개발자를 더 지원하기 위해, 2021년 말부터 2022년 5월까지 지원 버전 정책을 최신 3개 버전에서 최신 4개 버전으로 확장한다. 즉, 업그레이드 일정을 즉시 조정할 수 없더라도 이전 버전의 Electron이 여전히 보안 업데이트와 수정을 받을 수 있다.
이번 릴리스 주기 변경을 예정일보다 훨씬 앞서 이 글을 공개하는 데는 이유가 있다. 더 빠른 릴리스 주기가 Electron 앱에 미칠 실제 영향을 잘 알고 있으며, 이미 주요 릴리스 주기가 빠르다고 느끼는 앱도 있을 수 있다.
아래에서 주요 우려 사항을 해결하려고 노력했다:
Electron에서 최신 버전의 Chromium을 제공하려면 Chromium의 일정을 따라야 한다. Chromium의 릴리스 주기에 대한 자세한 정보는 여기에서 확인할 수 있다.
또한, 현재의 12주 릴리스 주기는 Microsoft Store의 새로운 제출 요구사항과 맞지 않는다. 최신 안정 버전의 Electron을 사용하는 앱도 새로운 보안 요구사항에 따라 약 2주 동안 앱이 거부될 가능성이 있다.
각각의 새로운 Chromium 릴리스에는 새로운 기능, 버그 수정/보안 패치, 그리고 V8 개선 사항이 포함된다. 앱 개발자로서 이러한 변경 사항을 빠르게 접할 수 있도록, 우리는 안정 버전 릴리스 날짜를 Chromium 안정 버전 릴리스와 일치시키기로 했다. 이제 앱 개발자는 이전보다 더 빠르게 새로운 Chromium과 V8의 기능 및 수정 사항을 사용할 수 있다.
기존 12주 릴리스 주기는 이미 빠른 속도로 진행되고 있다. 팀은 업그레이드를 더 쉽게 만들기 위해 어떤 조치를 취하고 있는가?
더 잦은 릴리스의 장점 중 하나는 더 작은 규모의 릴리스가 가능하다는 점이다. Electron의 주요 버전 업그레이드가 어려울 수 있다는 점을 잘 알고 있다. 더 작은 규모의 릴리스는 주요 Chromium과 Node 변경 사항을 줄이고, 릴리스당 발생하는 호환성 문제도 줄이길 기대한다.
현재로서는 지속적인 알파 릴리스를 지원할 계획이 없다. 이번 알파 버전은 Electron 15에 한정된 것으로, 개발자들이 단축된 릴리스 기간 동안 더 쉽게 업그레이드할 수 있도록 돕기 위한 목적으로 제공된다.
Electron 19가 출시되는 2022년 5월까지 지원 버전 정책을 최신 3개 버전에서 최신 4개 버전으로 확장할 예정이다. Electron 19 출시 이후에는 다시 최신 3개 주요 버전과 베타, 나이틀리 릴리스를 지원할 계획이다.
| E13 (2021년 5월) | E14 (2021년 8월) | E15 (2021년 9월) | E16 (2021년 11월) | E17 (2022년 2월) | E18 (2022년 3월) | E19 (2022년 5월) |
|---|---|---|---|---|---|---|
| 13.x.y | 14.x.y | 15.x.y | 16.x.y | 17.x.y | 18.x.y | 19.x.y |
| 12.x.y | 13.x.y | 14.x.y | 15.x.y | 16.x.y | 17.x.y | 18.x.y |
| 11.x.y | 12.x.y | 13.x.y | 14.x.y | 15.x.y | 16.x.y | 17.x.y |
| -- | -- | 12.x.y | 13.x.y | 14.x.y | 15.x.y | -- |
📨 질문이나 의견이 있다면 info@electronjs.org로 메일을 보내거나 Discord에 참여해 주세요. 이번 변경이 많은 앱과 개발자에게 영향을 미칠 것임을 잘 알고 있습니다. 여러분의 의견은 매우 중요합니다. 여러분의 소리를 듣고 싶습니다!