연재의 마지막 회차입니다. 지금까지 로컬 환경을 세우고, 저장소를 정리하고, 비밀값을 분리하고, DB 를 안전하게 옮기고, 스테이징을 맞추고, 배포와 CI 를 붙였습니다. 남은 것은 잘못됐을 때 어떻게 되돌리는가입니다.
여기서 가장 흔한 오해부터 짚습니다. 코드를 되돌린다고 데이터베이스가 되돌아오지 않습니다. 그리고 이것은 워드프레스에서 예외적인 상황이 아니라 기본 동작입니다.
왜 코드만 되돌리면 되지 않는가
플러그인이나 코어를 업그레이드하면, 새 코드는 활성화나 첫 요청 시점에 자기 형식으로 데이터를 고쳐 씁니다. 테이블 구조를 바꾸기도 하고, 옵션의 배열 모양을 바꾸기도 하고, 메타 키를 옮기기도 합니다. 이 과정은 대체로 한 방향으로만 설계돼 있습니다 — 되돌리는 절차는 제공되지 않습니다.
그 상태에서 옛 코드를 다시 올리면, 옛 코드는 자기가 모르는 모양의 데이터를 읽게 됩니다. 운이 좋으면 설정이 비어 보이고, 나쁘면 치명적 오류가 납니다. 배포를 되돌렸는데 사이트가 더 이상해지는 상황이 이렇게 생깁니다.
짝으로 남기고 짝으로 되돌린다
되돌릴 수 있는 상태란 코드 리비전과 DB 스냅샷이 한 쌍으로 존재하는 상태입니다. 배포 직전에 둘을 함께 남깁니다.
# 배포 직전 — 리비전 이름을 파일명에 박아 짝을 잃지 않게 한다
REV=$(git rev-parse --short HEAD)
wp db export "backups/$(date +%Y%m%d-%H%M)-${REV}.sql" --add-drop-table
되돌릴 때는 순서가 있습니다. 코드를 먼저, DB 를 그다음에 되돌립니다.
wp maintenance-mode activate
git checkout "${PREV_REV}" # ① 코드를 먼저
wp db import "backups/${SNAPSHOT}" # ② 그 코드와 짝인 DB
wp cache flush
sudo systemctl reload php8.3-fpm
wp maintenance-mode deactivate
순서가 반대면 어떻게 되는지가 이 회차의 핵심입니다. 새 코드가 아직 살아 있는 상태에서 옛 DB 를 넣으면, 새 코드는 그것을 “업그레이드가 필요한 데이터” 로 보고 다음 요청에서 다시 마이그레이션합니다. 방금 되돌린 데이터가 그 자리에서 다시 새 형식으로 바뀝니다. 그래서 코드가 먼저입니다.
되돌리기에는 비용이 있다 — 솔직하게 말한다
DB 를 복원하면 스냅샷 이후에 들어온 데이터가 사라집니다. 주문 · 문의 · 회원가입 · 댓글이 그 구간만큼 없어집니다. 이것은 절차의 결함이 아니라 스냅샷 복원의 정의이고, 그래서 판단이 필요합니다.
실무에서는 이렇게 갈립니다. 배포가 코드만 건드렸다면 되돌리기는 즉시이고 무손실이므로 망설일 이유가 없습니다. 배포가 데이터를 건드렸다면 두 선택지 중에서 고릅니다 — DB 까지 되돌리고 손실 구간을 감수하거나, 되돌리지 않고 앞으로 고치는 것입니다. 거래가 계속 들어오는 사이트에서는 후자가 정답인 경우가 많습니다.
어느 쪽을 고르든, 그 판단을 사고가 난 뒤에 처음 하지 않도록 미리 정해 두는 것이 이 회차가 말하려는 전부입니다.
되돌려 본 적 없는 절차는 절차가 아니다
5회차의 스테이징이 여기서 한 번 더 값을 합니다. 되돌리기 절차를 스테이징에서 그대로 돌려 보는 것이 유일한 검증 방법입니다. 걸린 시간을 기록해 두면 그것이 다음 사고 때의 예상 복구 시간이 됩니다 — 추측이 아니라 측정된 값으로요.
연재를 마치며
여덟 회차를 관통한 규칙은 하나였습니다. 우리가 쓴 것과 환경이 만든 것을 가른다. 저장소에 무엇을 넣을지, 비밀값을 어디에 둘지, DB 를 어느 방향으로 흘릴지, 무엇을 되돌릴 수 있는지가 전부 이 구분에서 따라 나왔습니다.
워드프레스는 이 방식과 잘 맞습니다. WP-CLI 는 설치 · 마이그레이션 · 검사를 전부 명령으로 제공하고, 환경 타입 · 훅 · mu-plugin 같은 장치가 환경별 분기를 코드로 표현하게 해 줍니다. 필요한 것은 특별한 도구가 아니라 구분을 지키는 규율이었습니다.
이 파이프라인을 기존 사이트에 처음부터 세우는 일 — Docker 기반 재구성 · 스테이징 구축 · 업그레이드와 성능 최적화 — 은 최적화 지원 사업에서 한 건으로 처리합니다. 우리가 실제로 어떤 순서로 작업하고 무엇을 전후로 측정하는지는 작업 과정에 절차 그대로 공개돼 있습니다.