워드프레스 백업 및 복구 실전 가이드

왜 서버 이전부터 시작했는가

2편에서 설계한 반자동화 커리큘럼의 핵심 실습 주제는 "수강생이 만든 결과물을 자동으로 홈페이지에 게시하는 자동화"였다. 아이디어는 명확했고 흐름도 분명했다. 학생이 결과물을 제출하면 AI가 설명을 정리하고, 이미지가 함께 정돈되고, 홈페이지 갤러리에 자동으로 올라가는 구조였다.

그런데 막상 기존 홈페이지를 열어보니 자동화 이전에 더 큰 문제가 있었다. 디스크 용량이 7GB에 불과했고, 백업 플러그인을 돌릴 여유조차 없었다. phpMyAdmin은 호스팅사 정책상 차단되어 있었고, 앞으로 학생 결과물이 쌓이기 시작하면 감당할 수 없는 구조였다.

결국 자동화는 한 단계 뒤로 미루고, 먼저 할 일이 정해졌다. 기존 홈페이지를 확장 가능한 새 호스팅으로 옮기는 것. 이게 이번 3편이다.

백업은 선택이 아니라 필수입니다. 자동화를 붙이기 전에 안정적인 운영 환경이 먼저 만들어져 있어야 합니다.

기존 서버 vs 신규 서버

서버 이전의 핵심은 결국 두 가지다. 파일을 안전하게 백업하고, 데이터베이스를 온전히 옮기는 것. 이 두 가지 중 하나라도 빠지면 복구가 불가능하다.

워드프레스는 두 조각으로 이루어진다

워드프레스를 처음 다루는 사람들이 가장 많이 오해하는 지점이 이것이다. "홈페이지 파일만 백업하면 되는 거 아닌가요?"라는 질문이 대부분이다. 하지만 워드프레스는 파일과 데이터베이스가 분리되어 있고, 둘 다 백업해야 진짜 백업이다.

파일 쪽에서 특히 중요한 것은 wp-config.php다. 이 파일 안에 데이터베이스 접속 정보가 들어있어서, 복구할 때 이 파일을 수정하지 않으면 새 서버에서 절대 연결되지 않는다.

1단계. FTP로 파일 백업하기

파일 백업에는 FileZilla 같은 FTP 클라이언트를 사용한다. 호스팅사에서 발급받은 FTP 접속 정보(호스트·아이디·비밀번호)를 입력하고, 원격 사이트의 www 또는 public_html 폴더 전체를 로컬 PC로 다운로드한다.

실행 순서

1. FileZilla 설치 — filezilla-project.org에서 무료로 다운로드
2. FTP 접속 정보 입력 — 호스팅사에서 제공한 호스트·아이디·비밀번호 그대로 사용
3. www 폴더 전체 다운로드 — 원격의 www(또는 public_html) 폴더를 로컬로 끌어내린다
4. 백업 확인 — wp-admin, wp-content, wp-includes 폴더와 wp-config.php 파일이 포함됐는지 점검

주의할 점이 두 가지 있다. 첫째, .htaccess 같은 숨김 파일도 반드시 포함해야 한다. FileZilla 설정에서 숨김 파일 보기를 켜지 않으면 빠뜨리기 쉽다. 둘째, wp-config.php에는 DB 비밀번호가 평문으로 들어있으니 백업 파일의 보관 위치에 주의해야 한다.

2단계. 데이터베이스 백업하기

DB 백업에는 상황에 따라 세 가지 선택지가 있다.

이번 SJ Atelier 이전 작업에서는 기존 호스팅이 phpMyAdmin을 차단했고, 디스크 여유가 부족해 플러그인도 쓸 수 없었다. 그래서 Adminer를 선택했다.

Adminer로 DB 백업하기

1. adminer.php 다운로드 — adminer.org에서 단일 파일(약 300KB)을 받는다
2. FTP로 웹 루트에 업로드 — 보안을 위해 파일명을 dbbackup.php 같은 임의의 이름으로 바꾼다
3. 브라우저에서 접속 — 도메인/dbbackup.php 주소로 접속
4. DB 로그인 — MySQL/MariaDB 선택 후 서버: localhost, 사용자·비밀번호 입력 (wp-config.php 안에 적혀 있다)
5. 내보내기 실행 — 출력을 "저장"으로, 형식을 "SQL"로 선택해 .sql 파일을 브라우저로 직접 다운로드
6. adminer 파일 즉시 삭제 — 백업이 끝나면 FTP에서 반드시 삭제. 남겨두면 보안 구멍이 된다

adminer 파일 삭제는 선택이 아니다. 업로드해둔 상태로 두면 DB 접속 경로가 그대로 노출된다. 이 단계를 잊으면 며칠 안에 정체불명의 로그인 시도가 쌓이기 시작한다.

3단계. 새 호스팅에 복구하기

이제 백업한 파일과 SQL을 새 호스팅에 올린다. 순서는 정해져 있다.

wp-config.php 수정이 가장 중요하다

새 호스팅에 파일을 업로드한 뒤 가장 먼저 해야 하는 일은 wp-config.php 안의 DB 접속 정보를 새 것으로 바꾸는 것이다.

수정 전(기존 호스팅)과 수정 후(새 호스팅)의 차이는 단순하다. DB_NAME, DB_USER, DB_PASSWORD 세 값을 새 호스팅에서 발급받은 값으로 교체한다. DB_HOST는 대부분의 경우 localhost 그대로 둔다.

이 수정을 빼먹고 파일만 그대로 옮기면 사이트가 전혀 열리지 않는다. "Error establishing a database connection" 메시지가 뜨면 99% 이 문제다.

wp_options 테이블의 URL 바꾸기

도메인이 바뀌는 경우 wp_options 테이블에서 두 개 항목의 URL을 새 도메인으로 바꿔야 한다. phpMyAdmin에서 직접 편집하거나 SQL로 수정한다.

• siteurl — https://old-domain.com → https://new-domain.com
• home — https://old-domain.com → https://new-domain.com

본문 내부에 박혀 있는 URL까지 일괄로 교체하려면 Better Search Replace 플러그인을 쓰면 깔끔하다. 이미지 경로, 내부 링크, 시리얼라이즈된 데이터까지 안전하게 교체해 준다.

4단계. 자주 발생하는 오류와 해결법

실제로 이전 작업을 하다 보면 만나게 되는 오류들이다.

500 Internal Server Error — .htaccess 원인 이전 호스팅 전용 설정이 .htaccess에 남아 있어 새 서버에서 충돌한다. 워드프레스 기본 .htaccess로 교체하면 해결된다.

500 Error — DB 연결 실패 wp-config.php의 DB 이름·사용자·비밀번호 중 하나가 틀렸다. 오타 한 글자만 있어도 발생한다.

500 Error — 플러그인 충돌 특정 플러그인이 새 환경과 호환되지 않는다. FTP에서 plugins 폴더를 plugins-old로 일단 이름만 바꾸면 사이트가 다시 뜬다. 이후 하나씩 되살리며 범인을 찾는다.

Disk quota exceeded 기존 호스팅의 용량 초과. 불필요한 파일을 정리하거나, DB만 먼저 백업해서 새 호스팅으로 옮긴 뒤 파일을 순차 이동한다.

406 Not Acceptable 호스팅사가 특정 파일명(특히 adminer.php)의 접근을 차단한다. dbbackup.php 같은 임의 이름으로 바꾸면 통과된다.

복구 완료 체크리스트

모든 작업이 끝났다면 아래 항목을 하나씩 확인한다.

• DB 가져오기(Import) 성공 확인
• wp-config.php에 새 DB 정보 입력 완료
• 파일 전체 public_html에 업로드 완료
• .htaccess를 워드프레스 기본값으로 초기화
• wordfence-waf.php 등 이전 서버 전용 파일 제거
• wp_options에서 siteurl · home URL 변경
• WP_DEBUG = false 확인 (운영 시)
• 사이트 접속 정상 확인
• wp-admin 로그인 확인
• Better Search Replace로 내부 URL 일괄 치환

이제 진짜 시작점

여기까지가 SJ Atelier 홈페이지 이전의 전체 과정이다. 기존 7GB 용량에서 200GB 호스팅으로 옮기면서 디스크 여유, 확장 가능성, 관리 도구 접근성까지 한꺼번에 해결했다.

이제 다음 단계가 가능해졌다. 원래 목표였던 "수강생 결과물 자동 게시 자동화"를 실제로 붙일 수 있는 기반이 생긴 것이다. 파일 공간이 넉넉하고, DB 접근 권한이 열려 있고, 필요하면 바로 확장할 수 있는 환경. 자동화를 고민하기 전에 반드시 먼저 해결해야 하는 것들이다.

4편에서는 이 새 호스팅 위에 반자동화 게시 파이프라인을 어떻게 설계하고 연결했는지 이어 다룬다.