전자 앱 자동 업데이트: 실용적인 2026년 안내서

Electron 빌드를 배포하고 릴리스 페이지를 공개했지만, 커피 머신이 끝나기 전에 첫 번째 지원 티켓이 도착했다. 사용자는 앱이 업데이트를 찾지 못했다고 말했고, 다른 사용자는 업데이트를 다운로드했지만 설치할 수 없었다. 세 번째 사용자는 오래된 바이너리에서 인증 흐름이 깨진 채로 앱을 실행하고 있었는데, 로그에는 거의 NOTHING이 표시되었다.

그것은 Electron 앱 자동 업데이트 의 불편한 현실이다.. The updater API is only one component. A production release also depends on platform signing, transport policy, manifests, hosting, lifecycle events, observability, rollout controls, and a rollback path. Treat any one of those as optional and a routine patch can become an overnight incident.

2026년 2시의 업데이트 사고가 이 안내서를 시작했다.

• Electron 업데이터 경로를 선택하는 방법
• Main Process에서 자동 업데이트 흐름을 implement하는 방법
• 배포 대상 설정을 먼저 구성하라
  • 체크를 예약하고 라이프 사이클 이벤트를 노출하라
  • Renderer를 업데이트하도록 유지하면서 작업을 방해하지 말라
  • __CAPGO_KEEP_0__
• CI/CD를 위한 서명된 릴리스 및 매니페스트 구성
  • CI/CD를 위한 서명된 릴리스 및 매니페스트 설정
• 업데이트 롤아웃, 채널, 롤백 전략
  • 롤아웃, 채널 및 롤백 전략
• Use cohorts before broad exposure
  • 대규모 노출 이전에 코호트 사용
• Treating Auto-Update as a Security Control
  • 자동 업데이트 관리를 위한 보안 제어
  • Protect the metadata as carefully as the binary
  • 바이너리와 마찬가지로 메타데이터를 보호

The Production Update Runbook and Checklist

생산 업데이트 가이드북 및 체크리스트

2시 8분에 PagerDuty는 온콜 엔지니어에게 경보를 발령했습니다. 새로운 인증 흐름이 일부 배치에서 실패했고, 업데이트 받은 사용자는 로그인 완료가 불가능했습니다. 다른 사용자는 이전 버전을 유지했습니다. 업데이터는 아티팩트를 확인하거나 설치할 수 없기 때문입니다. 일부 고객은 깨진 릴리즈를 사용했고, 나머지 배치에서는 다른 버전을 사용했습니다. 릴리즈에 대한 명확한 설명이 없었습니다.

조사 결과는 5가지 항목을 확인했습니다.

1. 릴리즈 피드 확인 바이너리가 존재했지만, 기대되는 메타데이터가 명확하게 클라이언트가 받을지 여부를 정의하지 못했습니다. 릴리즈 PIPELINE과 설치된 클라이언트 간의 계약은 메타데이터 옵션입니다.
2. 인증 확인 릴리즈가 올바르게 서명되지 않았기 때문에, 영향을 받은 플랫폼에서 인증이 실패했습니다. 서명은 누락되거나 유효하지 않으면 배포를 차단해야 합니다.
3. 클라이언트 로그 비교 업데이트 오류는 중앙 전송에 도달하지 못했습니다. 애플리케이션은 이벤트를 삼키고 계속 실행했습니다. 팀은 신뢰할 수 있는 증거를 얻지 못했습니다.
4. 릴리즈 롤아웃 제어 확인 내부 채널이나 스테이지드 코호트가 없었습니다. 모든 적격 클라이언트가 동일한 피드를 사용했기 때문에, 실패가 퍼졌습니다. 격리 지점이 없었습니다.
5. 롤백 검색 팀은 이전 버전이나 깨진 릴리즈로부터 클라이언트를 방지하는 테스트된 절차가 없었습니다.

Electron의 공식 문서는 플랫폼의 제한 사항을 명확히 설명합니다. Linux에는 내장된 자동 업데이트 지원이 없습니다., macOS 업데이트를 요청하려면 App Transport Security 요구 사항을 충족해야 합니다. App Transport Security 요구 사항Electron autoUpdater 문서는 __CAPGO_KEEP_0__ 제약 조건을 정의합니다. 릴리스 시스템은 주변 운영 제어를 강제해야 합니다. API 제약 조건을 정의하며, 릴리스 시스템은 주변 운영 제어를 강제해야 합니다.

설명할 수 없는 업데이트기가 있는 경우 원격 설치 시도는 미리 테스트되지 않은 업데이트입니다. 이 비용은 엔지니어링 시간만큼 더 비쌌습니다.

고객들은 데스크톱 클라이언트에 대한 신뢰를 잃었고, 지원 팀은 불일치하는 동작을 설명해야 했으며, 팀은 업데이트 프로세스를 다시 구축해야했습니다.

자동 업데이트에 대한 비용은 엔지니어링 시간만큼 더 비쌌습니다. 자동 업데이트에 대한 비용은 엔지니어링 시간만큼 더 비쌌습니다. Electron 앱의 자동 업데이트

올바른 Electron 업데이터 경로 선택

2시가 넘으면 잘못된 업데이터 선택은 운영 문제가 됩니다. 네이티브 바이너리 업데이트에는 서명, 매니페스트, 설치 프로그램, 롤백이 포함됩니다. 렌더러 전용 자바스크립트 또는 CSS 변경은 다른 경로를 따릅니다. 호스팅 제약조건도 중요합니다: 작은 GitHub 호스팅 프로젝트에는 대기업 배포 서비스와 같은 릴리스 제어를 필요로 하지 않습니다.

electron-builder를 사용하는 프로젝트에서 서명된 아티팩트를 게시하는 경우 electron-updater __CAPGO_KEEP_0__의 Electron 업데이터 통합 Electron updater integration for Capgo 팀이 서명, 피드 가용성, 채널 정책, 롤아웃 제어, 모니터링을 소유하고 있기 때문에 __CAPGO_KEEP_0__의 Electron 업데이터 통합은 팀이 작은 통합을 원하는 경우에 적합합니다.

update-electron-app suits teams that want a small integration around GitHub Releases. It checks at startup and then on a recurring interval, which keeps the setup simple but leaves less room for advanced channel selection, staged traffic, and custom rollback rules. The package is reasonable for a small release process, provided GitHub Releases and its availability match your operational requirements.

릴리즈 인증, 테넌트 타겟팅, 감사 기록, 규제 배포 규칙이 구현 비용을 정당화할 때, 내부 피드나 하젤, 나츠와 같은 커스텀 서비스가 적합합니다. ongoing ownership의 대가입니다. 팀은 매니페스트 의미를 정의하고, 서명 키를 보호하고, 클라이언트 호환성을 유지하고, 실패한 다운로드, 거부된 릴리즈, 롤백 동작을 테스트해야 합니다.

라이브 업데이트는 렌더러만 업데이트할 수 있습니다. 네이티브 셸을 다시 빌드하지 않습니다. 이들은 Electron, 네이티브 모듈, 권한, 설치 프로그램 동작이 변경되었을 때 바이너리 업데이트를 대체하지 않습니다. electron-updater를 사용하세요. 커스텀 롤아웃 로직이 필요하지 않다면. 커스텀 로직이 필요하다면, 다운로드와 다이내믹 업데이트 동작을 재현하기보다Established 매니페스트와 아티팩트 convention을 따라서 빌드하세요. 팀이 압박 상황에서 관찰, 스테이지, 역전할 수 있는 신뢰할 수 있는 경로를 선택하세요.

메인 프로세스에서 Auto-Update Flow Implement

메인 프로세스는 업데이트를 확인하고 설치해야 합니다. 렌더러는 상태를 표시할 수 있지만, 실행 가능한 업데이트를 신뢰할지, 애플리케이션을 종료할지 결정해서는 안됩니다.

배포 대상 설정부터 시작하세요.

최소한의 electron-builder 구성은 다음과 같습니다.

{
  "build": {
    "appId": "com.example.desktop",
    "publish": [
      {
        "provider": "s3",
        "bucket": "example-electron-releases",
        "channel": "stable"
      }
    ],
    "nsis": {
      "oneClick": false,
      "allowToChangeInstallationDirectory": true
    }
  }
}

베타 및 스테이블 피드 분리 유지하십시오. 채널은 UI 레이블이 아닌 릴리스 정책입니다. 각 채널은 올바른 서명된 아티팩트 및 매니페스트로 해결되어야 합니다.

스케줄링을 통해 체크를 수행하고 라이프 사이클 이벤트를 노출하십시오.

호출 checkForUpdates() 만 시작 시 호출하는 것은 일반적인 프로덕션 오류입니다. 사용자는 애플리케이션을 열어두고 days가 될 수 있으므로 메인 프로세스는 제어된 간격과 오프라인 운영을 존중하는 재시도 전략이 필요합니다.

const { app, BrowserWindow, ipcMain } = require('electron');
const { autoUpdater } = require('electron-updater');

let mainWindow;
let isQuitting = false;
let retryDelay = 60 * 1000;

function sendUpdateStatus(status, payload = {}) {
  if (mainWindow && !mainWindow.isDestroyed()) {
    mainWindow.webContents.send('update-status', { status, ...payload });
  }
}

function scheduleUpdateCheck() {
  setTimeout(async () => {
    try {
      await autoUpdater.checkForUpdates();
      retryDelay = 60 * 1000;
    } catch (error) {
      sendUpdateStatus('error', { message: error.message });
      retryDelay = Math.min(retryDelay * 2, 30 * 60 * 1000);
    }
    scheduleUpdateCheck();
  }, retryDelay);
}

app.whenReady().then(() => {
  mainWindow = new BrowserWindow({
    webPreferences: {
      preload: require('path').join(__dirname, 'preload.js')
    }
  });

  autoUpdater.autoDownload = true;
  autoUpdater.autoInstallOnAppQuit = false;

  autoUpdater.on('checking-for-update', () => {
    sendUpdateStatus('checking');
  });

  autoUpdater.on('update-available', info => {
    sendUpdateStatus('available', { version: info.version });
  });

  autoUpdater.on('download-progress', progress => {
    sendUpdateStatus('progress', { percent: progress.percent });
  });

  autoUpdater.on('update-downloaded', info => {
    sendUpdateStatus('downloaded', { version: info.version });
  });

  autoUpdater.on('error', error => {
    sendUpdateStatus('error', { message: error.message });
  });

  autoUpdater.checkForUpdates().catch(error => {
    sendUpdateStatus('error', { message: error.message });
  });

  scheduleUpdateCheck();
});

ipcMain.handle('install-update', () => {
  isQuitting = true;
  autoUpdater.quitAndInstall(false, true);
});

app.on('before-quit', event => {
  if (!isQuitting) {
    return;
  }
});

업데이트 이벤트의 정확한 동작은 플랫폼 및 패키징 설정에 따라 다르므로 개발 모드가 아닌 설치된 아티팩트에서 테스트하십시오. Electron의 문서는 Windows에서 시작 시점에 대한 우려를 제시하며, Squirrel의 첫 번째 실행 경우를 포함합니다. 애플리케이션이 플랫폼에 특정한 초기화 작업을 완료하기 전에 업데이트 체크를 트리거하지 마십시오.

렌더러에게 정보를 제공하지 않고 작업을 방해하지 마십시오.

프리로드 브리지는 좁은 API를 노출해야 합니다:

const { contextBridge, ipcRenderer } = require('electron');

contextBridge.exposeInMainWorld('updates', {
  onStatus(callback) {
    ipcRenderer.on('update-status', (_event, status) => callback(status));
  },
  install() {
    return ipcRenderer.invoke('install-update');
  }
});

렌더러 쪽 진행 표시줄은 간단하게 유지할 수 있습니다:

window.updates.onStatus(status => {
  const progress = document.querySelector('#update-progress');
  const message = document.querySelector('#update-message');

  if (status.status === 'progress') {
    progress.hidden = false;
    progress.value = status.percent;
    message.textContent = `Downloading update, ${Math.round(status.percent)}%`;
  }

  if (status.status === 'downloaded') {
    message.textContent = `Version ${status.version} is ready to install`;
  }

  if (status.status === 'error') {
    message.textContent = 'The update could not be downloaded. We will retry later.';
  }
});

설치 작업을 사용자 동의에 따라 제어하십시오. 즉시 재시작해야 하는 강력한 이유가 없는 경우 프로덕션에서. isQuitting flag를 설정하기 전에 quitAndInstall(), 일반적으로 창 닫기 핸들러가 설치자가 작업을 가져올 수 있도록 방해하지 않도록 하십시오.

두 실패는 명시적인 테스트가 필요합니다. 첫 번째로, 이미 실행 중인 클라이언트는 checkForUpdates() CI/CD를 위한 서명된 릴리스와 매니페스트 연결 error 릴리스 PIPELINE은 사용자가 설치하는 릴리스의 참조가 되는 소스이다. 개발자의 한 명의 머신에서 작동하는 로컬 빌드는 발행된 바이너리, 매니페스트, 서명, 채널이 동일한 릴리스를 설명하는지 증명하지 않는다. Electron-builder의 릴리스 모델은 릴리스 메타데이터와 업데이트를 목표로 함께 전송한다. 많은 구성에서, 이는 윈도우즈와 macOS에 대한 각각의 아티팩트, 플랫폼별 패키지, 블록맵 파일과 함께 전송된다. 매니페스트가 누락된 경우, 완벽한 유효한 바이너리는 클라이언트에게 보이지 않는다. 서명이 명시적이 되도록 CI를 구성하라

간단한 __CAPGO_KEEP_0__ Actions 패턴은 다음과 같다:

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__ latest.yml __CAPGO_KEEP_0__ latest-mac.yml __CAPGO_KEEP_0__

__CAPGO_KEEP_0__

GitHub

name: release

on:
  push:
    tags:
      - "v*"

jobs:
  build:
    strategy:
      matrix:
        os: [macos-latest, windows-latest]
    runs-on: ${{ matrix.os }}

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 24
          cache: npm

      - run: npm ci
      - run: npm run test
      - run: npm run build

      - name: Build and publish
        shell: bash
        env:
          CSC_LINK: ${{ secrets.CSC_LINK }}
          CSC_KEY_PASSWORD: ${{ secrets.CSC_KEY_PASSWORD }}
          WIN_CSC_LINK: ${{ secrets.WIN_CSC_LINK }}
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        run: npx electron-builder --publish always

플랫폼에 특정한 비밀을 사용하고 서명 자료를 저장소 외부에 유지하세요. 서명 실패는 작업을 중단하고,有人 수동으로 업로드하는_unsigned fallback을 생성하지 않아야 합니다.

발행 설정은 공급자와 채널을 일관되게 식별해야 합니다:

{
  "build": {
    "publish": {
      "provider": "s3",
      "bucket": "example-electron-releases",
      "channel": "stable",
      "publishAutoUpdate": true,
      "updaterCacheDirName": "example-desktop-updater"
    }
  }
}

게시 전에 패키지 버전, 태그, 커밋 SHA, 스모크 테스트 결과에 따라 작업을 게이트링하세요. 게시 후, 피드에 예상되는 매니페스트가 포함되어 있고 매니페스트가 생성한 작업에 의해 생성된 정확한 아티팩트를 참조하는지 확인하세요. 연속적 통합 설정 가이드 이 가이드는 formalizing those checks를 formalizing those checks할 때 유용하고 pipeline orchestration을 비교하는 팀도 understanding을 이해하는 데 도움이 될 수 있습니다. Jenkins와 Ansible를 함께 사용할 때는 언제 사용해야 하나?.

자주 사용하는 명령어는 의도적으로 불완전한 릴리스를 노출한다:

npx electron-builder --publish never
test -f dist/latest.yml
test -f dist/latest-mac.yml
find dist -name "*.blockmap" -print

이 검사들은 서명된 설치 테스트를 대체하지 않습니다. 그러나 업로드한 바이너리가 클라이언트가 이를 발견할 수 있도록 필요한 메타데이터가 없는 경우에 발생하는 운영 오류를 잡을 수 있습니다.

롤아웃, 채널, 롤백 전략

릴리스 피드는 배포 대상보다 다운로드 폴더처럼 행동해야 합니다. 유지 내부, beta, 그리고 최신 채널은 각 채널이 자신의 매니페스트와 서명된 아티팩트 세트에 의해 지원되는 별개의 채널입니다. 승격은 테스트된 릴리스를 정책 간에 이동시키는 것이며, 클라이언트가 다운로드 중인 파일을 덮어쓰지 않습니다.

채널 분리는 실수로 테스트 빌드를 보호합니다. 업데이터는 클라이언트가 내부 그룹, 베타 대상자, 또는 안정적인 인구에 속하는지 여부를 평가하기 전에 그 클라이언트가 어느 그룹에 속하는지 알 수 있어야 합니다.

대중 노출 이전에 코호트를 사용하십시오

사용자 지정 매니페스트 필드는 스테이지 배포를 표현할 수 있습니다:

version: 4.8.0
path: Example-Setup-4.8.0.exe
sha512: signed-artifact-hash
rolloutPercentage: 10

메인 프로세스는 안정적인 사용자별 버킷을 assign하고, 그 버킷을 rolloutPercentage. 안정적인 assign이 중요합니다. 사용자가 매 체크마다 eligible와 ineligible 상태를 바꾸면, 불확실한 동작을 받고, 지원 보고서의 해석이 어렵게 됩니다.

릴리스가 살아남은 관찰 창구 이후에만 코호트를 확장하세요. 정확한 창구는 사용 패턴에 따라 반영되어야 하지만, 결정은 신호에 따라야 하며, 단순히 캘린더만에 의존해서는 안 됩니다. 업데이트 체크 결과, 다운로드 완료, 런처 건강, 충돌, 렌더러 예외, 인증 성공을 추적하세요.

롤백과 기존 아티팩트 삭제를 혼동하지 마십시오. 기존 클라이언트는 캐시된 메타데이터를 가지고 있으며 일부는 이미 문제 버전을 실행하고 있을 수 있습니다. 롤백 계획에는 이전에 서명된 릴리스, 피드 변경, 클라이언트가 회복할 수 있는 동작이 필요합니다.

운영 규칙: 롤백은 재빌드 없이 인콜 엔지니어가 실행할 수 있어야 합니다.

실제로, 런북은 영향을 받은 채널에 이전 릴리스 매니페스트를 승격시켜야 하며 스테이징 마커를 invalidate하고 새로운 체크가 안전한 버전으로 해결되는지 확인해야 합니다. 렌더링 code이 네이티브 셸보다 문제가 있다면 대상 웹层 롤백이 더 빠를 수 있습니다. 이러한 플랫폼은 Capgo phased 배포 그것은 별도의 배포 층에 대한 관련성이 있을 수 있지만, native 바이너리 롤백과 웹-배ंडल 롤백 사이의 경계를 가리는 것은 shouldn’t해야 한다.

자동 업데이트 관리를 보안 제어로 다루기

Electron 업데이트기는 실행 가능한 code 파일을 다운로드하고 사용자와의 상호 작용이 거의 필요한 경우에 설치할 수 있습니다. 그로 인해 업데이트 경로가 자동화되며 사용자에게 더 적은 인터랙션을 제공합니다. __CAPGO_KEEP_0__ 인증은 기초가지만 전체 신뢰 모델이 아니다. 모든 릴리즈를 인증하고 CI에서 인증서와 식별자를 검증하고 문서화된 키 회전 절차를 유지하라. macOS에서 인증과 hardened 런타임을 combination하고, Windows에서 인증서 소유권, 갱신, 빌드 접근을 감사하라. Linux에서는 Electron이 제공하는 빌트인 universal 업데이트가 없기 때문에 distribution-특정 전략이 필요하다., not merely a convenience feature. Electron’s official documentation describes platform constraints such as macOS ATS, and security coverage has documented a 2022 scenario in which attackers controlling update infrastructure could serve malicious packages that still passed code-signing checks, as discussed in the __CAPGO_KEEP_0__.

Code signing remains foundational, but it isn’t the whole trust model. Sign every release, verify the certificate and identity during CI, and maintain a documented key-rotation procedure. On macOS, combine signing with notarization and the hardened runtime appropriate to your application. On Windows, make certificate ownership, renewal, and build access auditable. Linux needs a distribution-specific strategy because Electron doesn’t provide a built-in universal updater there.

__CAPGO_KEEP_0__

__CAPGO_KEEP_0__

제공 컨트롤도 피드에 필요합니다.

• 프로덕션 제어를 위한 피드도 deserves: 게시 액세스를 제한하십시오:
• CI에 릴리즈 자산을 게시할 수 있는 권한만 부여하십시오. 서명 비밀을 보호하십시오:
• 인증서와 개인 키를 관리된 비밀 저장소에 보관하십시오. 저장소 파일에 저장하지 마십시오. 의존성을 고정하십시오:
• Electron, electron-builder 및 전이적 의존성을 CI에서 고정하십시오. 아티팩트를 검토하십시오:
• 생성된 패키지를 검사하고 의도한 커밋 및 버전과 비교하십시오. 안전한 전송을 요구하십시오:
• 감시 오류 실패: 반복된 서명 또는 매니페스트 실패를 보안 이벤트로 대우하지 말고 일반 네트워크 잡음으로 대우하라.

Electron의 유지 보수 도구 생태계는 패키징 및 업데이터 커버리지가 계속해서 추가되고 있지만 유지 보수는 위협 모델링의 필요성을 제거하지는 않는다. 실제적인 목표는 공격자가 버킷, CDN, 또는 빌드 단계를 해킹해도 클라이언트가 비인가된 릴리즈를 수용할 수 없도록 하기 위함이다. 위협 모델링은 공격자가 버킷, CDN, 또는 빌드 단계를 해킹해도 클라이언트가 비인가된 릴리즈를 수용할 수 없도록 하기 위함이다. 서명 확인 지침 서명 확인 지침은 추가적인 확인层를 설계하는 데 유용한 맥락을 제공한다.

프로덕션 업데이트 런북 및 체크리스트

릴리즈가 준비된 것은 다른 엔지니어가 압박하에 작동할 수 있는 때에야 한다. 체크리스트는 배포 작업과 인시던트 채널과 가깝게 유지해야 한다.

릴리즈 전 게이트

• 버전 식별: 패키지 버전, 릴리즈 태그, 커밋 SHA, 및 변경 로그가 일치하는지 확인하라.
• 서명: 모든 플랫폼 아티팩트가 서명되어 있고, 인증 또는 동등한 검증이 완료되었는지 확인하세요.
• 매니페스트 계약: 확인 latest.yml, latest-mac.yml업로드한 아티팩트의 해시, 경로 및 블록맵이 일치하는지 확인하세요.
• 채널 안전: 내부 또는 베타 피드에 먼저 릴리스 채널을 승격하기 전에 내부 또는 베타 피드에 게시하세요.
• 테러미터리: 업데이트 확인, 다운로드 진행, 설치 완료, 런칭 건강, 오류가 도착하는지 확인하세요.

캐니와 풀 롤아웃

• 코호트 제어: 내부 또는 베타 사용자로 시작하여 의도적으로 작은 내부 또는 베타 그룹으로 시작하세요.
• 건강 지출: 발표 실패, 다운로드 실패, 렌더러 예외, 또는 인증 실패가 팀 승인 한 한계를 넘어설 경우 프로모션을 유지하세요.
• 프로모션 승인: 정식 피드로 릴리스를 이동하기 전에 명확한 '진행' 또는 '중단' 의사결정을 요구하세요.
• 고객 영향: 넓은 배포 전에 지원 메시지를 준비하세요, 첫 번째 사고 이후에 아닙니다.

사고 대응

새 바이너리 실행이 실패하거나 프로세스 스폰이 중단되거나 다운로드가 완료되지 않으면 프로모션을 즉시 중단하세요. 이전에 서명된 매니페스트를 복원하고 스테이징 마커를 invalidate하고 새 클라이언트가 이전 버전으로 돌아가도록 확인하세요. 그런 다음 fresh 클라이언트가 이전 버전으로 돌아가도록 확인한 후 통계를 통해 배포가 회복되고 있는지 확인한 후 통계를 통해 통보하세요.

provider에 따라 정확한 롤백 명령은 달라지지만 시퀀스는 항상 문서화되어야 합니다: 이전 버전의 채널 매니페스트를 전환하고 스테이징 태그를 invalidate하고 회복이 필요하면 강제 업데이트 마커를 푸시하고 롤백 경로를 live 통계를 통해 확인하세요.테스트되지 않은 롤백은 단순히 희망입니다.

Capgo는 서명된 웹 레이어 변경, 대상 채널, 롤아웃 제어, 업데이트 관찰성 등 렌더러 변경에 따라 native shell을 재빌드하지 않고 제공합니다. native 바이너리 릴리스와 제어된 자바스크립트 및 CSS 전달을 분리하고 싶다면 visit Capgo 그것을 여러분의 기존 Electron 릴리스 PIPELINE과 함께 평가하세요.