롤백이 안 되는 배포 — 코드는 되돌려도 데이터는 안 돌아온다

배포 전략을 잘 세워 뒀어요. 문제가 생기면 이전 버전으로 즉시 되돌리는 절차가 있고, 실제로 몇 번 써 봤어요.

그런데 이번엔 롤백이 안 통했어요. 코드는 되돌렸는데 문제가 그대로예요.

배포 중에 데이터가 새 형식으로 바뀌었고, 옛 코드는 그 형식을 못 읽거든요. 이미 발송된 알림도 취소가 안 되고요.

지금 할 수 있는 게 없어요. 앞으로 가지도 뒤로 가지도 못하는 상태에서, 고칠 코드를 급하게 쓰는 수밖에요. 그게 장애 시간을 몇 배로 늘립니다.

롤백이 항상 가능하다는 전제가 틀렸어요. 어떤 배포는 되돌릴 수 없고, 그걸 배포 전에 아는 것과 배포 후에 아는 것은 완전히 다른 상황입니다.

왜 그런가

롤백은 코드만 되돌려요. 코드가 만든 결과는 안 되돌아가요.

되돌릴 수 없는 것들을 나열해 보면 이래요.

데이터 변경. 새 코드가 데이터를 새 형식으로 썼다면, 옛 코드는 그걸 못 읽어요. 마이그레이션으로 컬럼을 지웠다면 데이터 자체가 없고요.

외부로 나간 것. 발송된 메일, 보낸 알림, 호출한 결제, 발행한 이벤트는 취소가 안 돼요. 상대가 이미 받았으니까요.

소비된 것. 사용한 쿠폰, 차감한 재고, 확정한 예약이요.

그리고 다른 시스템이 본 것도 있어요. 우리 API 를 쓰는 클라이언트가 새 응답 형식에 맞춰 저장해 뒀다면, 우리가 되돌려도 그쪽은 그대로예요.

여기서 관점이 나와요. 배포 위험은 "무엇이 잘못될 수 있는가"가 아니라 "잘못됐을 때 되돌릴 수 있는가"로 재야 해요. 되돌릴 수 있으면 과감하게 배포해도 되고, 되돌릴 수 없으면 훨씬 신중해야 해요.

그런데 대부분의 팀이 이 구분을 안 해요. 모든 배포를 같은 절차로 다루고, 롤백이 항상 가능하다고 가정합니다.

코드로 보면

되돌릴 수 있는 것과 없는 것을 나눈다:

· 되돌릴 수 있다 — 과감히 배포해도 된다
✓ 화면 변경 · 로직 수정 · 성능 개선
✓ 추가만 하는 스키마 변경

✕ 되돌릴 수 없다 — 다른 절차가 필요하다
✕ 데이터 형식 변경 · 컬럼 삭제
✕ 외부 발송(메일·알림·결제)
✕ 소비 처리(쿠폰·재고·예약)
✕ 공개 API 응답 형식 변경

· 되돌릴 수 없는 것은 되돌릴 수 있게 바꾼다
✓ 기능 플래그로 감싸 코드 배포와 기능 활성을 분리
✓ → 롤백이 '플래그 끄기' 가 된다 (즉시·안전)
✓ 데이터는 앞 편의 확장·이전·정리로
✓ 외부 발송은 단계적으로 (1% → 10% → 100%)

✕ 문제 지점 · ✓ 해법 · 그대로 돌려 보기 전에 자기 환경에 맞게 고쳐 주세요.

실전에서는

가장 강력한 도구가 코드 배포와 기능 활성의 분리예요.

새 기능을 기능 플래그로 감싸 두면, 코드는 배포되어 있지만 꺼져 있어요. 문제가 생기면 플래그만 끄면 되고, 그건 배포가 아니라 설정 변경이라 몇 초면 끝나요. 롤백이 훨씬 빠르고 안전해집니다.

그리고 단계적으로 켤 수 있어요. 1% 사용자에게만 켜 보고, 괜찮으면 10%, 그다음 전체로요. 문제가 있어도 영향받는 사람이 적어요.

데이터 쪽은 앞 편의 확장·이전·정리가 답이에요. 각 단계가 되돌릴 수 있게 설계되어 있으니까요.

외부 발송은 다르게 다뤄야 해요. 되돌릴 수 없으니 나가기 전에 확인하는 장치가 필요해요. 소량으로 먼저 보내고 결과를 보는 방식, 발송 전에 검토 단계를 두는 방식, 그리고 발송량에 상한을 두는 방식이요. 특히 상한이 중요한데, 버그로 백만 통이 나가는 사고를 막아 줍니다.

여기서 판단 기준이 생겨요. 되돌릴 수 없는 배포는 되돌릴 수 있는 배포와 다른 절차를 받아야 해요. 더 많은 검토, 더 작은 범위, 더 긴 관찰. 반대로 되돌릴 수 있는 배포는 빠르게 자주 해도 돼요.

이 구분이 없으면 두 가지 중 하나가 일어나요. 모든 배포를 조심스럽게 다뤄서 배포가 느려지거나, 모든 배포를 가볍게 다뤄서 언젠가 되돌릴 수 없는 사고를 냅니다.

그리고 롤백 절차 자체를 연습해야 해요. 앞 편에서 본 대로 해 본 적 없는 절차의 소요 시간은 미지수예요.

처방

1. 배포마다 "되돌릴 수 있는가"를 먼저 판단하세요. 이 질문이 절차를 정합니다.
2. 새 기능을 기능 플래그로 감싸세요. 롤백이 배포가 아니라 설정 변경이 됩니다.
3. 단계적으로 켜세요. 1% → 10% → 100% 로 가면 문제의 영향 범위가 작습니다.
4. 데이터 변경은 확장·이전·정리로 나누세요. 각 단계가 되돌릴 수 있어야 합니다.
5. 외부 발송에 상한을 두세요. 버그로 대량 발송되는 사고를 막습니다.
6. 되돌릴 수 없는 배포는 다른 절차를 받게 하세요. 더 많은 검토와 더 작은 범위요.
7. 롤백 절차를 연습하고 소요 시간을 재세요. 해 본 적 없으면 그 시간은 미지수입니다.
8. 배포 계획에 "롤백 방법"을 적는 칸을 만드세요. 못 적으면 아직 준비가 안 된 겁니다.
9. 플래그가 남기는 흔적까지 감싸는지 확인하세요. 화면만 끄고 데이터는 새 형식으로 쓰면 반쪽입니다.
10. 되돌릴 수 없는 사고는 되돌리려 하지 말고 앞으로 고치세요. 급한 복구가 이중 처리를 만들기도 합니다.

지금 확인해 보세요

이 배포는 되돌릴 수 있는가:

· 배포 전에 답해야 할 것들
✓ 문제가 생기면 어떻게 되돌리나
✓ 되돌리는 데 얼마나 걸리나
✓ 되돌려도 안 돌아가는 것이 있나 (데이터·발송·소비)
✕ 못 적으면 아직 배포 준비가 안 된 것이다

· 기능 플래그가 흔적까지 감싸는가
✕ 화면만 끄고 데이터는 새 형식으로 쓰고 있으면 반쪽이다

· 외부 발송에 상한이 있는가
✕ 버그 하나로 백만 통이 나갈 수 있다

· 롤백 소요 시간을 실제로 재 봤는가
✓ 연습해 본 적 없으면 그 시간은 미지수다

· 롤백 빈도
✕ 잦으면 배포 전 검증이 부족하다는 신호다

핵심 한 줄롤백은 코드를 되돌릴 뿐 결과를 되돌리지 않는다.