이 글의 링크는 추후 제휴 링크로 바뀔 수 있으며, 그 경우 구매 시 수수료를 받을 수 있습니다.
이 글에서 다루는 것
한국 독자를 보는 블로그를 해외 클라우드 서버에 올려도 되는지를, 오늘 공식 페이지에서 확인한 리전 목록과 공개 문서의 속도 기준만 가지고 정리합니다.
워드프레스를 해외 호스팅에 올릴지 망설이는 분, 이미 올려 두고 "느린 게 서버 위치 때문인가" 싶은 분을 위한 글입니다.
읽고 나면 서버를 어느 도시에 둘지, CDN으로 덮을 수 있는 부분이 어디까지인지 오늘 결정할 수 있습니다.
결론부터: 됩니다. 다만 거리만큼의 지연은 남습니다
해외 서버로 한국 블로그를 운영하는 데 제도적인 금지는 없습니다.
실제로 국내 상위 노출 블로그 중에도 해외 서버에 올라간 사이트가 흔합니다.
문제는 허용 여부가 아니라 체감 속도입니다.
독자의 요청은 광케이블을 타고 서버까지 갔다가 돌아오므로, 거리는 그대로 왕복 지연으로 쌓입니다.
서울과 도쿄는 가깝고, 싱가포르는 그보다 멀며, 미국 동부는 훨씬 멉니다.
기준선은 공개돼 있습니다.
web.dev 문서는 서버가 첫 바이트를 돌려주기까지 걸리는 시간(TTFB)에 대해 "대부분의 사이트는 0.8초 이하를 목표로 해야 한다"고 적고, 0.8초 이하면 양호, 1.8초 초과면 나쁨으로 봅니다.
이 예산 안에서 왕복 지연이 차지하는 몫이 클수록 본문 처리에 쓸 여유가 줄어듭니다.
그래서 순서는 하나입니다.
먼저 가까운 리전이 있는 공급사를 고르고, 그다음에 CDN으로 남는 부분을 덮습니다.
반대로 하면 돈만 더 씁니다.
1단계. 서울 리전이 있는 공급사부터 확인합니다
클라우드웨이즈는 서버를 직접 운영하지 않고 다섯 곳의 클라우드 위에 올려 주는 방식이라, 고를 수 있는 도시가 공급사마다 다릅니다.
요금 페이지의 'View Data Center Locations'를 열고 도시 이름으로 검색하면 바로 확인됩니다.
① 검색창에 Seoul을 넣고 ② 'All Locations' 탭을 보면, 오늘 기준 서울을 제공하는 곳은 Vultr · AWS · Google Cloud 세 곳입니다.
세 곳 모두 도시 목록에 Seoul이 한 줄씩 잡힙니다.
① 같은 검색을 DigitalOcean 탭에서 하면 "No cities match your search."가 뜹니다.
기본 선택 공급사인 DigitalOcean에는 서울이 없고, 목록에서 한국과 가장 가까운 곳이 싱가포르입니다.
Linode 역시 서울은 없고 도쿄·오사카까지입니다.
오늘 확인한 목록을 한국 기준으로 줄이면 이렇게 됩니다.
| 공급사 | 서울 리전 | 한국에서 가장 가까운 선택지 |
|---|---|---|
| DigitalOcean | 없음 | 싱가포르(그다음 방갈로르) |
| Vultr | 있음 | 서울 · 도쿄 · 오사카 |
| Linode | 없음 | 도쿄 · 오사카 |
| AWS | 있음 | 서울 · 도쿄 · 오사카 |
| Google Cloud | 있음 | 서울 · 도쿄 · 타이완 |
정리하면, 한국 독자가 대부분인 블로그라면 공급사 선택에서 이미 절반이 갈립니다.
서버를 만들 때 공급사와 도시는 나중에 바꿀 수 없고 새로 만들어 옮겨야 하므로, 첫 화면에서 정하는 편이 편합니다.
데이터센터 목록에서 서울 리전이 있는 공급사를 직접 펼쳐 보기
2단계. CDN이 덮어 주는 범위를 정확히 압니다
"CDN 붙이면 서버가 어디 있든 상관없다"는 말을 자주 봅니다.
절반만 맞습니다.
클라우드플레어 공식 문서의 기본 캐시 동작을 보면 경계가 분명합니다.
① 문서는 "클라우드플레어 CDN은 기본적으로 HTML이나 JSON을 캐시하지 않는다"고 적고, 캐시 대상을 MIME 타입이 아니라 파일 확장자로 판단한다고 밝힙니다.
아래 표가 기본 캐시 확장자 목록이며 CSS · JS · JPG · WEBP · WOFF2 같은 정적 파일이 여기에 들어갑니다.
즉 이미지·CSS·폰트는 독자와 가까운 엣지에서 나가지만, 글 본문이 담긴 HTML 응답은 기본 설정에서 매번 원 서버까지 다녀옵니다.
첫 바이트가 늦는 문제, 다시 말해 서버 위치 문제는 CDN을 붙였다고 저절로 사라지지 않습니다.
HTML까지 엣지에 올리려면 캐시 규칙을 따로 만들거나 엣지 페이지 캐싱이 포함된 상위 CDN을 붙여야 합니다.
클라우드웨이즈의 엔터프라이즈 클라우드플레어 애드온이 후자에 해당하고, 오늘 요금 페이지 기준 도메인당 월 4.99달러부터 별도로 청구됩니다.
무료 플랜으로 시작한다면 정적 파일만 엣지에 올라간다고 보는 편이 안전합니다.
3단계. 서울 리전의 값을 계산합니다
가까운 리전에는 값이 붙습니다.
이 점을 빼고 "서울로 고르세요"라고만 쓰는 글이 많은데, 공식 안내가 명확합니다.
① 요금 페이지 FAQ는 리전마다 요금이 다르다고 답합니다.
AWS와 GCP는 리전별 인프라 가격이 다르고 그 차이를 그대로 고객에게 넘기며, 북미·유럽이 아시아 태평양·남미보다 대체로 저렴하다고 적혀 있습니다.
서울을 고르면 같은 사양이라도 미국 리전보다 비쌀 수 있다는 뜻입니다.
① 오늘 요금표의 최저 요금제는 Micro이고, 설명이 "개인 사이트와 단순 블로그에 적합하다"입니다.
1GB RAM · 1 vCPU · 25GB NVMe · 전송량 1TB에 월 14달러(시간당 0.0208달러)이며, 화면의 기본 선택은 DigitalOcean입니다.
세금은 별도이고, 공급사를 Vultr·AWS·Google Cloud로 바꾸면 이 숫자는 그대로 적용되지 않습니다.
전송량을 넘겼을 때의 단가도 공급사마다 다릅니다.
같은 FAQ 기준으로 DigitalOcean은 GB당 0.02달러, AWS는 전 리전 0.12달러, GCP는 리전에 따라 0.10~0.17달러가 초과분에 붙습니다.
글 위주 블로그가 월 1TB를 넘기는 일은 드물지만, 이미지가 많고 유입이 몰리는 달에는 이 단가가 요금 차이를 만듭니다.
권하는 시작점은 최저 요금제 그대로입니다.
메모리 경고가 뜨거나 방문자가 늘어 응답이 느려질 때 한 단계 올리면 되고, 처음부터 상위 요금제를 잡을 이유는 없습니다.
오늘 기준 요금표와 리전별 과금 안내를 공식 페이지에서 대조해 보기
해외 서버가 안 맞는 경우
거리 문제를 풀었다고 해서 모두에게 맞지는 않습니다.
아래에 해당하면 국내 공유 호스팅이 더 편합니다.
결제가 달러라 환율에 따라 원화 청구액이 달라집니다.
관리 화면과 문서가 영어이고, 한국어 상담 창구는 없습니다.
메일 호스팅이 포함되지 않아 도메인 메일이 필요하면 별도 애드온(오늘 기준 메일박스당 월 1.5달러)을 붙여야 합니다.
월 1만 원 안쪽의 공유 호스팅으로 충분한 트래픽이라면, 서버 위치를 고민하는 것보다 이미지 용량을 줄이는 쪽이 체감 속도에 더 크게 작용합니다.
제도 측면에서 하나 더 있습니다.
댓글·문의 폼·구독 메일처럼 개인정보를 받는 블로그를 해외 서버에 올리면, 개인정보 보호법 시행령 제31조 제1항이 처리방침에 적도록 정한 항목 중 '국외 이전의 근거와 관련 사항'이 해당하게 됩니다.
운영해도 되지만, 처리방침에 그 사실을 적는 일은 남습니다.
카드 없이 사흘 동안 리전을 바꿔 가며 응답 속도를 재 보는 방법 확인하기
자주 묻는 질문
해외 서버에 올리면 네이버 검색에 불리한가요?
서버 위치 자체를 감점 요소로 밝힌 공식 문서는 없습니다.
다만 로봇이 페이지를 가져갈 때도 같은 왕복 지연을 겪으므로, 응답이 느린 상태를 오래 두는 것은 권하지 않습니다.
서버를 만든 뒤에 리전만 바꿀 수 있나요?
공급사와 도시는 서버를 만들 때 정해집니다.
바꾸려면 새 리전에 서버를 만들고 사이트를 옮기는 절차가 필요하므로, 처음에 정하는 편이 비용이 적게 듭니다.
도쿄와 서울 중 어디가 나은가요?
한국 독자만 본다면 서울이 가깝습니다.
다만 서울은 Vultr·AWS·Google Cloud에만 있고 아시아 태평양 리전은 요금이 더 붙을 수 있으니, 요금표를 같이 보고 정하십시오.
무료 CDN만으로 충분한 경우도 있나요?
이미지와 CSS 비중이 큰 정적인 블로그라면 체감 개선이 꽤 큽니다.
로그인·댓글·검색처럼 매번 새로 만들어지는 페이지가 많다면 원 서버 위치가 계속 남습니다.
마무리
해외 서버로 한국 블로그를 운영하는 것은 가능하고, 남는 문제는 거리에서 오는 왕복 지연입니다.
오늘 기준 서울 리전은 Vultr·AWS·Google Cloud에 있고, DigitalOcean과 Linode에는 없습니다.
서버를 만들기 전 공급사 선택이 사실상 리전 선택입니다.
CDN은 정적 파일까지가 기본 범위이고 HTML은 캐시 대상이 아닙니다.
가까운 리전으로 첫 바이트를 줄이고, 남는 부분을 CDN으로 덮는 순서가 맞습니다.
지금 쓰시는 서버는 어느 도시에 있고 TTFB는 몇 초로 나오시나요?
댓글로 남겨 주시면 리전을 옮길 만한 상황인지 같이 따져 보겠습니다.