임계값이 너무 낮으면 정상적인 OTA 배포가 중단될 수 있고, 너무 높으면 잘못된 번들이 너무 많은 기기에 도달할 수 있습니다. Capgo의 자동 일시 중지 최소 시도 횟수 설정은 Capgo가 채널을 일시 중지할 만큼 충분한 설치 및 실패 데이터를 확보했을 때를 제어합니다. 아래 단계를 따라 신중하게 설정하고, 테스트하고, 릴리스 흐름에 연결하세요.
목차
- 1단계: Minimum Attempts 제어 항목 이해하기
- 2단계: Capgo에서 Auto-Pause 설정 찾기
- 3단계: 안전한 Minimum Attempts 값 설정하기
- 4단계: 채널 기반 롤아웃으로 Auto-Pause 테스트하기
- 5단계: 시도 횟수, 분석 및 자동 롤백 모니터링하기
- 6단계: CI/CD에서 설정 자동화하기
- 자주 묻는 질문
- 결론
1단계: Minimum Attempts의 역할 이해하기
이 자동 일시 중지 최소 시도 횟수 이 값은 pause 규칙이 적용되기 위해 Capgo에 필요한 최소 샘플 수를 설정합니다. 이는 실패 제한이 아닌 게이트 역할을 합니다. 즉, Capgo이 롤아웃을 판단하기 전, 충분한 업데이트 시도가 발생할 때까지 기다리도록 합니다.
시도(attempt)에는 번들을 설치하려는 기기가 포함될 수 있습니다. 시도는 성공할 수도 있고 실패할 수도 있습니다. 정확한 결과는 업데이트 경로, 앱 상태 및 updater 설정에 따라 달라집니다. 따라서 롤아웃 규모를 고려하여 이 값을 설정해야 합니다.
Capgo의 채널 참조는 다음과 같습니다.auto-pause-min-attemptsauto-pause가 작동하기 전 필요한 최소 설치 및 실패 시도 횟수입니다. 이 필드는 CLI 레퍼런스에서 string으로 표현되므로, 사용 중인 명령어나 API에서 요구하는 형식을 유지해야 합니다. 다음 내용을 통해 Capgo 채널의 CLI 필드를 라이브 채널 변경 전에 검토할 수 있습니다.
이 설정은 '최소 증거 규칙'이라고 생각하면 쉽습니다. 값을 1로 설정하면 첫 번째 시도 기록 직후에 반응할 수 있습니다. 이는 소규모 내부 테스트에는 도움이 될 수 있지만, 일시적인 네트워크 불안정에도 반응할 수 있습니다. 값을 크게 설정하면 롤아웃 과정에서 유의미한 샘플을 수집할 시간을 더 확보할 수 있습니다.
사용자별 시도 횟수 구분
시도 횟수(Attempts)는 고유 사용자 수와 다릅니다. 한 기기에서 업데이트를 재시도할 수 있고, 한 사용자가 여러 기기에서 앱을 실행할 수도 있습니다. 또한 분석 뷰(analytics view)의 이벤트 그룹화 방식이 제품 메트릭과 다를 수 있습니다.
숫자를 결정하기 전에, 임계값(threshold)을 통해 무엇을 보호하려 하는지 먼저 정의하세요. 깨진 JavaScript bundle을 조기에 발견하는 것이 목적이라면, 소규모 제어 채널에서는 낮은 값을 사용할 수 있습니다. 반면 광범위한 프로덕션 릴리스를 보호하는 것이 목적이라면, 단일 기기나 일시적인 장애로 인해 잘못된 결정이 내려지지 않도록 충분한 시도 횟수를 확보해야 합니다.
- 프라이빗 테스트 채널에는 낮은 임계값을 사용하세요.
- 네트워크 환경이나 기기 종류가 다양한 채널에는 높은 임계값을 사용하세요.
- 일시적인 장애로 인해 오작동(false pause)이 발생했다면 임계값을 높이세요.
- 감지가 늦어짐으로써 발생하는 손실이 오작동의 비용보다 클 때만 임계값을 낮추세요.
Auto-pause는 롤아웃을 중단하는 용도로 사용해야 합니다. 이는 번들 리뷰, 디바이스 테스트 또는 명확한 롤백 계획을 대체할 수 없습니다. 임계값은 릴리스 프로세스 내의 하나의 제어 수단으로 간주하세요.
핵심 요약: Minimum attempts는 auto-pause 정책이 작동하기 전 Capgo이 확보해야 하는 롤아웃 증거의 양을 제어합니다.
2단계: Capgo에서 Auto-Pause 설정 찾기
설정하려면 Capgo auto pause minimum attempts 값을 먼저 번들을 전달하는 채널을 찾으세요. Auto-pause는 롤아웃 제어의 일부이므로, 앱 전체의 updater 설정을 변경해도 원하는 채널 정책이 바뀌지 않을 수 있습니다.
Capgo dashboard에서 시작하거나 팀에서 이미 사용 중인 channel 명령 및 API 경로를 사용하세요. 수정하기 전에 반드시 채널 이름을 확인해야 합니다. 테스트 채널과 프로덕션 채널은 이름이 비슷할 수 있으며, 잘못된 채널에 값을 설정하는 것은 곧 릴리스 사고로 이어질 수 있습니다.
채널 설정에서 auto-pause 필드를 찾으세요. 관련 필드에는 minimum attempts 값과 confidence 설정이 포함될 수 있습니다. 변경 사항을 검토할 때 이 필드들을 함께 확인하세요. Minimum sample은 Capgo이 롤아웃을 판단하는 시점을 결정하며, confidence 값은 일시 중단이 발생하기 위해 신호가 얼마나 강력해야 하는지에 영향을 미칩니다.
감사가 가능한 경로를 통해 값을 설정하세요
빠르고 제어된 변경이 필요하거나 팀에서 대시보드 변경 사항을 기록하는 경우 대시보드를 사용하세요. 설정이 릴리스 스크립트에 포함되어야 한다면 CLI를 사용하세요. 더 넓은 배포 시스템의 일부로 서비스가 채널 정책을 관리한다면 공개 API를 사용하세요.
어떤 방식을 선택하든 먼저 이전 값을 기록하세요. 채널 이름, 번들 버전, 롤아웃 상태 및 새 값을 동일한 변경 기록에 저장하세요. 그래야 나중에 채널이 일시 중지되었을 때 명확한 원인을 파악할 수 있습니다.
API 기반 워크플로의 경우, Capgo는 공개 API를 통해 채널 리소스를 노출합니다. Capgo 채널 API 문서 로컬 스크립트로 추측하는 대신 필드 이름과 요청 형식을 확인하려면 이곳을 참조하는 것이 가장 정확합니다.
값을 수정할 때는 필드 요구 사항에 따라 정수를 입력하세요. 퍼센트(%) 기호를 추가하거나 소수점을 사용하지 마세요. 도구에서 설정을 JSON으로 저장하는 경우, 키 스펠링을 정확히 유지하고 현재 Capgo 참조에 표시된 문자열 형식을 그대로 유지하세요.
변경 사항 확인
저장 후 채널을 다시 확인하세요. 명령이 성공했다고 해서 의도한 필드가 변경되었다고 단정해서는 안 됩니다. 반환된 채널 데이터나 대시보드 값을 반드시 검증하세요.
그 다음 세 가지를 확인하세요:
- 의도한 채널의 설정이 변경되었는가?
- 채널이 여전히 의도한 번들을 가리키고 있는가?
- 롤아웃 상태가 활성(active), 일시 중지(paused), 또는 완료(complete) 상태인가?
값이 나타나지 않는다면 거기서 멈추세요. 권한, 필드 철자, 채널 식별자를 확인해야 합니다. 저장된 상태를 검증하지 않고 성공만 보고하는 배포 스크립트는 신뢰하기 어렵습니다.
3단계: 안전한 Minimum Attempts 값 선택
롤아웃 규모와 리스크에 따라 Capgo auto pause minimum attempts 값을 선택하세요. 모든 앱에 통하는 안전한 숫자는 없습니다. 적절한 임계값은 정책에 충분한 근거를 주면서 문제 있는 업데이트를 조기에 감지하게 합니다.
유의미한 정보를 얻을 수 있는 가장 작은 그룹부터 시작하세요. 프라이빗 채널에는 앱 버전을 알고 있는 내부 기기가 있을 수 있습니다. 프로덕션 채널에는 구형 기기, 불안정한 연결, 며칠에 한 번만 앱을 여는 사용자가 포함될 수 있습니다. 이런 그룹은 기본적으로 같은 임계값을 공유해서는 안 됩니다.
간단한 판단 기준을 사용하세요
실패 패턴이 의미를 가지려면 시도가 몇 번 필요한지 자문해 보세요. 테스트 채널에 기기가 몇 대뿐이라면 테스트 기간 내에 높은 임계값에 도달하지 못할 수 있습니다. 프로덕션 채널에 몇 분 만에 많은 시도가 들어온다면, 임계값이 너무 낮을 때 짧은 네트워크 문제만으로도 릴리스가 일시 중지될 수 있습니다.
다음 경우에는 값을 낮게 설정하세요:
- 채널이 프라이빗인 경우
- bundle이 고위험 기능을 변경하는 경우
- 단계적 테스트 중 빠른 피드백이 필요한 경우
- 릴리스 후 곧 팀이 모든 실패를 검토할 수 있는 경우
다음 경우에는 값을 높게 설정하세요:
- 해당 채널은 다양한 기기 환경을 대상으로 합니다.
- 사용자는 불안정한 네트워크 환경에서 접속하기도 합니다.
- 앱의 일일 실행 빈도가 낮을 수 있습니다.
- 짧은 서비스 중단이 많은 오탐(false failure)을 유발할 수 있습니다.
임계값을 이미 알고 있는 문제를 숨기는 용도로 사용하지 마세요. 필수 Native Build 플러그인 문제로 bundle 설치가 실패한다면, 직접 릴리스를 일시 중지하고 원인을 해결해야 합니다. 최소 시도 횟수 설정만으로는 호환되지 않는 bundle을 안전하게 만들 수 없습니다.
임계값을 롤아웃 규모와 함께 설정하세요
먼저 소규모 내부 채널에 릴리스한다고 가정해 봅시다. auto-pause가 작동하기 전, 팀이 여러 번의 설치 결과를 확인할 수 있도록 임계값을 설정할 수 있습니다. bundle이 해당 단계를 통과하면, 더 큰 샘플 크기를 반영할 수 있는 임계값을 적용하여 더 넓은 채널로 이동하세요.
이 방식은 운영 정책이 너무 적은 샘플에 반응하지 않도록 하면서도, 첫 신호를 빠르게 확인할 수 있게 해줍니다. 또한 설정을 조정할 명확한 기준을 제공합니다. 롤아웃이 실패한 후가 아니라, 채널에 맞춰 임계값을 변경하세요.
릴리스 기록 옆에 해당 값을 기록해 두세요. 왜 이 값을 선택했는지, 어떤 상황에서 변경할 것인지, 그리고 변경 승인권자는 누구인지 적어두어야 합니다. 이는 장애 발생 시 팀원이 중지된 채널을 보고 빠르게 상황을 파악해야 할 때 매우 중요합니다.
고급 팁: 제어된 채널에서 시작하여 시도 횟수를 기록한 다음, 추측이 아닌 실제 롤아웃 동작을 관찰하여 운영 임계값을 조정하세요.
4단계: 채널 기반 롤아웃으로 Auto-Pause 테스트하기
프로덕션에 적용하기 전, 채널을 통해 auto-pause를 미리 테스트해 보세요. 채널을 사용하면 테스트 범위를 지정할 수 있습니다. 특정 그룹에 번들을 전송하여 시도 횟수가 증가하는 것을 모니터링하고, 정책 임계값에 도달했을 때 어떤 동작이 발생하는지 확인할 수 있습니다.
먼저, 실제 릴리스와 혼동되지 않도록 식별 가능한 테스트 번들을 만드세요. code 변경 사항을 안전하게 유지해야 합니다. 테스트의 목적은 릴리스 제어 기능을 검증하는 것이지, 또 다른 앱 문제를 만드는 것이 아닙니다.
다음으로, 소수의 테스트 기기를 해당 채널에 할당하세요. 각 기기에 예상되는 네이티브 앱 버전이 설치되어 있는지 확인해야 합니다. OTA code가 모든 네이티브 불일치를 해결할 수는 없으므로, 잘못된 바이너리가 실행 중인 기기가 있으면 테스트 결과 해석이 어려워질 수 있습니다.
채널에 번들을 게시하세요. 가급적 기존 Capgo 배포 흐름에서 하나의 명령어를 사용하되, 릴리스 로그에 번들과 채널 ID를 남겨두세요. 장애 발생 시 터미널 스크롤 버퍼에만 의존해서는 안 됩니다.
Pause 경로 테스트하기
실패 상황을 안전하게 재현할 방법이 필요합니다. 테스트 전용 번들을 사용하거나 팀에서 승인한 제어된 실패 조건을 활용하세요. auto-pause 작동 여부를 확인하려고 프로덕션 번들을 손상시켜서는 절대 안 됩니다.
다음 순서를 모니터링하세요:
- 채널이 테스트 번들을 가리킵니다.
- 기기가 업데이트 명령을 수신합니다.
- 애널리틱스 뷰에 시도(Attempts) 내역이 나타납니다.
- 최소 시도 횟수에 도달합니다.
- 정책 조건이 충족되면, 실패 신호로 인해 채널이 pause 상태가 됩니다.
다섯 번째 단계가 중요합니다. 최소 시도 횟수(minimum attempts)에 도달하면 auto-pause 대상이 될 수 있습니다. 하지만 모든 롤아웃이 정확히 해당 횟수에서 일시 중지되는 것은 아닙니다. 다른 정책 필드와 관찰된 결과에 따라 결과가 달라질 수 있습니다.
복구 프로세스도 함께 테스트하세요
일시 중지 후 사용자가 무엇을 받는지 확인하세요. 실패한 bundle이 계속 선택되어 있는지, 새로운 기기에 배포가 중단되었는지, 그리고 이전의 안전한 bundle로 롤백이 가능한지 체크해야 합니다. 결과는 사용 중인 updater와 channel 설정에 따라 다르므로, 추측하지 말고 앱 logs를 통해 직접 확인하세요.
실패 원인을 검토한 후에만 검증된 bundle로 재개하세요. 만약 빌드 자체의 문제라면 새로운 bundle을 만드세요. 단순히 동일한 artifact를 다시 push하며 다음 시도에는 다를 것이라고 기대해서는 안 됩니다.
테스트 결과를 문서화하세요. 임계값, 기기 수, 실패 조건, 일시 중지 시간, 그리고 복구 조치를 포함해야 합니다. 이렇게 하면 일회성 테스트를 반복 가능한 릴리스 체크 프로세스로 만들 수 있습니다.
5단계: 시도 횟수, 분석 및 자동 롤백 모니터링
모니터링을 통해 Capgo auto pause minimum attempts 규칙이 정상적인 롤아웃을 처리하고 있는지, 아니면 문제가 발생한 상태인지 알 수 있습니다. 실패 동작과 함께 시도 횟수를 주시하세요. 맥락 없는 횟수 확인은 너무 이른 일시 중지를 유발하거나, 커지는 문제를 놓치게 만들 수 있습니다.
Capgo Observe를 사용하여 업데이트 활동과 롤아웃 상태를 점검하세요. Capgo Observe 문서 업데이트 정보를 확인하고 auto-pause 동작을 설정하는 영역입니다. 릴리스 초기 단계에는, 특히 번들이 code 또는 핵심 앱 플로우를 변경할 때는 dashboard를 계속 열어두세요.
여러 신호를 종합적으로 분석하세요
먼저 전체 시도 횟수를 확인하세요. 그다음 실패 횟수와 시간 패턴을 체크합니다. 꾸준히 설치가 성공하는 패턴은 특정 번들이 활성화된 후 실패가 급증하는 패턴과 다르게 나타납니다.
가능한 경우 기기 및 앱 버전 상세 정보를 확인하세요. 특정 native 버전에서 실패가 집중된다면 OTA 번들에 더 최신 binary가 필요할 수 있습니다. 모든 버전에서 실패가 발생한다면 번들 자체나 업데이트 서비스 경로를 점검해야 합니다.
네트워크 장애는 노이즈를 유발할 수 있습니다. 짧은 네트워크 중단은 code 결함 없이도 실패를 일으킬 수 있습니다. 따라서 임계값은 신뢰 정책 및 수동 검토 프로세스와 함께 작동해야 합니다. Auto-pause는 노출을 차단할 수는 있지만, 모든 실패 원인을 설명할 수는 없습니다.
워크플로우 내 롤백의 의미를 정확히 파악하세요
롤백은 영향을 받은 사용자를 검증된 이전 릴리스로 되돌리거나, 문제가 있는 릴리스가 더 많은 기기에 도달하지 않도록 차단합니다. 필수 기능이 누락된 native binary를 복구할 수는 없으며, OTA 번들이 이미 실행한 데이터 마이그레이션을 되돌릴 수도 없습니다.
프로덕션에 적용하기 전, 테스트 채널을 통해 롤백 경로를 반드시 확인하세요. 어떤 번들이 안전한 것으로 간주되는지 검증하고, 일시 중지(pause) 중 기기가 오프라인일 때 어떻게 동작하는지 체크해야 합니다. 그 다음, 온콜 엔지니어가 즉시 확인할 수 있도록 복구 절차를 문서화해 두세요.
Capgo의 롤백 문서 를 참고하면 사용 가능한 롤백 제어 기능을 채널 플랜에 맞춰 구성하는 데 도움이 됩니다. 결과는 업데이트 버전이나 릴리스 설정에 따라 달라질 수 있으므로, 문서화된 동작을 기준으로 삼으세요.
장애 발생 시 실패 패턴이 명확하다면 먼저 일시 중지(pause)를 실행하세요. 그 다음 로그와 번들 변경 사항을 점검하십시오. 문제가 있는 릴리스가 계속 배포되도록 두는 것보다, 몇 분간 노출을 차단하는 것이 대응하기 훨씬 수월합니다.
6단계: CI/CD에서 설정 자동화하기
채널마다 설정값이 달라진다면 릴리스 워크플로우에 Capgo auto pause minimum attempts 값을 포함하세요. 자동화를 통해 수동 설정 오류를 방지할 수 있으며, code 리뷰에서도 설정된 임계값을 명확히 확인할 수 있습니다.
채널 정책은 보안 비밀(secrets)과 분리하여 관리하세요. 채널 이름, 롤아웃 단계, minimum attempts 값은 버전 관리되는 설정 파일에 저장할 수 있습니다. 반면 API 토큰은 반드시 CI/CD secret store에 보관해야 합니다. 채널 설정이 이미 저장소에 있다고 해서 토큰을 리포지토리에 커밋해서는 안 됩니다.
릴리스 작업은 다음과 같은 순서로 진행되어야 합니다:
- 웹 번들 빌드.
- 테스트 실행 및 네이티브 호환성 확인.
- 번들 업로드.
- 대상 채널을 설정하거나 확인하세요.
- 최소 시도 횟수 값을 적용하세요.
- 저장된 채널 상태를 검증하세요.
- 롤아웃을 게시하거나 진행하세요.
배포 시스템에서 지원한다면 dry-run 또는 검토 단계를 사용하세요. 검토 단계에서는 프로덕션 단계가 실행되기 전에 bundle identifier, 채널, 임계값, 롤아웃 작업을 보여줘야 합니다.
검증을 작업의 일부로 포함하세요
API 또는 CLI 명령이 완료되면 채널 상태를 다시 가져오세요. 반환된 값이 예상 설정과 일치하지 않으면 작업을 실패 처리하세요. 이렇게 하면 잘못된 채널 ID, 거부된 필드, 부분 업데이트를 잡을 수 있습니다.
환경 변수는 CI 작업에 릴리스 설정을 전달하는 일반적인 방법입니다. 작업은 소스 파일에 비밀 정보를 두지 않고도 채널 이름이나 임계값을 읽을 수 있습니다. 변수 이름을 명확히 유지하고 배포 전에 검증하세요.
예를 들어, 워크플로우에 다음이 필요할 수 있습니다:
CAPGO_CHANNEL대상 채널용CAPGO_MIN_ATTEMPTS승인된 임계값용CAPGO_BUNDLE_ID업로드된 bundle용
해당 명칭들은 워크플로우 컨벤션일 뿐, Capgo 필드명이 아닙니다. 한 곳에서 이를 정확한 CLI 또는 API 필드에 매핑하세요. 그래야 향후 변경 사항을 더 쉽게 검토할 수 있습니다.
더 심도 있는 보안 점검을 위해, CI/CD 파이프라인에서 OTA 업데이트를 보호하는 방법에 대한 Capgo의 가이드를 확인해 보세요. 핵심 습관은 간단합니다. 토큰 액세스를 제한하고, 릴리스 결정 사항을 로그로 남기며, 변경 후 결과를 검증하는 것입니다.
변경 기록 유지
임계값을 커밋 또는 릴리스 ID와 함께 저장하세요. 변경 사유도 함께 기록해야 합니다. 롤아웃이 예기치 않게 중단될 경우, 정책을 번들과 배포 시간과 비교하여 분석할 수 있습니다.
Capgo는 일회성 구매가 아닌 조직별 구독 모델로 운영되며, 14일간의 무료 체험을 제공합니다. 이 모델은 정기적인 배포 프로세스에 도입하기 전, 릴리스 워크플로우를 미리 테스트하려는 팀에 적합합니다. 체험 기간에는 하나의 채널 설정, 하나의 일시 중지 테스트, 하나의 롤백 경로 검증에 집중하세요.
명령어 하나로 업데이트를 배포할 수 있습니다. 하지만 더 안전한 워크플로우는 채널을 확인하고, 채택률을 추적하며, 롤백 경로를 확보해 두는 방식입니다.
자주 묻는 질문
Capgo auto pause minimum attempts란 무엇인가요?
Capgo auto pause minimum attempts는 auto-pause 정책이 작동하기 위해 필요한 최소 설치 및 실패 시도 횟수를 설정합니다. 이는 실패 설치 비율이 아니라 표본 크기를 결정하는 게이트 역할을 합니다. 값이 낮으면 더 빠르게 반응하지만 근거가 부족할 수 있고, 값이 높으면 채널이 결과를 수집할 시간을 더 많이 갖게 됩니다.
Capgo에서 auto pause minimum attempts는 어디서 설정하나요?
OTA bundle을 전달하는 채널에 값을 설정하세요. Capgo dashboard, CLI 또는 공개 API를 사용한 다음, 채널을 다시 조회해 저장된 필드를 확인하세요. 먼저 채널 이름을 확인하세요. 프로덕션이 활성화된 상태에서 테스트 채널을 수정해도 프로덕션 롤아웃은 바뀌지 않습니다.
안전한 minimum attempts 값은 얼마인가요?
안전한 값은 채널 규모, 기기 구성, 네트워크 품질 및 릴리스 리스크에 따라 달라집니다. 통제된 테스트 채널에는 낮은 임계값을 사용하고, 광범위한 프로덕션 롤아웃에는 높은 임계값을 사용하세요. 먼저 특정 그룹으로 시작해 시도량을 모니터링하고, 관찰된 동작에 따라 조정하세요.
minimum attempts 값에 도달하면 항상 릴리스가 일시 중지되나요?
아니요. Capgo minimum attempts 값에 도달하면 롤아웃이 auto-pause 대상이 되지만, 다른 정책 조건도 여전히 중요합니다. 실패 신호, 신뢰도 설정, 채널 상태 및 updater flow가 결과에 영향을 미칠 수 있습니다. 프로덕션에서 이 기능에 의존하기 전에 안전한 bundle로 전체 pause 경로를 테스트하세요.
auto-pause가 롤백 계획을 대체할 수 있나요?
아니요. auto-pause는 추가 노출을 중지하거나 제한하는 반면, rollback은 해당 경로를 사용할 수 있을 때 사용자를 검증된 bundle로 이동시킵니다. 두 제어 방식을 모두 테스트하세요. 또한 OTA rollback으로는 설치된 앱에 없는 네이티브 기능을 추가할 수 없다는 점도 기억하세요.
결론
채널별 최소 시도 횟수(minimum attempts)를 설정할 때는 습관적으로 정하지 마세요. 먼저 소규모 테스트 롤아웃으로 시작하여 일시 중지(pause) 및 롤백(rollback) 경로를 검증한 뒤, 승인된 설정을 CI/CD에 자동화하여 적용하세요. 워크플로우를 테스트하고 싶다면, 롤아웃을 확장하기 전에 하나의 채널과 제어된 하나의 bundle로 Capgo를 시도해 보세요.
