롤백할지 핫픽스할지 결정하는 기준

문제 정의

배포 후 문제가 생기면 “빨리 고치자”는 생각이 먼저 듭니다. 하지만 모든 문제를 핫픽스로 해결하려고 하면 장애 시간이 길어지고, 반대로 무조건 롤백하면 데이터 변경이나 외부 상태 때문에 더 큰 문제가 생길 수 있습니다.

롤백과 핫픽스는 감정이 아니라 기준으로 선택해야 합니다.

상황과 배경

작은 팀은 배포 담당자와 수정 담당자가 같은 경우가 많습니다. 이때 문제가 생기면 원인 분석, 코드 수정, 재배포, 사용자 안내를 동시에 처리하게 됩니다. 판단 기준이 없으면 가장 익숙한 작업을 선택하게 되고, 실제 사용자 영향은 뒤로 밀립니다.

배포 확인 기준은 smoke test 체크리스트에 먼저 포함되어야 합니다.

롤백과 핫픽스를 나누는 기준

• 롤백 우선: 로그인, 결제, 글 상세처럼 핵심 경로가 막혔고 이전 버전이 안전할 때 선택합니다.
• 핫픽스 우선: 원인이 명확하고 수정 범위가 작으며 즉시 검증 가능한 경우 선택합니다.
• 복구 우선: 데이터 손상이나 migration 실패가 있으면 코드보다 데이터 복구를 먼저 봅니다.
• 공지 우선: 사용자 행동이 계속 실패할 때는 해결 전에도 안내가 필요합니다.

실제 적용 방법

장애가 확인되면 먼저 영향 범위를 10분 안에 정리합니다. 공개 홈만 문제인지, API 전체 문제인지, 특정 글 상세만 문제인지 구분합니다. 다음으로 이전 버전이 현재 DB schema와 호환되는지 확인합니다. DB가 이미 변경됐다면 단순 롤백이 더 위험할 수 있습니다.

핫픽스를 선택했다면 수정할 파일과 검증할 URL을 먼저 적습니다. 이 범위가 두세 파일을 넘거나 검증 경로가 모호하다면 핫픽스가 아니라 새 배포 작업으로 보는 편이 안전합니다.

데이터 변경이 포함된 배포라면 DB 마이그레이션 체크리스트를 기준으로 되돌릴 수 있는지 판단해야 합니다.

운영 체크리스트

• 사용자 영향 경로와 시작 시간을 먼저 기록합니다.
• 이전 이미지나 커밋으로 돌아갈 수 있는지 확인합니다.
• DB schema가 이전 코드와 호환되는지 확인합니다.
• 핫픽스는 수정 범위와 검증 URL을 명확히 정한 뒤 진행합니다.
• 복구 후 원인과 다음 예방 조치를 런북에 추가합니다.

결론

좋은 릴리즈 운영은 실패가 없는 상태가 아니라 실패 후 선택이 빠른 상태입니다. 운영 런북에 롤백과 핫픽스 기준을 넣어 두면 다음 장애에서 훨씬 빠르게 움직일 수 있습니다.