Skip to main content

From native to JavaScript in Electron

· 8 min read

Electron에서 C++나 Objective-C로 작성된 기능이 어떻게 JavaScript로 전달되어 최종 사용자에게 제공되는지 알아보자.

Electron은 내부적으로 Node.js와 Chromium을 사용한다. Node.js는 C++로 작성된 코어 모듈을 JavaScript로 노출시키는 메커니즘을 제공한다. 이 과정에서 N-API(Node-API) 또는 Native Addons라는 기술을 활용한다.

  1. Native Addons 생성: C++로 작성된 코드를 Node.js가 이해할 수 있는 형태로 컴파일한다. 이를 위해 node-gyp라는 빌드 도구를 사용한다. 이 도구는 C++ 코드를 Node.js 바이너리와 호환되는 네이티브 모듈로 변환한다.

  2. JavaScript 바인딩: 컴파일된 네이티브 모듈을 JavaScript에서 사용할 수 있도록 바인딩한다. 이를 통해 C++ 함수를 JavaScript 함수처럼 호출할 수 있다.

  3. Electron 통합: 이렇게 생성된 네이티브 모듈을 Electron 애플리케이션에 통합한다. Electron은 Node.js 런타임을 포함하고 있기 때문에, 네이티브 모듈을 JavaScript 코드에서 직접 사용할 수 있다.

  4. 최종 사용자에게 노출: JavaScript로 래핑된 기능은 Electron 애플리케이션의 API로 제공된다. 이를 통해 최종 사용자는 JavaScript를 통해 C++ 또는 Objective-C로 구현된 기능을 사용할 수 있다.

이 과정을 통해 Electron은 하위 수준의 기능을 JavaScript로 쉽게 노출시킬 수 있다. 이를 통해 개발자는 복잡한 네이티브 코드를 직접 다루지 않고도 강력한 기능을 구현할 수 있다.

배경

Electron은 플랫폼별 구현에 신경 쓰지 않고도 강력한 데스크톱 앱을 개발할 수 있도록 도와주는 JavaScript 플랫폼이다. 그러나 내부적으로 Electron은 여전히 플랫폼별 기능을 시스템 언어로 작성해야 한다.

실제로 Electron은 네이티브 코드를 직접 처리해 주기 때문에 개발자는 단일 JavaScript API에만 집중할 수 있다.

그렇다면 이 과정은 어떻게 작동할까? C++이나 Objective-C로 작성된 Electron의 기능이 어떻게 JavaScript로 전달되어 최종 사용자에게 제공될까?

이 경로를 추적하기 위해 app 모듈부터 시작해 보자.

lib/ 디렉토리 안에 있는 app.ts 파일을 열면 상단에 다음과 같은 코드를 찾을 수 있다:

const binding = process.electronBinding('app');

이 코드는 Electron이 C++/Objective-C 모듈을 JavaScript에 바인딩해 개발자가 사용할 수 있도록 하는 메커니즘을 직접 가리킨다. 이 함수는 ElectronBindings 클래스의 헤더와 구현 파일에 의해 생성된다.

process.electronBinding

이 파일들은 Node.js의 process.binding과 유사하게 동작하는 process.electronBinding 함수를 추가한다. process.binding은 Node.js의 require() 메서드의 저수준 구현체로, JS로 작성된 다른 코드 대신 네이티브 코드를 require할 수 있게 해준다. 이 커스텀 process.electronBinding 함수는 Electron에서 네이티브 코드를 로드할 수 있는 기능을 제공한다.

최상위 자바스크립트 모듈(예: app)이 이 네이티브 코드를 요청할 때, 해당 네이티브 코드의 상태는 어떻게 결정되고 설정되는가? 메서드와 프로퍼티는 어떻게 자바스크립트에 노출되는가?

native_mate

현재 이 질문에 대한 답은 native_mate에서 찾을 수 있다. native_mate는 Chromium의 gin 라이브러리를 포크한 것으로, C++과 JavaScript 간의 타입 변환을 더 쉽게 만들어준다.

native_mate/native_mate 디렉토리 안에는 object_template_builder에 대한 헤더 파일과 구현 파일이 있다. 이 파일들은 네이티브 코드에서 JavaScript 개발자가 기대하는 형태로 모듈을 구성할 수 있게 해준다.

mate::ObjectTemplateBuilder

모든 Electron 모듈을 object로 본다면, object_template_builder를 사용해 이를 구성하려는 이유를 더 쉽게 이해할 수 있다. 이 클래스는 V8 위에 구축되어 있다. V8은 Google이 C++로 개발한 오픈소스 고성능 JavaScript 및 WebAssembly 엔진이다. V8은 JavaScript(ECMAScript) 사양을 구현하므로, 네이티브 기능 구현을 JavaScript 구현과 직접적으로 연결할 수 있다. 예를 들어, v8::ObjectTemplate은 전용 생성자 함수와 프로토타입 없이 JavaScript 객체를 제공한다. 이는 Object[.prototype]을 사용하며, JavaScript에서는 Object.create()와 동등하다.

이를 실제로 확인하려면 app 모듈의 구현 파일인 atom_api_app.cc를 살펴보자. 파일 하단에는 다음과 같은 코드가 있다.

mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
.SetMethod("getGPUInfo", &App::GetGPUInfo)

위 코드에서 .SetMethodmate::ObjectTemplateBuilder 인스턴스에 호출된다. .SetMethodObjectTemplateBuilder 클래스의 모든 인스턴스에서 호출할 수 있으며, JavaScript의 Object 프로토타입에 메서드를 설정한다. 사용법은 다음과 같다.

.SetMethod("method_name", &function_to_bind)

이는 JavaScript에서 다음과 동등하다.

function App{}
App.prototype.getGPUInfo = function () {
// implementation here
}

이 클래스는 또한 모듈에 속성을 설정하는 함수를 포함한다.

.SetProperty("property_name", &getter_function_to_bind)

또는

.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)

이것은 JavaScript의 Object.defineProperty 구현과 동등하다.

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
get() {
return _myProperty
}
})

그리고

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
get() {
return _myProperty
}
set(newPropertyValue) {
_myProperty = newPropertyValue
}
})

개발자가 기대하는 대로 프로토타입과 속성으로 구성된 JavaScript 객체를 생성할 수 있으며, 이 낮은 시스템 수준에서 구현된 함수와 속성에 대해 더 명확히 이해할 수 있다!

주어진 모듈 메서드를 어디에 구현할지 결정하는 것은 복잡하고 종종 비결정적인 문제이다. 이에 대해서는 추후 게시글에서 다룰 예정이다.

Electron Governance

· 5 min read

Electron이 데스크톱 애플리케이션 분야에서 인기를 얻으면서, 이를 개발하는 팀도 함께 성장했다. 다양한 회사에서 일하고, 다른 시간대에 살며, 다양한 관심사를 가진 풀타임 메인테이너들이 늘어났다. 우리는 원활한 성장을 위해 새로운 거버넌스 구조를 도입하고 있다.

왜 변화가 필요한가?

Electron 프로젝트는 전 세계 여러 시간대에서 활동하는 자원봉사자, 전임 관리자, 그리고 Electron에 의존하는 여러 기업과 함께 협력한다. 지금까지는 비공식적인 조정 방식으로 잘 운영해 왔지만, 팀 규모가 커지면서 이 방식이 더 이상 확장 가능하지 않다는 사실을 깨달았다. 또한 새로운 기여자들이 프로젝트에서 자신의 위치를 쉽게 찾을 수 있도록 하는 것도 중요하다.

작업 그룹

Electron의 거버넌스는 프로젝트의 다양한 부분을 담당하는 작업 그룹으로 구성된다. 현재 총 7개의 그룹이 운영 중이다:

  • 커뮤니티 & 안전: 행동 강령 관련 문제를 처리한다.
  • 문서 & 도구: 외부용 도구(예: Fiddle, Forge)와 Electron 문서를 관리한다.
  • 외부 협력: Electron 커뮤니티의 성장을 돕는다.
  • 릴리즈: 안정적이고 일정에 맞춰 릴리즈가 진행되도록 보장한다.
  • 보안: 보안 테스트를 수행하고 보안 문제에 대응한다.
  • 업그레이드: V8, Chromium, Node의 새로운 버전과 같은 업스트림 업그레이드를 통합한다.
  • 웹사이트: Electron 웹사이트를 유지 및 개선한다.

이 그룹들은 서로 협력하지만, 각자 독립적으로 생산적인 활동을 위해 고유의 회의 일정과 의제를 가지고 있다. 이 그룹들에 대한 자세한 내용은 거버넌스 저장소에서 확인할 수 있다.

이 변경 사항이 Electron 프로젝트의 방향에 직접적인 영향을 미치지는 않는다. 우리의 전략이 성공한다면, 워킹 그룹은 새로운 기여자들이 관심 있는 주제를 더 쉽게 찾을 수 있게 도울 것이며, 메인테이너들의 일상 업무와 관련 없는 논의를 다른 그룹으로 옮겨 그들의 삶을 더 단순하게 만들 것이다. 이러한 변화가 일어나면, 더 많은 사람들이 방해받지 않고 함께 작업함으로써 간접적으로 영향을 미칠 수 있다.

더 알아보기

Chromium FileReader Vulnerability Fix

· 2 min read

Chrome에서 심각도가 높은 취약점이 발견되었으며, 이는 Electron을 포함한 모든 Chromium 기반 소프트웨어에 영향을 미친다.

이 취약점은 CVE-2019-5786로 지정되었다. 자세한 내용은 Chrome 블로그 포스트에서 확인할 수 있다.

Chrome은 이 취약점이 실제로 악용되고 있다는 보고를 받았으므로, 가능한 한 빨리 Electron을 업그레이드할 것을 강력히 권장한다.

범위

이 내용은 제3자나 신뢰할 수 없는 자바스크립트를 실행할 수 있는 모든 Electron 애플리케이션에 영향을 미친다.

보안 대응

이 취약점의 영향을 받는 애플리케이션은 패치된 Electron 버전으로 업그레이드해야 한다.

이 취약점을 해결한 새로운 Electron 버전을 다음과 같이 공개했다:

Electron 5의 최신 베타 버전은 Chromium 73을 기반으로 하므로 이미 패치가 적용된 상태다:

추가 정보

이 취약점은 Google 위협 분석 그룹의 Clement Lecigne가 발견했으며, Chrome 팀에 보고했다. 관련 Chrome 블로그 글은 여기에서 확인할 수 있다.

Electron 앱의 보안을 유지하기 위한 모범 사례를 더 알고 싶다면 보안 튜터리얼을 참고한다.

Electron에서 취약점을 발견했다면 security@electronjs.org로 이메일을 보내면 된다.

32비트 리눅스 지원 중단

· 5 min read

Electron 팀은 Electron v4.0부터 32비트 리눅스(ia32 / i386) 지원을 중단한다. 32비트 리눅스를 지원하는 마지막 버전은 Electron v3.1이며, 이 버전은 Electron v6가 출시될 때까지 지원 릴리스를 받을 예정이다. 64비트 리눅스와 armv7l에 대한 지원은 기존과 동일하게 유지된다.

정확히 어떤 부분을 더 이상 지원하지 않는가?

여러분은 컴퓨터에 붙어 있거나 소프트웨어를 다운로드할 때 "64비트"와 "32비트"라는 설명을 본 적이 있을 것이다. 이 용어는 특정 컴퓨터 아키텍처를 설명하기 위해 사용된다. 1990년대와 2000년대 초반에 제작된 대부분의 컴퓨터는 32비트 아키텍처 기반의 CPU를 사용했지만, 이후 제작된 컴퓨터는 더 새롭고 강력한 64비트 아키텍처를 기반으로 했다. 닌텐도 64와 플레이스테이션 2가 이 새로운 아키텍처를 탑재한 최초의 대중적인 소비자 기기였으며, 2010년 이후 판매된 컴퓨터는 거의 모두 64비트 프로세서를 사용했다. 결과적으로 32비트에 대한 지원이 점점 줄어들고 있다. 구글은 2016년 3월에 32비트 리눅스용 크롬 배포를 중단했고, 캐노니컬은 2017년에 32비트 데스크톱 이미지 제공을 중단한 후 우분투 18.10에서 32비트 지원을 완전히 중단했다. 아치 리눅스, 엘리멘터리 OS 등 주요 리눅스 배포판도 이미 오래된 32비트 프로세서 아키텍처에 대한 지원을 중단했다.

지금까지 Electron은 오래된 32비트 아키텍처에서 실행되는 빌드를 제공하고 지원해 왔다. 하지만 버전 4.0부터 Electron 팀은 더 이상 32비트 리눅스용 바이너리나 지원을 제공할 수 없다.

Electron은 항상 활발한 오픈 소스 프로젝트였으며, 특수 아키텍처용 Electron 빌드에 관심 있는 개발자들을 계속 지원하고 격려할 것이다.

개발자에게 이 변화가 어떤 의미를 가지는가?

현재 리눅스용 32비트 버전 앱을 제공하지 않는다면, 별도의 조치가 필요하지 않다.

32비트 리눅스용 Electron 애플리케이션을 배포하는 프로젝트는 앞으로의 전략을 결정해야 한다. Electron 3은 Electron 6 출시까지 32비트 리눅스를 지원한다. 이는 개발자들이 결정을 내리고 계획을 세울 수 있는 시간적 여유를 제공한다.

이 내용이 사용자에게 어떤 의미인가?

리눅스 사용자라면 현재 64비트 기반 시스템인지 확실하지 않을 수 있다. 대부분의 경우 64비트 기반 아키텍처를 사용하고 있을 가능성이 높다. 이를 확인하려면 터미널에서 lscpu 또는 uname -m 명령어를 실행해보면 된다. 둘 중 하나를 실행하면 현재 아키텍처를 확인할 수 있다.

만약 32비트 프로세서에서 리눅스를 사용 중이라면, 최근 출시된 소프트웨어를 찾는 데 어려움을 겪었을 것이다. Electron 팀은 리눅스 커뮤니티의 다른 주요 멤버들과 함께 64비트 기반 아키텍처로 업그레이드할 것을 권장한다.

BrowserView window.open() 취약점 수정

· 2 min read

Node.js를 자식 윈도우에서 다시 활성화할 수 있는 코드 취약점이 발견되었다.

sandbox: true 또는 nativeWindowOpen: truenodeIntegration: false 옵션으로 BrowserView를 열면, window.open을 호출할 수 있는 webContents가 생성된다. 이때 새로 열린 자식 윈도우에서는 nodeIntegration이 활성화된다. 이 취약점은 현재 지원되는 모든 Electron 버전에 영향을 미친다.

취약점 완화

이 취약점을 해결한 새로운 버전의 Electron을 출시했다. 해당 버전은 다음과 같다: 2.0.17, 3.0.15, 3.1.3, 4.0.4, 그리고 5.0.0-beta.2.

모든 Electron 개발자는 가능한 한 빨리 최신 안정 버전으로 앱을 업데이트할 것을 권장한다.

어떤 이유로든 Electron 버전을 업그레이드할 수 없는 경우, 모든 하위 웹 콘텐츠를 비활성화해 이 문제를 완화할 수 있다:

view.webContents.on('-add-new-contents', (e) => e.preventDefault());

추가 정보

이 취약점은 PalmerAL에 의해 발견되어 Electron 프로젝트에 책임감 있게 보고되었다.

Electron 애플리케이션의 보안을 유지하기 위한 모범 사례에 대해 더 알고 싶다면 보안 튜토리얼을 참고한다.

Electron에서 취약점을 발견하고 보고하려면 security@electronjs.org로 이메일을 보낸다.

Node.js Native Addons and Electron 5.0

· 3 min read

Electron 5.0에서 네이티브 Node.js 애드온을 사용하는 데 문제가 있다면, 최신 버전의 V8과 호환되도록 업데이트가 필요할 수 있다.

v8::Handle 작별, v8::Local 환영

2014년, V8 팀은 로컬 핸들에 대해 v8::Handle 대신 v8::Local을 사용하도록 변경했다. Electron 5.0에는 v8::Handle이 완전히 제거된 V8 버전이 포함되어 있으며, 여전히 v8::Handle을 사용하는 네이티브 Node.js 애드온은 Electron 5.0에서 사용하기 전에 업데이트해야 한다.

필요한 코드 변경은 최소한이지만, 여전히 v8::Handle을 사용하는 모든 네이티브 Node 모듈은 Electron 5.0에서 빌드에 실패하며 수정이 필요하다. 다행히 Node.js v12도 이 V8 변경 사항을 포함할 예정이므로, v8::Handle을 사용하는 모듈은 Node의 새 버전과 호환되려면 어쨌든 업데이트해야 한다.

네이티브 애드온을 유지보수한다면 어떻게 도울 수 있을까?

Node.js용 네이티브 애드온을 유지보수하고 있다면, v8::Handle을 모두 v8::Local로 교체해야 한다. v8::Handle은 단순히 v8::Local의 별칭이었기 때문에, 이 특정 문제를 해결하기 위해 다른 변경 사항은 필요하지 않다.

또한 N-API를 살펴보는 것도 도움이 될 수 있다. N-API는 V8과 별도로 유지보수되며, Node.js 자체의 일부로 제공된다. 이 API는 네이티브 애드온이 기본 JavaScript 엔진의 변경 사항으로부터 격리될 수 있도록 설계되었다. 더 자세한 정보는 Node.js 웹사이트의 N-API 문서에서 확인할 수 있다.

도움! 내 앱에서 네이티브 애드온을 사용하는데 작동하지 않아요!

앱에서 Node.js용 네이티브 애드온을 사용 중이고, 이 문제로 인해 네이티브 애드온이 빌드되지 않는다면, 애드온 제작자에게 문의해 문제를 해결한 새 버전이 출시되었는지 확인해 보세요. 아직 해결된 버전이 없다면, 제작자에게 직접 문의하거나 Pull Request를 열어 수정을 제안하는 것이 가장 좋은 방법입니다.

Electron v5.0.0 Timeline

· 3 min read

Electron은 처음으로 v5.0.0부터 시작해 공개적인 릴리스 일정을 발표하게 되어 기쁘게 생각한다. 이는 장기적인 공개 타임라인을 갖추기 위한 첫 번째 단계다.


v4.0.0 안정 버전 릴리스 블로그 포스트에서 언급했듯이, 우리는 Chromium 릴리스와의 간격을 좁히기 위해 약 3개월마다 릴리스할 계획이다. Chromium은 매우 빠른 속도로 새 버전을 출시한다. 6주마다 새로운 버전이 나온다.

Electron과 Chromium의 진행 상황을 나란히 비교해 보자:

Electron과 Chromium 버전을 비교한 선 그래프

2018년 후반, 우리의 최우선 과제는 더 빠르게 릴리스하고 Chromium에 더 가까이 따라잡는 것이었다. 우리는 미리 정해진 타임라인을 고수함으로써 이 목표를 달성했다. Electron 3.0.0과 4.0.0은 각각 2-3개월 간격으로 릴리스되었다. 우리는 5.0.0 및 그 이후 버전에서도 이 속도를 유지할 수 있을 것이라고 낙관한다. 이제 주요 Electron 릴리스는 약 3개월마다 이루어지며, Chromium의 릴리스 속도와 거의 동일하다. Chromium 안정 버전보다 앞서는 것은 항상 우리의 목표이며, 이를 위해 노력하고 있다.

Node.jsChromium처럼 미래의 정확한 날짜를 약속하고 싶지만, 아직 그 단계에는 이르지 못했다. 우리는 미래에 장기적인 타임라인을 확보할 수 있을 것이라고 낙관한다.

이러한 점을 고려하여, 우리는 v5.0.0의 릴리스 일정을 공개적으로 게시하는 첫 번째 단계를 밟고 있다. 이는 여기에서 확인할 수 있다.

베타 버전 테스트와 안정화를 돕기 위해, 앱 피드백 프로그램에 참여해 주시길 바란다.

Electron 4.0.0

· 11 min read

Electron 팀은 Electron 4의 안정 버전 출시를 기쁘게 발표한다! electronjs.org에서 설치하거나 npm install electron@latest 명령어를 통해 npm으로 설치할 수 있다. 이번 릴리스는 다양한 업그레이드, 수정 사항, 그리고 새로운 기능으로 가득 차 있다. 여러분이 이를 활용해 어떤 것을 만들어낼지 기대된다. 이번 릴리스에 대한 자세한 내용은 계속 읽어보고, 탐색하면서 얻은 피드백을 공유해 주기 바란다!

새로운 기능

Electron의 기능 대부분은 Chromium, Node.js, V8이라는 핵심 컴포넌트에서 제공된다. 따라서 Electron 팀의 주요 목표는 이러한 프로젝트의 변화를 최대한 빠르게 반영해, Electron 앱을 개발하는 개발자들이 새로운 웹과 자바스크립트 기능을 활용할 수 있도록 하는 것이다. 이를 위해 Electron 4에서는 각 컴포넌트의 주요 버전이 업그레이드되었다. Electron v4.0.0은 Chromium 69.0.3497.106, Node 10.11.0, V8 6.9.427.24를 포함한다.

또한 Electron 4에는 Electron 전용 API의 변경 사항도 포함되어 있다. 아래에서 Electron 4의 주요 변경 사항을 확인할 수 있다. 전체 변경 사항은 Electron v4.0.0 릴리스 노트에서 확인할 수 있다.

remote 모듈 비활성화

보안상의 이유로 remote 모듈을 비활성화할 수 있다. BrowserWindowwebview 태그에 대해 이 모듈을 비활성화할 수 있다:

// BrowserWindow
new BrowserWindow({
webPreferences: {
enableRemoteModule: false
}
})

// webview 태그
<webview src="http://www.google.com/" enableremotemodule="false"></webview>

더 자세한 정보는 BrowserWindow<webview> 태그 문서를 참고한다.

remote.require() / remote.getGlobal() 요청 필터링

이 기능은 렌더러 프로세스나 webview에서 remote 모듈을 완전히 비활성화하지 않고도, remote.require를 통해 어떤 모듈을 요청할 수 있는지 추가적으로 제어하고 싶을 때 유용하다.

렌더러 프로세스에서 remote.require를 통해 모듈을 요청하면, app 모듈에서 remote-require 이벤트가 발생한다. 이 이벤트의 첫 번째 인자에서 event.preventDefault()를 호출하면 해당 모듈이 로드되는 것을 막을 수 있다. 요청이 발생한 WebContents 인스턴스는 두 번째 인자로 전달되며, 요청된 모듈의 이름은 세 번째 인자로 전달된다. 동일한 이벤트가 WebContents 인스턴스에서도 발생하지만, 이 경우에는 이벤트와 모듈 이름만 인자로 전달된다. 두 경우 모두 event.returnValue를 설정하여 커스텀 값을 반환할 수 있다.

// 모든 WebContents에서 `remote.require` 제어:
app.on('remote-require', function (event, webContents, requestedModuleName) {
// ...
});

// 특정 WebContents 인스턴스에서 `remote.require` 제어:
browserWin.webContents.on(
'remote-require',
function (event, requestedModuleName) {
// ...
},
);

비슷한 방식으로, remote.getGlobal(name)이 호출되면 remote-get-global 이벤트가 발생한다. 이 이벤트는 remote-require 이벤트와 동일하게 작동한다: preventDefault()를 호출하여 글로벌 값이 반환되는 것을 막을 수 있으며, event.returnValue를 설정하여 커스텀 값을 반환할 수 있다.

// 모든 WebContents에서 `remote.getGlobal` 제어:
app.on(
'remote-get-global',
function (event, webContents, requrestedGlobalName) {
// ...
},
);

// 특정 WebContents 인스턴스에서 `remote.getGlobal` 제어:
browserWin.webContents.on(
'remote-get-global',
function (event, requestedGlobalName) {
// ...
},
);

더 많은 정보는 다음 문서를 참고한다:

About 패널에 JavaScript로 접근하기

macOS에서는 app.showAboutPanel()을 호출해 프로그램적으로 About 패널을 표시할 수 있다. 이 기능은 {role: 'about'}로 생성한 메뉴 항목을 클릭하는 것과 동일하게 동작한다. 더 자세한 정보는 showAboutPanel 문서를 참고한다.

WebContents 백그라운드 스로틀링 제어

WebContents 인스턴스는 페이지가 백그라운드 상태일 때 타이머와 애니메이션의 스로틀링을 활성화하거나 비활성화할 수 있는 setBackgroundThrottling(allowed) 메서드를 제공한다.

let win = new BrowserWindow(...)
win.webContents.setBackgroundThrottling(enableBackgroundThrottling)

더 자세한 내용은 setBackgroundThrottling 문서를 참고한다.

주요 변경 사항

macOS 10.9 지원 중단

Chromium이 더 이상 macOS 10.9(OS X Mavericks)를 지원하지 않기 때문에, Electron 4.0 이상 버전도 이를 지원하지 않는다.

단일 인스턴스 잠금

이전에는 앱을 단일 인스턴스 애플리케이션으로 만들기 위해(앱의 한 인스턴스만 실행되도록 보장) app.makeSingleInstance() 메서드를 사용할 수 있었다. Electron 4.0부터는 app.requestSingleInstanceLock() 메서드를 대신 사용해야 한다. 이 메서드의 반환 값은 현재 애플리케이션 인스턴스가 잠금을 성공적으로 획득했는지 여부를 나타낸다. 잠금 획득에 실패했다면, 이미 다른 인스턴스가 잠금을 가지고 실행 중이라고 간주하고 즉시 종료하면 된다.

requestSingleInstanceLock() 사용 예제와 다양한 플랫폼에서의 세부 동작에 대한 정보는 app.requestSingleInstanceLock() 및 관련 메서드 문서second-instance 이벤트 문서를 참고한다.

win_delay_load_hook

윈도우용 네이티브 모듈을 빌드할 때, 모듈의 binding.gyp 파일에 있는 win_delay_load_hook 변수는 반드시 true로 설정해야 한다(기본값이 true임). 이 훅이 없으면 윈도우에서 네이티브 모듈을 로드할 수 없으며, Cannot find module과 같은 오류 메시지가 나타난다. 자세한 내용은 네이티브 모듈 가이드를 참고한다.

지원 중단 예정 기능

다음과 같은 주요 변경 사항은 Electron 5.0에서 적용될 예정이며, 따라서 Electron 4.0에서는 지원 중단(deprecated)으로 표시된다.

nativeWindowOpen으로 열린 윈도우에서 Node.js 통합 비활성화

Electron 5.0부터 nativeWindowOpen 옵션을 사용해 열린 자식 윈도우에서는 항상 Node.js 통합이 비활성화된다.

webPreferences 기본값

webPreferences 옵션을 설정하여 새로운 BrowserWindow를 생성할 때, 다음 webPreferences 옵션의 기본값은 아래에 나열된 새로운 기본값으로 대체되었다.

속성더 이상 사용되지 않는 기본값새로운 기본값
contextIsolationfalsetrue
nodeIntegrationtruefalse
webviewTagnodeIntegration 값이 설정된 경우 그 값을 사용, 그렇지 않으면 truefalse

참고: 현재 contextIsolation이 활성화된 상태에서 webview 태그가 작동하지 않는 알려진 버그 (#9736)가 있다. 최신 정보는 GitHub 이슈를 확인하자.

컨텍스트 격리, Node 통합, webview 태그에 대한 더 자세한 내용은 Electron 보안 문서를 참고하자.

Electron 4.0에서는 여전히 현재의 기본값을 사용하지만, 명시적인 값을 전달하지 않으면 더 이상 사용되지 않는다는 경고가 표시된다. Electron 5.0을 대비하려면 이러한 옵션에 명시적인 값을 사용해야 한다. 각 옵션에 대한 자세한 내용은 BrowserWindow 문서를 참고하자.

webContents.findInPage(text[, options])

medialCapitalAsWordStartwordStart 옵션은 상위 스트림에서 제거되었기 때문에 더 이상 사용되지 않는다.

앱 피드백 프로그램

Electron 3.0 개발 과정에서 도입한 앱 피드백 프로그램이 성공적이었기 때문에, 4.0 개발 과정에서도 이 프로그램을 계속 진행했다. Atlassian, Discord, MS Teams, OpenFin, Slack, Symphony, WhatsApp 및 다른 프로그램 멤버들에게 4.0 베타 기간 동안의 참여에 대해 깊은 감사를 표한다. 앱 피드백 프로그램에 대해 더 알아보고 향후 베타 테스트에 참여하려면 프로그램에 관한 블로그 포스트를 확인해보기 바란다.

다음 단계

단기적으로, 팀은 Chromium, Node, V8 등 Electron을 구성하는 주요 컴포넌트의 개발 속도를 따라잡는 데 계속 집중할 계획이다. 출시 일정에 대한 약속은 신중하게 하겠지만, 대략 분기별로 이러한 컴포넌트의 새 버전과 함께 Electron의 새로운 주요 버전을 출시할 예정이다. Electron의 버전 관리에 대한 더 자세한 정보는 버전 관리 문서를 참고한다.

다가오는 Electron 버전에서 예정된 주요 변경 사항에 대한 정보는 예정된 주요 변경 사항 문서를 확인한다.

SQLite Vulnerability Fix

· 2 min read

원격 코드 실행 취약점인 "Magellan"이 발견되었다. 이 취약점은 SQLite나 Chromium 기반의 소프트웨어에 영향을 미치며, Electron의 모든 버전도 포함된다.

적용 범위

Web SQL을 사용하는 Electron 애플리케이션이 영향을 받는다.

대응 방안

영향을 받는 앱은 Web SQL 사용을 중단하거나 패치된 버전의 Electron으로 업그레이드해야 한다.

이 취약점을 해결한 새로운 버전의 Electron을 출시했다:

현재까지 실제 사례는 보고되지 않았지만, 영향을 받는 애플리케이션은 반드시 대응 조치를 취해야 한다.

추가 정보

이 취약점은 Tencent Blade 팀에 의해 발견되었다. 이 팀은 해당 취약점에 대해 논의한 블로그 포스트를 공개했다.

Electron 앱의 보안을 유지하기 위한 모범 사례에 대해 더 알고 싶다면 보안 튜토리얼을 참고한다.

Electron에서 발견한 취약점을 보고하려면 security@electronjs.org로 이메일을 보낸다.

Electron App Feedback Program

· 5 min read

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의 행동 강령을 준수하기로 동의했습니다.

회원가입

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