2025년에 서버와 VPS에 실제로 필요한 RAM 용량은 얼마일까요?

RAM 용량 산정은 워크로드 계산이며, 벤치마크가 아닙니다. 과도하게 투자하면 유휴 용량에 대한 비용을 지불하게 됩니다. 용량이 부족하면 프로세스가 강제 종료되거나, 데이터베이스가 메모리 대신 디스크에서 데이터를 제공하거나, 컨테이너의 성능이 제한될 수 있습니다. 이 가이드에서는 가장 흔히 접하는 워크로드(웹 호스팅, 데이터베이스, 가상화, 컨테이너, AI 추론, 게임 서버)에 대한 구체적인 RAM 범위를 제시하며, 목록에 없는 워크로드의 용량을 산정할 때 적용해야 할 규칙도 함께 설명합니다.

서버에서 RAM의 역할

RAM은 서버가 현재 활발히 처리 중인 모든 작업을 저장합니다. 웹 서버, 데이터베이스 엔진, 백그라운드 데몬을 위한 프로세스 메모리, OS 수준의 페이지 캐시 및 디스크 I/O 버퍼, 애플리케이션과 컨테이너를 위한 런타임 메모리, 그리고 가상 머신이나 컨테이너 워크로드에 할당된 메모리 블록 등이 여기에 포함됩니다.

RAM 용량 산정이 CPU 용량 산정과 다른 점은 장애 발생 방식입니다. CPU 용량이 부족해지면 프로세스 속도가 느려집니다. RAM 용량이 부족해지면 커널이 스왑(속도 저하)을 수행하거나, OOM 킬러가 대상 프로세스를 선택해 종료시킵니다. 전자는 불편함을 유발합니다. 후자의 경우 데이터가 손실됩니다. 여유분을 두고 RAM을 프로비저닝하는 것은 단순히 ‘있으면 좋은’ 것이 아니라, 부하가 가해졌을 때 시스템이 완전히 무너지는 것을 막아주는 필수적인 조치입니다.

워크로드별 RAM

웹 및 애플리케이션 서버

• 경량 LAMP 또는 LEMP 스택: 1~2 GB
• 캐싱(예: Redis)이 적용된 WordPress 또는 CMS: 2~4 GB
• 전자상거래(Magento, WooCommerce): 4~8 GB
• Node.js, Django 또는 Rails 애플리케이션: 2~6 GB

Redis나 Varnish와 같은 캐싱 계층은 애플리케이션 기본 메모리 용량에 더해 별도의 RAM이 필요합니다. PHP-FPM 워커, 데이터베이스 연결, 리버스 프록시는 모두 동시에 메모리를 소비하므로, 중요한 수치는 유휴 상태의 메모리 사용량이 아니라 피크 병렬 처리량입니다.

데이터베이스 서버(SQL 및 NoSQL)

• MySQL 또는 PostgreSQL(소규모): 4~8 GB
• MySQL 또는 PostgreSQL(대규모 또는 트래픽이 많은 경우): 16~64 GB
• MongoDB 또는 Redis(인메모리 중심): 32~128 GB 이상
• Elasticsearch 또는 OpenSearch 노드: 노드당 32~128 GB

목표는 작업 세트, 인덱스 및 자주 액세스되는 행을 RAM에 유지하는 것입니다. 이 중 하나라도 디스크로 넘겨지면, SSD가 아무리 빠르더라도 지연 시간이 기하급수적으로 증가합니다.

가상화 호스트(Proxmox, VMware, Hyper-V)

• 경량 리눅스 VM: VM당 2~4 GB
• Windows 가상 머신: 가상 머신당 8~12 GB
• 호스팅 패널(cPanel, Plesk, DirectAdmin): 인스턴스당 4~8 GB
• KVM 또는 LXC 컨테이너 호스트: 32~128 GB 이상

게스트 할당량 외에도 호스트 OS 자체를 위해 항상 4~8 GB를 예약해 두십시오. 컨테이너는 전체 VM보다 워크로드당 RAM 사용량이 적지만 확장 방식이 다르므로, 컨테이너당 크기보다는 밀도와 버스트 여유 공간을 고려하여 계획하십시오. 호스트가 ZFS를 사용하는 경우, ARC도 고려해야 합니다. ARC는 기본적으로 시스템 RAM의 최대 절반까지 자동으로 차지하며 게스트 할당량과 경쟁 관계를 형성합니다(당사의 ZFS ARC 튜닝 가이드에는 하이퍼바이저 워크로드에 적합한 상한값이 설명되어 있습니다).

컨테이너 및 마이크로서비스(Docker, Kubernetes)

• 간단한 Docker 스택(웹, 앱, DB): 8~16 GB
• Docker Swarm 또는 K3s 에지 노드: 16~32 GB
• Kubernetes 워커 노드: 32~128 GB
• CI/CD 러너 및 빌드 에이전트(GitLab, Jenkins): 러너당 8~32 GB

장시간 실행되는 컨테이너에서는 메모리 누수를 주의 깊게 관찰해야 합니다. Kafka나 Elasticsearch와 같은 JVM 기반 워크로드는 힙 크기가 허용하는 대로 무제한으로 증가하기 때문에 더 높은 기준 메모리 용량이 필요하며, 이는 종종 예상보다 더 큰 용량을 차지하게 됩니다.

AI 및 ML 추론

• 소형 모델(양자화된 BERT, Llama 7B): 16~32 GB
• 중형 모델(13B~30B, 양자화): 64~128 GB
• 대형 모델(40B+ 또는 비양자화 중형 모델): 128~512 GB 이상
• GPU 기반 추론(Stable Diffusion, Whisper): 오프로드 방식에 따라 32~128 GB

양자화는 메모리 부하를 GPU에서 CPU RAM으로 전환시키므로, GPU에서 fp16을 처리하느냐 CPU에서 4비트를 처리하느냐에 따라 시스템 사양이 크게 달라집니다. 배치 크기와 프롬프트 길이 또한 필요한 메모리 용량을 증가시킵니다. AI 추론 호스팅 가이드에서는 모델 크기에 맞는 하드웨어 선택에 대해 더 자세히 다루고 있습니다.

게임 서버

• 마인크래프트(바닐라): 2~4 GB
• 마인크래프트(모드 적용): 6~16 GB
• Rust, ARK 또는 7 Days to Die: 8~16 GB
• 다중 인스턴스 호스팅 노드: 32~64 GB

전문 워크로드

• 비디오 트랜스코딩 (FFmpeg, Plex): 16~64 GB
• 백업 또는 스냅샷 서버: 8~16 GB, 중복 제거 엔진을 실행하는 경우 더 많은 용량 필요
• 방화벽 또는 IDS(pfSense, Suricata): 2~8 GB, NetFlow 또는 전체 패킷 로깅의 경우 더 필요

스왑 메모리에 의존하지 마십시오

스왑은 RAM보다 10~100배 더 느립니다. 스왑은 메모리 부하가 급증할 때 커널이 임시로 사용할 수 있는 공간을 제공하기 위한 안전망일 뿐, 사용 가능한 메모리를 확장하기 위한 수단이 아닙니다. 정상적인 부하 상태에서 서버가 스왑을 사용한다면, 이는 메모리 할당이 부족하다는 뜻이며, 그 이상도 이하도 아닙니다. '리눅스 스왑, OOM 킬러, cgroups의 상호작용' 문서는 이러한 오류 모드를 상세히 다룹니다.

RAM 용량을 정확하게 산정하는 방법

1. 평균이 아닌 피크 값을 측정하십시오. htop, free -m, vmstat 1또는 쿠버네티스 메트릭을 활용하여 전체 트래픽 주기 동안의 피크 사용량을 파악하십시오. 일일 피크, 주간 배치, 월간 청구 주기 등이 모두 중요합니다.
2. 성장을 위한 여유 공간을 확보하세요. 애플리케이션 확장을 위해 20%에서 50%를 추가하세요. 데이터베이스의 경우, 요청 빈도가 아닌 데이터 세트 크기에 따라 메모리를 확장하세요. 멀티테넌트 플랫폼의 경우, 클라이언트당 리소스 사용량을 계산한 후 곱하세요.
3. 용납할 수 있는 장애 모드를 고려하여 계획하십시오. RAM이 부족한 읽기 레플리카는 성능이 저하됩니다. RAM이 부족한 데이터베이스 프라이머리는 쿼리를 손상시키고, 이로 인해 애플리케이션까지 중단될 수 있습니다. 영향 범위가 가장 넓은 곳에 RAM을 할당하십시오.

RAM은 용량이 부족할 때 과잉보다 더 큰 피해를 주는 사양입니다. 메모리를 추가한다고 해서 CPU에 부하가 집중된 애플리케이션의 속도가 빨라지지는 않지만, 용량이 너무 부족하면 안정성이 무너집니다. 실제 모니터링 데이터와 테스트를 통해 확인된 피크 부하를 바탕으로 용량을 산정한 후, 여유를 두십시오.

FDC는 여러 리전에 걸쳐 대용량 RAM 구성과 무제한 대역폭을 갖춘 전용 서버 및 VPS를 제공합니다.