CapacitorJS 앱을 올바르게 OTA 업데이트하는 방법

금요일 오후, 체크아웃에서 회귀 버그를 발견했습니다. 수정 사항은 이미 Capacitor 웹 레이어에 반영되어 있지만, App Store 심사는 3일 동안 끝나지 않습니다. Android 사용자는 새 패키지를 더 빨리 받을 수 있지만, JavaScript만 고친 것 때문에 모든 고객에게 네이티브 빌드를 다시 설치하게 하는 건 여전히 낭비입니다.

이것이 바로 팀들이 CapacitorJS 앱의 OTA 업데이트를 배우는 실질적인 이유입니다. 제어된 OTA 릴리스는 대상이 되는 설치된 바이너리에 서명된 웹 번들을 전달하고, 백그라운드에서 다운로드한 뒤 다음 실행 시 적용할 수 있습니다. 네이티브 변경 사항은 여전히 스토어 프로세스를 따릅니다. 어려운 점은 파일을 업로드하는 게 아닙니다. 라이브 환경의 전체 기기에서 버전 타겟팅, 서명, 롤아웃 제어, 관측성, 복구를 일관되게 유지하는 것입니다.

CapacitorJS 팀에게 OTA가 중요한 이유
- 업데이터를 배포 파이프라인으로 취급하세요
사전 요구 사항 및 Capgo 업데이터 설치
- 릴리스 빌드 전 검증하기
첫 OTA Bundle을 안전하게 배포하기
- 대시보드를 릴리스 게이트로 활용하기
채널, 롤아웃 및 CI/CD 자동화
- 승격을 CI에 연결하기
테스트 전략 및 자동 롤백
- 서버 제어와 클라이언트 복구를 분리하세요
서명, 보안 및 OTA가 바꿀 수 없는 것
- 릴리스 계획의 경계 설정하기
각 릴리스 전 운영 체크리스트
- 업로드 전
- 승격 중

CapacitorJS 팀에게 OTA가 중요한 이유

Capacitor 앱은 보통 두 가지 릴리스 레이어로 구성됩니다. 네이티브 바이너리는 플랫폼 셸, 권한, 플러그인, 아이콘, 권한 설정(entitlements) 및 스토어 심사를 거친 기타 기능을 포함합니다. 웹 레이어는 JavaScript, CSS, HTML, 라우팅, 카피 및 에셋을 포함합니다. OTA 업데이트는 두 번째 레이어를 다루므로, 변경 사항이 Capacitor의 Capgo OTA 가이드에서 설명하는 플랫폼 및 스토어 정책 범위를 벗어나지 않는다면, 네이티브 셸을 다시 빌드하지 않고도 결제 흐름 오류를 즉시 수정할 수 있습니다..

스토어 심사 지연과 즉각적인 수정 사항을 비교하여 OTA 업데이트의 중요성을 보여주는 다이어그램입니다.

운영 측면의 이점은 단순히 속도에만 있지 않습니다. 설치된 바이너리들은 모두 동일한 버전을 사용하지 않습니다. 어떤 사용자는 이전 네이티브 빌드를 실행 중이고, 다른 사용자는 최신 스토어 버전을 사용할 수 있으며, 각 바이너리마다 웹 번들에 제공되는 네이티브 API가 다를 수 있습니다. 지원되지 않는 네이티브 API를 대상으로 컴파일된 번들은 JavaScript diff가 유효하더라도 실패할 수 있습니다. 따라서 OTA는 릴리스 엔지니어링을 우회하는 지름길이 아니라, 호환성을 관리하는 시스템입니다.

업데이터를 배포 파이프라인으로 취급하세요

프로덕션 환경 구축을 위해서는 명확한 순서가 필요합니다:

네이티브 브릿지를 설치합니다: 업데이터 패키지를 추가하고 Capacitor를 동기화하여 iOS와 Android가 이를 인식하도록 합니다.
Bundle 서명: 서명 키는 저장소 외부에 보관하고, 클라이언트 경로에서 검증 프로세스를 거치도록 하세요.
채널 지정: staging, beta, production 또는 고객별 코호트에 맞춰 의도적으로 라우팅하세요.
배포 자동화: 테스트 통과 시에만 CI가 build, sign, upload 및 promote를 수행하도록 설정하세요.
채택 현황 모니터링: 채널 및 바이너리별로 download, install, boot, crash 및 상태 신호를 추적하세요.
신속한 롤백: 서버 측에서 검증된 번들을 복구하고, 클라이언트 측의 복구 보호 기능을 유지하세요.

Capgo는 이 워크플로우를 위한 최적의 옵션 중 하나입니다. 오픈 소스인 Capacitor updater와 클라우드 서비스를 통해 서명된 웹 번들을 지정된 채널에 게시하고, 다음 실행 시 적용하며, 버전 및 디바이스 레벨의 배포 정보를 제공합니다. 가용성과 릴리스 탄력성을 검토 중인 팀은 다음 내용도 확인해 보세요. Capacitor 애플리케이션의 앱 가용성.

실무 원칙: 번들이 어떤 native binary를 대상으로 하는지 식별할 수 없다면, 해당 번들을 production으로 배포하지 마세요.

OTA의 성공 여부는 web code와 native code 사이의 경계를 모호하게 만들지 않으면서, 불필요한 스토어 출시를 줄이는 데 있습니다. 핵심은 팀이 번들을 푸시할 수 있느냐가 아닙니다. 누가 번들을 받았는지, 왜 대상이 되었는지, 실행 후 어떤 일이 일어났는지, 그리고 번들에 문제가 생겼을 때 어떻게 서비스를 복구할 것인지 설명할 수 있느냐입니다.

사전 요구 사항 및 Capgo 업데이터 설치

터미널을 열기 전에 프로젝트와 release 계정이 준비되었는지 확인하세요. Capacitor 5 또는 6 애플리케이션과 @capacitor/cli 초기화된 Node 18 이상 버전, 대상 binary를 위한 활성화된 Apple Developer 및 Google Play Console 계정, 그리고 Capgo cloud 계정이 필요합니다. appId 및 API 키가 필요합니다.

첫 설치는 의도적으로 가볍게 구성되었습니다:

npm install @capgo/capacitor-updater
npx cap sync
npx @capgo/cli init

npm install JavaScript package와 native dependency를 추가합니다. npx cap sync 사람들이 자주 건너뛰는 단계인데, 이 과정을 생략하면 native bridge가 연결되지 않은 상태로 남게 됩니다. JavaScript 레이어는 컴파일될지 몰라도, 런타임에서 설치된 binary에 존재하지 않는 bridge를 호출할 수 있습니다. 설치 후, 그리고 native plugin 설정이 변경될 때마다 동기화를 실행하세요.

initializer는 사용자의 capacitor.config.ts 를 updater 설정, web endpoint, 기본 channel로 패치합니다. 패치를 무조건 수락하지 마세요. 파일을 열어 애플리케이션 identity와 update contract를 명시적으로 확인하세요:

const config: CapacitorConfig = {
  appId: 'com.example.app',
  appName: 'Example',
  version: '1.0.0',
  autoUpdate: true,
  updateUrl: '',
  capgo: {
    channel: 'staging'
  }
}

생성되는 구조는 프로젝트 및 CLI 버전에 따라 다를 수 있지만, 핵심적인 값은 동일합니다. appId 설치된 바이너리와 일치해야 하며, version Native Build 관계를 설명해야 합니다. autoUpdate 출시 정책을 반영해야 하며, updateUrl 바이너리가 신뢰하는 서비스를 가리켜야 하며, capgo 블록은 초기 채널을 식별해야 합니다.

릴리스 빌드 전 검증하기

Xcode나 Android Studio를 열기 전에 진단 명령을 실행하세요:

npx @capgo/cli doctor

정상 결과라면 CLI 사용 가능 여부, 프로젝트 설정 읽기 가능 여부, updater 패키지 감지 여부, 필수 앱 식별자 존재 여부, 인증을 통한 설정된 계정 접근 가능 여부가 확인되어야 합니다. native sync 누락, 앱 식별자 부재, 잘못된 updater 설정이 보고되어서는 안 됩니다.

스크린샷 출처: https://capgo.app/docs/img/cli-doctor.png

첫 Native Build는 의도적으로 밋밋하게 유지하세요. 실제 iOS 기기와 Android 기기에 설치하고, 네트워크에 연결된 상태로 실행하고, 종료했다가 다시 열어서 updater가 정상 시작 경로에 영향을 주지 않고 확인할 수 있는지 검증하세요. Capacitor updater 설치 워크플로우는 프로젝트 설정을 예상 플러그인 설정과 비교해야 할 때 유용합니다.

첫 OTA Bundle을 안전하게 배포하기

첫 bundle은 기능 출시가 아니라 릴리스 경로 테스트로 생각하세요. 아티팩트를 준비하기 전에 서명 키를 생성하거나 교체하세요:

npx @capgo/cli key create

Private key는 secrets manager에 보관하세요. 코드로 커밋하거나, 프로젝트 아카이브에 저장하거나, CI 출력 결과에 노출해서는 안 됩니다. Native trust path에는 public verification material만 필요합니다. 오직 signing job만 private key에 접근할 수 있어야 합니다.

다음의 JavaScript 측 버전을 변경하세요: package.json 또는 web release metadata를 변경하세요. 웹 전용 수정 사항인 경우 native version 필드는 그대로 두어야 합니다. OTA bundle은 native code를 추가하거나 설치된 binary에 선언된 기능을 변경할 수 없으므로, native version을 변경하면 호환성을 개선하는 대신 오히려 혼란을 초래할 수 있습니다.

서명된 artifact를 대상 channel에 upload 하세요:

npx @capgo/cli bundle upload --channel production

upload 성공은 서버가 요청을 수락했음을 의미할 뿐입니다. 명령어 출력 결과를 확인하여 bundle identifier, target native-version 제약 조건, signed checksum, 그리고 channel 할당이 올바른지 검증하세요. 이 필드들은 artifact를 식별하고, 현재 설치된 binary가 해당 bundle을 받을 자격이 있는지 보여줍니다.

대시보드를 릴리스 게이트로 활용하기

Bundle detail view에서 다음 네 가지 릴리스 관련 질문에 대한 답을 확인할 수 있어야 합니다:

최소 native version: 어떤 버전의 가장 오래된 binary까지 이 bundle을 실행할 수 있나요?
최대 Native Build 버전: 의도적으로 제외할 최신 바이너리는 무엇인가요?
Channel: 어떤 사용자가 이 아티팩트를 확인할 수 있나요?
Rollout 비율: 대상 사용자 중 몇 %에게 배포할까요?

다음 시점에 프로덕션 노출 시작: 5%, 이후 확장에 필요한 검증 지표를 정의합니다. 다운로드 및 설치 성공 여부, 정상적인 Cold Start, Crash-free 세션, 변경된 플로우에서의 JavaScript 에러를 확인하세요. Capgo dashboard에서 아티팩트 식별 정보와 배포 제어 항목을 한눈에 관리할 수 있습니다.

디버그 빌드를 사용하여 디바이스 경로를 테스트하세요. getCurrent() 활성 번들을 보고하며, notifyAppReady() 새 번들이 정상 상태에 도달했음을 확인합니다:

import { CapacitorUpdater } from '@capgo/capacitor-updater'

const current = await CapacitorUpdater.getCurrent()
console.log(current)

await CapacitorUpdater.notifyAppReady()

앱이 health check를 통과할 수 있을 만큼 충분히 초기화된 후에만 readiness를 호출하세요. readiness가 확인되지 않으면, 다음 cold start 시 자동 복구 기능이 해당 bundle을 실패로 처리할 수 있습니다. 이 안전장치는 프로덕션 사용자를 보호하지만, 불완전한 테스트를 배포 문제처럼 보이게 만들 수도 있습니다. 노출 범위를 넓히기 전에 각 테스트 기기의 active bundle과 startup 결과를 기록해 두세요.

채널, 롤아웃 및 CI/CD 자동화

Channel은 게시된 bundle과 설치된 기기 사이의 라우팅 레이어입니다. 또한 릴리스 게이트 역할도 합니다. staging channel은 검증된 native binary를 가리켜야 하며, beta channel은 제어된 코호트(cohort)에 제공되어야 합니다. production은 이전 channel에서 smoke test를 통과한 후에만 업데이트되어야 합니다.

명확한 이름을 가진 staging 경로를 생성하세요:

npx @capgo/cli channel create staging
npx @capgo/cli bundle assign <bundle-id> --channel staging

해당 channel을 테스트 기기에서 사용하는 native 버전으로 고정하세요. 테스터는 추가 플러그인이 있거나 설정이 다른 로컬 개발용 빌드가 아닌, 프로덕션에서 지원할 것과 동일한 binary를 실행해야 합니다. smoke suite를 통과하면, 약간 다른 두 번째 bundle을 업로드하는 대신 테스트를 마친 artifact를 그대로 프로모션하세요.

Channel map은 다음 위치에 있어야 하며, capgo.config.json 애플리케이션 code처럼 검토되어야 합니다. channel 이름을 안정적으로 유지하고, 의도한 native 호환성 범위를 명시하며, production 프로모션을 명시적인 CI 액션으로 만드세요. 배포 노출과 함께 기능 노출을 관리하는 팀에게는, 이러한 feature flag 관리 팁은 배포 권한과 사용자 대상 활성화를 분리하는 유용한 방법을 제공합니다.

승격을 CI에 연결하기

실용적인 GitHub Actions 설계에는 두 가지 경로가 있습니다:

Pull request: 웹 레이어를 빌드하고, 제한된 프리뷰 자격 증명으로 서명한 뒤, 임시 프리뷰 채널에 게시합니다. Pull request가 닫히면 해당 채널을 삭제하거나 만료시킵니다.
태그된 main 릴리스: 단위 테스트를 실행하고, 프로덕션 번들을 빌드하며, 네이티브 버전 제약 조건을 검증한 뒤 업로드합니다. 테스트 작업이 성공적으로 종료된 경우에만 프로모션을 진행합니다.

프로모션 명령은 다음과 같은 형태일 수 있습니다:

npx @capgo/cli bundle promote <bundle-id> \
  --to-channel production \
  --percent 5

다음과 같이 의도적으로 단계를 나눠 노출을 늘립니다: 25%, 50%, 100%, 각 단계 사이에는 CI 승인이나 모니터링 작업이 있습니다. 퍼센트와 명령은 제어 수단일 뿐 안전의 증거는 아닙니다. 빌드가 통과하면 번들의 구문이 유효하다는 것만 알 수 있습니다. 하지만 특정 네이티브 바이너리에서, 저장된 로컬 상태나 느린 연결, 또는 이전 세션에서 재개된 기기에서 어떻게 동작하는지는 알려주지 않습니다.

릴리스 경계: 웹 번들은 바이너리 호환성 범위 내에 있어야 합니다. 채널이 설치된 앱에 포함되지 않은 네이티브 API를 참조하는 code를 배포하는 우회로가 되어서는 안 됩니다.

각 번들을 빌드 시점의 정확한 Native Build 버전과 연결하여 TestFlight 및 Android 내부 트랙 빌드의 일관성을 유지하세요. Native Build가 변경되면 해당 버전에 맞춘 새 번들을 게시하거나 새로운 채널 매핑을 생성해야 합니다. Capgo GitHub Actions 통합 가이드 를 통해 이러한 정책을 반복 가능한 워크플로우 단계로 구현할 수 있습니다.

소프트웨어 채널 및 자동화의 3단계(Staging Channel, Pin Binary, CI/CD Auto-Deploy)를 보여주는 다이어그램입니다.

테스트 전략 및 자동 롤백

OTA 릴리스는 CI를 통과하더라도 활성화 후 실패할 수 있습니다. 실패 원인은 번들, Native Build, 기기에 저장된 상태 또는 네트워크 환경에 따라 다를 수 있습니다. 시뮬레이터는 화면 렌더링 여부는 확인할 수 있지만, 모든 설치된 바이너리를 검증하거나 시작 실패 시 정상적으로 복구되는지까지는 보여줄 수 없습니다.

다음 세 가지 테스트 단계를 활용하세요:

CI 번들 테스트: 단위 테스트, 타입 체크, 린트, 프로덕션 웹 빌드를 실행하세요. 컴파일에서 멈추지 말고 변경된 체크아웃, 인증, 네비게이션, 상태 저장 경로를 실제로 돌려보세요.
프라이빗 디바이스 채널: 이전 네이티브 바이너리를 실행하는 실제 기기로 프라이빗 채널을 채우세요. 두 플랫폼을 모두 커버하고, 클린 설치, 업그레이드 설치, 대표적인 저장 상태를 포함하세요.
프로덕션 카나리: 자격을 갖춘 소규모 그룹, 연결된 크래시 리포팅, JavaScript 에러 알림으로 시작하세요. 시작 실패는 긴급하게 다뤄야 합니다. 영향을 받은 사용자는 앱 내 에러를 보고하는 code에 아예 도달하지 못할 수 있기 때문입니다.

이 Capacitor OTA 테스트 가이드 테스트 메커니즘을 설명합니다. 운영 원칙은 간단합니다. 각 업데이트는 그것이 보호하려는 네이티브 바이너리를 기준으로 테스트하세요.

서버 제어와 클라이언트 복구를 분리하세요

서버 측 롤백은 새 다운로드를 중단합니다:

npx @capgo/cli channel set production --bundle <previous-id>

이는 대상 기기가 다음에 발견할 내용을 변경합니다. 이미 다운로드되었거나 활성화된 번들을 삭제하지 않으므로, 클라이언트 측에도 복구 제어 기능이 필요합니다. 업데이트 설정 시 검증된 폴백(fallback)을 유지하고, 정의된 시작 실패 조건 발생 시 복구하도록 구성하세요.

신뢰할 수 있는 복구 경로는 다음과 같습니다:

다운로드 실패 추적: 연결 문제와 잘못된 아티팩트를 구분합니다.
설치 실패 추적: 압축 해제, 검증 및 파일 시스템 문제를 감지합니다.
부팅 상태 추적: 활성화 후 앱이 정상적으로 사용 가능한 상태가 되는지 확인합니다.
자동 폴백(Fallback): 앱 시작이 반복적으로 실패할 경우, 이전에 검증된 번들로 복구합니다.
수동 에스컬레이션: 지원 및 엔지니어링 대응을 위해 디바이스와 번들 식별자를 보존합니다.

대규모 플릿(Fleet) 규모에서는 아주 낮은 실패율도 상당한 지원 부하를 초래합니다. OTA 업데이트 성공률이 99.95%라 하더라도, 기기 100만 대당 약 1,000건의 실패가 발생함을 의미합니다.이는 IoT 플릿을 위한 OTA 테스트 벤치마크. 동일한 자료에서는 30분 이내 롤백, 크래시율 0.1% 미만, 지원 범위 내 기기 98% 유지 등의 가드레일을 설명합니다. 이는 보편적인 수락 기준이 아닌 벤치마크 예시로 참고하십시오. 에러 예산(Error budget)은 앱의 리스크와 사용자 영향도에 따라 설정해야 합니다.

서명, 보안 및 OTA가 바꿀 수 없는 것

서명되지 않은 업데이트는 배포 엔드포인트를 공급망 공격(supply-chain attack)의 표적으로 만듭니다. TLS가 연결을 보호하지만, 클라이언트는 다운로드한 아티팩트가 승인된 릴리스 프로세스를 통해 생성되었는지, 전송 과정에서 교체되거나 변조되지 않았는지 반드시 확인해야 합니다.

업데이터 도구를 사용하여 Ed25519 키 쌍을 생성하세요. 개인 키는 CI secret에 저장하고, 공개 검증 키는 앱 빌드 시 Native Build 바이너리에 포함합니다. 클라이언트는 활성화 전 모든 번들을 검증해야 합니다. CLI 토큰은 환경 및 권한 범위에 따라 제한하고, upload 및 프로모션 로그를 유지하며, 프로덕션 작업에는 강력한 인증을 요구하세요.

키 로테이션을 단순한 설정 변경이 아닌 호환성 마이그레이션으로 취급하세요. 교체용 키를 생성하고, 기존 키와 새 공개 키를 모두 신뢰하는 Native Build를 배포한 뒤, 새 개인 키로 릴리스에 서명합니다. 호환되는 바이너리가 교체된 키를 채택한 후에만 기존 키를 제거하세요. 신뢰를 너무 일찍 제거하면 이전 바이너리가 유효한 업데이트를 수락하지 못하며, 탈취된 키를 무기한 신뢰하면 로테이션의 의미가 없습니다.

릴리스 계획의 경계 설정하기

OTA는 웹 레이어의 변경 사항을 처리합니다. 설치된 바이너리에 없는 기능이 필요한 변경 사항의 경우 Native Build가 필요합니다:

카테고리	OTA로 배포	Native Build 필요
애플리케이션 동작	JavaScript 로직, 라우팅, 유효성 검사 및 상태 관리	Native 플러그인 구현
프레젠테이션	CSS, HTML, 복사된 텍스트, 테마 토큰 및 호환 가능한 이미지 에셋	앱 아이콘 및 스플래시 리소스
플랫폼 액세스 권한	이미 바이너리에 포함된 기능에 대한 기존 Capacitor 웹 레이어 호출	새로운 권한, 엔타이틀먼트(entitlements) 또는 네이티브 API
설정	호환 가능한 웹 설정 및 원격 콘텐츠 규칙	`Info.plist`, `AndroidManifest.xml`, 서명 ID(signing identity)
스토어 메타데이터	스토어 심사 대상 동작이나 버전 메타데이터를 변경하지 않는 경우	스토어 정책 관련 메타데이터 및 버전 번호 변경

이 Capacitor updater code signing 문서 검증 모델에 대해 설명합니다. 변조 방지 감사 로그, 인증서 검증, TLS, 엄격한 액세스 제어 및 버전 스푸핑이나 키 유출에 대비한 조사 프로세스를 통해 이를 운영에 적용하세요.

설치된 네이티브 사용자 층이 점진적으로 변화하기 때문에 호환성 타겟팅은 여전히 중요합니다. Apple의 보고에 따르면 iOS 26을 사용하는 전체 활성 기기의 66%가 및 최근 4년 내 출시된 기기의 74%가 iOS 26을 사용 중이며,또 다른 보고서에서는 iOS 26 점유율을 사이클 후반부 전체 기기의 79%로, 이는 모바일 OTA 키 관리 연구. 이 수치들은 서로 다른 시점과 기기군을 대상으로 합니다. 결론은 일관됩니다. 성숙한 플랫폼이라도 모든 기기를 한 번에 업데이트할 수는 없습니다. 하나의 OTA 아티팩트가 전체 기기에 적합할 것이라 가정하지 말고, 네이티브 버전과 기능에 따라 번들을 할당하세요.

각 릴리스 전 운영 체크리스트

릴리스 체크리스트는 저장소나 런북에 한 페이지 분량으로 관리하세요. 장애 발생 후에는 반드시 업데이트해야 합니다. 실제 장애를 겪은 뒤 추가한 제어 장치는 재발을 방지하는 데 매우 효과적입니다.

업로드 전

호환성 확인: bundle이 대상 native binary와 정확히 일치하는지, 사용 불가능한 plugin API를 호출하지 않는지 검증하세요.
아티팩트 점검: 클린 워크스페이스에서 빌드하고, 생성된 파일을 검사하여 의도한 웹 버전이 맞는지 확인하세요.
서명 보안 유지: CI에 필요한 secret과 key가 제대로 설정되었는지 확인하세요. 로그를 통해 개인 정보나 보안 데이터가 노출되지 않도록 주의해야 합니다.
채널 검증: bundle을 할당하기 전에 staging, beta, production 매핑을 다시 한번 검토하세요.
복구 기능 유지: 이전의 정상 작동하던 bundle을 기록해 두고, 장애 시 fallback 경로가 여전히 작동하는지 확인하세요.
실제 기기에서 스모크 테스트 실행: 대표적인 기기들을 사용하여 앱 시작, 로그인, 결제, 네비게이션, 데이터 유지 및 업데이트 준비 상태를 테스트하세요.

승격 중

먼저 제한된 코호트에 배포한 후, 사용자 영향과 관련된 지표를 모니터링하세요:

Crash-free 세션: 이전 bundle과 결과를 비교하고 regression이 있는지 조사하세요.
JavaScript 에러율: bundle, native 버전, 플랫폼, 기능 경로별로 에러를 그룹화합니다.
Cold-start 동작: 활성화가 앱 시작 동작을 바꾸거나 사용자를 빈 화면에 남기는지 확인하세요.
기능 커버리지: 원격으로 활성화된 기능이 이를 수신하는 바이너리와 일치하는지 확인합니다.
적용 및 실패: 업데이트를 확인하지 않은 대상 기기와, 확인했으나 실패한 기기를 구분합니다.

프로모션 후 첫 관찰 기간을 30분 동안 유지한 뒤 노출 범위를 확대하세요. 핵심 경로가 깨지면 프로덕션 채널을 이전 번들로 되돌리고 로그를 보존한 뒤, 수정 사항을 다른 OTA 번들에 넣을지 새 네이티브 릴리스로 낼지 결정하세요.

배포 당일 수칙: Fallback 번들은 팀이 해당 식별자, 호환성 범위, 복구 명령어를 정확히 알고 있을 때만 유효합니다.

이 체크리스트를 공동 운영 code로 활용하세요. Capgo을 통해 서명된 번들 전달, 채널 타겟팅, 롤아웃 제어, 업데이트 히스토리 및 디바이스 레벨의 관측성을 확보할 수 있습니다. 다만 호환성 정책과 프로모션 결정은 여전히 팀의 책임입니다.

Capgo는 CapacitorJS 팀에게 채널, 단계적 배포, 롤백 보호, 릴리스 관측성을 갖춘 서명된 JavaScript, CSS, 설정, 에셋 업데이트를 위한 통제된 경로를 제공합니다. 다음 배포에 이 체크리스트를 적용하고, 스테이징 바이너리로 테스트한 뒤, Capgo 프로덕션 워크플로우에 적합한지 평가하세요.