CapacitorJS 앱을 제대로 OTA 업데이트하는 방법

금요일 오후, 결제 관련 회귀 버그를 발견했습니다. 수정 사항은 이미 Capacitor 웹 레이어에 반영되었지만, App Store 심사 기간이 끝나려면 아직 사흘이나 남았습니다. Android 사용자는 더 빨리 새 패키지를 받을 수 있지만, 단순한 JavaScript 수정 사항 때문에 모든 고객에게 Native Build를 다시 설치하게 만드는 것은 매우 비효율적입니다.

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

CapacitorJS 팀에게 OTA가 중요한 이유
- 업데이터를 하나의 delivery pipeline으로 취급하세요
사전 요구 사항 및 Capgo Updater 설치하기
- 릴리스 빌드 전 검증하기
첫 OTA Bundle을 안전하게 배포하는 방법
- 대시보드를 릴리스 게이트로 활용하기
Channels, Rollouts 및 CI/CD 자동화
- CI와 프로모션 연결하기
테스트 전략 및 자동 롤백
- 서버 제어와 클라이언트 복구 분리하기
Signing, 보안 및 OTA의 한계
- 릴리스 계획에서 경계 설정하기
릴리스 전 운영 체크리스트
- upload 전 확인 사항
- 프로모션 진행 중 확인 사항

CapacitorJS 팀에게 OTA가 중요한 이유

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

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

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

업데이터를 딜리버리 파이프라인으로 취급하세요

프로덕션 환경 구축을 위한 명확한 순서는 다음과 같습니다:

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

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

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

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

사전 요구 사항 및 Capgo Updater 설치하기

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

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

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

npm install JavaScript 패키지와 native dependency를 추가합니다. npx cap sync 많은 분들이 건너뛰는 단계인데, 이 과정을 생략하면 native bridge가 연결되지 않습니다. JavaScript 레이어는 컴파일될 수 있지만, 런타임에서 설치된 바이너리에 없는 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 설정 오류가 보고되지 않아야 합니다.

첫 번째 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 또는 웹 릴리스 메타데이터를 변경하세요. 웹 전용 수정 사항인 경우 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가 이를 받을 자격이 있는지 보여줍니다.

릴리스 게이트로서 dashboard를 확인하세요

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

최소 native version: 어떤 가장 오래된 binary가 이 bundle을 실행할 수 있나요?
최대 native version: 의도적으로 제외된 최신 binary는 무엇인가요?
Channel: 어떤 사용자가 아티팩트를 확인할 수 있나요?
Rollout 비율: 해당 대상 사용자 중 얼마나 많은 비율이 받을 수 있나요?

프로덕션 노출 시작 시점: 5%, 그런 다음 확장에 필요한 검증 조건을 정의합니다. 다운로드 및 설치 성공 여부, 정상적인 콜드 스타트, 크래시 없는 세션, 변경된 플로우의 JavaScript 에러를 확인하세요. Capgo 대시보드에서 아티팩트 식별 정보와 배포 제어 항목을 함께 볼 수 있도록 유지하세요.

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

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

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

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

await CapacitorUpdater.notifyAppReady()

앱이 헬스 체크를 통과할 만큼 충분히 초기화된 후에만 readiness를 호출하세요. readiness가 확인되지 않으면 다음 콜드 스타트 시 자동 복구가 해당 번들을 실패로 처리할 수 있습니다. 이 안전장치는 프로덕션 사용자를 보호하지만, 불완전한 테스트가 배포 문제처럼 보이게 만들 수도 있습니다. 노출을 확대하기 전에 각 테스트 디바이스의 활성 번들과 시작 결과를 기록해 두세요.

Channels, Rollouts, CI/CD 자동화

Channels는 게시된 번들과 설치된 디바이스 사이의 라우팅 레이어이자 릴리스 게이트입니다. Staging 채널은 검증된 네이티브 바이너리를 가리켜야 하고, Beta 채널은 통제된 코호트에 제공해야 하며, Production은 이전 채널이 스모크 테스트를 통과한 후에만 배포를 진행해야 합니다.

명시적인 이름을 가진 스테이징 경로를 생성하세요:

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

해당 채널을 테스트 기기에서 사용하는 Native Build 버전과 일치시키세요. 테스터는 추가 플러그인이 포함된 로컬 개발 빌드나 다른 설정이 아닌, 실제 프로덕션에서 지원할 것과 동일한 바이너리를 실행해야 합니다. 스모크 테스트를 통과하면, 약간 다른 두 번째 번들을 업로드하는 대신 테스트 완료된 아티팩트를 그대로 프로덕션으로 승격(promote)시키세요.

채널 맵은 다음 위치에 있어야 하며, capgo.config.json 애플리케이션 code처럼 검토되어야 합니다. 채널 이름을 안정적으로 유지하고, 의도한 Native Build 호환 범위를 명시하며, 프로덕션 승격을 명시적인 CI 액션으로 만드세요. 배포와 기능 노출을 함께 관리하는 팀에게 이러한 피처 플래그 거버넌스 팁은 배포 권한과 사용자 대상 활성화를 분리하는 유용한 방법을 제공합니다.

승격(promotion) 프로세스를 CI에 연결하기

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

Pull Request: 웹 레이어를 빌드하고, 제한된 프리뷰 자격 증명으로 서명한 뒤, 임시 프리뷰 채널에 게시하세요. Pull Request가 종료되면 해당 채널을 삭제하거나 만료시키세요.
태그된 메인 릴리스: 유닛 테스트를 실행하고, 프로덕션 번들을 빌드하며, Native Build 버전 제약 조건을 검증한 뒤, 업로드하세요. 테스트 작업이 성공적으로 종료되었을 때만 프로덕션으로 승격하세요.

프로모션 명령은 다음과 같이 구성될 수 있습니다:

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

다음과 같이 단계별로 노출을 점진적으로 늘리세요: 25%, 50%, 100%와 같이,각 단계 사이에 CI 승인이나 모니터링된 작업을 배치합니다. 퍼센트와 명령은 제어 수단일 뿐, 안전을 보장하는 증거는 아닙니다. 빌드 성공은 번들이 구문적으로 유효하다는 것을 의미할 뿐입니다. 특정 Native Build 환경, 유지된 로컬 상태, 느린 네트워크 연결 또는 이전 세션에서 복구된 기기에서의 동작까지 보장하지는 않습니다.

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

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

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

테스트 전략 및 자동 롤백

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

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

CI bundle 테스트: 단위 테스트, 타입 체크, 린팅 및 프로덕션 웹 빌드를 실행합니다. 단순히 컴파일 단계에서 멈추지 말고, 변경된 결제, 인증, 네비게이션 및 데이터 지속성 경로를 직접 테스트하세요.
프라이빗 디바이스 채널: 이전 Native Build가 실행 중인 실기기로 프라이빗 채널을 구성합니다. 양쪽 플랫폼 모두 지원하며, 클린 설치, 업그레이드 설치 및 실제 저장된 상태를 포함하여 테스트하세요.
프로덕션 카나리(Canary): 소수의 대상 그룹으로 시작하며, 연결된 크래시 리포팅과 JavaScript 에러 알림을 활용합니다. 앱 시작 실패는 매우 긴급하게 처리해야 합니다. 영향을 받은 사용자가 앱 내 에러를 보고하는 code 단계에 도달하지 못할 수도 있기 때문입니다.

이 Capacitor OTA 테스트 가이드 테스트 메커니즘을 설명합니다. 운영 원칙은 간단합니다. 각 업데이트를 해당 업데이트가 보호하려는 대상인 네이티브 바이너리와 대조하여 테스트하는 것입니다.

서버 제어와 클라이언트 복구 분리

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

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

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

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

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

대규모 플릿 규모에서는 아주 작은 실패율로도 상당한 고객 지원 부하가 발생합니다. 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 배포 필요
애플리케이션 동작	JavaScript 로직, 라우팅, 유효성 검사 및 상태 관리	Native 플러그인 구현
프레젠테이션	CSS, HTML, 문구, 테마 토큰 및 호환 가능한 이미지 에셋	앱 아이콘 및 스플래시 리소스
플랫폼 액세스	이미 바이너리에 포함된 기능에 대한 기존 Capacitor 웹 레이어 호출	새로운 권한, 엔타이틀먼트 또는 네이티브 API
설정	호환 가능한 웹 설정 및 원격 콘텐츠 규칙	`Info.plist`, `AndroidManifest.xml`, 서명 ID
스토어 메타데이터	스토어 검토 대상 동작이나 버전 메타데이터를 변경하지 않는 경우	스토어 정책 관련 메타데이터 및 버전 번호 변경

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

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

릴리스 전 운영 체크리스트

릴리스 체크리스트는 저장소나 런북에 보관하며 한 페이지 이내로 유지하세요. 장애 발생 후에는 반드시 업데이트해야 합니다. 실제 장애 이후 추가된 제어 항목은 대개 다음 재발을 방지합니다.

upload 전 확인 사항

호환성 확인: bundle가 정확한 native binary를 대상으로 하는지, 사용 불가능한 plugin API를 호출하지 않는지 확인하세요.
아티팩트 점검: clean workspace에서 build를 수행하고, 생성된 파일을 검사하여 의도한 web 버전이 맞는지 확인하세요.
서명 보안 유지: CI에 필요한 secret과 key가 설정되어 있는지 확인하세요. logs를 통해 private 정보가 노출되지 않는지도 점검해야 합니다.
채널 검증: bundle를 할당하기 전에 staging, beta, production 매핑을 검토하세요.
복구 기능 보존: 이전의 정상적인 bundle를 기록해 두고, fallback 경로가 여전히 작동하는지 확인하세요.
실기기 스모크 테스트: 실제 기기에서 startup, login, checkout, navigation, persistence 및 update 준비 상태를 테스트하세요.

프로모션 진행 중

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

Crash-free 세션: 이전 bundle과 결과를 비교하여 회귀(regression)가 발생했는지 조사합니다.
JavaScript 에러율: bundle, native 버전, 플랫폼, 기능 경로별로 에러를 그룹화합니다.
Cold-start 동작: 활성화 후 시작 속도 변화가 있는지, 혹은 사용자가 빈 화면을 보게 되는지 확인합니다.
기능 커버리지: 원격으로 활성화된 기능이 해당 바이너리와 일치하는지 확인합니다.
채택 및 실패율: 업데이트를 확인하지 않은 대상 기기와, 확인했으나 실패한 기기를 구분하여 분석합니다.

프로모션 후 첫 관찰 기간을 30분 동안 유지한 뒤 노출 범위를 확대하세요. 만약 크리티컬 패스에 문제가 생기면, 프로덕션 채널을 이전 번들로 롤백하고 로그를 보존한 뒤, 수정 사항을 다른 OTA 번들에 포함할지 아니면 새로운 Native Build로 배포할지 결정해야 합니다.

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

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

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