Technote

개발 워크플로우 심화

연재 로컬에서 프로덕션까지 8부 중 8부

되돌리기 설계 — 코드와 DB 를 함께 되돌릴 때의 순서

코드를 되돌려도 DB 는 되돌아오지 않습니다. 새 코드가 데이터를 이미 고쳐 놓았다면 옛 코드는 그것을 읽지 못하고, 그래서 순서가 필요합니다.

연재의 마지막 회차입니다. 지금까지 로컬 환경을 세우고, 저장소를 정리하고, 비밀값을 분리하고, 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 를 복원하면 스냅샷 이후에 들어온 데이터가 사라집니다. 주문 · 문의 · 회원가입 · 댓글이 그 구간만큼 없어집니다. 이것은 절차의 결함이 아니라 스냅샷 복원의 정의이고, 그래서 판단이 필요합니다.

실무에서는 이렇게 갈립니다. 배포가 코드만 건드렸다면 되돌리기는 즉시이고 무손실이므로 망설일 이유가 없습니다. 배포가 데이터를 건드렸다면 두 선택지 중에서 고릅니다 — DB 까지 되돌리고 손실 구간을 감수하거나, 되돌리지 않고 앞으로 고치는 것입니다. 거래가 계속 들어오는 사이트에서는 후자가 정답인 경우가 많습니다.

어느 쪽을 고르든, 그 판단을 사고가 난 뒤에 처음 하지 않도록 미리 정해 두는 것이 이 회차가 말하려는 전부입니다.

되돌려 본 적 없는 절차는 절차가 아니다

되돌릴 수 있는 상태의 조건 — 아래 두 줄이 남아 있으면 되돌리기 계획은 아직 없는 것이다

5회차의 스테이징이 여기서 한 번 더 값을 합니다. 되돌리기 절차를 스테이징에서 그대로 돌려 보는 것이 유일한 검증 방법입니다. 걸린 시간을 기록해 두면 그것이 다음 사고 때의 예상 복구 시간이 됩니다 — 추측이 아니라 측정된 값으로요.

연재를 마치며

여덟 회차를 관통한 규칙은 하나였습니다. 우리가 쓴 것과 환경이 만든 것을 가른다. 저장소에 무엇을 넣을지, 비밀값을 어디에 둘지, DB 를 어느 방향으로 흘릴지, 무엇을 되돌릴 수 있는지가 전부 이 구분에서 따라 나왔습니다.

워드프레스는 이 방식과 잘 맞습니다. WP-CLI 는 설치 · 마이그레이션 · 검사를 전부 명령으로 제공하고, 환경 타입 · 훅 · mu-plugin 같은 장치가 환경별 분기를 코드로 표현하게 해 줍니다. 필요한 것은 특별한 도구가 아니라 구분을 지키는 규율이었습니다.

이 파이프라인을 기존 사이트에 처음부터 세우는 일 — Docker 기반 재구성 · 스테이징 구축 · 업그레이드와 성능 최적화 — 은 최적화 지원 사업에서 한 건으로 처리합니다. 우리가 실제로 어떤 순서로 작업하고 무엇을 전후로 측정하는지는 작업 과정에 절차 그대로 공개돼 있습니다.

이 주제의 다른 글

노하우 목록으로

개발 워크플로우 심화

CI 에서 WP-CLI 돌리기 — 검사 자동화의 실제 구성

사람이 기억해서 돌리는 검사는 바쁜 주에 건너뛰게 됩니다. 싼 검사부터 순서대로 쌓고, 일회용 워드프레스 위에서 명령으로 확인하면 그 기억이 필요 없어집니다.

개발자 5분 읽기

₩270,000 · 신청하기