시스템이 느려진다. 서버를 *키울지 / 서버를 *늘릴지** 가 첫 결정이다. 단순해 보이지만 — *어떤 자원 이 병목인지에 따라 답이 다르다. 같은 느림 도 CPU 가 부족한 느림 과 메모리 가 부족한 느림 은 해결 방향이 정반대.

TL;DR — 한 장 요약

자원 수직 (Scale Up) 수평 (Scale Out)
CPU 응답시간 ↓ 빠름 — single-thread 강화 처리량 ↑ 빠름 — 동시 요청 ↑, 응답시간 큰 변화 없음
Memory GC pause / cache 효율 ↑ 분산 캐시 (Redis Cluster) 가 실용적, 단 latency ↑
HDD RAID, 큰 단위 sequential 좋아짐 샤딩 — 거의 유일한 답 (random IOPS 합산)
SSD NVMe / RAID0 — 응답시간 ↓ 분산 storage (S3, Ceph) — 내구성/처리량, 응답시간 조금 ↑

수직 = 각 응답이 *덜 기다림** (응답시간). 수평 = *같은 시간에 *더 많은 응답 (처리량).

이 기본 명제 가 4 자원에 *어떻게 *다르게 적용되는지가 이 글의 주제.

1. 수직 확장 과 수평 확장 — 정의

수직 확장 (Scale Up / Vertical) : 한 서버를 *더 크게. 더 빠른 CPU, 더 큰 RAM, 더 빠른 SSD — 하나의 머신 안에서 자원 ↑.

수평 확장 (Scale Out / Horizontal) : 같은 사양의 서버를 *여러 대. 부하 분산기 (Load Balancer) 로 트래픽 분배.

차이의 핵심 :

  • 수직 — 애플리케이션 코드 변경 없음. 그저 서버 갈아 끼움. 상한선 존재 (시중 최대 사양).
  • 수평 — 상태 (state) 의 처리가 까다로움. 세션 / 캐시 / DB 의 분산 이 새 과제. 이론상 *무한 확장.

2. 처리량 vs 응답시간 의 짧은 복습

두 지표 :

  • 처리량 (Throughput) : 단위 시간당 처리하는 요청 수. (RPS)
  • 응답시간 (Latency) : 한 요청의 왕복 시간. (ms)

이 둘은 독립 이다. 처리량 만 늘리는 최적화가 응답시간 을 악화 시킬 수 있다. 반대도 마찬가지.

핵심 원리 :

*수직 = 응답시간 개선에 *유리** 한 경향. *수평 = 처리량 개선에 *유리** 한 경향.

이게 기본 직관. 다만 자원에 따라 예외 가 많다.

3. CPU — Clock + IPC + Core 수

수직 확장 (Scale Up)

고성능 CPU 를 박는다. Clock 3.5GHz → 5.0GHz, 코어 8 → 32.

  • 단일 요청의 복잡한 연산 (JSON 직렬화, 암호화, 압축, 이미지 처리) → 응답시간 직접 개선
  • 동기 / 순차 작업 의 성능 ↑
  • 컴파일 / ML inference / 분석 쿼리 — 한 CPU 가 깊이 일하는 일 — 큰 단일 코어가 *훨씬 빠름

수평 확장 (Scale Out)

동일 서버 N 대 + 로드밸런서.

  • 총 처리 가능 RPS 가 N 배
  • 단 한 요청의 *내부 처리 시간 은 그대로 — 응답시간 변화 없음
  • 동시 사용자 ↑ 의 피크 대응 에 결정적

백엔드 의사결정

CPU bound workload (이미지 처리, ML, 암호화) → *수직 우선*
I/O bound workload (DB / API 호출 위주)      → *수평 우선*
혼합 (대부분 웹 API)                          → *수평 으로 *시작*, 한계 시 수직

Amdahl’s Law — 무한 수평 확장 불가

전체 작업의 *80% 가 병렬화 가능 한데 20% 가 *직렬 이면 — 코어 무한대 라도 최대 5 배 만 빨라진다. 직렬 부분을 *줄이는 게 수평 확장 의 진짜 효과적 *전제 다.

수평 확장의 *효과 는 코어 수 가 아니라 직렬 비율 감소 가 결정한다*.

4. Memory — RAM 의 *역설

수직 확장

RAM 8GB → 64GB.

  • cache 더 많이 → DB / 디스크 액세스 ↓ → 응답시간 ↓
  • 큰 데이터 in-memory 처리 가능 (ETL, 집계, BI)
  • 그러나 — JVM heap 30GB 넘으면 *GC pause 폭증. Stop-the-world 가 수초 단위로 길어질 수 있음.
  • RAM 의 *수직 확장 의 *비용 도 기하급수 적

수평 확장

분산 캐시 (Redis Cluster, Memcached + sharding).

  • 총 캐시 크기 가 서버 N 대 합산
  • 한 노드 fail 해도 부분 동작
  • 과제 :
    • 분산 캐시 접근 은 네트워크 hop 추가 → 응답시간 +0.5ms ~ +2ms
    • 데이터 일관성 / TTL / invalidation 이 복잡
    • consistent hashing 의 필요

*수직 + 수평 의 *조합** — 흔한 패턴

앱 서버 RAM   : 작게 (2~4GB)              ← 수직 확장 안 함, 수평 확장
캐시 노드 RAM : 크게 (64~256GB)            ← 수직 확장 함
DB 마스터 RAM : 크게 (64GB+)               ← 수직 확장
DB replica    : 마스터와 동일 사양         ← *수평 확장 (replica 추가)*

Memory 는 수직 확장의 *가성비가 *가장 *빨리 떨어지는** 자원. *32GB 면 충분한 데 *128GB 를 박는* 건 낭비 가능성.

5. HDD — 수평 확장이 *거의 유일한 답

HDD 의 물리적 한계

  • Random IOPS 가 *100~200 으로 고정됨 (head 가 물리 이동 필요)
  • Sequential 처리량 은 비교적 좋음 (100~200MB/s)
  • Cache, DDR, 회로 의 영향 이 극히 제한

수직 확장

15K RPM HDD / RAID 0 / 10 구성. 효과는 *제한.

  • RAID 0 : 2개 disk → 처리량 ~ 2배, random IOPS ~ 2배 (4 disk 면 4배). 단 redundancy 0 → 위험.
  • RAID 10 : 안전 + 성능. 비용 2배.
  • 단일 노드 random IOPS 의 *상한 이 수백 ~ 천 단위. DB 로 *부족.

수평 확장 — 샤딩 / 분산

여러 HDD 노드에 데이터 분할 저장. 각 노드가 자기 슬라이스만 처리.

  • 총 IOPS = 노드 합산 (선형)
  • cross-shard 쿼리 는 복잡
  • 대규모 데이터 분석 / 콜드 스토리지 에서 이 방식이 표준 (HDFS, S3 표준 클래스)

백엔드 의사결정

2026 년 현재 — HDD 를 *온라인 DB 에 *쓰면 안 된다. 백업 / 콜드 스토리지 외엔 NVMe SSD 가 *기본.

본인 cluster 운영 경험 — ES (Elasticsearch) 를 HDD 에 깐 적 있고 심각하게 느렸다. NVMe 로 옮기자 문제 사라짐. 같은 비용으로 *2 배 비싼 NVMe 가 *10 배 빠른 비대칭.

6. SSD — NVMe 의 *수직 가성비

수직 확장

  • SATA SSD (500 µs) → NVMe (50~100 µs) : 5~10 배 응답시간 ↓
  • consumer NVMe (10만 IOPS) → enterprise NVMe (100만 IOPS) : 10 배
  • RAID 0 NVMe 2 개 : 응답시간 동일, 처리량 2 배
  • 수직 확장의 *효과가 *큰 자원

수평 확장 — 분산 스토리지

  • S3 / Ceph / Longhorn / Rook — 내구성 + 무한 확장
  • 응답시간은 *50µs → 5ms (네트워크 hop 포함) — 100 배 느려짐
  • 큰 정적 자산 / 로그 / 백업 에 적합. DB 의 *데이터 디스크 엔 부적합

수직 + 수평 조합 — 표준 아키텍처

DB 데이터 디스크      : NVMe 단일 노드 (수직)        → 응답시간 ↓
DB 백업 / WAL 아카이브: S3 (수평)                    → 내구성 ↑
정적 자산 (이미지 등) : S3 + CDN (수평 + edge)      → 글로벌
로그 / 메트릭        : ES / Loki + S3 (혼합)        → 검색 + 보관

SSD 는 수직 확장의 *가성비가 가장 좋은 자원. NVMe 1 개로 *HDD 100 개 와 같은 성능*.

7. 처리량 vs 응답시간 *기준 의 4 자원 정리

응답시간을 *우선 으로 개선 하고 싶다면

자원 권장
CPU 수직 (높은 single-thread 성능)
Memory 수직 (in-process cache 크게)
HDD NVMe 로 바꿈 (수직의 극단적 형태)
SSD NVMe + 직결 디스크 (분산 X)

→ 모놀리식 / 단일 노드 강화 의 방향.

처리량을 *우선 으로 개선 하고 싶다면

자원 권장
CPU 수평 (앱 인스턴스 N 배)
Memory 수평 (분산 캐시)
HDD 수평 (샤딩 — 거의 유일 답)
SSD 수평 (분산 스토리지) + 일부 노드 수직

→ 마이크로서비스 / 분산 시스템 의 방향.

둘 다 원할 때

앱 계층      : *수평* (트래픽 흡수)
캐시 계층    : *수평 + 노드별 수직* (큰 캐시 + 분산)
DB 계층      : *마스터 수직 / read replica 수평*
스토리지     : *Hot 데이터 NVMe 수직 / Cold S3 수평*

이게 현대 백엔드의 *기본 패턴. Netflix, AWS, 구글 의 기본 발상 도 같다.

8. 현실의 *의사결정 — 비용 / 운영 / 복잡도

이론은 위와 같다. 그러나 현실 에선 비용과 운영 이 핵심 :

수직 확장의 진짜 장점

  • 애플리케이션 코드 변경 없음 — 그대로 옮기면 됨
  • 운영 단순 — 1 대만 관리
  • 장애 범위 제한 — 분산 락 / 일관성 문제 없음
  • *작은 팀에 *유리** — 인력 비용 절감

수평 확장의 진짜 단점

  • *분산 시스템의 *모든 함정** — CAP, partition, split-brain, race condition
  • 디버깅 *난도 ↑ — 한 요청이 여러 노드 거침
  • 세션 / 캐시 / 트랜잭션 의 분산 처리 가 새 코드 비용
  • 모니터링 / 로깅 인프라 필수 — 안 그러면 디버깅 불가능

경험상 권장 (7년차 본인 시각)

1. *처음엔 수직 으로 시작*. *복잡도 부족* 이 *돈 부족* 보다 *더 큰 위험*.
2. *수직 의 *상한* 도달 후* — 그제야 *수평 으로*.
3. *수평 으로 갈 때 — *애초에 *상태 없는 *(stateless)* 설계* 가 *전제*.
4. *수평 확장의 *효과를 *측정* 안 하면 — *무의미* 한 *비용 증가*.

본인이 운영하는 5 노드 K3s 클러스터 — 수평 확장 의 *교과서 적용. 단 각 노드 는 적정 사양으로 *수직 확장 도 함. 둘의 *조합 이 현실의 답.

9. 흔한 함정 5 가지

  1. “수평 확장 하면 무조건 빨라진다“ — 직렬 병목 (Amdahl) 이 있으면 효과 0.
  2. “수직 확장이 비싸다“ — 코드 변경 비용 + 운영 복잡도 와 비교하면 수직이 더 싼 경우도 흔하다.
  3. “GC pause 가 수평 으로 해결“ — 작은 RAM 의 *여러 노드 가 큰 RAM 의 한 노드 보다 GC 부담 적음. 단 분산 시스템 비용 새로 발생.
  4. “DB 는 수평이 항상 답“ — 읽기 수평 은 쉬움. 쓰기 수평 (샤딩) 은 난도가 *훨씬 *높다. 대부분 시스템은 *읽기 수평 + 쓰기 수직 으로 충분*.
  5. “클라우드 = 수평 확장” — 클라우드의 *자동 스케일 도 수직 확장 한계 의 *반영. EC2 의 *큰 인스턴스 가 수직 확장의 *클라우드 형태.

10. *수직 + 수평 의 *언제 만나야 하는가**

대부분 시스템은 수직과 수평을 *동시에 쓴다. *전환점 의 신호 :

수직 → 수평 으로 넘어가야 할 *신호

  • 단일 노드 의 사양 이 시장 최상위 에 근접
  • DB / 캐시 / 처리 가 한 노드 메모리 를 넘어감
  • 팀 / 운영 인력 이 분산 시스템 운영 능력 보유
  • 비즈니스의 *지역 분산 요구 (글로벌)
  • 장애 격리 (blast radius 제한) 요구

수평 → 수직 으로 되돌아갈 *신호 (덜 흔하지만 있다)

  • 분산 운영 비용 (인력 + 모니터링) 이 *하드웨어 비용 *초과
  • 데이터 일관성 / 트랜잭션 요구 가 *분산 의 *너무 큰 비용
  • 팀이 작아짐 — 모놀리식 으로 *되돌아가는 게 *총체적으로 *싸다

완벽한 답 은 없다. 팀 / 비즈니스 / 트래픽 에 따라 주기적으로 *전환을 *고민하는 것 이 현실의 *건강한 자세.

11. 마치며 — 4 자원의 *서로 다른 *수직 / 수평 의 결

CPU 는 수평 으로 *기우는 경향. 메모리 는 수직 + 수평 의 *복잡한 조합. HDD 는 수평 거의 *유일 답. SSD 는 수직 의 *가성비 *최강.

각 자원이 다른 결 을 가진다는 것 — 모르면 *모든 자원에 *같은 처방 을 쓰게 된다. 그게 흔한 실수.

7년 운영 경험에서 가장 자주 본 *비효율 :

  • CPU 부족인데 *수평 확장 만 함 — 직렬 병목 이 해결 안 됨
  • 메모리 부족인데 *수직 확장 만 함 — GC 비용 폭증
  • HDD 인데 *수평 확장 만 — 각 노드도 *느려서 *전체 도 느림
  • SSD 단일 노드면 충분한데 *분산 스토리지 도입 — 응답시간 100배 증가

각 자원에 맞는 처방 — 진단이 *처방에 *선행. 이 한 줄이 7년 회고의 *총정리.

다음 시스템 설계 회의 — 지금 우리 시스템의 *각 자원의 *수직 / 수평 비중 을 4 분면 표로 그려보라. 어디가 *수직 으로 쏠려있고, 어디가 *수평 으로 쏠려있는지 — 그림 한 장 으로 팀의 *공통 인식 이 맞춰진다.

→ 다음 글 — 분산 시스템 의 *CAP 정리 와 상태 (state) 의 흩어짐 의 비용 에 대해. 같은 시리즈로.

본 글은 7년차 백엔드 운영 회고. 모든 권장이 *정답 은 아니다. *시스템 / 트래픽 / 팀 에 따라 답이 달라진다. 본인의 5 노드 K3s 클러스터 운영 의 실측 경험 을 원리 위주로 정리.