배포를 멈출 기준: 롤백 판단을 지표로 정하는 법

롤백은 배포가 마음에 들지 않을 때 누르는 취소 버튼이 아니라, 사용자 영향이 계속 커지는 것을 막기 위한 사전 합의된 의사결정입니다. 배포 전 정상 기준선과 관찰 시간창, 중단 조건을 정하고, 배포 중에는 오류율·지연·핵심 업무 성공률을 같은 대시보드에서 확인해야 합니다.

중요한 것은 ‘문제가 생기면 롤백한다’가 아니라 어떤 신호가 어느 시간 동안 지속될 때 멈출지를 숫자로 쓰는 일입니다. 일시적 경보는 완화로 지켜볼 수 있지만, 임계치를 넘은 고객 영향이 회복되지 않으면 자동화된 절차와 승인자를 통해 롤백으로 전환합니다.

배포 전 기준선을 먼저 고정하기

최근 정상 구간의 수치를 기준선으로 저장합니다. 평균만 기록하면 꼬리 지연이나 특정 지역의 실패를 놓치므로 성공률, p95 지연, 오류율, 처리량을 함께 봅니다. 핵심 업무는 서비스마다 다르므로 로그인 성공, 주문 완료, 파일 업로드처럼 사용자가 실제로 끝내야 하는 흐름을 별도 지표로 정의합니다. 기준선에는 측정 창과 데이터 지연도 적어야 합니다.

• 배포 전 정상 기준선과 비교할 측정 창을 정합니다.

• 핵심 사용자 여정의 성공 조건을 하나 이상의 지표로 표현합니다.

• 롤백 실행자, 승인자, 연락 채널을 배포 기록에 연결합니다.

• 데이터가 늦게 들어오는 지표의 판정 지연을 명시합니다.

중단과 롤백을 가르는 임계치

중단은 추가 확산을 멈추는 조치이고, 롤백은 이전 버전이나 안전한 구성으로 되돌리는 조치입니다. 예를 들어 오류율이 기준선보다 높지만 고객 성공률이 유지되면 확산을 멈추고 원인을 조사할 수 있습니다. 반대로 핵심 성공률이 임계치 아래로 내려가고 두 측정 창 연속으로 회복되지 않으면 롤백 조건을 충족한 것으로 봅니다. 임계치는 서비스의 위험도와 복구 시간을 반영해 정합니다.

시간창과 표본의 함정

한 번의 오류 스파이크로 롤백하면 정상적인 외부 요인을 배포 결함으로 오인할 수 있고, 긴 평균 창만 보면 급격한 악화를 늦게 발견합니다. 짧은 탐지 창으로 즉시 확산을 멈추고, 더 긴 확인 창으로 지속성을 검증하는 이중 기준이 실무에 적합합니다. 트래픽이 적은 시간에는 비율의 분모가 작아지므로 최소 표본 수나 절대 오류 건수 조건을 함께 둡니다.

완화가 가능한 경우와 즉시 되돌릴 경우

기능 플래그를 끄거나 트래픽 비율을 줄여 영향이 빠르게 줄어드는 경우에는 롤백보다 완화가 안전할 수 있습니다. 다만 완화가 핵심 데이터의 무결성, 인증, 결제에 영향을 주는 결함을 해결하지 못한다면 즉시 되돌려야 합니다. 판단자는 ‘고칠 수 있는가’보다 ‘안전한 상태를 얼마나 빨리 회복하는가’를 비교하고, 고객에게 남은 영향과 복구 예상 시간을 기록합니다.

1. 임계치 초과 신호와 측정 창이 실제로 충족됐는지 확인합니다.

2. 확산 중단과 기능 플래그 등 즉시 가능한 완화의 효과를 확인합니다.

3. 데이터 손상·보안·결제 위험이면 완화 실험을 생략하고 롤백합니다.

4. 결정 시각, 지표 값, 승인자, 실행 결과를 한 기록에 남깁니다.

롤백 후 검증과 재배포 조건

이전 버전으로 전환됐다는 로그만으로 복구를 선언하지 않습니다. 핵심 사용자 여정의 합성 테스트, 오류율과 지연의 기준선 복귀, 큐와 데이터 정합성, 외부 의존성의 상태를 확인합니다. 롤백 자체가 실패할 때 사용할 정적 안전 버전과 수동 절차도 배포 전에 검증해야 합니다. 같은 변경을 다시 배포하려면 원인과 수정 검증, 관측 담당자가 모두 지정되어야 합니다.

팀이 합의했는지 확인하는 체크리스트

판단 기준은 문서에만 있으면 작동하지 않습니다. 배포 전 리뷰에서 지표의 소유자와 임계치를 소리 내어 확인하고, 모의 장애에서 알림부터 롤백과 복구 확인까지 시간을 재세요. 다음 질문에 답할 수 있으면 기준이 운영 가능한 상태입니다.

• 어떤 지표가 어느 값과 시간창에서 배포를 멈추게 하는가?

• 누가 롤백을 승인하고, 승인자가 응답하지 않으면 누가 대체하는가?

• 복구가 완료됐다고 판단할 독립적인 증거는 무엇인가?

• 다시 배포하기 전에 어떤 원인 분석과 테스트를 통과해야 하는가?

롤백 기준의 목적은 배포를 두려워하게 만드는 데 있지 않습니다. 관찰 가능한 신호와 권한 경계를 미리 합의해 팀이 같은 정보를 보고 빠르게 안전한 상태로 돌아가게 하는 데 있습니다. 기준을 실제 사고 기록으로 정기적으로 조정하되, 임계치를 낮춰 책임을 피하는 식의 변경은 피해야 합니다.