워드프레스를 운영하다 보면 플러그인이나 테마를 수정해야 하는 순간이 자주 생깁니다. 특히 OpenLiteSpeed 환경에서는 캐시와 최적화 설정이 복잡하게 연결되어 있어서 작은 수정 하나만 잘못해도 사이트 전체가 깨질 수 있습니다.
저도 Astra 테마 오류를 수정하는 과정에서 처음으로 테스트 사이트가 필요했습니다. 당시 개발자에게 오류 화면을 보여줘야 했는데 원본 사이트에서 그대로 수정하기에는 부담이 컸습니다.
그 과정에서 알게 된 것이 WP Staging이었고, 지금은 LiteSpeed Cache 설정이나 워드프레스 플러그인 테스트를 할 때 거의 항상 먼저 복제 사이트를 만드는 편입니다.
목차
WP Staging 사용법을 찾게 된 이유
처음에는 단순히 테스트만 생각했습니다. 그런데 실제 운영에서는 문제가 더 많았습니다.
- 플러그인 충돌 발생 가능성
- 캐시 설정 꼬임 현상
- 테마 수정 후 레이아웃 깨짐
- 방문자에게 오류 화면 노출
- OpenLiteSpeed 캐시 재생성 문제
특히 LiteSpeed Cache를 사용하는 경우 설정 하나만 바꿔도 모바일 화면이나 CSS가 갑자기 깨지는 일이 있었습니다. 원본 사이트에서 바로 수정하는 방식은 위험하다고 느껴졌고, 결국 복제 사이트를 따로 운영하게 됐습니다.
플러그인 설치 후 가장 먼저 확인했던 부분
워드프레스 관리자에서 플러그인 추가 메뉴로 들어가 WP Staging을 검색하면 바로 찾을 수 있습니다. 설치 수가 많고 업데이트도 꾸준히 진행되고 있어서 최근 워드프레스 버전과의 충돌은 비교적 적은 편이었습니다.
지원 포럼에도 실제 오류 사례가 많아서 OpenLiteSpeed 환경에서 생기는 문제를 찾는 데 도움이 됐습니다.
WP Staging 사용법에서 가장 먼저 진행했던 단계
플러그인을 활성화하면 관리자 메뉴에 WP Staging 항목이 추가됩니다. 처음 들어가면 CREATE NEW STAGING SITE 버튼이 보이는데 여기서 복제 사이트 생성을 시작할 수 있었습니다.
처음에는 복잡한 서버 설정이 필요할 줄 알았는데 의외로 워드프레스 내부에서 대부분 처리되는 방식이라 어렵지 않았습니다.
복제 사이트 이름을 정할 때 중요했던 부분
다음 단계에서는 테스트 사이트 이름을 입력하게 됩니다.
저는 보통:
- test
- staging
- dev
- backup-test
같이 구분하기 쉬운 이름을 사용했습니다.
OpenLiteSpeed 서버에서 여러 테스트 사이트를 만들 경우 폴더 구조가 헷갈릴 수 있어서 이름을 명확하게 나누는 편이 관리하기 훨씬 편했습니다. 사이트 이름을 입력한 뒤 Start Cloning 버튼을 누르면 실제 복제가 시작됩니다.
복제 중 브라우저를 닫았다가 생겼던 문제
처음 WP Staging 사용법을 테스트할 때 가장 많이 실수했던 부분이 복제 도중 브라우저를 닫는 것이었습니다. 사이트 크기가 크면 시간이 꽤 오래 걸리는데, 중간에 브라우저를 닫으면 복제가 실패하는 경우가 있었습니다.
특히 이미지와 캐시 파일이 많은 사이트는 시간이 더 오래 걸렸습니다. LiteSpeed Cache와 QUIC.cloud를 함께 사용하는 경우 캐시 데이터까지 많아져서 예상보다 시간이 길어질 수 있었습니다.
WP Staging 사용법에서 가장 편했던 부분
복제가 끝나면 Open Staging Site 버튼이 나타납니다. 여기서 바로 테스트 사이트로 이동할 수 있었는데, 별도로 데이터베이스를 연결하거나 서버 설정을 수정할 필요가 없다는 점이 가장 편했습니다.
특히 CyberPanel 환경에서는 직접 서브도메인을 만드는 방식보다 훨씬 간단하게 느껴졌습니다.
로그인 화면에서 처음 당황했던 부분
테스트 사이트로 이동하면 로그인 화면이 다시 나타납니다. 처음에는 새로운 계정을 만들어야 하는 줄 알았는데 기존 워드프레스 관리자 계정 그대로 로그인하면 됐습니다.
복제 사이트라는 것을 바로 구분할 수 있도록 상단 관리자 바 색상도 변경되어 있어서 실수로 원본 사이트를 수정하는 일은 거의 없었습니다.
원본 사이트와 구분하기 쉬웠던 이유
로그인 후 가장 먼저 눈에 들어왔던 것은 상단 관리자 바 색상이었습니다. 원본 사이트와 다른 색으로 표시되기 때문에 지금 수정하는 곳이 테스트 환경이라는 것을 바로 확인할 수 있었습니다.
이 부분은 실제 운영할 때 꽤 중요했습니다. OpenLiteSpeed 캐시 설정이나 robots.txt 수정처럼 민감한 작업은 원본 사이트와 헷갈리면 위험할 수 있기 때문입니다.
개발자 공유용 계정을 따로 만들었던 이유
개발자와 오류를 공유할 때는 기존 관리자 계정을 그대로 전달하지 않았습니다. 워드프레스 사용자 메뉴에서 새 사용자를 만들어 테스트 사이트 전용 계정을 따로 전달하는 방식이 훨씬 안전했습니다.
특히 보안 플러그인이나 관리자 권한 설정이 복잡한 경우에는 계정을 따로 분리하는 편이 관리하기 편했습니다.
더 이상 사용하지 않는 테스트 사이트 정리 방법
테스트가 끝난 뒤에는 복제 사이트를 그대로 두지 않는 편이 좋았습니다. OpenLiteSpeed 서버에서는 복제 사이트도 저장 공간을 계속 사용하기 때문에 오래 쌓이면 용량이 꽤 빠르게 증가했습니다.
WP Staging 첫 화면에서 Actions 메뉴를 열면 Delete 항목이 나타납니다. 삭제를 진행하면 데이터베이스와 파일이 함께 제거됩니다.
실제 운영하면서 가장 체감했던 변화
WP Staging 사용법을 익힌 뒤 가장 크게 달라진 부분은 수정 작업에 대한 부담이 줄었다는 점이었습니다.
예전에는:
- 플러그인 업데이트
- LiteSpeed Cache 설정 변경
- 테마 수정
- 광고 코드 삽입
같은 작업을 할 때마다 사이트가 깨질까 걱정했습니다.
지금은 대부분 테스트 사이트에서 먼저 확인하고 원본에 적용하는 방식으로 바뀌었습니다. 특히 OpenLiteSpeed 환경은 캐시 구조가 복잡하기 때문에 테스트 공간이 따로 있다는 것만으로도 안정감 차이가 꽤 컸습니다.
FAQ
WP Staging 사용법은 무료 버전만으로 충분한가요?
테스트 사이트 생성과 기본 복제 정도는 무료 버전만으로도 충분했습니다. 다만 수정 내용을 원본 사이트에 바로 반영하려면 프로 기능이 필요했습니다.
WP Staging 사용법에서 저장 공간은 많이 필요한가요?
원본 사이트를 그대로 복제하기 때문에 이미지와 캐시 파일이 많으면 공간 사용량도 커질 수 있습니다. OpenLiteSpeed 캐시를 많이 사용하는 사이트는 먼저 용량을 확인하는 편이 안전했습니다.
WP Staging 사용법이 LiteSpeed Cache와 충돌하나요?
현재까지는 큰 충돌 없이 사용 중입니다. 다만 복제 후 캐시를 한 번 비우면 레이아웃이 더 안정적으로 보이는 경우가 있었습니다.
