SSD Nodes Learn 🎉 VPS $4.99/월부터
가이드 Matt Connor작성자 Matt Connor

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

RAM 1GB당 가격, 전송량, NVMe 스토리지 및 백업 비용을 기준으로 DigitalOcean 대안을 비교합니다. 서비스 이전 시 가동 중단 시간을 최소화하는 전략과 함께 2026년 최신 가격 데이터를 바탕으로 개발자에게 가장 경제적인 클라우드 인프라 선택 방법을 제시합니다.

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

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

이 가이드는 이러한 기준을 바탕으로 비교합니다. 개발자는 터미널이나 공개된 가격표를 통해 이 모든 항목을 직접 확인할 수 있기 때문입니다. 또한, 아무것도 인정하지 않는 비교는 광고에 불과하므로 DigitalOcean이 올바른 선택인 경우도 명시합니다.

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

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

ChartMonthly list price per GB of RAM, entry shared-CPU plans, checked 5 August 2026
The data behind this chart
[
  {
    "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 1GB당 가격은 거의 변하지 않습니다. DigitalOcean은 1GB 플랜에서 GB당 $6.00를 청구하며, 월 $24.00인 4GB 플랜에서도 GB당 $6.00로 동일합니다. 같은 업체에서 더 큰 플랜을 선택한다고 해서 할인이 적용되지는 않으므로, 플랜 크기 자체가 결정 요소는 아닙니다. 중요한 것은 제공업체입니다.

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

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

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

vmstat 1 10

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

포함된 전송량의 실제 비용

ChartIncluded outbound transfer and overage price, same plans, checked 5 August 2026
The data behind this chart
[
  {
    "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는 동일한 섀시 내에서 응답합니다. 네트워크 볼륨은 모든 읽기 작업마다 데이터센터 네트워크를 왕복해야 하므로, 큐 깊이가 깊을 때의 처리량(throughput)이 비슷해 보이더라도 지연 시간의 하한선은 더 높습니다.

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

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

리전 목록은 측정하기 전까지는 마케팅 문구에 불과합니다. 사용자가 체감하는 것은 사용자의 네트워크에서 서버까지의 왕복 시간이며, 이는 지도상의 거리가 아니라 패킷이 이동하는 경로에 따라 결정됩니다. 혼잡한 전송 링크 뒤에 있는 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은 각 홉의 손실률과 지연 시간을 출력하므로, 두 홉 사이에서 발생하는 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와 전용 서버(dedicated server) 간의 비교 문제입니다.

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으로 변경한 뒤, 방금 교체한 이전 TTL 값보다 더 긴 시간 동안 기다리십시오.

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

  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 미만이라면 덤프 및 복원 작업이 쓰기 중단(write freeze) 시간 내에 완료됩니다. 그 이상이라면 며칠 전부터 이전 데이터베이스에서 새 데이터베이스로 복제를 설정하여 동기화되도록 하십시오. 그러면 중단 시간은 승격(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를 허용 목록(allowlist)에 등록한 파트너가 있다면, 전환 전에 해당 정보를 업데이트해야 합니다. 그렇지 않으면 트래픽이 이동하는 즉시 해당 호출이 실패하기 시작합니다.

계약 전 확인 사항

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

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

FAQ

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

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

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

관리형 데이터베이스 사용이 DigitalOcean을 선택한 주된 이유라면, 동일한 서비스를 제공하는 Vultr나 Akamai가 가장 적합한 대체재입니다. 저가형 유럽 호스팅 업체들은 일반적으로 관리형 데이터베이스를 제공하지 않으므로, 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 주소는 발송 이력이 없으므로 수신 측에서 스팸으로 처리하거나 즉시 거부할 수 있습니다. 또한 DNS의 SPF 및 DKIM 레코드를 업데이트하기 전까지는 이전 호스트를 가리키고 있습니다. 애플리케이션 메일은 이미 평판이 확보된 릴레이나 이메일 서비스를 통해 발송하고, DNS 레코드는 이전 작업 이후가 아닌 이전에 미리 업데이트하십시오.

#vps#providers#comparison#pricing#hosting