Capgo Rollout 일시 중지 vs Rollback: 각각 언제 사용할까?

일시 중지는 rollout이 더 많은 기기에 도달하는 것을 막습니다. 롤백은 영향을 받은 기기를 검증된 정상 버전으로 되돌립니다. Capgo 두 가지를 모두 지원하므로, 먼저 문제를 격리한 뒤 다음 조치를 결정할 수 있습니다.

이 단계를 따라 적절한 조치를 선택하고, 그 효과를 확인하고, 같은 장애가 재발할 가능성을 줄이세요.

Google Play, Amazon Appstore, Microsoft의 CodePush, Bitrise, Nearform, Digia에서 발표한 staged rollout 및 rollback 관련 공개 가이드 6개를 분석했습니다. 6개 중 4개는 일시 중지와 롤백을 별개의 조치로 구분했지만, 2개는 롤백을 생략하거나 일시 중지만을 유일한 수단으로 다루었습니다. 또한 6개 가이드 모두 분석 데이터나 기기 점검으로 복구 여부를 확인하는 방법도, 재발 방지 워크플로우도 설명하지 않았습니다. 일시 중지와 롤백 중 올바른 선택을 하고 그 결과를 확인하는 과정은 공개 릴리스 가이드 전반에 남아 있던 공백을 메워줍니다.

목차

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

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

사건 발생 전, 팀이 어떤 채널이 릴리스를 전달하고 어떤 번들이 안정적인지 확인해야 합니다. 채널은 앱 기기를 업데이트로 유도하는 이름이 지정된 레인입니다. 번들은 해당 레인을 통해 전송되는 업데이트 가능한 웹 code입니다.

Capgo에서 점진적 롤아웃은 안정적인 번드를 유지하면서 선택된 그룹에 별도의 롤아웃 대상만 전송할 수 있습니다. 이는 새 번드가 더 넓은 사용자 기반에 도달하기 전에 제어 지점을 제공합니다. 검토하십시오 점진적 롤아웃 제어 프로덕션에서 활성화하기 전에.

릴리스 담당자와 롤아웃 확대를 중단해야 할 신호를 미리 적어 두세요. 예를 들어 업데이트 실패가 늘거나, 주요 화면이 작동하지 않거나, 지원팀에서 사용자가 작업을 완료할 수 없다고 보고하면 팀이 어떻게 대응할지 정하세요. 단순히 엄격해 보이는 수치를 고르기보다 앱의 정상 동작을 기준으로 한계치를 설정하세요.

OTA 업데이트는 앱의 업데이트 가능한 code를 무선으로 변경합니다. 앱 스토어에서 설치한 네이티브 앱 바이너리를 교체하는 것은 아닙니다. over-the-air 업데이트라는 용어는 이런 전달 방식을 뜻합니다. 이 경계를 기억하세요. 수정에 새 네이티브 플러그인이 필요하거나 앱의 네이티브 설정을 바꿔야 한다면 번들 롤백으로는 해결할 수 없습니다.

릴리스 전에 안정 번들이 예상한 번들인지 확인하세요. 채널 이름, 대상 번들, 롤아웃 상태를 점검하세요. 채널 이름의 오타나 오래된 대상 설정은 1분 1초가 급한 상황에서 대응 담당자가 잘못된 컨트롤을 조작하게 만들 수 있습니다.

이제 지정된 릴리스 담당자, 검증된 번들, 문서화된 중단 조건이 있어야 합니다. 이 준비가 있으면 다음 결정은 대시보드를 허둥대며 찾는 일이 아니라 운영상의 선택이 됩니다.

핵심 요약: 일시 중지는 새 노출을 제한합니다. 롤백은 사용자가 받도록 지정된 버전을 바꿉니다.

2단계: 일시 중지 또는 롤백 선택

Capgo에서 롤아웃 일시중지(pause)와 롤백(rollback) 중 무엇을 선택할지 고민된다면, 먼저 한 가지만 물어보세요. 더 많은 기기가 대상 버전을 받도록 막고 싶은 건지, 이미 문제를 일으키고 있는 대상 버전에서 기기를 빼내려는 건지. 일시중지는 새로운 노출을 제한합니다. 롤백은 대상 버전을 제거하고, 다음 업데이트 확인 시 기기를 안정적인 폴백 버전으로 되돌립니다.

증거가 불완전하거나 문제가 제한적으로 보일 때는 일시중지를 선택하세요. 보고가 몇 건 있을 뿐, 버그가 특정 기기 유형, 특정 사용자 플로우, 아니면 업데이트된 모든 기기에 영향을 미치는지 알 수 없는 상황일 수 있습니다. 일시중지는 팀이 새로운 기기를 롤아웃 그룹에 추가하지 않고 신호를 점검할 수 있는 시간을 확보해 줍니다.

사용자에게 명백히 위험하거나, 팀이 알려진 정상 번들이 더 안전하다는 충분한 근거를 확보한 경우 롤백을 선택하세요. 일시 정지만으로는 이미 롤아웃 코호트에 포함된 기기에서 잘못된 타겟을 제거하지 못합니다. 해당 사용자가 안정된 버전으로 돌아가야 한다면, 업데이트 경로를 변경하는 조치는 롤백입니다.

이 Capgo 채널 CLI 참조 일시 정지와 롤백 컨트롤을 별도로 나열합니다. 이를 동일한 비상 정지 기능의 두 가지 이름이 아닌, 서로 다른 동작으로 취급하세요.

롤백은 백엔드 장애를 해결하지 못하며, 누락된 네이티브 기능을 추가할 수도 없습니다. 먼저 어떤 계층에서 실패했는지 식별하세요. 웹 bundle에 문제가 있다면, 구제가 필요한 사용자 수에 따라 일시 중지와 되돌리기 중 하나를 선택하세요.

3단계: 원인 조사 중 추가 노출 일시 중지

새로운 기기가 롤아웃 그룹에 들어오는 것을 막아야 하지만, 이미 그룹에 있는 기기의 대상을 되돌릴 준비가 되지 않은 경우 일시 중지하세요. 이는 격리 단계입니다. 문제를 더 많은 사용자로 확산되는 것을 막으면서 사실을 확인하기 위한 시간을 벌 수 있습니다.

프로덕션 채널을 열고 영향받은 롤아웃에 대해 작업하고 있는지 확인하세요. 대시보드, CLI, 또는 팀이 사용하는 API로 일시 중지하세요. 그런 다음 채널 상태를 다시 읽어보세요. 명령이 성공적으로 완료되었다는 것만으로는 충분하지 않습니다. 롤아웃이 이제 일시 중지된 것으로 표시되는지 확인하세요.

Capgo의 점진적 배포 모델에서, 이미 코호트에 포함된 기기는 일시 정지 후에도 배포 대상 버전을 유지할 수 있습니다. 새로 대상이 되는 기기는 다음 확인 시점에 안정적인 폴백 버전을 받게 됩니다. 이 구분이 중요합니다. 일시 정지는 새로운 기기의 진입만 막을 뿐, 기존 코호트를 자동으로 안정 버전으로 되돌리지 않습니다.

다음으로, 추가 변경 사항을 적용하기 전에 릴리스 세부 정보를 기록하세요. 대상 bundle, channel, 일시 정지 시각, 그리고 최초 알려진 보고 내용을 기록합니다. 팀이 수집할 수 있는 권한이 있는 기기 또는 세션 세부 정보도 함께 남겨 두세요. 명확한 타임라인은 배포 코호트와 여전히 안정 bundle을 사용하는 기기를 비교하는 데 도움이 됩니다.

재현 가능한 경로를 통해 문제를 확인하세요. 사용자가 로그인 실패를 보고했다면, 영향받은 기기에서 해당 여정을 정확히 테스트해 보세요. 앱이 시작 시 크래시된다면, 그 크래시가 새로운 bundle과 네이티브 앱 버전과 일치하는지 확인하세요. 모든 지원 보고를 업데이트가 문제를 일으킨 증거로 단정하지 마세요.

조사 책임자와 의사 결정 시점을 정하세요. 다음 조치를 책임질 사람이 없으면 중단된 rollout이 표류할 수 있습니다. 책임자는 증거로 릴리스가 안전하다고 확인되면 재개하고, 대상이 여전히 안전하지 않으면 롤백을 선택해야 합니다.

유용한 팁: 지원 팀과 릴리스 팀에 rollout이 중단되었음을 알리세요. 그렇지 않으면 한 팀은 계속 리포트를 에스컬레이션하고, 다른 팀은 이미 롤백된 줄 알 수 있습니다.

이 시점에는 새 기기가 더 이상 rollout 코호트에 들어오지 않아야 합니다. 롤백이나 재개로 넘어가기 전에 채널 상태와 코호트에 없던 기기의 동작을 확인하세요.

4단계: 사용자에게 안정적인 버전이 필요할 때 롤백

이미 대상 버전을 쓰는 사용자가 검증된 정상 bundle로 돌아가야 할 때 롤백하세요. 중단보다 강한 대응입니다. 채널이 제공하는 내용이 바뀌므로, 실행을 확정하기 전에 선택한 안정적인 빌드가 맞는지 확인하세요.

Capgo에서 영향을 받은 채널을 열고 빌드 히스토리를 검토하세요. 복구할 버전을 선택한 다음, 이 앱과 채널에 맞는 올바른 안정적인 bundle인지 확인하세요. Capgo의 rollback 문서에는 대시보드 경로가 설명되어 있고, 기기가 다음 업데이트를 확인할 때 선택한 빌드를 받는다는 점도 언급되어 있습니다.

롤백 후에는 모든 기기가 한 번에 바뀌었다고 가정하지 마세요. 기기는 업데이트를 확인해야 하고, 오프라인 사용자는 나중에야 확인할 수도 있습니다. 채널의 활성 버전을 확인하고 영향을 받은 코호트의 기기에서 복구 경로를 테스트할 때까지 인시던트를 종료하지 마세요.

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

보관 정책에서 달리 정하지 않은 한, 분석할 수 있도록 장애를 일으킨 번들을 남겨 두세요. Release ID와 commit은 엔지니어가 변경 사항을 안정 버전과 비교하는 데 도움이 됩니다. 특히 이슈가 왜 테스트에서 걸러지지 않았는지 이해해야 한다면 정리 전에 관련 logs를 보존하세요.

Rollback이 모든 장애에 맞는 해결책은 아닙니다. 근본 원인이 서버 측 의존성이라면 해당 서비스를 수정하세요. 변경 사항이 설치된 바이너리에 없는 네이티브 code에 의존한다면, Native Build를 준비하고 해당 변경 사항은 앱 스토어 출시 경로를 따르세요.

5단계: 분석과 기기 점검으로 복구 확인

Pause 또는 Rollback 후에는 제어 변경을 복구의 증거로 삼지 말고, 기기가 실제로 어떤 상태인지 확인하세요. 먼저 활성 channel 상태를 확인한 다음, 영향을 받은 release와 안정 버전 간의 업데이트 채택률, 에러, 기기 리포트를 비교하세요.

Capgo의 live update analytics를 사용하면 채택 지표, 에러율, 디바이스별 logs를 검토할 수 있습니다. 이 신호를 바탕으로 다음 질문에 답해 보세요. 새 디바이스가 여전히 target을 받고 있는지, 영향받은 디바이스가 stable bundle을 확인 중인지, 복구 후 보고된 실패가 멈췄는지 확인하세요.

실패한 사용자 경로를 테스트하세요. 다운로드가 성공했다고 앱이 정상 작동하는 건 아닙니다. 관련 화면을 열고 보고로 이어진 동작을 다시 수행해 앱이 예상 상태에 도달하는지 확인하세요. 인시던트가 중요한 flow와 관련 있다면, 변경한 사람이 아닌 다른 사람이 결과를 확인하게 하세요.

같은 조건끼리 비교하세요. 서비스 이슈나 트래픽 변화처럼 릴리스와 무관한 이유로 전체 에러 수가 늘 수 있습니다. 해당 필드가 있으면 bundle, channel, app version, device로 필터링하세요. 기본적으로 최신 업데이트 탓으로 돌리지 말고 릴리스와 연관된 차이를 찾으세요.

업데이트하지 않은 사용자도 확인하세요. 이들이 포함되면 전체 지표는 정상처럼 보여도 영향받는 코호트는 여전히 버그를 겪을 수 있습니다. target 디바이스 비중과 stable 디바이스 비중을 추적하고, 지원 보고가 사용자가 실제 실행 중인 버전과 연결되도록 유지하세요.

복구 결과와 남은 불확실성을 기록하세요. 에러가 줄었는데도 일부 사용자가 같은 문제를 보고한다면, 그들이 오프라인인지, 구버전 native shell을 쓰는지, 아니면 여전히 영향받은 bundle을 사용 중인지 파악하기 전까지 인시던트를 닫지 마세요.

채널이 의도한 버전을 가리키고, 문제를 재현할 수 있는 디바이스에서 실패했던 사용자 경로가 정상 작동하는 것을 확인하면 복구 완료입니다. 메트릭은 문제의 형태를 파악하는 데 도움이 되지만, 실제 사용자가 경험하는 것은 디바이스 확인으로 검증합니다.

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

배포 전에 일시중지와 롤백을 릴리스 계획에 포함하세요. 릴리스 담당자는 누가 노출을 중단할 수 있고, 누가 안정 버전 복귀를 승인할 수 있는지 알아야 합니다. 이렇게 하면 롤아웃에 더 많은 기기가 참여하는 동안 회의를 기다리는 일반적인 지연을 제거할 수 있습니다.

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

테스트를 실행하고 변경 사항을 배포하는 자동화 프로세스인 CI/CD에 릴리스 체크를 추가하세요. 파이프라인은 테스트가 통과한 후 번들을 의도된 채널에 게시할 수 있습니다. 채널이 잘못되었거나 릴리스가 승격 준비가 되지 않은 경우에도 안전하게 실패하도록 설정해야 합니다.

지속적 배포 워크플로우는 자동화 프로세스를 통해 소프트웨어가 릴리스 준비 상태를 유지하도록 합니다. OTA 워크플로우의 경우, 게시가 자동화되어 있더라도 인간 승인 지점을 명확히 유지하세요. 자동화는 선택된 작업을 반복 가능하게 만들어야 하며, 검토되지 않은 변경 사항에 대한 결정을 내리는 것이 아닙니다.

Capgo를 사용하면 명령 한 번으로 채널에 번들을 게시할 수 있습니다. 이 명령을 체크와 같은 릴리스 프로세스에 두고, 배포 기록에 대상 채널을 드러내세요. 그러면 온콜 엔지니어가 어느 채널로 갔는지 추측하지 않고 무엇이 배포됐는지 정확히 볼 수 있습니다.

자동 세이프가드를 활성화하기 전에 어떤 신호가 트리거이고 어떤 조치를 하는지 정의하세요. Pause는 현재 코호트 기기를 대상에 유지하면서 새 노출을 중단할 수 있습니다. Rollback은 기기를 안정 버전으로 유도할 수 있습니다. 결과가 다르므로 하나를 다른 것처럼 설정하지 마세요.

테스트 채널에서 전체 대응을 리허설하세요. 무해한 변경을 게시하고 Pause 제어를 확인한 다음, 이전 번들로의 Rollback을 테스트합니다. 각 조치 후 기기에서 앱 동작을 확인하세요. 문서화된 런북에는 채널, 명령 또는 대시보드 경로, 예상 상태, 성공을 확인할 담당자가 포함되어야 합니다.

릴리스 노트에는 번들과 목적을 밝히세요. 에러가 나타났을 때 엔지니어가 범위를 좁힐 수 있도록 배포 기록과 소스 변경을 연결해 두세요. 팀이 시간대를 넘어 인시던트를 인계한다면 마지막 조치와 다음 결정 담당자를 포함하세요.

인시던트가 더 광범위한 프론트엔드 구현 병목을 가리킨다면, 다음과 같은 웹 개발자가 아미르 아레주 웹사이트 개발 작업과 관련이 있을 수 있습니다. 이는 호환되는 앱 업데이트의 전달과 복구를 처리하는 Capgo의 롤아웃 제어와는 별개입니다.

지금쯤이면 릴리스 경로에 안정적인 폴백, 담당자, 중단 규칙, 그리고 테스트된 복구 액션이 포함되어야 합니다. 온콜 엔지니어가 압박 상황에서도 사용할 수 있도록 워크플로우를 간결하게 유지하세요.

자주 묻는 질문

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

아니요. 일시 정지(Pause)는 롤아웃 대상이 되는 새 기기의 진입을 막지만, 이미 코호트에 포함된 기기는 대상 번들을 유지할 수 있습니다. 해당 사용자를 안정 버전으로 되돌리려면 롤백(rollback) 또는 다른 의도적인 채널 작업을 사용하세요. 변경 후 채널 상태를 확인하고, 대상 번들을 받은 기기에서 결과를 검증하세요.

롤백 대신 언제 일시 중지해야 하나요?

문제가 아직 조사 중이고 더 넓은 노출을 막아야 할 때는 일시 정지(Pause)를, 대상 번들이 사용자에게 해를 끼치는 것으로 확인되었거나 영향받은 기기에 안정 번들이 필요할 때는 롤백(rollback)을 사용하세요. Capgo 일시 정지 vs 롤백 선택은 기존 코호트에 대한 즉각적인 필요 사항이 격리(containment)인지 복구(recovery)인지에 따라 달라집니다.

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

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

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

아니요. OTA 롤백은 이전 업데이트 가능한 웹 번들을 복원할 수 있지만, 설치된 앱 바이너리 내부의 네이티브 code를 추가하거나 제거할 수는 없습니다. 문제가 네이티브 플러그인이나 앱 셸 변경에서 비롯된 경우, 새로운 네이티브 빌드가 필요한지 평가하세요. 먼저 어떤 레이어에서 실패가 발생했는지 식별하세요.

일시 중지하거나 롤백한 후 무엇을 확인해야 하나요?

채널 상태와 활성 번들을 확인한 후 릴리스별 업데이트 채택률과 오류를 점검하세요. 영향받은 그룹의 기기에서 실패한 사용자 여정을 테스트하고, 아직 업데이트되지 않은 기기까지 확인하세요. 전체 지표는 특정 버전이나 코호트에 국한된 문제를 가릴 수 있기 때문입니다.

마치며

조사 중 새로운 노출을 중단해야 할 때는 일시 정지(Pause)를, 대상 사용자가 안정된 버전이 필요할 때는 롤백을 사용하세요. 두 컨트롤을 사전에 설정해 두고 다음 프로덕션 릴리스 전에 테스트 채널에서 리허설을 진행하세요.