DigitalOcean 대안 서비스 가격 및 성능 비교 가이드

DigitalOcean 대안들이 실제로 변화시키는 것

대부분의 DigitalOcean 대안들은 기계 자체가 아니라 청구 금액을 변화시킵니다. 어떤 서비스를 선택하든 공인 IP, virtio 디스크, root 접근 권한을 가진 Linux 가상 머신을 제공받으며, 커널은 제어판에 어떤 로고가 붙어 있는지 신경 쓰지 않습니다. 선택을 결정짓는 차이점은 RAM 1GB당 가격, 포함된 데이터 전송 허용량과 초과 시 바이트당 비용, 디스크의 실제 구성, 그리고 운영체제 상위 스택을 얼마나 대신 관리해 주느냐에 있습니다.

이 가이드는 개발자가 터미널이나 공개된 가격표를 통해 직접 확인할 수 있는 이러한 기준들을 중심으로 비교합니다. 또한, 아무것도 인정하지 않는 비교는 광고에 불과하므로 DigitalOcean이 적합한 경우도 명시합니다.

아래의 모든 가격은 2026년 8월 5일 기준으로 확인된 공개 정가입니다. 가격은 변동되며, 여기에 나열된 공급자 중 한 곳 이상이 2026년 중에 가격을 변경했습니다. 가격 구조는 훨씬 느리게 변하므로, 비율과 과금 모델을 먼저 파악한 뒤 결정을 내리기 전에 공급자의 페이지에서 오늘의 가격을 확인하십시오.

RAM GB당 가격이 비교 기준입니다

[
  {
    "provider": "DigitalOcean 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "DigitalOcean 4 GB",
    "ram_gb": 4,
    "monthly_usd": "24.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "ram_gb": 1,
    "monthly_usd": "5.00",
    "usd_per_gb_ram": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "ram_gb": 4,
    "monthly_usd": "6.49",
    "usd_per_gb_ram": "1.62"
  }
]

동일한 제공업체 내에서 RAM GB당 가격은 거의 변하지 않습니다. DigitalOcean은 1 GB 플랜에서 GB당 $6.00를 청구하며, 월 $24.00인 4 GB 플랜에서도 동일하게 GB당 $6.00를 청구합니다. 같은 업체에서 더 큰 플랜을 선택한다고 해서 할인이 적용되지는 않으므로, 플랜 크기는 결정 요소가 아닙니다. 결정 요소는 제공업체 자체입니다.

과거 Linode를 인수한 Akamai는 2 GB 및 4 GB 공유 플랜을 각각 $12와 $24에 판매하며, 이는 DigitalOcean과 정확히 일치하는 가격입니다. Akamai의 엔트리 플랜은 월 $5.00로 이들보다 저렴합니다. 두 회사가 가격을 정확히 맞추는 것은 중요한 신호입니다. 해당 티어는 하드웨어가 아닌 경쟁사를 기준으로 가격이 책정되었으며, 앞으로도 경쟁사의 가격을 따라갈 것임을 의미합니다.

자체 데이터센터를 구축하고 유로화로 판매하는 제공업체들과는 가격 차이가 발생합니다. Hetzner CX23은 월 약 $6.49에 4 GB의 RAM을 제공하며, 이는 GB당 $1.62로 DigitalOcean 요금의 4분의 1 수준입니다. 해당 달러 금액은 유로화 정가에서 환전된 것이므로 환율에 따라 변동됩니다. 또한 Hetzner는 2026년 중에 클라우드 가격을 인상했으므로, 오래된 비교 게시물에 적힌 수치는 더 이상 유효하지 않습니다.

RAM GB당 가격은 제공되는 CPU에 대해 아무것도 알려주지 않습니다. 공유 vCPU는 하이퍼바이저가 다른 테넌트와 코어를 공유하도록 스케줄링함을 의미하며, 실제 성능을 확인하려면 대여한 서버에서 다음을 실행해야 합니다.

vmstat 1 10

st 열을 확인하십시오. 이 수치는 vCPU가 실행 준비 상태였으나 하이퍼바이저가 물리적 코어를 다른 사용자에게 할당하여 대기한 시간의 비율을 나타냅니다. 부하가 걸린 상태에서 몇 퍼센트 정도는 정상입니다. 두 자릿수 이상의 수치가 지속된다면 해당 호스트가 과도하게 할당(oversubscribed)된 것이며, 어떤 저렴한 RAM 가격으로도 사용할 수 없는 코어의 손실을 보상할 수 없습니다. steal time은 이웃 사용자의 문제이며 이웃마다 스케줄이 다르므로, 서버가 가장 바쁜 시간에 이 수치를 확인하십시오. 스토리지와 트래픽 비용을 포함하여 한 달 호스팅에 드는 실제 비용에 대한 더 자세한 내용은 VPS의 월별 실제 비용을 참조하십시오.

포함된 전송량의 실제 비용

[
  {
    "provider": "DigitalOcean 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "included_tb": 2,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "included_tb": 20,
    "overage_usd_per_tb": "1.20"
  }
]

DigitalOcean은 기본 요금제에 1 TB의 아웃바운드 전송량을 포함하며, 초과분에 대해서는 GiB 단위로 과금합니다. 이는 추가 1 TB당 약 $10.00 수준입니다. Akamai는 동일한 TB를 포함하고 그 절반 정도인 1 TB당 약 $5.00를 청구합니다. Vultr는 2 TB를 포함하며 유사한 초과 요율을 적용합니다. Hetzner는 20 TB를 포함하고 초과 시 1 TB당 약 $1.20를 부과하는데, 이는 다른 업체들과 비교했을 때 한 자릿수 이상 저렴한 수준입니다.

표면적인 수치보다 세 가지 구조적 세부 사항이 더 중요합니다. 네 곳 모두 인바운드 트래픽은 무료이므로, 외부로 나가는 데이터만 집계됩니다. DigitalOcean과 Vultr는 계정 내 모든 서버의 허용량을 통합 관리합니다. 따라서 한 대의 서버가 트래픽을 많이 사용하면 다른 서버의 할당량을 소진하게 되며, 여러 대의 소형 서버가 하나의 큰 풀을 공유하는 방식입니다. 또한 사설망이나 VPC 네트워크를 통한 서버 간 트래픽은 일반적으로 집계되지 않습니다. 데이터베이스를 사설 인터페이스에 배치하는 것이 보안뿐만 아니라 비용 측면에서도 중요한 결정인 이유가 바로 여기에 있습니다.

사용량이 제한치에 한참 미치지 못한다면 이러한 내용은 중요하지 않습니다. 블로그, JSON 응답을 사용하는 API, 소규모 SaaS는 한 달에 1 TB를 넘기기 어렵습니다. 하지만 비디오, 이미지 갤러리, 게임 서버, 패키지 미러, 외부 백업 대상은 제한치를 초과할 수 있습니다. 추측하기 전에 먼저 측정하십시오.

sudo apt update && sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

vnstat -m는 전송량을 월별로 출력하며, 수신과 송신으로 구분합니다. 송신 열에 대해서만 요금이 청구됩니다. 데이터베이스는 처음에 비어 있으므로, 설치 후 하루가 지나야 첫 번째 유효한 측정값이 나오며, 한 달이 지나야 온전한 월간 데이터를 확인할 수 있습니다. 그전까지는 제공업체가 제공하는 대역폭 그래프가 유일한 기록입니다.

가격표에 나와 있지 않은 질문을 하나 더 던져야 합니다. 허용량을 초과했을 때 제공업체가 요금을 청구하는지, 아니면 포트 속도를 제한하는지 확인하십시오. 요금 청구는 비용이 발생하지만, 속도 제한은 사용자가 가장 몰리는 순간에 사용자를 잃게 만듭니다. 트래픽이 급증할 때 어떤 결과가 발생하는지 미리 파악해야 합니다.

NVMe 또는 SATA, 그리고 실제 사양 확인 방법

제어판에는 NVMe라고 표시됩니다. 이는 호스트의 디스크에 대한 설명일 뿐이며, 귀하의 가상 머신이 반드시 해당 디스크를 사용 중이라는 의미는 아닙니다. 로컬 스토리지는 가상 디스크를 동일한 물리적 머신 내부의 드라이브에 배치합니다. 네트워크 스토리지는 데이터센터 네트워크를 통해 연결된 별도의 스토리지 클러스터에 디스크를 배치하며, 이 방식 덕분에 즉각적인 크기 조정, 라이브 마이그레이션, 제자리 스냅샷이 가능합니다.

게스트 내부에서 보면 두 방식은 동일하게 보입니다.

lsblk -d -o NAME,ROTA,MODEL,SIZE
cat /sys/block/vda/queue/rotational

ROTA 및 rotational는 호스트가 비회전식(non-rotational)이라고 선언한 모든 장치에 대해 0를 보고합니다. 따라서 NVMe 기반의 네트워크 볼륨은 로컬 NVMe와 정확히 동일한 값을 보고합니다. 이 값은 디스크가 회전하는 플래터 방식이 아님을 알려줄 뿐, 디스크가 어디에 위치하는지는 알려주지 않습니다. Linux에서 NVMe 디스크 확인하기에서는 장치 이름과 각 이름이 의미하는 바를 다룹니다.

이 둘을 구분하는 테스트는 큐 깊이(queue depth) 1에서의 지연 시간입니다. 단일 소규모 읽기 작업은 숨길 곳이 없기 때문입니다. 로컬 NVMe는 동일한 섀시 내에서 응답합니다. 네트워크 볼륨은 모든 읽기 작업마다 데이터센터 네트워크를 왕복해야 하므로, 깊은 큐 깊이에서의 처리량이 비슷해 보이더라도 지연 시간의 하한선은 더 높습니다.

sudo apt update && sudo apt install -y fio
fio --name=lat --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based --group_reporting
fio --name=iops --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fiotest

첫 번째 실행은 완료 지연 시간인 clat 블록을 출력합니다. 평균값은 사용자가 체감하는 지연을 가리므로, 평균 대신 99번째 백분위수(99th percentile) 라인을 확인하십시오. 두 번째 실행은 요약 라인에 IOPS=을 출력합니다. 현재 이용 중인 제공업체와 고려 중인 제공업체의 체험용 인스턴스에서 같은 날 두 테스트를 모두 실행하여 직접 수치를 비교하십시오. 공급업체가 게시한 수치는 귀하가 확인할 수 없는 환경에서 측정된 것입니다. 또한 조용한 호스트와 바쁜 호스트는 같은 플랜이라도 다른 결과를 내놓으므로, 서로 다른 시간대에 3회 이상 실행하십시오. VPS 벤치마킹을 올바르게 수행하는 방법에서는 구체적인 방법을 다루며, SSD VPS의 실제 의미에서는 그 이면에 숨겨진 마케팅 용어를 설명합니다.

리전: 지도를 보지 말고 지연 시간을 측정하십시오

리전 목록은 직접 측정하기 전까지는 마케팅 문구에 불과합니다. 사용자가 체감하는 것은 사용자의 네트워크에서 서버까지의 왕복 시간(round trip)이며, 이는 지도상의 거리가 아니라 패킷이 이동하는 경로에 따라 결정됩니다. 혼잡한 전송 링크 뒤에 있는 300 km 거리의 서버는, 깨끗한 경로에 있는 1,500 km 거리의 서버보다 성능이 떨어집니다.

ping -c 20 203.0.113.10
mtr -rwc 50 203.0.113.10
curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} total %{time_total}\n' https://example.com

mtr은 각 홉(hop)마다 손실률과 지연 시간을 출력하므로, 두 홉 사이에서 발생하는 60 ms의 지연은 목적지를 탓하는 대신 문제를 일으키는 링크를 정확히 지목하게 해줍니다. 이 명령은 사용자가 위치한 네트워크의 장비에서 실행해야 합니다. 데이터센터 간 경로는 인터넷에서 가장 최적화된 경로이며, 모든 제공업체의 성능을 동일하게 보여줍니다.

가격 변동과 관계없이 변하지 않는 구조적 사실이 하나 있습니다. 대륙 내에 리전이 하나뿐인 제공업체를 선택한다는 것은, 재해 복구 계획이 곧 대륙을 이동하는 계획이 됨을 의미하며 그에 따른 지연 시간도 감수해야 한다는 뜻입니다. 웹페이지에 나열된 리전 수가 아니라, 실제로 장애 조치(failover)를 수행할 수 있는 리전의 수를 세어 보십시오.

스냅샷과 백업은 별도 비용입니다

스토리지 부가 기능은 저렴한 요금제를 비싸게 만드는 주범입니다. DigitalOcean은 스냅샷에 대해 GiB당 월 0.06달러를 청구하며, 자동 백업은 서버 가격의 일정 비율로 책정합니다. 주간 백업은 요금제 가격의 20%, 일간 백업은 30%이며, GiB 단위로 과금되는 사용량 기반 옵션도 있습니다. 두 모델 모두 나름의 근거가 있지만, 각각 반대 방향으로 단점이 존재합니다. 비율 기반 가격은 서버 크기에 비례하므로, 작은 데이터셋을 담은 대형 서버는 비용을 과다 지불하게 됩니다. GiB당 가격은 데이터 크기에 비례하므로, 대용량 볼륨이 연결된 소형 서버는 비용을 과다 지불하게 됩니다.

복구 비용이 얼마인지, 복구에 시간이 얼마나 걸리는지 확인하십시오. 백업을 유지하는 비용은 문제의 절반에 불과하기 때문입니다. 서버를 삭제할 때 스냅샷도 함께 삭제되는지 확인하십시오.

그다음, 제공업체가 제어할 수 없는 사본을 따로 보관하십시오. 제공업체의 스냅샷은 해당 업체의 계정 내에 존재하므로, 로그인 정보 분실, 결제 실패, 계정 정지 등의 상황이 발생하면 서버와 백업이 동시에 사라집니다. 직접 소유한 스토리지로 restic 백업을 수행하면 오브젝트 스토리지 비용으로 몇 달러 정도만 지불하면 되며, 어떤 제공업체로든 복구가 가능합니다. 이는 마이그레이션을 되돌릴 수 없는 결정이 아닌, 언제든 되돌릴 수 있는 과정으로 만들어 줍니다.

스택의 어느 범위까지 직접 운영할 것인가

제공업체들은 일직선상에 놓여 있습니다. 한쪽 끝에는 기계를 임대하여 모든 것을 직접 운영하는 방식이 있고, 다른 쪽 끝에는 git 브랜치를 푸시하기만 하면 서버를 전혀 볼 필요가 없는 방식이 있습니다. RAM 1GB당 가격은 첫 번째 방식에서만 유효한 비교 기준입니다. 두 번째 방식에서는 메모리가 아닌 노동력을 구매하는 것이며, 노동력에는 GB당 가격이 책정되지 않기 때문입니다.

무엇을 비교하기 전에 자신이 어느 지점에 있는지 솔직해져야 합니다. 월 15.15달러의 관리형 데이터베이스는 6달러짜리 서버와 비교하면 비싸 보입니다. 하지만 그 뒤에 숨겨진 노동력의 가치를 계산하면 다릅니다. 복제, 장애 조치(failover), 특정 시점 복구(point in time restore), 마이너 버전 업그레이드, 그리고 새벽 03:00에 누군가를 깨우는 알람 등이 포함되기 때문입니다. 만약 그 작업이 본인의 업무라면 직접 운영하고 차액을 가져가십시오. 하지만 본인의 업무가 애플리케이션 개발이라면, 해당 작업을 외주로 돌리는 것은 저렴한 선택입니다. 관리형과 비관리형의 구분은 가격표의 어느 열을 읽어야 할지 결정해 줍니다. 만약 솔직한 답변이 기계 전체와 디스크를 독점하고 싶다는 것이라면, 이는 제공업체 선택의 문제가 아니라 VPS와 전용 서버 간의 비교 문제입니다. 동일한 질문은 개발자의 월간 청구서 나머지 항목에서도 나타납니다. Claude와 ChatGPT 플랜 비교 역시 표면적인 가격보다는 업무의 어느 정도를 위임하고 싶은지에 따라 결정됩니다.

DigitalOcean이 적합한 경우

가상 머신이 아닌 플랫폼 자체를 구매할 때 DigitalOcean이 유리합니다.

• Managed databases. Managed PostgreSQL 및 MySQL은 1 GiB RAM과 10 GiB 스토리지를 기준으로 월 $15.15부터 시작하며, 추가 스토리지는 GiB당, 대기 노드는 노드당 비용이 청구됩니다. 동일한 신뢰성을 직접 구축하려면 Patroni나 repmgr, 합의 저장소(consensus store), 연결 프록시, 그리고 실제로 훈련된 장애 조치(failover) 절차가 필요합니다. 2인 규모의 팀이 이 모든 것을 유지하면서 새로운 기능을 개발하기는 어렵습니다.
• App Platform. 브랜치를 푸시하면 빌드, 인증서, 실행 중인 서비스가 자동으로 생성되며 패치할 운영 체제도 없습니다. 저렴한 VPS로 이와 동일한 환경을 직접 구축하는 것은 주말을 반납해야 하는 작업입니다.
• 성숙한 Terraform 프로바이더가 지원하는 객체 스토리지 및 로드 밸런서. 코드로 파괴하고 재구축할 수 있는 인프라는 낮은 단가보다 더 큰 가치를 지닙니다.
• 제품을 뒷받침하는 기업. 공개된 지원 등급, 이력이 포함된 상태 페이지, 고객의 보안 설문지에 응답할 수 있는 조직 체계가 갖춰져 있습니다. 호스팅을 재판매하는 경우, 이는 GB당 몇 달러를 아끼는 것보다 훨씬 가치 있는 요소입니다.

DigitalOcean의 비용이 높아지는 지점은 대량의 일반 가상 머신을 사용하면서 실제 아웃바운드 트래픽이 발생할 때입니다. 이는 대안 업체들이 해결하는 영역이며, 자가 호스팅 개발자가 주로 구매하는 서비스 형태이기도 합니다.

다운타임 없이 새 제공업체로 마이그레이션하기

마이그레이션 중 발생하는 다운타임은 데이터가 새 서버로 이동한 후에도 이전 IP로 트래픽이 유입될 때 발생합니다. 아래의 모든 단계는 이 전환 구간을 짧고 예측 가능하게 만들기 위해 존재합니다.

이동 최소 48시간 전부터 DNS 작업을 시작하십시오. 리졸버는 TTL(time to live) 기간만큼 A 레코드를 캐시합니다. 따라서 TTL이 24시간인 레코드는 변경 후에도 최대 하루 동안 사용자를 이전 서버로 보냅니다. 전환 시점에 TTL을 낮추는 것은 도움이 되지 않습니다. 리졸버가 이미 이전 만료 시간이 포함된 이전 값을 가지고 있기 때문입니다. 먼저 TTL을 낮추고, 이전 값이 만료될 때까지 기다린 후 마이그레이션을 진행하십시오.

dig +noall +answer example.com A
dig +noall +authority example.com SOA

첫 번째 명령은 응답의 두 번째 열에 현재 TTL을 출력합니다. DNS 제공업체 설정에서 이를 300으로 변경한 뒤, 방금 교체한 기존 값보다 더 긴 시간 동안 기다리십시오.

그다음 아래 순서대로 작업을 진행하십시오.

1. 새 서버를 프로비저닝하고 다른 데이터가 올라오기 전에 보안 설정을 강화하십시오. 새 VPS에서의 첫 10분은 서두르는 사람들이 흔히 건너뛰는 부분을 다룹니다.
2. 애플리케이션 스택을 설치하고 이전 서버가 정상적으로 서비스를 제공하는 동안 rsync를 사용하여 1차 데이터 복사를 수행하십시오.
3. DNS-01 챌린지를 사용하여 새 호스트에서 TLS 인증서를 발급받으십시오. HTTP-01 챌린지는 현재 DNS가 가리키는 IP(즉, 여전히 이전 서버)를 기준으로 검증하기 때문입니다. DNS-01 챌린지는 이러한 순서 문제를 완전히 해결합니다.
4. 공개적인 변경 전에 본인의 노트북에서 DNS를 오버라이드하여 새 호스트를 테스트하십시오. 203.0.113.20 example.com를 /etc/hosts에 추가하여 실제 사이트를 탐색한 뒤 해당 줄을 삭제하십시오. 이 테스트는 사용자에게 영향을 주지 않습니다.
5. 데이터베이스 크기 문제를 처리하십시오. 데이터가 몇 GB 미만이라면 덤프 및 복원이 쓰기 중단 시간 내에 가능합니다. 그보다 크다면 며칠 전부터 이전 데이터베이스에서 새 데이터베이스로 복제를 설정하여 동기화하십시오. 이렇게 하면 중단 시간은 승격(promotion) 작업에만 소요됩니다.
6. 쓰기를 중단하십시오. 애플리케이션을 유지보수 모드나 읽기 전용 모드로 전환하십시오. 이 단계만이 사용자가 체감하는 부분이며, 몇 분 이내로 완료되어야 합니다.
7. 최종 델타 작업을 수행하십시오. rsync를 다시 실행하고 마지막 데이터베이스 동기화를 진행하십시오.
8. A 및 AAAA 레코드를 새 IP로 변경하십시오. TTL이 300초이면 대부분의 리졸버는 약 5분 이내에 이를 반영합니다.
9. 일부 리졸버는 짧은 TTL을 무시하므로 이전 서버를 최소 하루 동안은 실행 상태로 유지하십시오. 이전 애플리케이션에 여전히 쓰기가 가능하다면 늦게 도착한 요청이 잘못된 데이터베이스에 기록될 수 있습니다. 따라서 이전 호스트를 새 데이터베이스로 연결하거나 유지보수 페이지를 반환하도록 설정하십시오.
10. 하루 동안 새 서버의 오류율을 모니터링하고, TTL을 정상 값으로 되돌리십시오. 이전 서버는 당일 저녁에 바로 삭제하지 말고 일주일 정도 유지하십시오.

복사 작업은 두 가지 명령으로 구성되며, 각각 두 번씩 실행합니다. 파일 동기화는 다음과 같습니다.

rsync -aHAX --numeric-ids --delete -e ssh /srv/ deploy@203.0.113.20:/srv/

-a은 소유권, 권한, 타임스탬프를 보존하고, -H는 하드 링크를 유지하며, -AX은 ACL과 확장 속성을 유지합니다. --numeric-ids는 두 시스템 간에 이름이 다른 사용자 ID를 rsync가 매핑하지 않도록 방지합니다. 며칠 전에 한 번 실행하고, 쓰기 중단 중에 다시 실행하면 변경된 내용만 전송됩니다.

덤프가 가능한 소규모 PostgreSQL의 경우:

pg_dump --format=custom --no-owner --dbname=appdb --file=appdb.dump
scp appdb.dump deploy@203.0.113.20:/var/tmp/
pg_restore --clean --if-exists --no-owner --dbname=appdb /var/tmp/appdb.dump

MySQL 또는 MariaDB의 경우:

mysqldump --single-transaction --routines --triggers --databases appdb > appdb.sql

--single-transaction는 InnoDB 테이블의 단일 트랜잭션 내에서 덤프를 수행하므로 결과가 일관되며, 실행 중에도 애플리케이션이 계속 데이터를 기록할 수 있습니다. 이 플래그가 없으면 mysqldump가 테이블을 잠그게 되며, 이는 의도한 것보다 일찍 쓰기 중단이 시작되어 제어권을 잃게 됨을 의미합니다.

서버 외부에서 발생하는 두 가지 문제를 주의하십시오. 새 IP 주소는 이메일 평판이 없으므로 새 서버에서 직접 보낸 메일은 스팸으로 필터링됩니다. 이미 평판이 확보된 릴레이를 통해 메일을 발송하십시오. 또한 결제 게이트웨이나 클라이언트 방화벽처럼 아웃바운드 IP를 화이트리스트에 등록해 둔 파트너가 있다면, 전환 전에 해당 설정을 업데이트해야 합니다. 그렇지 않으면 트래픽이 이동하는 즉시 해당 호출이 실패하기 시작합니다.

계약 전 확인해야 할 사항

• 가격이 프로모션 가격인지, 갱신 시점의 가격은 얼마인지 확인하십시오. 첫 계약 기간의 할인이 갱신 시점에 두 배가 된다면, 이는 비용이 절감된 것이 아니라 단지 뒤로 미뤄진 것일 뿐입니다.
• 계약 기간이 선불인지 확인하십시오. SSD Nodes와 같은 서비스가 제공하는 다년 선불 플랜은 초기 비용을 지불하는 대신 GB당 RAM 가격을 크게 낮추는 방식입니다. 이 방식은 다음 달에 바로 해지할 수 없다는 단점이 있으므로, 서비스 이용 확신 정도에 맞춰 계약 기간을 선택하십시오.
• 스냅샷의 월별 비용과 복구 시 발생하는 비용 및 소요 시간을 확인하십시오.
• 초과 사용량에 대해 요금이 청구되는지, 아니면 속도가 제한되는지 확인하십시오.
• IPv6가 제대로 라우팅되는지, 아니면 단순히 주소 하나만 추가된 형태인지 확인하십시오.
• 수동이 아닌 코드로 인프라를 재구축할 계획이라면, 유지 관리되는 Terraform 프로바이더를 제공하는 API가 있는지 확인하십시오.
• 기술 지원팀에 연락하는 방법과, 영업 문의가 아닌 서버 다운 시의 공식적인 대응 목표 시간을 확인하십시오.

본인의 청구서에서 가장 큰 비중을 차지하는 항목을 기준으로 선택하십시오. 그 항목이 메모리라면 GB당 RAM 가격이 결정적인 기준이 됩니다. 아웃바운드 트래픽이라면 포함된 전송량이 기준이 됩니다. 만약 본인의 시간이 중요하다면 관리형 플랫폼이 기준이 되며, 여기에서 비교한 네 곳 중에서는 DigitalOcean이 가장 강력한 관리형 서비스를 제공합니다.

FAQ

Hetzner가 항상 DigitalOcean보다 저렴합니까?

단순 가상 머신의 경우, RAM 1GB당 비용은 Hetzner가 훨씬 저렴합니다. 2026년 8월 5일 기준, 입문용 공유 플랜에서 Hetzner는 약 $1.62인 반면 DigitalOcean은 $6.00입니다. 하지만 관리형 서비스가 포함되면 비교 결과가 달라집니다. Hetzner는 서버와 네트워크 자원만 판매하므로, 관리형 데이터베이스나 배포 플랫폼은 사용자가 직접 구축하거나 제3자 서비스를 이용해야 하며, 이에 따른 운영 비용이 발생합니다. 또한 Hetzner는 2026년 중에 클라우드 가격을 인상했으므로, 오래된 기사보다는 현재의 유로화 기준 가격을 확인해야 합니다.

관리형 데이터베이스가 필요하다면 어떤 DigitalOcean 대안을 선택해야 합니까?

Vultr와 Akamai는 모두 관리형 데이터베이스를 판매하므로, 관리형 데이터베이스 때문에 DigitalOcean을 사용 중이라면 이들이 가장 적합한 대체재입니다. 저가형 유럽 호스팅 업체들은 일반적으로 관리형 데이터베이스를 제공하지 않으며, 이는 사용자가 직접 PostgreSQL이나 MySQL을 운영하고 복제 및 검증된 장애 조치(failover)까지 책임져야 함을 의미합니다. 이는 상당한 작업입니다. 관리형 1 GiB 인스턴스 비용인 월 $15.15와 비교하여, 저렴한 서버로 옮기는 것이 실제로 비용을 절감하는지 판단하십시오.

다운타임 없이 운영 중인 사이트를 새 제공업체로 어떻게 이전합니까?

이전 최소 48시간 전에 DNS TTL을 300초로 낮추십시오. 리졸버는 이전 TTL 설정에 따라 기존 IP를 계속 제공하기 때문입니다. 기존 서버가 트래픽을 처리하는 동안 새 호스트를 구축하고 테스트하십시오. 이때 본인의 컴퓨터에서 /etc/hosts 설정을 사용하여 다른 사용자는 새 호스트를 볼 수 없도록 하십시오. 그 후 몇 분간 쓰기 작업을 중단하고, 최종 rsync 델타와 데이터베이스 동기화를 수행한 뒤 A 및 AAAA 레코드를 변경하십시오. 리졸버가 짧은 TTL을 무시할 가능성에 대비해 기존 서버를 일주일 정도 유지하십시오.

저렴한 VPS는 디스크 속도가 느립니까?

반드시 그렇지는 않습니다. 중요한 것은 가상 디스크가 호스트 로컬에 있는지 아니면 네트워크 스토리지 클러스터에 있는지 여부이며, 제어판에서 이를 명시하는 경우는 드뭅니다. lsblk -o NAME,ROTA은 두 경우 모두 0로 보고하는데, 둘 다 비회전식 매체이기 때문입니다. 대신 직접 측정하십시오. --iodepth=1 --bs=4k --direct=1 옵션을 사용하여 fio를 실행하고 99번째 백분위수 완료 지연 시간을 확인하십시오. 네트워크 볼륨은 모든 읽기 작업마다 데이터센터 네트워크 왕복이 추가되므로, 깊은 큐 처리량이 비슷해 보이더라도 지연 시간의 하한선은 로컬 NVMe보다 높습니다.

새 서버에서도 이메일이 정상적으로 발송됩니까?

처음에는 그렇지 않을 가능성이 높습니다. 새로운 IP 주소는 발송 이력이 없으므로 수신 측에서 메일을 의심스러운 것으로 간주하여 스팸으로 분류하거나 즉시 거부할 수 있습니다. 또한 SPF 및 DKIM 레코드를 업데이트하기 전까지는 이전 호스트를 가리키고 있습니다. 애플리케이션 메일은 이미 평판이 확보된 릴레이나 이메일 서비스를 통해 발송하고, DNS 레코드는 이전 작업 이후가 아닌 이전에 업데이트하십시오.