서버에서 파일을 바로 고치는 방식은 처음에는 가장 빠릅니다. 한 줄 고쳐 올리고 새로고침하면 끝나니까요. 문제는 그 방식에 되돌릴 지점이 없다는 것입니다. 무엇을 바꿨는지 기록이 남지 않고, 실수는 곧바로 방문자에게 노출되며, 두 사람이 같은 파일을 만지면 한쪽의 작업이 조용히 사라집니다.
이 연재는 워드프레스를 코드처럼 다루는 파이프라인을 세웁니다. 저장소 · 비밀값 · DB 동기화 · 스테이징 · 배포 · 되돌리기까지 이어지는데, 그 전부의 출발점이 로컬 환경입니다. 로컬에서 재현되지 않는 문제는 프로덕션에서 고치게 되고, 그 순간 나머지 규율이 전부 무너집니다.
세 가지 선택지와 각각이 포기하는 것
선택지는 실질적으로 셋입니다. 비교의 기준은 “설치가 쉬운가” 가 아니라 프로덕션과 무엇이 같고 무엇이 다른가 입니다.
PHP 내장 서버는 wp server 한 줄로 뜹니다. 대신 nginx 도 Apache 도 없으므로 리라이트 규칙 · FastCGI 캐시 · 보안 헤더처럼 웹서버가 하는 일은 전부 재현되지 않습니다. 기본적으로 요청을 한 번에 하나씩 처리한다는 점도 기억해 둘 만합니다 — 페이지가 자기 사이트에 HTTP 요청을 보내는 코드가 있으면 그 자리에서 멈춥니다. 테마 하나를 열어 보는 용도로는 충분하고, 그 이상으로 쓰면 거짓 안심을 얻습니다.
네이티브 스택은 일상 개발에 가장 편합니다. 파일 접근이 빠르고, PHP 와 nginx 가 이미 맞춰져 있습니다. 대신 확장 모듈 구성과 웹서버 설정은 대체로 주어진 대로 쓰게 됩니다. 프로덕션이 특정 확장(예: imagick · redis)에 의존한다면 그것이 로컬에 있는지 직접 확인해야 합니다.
컨테이너는 PHP 버전 · 확장 · DB 버전 · Redis · nginx 를 프로덕션과 같은 조합으로 묶을 수 있습니다. 대가는 부품 수와, 바인드 마운트에서의 파일 접근 속도입니다. 캐시 계층이나 서버 설정을 다루는 프로젝트라면 이 대가는 대체로 지불할 만합니다.
고르는 기준은 “차이 목록” 이다
어느 쪽이 옳은지는 프로젝트마다 다릅니다. 정하는 방법은 하나뿐입니다 — 프로덕션과 로컬의 차이를 실제로 뽑아 보는 것입니다. 추측하지 말고 출력해서 대조합니다.
# 프로덕션에서 한 번
php -v
php -m | sort > prod-modules.txt
# 로컬에서 같은 것을 뽑아 대조한다
php -m | sort > local-modules.txt
diff prod-modules.txt local-modules.txt여기서 나오는 차이 목록이 곧 위험 목록입니다. 확장 하나가 없으면 그 기능은 로컬에서 영영 재현되지 않고, PHP 버전이 다르면 문법 · 폐기 경고 · 형 변환 동작이 달라집니다. 차이가 몇 줄 안 된다면 네이티브 스택으로 충분하고, 목록이 길다면 컨테이너로 맞추는 편이 결국 빠릅니다.
로컬에서만 켜는 설정
환경이 정해졌으면 로컬 전용 설정을 켭니다. 이 값들은 프로덕션에 절대 따라가면 안 되는 것이라, 다음 회차의 저장소 규칙과 그다음 회차의 환경별 설정이 필요해지는 첫 번째 이유입니다.
마지막 줄에 설명을 붙이면 — 업로드 폴더는 수 기가바이트가 되기 쉽고, 그 안에는 고객이 올린 파일이 들어 있습니다. 개발에 필요한 것은 대체로 구조이지 파일 전부가 아닙니다. 이미지가 깨져 보이는 것이 불편하다면, 없는 파일 요청을 프로덕션으로 넘기는 리라이트 규칙 한 줄이 복사보다 훨씬 저렴합니다.
서버 구성 자체를 더 파고들고 싶다면 서버 · 인프라 아카이브가 이어지는 자리이고, 운영 중인 사이트를 재현 가능한 구성으로 옮기는 작업 자체를 맡기고 싶다면 최적화 지원 사업에 Docker 기반 재구성이 포함돼 있습니다.
다음 회차
로컬이 생겼으니 이제 변경을 기록할 차례입니다. 다음 회차는 워드프레스 저장소의 모양 — 무엇을 커밋하고 무엇을 무시하는가이고, 그 기준은 딱 한 문장으로 정리됩니다.