트라이얼 만료로 서버 날려먹고 뼈저리게 깨달은 워드프레스 호스팅 기준

워드프레스 호스팅 추천을 찾다가 이 글에 왔다면, 가격표 앞에서 백업부터 확인했으면 한다. 나는 Cloudways 3일 무료 체험의 만료일을 놓쳐 서버를 잃었다.

복구 화면에는 백업이 있었지만 disaster recovery limit 오류가 떴다. 새로 만들기로 결정한 뒤에야 복구가 진행됐다. 실제로 되찾은 것은 복구된 Cloudways 서버의 DB(글·설정이 담긴 데이터베이스)와 파일이었고, 그것을 Vultr로 옮겨 사이트를 살렸다.

이 글에는 2026년 8월 17일 작업 기록을 대조한 복구 경위와, 남은 백업에 따라 무엇부터 할지 정리했다. 호스팅 5종 가격표는 당시 선택을 설명하는 8월 자료다.

• 지금 서버가 사라졌다면: 남아 있는 자료별 복구 판단
• 복구 버튼을 눌렀는데 사이트가 안 열린다면: 실제 이전 과정과 확인 결과
• 새 호스팅을 고른다면: 사고 뒤 바꾼 선택 기준

트라이얼 만료부터 복구까지, 기록에 남은 순서

첫 서버는 Cloudways의 DigitalOcean 2GB, 싱가포르 리전이었다. 무료 체험 기간 안에 유료 전환을 결정하지 못했고, 8월 17일 다른 작업을 하다 접속 장애를 발견했다.

기록 날짜	확인한 일
8월 16일	체험 만료로 서버 삭제. 당시 사고 기록에 남은 삭제 날짜다.
8월 17일 발견	기존 IP의 HTTPS 연결이 안 됐고, HTTP에서는 내 블로그 대신 nginx 기본 페이지가 나왔다.
8월 17일 복구 시도	결제 등록 뒤 백업이 있는 복구 화면까지 들어갔지만 복구 한도 오류로 실행이 막혔다.
8월 17일 경로 변경	새로 구축하기로 결정한 직후 Cloudways 복구가 진행됐다. 복구 서버는 생겼지만 도메인 연결이 정상으로 돌아오지 않았다.
8월 17일 이전	복구 서버에서 DB와 파일을 꺼내 Vultr 서울로 옮겼다. 도메인이 새 서버를 찾도록 DNS를 바꾸고 HTTPS 연결과 공개 주소를 확인했다.

정확히 몇 시간 멈췄는지는 확인할 수 없다. 기록에는 삭제 날짜와 다음 날 복구 과정이 있지만, 장애 시작·종료 시각을 재는 감시 로그는 없다. 예전에 쓴 ‘2~3일 중단’은 이 기록으로 뒷받침되지 않아 정정했다.

기존 IP가 다른 사용자에게 넘어갔다는 설명도 추정이다. 확인한 사실은 HTTPS 연결 실패와 낯선 기본 페이지다. 기본 페이지가 나온다는 이유만으로 다른 사람의 서버라고 단정할 수는 없다.

Cloudways 복구 한도 오류가 왜 풀렸는지는 남은 기록으로 알 수 없다. 같은 오류를 만났다고 반복 클릭하면 해결된다는 뜻도 아니다. 계정 지원팀에 백업 존재 여부와 실행 가능한 복구 경로를 확인해야 한다.

서버가 삭제됐다면, 남아 있는 자료부터 구분한다

새 워드프레스를 설치하기 전에 무엇이 남아 있는지 적어 본다. 호스팅 백업, DB 파일, 이미지 폴더, 원고는 되살릴 수 있는 범위가 서로 다르다.

남아 있는 것	먼저 할 일	구분할 한계
호스팅사의 백업	실제 백업 날짜와 복구 가능 여부, 서버 전체인지 사이트 하나인지 확인한다.	같은 서버의 다른 사이트까지 과거 상태로 돌아갈 수 있다. 보존 기간이 지나거나 쓸 수 있는 백업이 없으면 복구가 어려울 수 있다.
서버 밖의 DB와 파일	둘의 백업 시점을 확인하고, 운영 사이트와 분리한 환경에서 복원을 검증한다.	DB 접속 설정, PHP·플러그인 호환성, DNS·HTTPS는 새 환경에 맞게 확인해야 한다.
원고와 이미지만	글을 다시 발행할 수 있는지, 기존 주소와 이미지 연결을 재구성할 수 있는지 확인한다.	댓글·사용자·플러그인 설정까지 되살리는 전체 사이트 백업은 아니다.
백업 위치를 모름	호스팅 계정과 별도 저장소에서 남은 사본을 확인한다. 지원팀에는 마지막 정상 날짜와 삭제·오류 화면을 전달한다.	남은 서버나 파일을 초기화하기 전에 사본을 확보한다. ‘삭제됐다’는 화면만 보고 복구 가능성을 확정하지 않는다.

Cloudways 공식 복구 문서는 백업과 계정·상품 조건에 따라 복구 가능 여부가 달라진다고 설명한다. Flexible 항목에는 14일 보존 제한이 있지만, 모든 삭제 서버가 14일 안이면 반드시 살아난다는 보장은 아니다. 복구 뒤 IP가 달라지면 도메인 연결과 인증서도 확인해야 한다. 2026년 9월 7일 확인했다.

워드프레스 공식 백업 안내의 기준은 DB와 파일을 함께 보관하는 것이다. 원고 사본만 믿지 말고, 댓글과 설정이 들어 있는 DB도 백업 대상에 넣는다.

DB 112KB와 파일 27MB를 옮긴 뒤 확인한 것

내 경우에는 첫 번째 경로로 복구 서버가 생겼고, 그 서버에서 두 번째 경로에 쓸 자료를 꺼냈다. 원고를 여섯 번 다시 올린 과정이 아니다.

1. 복구 서버에서 자료 확보. DB 덤프 112KB와 wp-content 압축 파일 27MB를 받았다. 당시 기록의 크기이며, 압축 파일에서는 캐시를 제외했다.
2. 새 서버에 DB와 파일 이식. DB 테이블 접두사를 유지했고, 새 DB 계정에 맞춰 연결 설정을 작성했다. 이전 호스팅에 의존하던 캐시 플러그인과 연결 파일도 정리했다.
3. 도메인 전환 전 확인. 서버 안에서 글 6편, 플러그인 8종, 테마와 사이트 주소를 확인했다. 내부 HTTP 응답은 200이었다.
4. DNS와 HTTPS 연결. 도메인이 새 서버를 가리키도록 바꾸고 인증서를 발급했다. 페이지뿐 아니라 사이트맵과 발행용 REST API 인증도 확인했다.

복구 뒤에도 끝이 아니었다. 새 서버에서 간헐적으로 502 오류가 났다. 당시 요청 기록에서는 내 도메인이 아닌 이름으로 들어오는 이전 서비스의 상태 확인 요청이 발견됐다. 이 요청들이 PHP 처리 자원을 쓰고 있었다.

내 사이트로 들어온 요청만 처리하도록 웹서버의 기본 호스트 처리를 분리한 뒤, 기록상 부하는 정상으로 돌아왔고 홈은 세 번 연속 200을 응답했다. 이 조치는 그 서버에서 확인한 원인에 대한 해결이다. 다른 502 오류에 같은 설정을 붙여 넣는 처방으로 쓰면 안 된다.

검사 대상	당시 남긴 결과	결과의 범위
글·설정	글 6편, 테마·플러그인 확인	기록에서 확인한 항목이다. DB의 모든 행을 전후 대조한 결과는 아니다.
공개 페이지	대상 URL의 HTTPS 200	주소가 열린다는 검사다. 모든 기능이 정상이라는 뜻은 아니다.
검색·발행 연결	사이트맵 200, REST API 인증 200	색인·순위 유지나 실제 새 글 발행 성공까지 증명하지 않는다.
간헐 오류	요청 처리 분리 뒤 홈 3회 연속 200	조치 직후 확인이다. 장기간 무장애 측정은 아니다.

글 6편과 허브를 되찾았고 확인한 범위에서 누락을 발견하지 못했다. 다만 ‘데이터 손실 0’이라고 전체를 보증할 만큼의 전후 대조 자료는 남아 있지 않다.

옵시디언 원고가 해 준 일과, DB 백업이 해 준 일

원고와 이미지를 옵시디언에 두었기 때문에, 복구가 끝내 안 되더라도 글을 다시 발행할 대안은 있었다. 하지만 그 대안을 실행해 사이트 전체를 복원한 것은 아니다. 실제 이전에는 복구 서버의 DB와 파일을 사용했다.

워드프레스 관리자에서 쓴 글도 DB 백업이 남아 있으면 복구할 수 있다. 반대로 원고만 남아 있다면 댓글·계정·설정은 별도로 재구성해야 할 수 있다. ‘글 원본이 있다’와 ‘사이트 전체를 되살릴 수 있다’를 구분하게 된 사고였다.

원고를 파일로 두는 발행 방식은 마크다운으로 워드프레스에 발행하기에서 설명한다. 저장소를 운영하는 이유는 LLM Wiki를 만든 이유에 적었다.

호스팅 5종 비교표는 당시 선택의 기록이다

아래는 2026년 8월 28일 각사 공식 페이지를 확인하며 남긴 가격이다. 현재 구매 견적이 아니다. 서로 메모리·관리 범위·약정 조건이 다른 상품이므로, 요금 차이 전체를 관리 서비스 비용이라고 계산할 수도 없다.

호스팅	월 비용 (2026년 8월 기준)	여러 블로그 운영	리전	관리 부담
Cloudways DigitalOcean 2GB (사고 전 사용)	$28 (Premium 기준), Standard는 8월 리서치 당시 $24	앱 수와 별도로 서버 자원 확인	싱가포르	서버 관리 지원, 사이트 운영은 별도
Vultr 서울 1GB High Frequency (이전 당시 선택)	$6, 자동 백업 +$1.2, 2GB는 $12	서버 자원 범위에서 직접 구성	서울	직접
AWS Lightsail 1GB	$7, 2GB는 $12	서버 자원 범위에서 직접 구성	서울 있음	직접
Hostinger Premium (공유 호스팅)	$2.99 (48개월 약정), 갱신 $10.99, 사이트 3개까지	3개까지	싱가포르 (8월 리서치 당시)	호스팅 관리 지원
카페24 뉴 매니지드 워드프레스	월 450원~ (Startup, SSD 700MB)	상품당 워드프레스 1개	국내	서버 관리 지원, 사이트 운영은 별도

당시 확인 출처: Cloudways · Vultr · Lightsail · Hostinger · 카페24. 약정·갱신가와 백업 비용은 구매할 때 다시 확인해야 한다.

Cloudways 요금 페이지, 2026-08-28 캡처. Premium 토글 기준이며 현재 요금 확인용 화면은 아니다.

Vultr High Frequency 요금 페이지, 2026-08-28 캡처.

워드프레스 호스팅을 고를 때 바꾼 기준 4가지

1. 만료·결제 실패 때 무슨 일이 생기는가. 서비스 정지와 삭제 시점, 백업 보존 기간을 확인한다. 가입한 날 만료일을 기록하고 그 전에 계속 쓸지 결정한다.
2. 백업이 실제로 남고, 내가 복구할 수 있는가. 백업 켜짐 표시뿐 아니라 마지막 성공 날짜, 보관 위치, 복구 범위를 확인한다. 원고와 설정 사본도 별도로 둔다.
3. 관리에 쓸 시간과 지원 범위가 맞는가. AI가 설치 명령을 만들더라도 업데이트·장애 대응·복구 결과의 판단은 운영자에게 남는다. 서버 관리에 쓸 시간이 없다면 지원 범위를 가격과 함께 비교한다.
4. 독자 위치와 실제 부하에 맞는가. 나는 한국 독자를 생각해 서울을 골랐다. 사이트를 여러 개 올릴 수 있다는 것과 안정적으로 처리할 용량이 있다는 것은 별도다. 이미지·DB·트래픽 증가와 백업 공간까지 본다.

내 선택은 당시 Vultr 서울 1GB와 자동 백업, 월 $7.2였다. 작은 블로그를 시작하며 직접 관리하기로 한 선택이지, 모든 초보 블로그에 충분한 용량이라는 뜻은 아니다. 서버 사양 변경에 걸리는 시간이나 중단 여부도 변경 전에 확인해야 한다.

설치 과정은 클로드 코드로 워드프레스 설치하기에 있다. 복구 기록에 나온 ‘1~2시간’은 처음 새로 구축할 때의 예상이므로, 이번 이전을 그 시간 안에 끝냈다는 실제로 잰 시간으로 쓰지 않는다.

자주 묻는 질문

클라우드웨이즈 서버가 삭제되면 14일 안에 무조건 복구되나요?

그렇게 단정할 수 없다. 사용 상품과 계정 상태, 실제 남은 백업을 확인해야 한다. 내 계정에서도 백업 화면은 보였지만 실행 제한 오류를 겪었다. 오류 화면과 마지막 정상 시점을 남기고 가능한 복구 경로를 확인하는 게 먼저다.

마크다운 원고만 있으면 워드프레스 백업은 필요 없나요?

필요하다. 원고는 글을 다시 만드는 데 도움이 된다. 댓글·계정·설정과 업로드 파일까지 복구하려면 DB와 파일 백업을 따로 준비해야 한다.

같은 주소로 서버만 옮기면 검색 순위도 유지되나요?

같은 URL을 쓰더라도 순위 유지를 보장할 수 없다. 구글의 호스팅 이전 안내에 따라 새 서버를 전환 전에 확인하고, 전환 뒤 접근 오류와 크롤링 상태를 살펴야 한다. 내 기록의 사이트맵 200은 색인 결과가 아니다.

지금 할 일은 호스팅 화면에서 마지막 백업 날짜·보관 위치·복구 대상 세 가지를 적는 것이다. 어디서 확인하는지 찾을 수 없다면 그 자체가 지원팀에 물을 내용이다.

다른 장애는 바이브코딩 블로그에서 겪은 사고 5가지에서 증상별로 볼 수 있다. 시리즈 순서는 워드프레스 블로그 만들기, 시작 전 전체 구성은 첫 편, AI 도구가 처음이라면 바이브코딩 시작 가이드를 참고하면 된다.

검증 기준

• 마지막 업데이트일: 2026-09-07
• 확인 환경: 2026-08-17 seoin.dev 사고 작업 기록과 이전 런북을 대조했다. 사고를 다시 발생시키거나 전체 복원 시험을 새로 한 것은 아니다.
• 주요 근거: Cloudways 복구 조건 · WordPress 백업 · Google 호스팅 이전 안내
• 자료 기준일: 복구·이전 공식 문서는 2026-09-07, 가격 자료는 2026-08-28 기록이다.
• 정정 내용: 중단 시간을 ‘2~3일’로 확정한 표현, 원고 사본만으로 전체 데이터를 복원했다는 설명, SEO 영향과 작업 시간의 단정을 바로잡았다.