[홈](https://servhidden.com/ko) /
[프라이버시 호스팅 가이드](https://servhidden.com/ko/guides) /
웹사이트를 다운타임 없이 역외 호스팅으로 이전하는 방법






운영


# 다운타임 없이 역외 호스팅으로 이전하기



고통스러운 마이그레이션은 거의 예외 없이 기술 문제가 아니라 순서 문제에서 비롯됩니다 — 이틀 전이 아니라 당일 밤에야 낮춘 TTL, DNS 변경 후에야 발급한 인증서, 더 이상 정본이 아닌 서버 위에 여전히 무장된 채 남은 cron 작업 같은 것들입니다. 이 글은 다운타임 구간을 완전히 없애는 순서와, 일반적인 가이드가 빼먹는 부분 — 이전이 당신에 대해 영구히 남기는 기록은 무엇이고, 그래도 여전히 할 수 있는 일은 무엇인지 — 까지 다룹니다.


[Read the 가이드](#guide-body)
[FAQ](#guide-faq)






## 이 페이지에서




- [가이드](#guide-body)

- [FAQ](#guide-faq)

- [관련 가이드](#guide-related)

- [추천 페이지](#guide-cta)






KYC 없음
암호화폐 결제 전용
로그 없음
DMCA 무시
전체 root 권한
NVMe SSD





20분 읽기
Aug 2026 업데이트

이 페이지에서

[01"무중단"이 실제로 의미하는 것](#무중단이-실제로-의미하는-것)
[02이전 예정일 며칠 전에 DNS TTL부터 낮춰라](#이전-예정일-며칠-전에-dns-ttl부터-낮춰라)
[03기억이 아니라 실제로 옮길 것의 목록을 만들어라](#기억이-아니라-실제로-옮길-것의-목록을-만들어라)
[04새 서버부터 만들고, 무언가를 담기 전에 먼저 하드닝하라](#새-서버부터-만들고-무언가를-담기-전에-먼저-하드닝하라)
[05데이터는 두 번 복사한다: 느린 1차, 빠른 2차](#데이터는-두-번-복사한다-느린-1차-빠른-2차)
[06DNS가 존재를 알기 전에 새 서버부터 테스트하라](#dns가-존재를-알기-전에-새-서버부터-테스트하라)
[07전환, 순서대로](#전환-순서대로)
[08마이그레이션이 남기고 가는 것](#마이그레이션이-남기고-가는-것)
[09도메인을 어떻게 할 것인가: 그대로 가져갈까, 새로 시작할까?](#도메인을-어떻게-할-것인가-그대로-가져갈까-새로-시작할까)
[10예전 호스트를 제대로 폐기하라](#예전-호스트를-제대로-폐기하라)
[11전체 순서를 한 페이지에](#전체-순서를-한-페이지에)
[FAQ자주 묻는 질문](#guide-faq)
[→추천 페이지](#guide-cta)







재미로 라이브 사이트를 옮기는 사람은 없다. 옮기게 되는 이유는 대개 이렇다. 지금 쓰는 호스트가 갑자기 여권 사진을 요구하거나, 24시간 시한이 붙은 신고 메일을 그대로 전달하거나, 데이터센터가 있는 나라가 더 이상 데이터를 맡길 만한 곳으로 보이지 않게 되었기 때문이다. 무엇이 등을 떠밀었든 위험한 부분은 이전 그 자체다. 사이트가 먹통이 될 수 있는 유일한 순간이자, 부주의한 한 걸음이 벗어나려던 그 신원을 새 서버에 그대로 못박아 버릴 수 있는 유일한 순간이기 때문이다.

두 위험 모두 같은 처방으로 해결된다. 도구가 아니라 순서다. 순서를 제대로 지킨 마이그레이션에는 사이트가 응답하지 않는 구간이 아예 없다. 두 서버가 동시에 살아 있고 DNS는 가장 마지막에 옮기기 때문이다. 순서를 그르친 마이그레이션은 장애와 흔적을 한꺼번에 남긴다. 지금부터 다루는 것이 바로 그 순서이며, 흔한 대형 공급자 사이를 오가는 경우가 아니라 KYC 없는 역외 호스트로 옮기는 사람을 염두에 두고 썼다 — 절차 자체는 같지만 그 뒤에 남는 뒷정리는 전혀 다르다.

## "무중단"이 실제로 의미하는 것

이 표현은 느슨하게 쓰이며, 사람들이 다치는 지점도 바로 그 느슨함이다. 두 대의 머신에서 동시에 HTTP를 서비스하는 것은 쉽다. 두 머신이 동시에 서비스하는 동안 *상태*를 일관되게 유지하는 것이 어려운 부분이며, 데이터를 잃는 유일한 부분이기도 하다. 그러니 무엇을 계획하기 전에 지금 자신이 실제로 다루는 대상이 이 둘 중 무엇인지부터 정하라. 그 답이 그날 밤 전체의 모양을 결정하기 때문이다.

| 옮기는 대상 | 실제로 발목을 잡는 것 | 계획이 담아야 할 것 |
| --- | --- | --- |
| 정적 사이트, 브로셔형 사이트, 생성된 출력물 | 없다. 나눌 상태 자체가 없다 | 복사하고 검증한 뒤 전환한다. 말 그대로 무중단 |
| 데이터베이스를 쓰는 CMS — WordPress, Ghost, 포럼 | 댓글, 로그인, 게시물이 동시에 두 데이터베이스에 나뉘어 쌓이는 것 | 가장 한산한 시간대에 **분 단위**로 끝나는 읽기 전용 동결 |
| 쇼핑몰, 또는 주문을 받는 모든 것 | 스플릿 브레인이 결제된 주문을 소리 없이 잃어버리는 것 | 짧은 전환 창을 잡아라. 대사 작업보다 훨씬 싸게 먹힌다 |
| cron 작업이나 백그라운드 워커가 있는 모든 것 | 같은 작업이 두 서버에서 동시에 실행되는 것 — 메일도 두 번, 결제도 두 번 | 새 호스트가 시작되기 *전에* 예전 호스트의 일정을 꺼 둔다 |
| 같은 도메인의 메일 | MX 레코드는 A 레코드와 무관하게 자기만의 시계로 캐시에서 만료된다 | 메일은 별도의 밤에 옮기고, 예전 MX가 일주일간 계속 수신하게 둔다 |

공짜인 것은 첫 번째 행뿐이라는 점에 주목하라. 그 외에는 모두 "무중단"이 "아무도 티켓을 올리지 않을 만큼 짧은 쓰기 동결"을 의미할 뿐이다. 새벽 4시의 읽기 전용 2분은 오차 범위지만, 두 데이터베이스에 걸친 두 시간짜리 쓰기 분열은 주말을 통째로 잡아먹는 대사 작업이다. 동결 구간을 선택하라.

두 서버가 동시에 돌아가고 DNS가 가장 마지막에 움직입니다 — 순서를 제대로 지킨 전환에 다운타임 구간이 아예 없는 이유입니다.

## 이전 예정일 며칠 전에 DNS TTL부터 낮춰라

선행 시간이 필요한 단계는 이것 하나뿐이다. 그래서 가장 먼저 나오고, 그래서 사람들이 가장 많이 건너뛴다. TTL — 즉 생존 시간(time to live) — 은 인터넷의 모든 리졸버에게 다시 묻기 전까지 레코드를 얼마나 캐시해도 되는지 알려주는 값이다. A 레코드의 TTL이 86400이라면, 한 시간 전에 조회한 리졸버는 등록기관에서 무엇을 바꾸든 상관없이 앞으로 23시간 더 예전 IP를 계속 내려준다.

결정적인 함정은 TTL을 낮추는 행위 자체도 기존 TTL의 지배를 받는다는 점이다. 리졸버는 캐시해 둔 예전 값이 만료되어야만 새로 짧아진 값을 알게 된다. 그러므로 TTL을 300초로 낮추는 시점은 **전환 최소 한 번의 기존 TTL 주기 이전**이어야 한다 — 하루짜리 TTL이었다면 24~48시간 전에 미리 낮춰야 한다는 뜻이다. 그러면 변경 후 5분 안에 전 세계가 새 레코드로 수렴하고, 전환은 더 이상 마음 졸이는 사건이 아니게 된다.

이전 후 며칠이 지나면 TTL을 다시 합리적인 값으로 올려 두라. 300초짜리 TTL은 도구로는 훌륭하지만 영구 설정으로는 나쁘다. 쿼리량을 몇 배로 늘리고, DNS 공급자를 훨씬 더 날카로운 단일 장애점으로 만들어 버린다.

## 기억이 아니라 실제로 옮길 것의 목록을 만들어라

실패한 마이그레이션의 사후 분석은 늘 똑같다. 아무도 목록에 적지 않은 무언가가 복사되지 않았다는 것이다. 웹 루트와 데이터베이스는 누구나 기억하는 두 가지이고, 아래 목록은 그 나머지다. 기억에 의존하지 말고 말 그대로 하나씩 짚어 볼 가치가 있다.

- **예약 작업.** 모든 사용자에 대해 crontab -l을 확인하고, systemd 타이머도 함께 본다. 갱신 훅과 야간 작업이 여기 숨어 있다.

- **서비스 정의.** 직접 작성한 systemd 유닛, 웹 서버 vhost, PHP-FPM 풀, supervisor 설정 전반.

- **시크릿과 환경 변수.** .env 파일, API 키, 데이터베이스 비밀번호, 애플리케이션 salt — 이들은 그냥 복사만 할 것이 아니라 교체해야 한다는 점도 기억하라.

- **TLS 자료.** 인증서, 그리고 그보다 더 중요한 ACME 계정과 갱신 설정.

- **메일 신원.** DKIM 개인 키, SPF와 DMARC 레코드. 여기서 어긋나면 요란하게 깨지지 않는다. 그저 조용히 메일이 스팸함으로 향할 뿐이다.

- **업로드된 미디어.** 흔히 웹 루트 바깥에 있고, 흔히 가진 것 중 가장 용량이 크다.

- **당신의 IP를 신뢰하는 외부의 모든 것.** 결제 게이트웨이 허용 목록, 웹훅 수신지, 데이터베이스 방화벽, IP 제한이 걸린 서드파티 API. 새벽 3시에 "사이트는 되는데 결제만 안 된다"는 사태의 원인 1순위다.

- **패키지 목록.** dpkg --get-selections 또는 그에 준하는 명령으로, 새 서버가 "거의 같은" 확장 모듈과 라이브러리가 아니라 "완전히 같은" 것을 갖추게 한다.

복사를 시작하기 전에 이 목록부터 적어 두라. 이 목록은 나중에 테스트 계획이 되기도 한다 — 목록의 각 줄은 DNS가 새 서버의 존재를 알기 전에 그 서버에서 반드시 확인해야 할 항목이다.

## 새 서버부터 만들고, 무언가를 담기 전에 먼저 하드닝하라

목적지 서버는 일찍 주문해서 하루 이틀 정도는 빈 채로 그냥 돌아가게 두라. 겹치는 기간에 드는 비용은 사실상 없고 — 작은 역외 VPS는 한 달에 몇 달러면 된다 — 동결된 데이터베이스가 기다리는 시간 압박 속에서 서버를 구축하지 않아도 된다는 가치는 상당히 크다.

예전 환경을 의도적으로 맞춰라. 같은 배포판과 메이저 버전, 같은 PHP나 Node나 Python의 메이저 버전, 같은 데이터베이스 메이저 버전. 이 김에 현대화하고 싶은 유혹은 상당히 크지만 철저히 뿌리쳐야 한다. 전환 후 사이트가 망가진다면 바뀐 변수가 딱 하나이기를 바랄 것이다. 스택 업그레이드는 2주쯤 뒤, 롤백이 가능한 상태로, 아무 일 없는 어느 오후에 하라.

아직 비어 있을 때 하드닝하라. 키 전용 SSH, 기본 거부 방화벽, 자동 보안 업데이트 — [첫 시간 하드닝 체크리스트](https://servhidden.com/ko/guides/first-hour-vps-hardening-checklist)가 정확히 이 목록이며, 아무것도 없는 서버에 적용하는 편이 훨씬 쉽다. 데이터가 관할권을 옮길 만큼 민감하다면, [저장 데이터 암호화](https://servhidden.com/ko/guides/full-disk-encryption-on-a-vps)를 결정하기에도 바로 지금이 적기다. 나중에 손보려면 또 한 번의 마이그레이션이 필요해지기 때문이다.

## 데이터는 두 번 복사한다: 느린 1차, 빠른 2차

직관적으로는 모든 것을 전환 창 안에서 복사하고 싶어진다. 반대로 하라. 예전 사이트가 아무 문제 없이 트래픽을 처리하는 동안 며칠 전에 전체 복사를 한 번 돌리고, 전환 시점에는 바뀐 것만 옮기는 2차 복사를 돌려라. 1차 복사는 여섯 시간이 걸려도 아무도 눈치채지 못한다. 2차는 90초면 끝나며, 그것이 곧 당신의 다운타임 예산 전부다.

파일은 rsync -aHAX --numeric-ids가 권한, 소유권, 하드링크, 확장 속성을 그대로 보존한다. --numeric-ids 플래그가 중요한 이유는 새로 구축한 두 머신 사이에서 UID가 일치하는 경우가 드물기 때문이다. 이 명령을 미리 한 번 돌리고, 전환 직전에 같은 인자로 다시 한 번 돌려라 — 두 번째 실행은 델타만 전송한다.

데이터베이스도 같은 2단계 처리가 필요하지만 도구는 다르다. mysqldump --single-transaction이나 pg_dump를 쓰면 구축과 테스트의 기준이 될 일관된 초기 스냅숏을 얻는다. 전환 시점에는 짧은 쓰기 동결 동안 두 번째 덤프를 뜨거나 — 짧은 동결조차 부담스러운 큰 데이터베이스라면 — 며칠 전에 미리 새 서버를 예전 서버의 복제본으로 세팅해 따라잡게 한 뒤 승격시키는 방법도 있다. 복제를 쓰면 동결 시간이 초 단위로 줄어든다. 다만 두 시간짜리 마이그레이션이 이틀짜리 프로젝트로 늘어나기도 하니, 규모가 정말로 그것을 요구할 때만 쓰라.

**Push가 아니라 Pull로, 그리고 절대 노트북을 거치지 마라.** 복사는 새 서버 쪽에서 시작해서 전송이 데이터센터 속도로 호스트 대 호스트로 이뤄지게 하라. 기가바이트 단위 데이터를 집 회선으로 우회시키면 느릴 뿐 아니라, 당신의 자택 IP가 두 머신의 접속 로그에 모두 남는다 — 프라이버시 때문에 마이그레이션을 하는 목적 자체를 정면으로 거스르는 흔적이다. 예전 호스트가 새 IP를 알게 되는 것조차 용납할 수 없다면 아예 직접 복사하지 마라. 대신 자신의 [오프사이트 암호화 백업](https://servhidden.com/ko/guides/vps-backup-strategy)에서 새 서버를 복원하면 두 머신은 서로 한 번도 통신하지 않는다.

## DNS가 존재를 알기 전에 새 서버부터 테스트하라

공개 레코드를 단 하나도 바꾸지 않고도 새 IP에서 실제 호스트네임을 서비스해 볼 수 있으며, 반드시 그렇게 해야 한다 — 이것이 전환을 아무 사건 없이 끝내는 비결이다. 로컬 /etc/hosts에 도메인을 새 IP로 가리키는 줄을 추가하거나, 그마저 생략하고 요청 하나만 curl이 대신 처리하게 하라.

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

이제 목록을 하나씩 짚어 가라. 첫 페이지와 하위 페이지 세 곳을 열어 본다. 로그인한다. 폼을 제출한다. 파일을 업로드한다. 데이터베이스 연결이 새 로컬 연결이지 인터넷 너머 예전 호스트를 여전히 가리키고 있지는 않은지 확인한다 — 이 실수는 예전 서버를 해지하는 순간까지 완벽하게 작동해 버린다. cron 작업을 손으로 직접 실행해 출력을 읽는다. 리다이렉트를 확인하고, 존재하지 않는 URL이 200이 아니라 여전히 404를 반환하는지 확인한다.

TLS 인증서는 전환 후가 아니라 지금, 전환 전에 발급하라. DNS-01 챌린지를 쓰면 TXT 레코드로 도메인 소유를 증명하므로 A 레코드가 아직 예전 서버를 가리키는 동안에도 발급이 된다. DNS 변경 후에 HTTP-01 검증을 기다리면 그 공백 동안 초기 방문자 전원이 인증서 경고를 보게 된다 — 지키려던 바로 그 전환 창 안에서 스스로 만든 장애다.

## 전환, 순서대로

여기까지 왔다면 새 서버는 이미 구축되고, 하드닝되고, 데이터가 채워지고, 실제 호스트네임으로 테스트를 마쳤으며, 유효한 인증서까지 갖고 있다. 전환 자체는 이제 짧고 지루한 목록일 뿐이며, 그것이 목표다.

- 사이트에 의존하는 다른 사람이 있다면 전환 창을 미리 공지한 뒤, 예전 사이트를 읽기 전용이나 유지보수 모드로 전환한다.

- **예전 호스트의 cron과 백그라운드 워커를 끈다.** 새 호스트에서 그것들을 시작하기 전에 반드시 먼저 해야 하며, 절대 나중이어서는 안 된다.

- 마지막 rsync 델타 패스와 마지막 데이터베이스 덤프를 실행하고, 그것을 임포트한다.

- 새 서버에서 애플리케이션을 시작하고, 최종 데이터를 대상으로 --resolve를 통해 스모크 테스트를 다시 돌린다.

- A와 AAAA 레코드를 새 IP로 바꾼다. TTL이 300초라면 5분 안에 전 세계가 따라온다.

- 새 호스트에서 cron과 워커를 켠다.

- 두 접속 로그를 나란히 지켜본다. 트래픽이 예전 서버에서 빠져나가 새 서버에 나타나며, 예전 서버가 조용해지면 전환이 끝난 것이다.

- 예전 서버는 일주일 동안 그대로 켜 두고 서비스하게 두고 건드리지 않는다. 그것이 곧 당신의 롤백이다.

사람들이 가장 많이 생략하는 것이 여덟 번째 단계이며, 목록 전체를 통틀어 가장 값싼 보험이기도 하다. 단돈 몇 달러로 DNS를 다시 되돌릴 수 있는 능력 — 5분이면 끝나는 복구 — 을 확신이 설 때까지 계속 쥐고 있을 수 있다.

## 마이그레이션이 남기고 가는 것

여기부터는 흔한 마이그레이션 가이드가 빼먹는 부분이며, 가격이 아니라 프라이버시 때문에 옮긴 경우라면 가장 중요한 부분이다. 사이트를 옮긴다고 그 이력이 지워지지는 않는다. 예전 구성에 대한 여러 공개·반공개 기록이 이전 후에도 영구히 남으며, 그것이 무엇인지 아는 것이 진짜 단절과 단절했다는 착각의 차이를 만든다.

| 무엇이 이전을 기록하는가 | 누가 그것을 볼 수 있는가 | 실제로 할 수 있는 일 |
| --- | --- | --- |
| 패시브 DNS — 과거 A 레코드 이력 | 상용 이력 조회 서비스를 통해 누구나 | **아무것도 없다.** 예전 IP는 그 이름과 영구히 연결된 채로 남는다. 실제로 공개된 정보이니 그렇게 취급하고 계획하라 |
| Certificate Transparency 로그 | 누구나, 영구히, 도메인으로 검색 가능 | 지금까지 발급된 모든 인증서가 나열된다 — 잊고 있던, 내부용처럼 보이는 서브도메인까지도. 설명적인 이름 대신 와일드카드를 쓰는 편이 낫다 |
| 예전 호스트의 계정 기록 | 예전 호스트, 그리고 그들에게 강제할 수 있는 누구든 | 카드 정보, 가입 이메일, 로그인 IP. KYC 없는 목적지는 미래를 지켜줄 뿐 과거는 지켜주지 못한다 |
| WHOIS 이력 | 상용 WHOIS 이력 아카이브 | 도메인이 한 번이라도 실제 정보로 등록된 적이 있다면 그 스냅숏은 이미 저장되어 있다. 나중에 프라이버시를 적용해도 그것을 되돌리지는 못한다 |
| 애널리틱스와 광고 식별자 | 공급업체, 그리고 페이지 소스를 읽는 누구든 | 같은 추적 ID를 그대로 가져가면 두 사이트가 결정적으로 연결된다. 새 ID를 발급하거나 아예 없애라 |
| 예전 디스크에 남은 덤프와 백업 | 그 스토리지를 다음에 할당받는 누구든 | 해지하기 전에 삭제하고 덮어써라. 공유 스토리지에서는 삭제가 보장이 아니라 힌트에 불과하다고 가정하라 |
| 발송한 메일의 Received: 헤더 | 모든 수신자, 영구히 | 소급되는 것은 없다. 이전 후에 보낸 메일만 새 경로를 담는다 |
| 복사 중 당신 자신의 접속 | 당신의 ISP, 그리고 두 호스트의 접속 로그 | 이것만은 전적으로 당신 손에 달려 있다. 당신을 특정할 수 있는 IP로는 어느 쪽 머신도 절대 건드리지 마라 |

정직하게 요약하면, 마이그레이션은 과거를 다시 쓸 수 없다 — 더 이상 보태지 않게 막을 수 있을 뿐이다. 그것만으로도 상당한 가치가 있지만, 이는 결정 자체를 바꿔 놓는다. 만약 위협 모델상 어떤 관찰자도 새 사이트와 예전 사이트를 연결할 수 없어야 한다면, 같은 도메인을 새 호스트로 옮기는 것만으로는 그것을 이룰 수 없으며, 전환 중에 아무리 조심해도 마찬가지다. 그런 경우라면 새 이름과 완전히 새로운 시작이 필요하며, 이는 다음 절에서 다룬다. 반대로 목표가 오늘 이후로 신원을 드러내는 기록을 더 만들지 않는 것, 그리고 법적 소재지를 스스로 고른 관할권으로 옮기는 것이라면, 이 이전은 정확히 그 목표를 달성한다. 이후에도 깨끗한 상태를 유지하는 습관은 [서버 OpSec 가이드](https://servhidden.com/ko/guides/server-opsec-staying-anonymous)에서 다룬다.

## 도메인을 어떻게 할 것인가: 그대로 가져갈까, 새로 시작할까?

사이트와 도메인은 서로 독립적인 결정이지만, 둘을 하나로 뭉뚱그리는 경우가 흔하다. 호스팅은 오늘 옮기고 등록기관은 영원히 그대로 둘 수 있다. 서버를 바꾼다고 해서 도메인을 건드려야 할 이유는 전혀 없다. *그래야 하는지* 여부는 전적으로 그 도메인이 이미 당신에 대해 무엇을 알고 있는지에 달려 있다.

- **도메인은 유지하고 등록기관만 바꾼다.** 도메인에 가치가 있을 때 — 링크, 랭킹, 사람들이 직접 입력하는 이름 — 합리적인 선택이다. WHOIS 레코드의 이력이 아니라 미래만 바로잡으며, 모든 랭킹 신호를 그대로 유지한다. 대부분의 상업용 사이트에는 이것이 정답이다.

- **도메인은 그대로 두고 호스트만 바꾼다.** 익명성이 아니라 관할권, 가동률, DMCA 대응 방침 때문에 옮기는 경우라면 더할 나위 없이 합리적이다. 가장 단순한 이전이며 SEO 위험도 전혀 없다.

- **새 도메인을 쓰고 예전 도메인은 리다이렉트한다.** 랭킹은 보존되지만, 두 이름을 공개적으로 그리고 영구히 연결해 버린다. 연속성을 위해서는 선택할 수 있어도 프라이버시를 위해서는 절대 선택하지 마라 — 리다이렉트 자체가 곧 연결 고리다.

- **새 도메인으로 완전히 단절한다.** 연결 고리를 진짜로 끊어내는 유일한 선택지이지만, 그동안 쌓은 모든 랭킹과 인바운드 링크를 대가로 치른다. 처음부터 비공개로 등록하라. 도메인의 익명성은 딱 최초 등록만큼만 보장되기 때문이다. [암호화폐로 익명 도메인 등록하기](https://servhidden.com/ko/guides/anonymous-domain-registration-with-crypto) 가이드에서 이를 제대로 하는 방법을 다룬다.

신중하게 고르되, 전환 도중이 아니라 전환 전에 결정하라. DNS를 옮긴 뒤에 도메인에 대한 마음을 바꾸면 가장 까다로운 부분을 두 번 해야 한다.

## 예전 호스트를 제대로 폐기하라

전환 후 한두 주가 지나 새 서버의 로그는 지루해지고 예전 서버의 로그는 텅 비면, 예전 계정을 정리할 때가 된 것이다. 반드시 이 순서대로 하라. 곧바로 해지 버튼부터 누르고 싶은 유혹이 바로 당신의 데이터를 남의 디스크 위에 그대로 남겨 두는 지름길이기 때문이다.

- 아직도 예전 IP를 가리키는 것이 없는지 확인한다. 서드파티 웹훅, 허용 목록, 모니터링에 하드코딩된 주소가 없는지, 그리고 mail이나 cpanel 같은 서브도메인처럼 깜빡 잊고 남겨 둔 DNS 레코드가 없는지 점검한다.

- 그 머신에 있었던 모든 시크릿을 교체한다 — 데이터베이스 비밀번호, API 키, 애플리케이션 salt, DKIM 키, SSH 키. 이것들을 그대로 가져오지 마라.

- 예전 서버에서 자신의 SSH 공개 키와 모든 지원 접근 권한을 제거한다.

- 애플리케이션과 덤프, 백업을 삭제한 뒤 여유 공간을 덮어써서, 재활용된 볼륨을 대충 읽어도 아무것도 나오지 않게 한다.

- 그런 다음에야 비로소 서비스를 해지하고, 예전 계정에 저장된 결제 수단을 모두 제거한다.

**더 이상 통제하지 못하는 하드웨어에 있었던 모든 것은 정의상 이미 침해된 것이다.** 예전 호스트가 악의적이어서가 아니라, 그 디스크가 다시 풀에 반환되고 나면 무엇이 와이프를 뚫고 살아남았는지 결코 알 수 없기 때문이다. 데이터베이스 비밀번호를 교체하는 데는 2분이면 충분하다. 폐기한 서버에서 나온 키가 몇 달 뒤에도 여전히 무언가를 열 수 있다는 사실을 뒤늦게 알게 되는 데는 훨씬 오랜 시간이 걸린다.

## 전체 순서를 한 페이지에

이유를 다 걷어내면 호스트 마이그레이션은 아홉 단계로 줄어들며, 그중 시급한 것은 단 두 가지뿐이다.

- **이틀 전:** DNS TTL을 300초로 낮춘다.

- **이틀 전:** 목적지 서버를 주문하고 하드닝하며, 예전 스택과 버전을 하나하나 맞춘다.

- **며칠 전:** 목록을 작성한다 — cron, 시크릿, TLS, 메일 키, 미디어, IP 허용 목록, 패키지.

- **며칠 전:** 호스트 간 첫 전체 데이터 복사를 실행한다.

- **전환 창 전:** DNS-01로 인증서를 발급하고 --resolve로 모든 것을 테스트한다.

- **전환 창(분 단위):** 쓰기를 동결하고, 예전 cron을 끄고, 델타 복사와 마지막 덤프를 실행한 뒤 새 앱을 시작한다.

- **전환 창(초 단위):** A 레코드를 바꾸고, 새 호스트에서 cron을 켠다.

- **그다음 한 주:** 예전 서버를 롤백용으로 계속 살려 두고, 두 로그 파일을 함께 지켜본 뒤 TTL을 다시 올린다.

- **그 이후:** 시크릿을 교체하고, 지우고, 해지한다 — 그리고 이 이전으로도 지울 수 없었던 것이 무엇인지 기억해 둔다.

이 목록에서 어려운 것은 하나도 없다. 아프게 되는 단계는 모두 순서를 어긴 단계다 — 당일 밤에야 낮춘 TTL, DNS 변경 후에야 발급한 인증서, 더 이상 정본이 아닌 머신 위에 여전히 무장된 채 남은 cron 작업. 순서만 제대로 지키면 마이그레이션에서 흥미로운 부분은 이전 그 자체가 아니라 서버를 어디에 둘지 고르는 일이 된다. 아직 정하지 못했다면 [관할권 가이드](https://servhidden.com/ko/guides/choosing-an-offshore-jurisdiction)에서 시작하라.





FAQ

## 호스트 마이그레이션 — 자주 묻는 질문





### 01
실제로 다운타임은 얼마나 예상해야 하나요?



정적 사이트라면 전혀 없습니다 — 두 서버가 동시에 같은 콘텐츠를 서비스할 수 있으므로 DNS 변경 자체가 눈에 띄지 않습니다. 데이터베이스가 있는 경우 다운타임은 정확히 쓰기 동결 시간만큼이며, 사전에 전체 데이터 복사를 이미 마쳤다면 보통 2~10분입니다. 중요한 수치는 DNS가 얼마나 빨리 퍼지느냐가 아니라 전환 창 동안 얼마나 많은 데이터를 복사하느냐입니다. 며칠 전에 미리 거의 모든 것을 복사해 두면 전환 창은 델타 크기만큼으로 줄어듭니다.





### 02
DNS 전파는 얼마나 걸리나요?



"전파"라는 현상 자체가 없습니다 — 그 단어는 실제로는 일어나지 않는 일을 가리킬 뿐입니다. 리졸버는 그저 TTL이 정한 시간만큼 레코드를 캐시했다가 만료되면 다시 물어봅니다. 적용 중이던 TTL이 86400이었다면 일부 리졸버는 앞으로 24시간 더 예전 IP를 내려줄 수 있습니다. 전환 최소 한 번의 기존 TTL 주기 전에 TTL을 300초로 낮춰 두면 인터넷 전체가 5분 안에 변경 사항을 따라옵니다.





### 03
도메인도 함께 옮겨야 하나요?



아닙니다. 등록기관과 호스트는 완전히 별개이며, 도메인은 그대로 둔 채 사이트만 옮겨도 아무 문제 없이 작동합니다. 옮겨야 하는지는 마이그레이션 이유에 달려 있습니다. 관할권, 가격, DMCA 대응 방침 때문이었다면 도메인은 그대로 두십시오. 익명성 때문이었다면 도메인이 그 자체로 별도의 이력을 갖고 있다는 점을 기억하십시오 — WHOIS 아카이브는 최초 등록 당시의 정보를 그대로 보관하며, 호스팅 변경은 그것을 건드리지 못합니다.





### 04
예전 호스트가 제가 어디로 갔는지 모르게 마이그레이션할 수 있나요?



두 머신 사이를 직접 복사한다면 불가능합니다 — 한쪽이 다른 쪽에 접속하는 순간 양쪽 접속 로그 모두에 그것이 기록됩니다. 그 연결 고리가 위협 모델상 정말로 중요하다면 호스트 간 직접 복사를 아예 하지 마십시오. 대신 자신의 오프사이트 암호화 백업에서 새 서버를 복원하면 두 공급자는 패킷 하나 주고받지 않습니다. 어느 쪽이든, 자신을 특정할 수 있는 연결로는 절대 전송을 시작하지 말고, 예전 공급자에게 여는 지원 티켓에 목적지 정보를 남기지 마십시오.





### 05
OS나 스택 업그레이드도 같은 시점에 해야 하나요?



아니요, 그것이야말로 가장 흔한 자초형 마이그레이션 실패입니다. 한 번에 하나만 바꾸십시오. 전환 후 사이트가 이상하게 작동한다면 원인 후보가 새 머신, 새 PHP 버전, 새 데이터베이스 메이저 버전 중 무엇인지 고민하는 것이 아니라 단 하나의 설명만 있기를 바랄 것입니다. 예전 환경과 버전을 하나하나 맞춰 이전을 마치고, 일주일간 깨끗한 로그를 확인한 뒤, 롤백이 가능한 상태로 별도로 업그레이드하십시오.





### 06
마이그레이션을 하면 검색 순위가 떨어지나요?



도메인, URL, 콘텐츠가 그대로 유지된다면 의미 있는 순위 하락은 없습니다 — 구글은 IP 주소가 아니라 URL을 인덱싱하며, 호스트 변경 자체는 랭킹 신호가 아닙니다. URL 구조를 동일하게 유지하고, 같은 상태 코드를 반환하며, 이전과 리디자인이나 URL 체계 변경을 함께 진행하지 마십시오. 대신 새 도메인으로 옮기는 경우라면 301 리다이렉트를 올바르게 설정해도 일시적인 순위 하락은 각오해야 하며, 그 리다이렉트 자체가 두 이름을 공개적으로 연결한다는 점도 알아 두어야 합니다.





### 07
TLS 인증서도 새로 발급해야 하나요?



예 — 새 서버는 자신만의 인증서와 개인 키가 있어야 하며, 예전 키를 그대로 가져오는 것은 기술적으로 작동하더라도 나쁜 습관입니다. 전환 전에 DNS-01 챌린지로 발급하십시오. TXT 레코드로 검증하므로 A 레코드가 아직 예전 호스트를 가리키는 동안에도 성공합니다. DNS 변경 후에 HTTP-01을 기다리면 지키려던 바로 그 구간에서 인증서 경고가 이어지는 것이 사실상 확정됩니다.





### 08
예전 서버는 언제 해지해도 안전한가요?



예전 머신의 로그가 조용해지고 새 머신의 로그가 깨끗한 상태로 한두 주가 지난 뒤입니다 — 그 지연 시간이 곧 당신의 롤백이며, 비용은 몇 달러에 불과합니다. 해지하기 전에 외부의 무언가가 여전히 예전 IP를 가리키고 있지 않은지 확인하고, 그 위에 있었던 모든 시크릿을 교체한 뒤 데이터를 삭제하고 여유 공간을 덮어쓰십시오. 해지는 가장 마지막입니다. 해지부터 먼저 눌러 버리면 더 이상 통제하지 못하는 디스크 위에 데이터베이스를 남겨 두게 됩니다.




관련 가이드

## 계속 읽기


[### 2026년 오프쇼어 호스팅 관할권 선택 방법

구매


오프쇼어 관할권 선택을 위한 실용적인 의사결정 프레임워크: 데이터 보존법, MLAT 노출, DMCA 입장, 법원 처리 속도, 실제 집행 현황 — 국가별로 살펴봅니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/choosing-an-offshore-jurisdiction)
[### 프라이버시가 중요한 워크로드를 위한 VPS vs 전용 서버

구매


언제 VPS로 충분한지, 언제 shared tenancy가 liability가 되는지, 언제 bare metal만이 정직한 답인지 설명합니다. Hardware isolation, hypervisor risk, 그리고 cost vs threat model을 다룹니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/vps-vs-dedicated-for-privacy)
[### KYC 없는 VPS에서의 자체 호스팅 VPN: WireGuard vs OpenVPN

운영


자체 호스팅 VPN이 상용 제공업체보다 나은 이유와, 2026년 프라이버시·성능·운영 위험 측면에서 WireGuard와 OpenVPN이 실제로 어떻게 비교되는지 알아봅니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### AI 추론을 위한 RTX 4090 vs H100 SXM5 (RTX 5090은 어디에 적합할까)

구매


구매 가이드: 2026년 자체 호스팅 LLM, 이미지, 영상, 음성, 파인튜닝 워크로드에 어떤 NVIDIA GPU를 쓸지. RTX 4090 vs RTX 5090 vs H100 SXM5 vs 듀얼 H100 — VRAM, 처리량, $/토큰, 각각이 유리한 경우.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/rtx-4090-vs-h100-for-ai-inference)
[### MT4 / MT5 / cTrader Forex 트레이딩을 위한 오프쇼어 Windows RDP

운영


완벽 가이드: Forex 트레이딩에 Windows RDP를 쓰는 이유, 저지연 오프쇼어 관할권 선택 방법, MT4 / MT5 / cTrader / Expert Advisor 설정, 브로커 서버까지의 지연 시간, 그리고 KYC 없는 결제 경로.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/offshore-windows-rdp-for-forex-trading)
[### DMCA 무시 호스팅 해설: 2026년 현재 실제 의미

구매


"DMCA 무시" 호스팅이 실제로 제공하는 것, 이를 진정으로 뒷받침하는 관할권, 이를 필요로 하는 워크로드, 그리고 이 용어가 커버하지 않는 저작권 함정.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/dmca-ignored-hosting-explained)
[### 크립토로 익명 도메인 등록: 2026년 WHOIS 프라이버시

프라이버시


신원 노출 없는 도메인 등록을 위한 2026년 실용 가이드: TLD별 WHOIS 체계, 레지스트라 선택, 크립토 결제 옵션, 그리고 어쨌든 신원을 노출시키는 운영상 실수들.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/anonymous-domain-registration-with-crypto)
[### 호스팅을 위한 암호화폐 결제: Monero vs Bitcoin vs USDT

프라이버시


결제 코인이 호스트가 여러분에 대해 알게 되는 것에 어떤 영향을 미치는지. XMR, BTC, USDT의 프라이버시, 수수료, 최종성, 체인 분석 노출 — 명확한 추천과 함께.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### 오프쇼어 호스팅은 정말 익명입니까? 솔직한 답변

프라이버시


오프쇼어, No-KYC 호스팅은 일반 호스팅업체가 수집하는 신원 정보를 제거합니다. 하지만 "익명성"은 결제 방식과 제공업체의 로그 정책, 그리고 사용자 자신의 운영 보안(opsec)에 따라 달라집니다. 실제로 무엇이 추적 가능한지 알려드립니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/is-offshore-hosting-truly-anonymous)
[### VPS 보안 강화 첫 1시간: 체크리스트

운영


새 VPS를 한 시간 이내에 안전하게 만드는 구체적이고 순서화된 체크리스트입니다: SSH 키, 방화벽, fail2ban, 자동 업데이트, 그리고 대부분의 기회주의적 공격을 막는 공격 표면 축소까지 다룹니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/first-hour-vps-hardening-checklist)
[### KYC 없는 호스팅이란? 정의, 합법성 및 작동 방식

프라이버시


KYC 없는 호스팅은 신원 확인 없이 서버를 임대할 수 있는 서비스입니다. 이름, 이메일, 신분증이 전혀 필요하지 않습니다. 이 서비스가 무엇인지, 어떻게 작동하는지, 합법성은 어떤지, 그리고 진정한 KYC 없는 공급자를 어떻게 선택하는지 상세히 설명합니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/what-is-no-kyc-hosting)
[### 오프쇼어 호스팅은 합법인가? 2026년 솔직한 답변

구매


오프쇼어 호스팅은 합법입니다 — 이용자와 제공업체 모두에게 해당됩니다. 이 용어가 실제로 무엇을 의미하는지, 법적 경계가 어디에 있는지, 버려야 할 오해들, 그리고 책임감 있게 활용하는 방법을 설명합니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/is-offshore-hosting-legal)
[### Monero(XMR)로 호스팅 결제하는 방법 — 단계별 가이드

프라이버시


Monero(XMR)로 VPS 또는 전용 서버 비용을 결제하는 단계별 가이드: XMR이 가장 프라이버시 보호에 뛰어난 옵션인 이유, 구매 방법, 그리고 결제 절차 — 인보이스 발행부터 서버 가동까지.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/how-to-pay-for-hosting-with-monero)
[### 웹사이트를 익명으로 호스팅하는 방법 — 2026년 실전 가이드

프라이버시


신원을 전혀 남기지 않고 웹사이트를 호스팅하는 방법을 계층별로 설명하는 실전 가이드입니다. 계정, 결제, 도메인, 관할권, 접속 방식, 콘텐츠 — 각 계층을 빠짐없이 다룹니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/how-to-host-a-website-anonymously)
[### VPS에 WireGuard VPN 설정하는 방법 — 단계별 가이드

운영


WireGuard로 VPS에 나만의 프라이빗 VPN 구축하기: 직접 호스팅하는 VPN이 상용 VPN보다 나은 이유, 설치부터 클라이언트 연결까지의 전체 설정 과정, 그리고 보안 강화 방법.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### GPU 서버에 LLM 직접 운영하는 방법 — 2026년 가이드

운영


임대한 GPU 서버에서 나만의 대형 언어 모델을 운영하는 방법: API 대비 셀프 호스팅의 장점, GPU와 모델 선택 기준, Ollama 또는 vLLM을 이용한 설정 방법, 그리고 실제 비용까지.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/self-host-an-llm-on-a-gpu-server)
[### 불릿프루프 호스팅 vs 오프쇼어 호스팅 — 차이점은 무엇인가요?

구매


불릿프루프 호스팅과 오프쇼어 호스팅은 늘 혼동되지만, 둘은 같은 것이 아닙니다. 실제 차이점, 그것이 중요한 이유, 그리고 당신에게 실제로 필요한 것이 무엇인지 알아보세요.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/bulletproof-vs-offshore-hosting)
[### Bitcoin으로 VPS 구매하는 방법 — 단계별 안내 (2026)

구매


Bitcoin으로 VPS를 구매하는 방법을 초보자도 쉽게 따라할 수 있도록 안내합니다. BTC 마련, 플랜 선택, 청구서 결제, 그리고 카드 없이 익명으로 서버를 받는 전 과정을 다룹니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/how-to-buy-a-vps-with-bitcoin)
[### 2026년 DMCA 무시 호스팅에 최적화된 국가

구매


미국식 저작권 삭제 요청의 영향을 받지 않는 서버를 원한다면 — 실질적으로 통하는 국가들, DMCA 무시의 진정한 의미, 그리고 선택 방법을 알아보세요.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/best-countries-for-dmca-ignored-hosting)
[### Tor 히든 서비스(.onion 사이트) 호스팅 방법 — 2026년 가이드

운영


VPS에서 Tor 어니언 서비스를 설정하는 방법: 히든 서비스란 무엇인지, 왜 가장 강력한 익명 호스팅 형태인지, 전체 설정 과정, 그리고 실제로 익명성을 유지하는 방법을 안내합니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/how-to-host-a-tor-hidden-service)
[### 오프쇼어 메일 서버 설정 — 2026년 프라이빗 이메일 자체 호스팅

운영


오프쇼어 VPS에서 나만의 프라이빗 이메일 서버를 운영하세요: 이메일 자체 호스팅이 필요한 이유, 준비 사항, 올인원 메일 스택을 활용한 실용적인 설정 방법, 그리고 이메일 전달율을 높이는 방법까지 안내합니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/offshore-mail-server-setup)
[### 크립토 노드 호스팅 가이드 — VPS에서 블록체인 노드 운영하기

운영


서버에서 블록체인 노드를 호스팅하는 방법: 직접 노드를 운영해야 하는 이유, Bitcoin·Ethereum·Monero 등 각 체인별 서버 사양 산정, 설정 방법, 그리고 프라이버시를 유지하는 법.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/crypto-node-hosting-guide)
[### Stable Diffusion용 GPU 호스팅 — 나만의 이미지 서버 운영하기

운영


자체 GPU 서버에서 Stable Diffusion 실행하기: 이미지 생성을 직접 호스팅해야 하는 이유, 적합한 GPU 선택 방법, 웹 UI 설정, 그리고 호스팅 서비스와의 비용 비교.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/gpu-hosting-for-stable-diffusion)
[### 서버 OpSec — 서버를 운영하면서 익명성 유지하기

프라이버시


익명 서버를 운영하는 모든 이를 위한 작전 보안 가이드: 신원을 노출시키는 실수들, 이를 방지하는 습관들, 그리고 정체성을 진정으로 분리하는 방법.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/server-opsec-staying-anonymous)
[### 시드박스 설정 가이드 — 2026년 나만의 프라이빗 시드박스 구축하기

운영


서버에서 직접 시드박스를 구축하는 방법: 시드박스의 정의, 서버 사양 선정, 웹 UI가 있는 토런트 클라이언트 설치, 그리고 프라이버시 및 보안 유지.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/seedbox-setup-guide)
[### 자체 VPS로 DPI 검열 우회하기 (2026 가이드)

프라이버시


VPN이 갑자기 먹통이 됐나요? 자체 VPS로 DPI 검열을 우회하는 방법을 알아봅니다: 심층 패킷 검사(DPI)가 실제로 탐지하는 것, 2026년 기준 5가지 프로토콜 중 어떤 차단에 어떤 프로토콜이 효과적인지, 그리고 VLESS+REALITY 전체 설정 과정까지 다룹니다.


6개 자주 묻는 질문](https://servhidden.com/ko/guides/bypass-dpi-censorship-with-your-own-vps)
[### VPS 전체 디스크 암호화: LUKS 설정과 실제로 보호되는 것

운영


LUKS로 VPS를 암호화하는 방법을 다룹니다: 암호화된 데이터 볼륨, SSH 원격 잠금 해제를 사용한 전체 루트 암호화, 소형 서버에서 실제로 중요한 설정, 그리고 디스크 암호화가 실제로 무엇을 막아주는지에 대한 솔직한 설명까지 함께 다룹니다.


8개 자주 묻는 질문](https://servhidden.com/ko/guides/full-disk-encryption-on-a-vps)
[### 오리진 서버 IP 숨기기: CDN, 리버스 프록시, 그리고 여전히 새는 것들

프라이버시


오프쇼어 서버 앞에 CDN을 둘지 말지 판단하는 방법을 다룹니다: CDN이 실제로 무엇을 숨겨 주는지, 그 대가로 함께 떠안게 되는 신고 창구, 완벽하게 설정해도 오리진 IP가 그래도 새는 여섯 가지 경로, 그리고 여러분 자신의 서버를 직접 점검하는 방법까지 다룹니다.


8개 자주 묻는 질문](https://servhidden.com/ko/guides/hiding-your-origin-server-ip)
[### VPS 백업 전략: 암호화·오프사이트·복구 테스트

운영


호스트는 백업을 보관하지 않습니다. 서버를 파괴하는 진짜 원인과 restic·Borg 비교, 잊기 쉬운 키 관리, 복구 테스트까지 정리했습니다.


8개 자주 묻는 질문](https://servhidden.com/ko/guides/vps-backup-strategy)
[### Matrix 셀프호스팅: 연합과 메타데이터의 진실

운영


Matrix 홈서버가 실제로 바꾸는 것: Synapse와 Conduit 비교, 되돌릴 수 없는 server_name, 디스크를 채우는 미디어, 연합이 드러내는 정보.


8개 자주 묻는 질문](https://servhidden.com/ko/guides/self-host-a-matrix-server)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

운영


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


8개 자주 묻는 질문](https://servhidden.com/ko/guides/self-host-a-crypto-payment-gateway)




## 마이그레이션이 내려앉을 곳을 마련하세요



일곱 개 관할권의 역외 KVM 서버, 월 $7.50부터 — 완전한 루트 권한, NVMe 스토리지, 무제한 대역폭을 갖추고 암호화폐 결제가 확인되면 5분 이내에 배포됩니다. 목적지 서버를 미리 띄워 두고, 원하는 속도로 복사한 뒤, 준비되면 전환하세요.


[VPS 요금제 보기](https://servhidden.com/ko/vps)
[오프쇼어 호스팅](https://servhidden.com/ko/offshore-hosting)
[전체 로케이션](https://servhidden.com/ko/locations)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "7개 오프쇼어 관할권의 VPS 및 전용 서버. KYC 없음, 로그 없음, 암호화폐 전용. 아키텍처 차원에서 프라이버시를 설계했습니다.",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "웹사이트를 다운타임 없이 역외 호스팅으로 이전하는 방법",
    "description": "호스트 마이그레이션을 지루한 일로 만드는 순서 — DNS TTL을 며칠 전에 낮추고, 두 서버를 동시에 띄운 채 쓰기 동결은 시간이 아니라 분 단위로 끝내는 것 — 과 이전이 남기는 패시브 DNS·Certificate Transparency·WHOIS 흔적을 정리하는 방법까지 담았습니다.",
    "image": "https://servhidden.com/assets/img/guides/migrate-website-to-offshore-hosting.webp?v=1787969426",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-29T00:00:00+00:00",
    "dateModified": "2026-08-29T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/migrate-website-to-offshore-hosting",
    "inLanguage": "ko",
    "keywords": "웹사이트 서버 이전, 무중단 호스팅 마이그레이션, 호스팅 다운타임 없이 옮기기, DNS TTL 전환, VPS 마이그레이션 체크리스트, 역외 호스팅으로 이전, KYC 없는 호스팅 이전, rsync 서버 마이그레이션",
    "articleSection": "운영",
    "wordCount": 3825
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "실제로 다운타임은 얼마나 예상해야 하나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "정적 사이트라면 전혀 없습니다 — 두 서버가 동시에 같은 콘텐츠를 서비스할 수 있으므로 DNS 변경 자체가 눈에 띄지 않습니다. 데이터베이스가 있는 경우 다운타임은 정확히 쓰기 동결 시간만큼이며, 사전에 전체 데이터 복사를 이미 마쳤다면 보통 2~10분입니다. 중요한 수치는 DNS가 얼마나 빨리 퍼지느냐가 아니라 전환 창 동안 얼마나 많은 데이터를 복사하느냐입니다. 며칠 전에 미리 거의 모든 것을 복사해 두면 전환 창은 델타 크기만큼으로 줄어듭니다."
            }
        },
        {
            "@type": "Question",
            "name": "DNS 전파는 얼마나 걸리나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "\"전파\"라는 현상 자체가 없습니다 — 그 단어는 실제로는 일어나지 않는 일을 가리킬 뿐입니다. 리졸버는 그저 TTL이 정한 시간만큼 레코드를 캐시했다가 만료되면 다시 물어봅니다. 적용 중이던 TTL이 86400이었다면 일부 리졸버는 앞으로 24시간 더 예전 IP를 내려줄 수 있습니다. 전환 최소 한 번의 기존 TTL 주기 전에 TTL을 300초로 낮춰 두면 인터넷 전체가 5분 안에 변경 사항을 따라옵니다."
            }
        },
        {
            "@type": "Question",
            "name": "도메인도 함께 옮겨야 하나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "아닙니다. 등록기관과 호스트는 완전히 별개이며, 도메인은 그대로 둔 채 사이트만 옮겨도 아무 문제 없이 작동합니다. 옮겨야 하는지는 마이그레이션 이유에 달려 있습니다. 관할권, 가격, DMCA 대응 방침 때문이었다면 도메인은 그대로 두십시오. 익명성 때문이었다면 도메인이 그 자체로 별도의 이력을 갖고 있다는 점을 기억하십시오 — WHOIS 아카이브는 최초 등록 당시의 정보를 그대로 보관하며, 호스팅 변경은 그것을 건드리지 못합니다."
            }
        },
        {
            "@type": "Question",
            "name": "예전 호스트가 제가 어디로 갔는지 모르게 마이그레이션할 수 있나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "두 머신 사이를 직접 복사한다면 불가능합니다 — 한쪽이 다른 쪽에 접속하는 순간 양쪽 접속 로그 모두에 그것이 기록됩니다. 그 연결 고리가 위협 모델상 정말로 중요하다면 호스트 간 직접 복사를 아예 하지 마십시오. 대신 자신의 오프사이트 암호화 백업에서 새 서버를 복원하면 두 공급자는 패킷 하나 주고받지 않습니다. 어느 쪽이든, 자신을 특정할 수 있는 연결로는 절대 전송을 시작하지 말고, 예전 공급자에게 여는 지원 티켓에 목적지 정보를 남기지 마십시오."
            }
        },
        {
            "@type": "Question",
            "name": "OS나 스택 업그레이드도 같은 시점에 해야 하나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "아니요, 그것이야말로 가장 흔한 자초형 마이그레이션 실패입니다. 한 번에 하나만 바꾸십시오. 전환 후 사이트가 이상하게 작동한다면 원인 후보가 새 머신, 새 PHP 버전, 새 데이터베이스 메이저 버전 중 무엇인지 고민하는 것이 아니라 단 하나의 설명만 있기를 바랄 것입니다. 예전 환경과 버전을 하나하나 맞춰 이전을 마치고, 일주일간 깨끗한 로그를 확인한 뒤, 롤백이 가능한 상태로 별도로 업그레이드하십시오."
            }
        },
        {
            "@type": "Question",
            "name": "마이그레이션을 하면 검색 순위가 떨어지나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "도메인, URL, 콘텐츠가 그대로 유지된다면 의미 있는 순위 하락은 없습니다 — 구글은 IP 주소가 아니라 URL을 인덱싱하며, 호스트 변경 자체는 랭킹 신호가 아닙니다. URL 구조를 동일하게 유지하고, 같은 상태 코드를 반환하며, 이전과 리디자인이나 URL 체계 변경을 함께 진행하지 마십시오. 대신 새 도메인으로 옮기는 경우라면 301 리다이렉트를 올바르게 설정해도 일시적인 순위 하락은 각오해야 하며, 그 리다이렉트 자체가 두 이름을 공개적으로 연결한다는 점도 알아 두어야 합니다."
            }
        },
        {
            "@type": "Question",
            "name": "TLS 인증서도 새로 발급해야 하나요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "예 — 새 서버는 자신만의 인증서와 개인 키가 있어야 하며, 예전 키를 그대로 가져오는 것은 기술적으로 작동하더라도 나쁜 습관입니다. 전환 전에 DNS-01 챌린지로 발급하십시오. TXT 레코드로 검증하므로 A 레코드가 아직 예전 호스트를 가리키는 동안에도 성공합니다. DNS 변경 후에 HTTP-01을 기다리면 지키려던 바로 그 구간에서 인증서 경고가 이어지는 것이 사실상 확정됩니다."
            }
        },
        {
            "@type": "Question",
            "name": "예전 서버는 언제 해지해도 안전한가요?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "예전 머신의 로그가 조용해지고 새 머신의 로그가 깨끗한 상태로 한두 주가 지난 뒤입니다 — 그 지연 시간이 곧 당신의 롤백이며, 비용은 몇 달러에 불과합니다. 해지하기 전에 외부의 무언가가 여전히 예전 IP를 가리키고 있지 않은지 확인하고, 그 위에 있었던 모든 시크릿을 교체한 뒤 데이터를 삭제하고 여유 공간을 덮어쓰십시오. 해지는 가장 마지막입니다. 해지부터 먼저 눌러 버리면 더 이상 통제하지 못하는 디스크 위에 데이터베이스를 남겨 두게 됩니다."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "홈",
            "item": "https://servhidden.com/ko/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "프라이버시 호스팅 가이드",
            "item": "https://servhidden.com/ko/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "웹사이트를 다운타임 없이 역외 호스팅으로 이전하는 방법",
            "item": "https://servhidden.com/ko/guides/migrate-website-to-offshore-hosting"
        }
    ]
}
```