워드프레스 관리자 "모든 데이터 내보내기"만으로 충분할까? Docker Compose 환경에서의 서버 마이그레이션을 실무 관점에서 정리한다.
1. 먼저 짚고 넘어가자: 워드프레스 관리자 "내보내기"의 한계
워드프레스 대시보드에서 도구 → 내보내기 → 모든 콘텐츠를 선택하면 WXR(WordPress eXtended RSS) 형식의 XML 파일이 다운로드된다. 이 파일에는 글, 페이지, 댓글, 카테고리, 태그, 그리고 미디어 파일에 대한 참조 링크가 포함된다.
하지만 이 방식에는 치명적인 한계가 있다.
- 테마·플러그인 미포함: 설치된 테마, 플러그인, 위젯 설정이 일절 포함되지 않는다.
- 미디어 파일 미포함: 실제 이미지나 동영상이 아닌 URL 참조만 담기므로, 원본 서버가 살아있어야 새 서버에서 미디어를 다시 끌어올 수 있다.
- DB 설정 데이터 유실: wp_options 테이블에 저장된 사이트 URL, 퍼머링크 구조, 플러그인별 설정값 등은 XML에 완전히 반영되지 않는다.
- Redis 캐시 데이터 제외: 오브젝트 캐시(Object Cache) 레이어는 워드프레스 내보내기와 무관하다.
- Nginx 설정 미포함: 리버스 프록시, SSL, 리다이렉트 규칙 등 웹서버 설정은 당연히 빠진다.
결론적으로, Docker Compose로 Nginx + WordPress App + Redis + MariaDB/MySQL 스택을 구성한 환경이라면 단순 XML 내보내기로는 서버 이전이 불가능하다. 전체 컨테이너 스택을 대상으로 한 체계적인 마이그레이션이 필요하다.

2. Docker WordPress 마이그레이션이란?
Docker WordPress 마이그레이션이란, 컨테이너화된 워드프레스 스택 전체를 한 서버에서 다른 서버로 옮기는 작업을 말한다. 여기서 "전체"란 다음을 의미한다.
| 컨테이너 | 역할 | 보존 대상 |
|---|---|---|
| wordpress-nginx | 리버스 프록시, SSL 터미네이션, 정적 파일 서빙 | nginx.conf, SSL 인증서, 사이트 설정 |
| wordpress-app | PHP-FPM 기반 워드프레스 애플리케이션 | wp-content(테마, 플러그인, 업로드 미디어), wp-config.php |
| wordpress-redis | 오브젝트 캐시 | 선택적(캐시는 재생성 가능) |
| wordpress-db | MariaDB/MySQL 데이터베이스 | 전체 데이터베이스 덤프 |
Docker의 핵심 장점은 이 모든 것이 docker-compose.yml 하나와 볼륨(Volume) 데이터로 정의된다는 점이다. 올바르게 구성되어 있다면, 설정 파일과 데이터만 새 서버로 복사하고 docker compose up -d를 실행하면 동일한 환경이 재현된다.
3. 마이그레이션 작동 원리: 단계별 프로세스
3-1단계: 원본 서버에서 데이터 백업
① 데이터베이스 덤프
# 실행 중인 DB 컨테이너에서 mysqldump 실행
docker exec wordpress-db mysqldump \
-u wordpress_user -p'your_password' \
--add-drop-table \
wordpress_db | gzip > wordpress_db_backup.sql.gz--add-drop-table 옵션은 복원 시 기존 테이블을 삭제 후 재생성하므로, 깔끔한 복원을 보장한다. gzip으로 압축하면 전송 시간을 크게 줄일 수 있다.
② wp-content 디렉토리 백업
# 워드프레스 볼륨에서 wp-content 압축
docker cp wordpress-app:/var/www/html/wp-content ./wp-content-backup
tar -czf wp-content-backup.tar.gz wp-content-backup/wp-content에는 테마, 플러그인, 업로드된 미디어 파일이 모두 포함된다. 이것이 워드프레스 사이트의 실질적인 "콘텐츠 자산"이다.
③ Docker Compose 및 설정 파일 복사
# 프로젝트 디렉토리 전체를 압축
tar -czf docker-project-backup.tar.gz \
docker-compose.yml \
.env \
nginx/conf.d/ \
nginx/ssl/ \
wp-config.php④ Redis 데이터 백업(선택)
# Redis 스냅샷 생성 후 복사
docker exec wordpress-redis redis-cli SAVE
docker cp wordpress-redis:/data/dump.rdb ./redis-dump.rdbRedis는 오브젝트 캐시 용도이므로 새 서버에서 자동으로 워밍업(재생성)된다. 하지만 대규모 사이트에서 초기 성능 저하를 최소화하고 싶다면 RDB 파일을 함께 옮기는 것도 방법이다.
3-2단계: 새 서버로 파일 전송
# SCP로 전송 (rsync도 가능)
scp wordpress_db_backup.sql.gz user@new-server:/home/user/migration/
scp wp-content-backup.tar.gz user@new-server:/home/user/migration/
scp docker-project-backup.tar.gz user@new-server:/home/user/migration/대용량 사이트라면 rsync --progress를 사용하면 진행 상황을 확인하면서 전송할 수 있고, 중단 시 이어받기도 가능하다.
3-3단계: 새 서버에서 복원
① Docker 환경 준비
# Docker, Docker Compose 설치 확인
docker --version
docker compose version
# 프로젝트 디렉토리 생성 및 설정 파일 복원
mkdir -p /opt/wordpress
cd /opt/wordpress
tar -xzf /home/user/migration/docker-project-backup.tar.gz② docker-compose.yml에서 도메인/IP 수정
워드프레스는 DB 내 wp_options 테이블의 siteurl과 home 값에 도메인을 저장한다. 도메인이 변경되는 경우, DB 덤프 파일에서 직접 치환하는 것이 가장 확실하다.
# 도메인 변경이 필요한 경우 (serialized 데이터 주의!)
# WP-CLI 사용 권장
docker exec wordpress-app wp search-replace \
'https://old-domain.com' 'https://new-domain.com' \
--all-tables --allow-root주의할 점은, 워드프레스가 플러그인 설정 등에서 직렬화(serialized) 형태로 도메인을 저장한다는 것이다. 단순 텍스트 에디터로 치환하면 직렬화된 문자열의 길이(length) 값이 깨져서 데이터가 손상된다. 반드시 wp search-replace나 interconnectit/Search-Replace-DB 같은 직렬화 인식 도구를 사용해야 한다.
③ 컨테이너 기동 및 데이터 복원
# 컨테이너 실행 (DB 컨테이너만 먼저)
docker compose up -d wordpress-db
# DB 복원
gunzip < wordpress_db_backup.sql.gz | \
docker exec -i wordpress-db mysql \
-u wordpress_user -p'your_password' wordpress_db
# wp-content 복원
tar -xzf wp-content-backup.tar.gz
docker cp wp-content-backup/ wordpress-app:/var/www/html/wp-content
# 전체 스택 기동
docker compose up -d④ 퍼미션 확인
# 워드프레스 파일 소유권 설정
docker exec wordpress-app chown -R www-data:www-data /var/www/html/wp-content파일 권한이 맞지 않으면 미디어 업로드 실패, 플러그인 설치 불가 등의 문제가 발생한다.
4. 마이그레이션 도구 비교
실무에서 자주 사용되는 마이그레이션 방법을 비교하면 다음과 같다.
| 방법 | 장점 | 단점 | 적합한 상황 |
|---|---|---|---|
| 수동 백업 (mysqldump + tar) | 완전한 통제, 무료, Docker 친화적 | CLI 숙련도 필요 | Docker 환경의 개발자 |
| Duplicator 플러그인 | GUI 기반, DB+파일 패키지 생성 | 대용량 사이트에서 타임아웃 가능 | 소규모~중규모 사이트 |
| All-in-One WP Migration | 원클릭 마이그레이션, 테마·플러그인 포함 | 무료 버전 용량 제한, Docker 볼륨 미지원 | 비개발자 |
| Docker Volume 직접 복사 | 모든 데이터 보존, 정확한 환경 재현 | 볼륨 구조 이해 필요 | Docker-to-Docker 이전 |
| WP-CLI + rsync | 스크립트 자동화 가능, 대규모 사이트 적합 | 초기 설정 복잡 | 대규모·반복적 마이그레이션 |
Docker 환경에서는 수동 백업 + Docker Volume 복사 조합이 가장 안정적이다. 플러그인 기반 도구들은 컨테이너 환경을 고려하지 않은 경우가 많아, DB 호스트명을 localhost 대신 컨테이너 서비스명(예: db, wordpress-db)으로 설정해야 하는 등 추가 설정이 필요하다.
5. Docker Volume 백업의 두 가지 전략
Named Volume 방식
Named Volume을 사용하는 경우, Docker가 /var/lib/docker/volumes/ 하위에 데이터를 관리한다.
# Named Volume을 tar로 추출
docker run --rm \
-v wordpress_db_data:/source:ro \
-v $(pwd):/backup \
alpine tar -czf /backup/db_volume.tar.gz -C /source .Bind Mount 방식
Bind Mount는 호스트 파일 시스템 경로를 직접 마운트하므로, 디렉토리를 그대로 tar로 묶으면 된다.
# docker-compose.yml 예시
volumes:
- ./data/mysql:/var/lib/mysql
- ./data/wp-content:/var/www/html/wp-content
# 호스트에서 직접 백업
tar -czf full-backup.tar.gz ./data/Bind Mount 방식이 마이그레이션에서는 더 직관적이다. 프로젝트 디렉토리 전체를 압축해서 새 서버에 풀면 되기 때문이다.
6. 마이그레이션 체크리스트
실전에서 빠뜨리기 쉬운 항목들을 체크리스트로 정리한다.
- [ ] DB 덤프 완료 (mysqldump + gzip)
- [ ] wp-content 전체 백업 (테마, 플러그인, uploads)
- [ ] docker-compose.yml 및 .env 파일 복사
- [ ] Nginx 설정 파일 복사 (conf.d, ssl 인증서)
- [ ] wp-config.php 내 DB 연결 정보 확인
- [ ] 새 서버에서 Docker 엔진 및 Compose 버전 확인
- [ ] DB 복원 후 siteurl, home 값 확인
- [ ] 도메인 변경 시 wp search-replace 실행
- [ ] 파일 퍼미션 (www-data) 설정
- [ ] Redis Object Cache 플러그인 재활성화
- [ ] SSL 인증서 갱신 또는 Let's Encrypt 재설정
- [ ] DNS 레코드 변경 (A 레코드 → 새 서버 IP)
- [ ] 이전 서버의 컨테이너 중지 (DNS 전파 완료 후)
7. 실전 주의사항과 트러블슈팅
직렬화 데이터 손상: 워드프레스 DB에서 가장 흔한 마이그레이션 실패 원인이다. sed나 텍스트 에디터로 도메인을 바꾸면 s:23:"https://old-domain.com" 같은 직렬화 문자열의 길이가 맞지 않게 된다. 반드시 직렬화 인식 도구를 사용하자.
MySQL 인증 방식 충돌: MySQL 8.x의 caching_sha2_password 인증 방식이 구버전 워드프레스와 호환되지 않을 수 있다. docker-compose.yml에서 command: --default-authentication-plugin=mysql_native_password를 추가하면 해결된다.
Redis 연결 실패: 새 서버에서 Redis 컨테이너가 먼저 기동되지 않으면 워드프레스에서 연결 오류가 발생한다. depends_on 설정과 함께 wp-config.php의 WP_REDIS_HOST 값이 Docker 서비스명과 일치하는지 확인한다.
볼륨 퍼미션 문제: Docker Named Volume에서 Bind Mount로 전환하거나 서버 OS가 다른 경우, UID/GID 매핑이 달라져 권한 오류가 생길 수 있다. chown -R 33:33(www-data의 일반적인 UID)으로 수정한다.
8. 전망: 컨테이너 기반 WordPress 운영의 미래
2025년 현재, Docker를 활용한 워드프레스 운영은 점점 표준적인 접근이 되어가고 있다. 특히 AWS ECS/Fargate, Google Cloud Run, Kubernetes 같은 컨테이너 오케스트레이션 플랫폼과의 연계가 활발해지면서, 한 번 잘 구성된 Docker Compose 스택은 클라우드 환경 전반에서 재활용할 수 있게 되었다.
Infrastructure as Code(IaC) 도구인 Terraform이나 Ansible과 결합하면, 서버 이전 자체를 자동화 파이프라인으로 구축할 수도 있다. 마이그레이션이 "일회성 작업"이 아니라 "재현 가능한 프로세스"로 진화하는 것이다.
결론적으로, Docker 기반 WordPress 서버 이전의 핵심은 단순하다. 데이터베이스 덤프, 파일 시스템 백업, 설정 파일 복사. 이 세 가지를 빠짐없이 챙기면, 관리자 패널의 XML 내보내기로는 절대 달성할 수 없는 완벽한 환경 재현이 가능하다.
'Tech > AI & LLM' 카테고리의 다른 글
| GitHub 비밀번호 로그인 실패 : 토큰·SSH 기반 변경방법 (0) | 2026.03.10 |
|---|---|
| Mac / Mac Mini SSH 접속 설정 완전 가이드 (0) | 2026.03.10 |
| Ubuntu 서버 신규 사용자 추가와 SSH Key 등록 — 실무 가이드 (0) | 2026.03.10 |
| AI 에이전트 시대, 직장인이 진짜 알아야 할 것들 — 챗GPT 쓰던 시절은 이미 옛날이다 (0) | 2026.03.09 |
| RAG 검색 품질 개선 방법 (Hybrid Search, Metadata Filtering, Knowledge Graph까지) (0) | 2026.03.09 |