워드프레스를 버전 관리에 올리는 일은 “전부 추가” 로 시작하면 반드시 사고가 됩니다. 코어 · 업로드 · 설정 파일이 한 트리에 섞여 있는 구조라, 무엇을 커밋하고 무엇을 제외할지의 경계를 먼저 긋고 시작해야 합니다. 이 글은 저희가 고객 사이트를 Git 으로 옮길 때 실제로 쓰는 기준입니다.
커밋 경계 — 한 장으로
판단 기준은 하나입니다. 이 파일을 잃었을 때 코드로 다시 만들 수 있는가? 다시 만들 수 있으면(코어 · 벤더 · 캐시) 제외하고, 만들 수 없으면(직접 쓴 테마 · 플러그인) 커밋합니다. 단 하나의 예외가 비밀값입니다 — 다시 만들 수 없지만 커밋해서도 안 됩니다.
왜 wp-config.php 가 첫 번째인가
이 파일에는 DB 비밀번호와 인증 솔트 8개가 평문으로 들어 있습니다. 저장소가 공개되는 순간 — 혹은 비공개라도 저장소 접근 권한이 한 번 새는 순간 — 사이트 전체의 세션을 위조할 수 있는 재료가 함께 나갑니다. 저희가 인수한 구 사이트 중에는 실제로 SVN 트리에 평문 DB 비밀번호와 솔트가 커밋된 채 수년간 방치된 경우가 있었습니다. 저장소에는 wp-config.sample.php 만 두고, 실제 값은 배포 시점에 서버에서만 만듭니다.
커밋된 비밀값은 삭제 커밋으로 지워지지 않습니다. 히스토리에 남고, 포크와 클론에 이미 복제됐습니다. 유일한 대응은 값 자체를 폐기하고 재발급하는 것입니다.
실전 .gitignore
docroot 가 저장소 루트 바로 아래 wordpress/ 인 배치 기준입니다. 경로만 환경에 맞게 조정하세요.
# 비밀값 — 절대 커밋 금지
wordpress/wp-config.php
.env
# 코어 — 버전과 zip 으로 재현된다
wordpress/wp-admin/
wordpress/wp-includes/
wordpress/wp-*.php
wordpress/index.php
wordpress/license.txt
wordpress/readme.html
# 사용자 산출물 · 런타임
wordpress/wp-content/uploads/
wordpress/wp-content/upgrade/
wordpress/wp-content/cache/
# 서드파티 (버전 고정은 문서로)
wordpress/wp-content/themes/twenty*/
# 빌드 · 도구
node_modules/
*.sql
*.log코어를 제외하면 버전은 어떻게 고정하나
코어 파일 대신 버전 번호를 기록합니다. 배포 스크립트가 wp core download --version=X.Y 로 같은 버전을 내려받으면 어느 서버에서든 같은 트리가 재현됩니다. 코어를 통째로 커밋하면 저장소가 수십 MB 씩 커지고, 코어 업데이트가 수천 파일짜리 diff 가 되어 정작 우리가 고친 코드 리뷰가 묻힙니다.
uploads 를 제외하는 이유와 대책
업로드 디렉터리는 콘텐츠이지 코드가 아닙니다. 고객 이미지 수 GB 가 저장소에 들어가면 클론이 느려지는 것으로 끝나지 않고, 고객 자산이 코드 저장소의 접근 권한을 따라 이동하게 됩니다. 업로드는 DB 와 함께 백업 체계(스냅샷 · 오브젝트 스토리지)가 담당하는 것이 맞습니다.
이미 커밋해 버렸다면
- 비밀값 — 지금 즉시 DB 비밀번호를 바꾸고 솔트를 재발급합니다 (
api.wordpress.org/secret-key/1.1/salt/). 히스토리 세탁은 그 다음 문제입니다. - 대용량 파일 —
git filter-repo로 히스토리에서 걷어냅니다. 협업 중이라면 전원 재클론이 필요하니 일정을 잡고 진행하세요. - 지금부터라도 — .gitignore 를 먼저 넣고,
git rm -r --cached로 추적만 해제하면 파일은 서버에 남습니다.
이 경계 긋기까지가 개발 워크플로우의 절반입니다. 나머지 절반 — 스테이징에서 검증한 것을 그대로 프로덕션에 올리는 절차는 되돌릴 수 있는 배포에서 다루고, 저희가 실제 작업에서 밟는 순서는 작업 과정에 공개돼 있습니다.