스테이징을 두는 이유는 단 하나입니다 — 배포하기 전에 결과를 미리 보기 위해서입니다. 그런데 스테이징이 프로덕션과 다르면 그 미리보기는 다른 사이트의 미리보기가 됩니다. 통과했는데 프로덕션에서 깨지거나, 반대로 스테이징에서만 깨져 존재하지 않는 문제를 몇 시간 동안 쫓게 됩니다.
“완전히 똑같게” 는 대개 불가능하고 필요하지도 않습니다. 정할 것은 어느 차이가 결과를 바꾸는가입니다.
같아야 하는 것과 달라야 하는 것
오른쪽 목록이 왜 중요한지는 각각 다른 방식으로 드러납니다. PHP 버전이 다르면 폐기 경고와 형 처리가 달라져, 스테이징에서 조용하던 코드가 프로덕션에서 경고를 뿜습니다. 확장 모듈 하나가 없으면 그 기능은 아예 실행 경로가 달라집니다. DB 버전과 sql_mode 는 특히 조용한데, 엄격 모드에서 거부되는 INSERT 가 느슨한 쪽에서는 통과해 버립니다.
캐시 계층은 양방향으로 거짓말을 합니다. 프로덕션에만 오브젝트 캐시가 있으면 스테이징에서 잡히던 N+1 쿼리가 프로덕션에서는 숨습니다. 반대로 프로덕션에만 페이지 캐시가 있으면 스테이징에서 멀쩡했던 “로그인 사용자에게 캐시된 화면이 나가는” 문제가 프로덕션에서만 터집니다.
대조는 명령 몇 줄로 끝난다
양쪽에서 같은 것을 뽑아 diff 로 대조합니다. 이 습관 하나가 “환경 탓인가” 라는 질문을 사실 확인으로 바꿔 줍니다.
wp --info
wp db query 'SELECT VERSION();'
wp db query 'SELECT @@sql_mode;'
wp eval 'echo implode( PHP_EOL, get_loaded_extensions() );' | sort
wp plugin list --status=active --field=name | sort
wp eval 'echo ini_get( "memory_limit" ), " ", ini_get( "max_execution_time" );'스테이징이 사고를 내지 않게 하는 장치
스테이징은 실데이터의 사본을 갖고 있으므로, 아무것도 하지 않으면 실제 고객에게 메일을 보내고 검색에 색인됩니다. 이 둘은 반드시 코드로 막습니다. 사람이 기억해서 끄는 방식은 언젠가 잊습니다.
<?php
// wp-content/mu-plugins/staging-guard.php
if ( 'production' !== wp_get_environment_type() ) {
// 메일을 보내지 않고 성공으로 처리한다 (WP 5.7+)
add_filter( 'pre_wp_mail', '__return_true' );
// 옵션 값이 아니라 읽는 순간 강제한다 — DB 를 다시 import 해도 유지된다
add_filter( 'pre_option_blog_public', '__return_zero' );
}두 번째 필터가 옵션을 수정하지 않고 읽기를 가로채는 점이 중요합니다. 프로덕션 DB 를 다시 가져와도 값이 되살아나지 않습니다. 여기에 HTTP 기본 인증이나 IP 제한을 얹으면 스테이징 주소가 검색에 잡히는 경로 자체가 사라집니다.
데이터의 규모도 환경이다
마지막으로 자주 잊히는 축이 있습니다. 글 20편짜리 스테이징은 글 20만 편에서만 나타나는 문제를 재현하지 못합니다. 목록 쿼리 · 인덱스 · 사이트맵 생성처럼 규모에 비례해 무거워지는 것들이 그렇습니다. 4회차의 절차대로 프로덕션 데이터를 정제해 내려받는 것이, 이 축을 맞추는 유일한 현실적인 방법입니다.
측정과 검증을 실제로 어떻게 하는지는 작업 과정에 절차 그대로 공개돼 있고, 성능 관점의 배경은 성능 최적화 아카이브에 있습니다.
다음 회차
스테이징에서 확인이 끝났다면 이제 옮길 차례입니다. 다음 회차는 배포 전략 셋 — rsync · 서버에서 git · 빌드 산출물이고, 셋을 가르는 기준은 속도가 아니라 되돌리기 이야기입니다.