배포 방식을 고를 때 대부분 “어떻게 올리나” 를 먼저 생각합니다. 순서를 뒤집는 편이 낫습니다 — “어떻게 되돌리나” 를 먼저 정하면 세 방식 중 어느 것이 이 프로젝트에 맞는지가 바로 드러납니다.
① rsync — 트리를 그대로 맞춘다
CI 나 로컬의 체크아웃을 서버 디렉터리에 그대로 맞추는 방식입니다. 서버에 필요한 것은 SSH 뿐이고, 배포된 트리가 소스와 어긋나 있으면 --delete 가 그것을 정리합니다.
rsync -az --delete --exclude-from=deploy-exclude.txt --dry-run ./ deploy@host:/srv/site/current/두 가지를 반드시 지킵니다. --dry-run 을 먼저 돌려 무엇이 지워질지 봅니다. 그리고 제외 목록에 wp-content/uploads/ 와 wp-config.php 를 넣습니다 — 빠뜨리면 --delete 가 업로드 파일을 통째로 지웁니다. 이 두 줄이 rsync 배포에서 가장 값비싼 실수를 막아 줍니다.
되돌리기는 이전 리비전을 체크아웃해 같은 명령을 다시 도는 것입니다. 간단하지만 전환이 원자적이지 않습니다 — 파일이 하나씩 갱신되는 동안 방문자는 새 템플릿과 옛 클래스가 섞인 상태를 볼 수 있습니다.
② 서버에서 git — 가장 단순한 구성
ssh deploy@host 'cd /srv/site/current && git fetch --tags && git checkout v2026.09.05'서버에 git 과 읽기 전용 배포 키만 있으면 됩니다. 되돌리기는 이전 태그로 checkout 하는 것이라 기록이 그대로 남고, 무엇이 배포됐는지 서버에서 바로 확인할 수 있습니다.
대신 두 가지 위험이 따라옵니다. 첫째, 서버의 작업 트리를 누군가 직접 고치면 다음 배포가 충돌로 멈춥니다 — 급할 때 서버에서 한 줄 고치는 습관과 이 방식은 공존하지 못합니다. 둘째, .git 디렉터리가 웹으로 노출되면 소스 전체가 유출됩니다. 웹서버에서 반드시 차단합니다.
③ 빌드 산출물 + 심링크 — 전환이 한 번에
어딘가에서 빌드한 결과를 릴리스 디렉터리로 올리고, current 심링크를 새 릴리스로 옮기는 방식입니다. 전환이 링크 하나이므로 중간 상태가 없습니다.
ssh deploy@host 'ln -sfn /srv/site/releases/20260905-1200 /srv/site/current'-n 이 빠지면 안 됩니다. -n 없이 실행하면 ln 이 기존 심링크를 따라가서 그 대상 디렉터리 안에 새 링크를 만듭니다. 겉보기에 성공하고, 배포는 반영되지 않으며, 원인은 며칠 뒤에 발견됩니다.
wp-config.php 와 wp-content/uploads/ 는 릴리스 밖의 공유 디렉터리에 두고 각 릴리스에서 링크로 걸어 줍니다. 되돌리기는 심링크를 이전 릴리스로 되돌리는 것 하나이고, 이것이 세 방식 중 가장 빠릅니다.
어느 방식이든 배포 후에 남는 일
파일을 옮기는 것만으로 반영이 끝나지 않습니다. 캐시가 옛 코드를 붙잡고 있습니다.
OPcache 는 컴파일된 바이트코드를 들고 있고, 심링크 전환에서는 realpath 캐시가 옛 경로를 계속 가리킵니다. PHP-FPM 을 재적재하면 새 워커가 깨끗한 캐시로 시작합니다. 그다음 wp cache flush 로 오브젝트 캐시를, 마지막으로 페이지 캐시를 비웁니다.
배포와 서버 구성 전반은 서버 · 인프라 아카이브에서 이어지고, 재현 가능한 배포 구성을 처음부터 세우는 작업은 최적화 지원 사업에 포함돼 있습니다.
다음 회차
배포가 명령 한 줄이 됐다면, 그 앞에 자동 검사를 세울 차례입니다. 다음 회차는 워드프레스 프로젝트의 CI — 무엇을 현실적으로 자동 검사할 수 있는가입니다.