Capgo 업데이트를 가볍고 빠르게 유지하는 방법

최고의 live update는 사용자가 거의 느끼지 못하는 것입니다.

이는 보통 세 가지를 의미합니다:

다운로드 크기가 작아야 합니다.
배포가 제어되어야 합니다.
문제가 생겨도 복구는 즉시 이루어집니다.

React Native에서 통용되는 “OTA를 가볍게 유지하라”는 조언은 Capgo에도 그대로 적용됩니다. 차이점은 Capgo이 Capacitor 팀에게 몇 가지 추가 제어 수단을 제공한다는 것입니다: 델타 업데이트, 채널, 자동 롤백, 버전 타겟팅, 그리고 선택 사항인 종단간 암호화(end-to-end encryption).

이 기능들을 함께 사용하면 페이로드가 작아지고, 설치가 빨라지며, 운영상의 번거로움도 훨씬 줄어듭니다.

MAU가 그대로여도 가벼운 번들이 중요한 이유

Capgo만의 유용한 세부 사항 하나: Capgo MAU는 사실상 지난 30일 동안 업데이트 서비스에 접속한 월간 활성 디바이스 수입니다.

따라서 번들 크기를 줄이는 것은 주로 MAU 집계를 낮추기 위한 꼼수가 아닙니다. 사용자와 팀이 실제로 체감하는 부분을 개선하기 때문에 중요합니다:

셀룰러 또는 Wi-Fi가 약한 환경에서 더 빠른 다운로드
더 나은 경험을 위한 직접 업데이트
실패하거나 롤백된 릴리스에서 대역폭 낭비 감소
릴리스 테스트 또는 스테이징 시 영향 범위 축소

Lean update의 핵심은 속도, 안전성, 운영 규율입니다.

1. Delta update를 기본으로 사용

딱 한 가지만 해야 한다면, 바로 이것입니다.

Capgo의 델타 업데이트 전체 웹 번들을 다시 다운로드하는 대신, 버전 간에 변경된 파일만 전송하세요. 이것이 일상적인 OTA 성능을 높이는 가장 확실한 방법입니다.

bun run build
bunx @capgo/cli@latest bundle upload --channel staging --delta

QA 검수가 완료되면:

bunx @capgo/cli@latest bundle upload --channel production --delta

CI 프로세스를 엄격하게 유지하려면 다음을 사용하세요: --delta-only 실수로 전체 번들을 업로드하는 일을 방지하려면:

bunx @capgo/cli@latest bundle upload --channel production --delta-only

Only use --delta-only 다음 명령어를 사용하세요. 플러그인 버전이 섞여 있는 경우, manifest 기반의 delta delivery를 지원하지 않는 구형 기기는 해당 업데이트를 다운로드할 수 없습니다.

다음 기능을 사용 중이라면 이 점은 더욱 중요합니다: directUpdate“업데이트 발견”부터 “앱 재실행”까지의 시간이 사용자에게 그대로 노출되기 때문입니다.

2. 에셋은 JavaScript 부하가 아닌 별도의 에셋으로 취급하세요

대용량 에셋은 OTA bundle 크기를 키우는 주범입니다.

몇 가지 실무적인 규칙을 소개합니다:

일반 에셋 파일로 충분하다면, 큰 이미지나 미디어를 JavaScript 안에 인라인으로 넣지 마세요.
자주 바뀌는 콘텐츠가 앱 bundle에 포함될 필요가 없다면, 자체 CDN이나 API를 활용하세요.
매 릴리스마다 교체되는 마케팅 이미지, onboarding 영상, 일회성 캠페인 에셋을 주의해서 관리하세요.
안정적인 에셋은 그대로 두세요. Delta update를 사용하면 변경되지 않은 파일은 다시 다운로드하지 않고 재사용됩니다.

이는 앱이 커져도 Capgo를 빠르게 유지하는 가장 쉬운 방법 중 하나입니다. 최악의 패턴은 아주 작은 UI 수정 때문에 사용자가 관련 없는 대량의 미디어를 다시 다운로드하게 만드는 것입니다.

3. 실제 네이티브 변경 사항은 Native Build로 처리하세요

Capgo는 HTML, CSS, JavaScript 및 런타임에 로드되는 에셋 등 웹 레이어를 업데이트합니다.

다음과 같은 경우에는 적합하지 않습니다:

새로운 네이티브 plugin 추가,
권한(permission) 변경,
capacitor.config.ts 변경 사항,
iOS 또는 Android 네이티브 프로젝트 상태를 수정하는 모든 작업입니다.

이 부분은 성능과도 직결됩니다. 대규모 구조적 변경 사항을 계속 OTA 경로로 밀어 넣으면, 시간이 갈수록 업데이트 전략이 무거워지고 위험해집니다.

의도적으로 두 개의 릴리스 경로를 사용하세요:

Native lane

플러그인 변경, 권한 변경 및 네이티브 설정의 경우:

bun run build
bunx cap sync

그다음 일반적인 스토어 릴리스를 진행하세요.

Capgo lane

안전한 웹 레이어 반복 개발을 위해:

bun run build
bunx @capgo/cli@latest bundle upload --channel production --delta

최근에 대용량 에셋을 많이 추가했다면 네이티브 베이스라인도 정기적으로 갱신하세요. 새로운 스토어 빌드를 통해 해당 베이스라인이 포함되면, 향후 Capgo diff 크기를 작게 유지할 수 있습니다.

4. 채널을 사용하여 롤아웃 규모를 작게 유지하기

“Lean” 업데이트는 단순히 메가바이트(MB)의 문제가 아닙니다. 업데이트가 안정적이라는 것을 확인하기 전까지 얼마나 많은 기기에 업데이트가 전달되는지의 문제이기도 합니다.

Capgo의 channel 시스템을 가장 깔끔한 제어 방법은 다음과 같습니다:

staging QA용
beta 초대된 테스터용
production 전체 사용자용
hotfix 긴급 복구용

간단한 워크플로우는 다음과 같습니다:

업로드 대상: staging.
실제 기기에서 검증합니다.
제한된 채널이나 퍼센트 기반 배포를 통해 점진적으로 출시합니다.
상태가 악화되면 즉시 롤백합니다.

If your app has multiple native baselines in the wild, pair channels with 버전 타겟팅이렇게 하면 호환되지 않거나 불필요하게 무거운 번들이 구버전 바이너리에 전달되는 것을 방지할 수 있습니다.

더욱 빠른 리뷰 루프를 원하는 팀을 위해, Capgo는 다음 작업에도 매우 효과적입니다. PR 프리뷰입니다이를 통해 제품 팀, QA, 이해관계자들이 새로운 TestFlight나 Play internal build를 기다리지 않고도 JS 전용 변경 사항을 테스트할 수 있습니다.

5. 직접 업데이트를 활성화했다면 시작 성능을 적극 최적화하세요

업데이트 적용 속도를 높이려면, 스타트업의 배포 프로세스가 더욱 체계적이어야 합니다.

Capgo의 업데이트 동작 방식 문서에서는 명시적으로 함께 사용할 것을 권장합니다 directUpdate Delta updates와 함께 사용하는 것이 가장 올바른 기본 설정입니다.

두 번째 안전장치는 notifyAppReady().

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

CapacitorUpdater.notifyAppReady()

앱이 기본 설정된 10초 이내에 ready 상태를 보고하지 않거나, notifyAppReady() window 또는 그 어떤 환경 내에서도 appReadyTimeout you set in your Capacitor config, Capgo can mark that bundle invalid and restore the previous good version. That rollback behavior is what you want in production, but it also means you should keep startup clean:

호출하세요 notifyAppReady() 적절한 위치에서
크리티컬 패스(critical path)에서 느린 부팅 작업 피하기
즉시 재로드되는 경우 앱 상태를 신중하게 저장하고 복구하기
광범위한 배포 전에 네트워크 불량 및 저사양 기기 시나리오 테스트하기

최근에 확인하지 않았다면, notifyAppReady 가이드를 다시 읽어볼 가치가 있습니다.

6. 불필요한 native rebuild 대신 내부 업데이트 채널을 사용하세요

많은 모바일 팀이 분명 웹 전용 변경 사항인데도 바이너리를 빌드하느라 시간을 낭비합니다.

변경 사항이 다음과 같다면:

카피,
UI 개선,
온보딩 플로우,
가격 화면 로직,
애널리틱스 연동,
피처 플래그,
프롬프트 또는 API 응답 렌더링,

그렇다면 Capgo 업데이트가 더 빠른 리뷰 산출물인 경우가 많습니다.

즉, 네이티브 재빌드와 TestFlight 반복 작업이 줄고 팀의 피드백 루프가 더 촘촘해집니다. Capgo의 가장 덜 활용되는 장점 중 하나는 네이티브/웹 경계를 허물지 않고도 더 많은 리뷰와 QA 작업을 OTA 레인으로 옮길 수 있다는 점입니다.

가이드: 단일 모바일 앱 ID로 스테이징하기 시간이 지나도 깔끔하게 관리하는 실무적인 방법을 소개합니다.

7. lean과 secret은 별개로 관리하세요

번들 크기를 줄이는 것과 보안을 강화하는 것은 서로 다른 문제입니다.

Channel은 배포 대상(eligibility)을 제어할 뿐, 그 자체로 번들을 비공개로 만들지는 않습니다.

더 강력한 배포 보장이 필요하다면:

활성화 Live Update 암호화,
사용하세요 커스텀 스토리지 또는 셀프 호스팅 배포를 고려하세요.,
프라이빗 키는 반드시 CI 또는 보안이 확보된 운영 워크플로우에만 보관해야 합니다.

그렇다고 업데이트 크기가 중요하지 않은 것은 아닙니다. 다음 두 가지 측면을 모두 최적화해야 합니다:

속도를 위한 경량화,
전송 제어를 위한 암호화,
배포 제어를 위한 채널,
복구를 위한 롤백.

실전형 “lean Capgo” 워크플로우

간단한 기본 운영 모델을 원한다면 다음 방식을 사용하세요:

Native Build와 OTA 릴리스 경로를 분리하세요.
다음 명령어로 JS 변경 사항을 upload 하세요: --delta 기본 설정입니다.
사용 staging 및 beta 이전 채널 production.
시청하기 업데이트 통계 및 로그 배포 전뿐만 아니라 배포 후에도.
Native Build가 필요 없는 경우, PR을 즉시 설치 가능한 프리뷰로 전환하세요.
용량이 크거나 변경이 잦은 미디어는 가급적 bundle에서 제외하세요.
에셋이 크게 늘거나 native 변경이 생기면 native baseline을 새로고침하세요.
배포 및 notifyAppReady() 롤백 동작을 릴리스 엔지니어링의 일부로 다루세요. 단순한 설정 작업이 아니라요.

이 조합은 흔한 “변경된 것만 그냥 upload” 방식보다 훨씬 오래 빠른 속도를 유지합니다.

마치며

Capgo 팀에게 “lean and fast”는 단순한 bundle 크기 문제가 아닙니다.

이건 릴리스 설계의 문제입니다.

페이로드 크기는 Delta updates로, 배포 규모는 channels로, 장애 대응은 rollbacks로 관리하세요. OTA를 그렇게 바라보면 앱과 팀, 사용자 기반이 커져도 업데이트는 계속 빠릅니다.

‘Capgo 업데이트를 가볍고 빠르게 유지하는 방법’에서 계속 읽기

사용 중이라면 Capgo 업데이트를 가볍고 빠르게 유지하는 방법 채널 라우팅과 단계적 배포를 계획하려면, 다음을 연결하세요: 채널 Channels의 구현 세부 사항은 다음을 참고하세요: 채널 Channels의 구현 세부 사항은 다음을 참고하세요: 채널 Channels의 구현 세부 사항은 다음을 참고하세요: Beta Testing 솔루션 Beta Testing 솔루션의 제품 워크플로우를 위한, 그리고 버전 타겟팅 솔루션 Version Targeting Solution의 제품 워크플로우용.