정의: 서버를 키우는 두 가지 방법
서비스에 사용자가 늘어나면 서버가 감당해야 할 트래픽도 늘어난다. 이때 확장(Scaling)하는 방법은 크게 두 가지다. 하나는 Vertical Scaling(수직 확장)으로, 기존 서버의 CPU나 RAM 같은 자원을 더 강력한 사양으로 업그레이드하는 방식이다. 예를 들어 4코어 8GB 서버를 16코어 64GB로 바꾸는 식이다. 다른 하나는 Horizontal Scaling(수평 확장)으로, 서버 한 대의 성능을 올리는 대신 같은 사양의 서버를 여러 대 추가해서 부하를 나누는 방식이다.
흔히 드는 비유로, Vertical Scaling은 ‘더 큰 트럭 한 대’로 짐을 나르는 것이고, Horizontal Scaling은 ‘같은 크기의 트럭 여러 대’로 나눠 나르는 것이다. 짐(트래픽)이 많아졌을 때 트럭을 키울 수도 있고, 트럭 대수를 늘릴 수도 있는 셈이다.
동작 원리와 차이점
Vertical Scaling은 구조가 단순하다. 서버 한 대만 존재하기 때문에 데이터 동기화나 세션 공유 같은 복잡한 문제가 없다. 하지만 하드웨어 성능에는 물리적 한계가 있고, 업그레이드 중 서버를 잠시 멈춰야 하는 경우도 많다.
반면 Horizontal Scaling은 서버 여러 대가 동시에 요청을 처리하므로, 트래픽을 나눠주는 로드밸런서(Load Balancer)가 필요하다. 예를 들어 사용자의 요청이 오면 로드밸런서가 서버 A, B, C 중 한 곳으로 요청을 분산시킨다. 이 방식은 서버를 계속 추가할 수 있어 확장성이 뛰어나지만, 여러 서버 간에 데이터를 일관되게 유지하는 작업(예: 세션 관리, 데이터베이스 복제)이 추가로 필요해 구조가 복잡해진다.
실무에서 왜 중요한가
실무에서는 두 방식을 상황에 맞게 혼용한다. 초기 스타트업이나 트래픽이 적은 서비스는 관리가 단순한 Vertical Scaling으로 시작하는 경우가 많다. 하지만 사용자가 급증하고 장애 대응 능력(고가용성)이 중요해지면 Horizontal Scaling으로 전환한다. 대표적으로 쿠버네티스(Kubernetes) 같은 오케스트레이션 도구는 트래픽에 따라 서버(Pod) 개수를 자동으로 늘리고 줄이는 Horizontal Scaling을 기본 철학으로 삼고 있다.
정리하면, Vertical Scaling은 ‘한 대를 강하게’, Horizontal Scaling은 ‘여러 대를 함께’라는 접근이다. 둘 다 장단점이 있으므로, 서비스의 트래픽 패턴과 장애 허용 범위를 고려해 적절한 전략을 선택하는 것이 중요하다.