용량 산정을 감으로 하면 안 되는 이유

시스템을 구축하거나 확장할 때 자원 규모를 정하는 방식은 크게 두 가지로 실패한다. 넉넉하게 잡으면 유휴 자원에 돈이 새고, 빠듯하게 잡으면 피크 시간에 응답이 늘어지거나 서비스가 죽는다. 용량 산정(Capacity Planning)은 이 사이에서 균형점을 찾기 위해 사용자 수, 트랜잭션 패턴, 데이터 증가율 같은 데이터를 근거로 필요한 자원을 정량적으로 예측하는 작업이다.

⤢✕

이 산정이 겨냥하는 목표는 응답 시간과 처리량 같은 성능 지표를 달성하는 것, 과다 투자를 막고 TCO(Total Cost of Ownership)를 최소화하는 것, 향후 증설 계획과 Scale-Up/Scale-Out 전략을 미리 세워 병목을 예방하는 것, 그리고 SLA를 지킬 수 있을 만큼의 장애 대응·백업 자원을 확보하는 것 네 가지로 모인다.

절차: 현황에서 시작해 수치로 끝난다

산정은 순서가 있다. 먼저 현재 하드웨어 사양, 소프트웨어 구성, 네트워크 토폴로지를 조사하고 CPU·메모리·디스크 사용률, 네트워크 트래픽, 응답 시간·처리량, 피크 타임 부하 패턴 같은 운영 데이터를 실측한다. 그다음 목표 사용자 수, 예상 트랜잭션 양, 데이터 증가율, 서비스 시간(24x7인지 업무 시간인지) 같은 비즈니스 요구사항과, 응답 시간 목표(예: 2초 이내)나 가용성 목표(예: 99.9%) 같은 비기능 요구사항을 정리한다. 이어서 동시 접속자 수, 평균·피크 트래픽, 계절성과 이벤트 영향, YoY 증가 추세를 분석해 부하를 예측하고, 트랜잭션 유형별 빈도와 자원 소비량, 쿼리 복잡도, 배치 작업 부하까지 따져본다.

⤢✕

마지막 자원 산정 단계에서는 실제로 공식을 쓴다. CPU 코어 수는 피크 TPS에 트랜잭션당 CPU 시간을 곱한 값을 CPU 활용률 목표로 나눠 구하고, 메모리 용량은 동시 사용자 수에 사용자당 메모리를 곱한 값에 OS·미들웨어 오버헤드를 더하며, 스토리지 용량은 현재 데이터에 증가율×기간을 더하고 여유 공간을 얹는다. 이렇게 계산된 값에는 보통 20~30%의 여유율(Margin)을 추가로 잡는데, 클라우드 환경이라면 Auto Scaling이 뒷받침되므로 여유율을 낮춰도 되고, 온프레미스는 확장이 어려운 만큼 여유율을 높게 잡는 게 안전하다.

무엇을 산정하는가

서버는 CPU(코어 수, 클럭 속도, Intel Xeon·AMD EPYC 같은 모델, 멀티프로세서 구성), 메모리(용량, DDR4·DDR5 속도, ECC 여부, 확장 슬롯 수), 그리고 웹·WAS·DB·캐시 서버별 대수를 따진다. 네트워크 대역폭은 동시 사용자 수와 평균 데이터 전송량, 파일 전송 크기, API 호출 빈도, 영상·이미지 스트리밍량을 근거로 계산한다.

필요 대역폭(Mbps) = (동시 사용자 × 평균 데이터 전송량) / 평균 세션 시간

스위치 포트 속도(1Gbps, 10Gbps), 방화벽 처리 용량, 로드밸런서 성능 같은 네트워크 장비 사양도 함께 정해야 한다.

스토리지는 데이터베이스 데이터, 업로드 파일과 로그 같은 파일 시스템, 백업, 아카이브까지 항목별로 산정한다. IOPS(Input/Output Operations Per Second)는 데이터베이스 성능에 직결되는데, SSD가 10,000~~100,000 IOPS인 데 비해 HDD는 100~~200 IOPS 수준이라 워크로드에 따라 DAS·NAS·SAN·클라우드 스토리지(S3, EBS) 중 어떤 유형을 쓸지가 갈린다. 데이터베이스 용량은 레코드 수에 평균 레코드 크기와 증가율을 곱해 테이블 크기를 구하고, 인덱스는 보통 데이터의 10~30% 수준으로 인덱스 수에 비례해 늘어나며, 트랜잭션 로그는 변경 데이터량과 백업 주기에 따라 크기가 결정된다.

테이블 크기 = 레코드 수 × 평균 레코드 크기 × 증가율

방법론: 빠른 것과 정확한 것은 다르다

경험 기반 산정은 유사 프로젝트나 업계 표준 벤치마크, 벤더 권고 사양을 참조하는 방식이라 빠르고 실무 경험이 반영되지만, 정확도가 낮고 새로운 기술에는 적용하기 어렵다. 벤치마크 기반 산정은 TPC, SPECint·SPECfp, Sysbench 같은 표준 벤치마크로 유사 환경을 구성해 목표 부하를 걸고 성능을 측정한 뒤 실제 환경 규모로 스케일링하는 방식이다.

수학적 모델링은 대기 이론(Queueing Theory)을 쓴다. M/M/1, M/M/c 같은 모델과 Little's Law(L = λW, 평균 큐 길이는 도착률과 평균 대기 시간의 곱)로 응답 시간을 계산할 수 있고, 다음 공식은 활용률이 어떻게 응답 시간을 밀어 올리는지를 보여준다.

Response Time = Service Time / (1 - Utilization)

이 식에서 Utilization이 커질수록 분모가 0에 가까워지며 응답 시간이 급격히 증가한다. 그래서 실무에서는 일반적으로 70~80% 활용률을 상한선으로 잡는다. 시뮬레이션은 JMeter·Gatling 같은 부하 테스트 도구나 NS-3 같은 네트워크 시뮬레이터, 용량 계획 소프트웨어로 다양한 시나리오를 테스트해 병목 지점을 찾고 최적 구성을 탐색하는 방법이다.

산정 결과를 검증하는 지표들

CPU는 평균 사용률 5070%, 피크 사용률 80% 이하를 목표로 삼고, Load Average는 코어 수보다 낮아야 정상이다(예: 4코어 시스템이라면 Load 4.0 미만). 메모리는 스왑 사용을 최소화하는 게 관건이고, 시간에 따라 사용량이 계속 늘어나는 패턴이 있다면 메모리 누수를 의심해야 한다. 디스크는 IOPS와 Throughput(MB/s), Latency(SSD 0.1ms, HDD 10ms 수준)를 함께 보고, 네트워크는 대역폭 사용률과 패킷 손실률(정상 0.1% 이하), RTT(국내 1030ms, 해외 100~300ms)를 확인한다.

온프레미스와 클라우드는 산정 논리가 다르다

온프레미스는 한번 사양을 정하면 확장이 어려우니 사전 산정의 무게가 크고 여유율도 30~~50%로 넉넉히 잡으며 초기 투자 비용도 높다. 클라우드는 반대로 유연하게 확장할 수 있어 여유율을 10~~20%까지 낮추고 종량제로 탄력적인 용량을 운영한다. Auto Scaling을 산정에 넣는다면 수평 확장은 CPU·메모리 사용률 기반 자동 확장이나 트래픽 패턴에 따른 스케줄 기반 확장, 최소·최대 인스턴스 수 설정으로 다루고, 수직 확장은 인스턴스 타입 변경과 그에 따른 다운타임을 감안해야 한다. 야간·주말에는 인스턴스를 축소하고 피크 시간에만 자동 확장하며, Reserved Instance로 기본 부하를 처리하는 조합이 비용 최적화의 기본 패턴이다.

인스턴스 타입도 범용(t3, m5), 컴퓨팅 최적화(c5), 메모리 최적화(r5), 스토리지 최적화(i3) 중 워크로드에 맞는 걸 고르는 Right Sizing이 필요하고, 요금 모델은 시간당 과금인 On-Demand, 1~3년 계약에 최대 75% 할인되는 Reserved, 경매 방식으로 최대 90% 할인되는 Spot 중에 선택한다. CapEx(자본 지출, 온프레미스 구매)와 OpEx(운영 비용, 클라우드 구독)의 차이도 결국 이 산정 방식의 차이에서 갈라진다.

산정을 뒷받침하는 도구

산정은 감이 아니라 실측 데이터로 검증해야 하고, 여기에 쓰는 도구도 역할이 나뉜다. 시스템 모니터링은 Prometheus + Grafana, Nagios, Zabbix, Datadog이, 애플리케이션 성능은 New Relic, Dynatrace, AppDynamics, Elastic APM 같은 APM 도구가 맡는다. 부하 테스트는 웹 애플리케이션이라면 Apache JMeter, Gatling, Locust, K6를, 데이터베이스라면 Sysbench(MySQL), pgbench(PostgreSQL), YCSB(NoSQL)를 쓴다. 산정 자체를 돕는 도구로는 BMC Capacity Optimization, IBM Planning Analytics, TeamQuest 같은 전문 소프트웨어부터 엑셀 기반 자체 개발까지 다양하고, 클라우드 환경이라면 AWS·Azure·Google Cloud 각각의 Pricing Calculator로 비용을 미리 가늠해볼 수 있다.

결국 용량 산정은 한 번의 계산으로 끝나는 일이 아니다. 현황을 실측하고, 공식으로 초기 규모를 잡고, 벤치마크나 시뮬레이션으로 검증한 뒤, 모니터링 데이터로 다시 조정하는 순환을 반복하는 과정에 가깝다.