“테스트한 것을 배포한다” 는 원칙은 뒤집으면 이렇게 됩니다 — 배포 직전에 무언가를 바꾸면 그것은 테스트되지 않은 것이다. 스테이징에서 검증한 산출물이 그대로 프로덕션에 올라가야 하고, 올라간 것이 문제면 그대로 내려올 수 있어야 합니다.
배포 전에 만드는 것: 롤백 경로
- 코드 — 직전 버전 태그. 되돌리기 = 태그 체크아웃 한 줄이어야 합니다.
- DB — 배포 직전 덤프. 스키마를 바꾸는 배포라면 필수이고, 안 바꾸는 배포라도 싸니까 뜹니다.
- 결정 기준 — 무엇이 보이면 롤백하는지 미리 적어 둡니다. 장애 중에 판단 기준을 만들면 늦습니다.
워드프레스 배포의 함정 두 가지
DB 에 든 상태. 워드프레스는 설정의 상당 부분이 DB(wp_options)에 삽니다. 코드만 롤백하면 새 코드가 만든 옵션 · 마이그레이션이 남아 옛 코드와 충돌할 수 있습니다. 스키마나 옵션 구조를 바꾸는 배포는 코드와 DB 를 한 세트로 롤백해야 합니다.
캐시 계층. 배포 후 “안 바뀌었어요” 의 태반은 실패가 아니라 캐시입니다. 배포 절차 마지막에 오브젝트 캐시 flush 와 페이지 캐시 무효화를 명시해 두면, 장애 조사가 캐시 추적으로 새는 일이 없어집니다.
배포 후 10분
- 핵심 화면 3~4개를 실제로 엽니다 — 홈 · 글 하나 · 폼 제출 · 관리자 로그인.
- 에러 로그를 배포 시각 이후로 봅니다. 평소 로그와 섞으면 신호가 묻힙니다.
- 지표(응답 시간 · 5xx)가 배포 전 수준으로 돌아오는지 관찰하고 나서 자리를 뜹니다.
저장소에 무엇을 올릴지의 경계는 워드프레스 .gitignore 가이드에서, 저희가 고객 작업에서 실제로 밟는 무중단 절차는 작업 과정에서 확인할 수 있습니다.