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