롤백 신화: '언제든 되돌릴 수 있다'는 팀이 스스로에게 속이는 거짓말

저는 예전에 롤백을 믿었습니다. 가볍게가 아니라, 종교적으로요.

모든 배포에는 같은 기도가 있었습니다. “만약 문제가 생기면, 그냥 되돌리면 돼.”

그러던 어느 목요일 오후 6시 47분, 우리는 ‘작은’ 변경 사항을 출시했습니다. 40분 후, 체크아웃 과정에서 오류가 발생했습니다. 완전히 다운된 것은 아니었지만, 충분히 공포스러울 정도였습니다. 주문이 pending 상태에 갇혔고, 고객들은 재시도를 했으며, 지원팀은 이미 모두 대문자로 타이핑하고 있었습니다.

그래서 우리는 되돌리기(revert)를 실행했습니다. CI가 녹색으로 바뀌었습니다. 모두 안도했습니다.

그런 다음 데이터베이스를 확인했습니다.

마이그레이션(migration)은 이미 실행된 상태였습니다. 새로운 컬럼이 존재했습니다. 이전 코드는 이를 무시했지만, 백그라운드 워커는 그렇지 않았습니다. 그것은 계속해서 새 컬럼을 읽고, null 값을 발견하고, 잘못된 작업을 수행했습니다. 우리는 수동으로 행을 수정하고 중복 청구에 대한 환불 처리를 하면서 6시간 동안 ‘되돌리는’ 작업을 했습니다.

그때 저는 롤백을 시간 여행처럼 취급하는 것을 멈췄습니다.

롤백은 되돌리기(undo)가 아닙니다. 그것은 이전 배포의 뒷정리를 할 수 있기를 바라는 새로운 배포입니다. 그리고 보통, 그것이 정리하는 것은 코드뿐입니다. 다음 것들은 정리하지 못합니다:

• 데이터 변경 사항. 마이그레이션, 백필(backfills), 삭제된 행, 이름이 바뀐 컬럼.
• 외부 부작용. 전송된 이메일, 청구된 결제, 발동된 웹훅(webhooks), 전달된 푸시 알림.
• 큐(queues), 캐시(caches), 외부 API, 그리고 지난달 빌드를 여전히 실행하고 있는 모바일 앱에 남아있는 상태(state).
• 인간의 결정. 이미 그 기능을 본 사람. 이미 설정을 변경한 사람. 이미 고객에게 약속한 사람.

거짓말은 되돌리기가 불가능하다는 것이 아닙니다. 거짓말은 되돌리기가 안전하게 만든다는 것입니다.

이것은 개발팀이 지루한 것들을 건너뛰어도 충분히 안전하다고 느끼게 만듭니다. 기능 플래그(feature flag)도, 카나리 배포(canary)도, 하위 호환 마이그레이션도 없습니다. 아무도

진정한 안전성은 되돌리기 버튼(revert button)이 아닙니다. 그것은 앞으로 나아가며 수정하는 것을 설계하는 것입니다. 확장 및 축소 마이그레이션(Expand-and-contract migrations). 실제로 기능을 끌 수 있는 기능 플래그(Feature flags). 100%가 되기 전에 1%를 노출시키는 카나리아 배포(Canaries). 누군가가 실제로 테스트해 본 운영 매뉴얼(Runbooks). 그리고 “만약 이것이 잘못된다면, 우리가 돌아갈 수 없을 수도 있다”고 말할 만큼 충분한 겸손함입니다. 그래서 폭발 반경(blast radius)을 작게 만들도록 합시다.

저는 여전히 롤백 기능을 제 도구 상자에 가지고 있습니다. 하지만 더 이상 그것을 신격화하지는 않습니다. 그것은 전술이지, 전략이 아닙니다.

그러니 다음에 누군가 “우리는 언제든지 되돌릴 수 있다(We can always revert)”라고 말하면, 그들에게 이 질문 하나를 하세요:

정확히 무엇을 되돌린다는 것인가요?