배포가 실패해도 5분 안에 되돌리는 소규모 서비스 운영법

빠른 롤백은 사람이 명령어를 빨리 입력하는 능력이 아니다. 이전 버전이 무엇인지 알고, 같은 산출물을 다시 실행할 수 있고, DB가 이전 코드와 호환되도록 미리 설계한 결과다. 준비 없이 배포한 뒤 5분 안에 되돌리겠다는 목표는 지키기 어렵다.

코드와 DB 롤백은 다르다

애플리케이션은 이전 이미지나 이전 배포를 다시 활성화하면 돌아갈 수 있다. 하지만 새 코드가 컬럼을 삭제하거나 데이터를 변환했다면 코드만 되돌려도 이전 버전이 동작하지 않는다. 그래서 DB 변경은 되돌리기보다 앞뒤 버전이 잠시 함께 동작하도록 만드는 편이 안전하다.

대표적인 방식은 확장 후 축소다.

1. 새 컬럼이나 테이블을 추가한다.
2. 이전 코드와 새 코드가 모두 동작하게 배포한다.
3. 필요한 데이터를 천천히 채운다.
4. 읽기 경로를 새 구조로 바꾸고 확인한다.
5. 충분한 관찰 기간 뒤 이전 컬럼을 제거한다.

Supabase는 운영 DB를 대시보드에서 직접 바꾸지 말고, 버전 관리되는 마이그레이션 파일로 변경할 것을 권장한다. 로컬, 스테이징, 운영 환경을 나누고 승인 절차를 두면 실수로 운영 마이그레이션이 실행될 가능성을 줄일 수 있다. Supabase 운영 성숙도 지침

되돌릴 수 있는 배포의 조건

• 배포마다 Git 커밋과 변경 불가능한 이미지 태그 또는 digest가 연결돼 있다.
• 직전 정상 버전의 환경 설정과 이미지가 남아 있다.
• 배포 직후 자동으로 핵심 URL과 로그인, 주요 API를 확인한다.
• DB 변경은 이전 애플리케이션과 호환된다.
• 롤백 권한과 담당자가 정해져 있다.
• 배포 중에는 같은 환경에 다른 배포가 동시에 들어오지 않는다.

GitHub Actions의 environment는 운영 배포에 승인, 허용 브랜치, 보호 규칙, 환경별 비밀정보를 적용할 수 있다. concurrency를 사용하면 같은 운영 환경에 여러 배포가 동시에 실행되는 것도 막을 수 있다. GitHub Actions 배포 관리

5분 롤백 실행 문서

0분에서 1분: 영향 확인과 배포 중지

오류율, 핵심 업무 실패, 사용자 범위를 확인한다. 새 배포가 계속 진행 중이면 중지하고 사건 채널을 연다. 원인 분석보다 사용자 영향 차단을 우선할 기준을 미리 정한다.

1분에서 2분: 직전 정상 버전 선택

마지막으로 health check를 통과한 배포 ID, Git 커밋, 이미지 digest를 선택한다. 누군가 기억하는 버전이 아니라 배포 기록에 표시된 버전을 쓴다.

2분에서 4분: 트래픽 전환

Vercel이라면 이전 배포로 즉시 롤백할 수 있다. 자체 VPS라면 이전 이미지로 컨테이너를 올리고 프록시의 대상만 전환하는 blue-green 구성이 빠르다. Vercel Instant Rollback

4분에서 5분: 핵심 기능 확인과 공지

홈 화면만 열어 보지 않는다. 로그인, 핵심 조회, 한 건의 쓰기 작업, 워커와 외부 연동까지 짧은 자동 점검을 실행한다. 정상화 시각과 남은 영향을 공지하고, 실패한 작업의 재처리 여부를 기록한다.

롤백하면 안 되는 경우

이미 되돌릴 수 없는 데이터 변환이 끝났거나, 이전 버전에 더 심각한 보안 문제가 있거나, 외부 API 계약이 바뀐 경우에는 롤백이 더 위험할 수 있다. 이때는 기능 플래그로 새 기능만 끄거나, 읽기 전용 모드로 전환하거나, 빠른 수정 배포를 선택한다.

평소에 해야 할 연습

• 월 1회 시험 환경에서 이전 버전 전환 시간을 잰다.
• 롤백 후 세션, 큐, 예약 작업이 어떻게 되는지 확인한다.
• DB 마이그레이션 검토에 호환성 항목을 넣는다.
• 실패한 배포의 자동 재시도를 제한한다.
• 사고 후 실행 문서와 health check를 보완한다.

5분 롤백의 핵심은 빠른 손이 아니라 이전 버전을 계속 실행 가능한 상태로 보존하는 것이다. 코드, 설정, DB, 작업 큐를 함께 고려하면 소규모 팀도 복잡한 배포 플랫폼 없이 짧은 복구 시간을 만들 수 있다.