VPS 사양 산정 방법: CPU, RAM, 디스크, 대역폭

실제 워크로드에 맞춰 VPS의 사양을 최적화하는 실전 가이드입니다 — 실제 워크로드를 기준으로 vCPU, RAM, 디스크 종류/용량, 월 대역폭을 추정하는 방법과, 선택을 측정하고 검증하는 데 필요한 Linux 명령어를 함께 다룹니다.

VPS 사양 산정 방법: CPU, RAM, 디스크, 대역폭

VPS 요금제를 고르는 일은 균형 잡기입니다. 과도하게 할당하면 매달 놀고 있는 코어와 메모리에 비용을 지불하게 됩니다. 부족하게 할당하면 부하가 걸렸을 때 앱이 멈추거나, 디스크로 스왑하거나, 대역폭 할당량을 소진해 차단됩니다. 이 가이드는 실제 워크로드를 기준으로 각 리소스 — vCPU, RAM, 디스크, 대역폭 — 의 사양을 어떻게 산정할지 안내하고, 추측 대신 그 선택을 검증할 수 있는 Linux 명령어를 제공합니다.

공유 호스팅이나 다른 제공업체에서 마이그레이션하는 경우, 가장 신뢰할 수 있는 방법은 먼저 측정한 다음 그 수치를 요금제에 매핑하는 것입니다.

요금제가 아니라 워크로드부터 시작하세요

가격 페이지를 보기 전에, 서버가 실제로 무엇을 실행할지 적어두세요. 가장 흔한 네 가지 형태는 다음과 같습니다.

• 웹 앱 + 데이터베이스를 한 서버에서 운영(WordPress, Laravel, Node): CPU가 간헐적으로 치솟고, RAM은 보통 수준이며, 디스크는 읽기 위주입니다.
• 데이터베이스 서버: RAM을 많이 사용하며(워킹셋이 메모리에 들어가야 함), 디스크 IOPS가 가장 중요합니다.
• 백그라운드/배치 또는 빌드 워커: CPU를 지속적으로 사용하고, RAM은 예측 가능합니다.
• 정적/엣지 또는 프록시: CPU/RAM은 낮고, 대역폭이 실제 제약 요인입니다.

각 형태는 서로 다른 리소스에 부담을 줍니다. 가장 먼저 한계에 도달하는 리소스 — 즉 병목 — 에 맞춰 사양을 산정하고, 나머지에는 여유를 두세요.

CPU: vCPU는 물리 코어가 아닙니다

vCPU는 하이퍼바이저가 스케줄링하는, 공유된 물리 코어의 스레드입니다. 안정적인 워크로드에서는 전용 코어처럼 동작하고, 간헐적인 워크로드에서는 "공유" 요금제가 잠깐 기준선 이상으로 치솟도록 허용하는 반면, "전용 vCPU" 요금제는 상시 전체 접근을 보장합니다.

대략적인 기준:

• 소규모 WordPress 또는 비즈니스 사이트: 1~2 vCPU.
• 트래픽이 많은 CMS, 앱 서버, 또는 동시성이 중간 수준인 데이터베이스: 2~4 vCPU.
• CI 빌드, 영상 트랜스코딩, 또는 지속적인 연산: 공유가 아닌 전용 vCPU를 선택하세요.

기존 서버의 CPU 부하를 측정하기:

# 1분, 5분, 15분 부하 평균을 코어 수와 비교
uptime
nproc          # number of vCPUs available

# 코어별 사용률, 2초마다 갱신
mpstat -P ALL 2

5분 부하 평균이 nproc 개수를 지속적으로 초과하거나, mpstat의 %idle이 0에 가깝게 머문다면 CPU에 묶여 있는 것이므로 — 코어를 추가하세요. 부하가 코어 수보다 한참 아래에 머문다면 놀고 있는 vCPU에 비용을 지불하고 있는 것입니다.

RAM: 워킹셋에 맞춘 다음 여유를 두세요

RAM은 보통 가장 먼저 부딪히는 벽입니다. 목표는 애플리케이션의 핫 데이터와 OS 페이지 캐시를 메모리에 유지해, 서버가 읽기를 위해 디스크에 거의 접근하지 않도록 하는 것입니다.

무섭게 보이는 "총 사용량(total used)" 수치가 아니라 실제 사용량을 확인하세요:

free -h
# "free"가 아니라 "available" 열을 보세요.
# Linux는 남는 RAM을 버퍼/캐시에 사용하고 필요할 때 해제합니다.

실용적인 두 가지 원칙:

• 스왑을 주시하세요. 정상 부하에서 free -h에 스왑이 활발히 사용되는 것으로 나타난다면 RAM이 부족한 것이며, 막대한 지연(latency) 비용을 치르고 있는 것입니다.
• 서비스 사양을 적정하게 맞추세요. 잘못 설정된 MySQL innodb_buffer_pool_size나 너무 많은 PHP-FPM 워커는 요금제 크기와 무관하게 RAM을 고갈시킬 수 있습니다. 더 큰 서버를 구입하기 전에 앱을 튜닝하세요.

디스크: 용량과 속도는 별개의 두 결정입니다

두 가지 질문: 공간은 얼마나, 속도는 얼마나.

용량 — OS(약 3~10 GB), 애플리케이션, 데이터베이스, 로그, 업로드를 모두 합한 다음 성장 여지를 더하세요. 최소 20~30%는 여유로 확보하세요. 데이터베이스와 로그 로테이션은 디스크가 꽉 차면 제대로 동작하지 않습니다.

df -h          # 파일시스템별 사용/여유 공간
du -sh /var/* | sort -h   # 실제로 공간을 차지하는 것을 찾기

속도 — NVMe SSD를 선호하세요. Skyline Cloud VPS 요금제는 기본적으로 NVMe SSD를 사용합니다. 회전식 디스크는 물론 SATA SSD조차 데이터베이스에서는 병목이 됩니다. I/O에 묶여 있는지 확인하세요:

# %iowait가 높음 = CPU가 디스크를 기다리는 중
iostat -x 2

# 디스크 장치의 %util이 100%에 가까움 = I/O 포화 상태

iowait가 높은데 CPU %idle도 함께 높다면, 프로세서가 아니라 디스크가 한계인 것이며, 코어를 더 늘리는 것보다 더 빠른 스토리지(또는 캐싱을 위한 더 많은 RAM)가 더 도움이 됩니다.

대역폭: 할당량과 처리량

서로 다른 두 가지 수치가 "대역폭"이라고 불립니다.

1. 월 전송 할당량(예: 2 TB/월) — 인/아웃 총 데이터량. 이를 초과하면 속도가 제한되거나 초과분에 대해 요금이 청구됩니다.
2. 포트 속도 / 처리량(예: 1 Gbps) — 단일 전송이 얼마나 빠르게 이동할 수 있는지.

실제 트래픽으로 월 전송량을 추정하세요: 평균 페이지 용량 × 페이지뷰 × 약 1.3(재시도, 에셋, API 호출을 감안). 약 2 MB짜리 페이지를 월 100,000 뷰 제공하는 사이트는 아웃바운드로 대략 260 GB/월이 필요합니다 — 일반적인 1~2 TB 허용량 안에 충분히 들어가지만, 미디어나 다운로드가 많은 사이트는 이를 훌쩍 넘을 수 있습니다.

운영 중인 서버에서 현재 사용량을 확인하기:

# 설치 방법: apt install vnstat  (Debian/Ubuntu)
vnstat -m      # 월별 인/아웃 합계

사우디아라비아 및 GCC 내부의 사용자와 트래픽의 경우, 국내(in-Kingdom) 호스팅은 왕복 지연(latency)을 줄이고 데이터를 PDPL 및 NCA 요건의 적용 범위 안에 유지해 줍니다 — 이는 단순 용량만큼이나 위치에 관한 사양 결정이기도 합니다. 국내 옵션은 Skyline Cloud 호스팅과 VPS 및 클라우드 서버 허브를 참고하세요.

종합하기: 사양 산정 체크리스트

1. 워크로드 형태와 그것의 병목이 될 가능성이 높은 리소스를 파악하세요.
2. mpstat, free -h, iostat -x, vnstat로 기존 사용량을 측정하세요.
3. 병목 리소스는 약 30% 여유를 두고 산정하고, 나머지는 적정하게 맞추세요.
4. 지속적인 연산에는 NVMe 스토리지와 전용 vCPU를 선호하세요.
5. 나중에 확장(scale up)할 수 있는 요금제를 고르세요 — 가볍게 시작하고 지표가 알려줄 때 사양을 조정하세요.

클라우드 VPS의 가장 큰 장점은 사양이 영구적이지 않다는 점입니다. 보수적인 요금제로 시작해 위의 지표를 1~2주 관찰한 뒤, 불안감이 아니라 실제 데이터가 그렇게 말할 때 사양을 조정하세요. 메일도 함께 운영한다면 앱 서버에서 분리하세요. 전용 비즈니스 이메일 호스팅이 더 저렴하고, VPS 리소스를 애플리케이션에 온전히 쓸 수 있게 해줍니다.

시작하기

투명한 요금과 현지 아랍어 지원이 제공되는 NVMe 기반의 국내(in-Kingdom) VPS를 프로비저닝하고, 성장에 맞춰 언제든 사양을 조정하세요. Skyline Cloud 계정을 만들고 몇 분 만에 서버를 시작하세요.