Scale-Up이냐 Scale-Out이냐, 결정은 데이터베이스에서 갈린다
수직 확장과 수평 확장의 장단점을 비교하고, 웹 서버·데이터베이스·마이크로서비스 각각에 어떤 전략이 맞는지, 하이브리드 접근은 어떻게 조합하는지 정리한다.
2026-08-12 · 최초 발행 2026-01-02
시스템 용량이 부족해지면 선택지는 두 가지뿐이다. 지금 있는 서버의 사양을 올리거나(Scale-Up), 같은 사양의 서버를 더 붙이거나(Scale-Out). 두 방식은 겉보기엔 같은 목표를 향하지만 실제로는 완전히 다른 제약과 위험을 갖고 있어서, 어느 쪽을 고르느냐가 이후 아키텍처 전체의 방향을 정해버린다.
Scale-Up: 빠르지만 상한이 있다
Scale-Up은 CPU 코어 수를 4에서 8, 16으로 늘리거나 메모리를 16GB에서 64GB, 256GB로 올리고, 디스크를 HDD에서 SSD로, 용량을 1TB에서 10TB로 키우는 식으로 단일 서버의 사양 자체를 바꾸는 방식이다. 물리 서버라면 하드웨어를 교체하고, 클라우드라면 AWS EC2 t2.micro를 t2.xlarge로 바꾸는 것처럼 인스턴스 타입만 변경하면 된다.
이 방식의 매력은 단순함이다. 애플리케이션 코드나 아키텍처를 손대지 않고 클라우드 인스턴스 타입만 바꾸면 빠르게 적용되고, 단일 서버라 관리도 단순하며 복잡한 분산 시스템을 다룰 필요가 없다. 데이터베이스가 하나뿐이니 트랜잭션 관리와 락 경합도 상대적으로 단순하고, 서버 간 통신이 없어 네트워크 오버헤드도 없다.
하지만 물리적 상한선은 피할 수 없다. CPU와 메모리는 무한히 늘어나지 않고, 고사양 장비로 갈수록 가격이 비선형적으로 급증한다. 서버가 하나뿐이라는 건 곧 단일 장애점(SPOF)이라는 뜻이라, 그 서버가 죽으면 서비스 전체가 멈추고 고가용성을 달성하기 어렵다. 특정 용량을 넘어서면 더 이상 확장할 방법이 없고, 하드웨어 교체나 인스턴스 타입 변경 시점에는 대개 재시작이 필요해 다운타임이 발생한다. 피크 시간을 기준으로 항상 고사양을 유지해야 한다는 점에서 비용 효율도 떨어진다.
Scale-Out: 무한히 늘어나지만 대가가 있다
Scale-Out은 동일하거나 유사한 사양의 서버를 추가해 로드 밸런서로 부하를 분산하는 방식이다. 물리 서버를 추가하든, 클라우드 인스턴스를 늘리든, 컨테이너 Pod 개수를 늘리든 원리는 같다.
하드웨어 한계 없이 필요한 만큼 서버를 계속 추가할 수 있어 장기적 확장성이 확보되고, 한 서버가 죽어도 다른 서버가 처리를 이어받는 고가용성과 무중단 유지보수가 가능해진다. 비용도 저사양 서버를 여러 대 쓰는 쪽이 선형적으로 늘어나 오히려 효율적일 수 있고, 수요에 따라 동적으로 증감시키면(Auto Scaling) 피크 시간에만 자원을 추가하는 것도 가능하다. 필요한 만큼만 점진적으로 추가할 수 있어 위험도 분산되고, 병렬 처리로 성능 자체가 올라간다.
대가는 복잡성이다. 분산 시스템을 설계해야 하고 로드 밸런서 설정과 네트워크 복잡도가 따라온다. 무엇보다 애플리케이션을 Stateless 아키텍처로 바꿔야 한다 — 세션 정보를 Redis나 Memcached 같은 외부 저장소로 옮기고, 파일은 NFS나 S3 같은 공유 스토리지에 둬야 한다. 데이터를 여러 노드에 흩어놓으면 분산 데이터베이스의 CAP 이론(Consistency, Availability, Partition Tolerance)과 최종 일관성(Eventual Consistency) 문제가 뒤따르고, 서버 간 통신 오버헤드로 네트워크 지연도 새로 생긴다. 분산 트랜잭션은 단일 DB보다 훨씬 복잡해지고, 여러 서버를 모니터링하고 설정을 관리하려면 배포 자동화가 사실상 필수가 된다.
| 특성 | Scale-Up (수직 확장) | Scale-Out (수평 확장) |
|---|---|---|
| 방법 | 서버 사양 증가 | 서버 개수 증가 |
| 확장성 | 하드웨어 한계 존재 | 이론상 무한 확장 |
| 고가용성 | 낮음 (SPOF) | 높음 (분산) |
| 복잡도 | 낮음 | 높음 |
| 비용 | 비선형 증가 | 선형 증가 |
| 애플리케이션 수정 | 불필요 | 필요 (Stateless) |
| 데이터 일관성 | 쉬움 (단일 DB) | 어려움 (분산 DB) |
| 유지보수 | 다운타임 발생 | 무중단 가능 |
| 적용 사례 | 데이터베이스, 레거시 | 웹 서버, 마이크로서비스 |
어디에 어느 쪽을 쓰는가
강한 일관성과 ACID 트랜잭션, 복잡한 조인 쿼리가 필요한 RDBMS는 MySQL이나 PostgreSQL 마스터 DB처럼 Scale-Up이 자연스럽다. 분산 환경을 지원하지 않거나 코드 수정이 불가능한 레거시 애플리케이션, 비디오 인코딩·과학 계산처럼 병렬화가 어렵고 단일 작업의 성능 자체가 중요한 계산 집약적 작업도 마찬가지다.
반대로 Stateless한 웹 애플리케이션은 HTTP 요청이 서로 독립적이라 로드 밸런싱이 쉬워 Scale-Out에 잘 맞고, 마이크로서비스는 서비스별로 독립적으로 확장할 수 있어 Kubernetes 같은 컨테이너 오케스트레이션과 함께 Scale-Out을 전제로 설계된다. Hadoop·Spark 기반의 빅데이터 처리나 MapReduce는 데이터 병렬 처리 자체가 Scale-Out 구조를 요구하고, MongoDB·Cassandra·DynamoDB 같은 NoSQL 데이터베이스는 샤딩과 최종 일관성을 받아들이는 대신 Scale-Out으로 확장한다.
실무는 둘 중 하나가 아니라 계층별 조합이다
한 시스템 안에서도 계층마다 다른 전략을 쓰는 게 오히려 일반적이다. 데이터베이스는 쓰기 성능을 위해 마스터를 Scale-Up하면서, 읽기 성능은 읽기 레플리카로 Scale-Out하고, 데이터 용량 자체는 샤딩으로 Scale-Out한다. 애플리케이션 계층에서는 웹 서버와 애플리케이션 서버를 Scale-Out으로 부하 분산하면서, 데이터베이스만 Scale-Up과 레플리카 Scale-Out을 함께 쓰는 구조가 흔하다. 시스템이 커가는 순서로 보면 초기에는 간단하고 빠르게 대응할 수 있는 Scale-Up으로 시작했다가, 한계에 도달하면 아키텍처를 재설계해 Scale-Out으로 전환하고, 이후로는 Scale-Out을 중심에 두되 필요한 지점에서만 Scale-Up을 곁들이는 흐름을 밟는다.
클라우드에서는 이 전환이 도구 수준에서도 갈린다. AWS는 EC2 인스턴스 타입 변경(t2.micro → t2.xlarge → c5.4xlarge, 재부팅 필요)으로 Scale-Up을, Auto Scaling Group과 Elastic Load Balancer로 Scale-Out을 구현한다. Azure는 VM 크기 조정(Standard_B1s → Standard_D4s_v3)이 Scale-Up에, Google Cloud는 Machine Type 변경(n1-standard-1 → n1-standard-16)이 마찬가지다. Kubernetes는 HPA로 Pod 개수를, Cluster Autoscaler로 노드 수를 조정하는 것으로 Scale-Out을 자동화하고, 서버리스인 AWS Lambda나 Azure Functions는 동시 실행 수를 자동 조정하는 방식으로 아예 Scale-Out을 기본값으로 삼는다.
Stateless냐 Stateful이냐가 갈림길이다
Scale-Out을 택할 수 있느냐는 결국 애플리케이션이 상태를 어디에 두느냐에 달려 있다. 상태 정보를 서버에 저장하지 않고 각 요청이 독립적으로 처리되는 Stateless 애플리케이션 — REST API 서버가 전형적이다 — 은 어느 서버로 요청이 가도 동일하게 처리되므로 서버를 자유롭게 추가·제거할 수 있고 로드 밸런서의 라운드로빈도 그대로 통한다. 반면 세션을 서버에 유지하는 Stateful 애플리케이션은 특정 서버에 요청이 고정돼야 해서 Sticky Session(세션 어피니티)이 필요하고, 서버를 제거하면 세션이 유실될 위험이 있어 부하 분산도 균형을 잃기 쉽다. 이 문제는 세션을 Redis Cluster 같은 외부 저장소로 빼거나 데이터베이스를 샤딩하거나, 아예 Stateless로 재설계해야 풀린다.
데이터베이스만 놓고 보면 확장 전략이 더 세분화된다
단일 DB 서버의 CPU·메모리·SSD를 늘리는 Scale-Up은 쿼리 성능을 직접 끌어올리지만 수십만 TPS 수준에서 한계에 부딪힌다. 읽기 레플리카는 마스터(쓰기)와 여러 슬레이브(읽기)로 나눠 비동기 복제로 읽기 부하를 분산하는 Scale-Out 전략이고, 샤딩은 사용자 ID나 지역 같은 기준으로 데이터를 여러 DB 서버에 분산해 쓰기와 데이터 용량 자체를 늘리지만 조인이 어려워지는 복잡성을 감수해야 한다. 수평 분할(Horizontal Partitioning)은 테이블 행을 여러 서버에 나누는 방식으로 샤딩과 유사하고, 수직 분할(Vertical Partitioning)은 자주 쓰는 열과 드물게 쓰는 열을 분리해 테이블 자체를 쪼갠다.
결국 Scale-Up과 Scale-Out은 경쟁 관계가 아니라, 시스템의 각 부분이 요구하는 일관성·확장성·가용성의 균형에 따라 나눠 쓰는 두 개의 도구다.