내 WordPress 사이트 URL이 준비에서 라이브로 변경되어 대시보드와 전체 재설정이 완전히 지워진 방법

게시 됨: 2025-11-15

WordPress 사이트를 시작하려면 모든 것을 라이브로 푸시하기 전에 테마, 플러그인 및 콘텐츠를 테스트하는 준비 환경부터 시작해야 하는 경우가 많습니다. 이는 모든 웹 개발 프로세스에서 중요한 단계입니다. 하지만 URL 변경과 같이 간단해야 하는 일로 인해 WordPress 대시보드가 지워지고 사이트가 손상되고 강제로 전체 재설정이 이루어지면 어떻게 될까요? 그것이 바로 나에게 일어난 일이며, 다른 사람들이 같은 실수를 피할 수 있도록 내 경험을 공유하고 싶습니다.

TLDR

사이트 URL을 변경하여 WordPress 사이트를 스테이징 환경에서 라이브 도메인으로 옮겼습니다. 불행하게도 이 작업을 잘못된 방식으로 수행하면 관리 대시보드가 완전히 손상되었습니다. 전체 재설정을 수행하고, 데이터베이스를 재구성하고, 백업에서 콘텐츠를 복원해야 했습니다. 이 문서에서는 무엇이 잘못되었는지, 그리고 귀하의 사이트에서 유사한 재난을 예방할 수 있는 방법을 설명합니다.

실수: URL을 부적절하게 변경함

모든 것이 순조롭게 진행되고 있었습니다. 저는 레이아웃을 조정하고, 올바른 플러그인을 설치하고, 모바일 반응성이 준비 환경에서 완벽하게 작동하는지 확인하는 데 몇 주를 보냈습니다. 라이브를 시작할 때가 되었을 때 설정 > 일반 화면에서 WordPress 주소(URL) 및 사이트 주소(URL) 변경에 관해 온라인에서 찾은 일부 문서를 따랐습니다. 그것은 간단해 보였다. 결국 스테이징 도메인을 라이브 도메인으로 업데이트하기만 하면 됐죠?

잘못된. "변경 사항 저장"을 누르자마자 대시보드에서 부팅되었습니다. 다시 로그인을 시도했을 때 빈 흰색 화면, 즉 일반적으로 WordPress "죽음의 흰색 화면" 이라고 알려진 화면이 나타났습니다. 내 프런트 엔드도 제대로 로드되지 않습니다. 그 순간 나는 내가 심각한 실수를 저질렀음을 깨달았다.

문제의 근원

WordPress는 데이터베이스와 코드 모두에 주요 URL 정보를 저장합니다. 대시보드 내에서 이를 변경하면 데이터베이스의 몇 가지 레코드만 업데이트됩니다. 그러나 내 준비 환경에는 여전히 이전 URL에 연결된 파일 경로, 캐시 및 직렬화된 PHP 데이터가 있었습니다. 전체 데이터베이스에서 준비 URL의 모든 인스턴스를 적절하게 바꾸지 않으면 문제가 발생합니다.

내가 겪은 핵심 문제는 다음과 같습니다.

직렬화 문제: WordPress의 일부 설정은 직렬화된 PHP 배열 로 저장됩니다. WP-CLI 또는 WP Migrate DB 와 같은 전문 도구를 통해 신중하게 처리하지 않으면 직접 문자열 교체가 작동하지 않습니다.
하드코딩된 링크: 위젯, 테마 옵션 및 일부 사용자 정의 게시물 유형에는 스테이징을 가리키는 하드코딩된 URL이 있습니다. 도메인 전환 후에 실패했습니다.
관리자 잠금: 사이트 URL이 변경되면서 로그인 페이지가 현재 손상된 준비 경로로 리디렉션되어 완전히 잠겼습니다.

복구 시도 중

초보자 포럼에서 찾을 수 있는 몇 가지 일반적인 수정 사항을 시도했습니다.

define('WP_HOME', 'https://livesite.com') 및 define('WP_SITEURL', 'https://livesite.com') 사용하여 wp-config.php 수동으로 편집하여 새 라이브 URL을 강제 적용합니다.
phpMyAdmin에 액세스하여 wp_options 테이블을 직접 업데이트합니다.
브라우저 캐시 지우기, 플러그인 비활성화, 테마 폴더 이름 바꾸기 등 기본적으로 전체 삭제 이외의 모든 작업을 시도합니다.

아무것도 작동하지 않았습니다. 사이트는 프런트엔드와 백엔드 모두 여전히 다운된 상태였습니다. 더 나쁜 것은 사후 준비 형식의 데이터베이스 구조에 대한 최근 전체 백업이 없었기 때문에 여전히 모든 곳에서 준비 도메인을 참조하고 있었습니다.

고통스러운 결정: 전체 재설정 및 복원

몇 시간 동안 복구 시도가 실패한 후, 최선의 방법은 다시 시작하는 것임을 깨달았습니다. 다행히도 게시물 콘텐츠와 테마 사용자 정의를 XML 파일로 내보내고 준비 사이트에서 FTP를 통해 이미지와 자산을 저장했습니다. 이것을 사용하여 전체 웹사이트 재설정을 시작했습니다. 방법은 다음과 같습니다.

1. WordPress 설치를 지웠습니다.

내 호스팅 플랫폼의 제어판을 사용하여 손상된 데이터베이스와 함께 현재 WordPress 설치를 삭제했습니다. 저는 라이브 도메인에 WordPress를 다시 설치하여 깨끗한 상태로 시작했습니다.

2. 다시 가져온 콘텐츠

WordPress Importer 플러그인을 사용하여 내 게시물, 페이지 및 기본 메타데이터가 포함된 백업된 XML 파일을 업로드했습니다. 미디어 파일이 누락된 경우 수동으로 다시 업로드해야 했습니다.

3. 플러그인 재설치 및 재구성

재설정으로 인해 플러그인 설정이 손실되었기 때문에 하나하나 재설치하고 다시 구성했습니다. 특히 사용자 정의 게시물 유형과 사용자 역할 구성이 포함된 경우에는 상당한 시간이 걸렸습니다.

4. 재구축된 메뉴, 위젯, 사용자 정의 설정

안타깝게도 이 데이터는 일반 내보내기에 항상 포함되지는 않습니다. 특히 customize_changeset 데이터를 명시적으로 백업하지 않은 경우에는 더욱 그렇습니다. 개발 과정에서 운 좋게 찍은 스크린샷을 참조하여 메뉴와 위젯을 수동으로 다시 만들어야 했습니다.

내가 그 모든 것에서 배운 것

이 사건은 심각한 경각심을 불러일으켰습니다. 여러분이 저처럼 힘들게 배울 필요가 없도록 이 교훈을 공유하고 있습니다.

주요 시사점:

영향을 완전히 인식하지 않는 한 WordPress 관리 패널에서 사이트 URL을 변경하지 마십시오 .
WP Migrate DB , Duplicator 또는 All-in-One WP Migration 과 같은 전용 마이그레이션 도구를 사용하여 스테이징에서 라이브로의 전환을 처리하세요.
구조적 변경을 수행하기 전에 항상 파일과 데이터베이스를 모두 백업하십시오 .
데이터베이스의 URL은 직렬화될 수 있으므로 간단한 문자열 교체로 인해 손상될 수 있다는 점을 이해하세요 .

권장되는 마이그레이션 전략

사이트를 스테이징에서 라이브로 이동할 계획이라면 이 전략을 사용하여 위험을 최소화하세요.

모든 것을 백업하십시오 . 플러그인이나 호스트 도구를 사용하여 사이트와 데이터베이스의 전체 백업을 수행하십시오.
마이그레이션 플러그인 사용 : WP Migrate DB Pro 와 같은 도구는 직렬화된 배열을 포함한 URL을 안전하게 대체합니다.
내부 링크를 지능적으로 업데이트하십시오 . 마이그레이션 후 Better Search와 같은 도구를 사용하여 직렬화 옵션을 활성화 하여 내부 URL을 올바르게 업데이트하십시오.
꼭 필요한 경우에만 wp-config.php 업데이트하고 URL 변경 시 GUI에만 의존하지 마십시오.
리디렉션 및 SSL 확인 : 새 라이브 사이트가 올바르게 리디렉션되고 작동하는 HTTPS가 구성되어 있는지 확인하세요.

결론

URL을 스테이징에서 라이브로 변경하는 것은 작은 작업처럼 보이지만 WordPress의 경우 올바르게 수행하지 않으면 치명적인 결과를 초래할 수 있습니다. 순조롭게 사이트를 시작하려고 했으나 이틀 동안 문제 해결, 데이터 복구 및 사이트 재구축을 해야 하는 시련이 발생했습니다. 마이그레이션을 진지하게 다루십시오. 올바른 도구를 사용하고, 문서를 읽고, 백업을 만들고, 확실하지 않은 경우 도움을 줄 개발자를 고용하는 것을 고려하십시오.

현재 내 라이브 사이트는 원활하게 운영되고 있지만 이제 라이브로 전환하기 전에 복제된 테스트 환경에서 모든 주요 변경 사항을 수행합니다. 그 한 번의 실수로 인해 수십 시간이 걸렸지만 WordPress 마이그레이션을 마땅히 받아야 할 배려와 존중으로 대하는 법도 배웠습니다.