Capgo Pause Rollout vs Rollback: 상황별 사용 가이드

Pause는 rollout이 더 많은 기기에 도달하지 않도록 차단합니다. Rollback은 문제가 발생한 기기들을 검증된 안정적인 버전으로 되돌립니다. Capgo 두 기능 모두 지원하므로, 먼저 문제를 격리한 뒤 다음 조치를 결정할 수 있습니다.

이 가이드를 통해 적절한 조치를 선택하고, 효과를 점검하며, 동일한 장애가 재발하지 않도록 방지하세요.

Google Play, Amazon Appstore, Microsoft의 CodePush, Bitrise, Nearform, Digia에서 발행한 staged rollout 및 rollback 관련 공개 가이드 6종을 분석했습니다. 분석 결과, 6개 중 4개는 pause와 rollback을 별개의 조치로 구분했지만, 2개는 rollback을 생략하거나 pause만을 유일한 수단으로 다루고 있었습니다. 또한 6개 가이드 모두 분석 데이터나 기기 점검을 통한 복구 확인 방법이나, 장애 재발 방지를 위한 워크플로우를 설명하지 않았습니다. 올바른 pause vs rollback 선택과 실행 결과 확인은 기존 공개 가이드들이 놓치고 있는 공백을 메워줍니다.

목차

• 1단계: Capgo에서 릴리스 제어 설정
• 2단계: 일시 중지 또는 롤백 선택
• 3단계: 원인 조사 중 추가 노출 일시 중지
• 4단계: 안정적인 버전이 필요할 때 롤백
• 5단계: 분석 및 기기 체크로 복구 확인
• 6단계: 안전한 릴리스 워크플로우로 재발 방지
• 자주 묻는 질문
• 결론

1단계: Capgo에서 릴리스 제어 설정

장애 발생 전, 팀이 어떤 채널을 통해 릴리스를 배포 중인지, 어떤 번들이 안정적인지 파악하고 있어야 합니다. 채널은 앱 기기를 특정 업데이트로 안내하는 이름이 지정된 경로입니다. 번들은 해당 경로를 통해 전송되는 업데이트 가능한 웹 code입니다.

Capgo의 점진적 롤아웃(progressive rollout)을 사용하면, 기존의 안정적인 번들을 유지하면서 선택된 그룹에만 별도의 롤아웃 대상을 보낼 수 있습니다. 이를 통해 새로운 번들이 더 넓은 사용자층에 도달하기 전 제어 지점을 확보할 수 있습니다. 다음의 점진적 롤아웃 제어 기능을 검토해 보세요 프로덕션에 적용하기 전에 말이죠.

배포 담당자와 확장을 중단해야 할 신호를 미리 기록해 두세요. 예를 들어, 업데이트 실패율이 증가하거나, 주요 화면이 작동하지 않거나, 고객 지원팀으로부터 사용자가 특정 작업을 완료할 수 없다는 보고가 들어올 경우 팀이 어떻게 대응할지 결정해야 합니다. 단순히 엄격해 보이는 수치를 정하기보다, 앱의 정상적인 동작 범위를 기준으로 한계치를 설정하세요.

OTA 업데이트는 앱의 업데이트 가능한 code를 무선으로 변경합니다. 앱 스토어에서 설치한 네이티브 앱 바이너리를 교체하는 것이 아닙니다. 'over-the-air'라는 용어는 이러한 전달 방식을 의미합니다. 이 경계를 명확히 인지해야 합니다. 만약 수정 사항에 새로운 네이티브 플러그인이 필요하거나 앱의 네이티브 설정 변경이 수반된다면, 번들 롤백만으로는 이를 해결할 수 없습니다.

배포 전, 안정적인 번들이 의도한 것이 맞는지 확인하세요. 채널 이름, 대상 번들, 롤아웃 상태를 점검해야 합니다. 채널 이름의 오타나 잘못된 대상 설정은 1분 1초가 급한 상황에서 대응 방향을 잘못 잡게 만들 수 있습니다.

이제 배포 담당자, 검증된 번들, 그리고 명문화된 중단 조건이 준비되었습니다. 이러한 준비가 되어 있다면, 다음 결정은 대시보드에서 허둥지둥 찾는 과정이 아니라 운영상의 선택이 될 것입니다.

핵심 요약: Pause는 새로운 노출을 제한합니다. Rollback은 사용자가 받게 될 버전을 변경합니다.

2단계: Pause할지 Rollback할지 선택하기

Capgo pause rollout과 rollback 사이에서 고민 중이라면, 먼저 이 질문을 던져보세요. 타겟 업데이트를 받는 기기를 더 이상 늘리지 않으려는 것인가요, 아니면 이미 문제를 일으키고 있는 타겟에서 기기들을 벗어나게 하려는 것인가요? Pause는 새로운 노출을 제한합니다. Rollback은 타겟을 제거하고, 다음 업데이트 확인 시 기기들을 안정적인 fallback 상태로 되돌립니다.

증거가 불충분하거나 문제가 국한된 것으로 보일 때는 pause를 선택하세요. 몇 건의 리포트는 있지만, 버그가 특정 기기 유형인지, 특정 사용자 흐름인지, 아니면 업데이트된 모든 기기에 영향을 미치는지 확실하지 않을 수 있습니다. Pause를 사용하면 rollout 그룹에 새로운 기기를 추가하지 않고도 팀이 신호를 조사할 여유를 가질 수 있습니다.

타겟이 사용자에게 명백히 위험하거나, 기존의 검증된 bundle이 더 안전하다는 충분한 근거가 있다면 rollback을 선택하세요. Pause만으로는 이미 rollout 코호트에 포함된 기기에서 문제가 되는 타겟을 제거할 수 없습니다. 해당 사용자들이 안정적인 버전으로 돌아가야 한다면, 업데이트 경로를 변경하는 작업은 rollback입니다.

이 Capgo 채널 CLI 참조 별도의 pause 및 rollback 컨트롤을 제공합니다. 이 둘을 동일한 긴급 중단 기능의 다른 이름이 아닌, 서로 다른 작업으로 취급해야 합니다.

롤백은 백엔드 장애를 해결하거나 누락된 네이티브 기능을 추가할 수 없습니다. 먼저 어느 레이어에서 문제가 발생했는지 파악하세요. 웹 번들이 원인이라면, 사용자에게 얼마나 빠른 조치가 필요한지에 따라 일시 중지와 롤백 중 하나를 선택하세요.

3단계: 조사하는 동안 노출을 일시 중지

이미 롤아웃 그룹에 포함된 기기의 타겟을 되돌릴 준비는 되지 않았지만, 새 기기가 롤아웃 그룹에 진입하는 것을 막아야 할 때 Pause를 사용하세요. 이는 확산을 방지하기 위한 격리 단계입니다. 문제를 더 많은 사용자에게 퍼뜨리지 않으면서 사실 관계를 확인할 시간을 벌어줍니다.

프로덕션 채널을 열고 영향받은 롤아웃을 대상으로 작업 중인지 확인하세요. 대시보드, CLI, 또는 팀에서 쓰는 API 제어 방식으로 Pause하세요. 그런 다음 채널 상태를 다시 조회하세요. 명령이 성공적으로 끝났다는 것만 믿지 말고, 롤아웃이 실제로 paused로 표시되는지 확인하세요.

Capgo의 점진적 롤아웃 모델에서 Pause 후에도 이미 코호트에 포함된 기기는 롤아웃 타겟에 남을 수 있습니다. 새로 대상이 된 기기는 다음 체크 때 stable fallback을 받습니다. 이 구분이 중요합니다. Pause는 신규 진입을 막을 뿐, 그 자체로 기존 코호트를 stable로 되돌리지는 않습니다.

다음으로, 다른 변경을 하기 전에 릴리스 세부 정보를 기록하세요. 타겟 번들, 채널, Pause 시점, 최초로 알려진 보고를 기록합니다. 팀이 수집해도 되는 기기 또는 세션 정보는 보관하세요. 명확한 타임라인은 롤아웃 코호트와 아직 stable 번들에 있는 기기를 비교하는 데 도움이 됩니다.

재현 가능한 경로로 이슈를 확인하세요. 사용자가 로그인 실패를 보고하면, 영향받은 기기에서 해당 흐름을 그대로 테스트하세요. 앱 실행 시 크래시가 나면, 그 크래시가 새 번들 및 네이티브 앱 버전과 맞는지 확인하세요. 모든 지원 보고를 업데이트가 문제를 일으켰다는 증거로 단정하지 마세요.

조사 담당자와 의사 결정 시간을 미리 정해두세요. 다음 단계를 결정할 담당자가 없으면 중단된 rollout이 방치될 수 있습니다. 담당자는 증거를 통해 릴리스가 안전하다고 판단되면 다시 재개하거나, 여전히 위험하다고 판단되면 rollback을 선택해야 합니다.

꿀팁: 지원 팀과 릴리스 팀에 rollout이 중단되었음을 알리세요. 그렇지 않으면 한쪽에서는 계속 리포트를 에스컬레이션하고, 다른 쪽에서는 이미 롤백이 완료되었다고 오해할 수 있습니다.

이 시점부터는 새로운 디바이스가 rollout 코호트에 진입하지 않아야 합니다. rollback이나 재개를 진행하기 전에 채널 상태와 기존 코호트에 포함되지 않았던 디바이스의 동작을 확인하세요.

4단계: 사용자가 안정적인 버전이 필요한 경우 Roll back 실행

대상 버전을 사용 중인 사용자를 검증된 번들로 되돌려야 할 때 rollback을 실행합니다. 이는 중단(pause)보다 더 강력한 조치입니다. 채널에서 제공하는 번들 자체가 변경되므로, 작업을 확정하기 전에 선택한 stable build가 맞는지 반드시 확인하세요.

Capgo에서 문제가 발생한 채널을 열고 빌드 히스토리를 검토하세요. 복구하려는 버전을 선택한 다음, 해당 앱과 채널에 맞는 올바른 stable bundle인지 확인합니다. Capgo의 rollback 문서에는 대시보드 경로가 설명되어 있으며, 디바이스가 다음 업데이트를 확인하는 시점에 선택한 빌드를 받게 된다고 명시되어 있습니다.

rollback 후에는 모든 디바이스가 즉시 변경되었다고 가정해서는 안 됩니다. 디바이스가 업데이트를 확인해야 하며, 오프라인 사용자는 나중에 확인을 할 수도 있기 때문입니다. 채널의 활성 버전을 확인하고 문제가 된 코호트 내 디바이스로 복구 경로를 테스트할 때까지 인시던트를 종료하지 마세요.

내장된 번들을 사용하는 것은 의도한 복구 대상이 그럴 때뿐이어야 합니다. 이는 기기를 네이티브 앱 내부에 패키징된 웹 빌드로 되돌리는데, 이는 마지막 OTA 번들과 다를 수 있습니다. 복구 단계로 선택하기 전에 호환성과 사용자 영향을 반드시 확인하세요.

별도의 보관 프로세스가 없다면, 분석을 위해 장애를 일으킨 번들을 그대로 유지하세요. Release ID와 commit 정보는 엔지니어가 변경 사항을 안정적인 버전과 비교하는 데 도움이 됩니다. 특히 이슈가 왜 테스트를 통과했는지 파악해야 한다면, 정리하기 전에 관련 logs를 보존하세요.

Rollback이 모든 장애의 정답은 아닙니다. 근본 원인이 서버 측 종속성 문제라면 해당 서비스를 수정하세요. 만약 변경 사항이 설치된 바이너리에 없는 네이티브 code에 의존한다면, Native Build를 준비하고 앱 스토어 출시 절차를 따라야 합니다.

5단계: 분석 및 기기 점검을 통한 복구 확인

Pause 또는 Rollback 후에는 제어 변경 자체를 복구의 증거로 간주하지 말고, 실제 기기 상태를 확인하세요. 먼저 활성화된 channel 상태를 점검한 다음, 문제가 된 release와 안정적인 버전 간의 업데이트 채택률, 에러, 기기 보고를 비교하세요.

Capgo의 live update analytics를 사용하면 채택 지표, 에러율, 디바이스 레벨의 logs를 검토할 수 있습니다. 이러한 시그널을 통해 특정 질문에 대한 답을 찾아보세요. 새로운 디바이스가 여전히 타겟을 받고 있는지, 문제가 발생한 디바이스가 stable bundle을 확인하고 있는지, 그리고 복구 후 보고된 실패 사례가 중단되었는지 확인하십시오.

실패한 사용자 경로를 직접 테스트하세요. 다운로드가 성공했다고 해서 앱이 정상 작동한다는 뜻은 아닙니다. 관련 화면을 열고, 에러를 유발했던 동작을 반복하여 앱이 예상된 상태에 도달하는지 검증하십시오. 만약 해당 장애가 크리티컬한 flow와 관련되어 있다면, 변경을 수행한 사람 외에 다른 사람이 결과를 확인하도록 하세요.

동일한 조건끼리 비교해야 합니다. 서비스 이슈나 트래픽 변화처럼 릴리스와 무관한 이유로 전체 에러 수가 증가할 수 있습니다. 필터 기능을 활용해 bundle, channel, app version, device별로 데이터를 살펴보세요. 무조건 최신 업데이트를 탓하기보다 릴리스와 직접적으로 연관된 차이점이 있는지 찾아야 합니다.

업데이트를 하지 않은 사용자들도 확인해야 합니다. 이들이 포함되어 있으면 전체 지표는 정상처럼 보일 수 있지만, 실제 대상 코호트는 여전히 버그를 겪고 있을 수 있기 때문입니다. stable 버전 대비 타겟 버전의 디바이스 점유율을 추적하고, 고객 지원 리포트를 사용자가 실제로 실행 중인 버전과 연결하여 관리하세요.

복구 결과와 여전히 남아있는 불확실성을 기록하세요. 에러가 줄어들었더라도 일부 사용자가 동일한 문제를 보고한다면, 해당 사용자가 오프라인 상태인지, 구버전 native shell을 사용하는지, 혹은 여전히 문제가 있는 bundle을 사용 중인지 파악하기 전까지는 인시던트를 종료하지 마세요.

채널이 의도한 버전으로 설정되고, 문제가 발생했던 사용자 경로가 재현 기기에서 정상 작동하면 복구가 완료된 것입니다. 메트릭은 문제의 양상을 파악하는 데 도움을 주며, 기기 테스트는 실제 사용자가 겪는 현상을 확인해 줍니다.

6단계: 더 안전한 릴리스 워크플로우로 재발 방지

배포 전, pause와 rollback을 릴리스 계획에 포함하세요. 릴리스 담당자는 노출을 중단할 수 있는 사람과 안정적인 버전으로의 복구를 승인할 수 있는 사람이 누구인지 알고 있어야 합니다. 이를 통해 릴리스가 진행되는 동안 회의를 기다리느라 지연되는 상황을 방지할 수 있습니다.

롤아웃 대상을 테스트하는 동안에는 안정적인 fallback 버전을 지정해 두세요. 처음에는 작고 정의된 코호트(cohort)를 대상으로 시작하고, 합의된 헬스 시그널이 허용 범위 내에 있을 때만 범위를 확장하세요. Capgo는 채널 기반의 릴리스 제어를 지원하므로, 팀은 테스트와 광범위한 프로덕션 배포를 분리할 수 있습니다.

테스트를 실행하고 변경 사항을 배포하는 자동화 프로세스인 CI/CD에 릴리스 체크를 포함하세요. 파이프라인은 테스트 통과 후 번들을 의도한 채널에 배포할 수 있어야 합니다. 또한 채널이 잘못되었거나 릴리스가 프로모션 준비가 되지 않은 경우 안전하게 실패(fail) 처리되어야 합니다.

지속적 배포(Continuous Delivery) 워크플로우는 자동화된 프로세스를 통해 소프트웨어를 언제든 배포 가능한 상태로 유지합니다. OTA 워크플로우의 경우, 배포가 자동화되어 있더라도 사람이 승인하는 단계를 명확히 유지하세요. 자동화는 선택한 동작을 반복 가능하게 만들어야 하며, 검토되지 않은 변경 사항에 대해 스스로 결정을 내리게 해서는 안 됩니다.

Capgo를 사용하면 단 한 번의 명령으로 특정 채널에 번들을 배포할 수 있습니다. 배포 명령을 기존 검증 프로세스에 포함하고, 배포 기록에 대상 채널을 명시하세요. 그래야 온콜 엔지니어가 어떤 채널에 배포되었는지 추측할 필요 없이 정확히 무엇이 배포되었는지 확인할 수 있습니다.

자동 세이프가드(safeguards)를 활성화하기 전에, 어떤 신호가 트리거가 될지 그리고 어떤 조치를 취할지 정의해야 합니다. Pause는 현재 대상 그룹의 기기 상태를 유지하면서 새로운 노출을 중단합니다. 반면 Rollback은 기기를 안정적인 버전으로 되돌립니다. 두 결과는 다르므로, 하나를 다른 것과 동일하게 설정해서는 안 됩니다.

테스트 채널을 사용하여 전체 대응 과정을 연습해 보세요. 무해한 변경 사항을 배포하고, Pause 제어를 확인한 다음, 이전 번들로의 Rollback을 테스트합니다. 각 조치 후에는 실제 기기에서 앱 동작을 확인해야 합니다. 작성된 런북(runbook)에는 채널, 명령 또는 대시보드 경로, 예상 상태, 그리고 성공을 확인하는 담당자가 포함되어야 합니다.

릴리스 노트에는 번들과 그 목적이 명시되어야 합니다. 배포 기록과 소스 변경 사항을 연결해 두어야 에러 발생 시 엔지니어가 빠르게 원인을 좁힐 수 있습니다. 팀이 시차 때문에 인시던트를 인수인계해야 한다면, 마지막으로 취한 조치와 다음 의사결정권자를 포함하세요.

만약 인시던트의 원인이 더 넓은 범위의 프론트엔드 구현 병목 현상이라면, 다음과 같은 웹 개발자가 Amir Arezoo 웹사이트 개발 작업에 필요할 수 있습니다. 이는 호환 가능한 앱 업데이트의 배포 및 복구를 담당하는 Capgo의 롤아웃 제어 기능과는 별개의 영역입니다.

이제 릴리스 프로세스에는 안정적인 폴백(fallback), 담당자, 중단 규칙, 그리고 검증된 복구 조치가 포함되어 있어야 합니다. 온콜 엔지니어가 긴박한 상황에서도 즉시 실행할 수 있도록 워크플로우를 최대한 간결하게 유지하세요.

자주 묻는 질문

Capgo 롤아웃을 일시 중지하면 이미 업데이트된 기기들도 롤백되나요?

아니요. 일시 중지는 새로운 대상 기기가 롤아웃에 포함되는 것을 막을 뿐, 이미 해당 코호트에 포함된 기기는 타겟 번들을 그대로 유지할 수 있습니다. 해당 사용자들을 다시 안정적인 버전으로 되돌리려면 롤백이나 다른 채널 액션을 직접 수행해야 합니다. 변경 후에는 채널 상태를 확인하고, 타겟을 받은 기기에서 결과가 제대로 반영되었는지 검증하세요.

롤백 대신 일시 중지를 사용해야 하는 경우는 언제인가요?

문제를 조사 중이라 노출 범위를 일단 제한해야 한다면 일시 중지를 선택하세요. 타겟 번들이 사용자에게 해를 끼친다는 것이 확인되었거나, 영향을 받은 기기에 즉시 안정적인 번들이 필요하다면 롤백을 해야 합니다. Capgo 롤아웃 일시 중지와 롤백 사이의 선택은 현재 상황이 확산 방지가 우선인지, 기존 코호트의 복구가 우선인지에 따라 달라집니다.

롤백을 하면 모든 기기가 즉시 업데이트되나요?

아니요. 롤백은 채널이 가리키는 번들을 변경할 뿐이며, 기기는 다음 업데이트 체크 시점에 이를 수신합니다. 오프라인 상태인 기기는 다시 연결될 때까지 현재 번들을 유지할 수 있습니다. 채널 타겟을 확인한 후, 영향을 받은 기기들의 업데이트 상태를 점검하고 장애가 해결되었는지 판단하세요.

OTA 롤백으로 네이티브 앱 문제를 해결할 수 있나요?

아니요. OTA rollback을 통해 이전의 업데이트 가능한 웹 번들을 복구할 수는 있지만, 이미 설치된 앱 바이너리 내부의 네이티브 code를 추가하거나 제거할 수는 없습니다. 만약 문제가 네이티브 플러그인이나 앱 셸(app-shell) 변경에서 발생했다면, 새로운 Native Build가 필요한지 검토해야 합니다. 우선 어떤 레이어에서 오류가 발생했는지 파악하세요.

배포 중단(Pause) 또는 롤백(Rollback) 후 무엇을 확인해야 하나요?

채널 상태와 활성화된 번들을 확인한 다음, 릴리스별 업데이트 채택률과 에러를 점검하세요. 문제가 발생한 그룹의 기기에서 실패했던 사용자 여정을 직접 테스트해 보세요. 또한, 전체 지표에서는 특정 버전이나 코호트에 국한된 문제가 가려질 수 있으므로 아직 업데이트되지 않은 기기들도 함께 확인해야 합니다.

결론

조사하는 동안 새로운 노출을 막아야 한다면 Pause를 사용하세요. 타겟 사용자가 안정적인 버전이 필요하다면 Rollback을 사용하세요. 두 제어 기능을 미리 설정해 두고, 다음 프로덕션 배포 전에 테스트 채널에서 연습해 두는 것이 좋습니다.