2025년 초, Electron의 npm 생태계 저장소(@electron/ 및 @electron-forge/ 네임스페이스 아래)는 최소 지원 버전을 Node.js 22로 변경한다.

과거에는 Electron의 npm 생태계(Forge, Packager 등) 내 패키지들이 가능한 한 오랫동안 Node 버전을 지원해왔다. 심지어 해당 버전이 End-Of-Life(EOL)에 도달한 후에도 말이다. 이는 생태계가 분열되는 것을 방지하기 위한 조치였다. 많은 프로젝트가 구버전의 Node에 의존하고 있음을 이해했기 때문에, 업그레이드가 꼭 필요한 상황이 아니라면 이러한 프로젝트를 방치하는 위험을 감수하고 싶지 않았다.

하지만 시간이 지나면서 Node.js 14를 최소 버전으로 사용하는 것이 점점 더 어려워졌다. 그 이유는 다음과 같다:

• 공식적인 Node.js 14 macOS ARM64 빌드가 없어, 전체 테스트 커버리지를 제공하기 위해 CI 인프라를 유지하는 데 추가 작업이 필요하다.
• 상위 패키지 의존성의 engines 요구사항이 점점 더 높아지면서, 의존성 업데이트를 통해 공급망 보안 문제를 해결하기가 더 어려워졌다.

또한, 최신 버전의 Node.js에는 fs.glob과 util.parseArgs 같은 런타임 내장 유틸리티와 node:test, node:sqlite 같은 새로운 모듈이 포함되어 있다. 이러한 개선 사항을 활용하고 싶은 이유도 있다.

왜 지금 업그레이드해야 할까?​

2024년 7월, Electron의 Ecosystem Working Group은 모든 패키지를 동기식 ESM 그래프의 require()를 지원하는 가장 이른 Node 버전으로 업그레이드하기로 결정했다. 이 버전이 LTS(장기 지원) 날짜에 도달한 후에 적용될 예정이다. 관련 내용은 nodejs/node#51977과 nodejs/node#53500에서 확인할 수 있다.

이 업데이트 시점을 2025년 1월/2월로 정했다. 이 업그레이드가 완료되면, Node 22가 기존 생태계 패키지에서 지원되는 최소 버전이 된다.

어떤 조치를 취해야 하나?​

가능한 한 많은 호환성을 유지하기 위해 노력할 것이다. 하지만 최상의 지원을 보장하기 위해 여러분의 앱을 Node 22 이상으로 업그레이드할 것을 권장한다.

프로젝트에서 실행 중인 Node 버전은 현재 사용 중인 Electron 버전에 내장된 Node 버전과는 별개라는 점을 유의하라.

궁금한 점이나 문의사항이 있다면 언제든지 info@electronjs.org로 메일을 보내주세요. 또한 공식 Electron Discord에서 커뮤니티 지원을 받을 수도 있습니다.

Electron 30부터 BrowserView는 더 이상 사용되지 않으며, WebContentView로 대체되었다. 다행히도 마이그레이션은 비교적 간단하다.

Electron은 Chromium의 UI 프레임워크인 Views API와의 일관성을 유지하기 위해 BrowserView에서 WebContentsView로 전환하고 있다. WebContentsView는 Chromium의 렌더링 파이프라인과 직접 연결된 재사용 가능한 뷰를 제공하며, 이를 통해 향후 업그레이드가 간소화되고 개발자가 Electron 앱에 비웹 UI 엘리먼트를 통합할 수 있는 가능성이 열린다. WebContentsView를 채택함으로써 애플리케이션은 다가오는 업데이트에 대비할 수 있을 뿐만 아니라 코드 복잡성이 줄어들고 장기적으로 잠재적인 버그가 감소하는 이점을 얻는다.

BrowserWindow와 BrowserView에 익숙한 개발자라면 BrowserWindow와 WebContentsView가 각각 BaseWindow와 View 기본 클래스를 상속받은 서브클래스라는 점을 주목해야 한다. 사용 가능한 인스턴스 변수와 메서드를 완전히 이해하려면 이 기본 클래스에 대한 문서를 참고하는 것이 좋다.

마이그레이션 단계​

1. Electron을 30.0.0 이상 버전으로 업그레이드​

2. 애플리케이션에서 BrowserView를 사용하는 부분 파악하기​

이를 위해 코드베이스에서 new BrowserView(를 검색해 보는 방법이 있다. 이렇게 하면 애플리케이션이 BrowserView를 어떻게 사용하고 있는지, 그리고 몇 군데를 마이그레이션해야 하는지 대략적인 감을 잡을 수 있다.

3. BrowserView 사용 부분 마이그레이션​

1. 인스턴스 생성 부분을 마이그레이션한다. WebContentsView와 BrowserView의 생성자는 거의 동일한 형태를 가지고 있기 때문에 비교적 간단하다. 둘 다 webPreferences 파라미터를 통해 WebPreferences를 받는다.

   - this.tabBar = new BrowserView({
   + this.tabBar = new WebContentsView({
   
   info

   기본적으로 WebContentsView는 흰색 배경으로 인스턴스화되지만, BrowserView는 투명한 배경으로 인스턴스화된다.
   WebContentsView에서 투명한 배경을 얻으려면 배경색을 RGBA 헥스 값으로 설정하고 알파 채널을 00으로 지정한다:

   + this.webContentsView.setBackgroundColor("#00000000");
   

2. BrowserView가 부모 윈도우에 추가되는 부분을 마이그레이션한다.

   - this.browserWindow.addBrowserView(this.tabBar)
   + this.browserWindow.contentView.addChildView(this.tabBar);
   

3. 부모 윈도우에서 BrowserView 인스턴스 메서드 호출을 마이그레이션한다.

   이전 메서드	새로운 메서드	참고 사항
   win.setBrowserView	win.contentView.removeChildView + win.contentView.addChildView
   win.getBrowserView	win.contentView.children
   win.removeBrowserView	win.contentView.removeChildView
   win.setTopBrowserView	win.contentView.addChildView	기존 뷰에 addChildView를 호출하면 해당 뷰를 맨 위로 재정렬한다.
   win.getBrowserViews	win.contentView.children

4. setAutoResize 인스턴스 메서드를 리사이즈 리스너로 마이그레이션한다.

   - this.browserView.setAutoResize({
   -   vertical: true,
   - })
   
   + this.browserWindow.on('resize', () => {
   +   if (!this.browserWindow || !this.webContentsView) {
   +     return;
   +   }
   +   const bounds = this.browserWindow.getBounds();
   +   this.webContentsView.setBounds({
   +     x: 0,
   +     y: 0,
   +     width: bounds.width,
   +     height: bounds.height,
   +    });
   +  });
   
   tip

   browserView.webContents와 browserView.setBounds, browserView.getBounds, browserView.setBackgroundColor 인스턴스 메서드의 기존 사용법은 마이그레이션할 필요가 없으며, WebContentsView 인스턴스에서 바로 작동한다!

4. 변경 사항 테스트 및 커밋​

문제가 발생한가요? Electron의 이슈 트래커에서 WebContentsView 태그를 확인해 보고, 당신이 겪고 있는 문제가 이미 보고되었는지 확인하세요. 해당 문제가 없다면 새로운 버그 리포트를 추가해도 좋습니다. 테스트 케이스 예제를 포함하면 문제를 더 효율적으로 처리할 수 있습니다.

축하합니다! WebContentsView로 마이그레이션을 성공적으로 완료했습니다! 🎉

Electron API의 역사적 변경 사항이 이제 문서에 상세히 기록된다.

안녕하세요 👋, 저는 2024년 Google Summer of Code(GSoC)에 참여하여 Electron에 기여한 Peter입니다.

GSoC 프로그램 기간 동안, 저는 Node.js 문서와 유사한 방식으로 Electron 문서와 그 기능, 클래스 등에 대한 API 기록 기능을 구현했다. 이를 위해 API 문서 마크다운 파일에 간단하지만 강력한 YAML 스키마를 사용할 수 있게 했고, Electron 문서 웹사이트에서 이를 멋지게 표시하도록 했다.

Electron이 2024년 Google Summer of Code(GSoC)의 20번째 멘토링 기관으로 선정되었다는 소식을 전하게 되어 기쁩니다! Google Summer of Code는 오픈소스 소프트웨어 개발에 새로운 기여자를 유치하는 데 중점을 둔 글로벌 프로그램입니다.

프로그램에 대한 자세한 내용은 Google의 Summer of Code 홈페이지에서 확인할 수 있습니다.

우리 소개​

Electron은 웹 기술을 활용해 크로스 플랫폼 데스크톱 애플리케이션을 개발할 수 있는 자바스크립트 프레임워크다. Electron의 핵심 프레임워크는 Chromium과 Node.js를 기반으로 빌드된 컴파일된 바이너리 실행 파일이며, 주로 C++로 작성되었다.

Electron 코어 외에도, 우리는 Electron 생태계를 유지하고 발전시키기 위해 다양한 프로젝트를 진행하고 있다. 주요 프로젝트는 다음과 같다:

• 최종 사용자 배포 도구 (예: Electron Forge와 update.electronjs.org).
• Electron 개발자를 위한 학습 자료 (예: electronjs.org와 Electron Fiddle).
• 개발자 생산성을 높이는 내부 도구 (예: Electron Build Tools와 Sheriff).

Summer of Code 기여자로서, 여러분은 github.com/electron 아래의 다양한 프로젝트 중 하나에서 Electron의 핵심 기여자들과 함께 협업하게 될 것이다.

적용 전에​

Electron에 익숙하지 않다면, 먼저 공식 문서를 읽고 Electron Fiddle에서 예제를 직접 실행해보는 것을 추천한다.

Electron 앱 배포에 대해 더 알고 싶다면, Electron Forge를 사용해 샘플 애플리케이션을 만들어보자:

npm init electron-app@latest my-app

코드를 어느 정도 익힌 후에는 Electron Discord 서버에 참여해 대화에 동참해보자.

제안서 작성하기​

Electron과 협업에 관심이 있다면, 먼저 준비된 일곱 가지 프로젝트 아이디어 초안을 확인해 보자. 현재 모든 아이디어는 제안을 받고 있다.

다른 아이디어를 제안하고 싶다면, 제안된 프로젝트 목록에 없는 새로운 아이디어도 검토할 수 있다. 단, 접근 방식을 철저히 정리하고 상세히 설명해야 한다. 확신이 없다면, 우리가 제안한 아이디어를 따르는 것을 권장한다.

지원서에는 다음 내용을 포함해야 한다:

• 제안서: 여름 동안 달성할 계획을 상세히 설명한 문서
• 개발자로서의 배경: 이력서가 있다면 사본을 첨부한다. 그렇지 않다면, 과거의 기술 경험에 대해 설명한다.
  • 특정 분야에서 경험이 부족하더라도 자격이 박탈되지는 않지만, 멘토들이 최상의 지원 계획을 세우고 여름 프로젝트가 성공할 수 있도록 도움을 줄 것이다.

Electron 지원서 제출에 대한 상세 가이드는 여기에서 확인할 수 있다. 제안서는 Google Summer of Code 포털에 직접 제출해야 한다. Electron 팀에 이메일로 보낸 제안서는 최종 제출로 간주되지 않는다.

제안서 작성에 대한 추가 지침이 필요하거나 무엇을 포함해야 할지 확실하지 않다면, Google Summer of Code의 공식 제안서 작성 가이드를 따르는 것을 권장한다.

지원은 2024년 3월 18일에 시작되어 2024년 4월 2일에 마감된다.

궁금한 점이 있나요?​

블로그 글에서 다루지 않은 질문이나 제안서 초안에 대한 문의가 있다면, summer-of-code@electronjs.org로 이메일을 보내거나 GSoC FAQ를 확인해 보세요!

참고 자료​

• Electron Google Summer of Code 2024 아이디어 목록
• Electron Google Summer of Code 2024 참여자 가이드
• Google Summer of Code 학생/참여자 가이드

Electron의 API Working Group은 Electron 코어에 대한 주요 변경 사항을 관리하기 위해 공개적인 Requests for Comments (RFC) 프로세스를 도입하고 있다.

RFC가 필요한 이유​

간단히 말해, 우리는 Electron 코어에 중대한 변경 사항을 적용하는 과정을 원활하게 만들고자 한다.

현재 새로운 코드 변경은 대부분 GitHub 이슈와 풀 리퀘스트를 통해 논의된다. 대부분의 Electron 변경 사항에 대해 이 시스템은 잘 작동한다. 많은 버그 수정, 문서 변경, 그리고 새로운 기능들은 GitHub의 표준 워크플로우를 통해 비동기적으로 리뷰하고 병합하기에 충분히 직관적이다.

그러나 더 중요한 변경 사항, 예를 들어 큰 API 영역이나 대부분의 Electron 앱에 영향을 미칠 수 있는 호환성 깨짐(breaking changes)과 같은 경우, 코드 대부분이 작성되기 전에 아이디어 단계에서 리뷰가 이루어지는 것이 합리적이다.

이 프로세스는 공개적으로 진행되도록 설계되어 있다. 이를 통해 오픈소스 커뮤니티가 Electron에 반영되기 전에 잠재적인 변경 사항에 대해 피드백을 제공하기가 더 쉬워진다.

동작 원리​

전체 RFC 프로세스는 GitHub의 electron/rfcs 저장소에서 관리된다. 각 단계는 저장소의 README에 자세히 설명되어 있다.

간단히 설명하면, RFC는 electron/rfcs 저장소에 PR이 생성되면 Proposed 상태가 된다. Proposed RFC는 다음과 같이 변한다:

• Active: PR이 저장소의 main 브랜치로 병합되면 Active 상태가 된다. 이는 Electron 관리자가 electron/electron에서 구현을 허용한다는 의미다.
• Declined: PR이 최종적으로 거부되면 Declined 상태가 된다.

Active 상태의 RFC는 구현이 electron/electron에 병합되면 Completed 상태가 된다.

누가 참여할 수 있나요?​

Electron 커뮤니티의 누구나 electron/rfcs 저장소에 RFC를 제출하거나 피드백을 남길 수 있습니다!

• 현재 활성화된 RFC 목록을 확인하려면 저장소의 text 폴더를 참고하세요.
• 제안된 RFC에 대한 피드백을 남기려면 열려 있는 PR 목록을 확인하세요.
• 새로운 RFC를 제출하려면 저장소의 README와 RFC 템플릿을 참고하세요.

이 과정을 양방향 대화로 만들고, 커뮤니티의 참여를 장려하여 향후 이러한 API를 사용할 수 있는 Electron 앱으로부터 다양한 의견을 수집하고자 합니다. 현재 제안된 RFC에 피드백을 남기고 싶다면, Electron 메인테이너들이 이미 몇 가지를 작성해 두었습니다:

• Electron C APIs
• Preload Realm for Service Workers

크레딧​

Electron의 RFC 프로세스는 여러 오픈소스 RFC 프로세스를 참고하여 설계되었다. 아이디어와 주요 문구 작성에 영감을 준 프로젝트는 다음과 같다:

• emberjs/rfcs
• reactjs/rfcs
• rust-lang/rfcs
• tauri-apps/rfcs
• vuejs/rfcs
• yarnpkg/rfcs

electron/electron 저장소에 첫 커밋이 이루어진 날은 2013년 3월 13일이었다¹.

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 릴리즈 관리 (Releases WG)
• Chromium과 Node.js 업그레이드 (Upgrades WG)
• 공개 API 설계 감독 (API WG)
• Electron 보안 유지 (Security WG)
• 웹사이트, 문서, 도구 관리 (Ecosystem WG)
• 커뮤니티 및 기업 외부 연계 (Outreach WG)
• 커뮤니티 규제 (Community & Safety WG)
• 빌드 인프라, 메인테이너 도구, 클라우드 서비스 유지 (Infrastructure WG)

우리가 거버넌스 모델로 전환한 시기와 거의 동시에, Electron의 소유권도 GitHub에서 OpenJS Foundation으로 이전했다. 원래의 코어 팀은 여전히 Microsoft에서 근무하고 있지만, 이제는 Electron 거버넌스를 구성하는 더 큰 협력자 그룹의 일부일 뿐이다.²

이 모델이 완벽하지는 않지만, 전 세계적인 팬데믹과 지속적인 거시경제적 어려움 속에서도 우리에게 잘 맞아왔다. 앞으로 우리는 Electron의 두 번째 10년을 이끌어갈 수 있도록 거버넌스 헌장을 개선할 계획이다.

커뮤니티​

오픈소스의 커뮤니티 부분은 쉽지 않다. 특히 아웃리치 팀이 '커뮤니티 매니저'라는 이름의 트렌치코트를 입은 소수의 엔지니어들로 구성되어 있을 때는 더욱 그렇다. 하지만 대규모 오픈소스 프로젝트로서 우리는 많은 사용자를 보유하고 있으며, 이들의 에너지를 활용해 Electron을 위한 사용자 중심의 생태계를 구축하는 것은 프로젝트의 건강을 유지하는 데 중요한 부분이다.

그렇다면 우리는 커뮤니티 존재감을 강화하기 위해 어떤 노력을 기울이고 있을까?

가상 커뮤니티 구축​

• 2020년에 우리는 커뮤니티 디스코드 서버를 출시했다. 이전에는 Atom 포럼의 한 섹션을 사용했지만, 더 비공식적인 메시징 플랫폼을 통해 관리자와 Electron 개발자 간의 토론 공간을 마련하고 일반적인 디버깅 도움을 제공하기로 결정했다.
• 2021년에는 @BlackHole1의 도움으로 Electron China 사용자 그룹을 설립했다. 이 그룹은 중국의 급성장하는 기술 환경에서 Electron 사용자 증가에 중요한 역할을 했다. 중국 사용자들이 아이디어를 공유하고 영어 공간 외에서 Electron에 대해 논의할 수 있는 공간을 제공했다. 또한 cnpm이 중국 npm 미러에서 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을 컴파일할 수 있게 되었다!

지속적 인증(Continuous Factor Authentication)​

지속적 인증(CFA)은 npm의 2단계 인증(2FA) 시스템을 자동화한 레이어로, semantic-release와 결합하여 다양한 @electron/ npm 패키지의 안전하고 자동화된 릴리즈를 관리한다.

semantic-release는 이미 npm 패키지 배포 과정을 자동화하지만, 2단계 인증을 비활성화하거나 이 제한을 우회하는 비밀 토큰을 전달해야 한다.

CFA는 npm 2FA를 위한 시간 기반 일회용 비밀번호(TOTP)를 임의의 CI 작업에 제공하도록 설계되었다. 이를 통해 semantic-release의 자동화 기능을 활용하면서도 2단계 인증의 추가 보안을 유지할 수 있다.

CFA는 Slack 통합 프론트엔드와 함께 사용되며, 유지 관리자는 TOTP 생성기가 있는 한 Slack이 설치된 모든 기기에서 패키지 배포를 검증할 수 있다.

Sheriff​

Sheriff는 GitHub, Slack, Google Workspace의 권한 관리를 자동화하기 위해 개발한 오픈소스 도구다.

Sheriff의 핵심 가치는 권한 관리를 투명한 프로세스로 만드는 데 있다. 이 도구는 단일 YAML 설정 파일을 사용해 위에 언급한 모든 서비스의 권한을 지정한다. Sheriff를 사용하면 리포지토리에 협력자로 추가되거나 새로운 메일링 리스트를 만드는 작업이 PR을 승인하고 병합하는 것만큼 간단해진다.

또한 Sheriff는 Slack에 감사 로그를 전송해 Electron 조직 내에서 의심스러운 활동이 발생할 때 관리자에게 경고를 보낸다.

GitHub는 풍부한 API 확장성을 제공하며, 공식적인 봇 애플리케이션 프레임워크인 Probot을 지원한다. 우리가 더 창의적인 업무에 집중할 수 있도록, 다양한 작은 봇들을 개발해 반복적인 작업을 자동화했다. 몇 가지 예를 살펴보자:

• Sudowoodo는 Electron 릴리스 프로세스를 처음부터 끝까지 자동화한다. 빌드를 시작하고, 릴리스 자산을 GitHub와 npm에 업로드하는 작업을 포함한다.
• Trop은 Electron의 백포트 프로세스를 자동화한다. GitHub PR 레이블을 기반으로 이전 릴리스 브랜치에 패치를 적용한다.
• Roller는 Electron의 Chromium과 Node.js 의존성을 자동으로 업그레이드한다.
• Cation은 electron/electron PR의 상태를 확인하는 봇이다.

이러한 봇들은 개발자 생산성을 크게 향상시켰다. 작은 봇들이 모여 큰 효율을 만들어낸 셈이다.

앞으로의 계획​

Electron 프로젝트가 두 번째 10년을 맞이한 지금, 여러분은 Electron의 미래가 어떻게 펼쳐질지 궁금할 것이다.

우리는 Chromium의 릴리스 주기에 맞춰 Electron의 새로운 주요 버전을 8주마다 출시할 계획이다. 이를 통해 웹 플랫폼과 Node.js의 최신 기술을 Electron 프레임워크에 반영하면서도, 엔터프라이즈급 애플리케이션에 필요한 안정성과 보안을 유지할 것이다.

구체적인 계획이 확정되면, 우리는 이를 공식적으로 발표할 예정이다. 앞으로의 릴리스, 새로운 기능, 그리고 프로젝트 업데이트에 대한 최신 정보를 받아보고 싶다면 Electron 블로그를 읽거나, 소셜 미디어 프로필(Twitter 및 Mastodon)을 팔로우하면 된다.

Electron 팀은 올해 처음으로 Google Summer of Code에 참여하게 되어 매우 기쁘게 생각한다!

구글 서머 오브 코드란?​

구글 서머 오브 코드(GSoC)는 오픈소스 소프트웨어 프로젝트와 잠재적인 기여자를 연결하는 연간 멘토링 프로그램이다. 이전에는 학생만 참여할 수 있었지만, 이제는 18세 이상의 누구나 GSoC에 등록할 수 있다.

더 자세한 정보는 Summer of Code 홈페이지에서 확인할 수 있다.

어떻게 신청하나요?​

Electron과 함께 협업하고 싶은가요? 오픈소스 기여자가 처음이거나 초보자라도 환영합니다!

Google Summer of Code의 Electron 기여자로 선정되려면 신청서를 제출해야 합니다. 신청 기간은 2022년 4월 4일부터 2022년 4월 19일까지입니다. Google Summer of Code 신청 가이드라인 업데이트는 여기서 확인할 수 있습니다.

신청하고 싶다면 먼저 다섯 가지 프로젝트 아이디어 초안을 확인해 보세요. 나열된 모든 아이디어는 현재 제안을 받고 있습니다. 또한 제안된 프로젝트 목록에 없는 새로운 아이디어도 환영합니다.

신청서에는 다음 내용이 포함되어야 합니다:

• 여름 동안 달성하고자 하는 계획을 상세히 설명한 제안서
• 개발자로서의 배경. 이력서가 있다면 사본을 포함하고, 그렇지 않다면 관련 기술 경험을 중심으로 과거 경험을 설명

Electron 신청서 제출에 대한 상세 가이드는 여기서 확인할 수 있습니다.

또한 공식 GSoC 학생/기여자 가이드를 읽어보면 제안서 준비에 유용한 팁을 얻을 수 있습니다.

프로젝트 제안에 대해 논의하거나 질문이 있다면 #gsoc-general Discord 채널에 참여해 보세요!

참고 자료​

• Electron 제안 가이드
• Electron GitHub
• 프로젝트 아이디어 문서
• Google Summer of Code 학생/기여자 가이드

오픈소스의 달을 기념하며 커뮤니티와 함께하는 시간에 참여하세요.

Electron 커뮤니티 Discord 출시

Electron의 Outreach Working Group이 공식 커뮤니티 Discord 서버 출시를 발표하게 되어 기쁘게 생각합니다!

새로운 Discord 서버를 만든 이유​

초기에는 Atom 텍스트 에디터의 핵심 기술로 사용되던 Electron 프레임워크에 대한 커뮤니티 토론은 Atom의 Slack 워크스페이스 내 단일 채널에서 이루어졌다. 시간이 지나면서 두 프로젝트가 점차 분리되면서, Electron 프로젝트와 Atom 워크스페이스의 관련성은 줄어들었고, Slack 채널에서의 메인테이너 참여도 같은 방식으로 감소했다.

지금까지는 더 넓은 커뮤니티를 Atom Slack 워크스페이스로 리다이렉트하고 있었지만, 초대장을 받는 데 어려움을 겪었다는 많은 보고가 있었고, 핵심 메인테이너들 중 채널을 자주 방문하는 사람은 거의 없었다.

이제는 커뮤니티가 Electron에 관한 최신 소식을 얻을 수 있는 중앙 토론 허브 역할을 할 새로운 Discord 서버를 구축했다. 이 서버는 Electron과 관련된 모든 주제를 다루는 주요 커뮤니케이션 채널이 될 것이다.

함께 참여하세요!​

지금까지 서버는 몇 명의 관리자들이 함께 설정하며 운영해 왔지만, 여러분과 소통할 수 있게 되어 정말 기쁩니다! 도움을 요청하거나, Electron의 최신 릴리즈 소식을 확인하거나, 다른 개발자들과 교류하는 등 다양한 목적으로 참여해 보세요. 서버에 접속할 수 있는 초대 링크를 준비했으니, 편하게 이용해 보세요!

Hacktoberfest 2020 참여

Electron은 대규모 오픈소스 프로젝트로, 오랜 기간 동안 지속해 온 프로젝트다. 코드 제출부터 버그 리포트, 문서 수정 등 다양한 형태의 커뮤니티 기여 없이는 이만큼 성공할 수 없었다. 그래서 우리는 Hacktoberfest에 참여하는 것이 중요하다고 믿는다. 이 행사를 통해 다양한 기술 수준의 개발자들이 더 넓은 커뮤니티로 프로젝트에 합류할 수 있기 때문이다.

기타 사항​

올해는 여러분이 함께 작업할 대규모 프로젝트는 없지만, Electron 자바스크립트 생태계 전반에 걸쳐 기여할 수 있는 기회에 집중하고자 한다.

다양한 저장소에서 hacktoberfest 태그가 붙은 이슈를 찾아보길 바란다. 주요 저장소인 electron/electron, electron/electronjs.org 웹사이트, electron/fiddle, 그리고 electron-userland/electron-forge를 포함한다.

추가로, 좀 더 도전적인 과제를 원한다면 help wanted 태그가 붙은 이슈도 확인해보길 바란다.

막히셨나요? 우리와 함께 이야기해 보세요!​

또한, 우리 디스코드 서버의 오픈이 올해 가장 큰 오픈소스 소프트웨어 축제와 맞춰진 것은 결코 우연이 아닙니다. Hacktoberfest PR에 대한 도움을 받고 싶다면 #hacktoberfest 채널을 확인해 보세요. 혹시 놓치셨다면, 다시 한번 초대 링크를 공유합니다!

Electron은 Google의 Season of Docs 이니셔티브 두 번째 버전에 참여하게 된 것을 자랑스럽게 생각한다. 이 프로그램은 오픈소스 조직의 멘토와 기술 문서 작성자를 연결해 프로젝트 문서를 개선하는 데 초점을 맞춘다.

Season of Docs는 기술 문서 작성자와 오픈소스 커뮤니티 간의 협업을 촉진하여 양측에 이익을 주는 프로그램이다. 오픈소스 관리자는 기술 문서 작성자의 전문성을 활용해 문서의 구조와 내용을 개선하고, 기술 문서 작성자는 멘토의 지도 아래 오픈소스 커뮤니티에 참여하게 된다. 더 자세한 내용은 Google의 Season of Docs 웹사이트에서 확인할 수 있다.

이번 프로그램에 처음으로 참여하면서, 우리는 단 한 명의 기술 문서 작성자를 멘토링할 예정이다. 이 작성자는 Electron의 Ecosystem Working Group과 함께 작업하며 문서의 상당 부분을 재구성할 것이다. 전체 프로젝트의 타임라인은 여기에서 확인할 수 있다.

어떻게 참여할 수 있나요?

Electron과 함께 기술 문서 작가로 협업하고 싶은가요? 먼저 Google의 기술 문서 작성 가이드를 확인하고, 우리가 준비한 두 가지 프로젝트 아이디어 초안을 살펴보세요.

Season of Docs에서 Electron의 기술 문서 작가로 선발되려면, 6월 8일부터 7월 9일까지 진행되는 '기술 문서 작성자 지원 단계'에서 Google Season of Docs 웹사이트를 통해 지원해야 합니다.

지원서에는 제안서를 포함해야 합니다. 제안서는 3개월 동안 Electron 문서에서 달성하고자 하는 계획을 상세히 설명하는 문서입니다. 이 제안서는 우리가 제공한 프로젝트 아이디어 문서에 언급된 시작점을 기반으로 할 수도 있고, 완전히 새로운 아이디어를 제안할 수도 있습니다. 어디서부터 시작해야 할지 모르겠다면, 작년의 선정된 제안서 목록을 참고해 영감을 얻을 수 있습니다.

제안서 외에도, 지원자의 기술 문서 작성 경력을 확인할 예정입니다. 관련된 글쓰기 경험을 강조한 이력서와 함께, 기술 문서 샘플(기존 문서, 튜토리얼, 블로그 포스트 등)을 제출해 주세요.

프로젝트 제안에 대해 논의하고 싶다면, season-of-docs@electronjs.org로 이메일을 보내주세요. 그곳에서 대화를 이어갈 수 있습니다!

참고 자료

• Electron 공식 문서
• 프로젝트 아이디어 문서
• Season of Docs 기술 문서 작성자 가이드

Electron은 더 빠르고 안정적인 릴리스 주기를 만들기 위해 노력하고 있다. 이를 실현하기 위해 대규모 Electron 애플리케이션을 대상으로 App Feedback Program을 시작했다. 이 프로그램은 베타 릴리스를 테스트하고 애플리케이션별 문제를 보고하는 데 목적이 있다. 이를 통해 다음 안정 버전으로 애플리케이션을 더 빨리 업그레이드할 수 있도록 작업 우선순위를 정하는 데 도움이 된다.

편집 (2020-05-21): 이 프로그램은 종료되었다.

누가 참여할 수 있나요?​

이 프로그램에 참여할 앱에 대한 기준과 기대 사항은 다음과 같습니다:

• 베타 기간 동안 10,000시간 이상의 사용자 시간 동안 앱을 테스트한다.
• 매주 앱의 Electron 버그와 앱 블로커에 대해 논의할 단일 담당자를 지정한다.
• Electron의 행동 강령을 준수할 것에 동의한다.
• 다음 질문에 나열된 정보를 공유할 의향이 있다.

내 Electron 앱은 어떤 정보를 공유해야 하나?​

• 베타 버전으로 실행된 앱의 총 사용 시간
• 앱이 테스트 중인 Electron 버전 (예: 4.0.0-beta.3)
• 베타 테스트 중인 릴리스 라인으로 업그레이드하는 것을 방해하는 버그

사용자 시간​

모든 사람이 정확한 사용자 수를 공유할 수는 없다는 점을 이해한다. 하지만 더 나은 데이터는 특정 릴리스의 안정성을 판단하는 데 도움이 된다. 앱이 베타 주기 동안 최소 10,000 사용자 시간을 테스트할 것을 요청한다.

• 10 사용자 시간은 10명이 1시간 동안 테스트하거나, 1명이 10시간 동안 테스트하는 것과 같다.
• 테스트를 베타 릴리스 간에 나눌 수 있다. 예를 들어 3.0.0-beta.2에서 5,000 사용자 시간을 테스트하고, 3.0.0-beta.5에서 5,000 사용자 시간을 테스트할 수 있다. 더 많은 테스트가 좋지만, 모든 베타 릴리스를 테스트할 수 없는 애플리케이션도 있다는 점을 이해한다.
• CI 또는 QA 시간은 총합에 포함되지 않는다. 하지만 내부 릴리스는 포함된다.

여러분의 Electron 앱이 참여해야 하는 이유​

여러분의 앱에서 발생하는 버그를 추적하고, 이를 Electron 코어 팀이 주시하게 된다. 여러분의 피드백은 Electron 팀이 새로운 베타 버전의 성능을 평가하고, 어떤 작업이 필요한지 파악하는 데 도움을 준다.

내 애플리케이션 정보가 공개적으로 공유되나요? 누가 이 정보를 볼 수 있나요?​

아니요, 여러분의 애플리케이션 정보는 일반 대중에게 공유되지 않습니다. 정보는 App Feedback Program과 Electron Governance 멤버만 볼 수 있는 비공개 GitHub 저장소에 보관됩니다. 모든 멤버는 Electron의 행동 강령을 준수하기로 동의했습니다.

회원가입​

현재 제한된 수로 회원가입을 받고 있습니다. 관심이 있고 위 요구사항을 충족할 수 있다면, 이 폼을 작성해 주세요.