9. 롤백 없는 배포는 편도행

사고 시나리오

금요일 저녁 배포가 잘못됐다. 고치는 코드를 급히 짜서 또 배포한다. 그것도 잘못됐다. “이전 버전으로 돌아가기” 버튼이 있었다면 30초짜리 일이, 새 코드를 짜서 앞으로 도망치는 몇 시간짜리 장애가 된다. 더 나쁜 변형: DB 스키마까지 바꿔버려서 이전 코드로 돌아가면 그 코드가 새 스키마에서 죽는다. 이제 돌아갈 곳이 없다.

원칙

배포의 완성 조건은 “새 버전이 나갔다”가 아니라 “이전 버전으로 즉시 돌아갈 수 있다”이다. 그리고 스키마 변경은 코드보다 먼저, 하위 호환(additive)으로 나간다.

실무 처방

• 배포 플랫폼의 즉시 롤백(instant rollback) 기능 위치를 미리 확인해둔다. 대부분의 정적/서버리스 플랫폼은 이전 배포가 그대로 남아 있어 클릭 한 번이면 된다.
• 락파일(package-lock, pnpm-lock 등)을 반드시 커밋한다. 락파일 없는 빌드는 배포마다 다른 의존성을 설치할 수 있어, “같은 코드인데 어제는 됐다”류 장애를 만든다.
• 스키마 변경은 컬럼 추가·테이블 추가 같은 하위 호환 변경을 먼저 적용하고, 그 다음 코드를 배포한다. 순서를 지키면 구버전 코드와 신버전 코드 둘 다 어느 시점에도 살아 있다. 컬럼 삭제·개명은 아무 코드도 그것을 안 쓰게 된 뒤에.
• 배포 직전 자동 게이트(빌드+테스트+최소 스모크)를 스크립트 하나로 묶는다. 게이트를 통과 못 하면 배포 명령 자체가 실행되지 않게.
• 배포 기록(언제·무엇을·어느 커밋)을 남긴다. 장애 시각과 배포 시각을 겹쳐보는 것이 원인 파악의 첫 수다.

체크리스트

• 이전 버전으로 30초 안에 돌아가는 방법을 안다 (실제로 눌러봤다)
• 락파일이 커밋돼 있다
• 스키마 변경이 하위 호환 우선 + 코드보다 먼저 순서다
• 빌드·테스트·스모크가 배포 명령과 한 체인으로 묶여 있다