자주 묻는 질문

이 플러그인의 설치 단계와 전체 마크다운 가이드가 포함된 설정 프롬프트를 복사하세요.

여기에 답이 없는 질문이 있다면 언제든 물어보세요! issue를 등록하거나 Discord에서 질문하셔도 됩니다.

“code push”란 무엇인가요?

“over-the-air updates”(OTA)라고도 불리는 Code push는 Capacitor 개발자가 프로덕션 앱에 업데이트를 배포할 수 있게 해주는 클라우드 서비스입니다. Capgo는 현재 Android, iOS, Electron을 지원합니다.

“Code Push”는 React Native 커뮤니티에서 사용하는 배포 기능 이름을 참조한 것으로, Microsoft 및 Expo, 둘 다 Capacitor를 지원하지 않습니다.

Capgo CLI 메이저 버전이 제 플러그인이나 Capacitor 버전과 일치해야 하나요?

아니요. 항상 최신 Capgo CLI을 사용하세요 (npx @capgo/cli@latest). CLI 및 Capgo Console은 자체 버전 관리 방식을 따르며, 지원되는 모든 updater plugin 메이저 버전과 호환됩니다. Capgo 플러그인은 Capacitor 메이저 버전을 따릅니다. 다음을 참조하세요: Capgo 버전 관리 다음과 같은 LTS 태그는 @lts-v7.

bundle과 release의 차이점은 무엇인가요?

저희는 앱 스토어용 바이너리를 준비하는 과정을 “release”라고 부릅니다. 나중에 bundle을 생성하려면 Capgo가 앱 스토어에 배포된 정확한 바이너리를 알고 있어야 합니다.

저희는 release를 새로운 code로 업데이트하기 위해 적용할 수 있는 패치를 “bundle”이라고 부릅니다. npx @capgo/cli@latest bundle upload 명령어는 새 로컬 code에서 bundle을 생성한 뒤 사용자에게 배포하는 데 사용됩니다.

Delta update 파일 경로에 제한이 있나요?

네:

0바이트 파일: CLI 로그는 Ignoring empty file... delta 파일에서 빈 파일을 제외합니다. upload를 실패시키지는 않으므로, 빈 파일이 배포를 중단시키지 않고 결과 bundle을 변경할 수 있습니다. Delta bundle 경로에 0바이트 파일을 포함하지 마세요.
공백이 있는 경로: Delta upload는 bundle 경로에 공백이 있으면 명확한 에러와 함께 바로 실패합니다. Delta update를 upload하기 전에 파일이나 디렉토리 이름에서 공백을 제거하세요.

자세한 내용은 델타 업데이트 설정 세부 정보를 확인하세요.

로드맵이 어떻게 되나요?

프로젝트 보드도 공개되어 있으며, 다음에서 확인하실 수 있습니다: https://github.com/orgs/Cap-go/projects

저희 팀은 공개적인 방식으로 협업하므로, 언제든 진행 중인 작업을 확인하실 수 있습니다. 로드맵이나 우선순위에 대해 궁금한 점이 있다면 Github issue를 통해 문의해 주세요. Discord에서.

팀원들과 함께 Capgo를 사용할 수 있나요?

네! 모든 플랜은 무제한 개발자를 지원합니다. 각 조직별로 앱 메트릭(MAU, 스토리지 및 대역폭)에 대해서만 제한이 적용됩니다.

자세한 내용은 팀 자세한 내용은 여기를 참고하세요.

Capgo가 제 소스 code를 저장하나요?

아니요. Capgo 서버는 사용자의 소스 code를 절대 볼 수 없습니다. 실행하면 npx @capgo/cli@latest bundle upload, Capgo는 minify/컴파일된 code의 zip 파일을 저장합니다. 이는 브라우저가 받는 것과 동일한 code이며, 사용자의 소스 code가 아닙니다.

보안을 강화하려면 두 가지 옵션이 있습니다:

종단 간 암호화: 번들을 업로드하기 전에 암호화하면 저장 및 전송 중에 보호되고, 제3자가 개인 키 없이 유효한 암호화 업데이트를 생성하는 것을 막을 수 있습니다. 다만 배포된 앱에 공개 키가 포함되어 있으므로, 배포된 웹 에셋의 리버스 엔지니어링을 불가능하게 만들지는 않습니다.
외부 URL 업로드: 번들을 자체 서버에 저장하고 Capgo에 다운로드 링크만 제공하는 옵션도 있습니다. --external <url>

개인정보 처리방침도 확인해 보세요: https://capgo.app/privacy

bundle 파일은 비공개 데이터인가요?

아니요. 번들 파일은 앱 사용자가 다운로드하도록 만들어진 공개 웹 에셋입니다. 번들 URL을 아는 사람이라면 누구나 해당 파일을 가져올 수 있으며, Capgo는 설정 과정과 문서를 통해 이 점을 사용자에게 안내합니다.

번들 파일에 대한 접근은 데이터 유출로 간주되지 않습니다. 앱 번들에 시크릿, 자격 증명, 개인 데이터 또는 규제 대상 데이터를 넣지 마세요. 보안 요구가 높은 사용 사례에서 더 강력한 기밀성이 필요하다면 종단 간 암호화를 사용하되, 보안 신고 관점에서는 배포된 앱의 code와 에셋을 여전히 공개 데이터로 취급해야 합니다.

CI 시스템에서 Capgo를 사용할 수 있나요?

네. Capgo는 CI 시스템에서 사용하도록 만들어졌습니다. 관련 가이드도 게시해 두었습니다. Android 및 Github 액션 및 iOS, 및 GitLab. 다른 CI 시스템도 유사하게 작동합니다.

문제가 발생하면 GitHub 이슈나 Discord를 통해 언제든 문의해 주세요.

Firebase Remote Config나 LaunchDarkly와는 어떻게 다른가요?

Code push를 사용하면 기기에 새로운 code을 추가하거나 code를 교체할 수 있습니다. Firebase Remote Config와 Launch Darkly는 모두 설정(configuration) 시스템입니다. 앱의 새 버전을 배포하지 않고도 설정을 변경할 수 있게 해줍니다. 이들은 code을 대체하기 위한 도구가 아닙니다.

의존성 크기는 얼마나 늘어나나요?

최근에 직접 측정해 보지는 않았지만, code push 라이브러리가 Capacitor 앱에 추가하는 용량은 1MB 미만일 것으로 예상합니다. 용량 최적화가 우선순위가 되면 크기를 더 줄일 수 있는 방법을 알고 있습니다. 만약 용량 문제가 걸림돌이 된다면 저희에게 알려주세요!

Capgo가 iOS 18.4 Simulator에서 작동하나요?

아니요. iOS 18.4 시뮬레이터 자체의 이슈로 인해 Capgo가 해당 환경에서 안정적으로 실행되지 않습니다. 실제 기기에서 테스트하거나 다른 iOS 시뮬레이터 버전을 사용해 주세요.

React Native 이슈 상세 내용: facebook/react-native#50510

code push가 대규모 앱에서도 작동하나요?

네. code push를 통해 업데이트할 수 있는 애플리케이션 크기에는 제한이 없습니다. 명시된 바와 같이 참조), Capgo는 앱의 크기와 관계없이 모든 JS code를 변경할 수 있습니다.

참고: 앱 크기가 커지면 사용자의 업데이트 다운로드가 어려워질 수 있습니다. 앱 크기를 최대한 작게 유지하는 것을 권장합니다.

Capgo code push를 어떤 용도로 사용할 수 있나요?

다음과 같은 다양한 활용 사례가 있습니다:

운영 중인 앱의 긴급 수정 사항 반영.
구버전 앱을 사용하는 사용자에게 버그 수정 사항 배포.
지속적인 업데이트 배포 (예: 매시간).

대부분의 앱 스토어는 앱의 동작을 크게 변경하는 code 배포를 금지하고 있으니 주의하세요. 자세한 내용은 참조) 자세한 내용은 여기를 참고하세요.

Capgo의 “MAU” 기준은 무엇인가요?

MAU는 Monthly Active Device를 의미합니다. 30일 동안 Capgo에 접속한 고유 디바이스를 해당 native app ID 기준 1 MAU로 집계합니다. 동일한 물리적 디바이스라도 서로 다른 두 개의 native app ID에서 사용된다면 각 app ID별로 1회씩 집계되며, 앱 간 중복 제거는 이루어지지 않습니다.

flavours의 차이가 웹 레이어나 업데이트 라우팅에만 있다면, 다음을 사용하여 채널 하나의 native app ID를 사용하세요. 이렇게 하면 flavours를 하나의 Capgo 앱으로 관리할 수 있어 릴리스가 간편해집니다. 만약 flavour마다 별도의 bundle ID, signing identity, entitlement set 또는 스토어 등록 정보가 필요하다면 각각 별도의 native app ID를 사용해야 합니다.

iOS에서는, v7.25.0+ Keychain을 통해 일반적인 재설치 시에도 앱 범위의 랜덤 디바이스 ID를 유지합니다. Android의 경우 v7.50.1+ (또는 v5.50.1+ 및 v6.50.1+ 해당 릴리스 라인에서); ID는 Android Backup/Restore가 앱 환경설정을 유지할 때만 복원됩니다. 백업을 비활성화하거나 해당 환경설정을 제외하거나 앱 데이터를 지우면 새 device ID가 생성됩니다. 앱을 업데이트해도 새 device ID는 생성되지 않습니다.

테스트 및 개발용 빌드의 경우 프로덕션 채널에서 개발 빌드 및 에뮬레이터 배포를 꺼두세요. 이는 배포를 제어할 뿐 MAU를 제어하는 것은 아닙니다. 기기가 Capgo에 접속하면 여전히 집계될 수 있습니다. 프로덕션 사용량에 포함되지 않게 하려면 Live Updates를 비활성화하고 프로덕션 Capgo 엔드포인트를 호출하지 마세요. 정확한 설정은 Live Updates 없이 Native Build 테스트하기 참고하세요.

Capgo code push를 사용할 수 없는 경우는 언제인가요?

Capgo는 Java, Kotlin, Objective-C, Swift, native plugin, native configuration 등 native code를 변경할 수 없습니다. 이런 변경에는 새로운 native 앱 출시가 필요합니다. 스토어 심사 범위는 다음을 참고하세요: App Store 및 Google Play 정책.

Capgo을 통해 capacitor.config.ts 변경 사항을 업데이트할 수 있나요?

아니요. 간단한 규칙: Capgo는 HTML, CSS, JavaScript, assets, 그리고 해당 출력물에 번들된 순수 JavaScript package 변경 사항을 포함한 생성된 web build 폴더를 전송할 수 있습니다. 다음의 변경은: capacitor.config.ts, native plugin configuration, native package installs or upgrades, and anything that must update the iOS or Android project through npx cap sync 또는 npx cap copy native 앱 출시가 필요합니다.

Capacitor 설정 파일은 native build 시점에 읽히고 native 앱 바이너리로 컴파일됩니다. Capacitor 설정을 변경해야 한다면 다음을 수행해야 합니다:

업데이트 capacitor.config.ts 로컬에서
네이티브 앱 재빌드 (npx cap sync 이후 네이티브 build 진행)
새 바이너리를 앱 스토어에 제출

Capgo가 대신 스토어에 제출해 주나요?

Capgo Build는 준비된 네이티브 iOS 또는 Android 프로젝트를 컴파일 및 서명할 수 있으며, 설정 시 서명된 결과물을 App Store Connect 또는 Google Play에 제출할 수 있습니다. 프라이빗 의존성, 웹 빌드, Capacitor sync 및 커스텀 네이티브 준비 작업을 위해 기존 CI를 그대로 유지할 수 있습니다. Capgo는 네이티브 build 단계를 위해 준비된 네이티브 프로젝트를 전달받습니다.

자세한 내용은 Capgo 빌드 및 build 설정 참조 워크플로우 및 스토어 제출 옵션 안내.

Capgo는 디스크의 어디에 무엇을 저장하나요?

Capgo updater(code를 로드할 수 있도록 capacitor이 허용하는 유일한 디렉토리)는 앱 빌드 시 포함되며, 가장 최근에 다운로드한 bundle을 캐싱합니다. Android의 경우 다음 위치에 저장됩니다: /data/user/0/com.example.app/code_cache/capgo_updater 해당 경로의 기본값은 Android 시스템에서 제공하며 런타임에 동적으로 변경될 수 있습니다. iOS 기기의 경우 데이터는 다음 위치에 저장됩니다: Library/Application Support/capgo.

Capgo CLI 도구(예: npx @capgo/cli@latest bundle upload)는 npm 캐시에 설치되며, 로그인 정보는 홈 디렉토리의 다음 위치에 저장됩니다: ~/.capgo.

Capacitor Hot Reload와 어떤 관계가 있나요?

Capacitor의 Hot reload는 개발 단계에서만 사용하는 기능입니다. 프로덕션 환경에서는 Code push를 사용하세요.

Hot reload는 개발 중 기기에서 code을 변경할 수 있게 해주는 Capacitor의 기능입니다. 이를 사용하려면 로컬 머신에 연결할 프록시가 포함된 Capacitor 앱을 빌드해야 합니다.

Code push는 프로덕션 환경의 디바이스에서 code을(를) 변경할 수 있는 기능입니다. 플랫폼에 따라 이를 구현하기 위해 다양한 기술을 사용합니다.

Capgo code push는 어떤 유형의 변경 사항을 지원하나요?

Capgo를 통해 애플리케이션의 모든 JS code을(를) 변경할 수 있습니다. 여기에는 앱 code 및 생성된 code이(가) 포함됩니다. 또한 다음의 의존성도 업데이트할 수 있습니다: package.json 단, 네이티브 code 변경이 필요하지 않은 경우에 한합니다.

네이티브 code (예: Android의 Java/Kotlin 또는 iOS의 Objective-C/Swift) 변경을 지원할 계획은 없습니다. 네이티브 code 변경이 감지되면 번들에 포함되지 않으므로 도구에서 경고를 표시합니다.

Web 환경도 지원하나요?

Web은 이미 작동 방식이 동일하므로 Code push가 필요하지 않습니다. 사용자가 웹 앱을 열면 필요한 경우 서버에서 최신 버전을 다운로드합니다.

Web 환경에서 code push를 활용할 사례가 있다면 저희에게 알려주세요!

iOS, Android, Mac, Windows, Linux 등에서도 작동하나요?

네.

현재까지 Android, iOS, Electron 지원에 집중해 왔으며, 세 플랫폼 모두에서 code push를 프로덕션 환경에서 바로 사용할 수 있습니다.

Capgo가 지원하는 OS 버전은 무엇인가요?

Capgo는 Capacitor이 지원하는 Android 버전과 동일한 버전을 지원합니다.

Capacitor는 현재 Android API level 22+ 및 iOS 13.0+를 지원합니다: https://capacitorjs.com/docs/main/reference/support-policy

Capgo가 지원하는 Capacitor 버전은 무엇인가요?

Capgo는 현재 Capacitor의 최근 안정 버전만 지원합니다. Capacitor의 이전 버전도 지원할 수 있지만, 이를 장기적으로 유지 관리할 인프라가 아직 구축되지 않았을 뿐입니다. 향후 Capacitor의 더 많은 버전을 지원할 예정이며, 엔터프라이즈 고객을 위한 모든 버전도 포함됩니다. https://github.com/Cap-go/capgo/issues/1100

Capgo는 Capacitor의 안정 버전을 추적하며, 보통 안정 버전이 나온 뒤 몇 시간 이내에 업데이트합니다. 이 업데이트는 자동화되어 있어 실행에 몇 분이면 충분합니다. 이후 서버에 배포하기 전에 수동 검증 단계를 한 번 더 거칩니다.

App/Play Store의 심사 프로세스나 정책과는 어떤 관계가 있나요?

Capgo는 Capacitor 웹 레이어, 즉 앱의 WebView에서 이미 실행 중인 HTML, CSS, JavaScript, 에셋에만 변경 사항을 전달합니다. 네이티브 바이너리, 네이티브 플러그인, 권한, entitlements, 서명, 스토어 메타데이터는 변경하지 않습니다.

네이티브 변경이 있거나 앱의 심사 목적이나 기능에 영향을 줄 수 있는 중대한 변경이 있을 때는 반드시 스토어 네이티브 릴리스를 사용하세요. Live Update는 사용자에게 제출하고 공개한 앱 경험 범위 안에서 유지해야 합니다.

Capgo 때문에 Apple이 원격 code 실행을 이유로 거절할 수 있나요?

아니요, 불가능합니다. Capgo는 네이티브 code, 동적 라이브러리, 프레임워크 또는 플러그인을 설치하거나 실행하지 않으며, dlopen, dlsym, performSelector:, 또는 method_exchangeImplementations(). 검토된 바이너리에 이미 컴파일된 WebView 또는 JavaScriptCore 엔진 내부의 JavaScript, HTML, CSS, 정적 에셋만 교체합니다.

App Review에서 가이드라인 2.5.2 또는 “원격 code 실행”을 언급하더라도, Capgo을 원인으로 간주하지 마세요. 리뷰 노티스를 읽고, 네이티브 프로젝트나 다른 SDK에서 실행 파일 로딩 또는 private-API 사용 여부를 확인하세요. 과거에 Capgo 스플래시 화면 자동 숨기기 경로의 동적 링크와 관련된 리뷰 노티스가 있었으나, 이는 Live Update가 아닌 해당 네이티브 플러그인의 버그였으며 해당 링크는 제거되었습니다.

Apple의 원격 code 실행 규제가 Capgo에 영향을 미치나요?

아니요. Capgo는 원격 code 실행 거절의 원인이 될 수 없습니다. 자세한 내용은 Capgo 때문에 Apple이 원격 code 실행을 이유로 거절할 수 있나요?참조하세요. Capgo는 Capacitor 앱의 인터프리티드 웹 레이어를 위해 설계되었습니다. 심사 후 네이티브 code를 설치하거나 실행하지 않습니다. Apple은 여전히 각 앱의 개별 사실을 바탕으로 심사하며, Capgo는 그 결과를 보장할 수 없습니다.

Apple의 App Review 가이드라인 2.5.2 에 따르면 앱은 “앱의 기능이나 기능성을 도입하거나 변경하는 code를 다운로드, 설치 또는 실행할 수 없습니다.” 심사 팀은 이 규칙을 Apple Developer Program License Agreement 섹션 3.3.1(B) 에서 실행 가능한 code에 관한 조항과 함께, 승인 후 동작을 변경하기 위해 원격 리소스를 사용하는 앱을 거절할 때 인용합니다. 대표적인 예는 다음과 같습니다. dlopen, dlsym, performSelector:또는 프라이빗 API에 접근하는 원격 스크립트입니다.

같은 라이선스 계약은 해석된 code을 다음 조건 충족 시 다운로드하도록 허용합니다:

앱의 주된 목적을 변경하지 않고,
서명, 샌드박스 또는 기타 OS 보안 기능을 우회하지 않으며,
다른 애플리케이션을 위한 스토어나 스토어프론트를 만들지 않는 경우입니다.

섹션 3.3.1(C) Apple의 사전 서면 승인을 받거나 해당 섹션에서 허용하는 경우를 제외하고, App Store, Custom App Distribution, TestFlight 이외의 배포 수단을 통해 추가 기능이나 기능성을 제공·잠금 해제·활성화하는 행위를 별도로 제한합니다. 3.3.9(A) (In-App Purchase API). 해당 조항이 특정 인터프리트된 code OTA 번들에 어떻게 적용되는지는 귀사 팀과 법률 자문이 판단할 법적 문제입니다.

Capgo는 앱의 WebView 또는 JavaScriptCore 엔진에서 이미 실행 중인 JavaScript, HTML, CSS, 정적 에셋을 교체합니다. 네이티브 바이너리, 머신 code, 동적 라이브러리, 플러그인은 포함하지 않습니다. 가이드라인 4.7 (다음에서 명확화됨: 2025년 11월)은 앱이 바이너리에 내장되지 않은 HTML5 및 JavaScript 미니 앱, 미니 게임, 챗봇, 플러그인 또는 유사한 소프트웨어를 제공할 때 적용됩니다. 사용자가 앱 안에서 여러 가지 서로 다른 소프트웨어 경험을 탐색하거나 실행할 수 있다면, 4.7 요구 사항을 법률 자문과 함께 검토하십시오. 단일 제품이 자체 심사를 받은 웹 번들을 채널을 통해 업데이트하는 것은 별개의 사용자 경험이지만, 메타데이터가 해당 설명과 일치하는지는 Apple만이 결정합니다.

네이티브 기능, 권한, 엔타이틀먼트 및 주요 기능 변경 사항은 일반 App Store 바이너리로 출시하십시오. 제출한 앱 범위를 벗어나지 않는 웹 레이어 수정 및 개선에는 Capgo를 사용하십시오. 참고: Apple의 원격 code 실행 및 Capgo 더 자세한 규정 준수 분석이나 블로그 가이드 Guideline 2.5.2, ADPLA 3.3.1(B), 2025 Guideline 4.7 명확화 자료 관련.

Capgo를 사용하면 App Store나 Google Play 승인이 보장되나요?

아니요. Apple과 Google은 각 앱과 릴리스를 개별적으로 검토하며, Capgo는 개별 승인이나 검토 결과를 보장할 수 없습니다. 앱의 콘텐츠, 고지 사항, 업데이트 범위 및 최신 스토어 정책 준수에 대한 책임은 개발 팀에 있습니다.

검토 및 출시 계획을 위해 다음 공식 정책을 직접 확인하세요: Apple App Store 심사 가이드라인 및 Google Play의 기기 및 네트워크 오용 정책.

제 국가에서도 Capgo를 사용할 수 있나요?

저희는 어떤 국가에서도 Capgo에 대한 접근을 제한하려고 한 적이 없습니다.

일부 국가에서는 자국 내에서 접근할 수 있는 URL에 제한이 있다는 점을 인지하고 있습니다. Capgo는 현재 호스팅에 R2 Storage와 Cloudflare workers를 포함한 Cloudflare Cloud를 사용합니다.

Capgo에서 사용하는 URL은 다음과 같습니다:

https://api.capgo.app — 다음에서 사용: npx @capgo/cli Capgo 서버와 상호작용하는 CLI 도구와 사용자 기기에서 업데이트를 확인하는 Capgo updater
https://*.r2.cloudflarestorage.com — 다음에서 사용: npx @capgo/cli bundle을 upload 및 download하기 위한 CLI 도구

해당 국가에서 위 URL에 모두 접속할 수 있다면 Capgo는 정상적으로 작동할 것입니다.

특정 지역에서 해당 URL에 대한 접근을 차단해야 하는 경우, 저희에게 알려주세요. 프록시 서버 활용 등 해결 방안을 함께 찾아보겠습니다.

Capgo를 셀프 호스팅할 수 있나요?

네, 가능합니다. 자체 인프라에서 updater backend를 실행해야 하는 경우, Enterprise 플랜을 통해 라이선스가 포함된 Capgo 셀프 호스팅 배포를 지원합니다. 자세한 내용은 Self-Hosted Updater 배포 모델 및 엔드포인트를 참조하세요.

code push를 사용하려면 인터넷 연결이 필수인가요?

네, 필수입니다. 일반 인터넷과 분리된 별도의 서버를 통해 업데이트를 배포할 수는 있지만, 기기로 업데이트를 전달하기 위해서는 어떤 형태로든 네트워크 연결이 필요합니다.

네트워크 연결이 끊기면 Capgo에 어떤 영향이 있나요?

Capgo로 앱을 빌드할 때 포함되는 Capgo updater는 네트워크 연결 문제에 유연하게 대응하도록 설계되었습니다.

기본 업데이트 동작 시, 앱이 실행되면 Capgo updater에 알림을 보냅니다. 그러면 별도의 스레드가 생성되어 Capgo 서버에 네트워크 요청을 보내 업데이트를 확인합니다. 앱의 다른 작업이 차단되지 않도록 의도적으로 별도 스레드를 사용합니다. 네트워크 요청이 실패하거나 타임아웃이 발생하면, updater는 다음 앱 실행 시 다시 확인을 시도합니다.

Capgo CLI 도구(예. npx @capgo/cli@latest bundle upload)는 작동을 위해 네트워크 연결이 필요합니다. Capgo를 사용하여 앱을 배포하는 경우, CI 시스템에 네트워크 연결이 확보되어 있는지 확인해야 합니다.

사용자가 오랫동안 업데이트를 하지 않아 업데이트를 놓치면 어떻게 되나요?

저희 구현 방식은 요청하는 디바이스에 최적화된 업데이트를 항상 전송하며, 요청자를 항상 사용 가능한 최신 버전으로 업데이트합니다. 따라서 사용자가 한동안 업데이트를 하지 않으면 중간 단계의 업데이트들은 “건너뛰게” 됩니다.

애플리케이션의 요구 사항에 따라 다음 증분 버전 또는 최신 버전을 응답하도록 업데이트 서버 설정을 변경할 수 있습니다. 다른 업데이트 동작 방식이 필요하시다면 언제든 알려주세요.

Capgo와 Capacitor은 어떤 관계인가요?

Capgo는 Capacitor용 플러그인으로 code 푸시 기능을 추가합니다. Capgo은 Capacitor를 대체하는 것이 아닙니다. 기존에 사용하시던 Capacitor 툴링을 그대로 계속 사용하실 수 있습니다.

저희는 Capacitor의 최신 안정화 버전을 추적하며, 이에 맞춰 code 푸시 플러그인을 업데이트합니다.

업데이트는 언제 발생하나요?

기본적으로 Capgo updater는 앱 시작 시 업데이트를 확인합니다. 백그라운드 스레드에서 실행되므로 UI 스레드를 차단하지 않습니다. 업데이트는 사용자가 앱을 사용하는 동안 설치되며, 앱을 재시작할 때 적용됩니다.

또한 다음을 사용하여 Capgo updater를 수동으로 실행할 수도 있습니다: @capgo/capacitor-updater 해당 package를 통해 푸시 알림을 포함하여 언제든지 업데이트를 트리거할 수 있습니다.

Capgo updater는 네트워크가 연결되지 않았거나 서버가 다운되어 접속할 수 없는 상황에서도 앱이 정상적으로 작동하도록 설계되었습니다. 서버에서 업데이트를 삭제하더라도 모든 클라이언트는 문제없이 계속 실행됩니다.

패치를 롤백할 수 있는 기능을 추가했습니다. 이전 번들을 채널에 다시 연결하기만 하면 간단하게 이전 상태로 되돌릴 수 있습니다.

app_id를 비밀로 유지해야 하나요?

아니요. app_id 은(는) 앱에 포함되어 있으므로 공개되어도 안전합니다. 버전 관리 시스템에 (공개 저장소라도) 커밋해도 다른 사람이 이를 악용할 걱정은 하지 않으셔도 됩니다.

귀하의 정보를 가진 누군가 app_id 있더라도 Capgo 서버에서 앱의 최신 버전을 가져올 수는 있지만, 앱에 업데이트를 푸시하거나 Capgo 계정의 다른 부분에 접근할 수는 없습니다.

Capgo 서버로 어떤 정보가 전송되나요?

전체 데이터 인벤토리, 엔드포인트 동작, 개인정보 보호 제어는 다음에 문서화되어 있습니다: 컴플라이언스.

설정 statsUrl: '' 명시적 업데이터 통계 보고를 비활성화하려면 사용하세요. 또한 다음을 전송할 수도 있습니다: statsUrl 직접 제어하는 프록시 또는 엔드포인트로; 자세한 내용은 다음을 참조하세요: 자체 호스팅 인프라에서 통계 처리. 업데이트 확인에는 Capgo가 올바른 업데이트를 선택하고 월간 활성 디바이스 수를 측정할 수 있도록 앱 범위의 디바이스 식별자가 여전히 필요합니다.

이 하위 프로세서 목록 는 제공업체, 처리 위치, 전송 메커니즘, 변경 이력에 대한 최신 공개 정보원입니다.

HIPAA 민감 데이터를 다루는 앱에서 Capgo를 사용할 수 있나요?

네, 하지만 컴플라이언스 책임자가 적절한 배포 모델을 선택해야 합니다. 현재 Capgo Cloud는 HIPAA 준수 호스팅형 통계 처리자로 제시되지 않습니다. 기본적으로 업데이터 데이터는 디바이스 단위이며 알려진 앱 사용자와 연결되지 않으며, 많은 팀이 이 모델을 성공적으로 사용합니다.

더 엄격한 검토가 필요한 경우 플러그인 트래픽을 지역화하고, 통계를 비활성화하려면 statsUrl 빈 문자열로 설정하거나, 통계 엔드포인트만 셀프 호스팅하거나, 라이선스 셀프 호스팅을 사용하세요. 다음으로 호출하지 마세요: CapacitorUpdater.setCustomId(...) 이메일, 사용자 ID, 환자 ID, 직원 ID 또는 업데이터 텔레메트리를 특정 개인에게 다시 매핑하는 값으로.

자세한 내용은 HIPAA 준수 통계가 비활성화될 때의 전체 기술 설정과 관측성 트레이드오프

Capgo의 live update 데이터를 유럽 내에 보관할 수 있나요?

네. Capgo Cloud 플러그인 트래픽에 EU 데이터 레지던시가 필요한 앱은 업데이터 엔드포인트를 EU 호스트로 설정할 수 있습니다:

updateUrl: https://plugin.eu.capgo.app/updates
statsUrl: https://plugin.eu.capgo.app/stats
channelUrl: https://plugin.eu.capgo.app/channel_self

업데이트 확인, 통계, 채널 자체 할당이 동일한 지역 데이터 경로를 사용하도록 세 개의 EU URL을 함께 사용하세요. 이 값들은 capacitor.config.ts에 저장되므로, 기존에 설치된 앱이 새 엔드포인트를 사용하려면 프로덕션 모바일 앱은 네이티브 릴리스가 필요합니다.

자세한 내용은 데이터 위치 정확한 Capacitor 및 Electron 예시를 참조하세요.

Capgo는 어떤 플랫폼을 지원하나요?

현재 Capgo는 Android, iOS, Electron을 지원하며, 모두 프로덕션에서 사용할 수 있습니다.

iOS, Android, Electron에서 Capgo 사용 여부는 각각 독립적으로 결정할 수 있습니다. 필요에 따라 Android와 App Store용으로 빌드한 ipa, 또는 Electron 채널에 대한 채널 전략을 설정할 수 있습니다.

Capgo는 데스크톱이나 임베디드 타깃도 (비교적 쉽게) 지원하도록 만들 수 있습니다. 해당 기능이 중요하다면 저희에게 알려주세요.

Capgo는 Play Testing Tracks나 Apple TestFlight와 어떻게 연동되나요?

각 앱 스토어는 제한된 사용자 그룹(예: “내부 테스트”, “비공개 베타” 등)에 앱을 배포하는 별도의 방식을 제공합니다. 이는 모두 사용자를 그룹으로 나누고 각 그룹에 특정 버전의 앱을 배포하기 위한 방식입니다.

안타깝게도 이러한 방식 중 일부는 특정 테스트 트랙이나 TestFlight를 통해 앱이 설치되었는지 제3자가 감지할 수 없게 합니다. 따라서 해당 그룹의 구성을 정확히 파악할 수 없으며, 이 그룹을 기준으로 Capgo 패치 접근 권한을 확실하게 제어할 수도 없습니다. https://stackoverflow.com/questions/53291007/can-an-android-application-identify-the-test-track-within-google-play https://stackoverflow.com/questions/26081543/how-to-tell-at-runtime-whether-an-ios-app-is-running-through-a-testflight-beta-i

Capgo bundle의 가용성을 세분화하려면 다음 4가지 옵션을 고려할 수 있습니다:

그룹마다 별도의 channel을 사용하세요. 가장 간단한 방법이지만 여러 channel을 관리해야 합니다. 이미 가용성이 다른 dev channel과 prod channel을 운영 중일 수도 있습니다. 따라서 dev channel을 업데이트해 검증한 뒤, 별도로 prod channel을 업데이트할 수 있습니다. 각 릴리스와 연결된 소스를 추적하려면 버전 관리에서 branches / tags를 사용하는 것이 좋습니다.
직접 opt-in한 사용자 집합을 추적하고, 자동 업데이트를 비활성화하고, 특정 사용자에게만 업데이트를 트리거할 수 있습니다. 다음 패키지를 통해: @capgo/capacitor-updater 이 방식은 현재도 동작하지만, opt-in 목록은 직접 관리해야 합니다.
Capgo를 사용하면 기기별로 자체 opt-in 방식을 만들 수 있습니다(Test Tracks나 TestFlight와 비슷하지만 플랫폼에 구애받지 않습니다). 덕분에 QA 팀은 번들이 일반 사용자에게 배포되기 전에 미리 opt-in할 수 있습니다.
사용 단계적 롤아웃 채널 내 무작위이면서 고정된 일부 사용자에게 후보 번들을 전달합니다. 롤아웃 비율을 0~100%로 설정하거나, --rollout-percentage-bps 0.01% 단위로 설정할 수 있습니다. 캐시 기간은 60초에서 365일까지 설정할 수 있고, 선택 사항으로 auto-pause 정책도 구성할 수 있습니다. 이 기능은 이름이 지정된 기기 그룹을 선택하는 방식이 아닙니다.

결제

플랜을 업그레이드하거나 다운그레이드하려면 어떻게 해야 하나요?

대시보드에서 언제든지 요금제를 업그레이드하거나 다운그레이드할 수 있습니다: https://console.capgo.app/settings/organization/plans. 업그레이드는 즉시 적용됩니다. 다운그레이드는 현재 결제 주기가 종료된 후 적용됩니다.

MAU 한도에 도달하면 어떻게 되나요?

Capgo는 MAU 한도의 50%, 70%, 90%, 100%에 도달할 때마다 이메일을 보냅니다. 한도에 도달하면 결제 주기가 끝날 때까지 Live Update가 차단됩니다. 업데이트를 다시 제공하려면 상위 요금제로 업그레이드하거나 크레딧을 구매하세요. 요금제 등급은 Capgo 가격 및 pricing.md 에서 확인하실 수 있습니다.

환불이 가능한가요?

법적으로 요구되는 경우를 제외하고, 결제된 구독료는 환불되지 않습니다. 특정 환불 요청은 Capgo의 독자적인 판단에 따라 개별적으로 검토될 수 있습니다. 관련 문의는 고객 지원 자격 요건을 충족한다고 판단되는 경우 연락해 주세요.

결제 주기는 언제 리셋되나요?

Capgo를 처음 구독한 달을 기준으로 매월 자동으로 결제 주기가 갱신됩니다. 예를 들어, 이번 달 15일에 구독했다면 매달 15일에 결제 주기가 갱신됩니다.

구독을 취소하려면 어떻게 해야 하나요?

대시보드에서 언제든지 구독을 취소할 수 있습니다: https://console.capgo.app/settings/organization/plans

1년 치 요금을 선결제할 수 있나요?

네. 다음 메뉴의 연간 결제를 선택할 수 있습니다: 조직 플랜 설정.

스토리지에 포함되는 항목은 무엇이고, 보관 기간을 변경할 수 있나요?

스토리지에는 각 채널의 히스토리 번들과 Delta 에셋이 포함됩니다. 앱 설정에서 앱별 미사용 번들 보관 기간을 관리할 수 있습니다. 활성 채널이나 롤아웃에 연결된 번들은 배포 및 롤백을 위해 안전하게 보호됩니다.

지역 복제 시 스토리지나 대역폭이 배로 늘어나나요?

아니요. 번들은 제공되는 지역 수와 관계없이 스토리지 용량이 한 번만 계산됩니다. 대역폭 또한 지역에 따라 배수로 늘어나지 않습니다. 다음을 참조하세요: 대역폭은 어떻게 계산되나요?.

대역폭은 어떻게 계산되나요?

대역폭은 디바이스가 Capgo에서 실제로 다운로드한 파일만 계산합니다:

Delta 업데이트: when you upload with --delta, 디바이스는 이미 보유한 버전 이후로 변경된 파일만 다운로드합니다. 변경된 파일만 계산됩니다. 대용량 이미지나 폰트처럼 변경되지 않은 파일은 다시 다운로드되지 않으며 비용도 발생하지 않습니다. 자세히 보기: 델타 업데이트.
Edge 캐시: 요청한 파일이나 전체 zip이 이미 Edge 캐시에 있으면 해당 다운로드는 대역폭에 포함되지 않습니다. Delta 파일과 전체 zip 모두 마찬가지입니다.
다운로드 재개: 다운로드가 중단되면 기기는 중단된 지점부터 이어받습니다. 이미 다운로드된 부분은 다시 받지 않으며 대역폭에도 다시 포함되지 않습니다.
전체 zip: 없이 업로드된 bundle --delta또는 Delta를 지원하지 않는 plugin 버전을 사용하는 기기는 전체 zip을 다운로드합니다. Edge 캐시에서 제공되지 않을 때만 대역폭에 포함됩니다.

대역폭을 낮게 유지하려면 다음을 사용해 업로드하고, --delta 변경이 거의 없는 대용량 에셋은 고정된 파일 경로에 보관하세요.

Enterprise SLA에는 무엇이 포함되나요?

Enterprise에는 프로덕션 플랫폼에 대한 월간 99.9% 가용성 약정이 포함됩니다. 이 약정을 지키지 못하면 월간 가용성에 따라 10%~30%의 서비스 크레딧이 지급됩니다. 초기 지원 응답 목표는 P1: 1시간(24/7/365), P2: 영업일 기준 2시간, P3: 영업일 기준 1일, P4: 영업일 기준 2일입니다. 자세한 내용은 Enterprise SLA 에서 전체 약관을 확인하세요.

통계 및 분석

대시보드의 통계는 매일 UTC 자정에 업데이트됩니다. 통계는 고유 MAU 를 기준으로 계산되며, 롤링 30일 기간 동안 활성 상태인 사용자를 집계합니다.

디바이스 ID 생성 방식

디바이스 ID는 앱 최초 실행 시 디바이스에서 생성됩니다. 이는 디바이스별 설치 중복을 방지하고, 전체 패치 수나 패치 설치 수가 아닌 실제 설치된 사용자 수(예: 월간 활성 사용자 수, MAU)를 기준으로 과금하기 위해 사용됩니다.

Capgo의 가격 책정에는 설치 수보다 MAU가 더 나은 솔루션입니다. MAU가 더 정확하며 디바이스당 Capgo의 실제 비용을 더 잘 반영하기 때문입니다.

디바이스 ID 유지 방식:

iOS: v7.25.0 이상부터 디바이스 ID는 Keychain에 저장되어 일반적인 재설치 후에도 유지됩니다.
Android: v7.50.1 이상(또는 해당 릴리스 라인의 v5.50.1+/v6.50.1+)을 사용하세요. 디바이스 ID는 Android Backup/Restore가 앱 설정을 유지할 때만 복구됩니다.
Electron: 디바이스 ID는 secure storage에 저장됩니다.
Android 주의 사항: 백업을 비활성화하거나, 관련 설정을 제외하거나, 앱 데이터를 삭제하면 새로운 디바이스 ID가 생성됩니다. Android v7.25.0부터 v7.50.0 버전은 백업이 활성화되어 있어도 재설치 후 새로운 디바이스 ID가 생성될 수 있습니다.

Device ID는 앱 단위로 할당되며 Live Update 배포 및 MAU 중복 제거를 지원합니다. 이는 광고용 또는 앱 간 추적용 식별자가 아닙니다.

Device ID는 앱이 updater 또는 stats 엔드포인트를 통해 Capgo에 체크인한 후 목록에 표시됩니다. 패치를 설치하지 않아도 device list에 나타날 수 있습니다.

기기 수가 MAU와 왜 다른가요?

Device list와 MAU는 서로 다른 신호를 기반으로 합니다.

Device list에는 device ID, 플랫폼, plugin 버전, OS 버전, native 버전, channel, 설치된 bundle, 요청 국가(가능한 경우) 등 각 기기의 최신 메타데이터가 표시됩니다. 요청 국가는 GPS나 앱 제공 위치가 아니라, 해당 기기의 Cloudflare 처리된 요청에서 수신된 최신 유효 2자리 code입니다. 유효한 국가 정보가 없는 요청이라도 마지막 유효 값을 삭제하지 않습니다. Capgo는 앱이 체크인할 때 이 메타데이터를 업데이트하지만, 동일한 메타데이터를 보고하는 반복적인 체크인은 행이나 마지막 업데이트 시간을 변경하지 않을 수 있습니다.

MAU는 과금 기간 동안의 고유 활성 기기 수를 집계합니다. 기기 메타데이터가 동일하더라도 활동이 증가할 수 있으므로 기기 수와 MAU는 다를 수 있습니다.

플랫폼별로 다른 업데이트를 적용하려면 어떻게 하나요?

플랫폼별로 채널을 생성하고, 각 채널에서 특정 플랫폼의 업데이트를 비활성화할 수 있습니다.

iOS 채널에서는 Android 업데이트를 비활성화하고, Android 채널에서는 iOS 업데이트를 비활성화하세요.

그 다음 각 채널에 번들을 upload하면 플랫폼마다 서로 다른 업데이트를 적용할 수 있습니다.

두 플랫폼에 동일한 업데이트를 적용하려면 하나의 번들을 여러 채널에 연결하면 됩니다. 번들을 중복해서 만들 필요가 없습니다.

FAQ 더 보기

사용 중이라면 자주 묻는 질문 live update 배포를 계획하려면, 다음과 연결하세요 Capgo Live Updates Capgo Live Updates의 제품 워크플로우를 보려면, 개요 Overview의 구현 상세를 보려면, 기능 Features의 구현 상세를 보려면, 업데이트 동작 Update Behavior의 구현 세부 사항은 다음과 같고, 업데이트 유형 Update Types의 구현 세부 사항은 다음과 같습니다.