SSD Nodes Learn 🎉 VPS $5.50/월부터
가이드 Matt Connor작성자 Matt Connor · 업데이트됨 2026-08-13

Storage VPS와 일반 VPS 차이점 및 용도 비교

Storage VPS는 대용량 저속 디스크를, 일반 VPS는 고속 NVMe와 많은 CPU를 제공합니다. 백업과 미디어 서버 등 데이터 성격에 따른 적합한 플랜 선택 기준과 Standard VPS, VDS, Block storage의 차이를 명확하게 정리해 드립니다.

Storage VPS와 일반 VPS의 차이: 요약

Storage VPS는 테라바이트 단위로 판매되는 가상 사설 서버이며, 일반 VPS는 코어 단위로 판매됩니다. Storage 플랜은 적은 CPU 점유율과 함께 수 테라바이트의 저속 디스크를 제공합니다. 표준 플랜은 동일한 가격에 더 많은 프로세서와 메모리를 제공하며, 보통 20배 더 작은 고속 NVMe(non-volatile memory express) 디스크를 탑재합니다. 두 제품의 나머지 사양은 동일합니다. 동일한 하이퍼바이저, 동일한 root 셸, 동일한 Ubuntu 이미지, 동일한 네트워크 스택을 사용합니다.

이러한 차이점이 적합한 용도를 결정합니다. Storage VPS는 백업 대상, 미디어 라이브러리, 콜드 아카이브 등 한 번 기록하고 거의 읽지 않는 데이터에 적합합니다. 데이터베이스나 사용자가 응답을 기다려야 하는 웹 페이지에는 적합하지 않습니다. 이러한 작업은 작은 단위의 무작위 읽기(random read)가 약 1밀리초 내에 완료되어야 하는데, 저렴한 용량의 스토리지는 바로 그 성능을 제공할 수 없기 때문에 저렴한 것입니다.

가격 페이지에서 접하게 되는 플랜 명칭

거의 모든 공급업체가 4가지 명칭을 사용하며, 그중 두 가지만이 구체적인 의미를 지닙니다.

  • Standard VPS. 2개에서 8개의 vCPU, 2 GB에서 32 GB의 RAM, 그리고 호스트 노드에 직접 연결된 20 GB에서 400 GB 용량의 NVMe 또는 SATA SSD를 제공합니다.
  • Storage VPS. 1 TB에서 20 TB 이상의 용량을 제공하며, 일반적으로 회전식 SATA 디스크나 고용량 SATA SSD를 사용합니다. 1개에서 4개의 공유 vCPU와 적절한 수준의 RAM을 포함하며, 소규모 Standard 플랜과 월 이용료가 비슷한 경우가 많습니다.
  • VDS. Virtual Dedicated Server의 약자입니다. 이 용어에 대해 합의된 정의는 없으므로, 아래 섹션에서 무엇을 확인해야 하는지 다룹니다.
  • Block storage volume. 플랜이 아닙니다. 기존 VPS에 추가하여 GB당 월 단위로 비용을 지불하는 네트워크 연결 디스크입니다. 이 4가지 중 서버를 이전하지 않고도 용량을 확장할 수 있는 유일한 항목입니다.

위의 범위는 특정 업체의 제안이 아니라 시장 전반의 일반적인 형태를 나타냅니다. 플랜의 명칭은 카테고리일 뿐이며, 서버가 어떤 섀시에서 구동되는지 대략적으로 알려줄 뿐입니다. 디스크 유형, CPU 할당 정책, 대역폭 허용량은 명칭만으로는 알 수 없으며, 이러한 세부 사항이 워크로드의 원활한 실행 여부를 결정합니다.

두 요금제 사이의 실질적인 차이점

디스크 유형 및 수량. 이것이 제품의 전체적인 차이입니다. 표준 요금제는 PCI Express 버스를 통해 연결된 NVMe 플래시를 사용합니다. 스토리지 요금제는 대규모 HDD 어레이나 고용량 SATA SSD를 사용합니다. 이 용어들의 차이가 무엇인지 확실하지 않다면, SSD VPS의 정의와 구형 디스크 요금제와의 차이점을 먼저 확인한 뒤 NVMe와 SATA SSD의 실질적인 성능 격차를 읽어보시기 바랍니다.

CPU 비율. 스토리지 요금제는 테라바이트당 vCPU 수가 적으며, 이 vCPU들은 거의 항상 다른 사용자와 공유됩니다. 이는 결함이 아닙니다. 백업 대상 서버는 네트워크 응답을 기다리는 시간이 대부분이므로 많은 코어가 필요하지 않습니다.

RAM. 스토리지 요금제는 가격 대비 RAM 용량이 적습니다. 이는 파일 시스템 메타데이터 처리 시 문제가 됩니다. 수백만 개의 작은 파일을 다룰 때는 디렉터리와 inode 캐시를 위해 메모리가 필요한데, 메모리가 부족하면 모든 목록 조회 작업이 디스크 읽기로 이어집니다.

네트워크 허용량. 스토리지 요금제에서는 이 항목을 주의 깊게 읽어야 합니다. 복구할 수 없는 용량은 백업이 아닙니다. 월간 전송 허용량(TB)과 포트 속도(Gbit/s)를 확인하십시오. 1 Gbit/s 포트에서 4 TB를 완전히 복구하는 데는 회선 속도 기준으로 약 9시간이 걸리며, 포트를 공유하는 경우 훨씬 더 오래 걸립니다.

ChartTypical advertised disk cost per TB per month, August 2026
The data behind this chart
[
  {
    "plan": "Storage VPS, HDD",
    "usd_per_tb_month": 3
  },
  {
    "plan": "Storage VPS, SATA SSD",
    "usd_per_tb_month": 9
  },
  {
    "plan": "Standard VPS, NVMe",
    "usd_per_tb_month": 40
  },
  {
    "plan": "Block storage add-on",
    "usd_per_tb_month": 90
  }
]

위 수치는 2026년 8월 여러 공급업체의 공개 가격 페이지에서 가져온 반올림된 값이며, 특정 업체의 견적이 아니므로 변동될 수 있습니다. 중요한 것은 구조적 차이입니다. 스토리지 요금제의 테라바이트당 비용은 월 3 미국 달러 수준입니다. 표준 요금제의 동일한 NVMe 테라바이트 비용은 약 40이며, 네트워크 연결 블록 볼륨은 4개의 옵션 중 가장 비싼 90입니다. 월 청구 금액의 구성 요소에 대한 더 자세한 내용은 VPS의 실제 월간 비용을 참조하십시오.

TB당 가격과 코어당 가격이 반대로 움직이는 이유

스토리지 노드는 12개에서 16개의 대용량 디스크를 장착한 섀시에 소규모 프로세서 하나가 탑재된 형태입니다. 반면 컴퓨팅 노드는 다수의 코어, 대용량 RAM, 2개 또는 4개의 NVMe 드라이브를 갖춘 정반대의 구성을 가집니다. 제공업체는 해당 섀시에서 남는 자원을 판매합니다. 따라서 테라바이트당 가격이 저렴한 플랜은 코어당 가격이 비싸고, 코어당 가격이 저렴한 플랜은 테라바이트당 가격이 비싸집니다. 두 가지 모두 저렴한 플랜은 존재하지 않는데, 애초에 그런 식으로 설계된 섀시가 없기 때문입니다.

이것이 "어떤 것을 구매해야 합니까?"라는 질문에 대한 솔직한 답변이 종종 "둘 다"인 이유입니다. 애플리케이션을 구동하는 소규모 NVMe VPS와 백업을 저장하는 스토리지 VPS를 조합하는 것이, 두 작업을 모두 잘 수행할 만큼 큰 단일 장비를 사용하는 것보다 비용이 적게 듭니다. 한 대의 장비가 반드시 두 역할을 모두 수행해야 한다면, 이는 이미 VPS의 영역을 벗어난 것입니다. 전용 서버가 VPS보다 나은 경우를 참조하십시오.

랜덤 읽기는 저가형 디스크가 수행할 수 없는 작업입니다

ChartRandom 4k read figures by disk class, vendor datasheet order of magnitude
The data behind this chart
[
  {
    "disk": "7200 rpm SATA HDD",
    "random_read_iops": "180",
    "typical_latency_ms": 8.5
  },
  {
    "disk": "SATA SSD",
    "random_read_iops": "75,000",
    "typical_latency_ms": 0.2
  },
  {
    "disk": "NVMe SSD",
    "random_read_iops": "600,000",
    "typical_latency_ms": 0.08
  }
]

이 수치들은 특정 제공업체의 벤치마크가 아닌 데이터시트상의 등급입니다. 7200 rpm 디스크는 초당 약 180회의 4k 랜덤 읽기를 처리합니다. 헤드가 물리적으로 트랙으로 이동한 뒤 플래터가 해당 섹터를 헤드 아래로 가져올 때까지 기다려야 하며, 이 과정에서 매번 약 8.5 ms의 지연 시간이 발생하기 때문입니다. 플래시 메모리는 움직이는 부품이 없으므로 SATA SSD는 약 75,000 IOPS, NVMe 장치는 약 600,000 IOPS를 0.08 ms의 지연 시간으로 처리합니다. 이는 3천 배가 넘는 격차이며, RAM이나 CPU를 아무리 추가해도 이 차이를 극복할 수 없습니다.

순차적 작업은 완전히 다른 이야기이며, 이것이 바로 스토리지 플랜이 여전히 유용한 이유입니다. 단일 회전식 디스크도 150 MB/s에서 250 MB/s의 속도로 데이터를 전송하며, 디스크 어레이를 구성하면 더 높은 속도를 낼 수 있습니다. 이는 1 Gbit/s 포트의 대역폭을 가득 채우기에 충분하므로, 백업 업로드는 네트워크 최대 속도로 실행되며 디스크가 병목 현상을 일으키지 않습니다. 또한 스트라이핑을 통해 하나의 요청을 여러 디스크에 분산하므로 어레이 구성 방식에 따라 성능 수치가 달라집니다. RAID 10이 스토리지 플랜 성능을 변화시키는 방식에서 이 내용을 다룹니다.

VDS는 무엇을 의미합니까?

보통은 마케팅 용어입니다. 흔히 세 가지 의미로 사용되지만, 제공업체가 어떤 의미로 사용하는지 명확히 밝히는 경우는 드뭅니다. 일부 업체는 VDS를 고정된(pinned) 또는 전용 CPU 코어를 의미하는 용도로 사용하여, 다른 사용자가 고객의 CPU 자원을 점유하지 못하도록 합니다. 어떤 업체는 이를 KVM과 같은 완전 가상화(full virtualization)를 의미하는 용도로 사용하는데, 이는 호스트 커널을 공유하는 LXC나 OpenVZ 같은 컨테이너 가상화와 대비됩니다. 또 어떤 업체는 단순히 VPS보다 더 강력해 보이는 이름을 붙이기 위해 아무런 기술적 차이 없이 이 용어를 사용하기도 합니다.

서버 내부에서 일부 내용을 확인할 수 있습니다. systemd-detect-virt 명령은 완전 가상 머신에서는 kvm을 출력하고 컨테이너에서는 lxc을 출력합니다. 컨테이너 환경이라면 커널 모듈을 로드하거나 자체 커널을 실행할 수 없습니다. 전용 CPU라는 주장은 아래에 설명된 steal time 확인 방법을 통해 직접 측정해야 합니다. 요금제에 적힌 명칭은 참고용으로만 보고, 실제 사양 명세서를 계약의 기준으로 삼으십시오.

이름 대신 확인해야 할 사양 항목

  • 용량 옆에 표기된 단어: NVMe, SSD, SATA 또는 HDD. 페이지 어디에도 디스크 관련 단어가 없다면 해당 가격대에 맞는 가장 저렴한 하드웨어로 간주합니다.
  • 디스크가 노드 로컬 방식인지 네트워크 연결 방식인지 확인합니다. 네트워크 연결 스토리지는 모든 요청에 지연 시간을 추가하며 노드 장애 시에도 데이터가 유지됩니다. 로컬 디스크는 속도가 빠르지만 노드와 함께 소멸합니다.
  • CPU 표기: "dedicated" 또는 "pinned"인지, 아니면 "shared", "fair share" 또는 아무런 표기가 없는지 확인합니다.
  • 요금제에 명시된 IOPS 또는 MB/s 제한. 500 IOPS 제한이 있다면 디스크 유형은 사실상 의미가 없습니다.
  • 월간 전송 허용량 및 포트 속도. 이는 전체 복구에 걸리는 시간을 결정합니다.
  • 스냅샷, 백업 및 추가 IP 주소가 포함되어 있는지, 아니면 별도로 청구되는지 확인합니다.

실제로 할당받은 디스크 확인 방법

커널이 보고하는 내용에서 시작하되, 그 내용을 무조건 신뢰하지 마십시오.

lsblk -d -o NAME,ROTA,SIZE,MODEL
df -h /
nproc
free -h

ROTA 값은 회전식 장치일 경우 1, 플래시 장치일 경우 0입니다. VPS 환경에서는 이 값을 신뢰하지 마십시오. virtio 디스크는 하이퍼바이저가 범용 블록 장치를 제공하고 게스트가 물리 드라이브를 직접 볼 수 없으므로, 실제 하드웨어와 관계없이 보통 ROTA=0 값을 보고합니다. 같은 이유로 MODEL 항목은 비어 있습니다. 이 플래그는 랙에 장착된 실제 장치가 아니라 하이퍼바이저가 선언한 내용을 나타내므로, 직접 측정해야 합니다.

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

--direct=1 옵션은 페이지 캐시를 우회하므로 RAM이 아닌 디스크 성능을 측정합니다. 확인해야 할 줄은 read: IOPS=이며, 그 아래 clat percentiles (usec) 항목에서 분포를 확인할 수 있습니다. 표준 NVMe 플랜은 99번째 백분위수 지연 시간이 1밀리초 미만이며 수만 IOPS를 기록합니다. 회전식 저장 장치 플랜은 수백 IOPS를 기록하며 99번째 백분위수 지연 시간이 두 자릿수 밀리초 단위로 나타납니다. 만약 fio에서 libaio 엔진을 불러올 수 없다고 나오면 --ioengine=psync --iodepth=1를 사용하십시오. 이 엔진은 한 번에 하나의 요청만 처리하므로 더 낮은 수치가 나올 것입니다.

vmstat 1 5
sudo apt install -y sysstat
iostat -x 1 5

vmstat에서 st 열은 steal time을 나타냅니다. 이는 vCPU가 실행 준비를 마쳤음에도 호스트가 해당 사이클을 다른 게스트에게 할당하여 대기한 시간의 비율입니다. 이 수치가 5를 넘는 상태가 지속된다면 해당 노드는 오버서브스크립션(oversubscription) 상태이며, 이는 "전용 CPU"라는 주장을 검증하는 실제 지표가 됩니다. iostat -x에서는 %util, r_await, w_await 항목을 주시하십시오. %util 값이 100에 가깝고 w_await이 수십 밀리초 단위라면 디스크가 병목 현상의 원인이므로, 애플리케이션 튜닝으로는 문제를 해결할 수 없습니다. 플래시 전용 검사에 관한 자세한 내용은 NVMe 디스크가 실제로 NVMe인지 확인하기를 참조하십시오.

워크로드별 선택

  • restic, Borg 또는 rsync를 위한 백업 대상. 스토리지 VPS는 이 용도로 설계되었습니다. 쓰기 작업은 대용량 순차 방식으로 이루어지며, 중복 제거는 원본 머신에서 수행되므로 결과값을 기다릴 필요가 없습니다. 한 가지 주의할 점은 restic prunerestic check --read-data가 전체 저장소를 작은 조각으로 읽어 들인다는 것입니다. 따라서 충분한 시간을 할당하고 일정에 맞춰 실행하십시오. VPS로 restic 백업 실행하기를 참조하십시오.
  • Immich 또는 Jellyfin 미디어 라이브러리. 파일 저장을 위해 스토리지 VPS를 사용하되, CPU 성능에 유의해야 합니다. Immich는 가져오기 시 썸네일을 생성하고 머신러닝 작업을 수행하며, Jellyfin은 재생 시 트랜스코딩을 수행합니다. 2개의 공유 vCPU로는 200 GB의 사진을 처음 가져올 때 매우 느리게 작동할 것입니다. 데이터베이스와 썸네일 캐시는 서버에서 가장 빠른 디스크에 두십시오. Google Photos 대체제로 Immich 셀프 호스팅하기에서 적정 사양을 다룹니다.
  • PostgreSQL 또는 MySQL. 표준 NVMe 플랜을 사용하십시오. 모든 커밋은 트랜잭션이 반환되기 전에 영구 저장소에 도달해야 하는 fsync으로 끝나므로, 커밋 지연 시간은 곧 디스크 지연 시간입니다. 인덱스 조회는 회전식 디스크가 가장 취약한 8 kB 단위의 무작위 읽기 작업입니다.
  • 웹 애플리케이션, API 또는 컨트롤 플레인. 표준 플랜을 사용하십시오. 이들은 코어와 예측 가능한 지연 시간이 필요하며, 100 GB 이상의 용량이 필요한 경우는 드뭅니다.
  • CI 캐시 또는 아티팩트 저장소. 파일 크기에 따라 다릅니다. 대용량 tarball은 스토리지 플랜에서 전체 네트워크 속도로 스트리밍됩니다. 수십만 개의 작은 파일로 구성된 캐시를 여러 러너가 병렬로 가져오는 작업은 사실상 무작위 IO와 다름없으므로 성능이 기대에 미치지 못할 수 있습니다.

설정을 잘못했을 때 나타나는 현상

장애는 즉각적으로 발생하지 않습니다. 회전식 저장 장치(HDD) 기반의 데이터베이스는 사용자가 1명일 때는 정상적으로 작동하다가 10명이 넘어가면 붕괴합니다. RAM에서 처리되던 쿼리가 디스크로 넘어가면서 처리 시간이 마이크로초 단위에서 밀리초 단위로 늘어나기 때문입니다. 시스템 부하(load average)는 상승하지만 top 명령어를 확인해 보면 CPU는 대부분 유휴 상태이고 %wa 수치가 높게 나타납니다. 이는 프로세스가 연산을 수행하는 대신 디스크 응답을 기다리며 차단(blocked)되었음을 의미합니다. iostat -x 1 명령어를 실행하면 %util 항목이 100에 가깝게 고정된 것을 볼 수 있습니다.

PostgreSQL은 자체 로그에 이 문제를 명확히 기록합니다. 버전 15부터는 log_checkpoints 설정이 기본적으로 활성화되어 있기 때문입니다.

LOG:  checkpoint complete: wrote 8241 buffers (2.5%); ... write=112.402 s, sync=9.318 s, total=121.914 s

여기서 중요한 것은 sync= 수치입니다. 이는 체크포인트가 fsync의 응답을 기다리는 데 소요된 시간입니다. 따라서 이 값이 초 단위로 나타난다면 디스크가 데이터베이스의 쓰기 속도를 감당하지 못하고 있다는 뜻입니다. 쿼리 자체는 가볍더라도 이 대기 시간 동안 클라이언트 연결은 정지됩니다. 이 문제의 해결책은 설정을 변경하는 것이 아닙니다. 데이터 디렉터리를 NVMe로 이전하고, 기존 저장 장치는 데이터베이스 백업을 저장하는 용도로만 사용해야 합니다.

FAQ

스토리지 VPS가 일반 VPS보다 느립니까?

무작위 읽기 및 쓰기 작업의 경우, 큰 차이로 느립니다. HDD 기반 스토리지 플랜은 초당 수백 개의 작은 무작위 요청을 각각 약 8 ms의 속도로 처리하는 반면, NVMe 플랜은 1 ms 미만의 속도로 수만 개를 처리합니다. 순차 전송의 경우 스토리지 어레이도 150 MB/s 이상의 속도를 내어 1 Gbit/s 포트를 충분히 채울 수 있으므로 두 방식 간의 차이가 훨씬 적습니다. 결정을 내리기 전에 fio --rw=randread --bs=4k --direct=1을 사용하여 직접 측정해 보십시오.

스토리지 VPS에서 PostgreSQL을 실행할 수 있습니까?

실행은 가능하며, 작업 데이터 세트가 RAM에 들어가는 동안에는 정상적으로 작동합니다. 그 이후에는 모든 커밋이 느린 디스크의 fsync를 기다리게 되며, Postgres는 이를 checkpoint complete 내에 초 단위의 sync= 수치로 기록합니다. 이때 iostat -x 1를 확인하면 높은 w_await와 함께 %util이 100에 가깝게 나타납니다. 일반적으로는 데이터베이스용으로 작은 NVMe VPS를 사용하고, 덤프 저장용으로 스토리지 VPS를 사용하는 구성을 권장합니다.

VDS는 전용 하드웨어를 제공한다는 의미입니까?

확실하지 않습니다. VDS에는 표준화된 정의가 없습니다. 일부 제공업체는 CPU 코어를 고정할 때 이 용어를 사용하고, 일부는 공유 커널 컨테이너와 대비되는 완전한 KVM 가상화를 의미할 때 사용하며, 단순히 마케팅 명칭으로 사용하는 경우도 있습니다. systemd-detect-virt를 실행하여 kvm인지 lxc인지 확인하고, vmstat 1 5을 실행하여 st 열을 통해 다른 사용자가 CPU 자원을 점유하고 있는지 확인하십시오.

VPS 디스크가 실제로 NVMe인지 어떻게 확인합니까?

lsblk -d -o NAME,ROTA,MODEL은 신뢰하지 마십시오. 하드웨어 구성과 관계없이 virtio 디스크는 일반적으로 ROTA=0과 빈 모델 문자열을 보고하기 때문입니다. --direct=1을 사용하여 30초 동안 fio 무작위 읽기 테스트를 수행한 뒤, IOPS와 99번째 백분위수 지연 시간을 확인하십시오. 두 자릿수 밀리초 단위의 수백 IOPS라면 HDD 어레이입니다. 1 밀리초 미만의 수만 IOPS라면 플래시 스토리지입니다.