rollback과 hotfix 중 무엇을 할지 결정할 때 어떤 기준을 사용하나요?

Question

Accepted Answer

기본은 **rollback**입니다 — 알려진 정상 상태로 복구하는 가장 빠르고 신뢰할 만한 방법입니다. rollback이 불가능하거나 앞으로 고치는 것보다 더 위험할 때에만 **hotfix**를 시도합니다. 진행 중인 incident에서 우선순위는 **먼저 출혈을 멈추고** 진단은 나중에 하는 것입니다.

## 의사결정 기준

- **rollback이 안전하고 가능한가?** 이전 버전이 알려진 정상이고 되돌릴 수 없는 일이 일어나지 않았다면 rollback하세요. 이것이 보통의 답입니다.
- **나쁜 릴리스가 되돌릴 수 없는 상태를 만들었는가?** **데이터베이스 마이그레이션**이나 데이터 손상은 rollback을 버그보다 더 나쁘게 만들 수 있습니다. 안전하게 되돌아갈 수 없다면, 앞으로 고쳐야 합니다.
- **수정을 이해하고 있는가?** rollback은 진단이 필요 없습니다 — 그것이 그 힘입니다. 완전히 이해하지 못한 hotfix는 incident를 더 깊게 만들 수 있습니다; 압박 속에서 추측을 프로덕션에 출시하지 마세요.
- **안전 상태까지의 시간.** 가장 적은 리스크로 가장 빠르게 안정에 도달하는 경로를 고르세요. 한 줄짜리, 잘 이해된 hotfix는 복잡한 rollback을 이길 수 있습니다; 위험한 앞으로 고치기는 깔끔한 revert를 결코 이기지 못합니다.
- **폭발 반경과 심각도.** 전면 장애는 가장 빠른 복구(보통 rollback)를 요구합니다; 경미한 저하는 신중한 hotfix를 허용할 수 있습니다.

## 빠른 의사결정 표

| 상황 | 선택 |
| --- | --- |
| 이전 버전 알려진 정상, 마이그레이션 없음 | Rollback |
| 되돌릴 수 없는 DB 마이그레이션 출시됨 | Hotfix / 앞으로 고치기 |
| 원인 미상, 심각한 영향 | Rollback (시간 벌기) |
| 사소하고 잘 이해된 한 줄짜리 | Hotfix |
| rollback 자체가 위험/미검증 | Hotfix |

## 트레이드오프와 함정

- **rollback**은 안전하지만 증상만 다룹니다 — 여전히 진짜 수정과 postmortem을 빚지고 있습니다.
- **hotfix**는 근본 원인을 다루지만 평소의 안전망을 건너뜁니다; hotfix의 버그가 흔한 것은 바로 그것이 급하게 만들어지기 때문입니다.
- **미검증 rollback 경로**는 함정입니다 — 한 번도 리허설하지 않았다면, 가장 필요할 때 실패할 수 있습니다. 필요해지기 전에 rollback을 연습하세요.
- 압박 속의 **프로덕션 디버깅**을 경계하세요; 확신 있는 수정까지 몇 분 이상 걸린다면, rollback하고 차분하게 조사하세요.

## 왜 중요한가

이 결정은 최악의 순간에 일어납니다 — 시스템 다운, 시계는 돌아가고, 모두가 보고 있습니다. 이에 대한 명확하고 리허설된 규칙을 가진 Tech Lead는 MTTR을 극적으로 줄이고, 지루한 revert가 바로 거기 있었는데도 incident 한복판에서 영리해지려는 고전적 실수를 방지합니다. 먼저 복구하고, 영리함은 나중에.

상황	선택
이전 버전 알려진 정상, 마이그레이션 없음	Rollback
되돌릴 수 없는 DB 마이그레이션 출시됨	Hotfix / 앞으로 고치기
원인 미상, 심각한 영향	Rollback (시간 벌기)
사소하고 잘 이해된 한 줄짜리	Hotfix
rollback 자체가 위험/미검증	Hotfix