연재의 마지막 회차입니다. 지금까지 재고를 세고, 범위를 정하고, 주소를 지키고, 스테이징에서 리뷰받고, 템플릿 단위로 켜고, 옛 본문을 수습하고, 배포 후를 관측했습니다. 남은 것은 하나입니다 — 되돌릴 수 있는 상태로 배포하는 것.
롤백 계획은 자신 없음의 표시가 아닙니다. 오히려 반대입니다 — 되돌릴 수 있으면 과감하게 배포할 수 있고, 되돌릴 수 없으면 배포 자체가 두려워져 결국 검증이 부족한 큰 덩어리를 한 번에 밀어 넣게 됩니다.
롤백은 두 갈래입니다
워드프레스 배포에서 바뀌는 것은 코드(테마 · 플러그인 · 설정 파일)와 데이터베이스(콘텐츠 · 옵션 · 메타)입니다. 이 둘은 되돌리는 방법이 다르고, 되돌렸을 때의 대가도 다릅니다.
핵심은 두 번째 층입니다. 배포 시점의 데이터베이스로 되돌리면 그 사이에 들어온 문의 · 주문 · 새 글이 함께 사라집니다. 그래서 데이터베이스 롤백은 언제나 마지막 수단이고, 되돌리기 전에 현재 상태를 먼저 백업해 그 사이 데이터를 나중에 꺼낼 수 있게 합니다.
배포 전에 만드는 것
롤백 준비는 배포 직전 5분이 아니라 배포 계획의 일부입니다. 다섯 가지를 준비합니다.
마지막 줄이 가장 중요합니다. 기준 없이 배포하면 판단이 감정으로 이뤄집니다. “전환 경로의 폼이 동작하지 않으면 즉시”, “특정 템플릿의 404 가 계속 늘면 그 템플릿만”, “순위 출렁임은 2주 관찰” 처럼 미리 적어 두면 배포 당일 밤의 논쟁이 사라집니다.
되돌리는 순서
롤백은 배포의 역순입니다. 순서를 지키지 않으면 되돌렸는데도 화면이 그대로이거나, 새 코드가 옛 데이터를 읽어 더 이상한 상태가 됩니다.
① 지금 상태를 먼저 백업합니다. 되돌리기 전의 데이터베이스와 업로드 파일을 남겨 둬야 그 사이 문의를 나중에 꺼낼 수 있습니다.
② 코드를 이전 버전으로 되돌립니다. 대부분의 문제는 여기서 해결됩니다 — 화면 · 레이아웃 · 자산은 전부 코드 쪽이기 때문입니다.
③ 캐시를 전부 비웁니다. 서버의 페이지 캐시, 오브젝트 캐시, 그리고 앞단에 CDN 이 있다면 그것까지. 이 단계를 빠뜨리면 되돌렸는데도 방문자에게는 새 화면이 계속 보이고, 그 상태에서 “롤백이 안 된다” 는 오진이 나옵니다.
④ 주소가 여전히 열리는지 확인합니다. 주소를 바꿨다면 리다이렉트 규칙도 함께 되돌아가야 하고, 그 사이 새 주소가 공유됐다면 반대 방향 규칙이 한동안 필요합니다.
데이터베이스 되돌리기는 이 네 단계로 해결되지 않을 때만 합니다. 콘텐츠 구조나 옵션이 바뀌어 새 데이터로는 옛 코드가 동작하지 않는 경우인데, 그때도 ①에서 남긴 백업이 있어야 사이에 들어온 것을 되살릴 수 있습니다.
전부 되돌리지 않는 선택
점진 전환을 했다면 선택지가 하나 더 생깁니다 — 문제가 난 템플릿만 되돌리는 것입니다. 나머지 템플릿은 잘 돌고 있으므로 함께 되돌릴 이유가 없고, 원인도 그 템플릿 안에 있습니다. 5회차에서 템플릿 단위로 켠 이유가 여기서 값을 합니다.
반대로 앞으로 고치는 것이 나은 경우도 있습니다. 원인이 명확하고 수정이 짧으면 되돌리는 비용이 더 큽니다. 판단 기준은 수정에 걸리는 시간을 확신할 수 있는가 하나입니다 — 확신할 수 없으면 되돌리고 스테이징에서 고칩니다.
연재를 마치며
운영 중인 사이트의 리뉴얼은 새로 만드는 것보다 어렵습니다. 지켜야 할 것이 있기 때문입니다. 그런데 지켜야 할 것이 있다는 사실 자체가 좋은 신호입니다 — 유입도 전환도 없는 사이트라면 무엇을 바꾸든 잃을 것이 없습니다.
이 연재의 여덟 회차는 결국 한 가지를 말합니다. 목록을 만들고, 한 번에 하나씩 바꾸고, 되돌릴 길을 남긴다. 워드프레스는 이 방식을 아주 잘 지원하는 도구입니다 — 콘텐츠가 테마와 분리돼 있고, 주소를 제어할 수 있고, 코드와 데이터를 따로 백업할 수 있습니다.
업그레이드 · 성능 최적화 · 보안 점검처럼 리뉴얼과 함께 정리하면 좋은 작업은 최적화 지원 사업에서 한 건으로 처리할 수 있고, 우리가 실제로 어떤 순서로 작업하고 무엇을 근거로 남기는지는 작업 과정에 그대로 공개돼 있습니다. 리뉴얼 계획이 서 있다면 신청에서 현재 상태부터 함께 진단해 드립니다.