DB 동기화 — SQL 치환이 직렬화 데이터를 깨뜨리는 이유

프로덕션 데이터를 로컬로 가져오는 작업은 개발 흐름에서 가장 자주 반복되는 일입니다. 그리고 여기서 가장 흔한 사고가 납니다 — SQL 로 도메인을 치환하고 나면 위젯 설정 · 테마 옵션 · 플러그인 설정이 통째로 사라지는 현상입니다. 이 사고는 원인을 알면 완전히 피할 수 있습니다.

직렬화 — 길이가 값 안에 적혀 있다

워드프레스는 배열이나 객체를 wp_options 와 wp_postmeta 에 넣을 때 PHP 직렬화 형식으로 저장합니다. 이 형식의 핵심은 문자열마다 길이가 함께 기록된다는 것입니다.

-- 원본
a:1:{s:8:"site_url";s:19:"https://example.com";}

-- SQL REPLACE 후 — 문자열은 27자가 됐는데 선언은 19 그대로다
a:1:{s:8:"site_url";s:19:"https://staging.example.com";}

-- wp search-replace 후 — 길이까지 다시 쓴다
a:1:{s:8:"site_url";s:27:"https://staging.example.com";}

가운데 줄이 사고의 실체입니다. s:19: 는 “여기서부터 19바이트가 문자열” 이라는 선언인데 실제 내용은 27바이트입니다. PHP 의 unserialize() 는 이 값을 복원하지 못하고 false 를 돌려주며, 워드프레스는 그 옵션이 없는 것처럼 동작합니다.

증상이 고약한 이유가 여기 있습니다. 에러가 나지 않습니다. 화면은 200 으로 뜨고, 위젯만 비어 있고, 테마 옵션만 기본값으로 돌아가 있습니다. “이관하다가 설정이 날아갔네” 로 읽히지 데이터가 깨졌다고는 보이지 않습니다. 그리고 길이가 우연히 같은 치환(example.com → example.dev)은 멀쩡히 동작하므로, 같은 방식을 계속 쓰다가 어느 날 길이가 달라지는 순간 처음 터집니다.

올바른 절차

wp search-replace 는 값을 역직렬화 → 치환 → 재직렬화 하므로 길이가 항상 맞습니다. 중첩된 배열과 객체 안까지 재귀로 들어갑니다.

# 1) 프로덕션에서 덤프
wp db export prod.sql --add-drop-table

# 2) 로컬에 넣는다
wp db import prod.sql

# 3) 반드시 dry-run 을 먼저 본다
wp search-replace 'https://example.com' 'https://example.test' --skip-columns=guid --report-changed-only --dry-run

# 4) 확인했으면 실제 실행
wp search-replace 'https://example.com' 'https://example.test' --skip-columns=guid --report-changed-only

wp cache flush

--skip-columns=guid 를 빠뜨리지 않습니다. guid 는 주소가 아니라 식별자입니다. 생김새가 URL 이라 바꾸고 싶어지지만, 피드 리더는 이 값으로 “이미 본 글” 을 판단합니다. 바꾸면 구독자 쪽에서 전체 글이 새 글로 다시 나타납니다. 워드프레스 문서가 오래전부터 손대지 말라고 적어 둔 값입니다.

멀티사이트이거나 접두사가 다른 테이블을 함께 다뤄야 하면 --all-tables-with-prefix 또는 --all-tables 를 씁니다. 기본값은 현재 사이트의 테이블만이라, 플러그인이 자체 테이블에 URL 을 넣어 두었다면 기본 실행으로는 남습니다.

방향에도 규칙이 있다

절차보다 중요한 규칙이 하나 더 있습니다. 코드는 위로 흐르고 데이터는 아래로 흐릅니다. 로컬에서 만든 DB 를 프로덕션에 밀어 올리는 순간, 덤프를 뜬 뒤에 들어온 주문 · 문의 · 가입이 전부 사라집니다.

가져온 뒤에 로컬에서 반드시 해 둘 것도 있습니다. 색인 차단(wp option update blog_public 0), 사용하지 않는 결제 · 발송 연동 비활성화, 그리고 개인정보가 섞인 사용자 데이터의 정리입니다. 개발 편의를 위해 가져온 데이터가 개인정보 사본이 되지 않도록 하는 것은 절차가 아니라 의무에 가깝습니다.

이관과 배포 전반은 개발 워크플로우 아카이브에서 이어지고, 이관 · 최적화 · 보안 점검을 한 건으로 맡기고 싶다면 최적화 지원 사업이 그 범위입니다.

다음 회차

데이터를 안전하게 옮길 수 있게 됐으니, 이제 그 데이터를 어디서 시험할지가 남았습니다. 다음 회차는 스테이징 — 프로덕션과 다른 스테이징이 왜 테스트를 거짓말로 만드는가입니다.