rollback 보다 forward fix 가 빠를 때
배포 복구 전략에서 rollback 이 항상 정답이 아닌 이유와 판단 기준
rollback 이 느린 이유
보통 사고 나면 팀 반응이 빠르다. “롤백 해!” 그런데 막상 해보면 느리다.
- 배포 파이프라인이 단방향으로 설계된 경우, 이전 버전 태그를 찾고 재배포하는 데만 5~10분
- DB 마이그레이션이 붙어 있으면 rollback 자체를 막아둔 경우가 많음
- 마이크로서비스 환경에서 A → B → C 로 의존하는 구조면, A 만 롤백해도 B 가 새 스키마 응답을 기대하고 있어서 반쯤 터진 상태 유지
2026년 기준으로 우리 팀 내부 포스트모템 7건을 돌아보면, rollback 선택 후 실제 서비스 정상화까지 평균 18분이었다. forward fix 는 평균 9분. 두 배 차이가 난다. 물론 이건 상황에 따라 다르지만, 적어도 “롤백이 항상 더 빠르다” 는 전제는 틀렸다.
forward fix 가 유리한 조건
조건을 명확히 안 하면 이 글이 “forward fix 무조건 해라” 로 읽힌다. 그건 아니다.
forward fix 가 유리한 경우:
- 버그가 특정 코드 경로 한 곳에 있고, 원인이 배포 5분 안에 파악됨
- 핫픽스 브랜치 → 빌드 → 배포 사이클이 3분 이내로 가능한 팀
- DB 마이그레이션이 이미 돌았고, 이전 버전이 새 스키마와 호환 안 됨
- feature flag 로 문제 기능만 껐을 때 나머지가 정상 동작
rollback 이 유리한 경우:
- 원인 파악이 15분 이상 걸릴 것 같을 때
- 새 코드가 여러 모듈에 걸쳐 있고 hotfix 범위가 불명확할 때
- 인프라 설정 변경(예: nginx 설정, 환경변수 오타)이 원인일 때 — 이건 그냥 revert 가 빠름
실제로 최근 사례. 결제 모듈 배포 후 특정 카드사 응답 파싱이 깨졌다. 원인은 배포 3분 만에 로그에서 잡혔다. response.data.result 를 response.data.payload.result 로 바꿔야 하는 한 줄짜리 fix. 이 상황에서 rollback 을 선택했다면 이전 빌드 아티팩트 찾고 파이프라인 다시 태우는 동안 더 많은 결제가 실패했을 거다. 그냥 hotfix PR 올리고 머지하고 배포했다. 7분.
반대 사례도 있다. 인증 서비스에 캐시 레이어를 새로 붙인 배포였는데, 배포 후 특정 사용자만 로그인 실패가 났다. 재현 조건을 못 찾겠고, 캐시 키 설계가 엮인 부분이 너무 많아서 hotfix 로 건드리면 더 터질 것 같았다. 이건 롤백했다. 맞는 판단이었다.
판단을 빠르게 만드는 것
막상 사고 나면 사람이 당황한다. 판단이 느려진다. 그래서 미리 기준을 팀 내 문서에 박아두는 게 중요하다.
우리 팀은 이렇게 정리했다:
사고 발생 후 5분 안에:
1. 원인 로그/트레이스 확인 가능? Y → forward fix 검토
2. fix 범위가 파일 3개 이하? Y → hotfix PR
3. 위 둘 중 하나라도 N → rollback 트리거숫자가 중요한 게 아니라 “누가 결정하는가” 가 더 중요하다. 사고 상황에서 5명이 슬랙에서 “롤백 해야 하는 거 아닌가요”, “아니 핫픽스가 빠를 것 같은데요” 를 반복하면 10분이 날아간다. 인시던트 오너 한 명이 위 기준 보고 5분 안에 결정하게 구조를 만드는 게 핵심이다.
feature flag 를 쓰면 이 판단 자체를 우회할 수 있다. 문제 기능 flag off → 서비스 정상화 → 천천히 원인 파악 → 고치고 flag on. 이게 제일 편한데, 모든 기능에 flag 를 붙이는 비용이 있으니 결제/인증/핵심 경로에만 적용하는 게 현실적이다.
다음 한 가지: 인시던트 발생 시 “rollback vs forward fix” 판단 기준을 팀 런북에 2문장으로 박아두기. 사고 나고 나서 정리하는 게 아니라 다음 배포 전에.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.