안녕하세요. 원래는 목요일까지 면접에만 집중하면서 이것저것 확인하려고 했는데, 그렇다고 블로그를 못쓸 정도는 아닌 것 같아서 그냥 쓰기로 했습니다.
이번 편은 총 3편으로 나뉘어져 있으며, 백엔드 로드맵에 해당하는 부분은 다 해냈습니다. 이후에는 아마 내용적인 부분 추가나 자세히 알아보는 과정, 그리고 신기술 등을 학습할 것 같습니다.
그럼 시작하겠습니다.
확장성
확장성은 서비스의 트래픽이나 데이터가 증가했을 때 시스템이 이를 감당할 수 있도록 커질 수 있는 능력을 의미합니다.
처음에는 사용자 수가 적어 하나의 서버로도 충분할 수 있습니다. 하지만 사용자가 많아지고 요청량이 증가하면 CPU, 메모리, 네트워크, 데이터베이스 연결 수 같은 자원이 부족해질 수 있습니다.
이때 서버를 더 좋은 사양으로 바꾸거나, 여러 서버로 요청을 나누어 처리하는 방식으로 시스템을 확장할 수 있습니다.
수직 확장
수직 확장(Scale-Up)은 기존 서버의 CPU, RAM 등 하드웨어 성능을 업그레이드하는 방식입니다.
예를 들어 CPU 코어 수를 늘리거나, 메모리를 확장하거나, 더 빠른 디스크를 사용하는 방식입니다. 쉽게 말해 서버 한 대를 더 강력한 서버로 바꾸는 것입니다.
수직 확장은 구조가 비교적 단순합니다. 서버의 개수를 늘리는 것이 아니라 기존 서버의 자원을 늘리는 방식이기 때문에 애플리케이션 구조를 크게 바꾸지 않아도 됩니다.
초기 서비스나 트래픽 규모가 크지 않은 서비스에서는 수직 확장만으로도 충분한 경우가 많습니다.
수직 확장의 장점
- 구조가 단순함
- 서버 대수를 늘리지 않아도 됨
- 적용이 빠름
- 서버 사양을 높이면 바로 효과를 볼 수 있음
- 애플리케이션 변경이 적음
- 분산 처리 구조를 크게 고려하지 않아도 됨
- 운영 난이도가 낮음
- 여러 서버를 관리하는 부담이 적음
수직 확장의 한계
- 물리적 한계
- 한 대의 서버가 가질 수 있는 CPU, 메모리에는 한계가 있음
- 비용 증가
- 고성능 서버일수록 비용이 급격히 증가할 수 있음
- 단일 장애점
- 서버 한 대에 장애가 발생하면 전체 서비스가 영향을 받을 수 있음
- 확장 유연성 부족
- 트래픽 변화에 따라 유연하게 늘리고 줄이기 어려움
즉, 수직 확장은 시작하기 쉽지만 한 대의 서버에 의존한다는 한계가 있습니다.
수평 확장
수평 확장(Scale-Out)은 서버의 성능을 높이는 대신 서버의 대수를 늘려 요청을 분산하는 방식입니다. 장애 발생 시에도 전체 서비스가 중단되지 않는 고가용성 확보에 유리합니다.
예를 들어 하나의 애플리케이션 서버가 모든 요청을 처리하던 구조에서 동일한 애플리케이션 서버를 여러 대 띄우고 요청을 나누어 처리하는 방식입니다.
수평 확장에서는 여러 서버가 같은 애플리케이션을 실행하고, 로드 밸런서가 들어오는 요청을 각 서버로 분산합니다.
이렇게 하면 특정 서버 한 대에 요청이 몰리는 것을 줄일 수 있고, 트래픽이 증가했을 때 서버를 추가해 처리량을 늘릴 수 있습니다.
수평 확장의 장점
- 확장 유연성
- 트래픽 증가에 따라 서버를 추가할 수 있음
- 장애 대응
- 일부 서버에 문제가 생겨도 다른 서버가 요청을 처리할 수 있음
- 비용 효율성
- 고성능 서버 한 대보다 일반 서버 여러 대가 유리할 수 있음
- 대규모 트래픽 대응
- 많은 요청을 여러 서버가 나누어 처리 가능
수평 확장의 어려움
- 로드 밸런싱
- 요청을 여러 서버로 분산해야 함
- 세션 관리
- 특정 서버에만 세션이 저장되면 문제가 생길 수 있음
- 무상태 설계
- 어느 서버가 요청을 받아도 동일하게 처리할 수 있어야 함
- 데이터베이스 부하
- 애플리케이션 서버를 늘려도 DB가 병목이 될 수 있음
- 파일 저장소
- 서버 로컬에 파일을 저장하면 서버 간 데이터 불일치가 생길 수 있음
- 배포 관리
- 여러 서버에 동일한 버전을 배포해야 함
수직 확장과 수평 확장의 차이
수직 확장은 서버 한 대를 더 강하게 만드는 방식이고, 수평 확장은 서버 여러 대가 함께 처리하도록 만드는 방식입니다.
| 구분 | 수직 확장 | 수평 확장 |
| 방식 | 서버 한 대의 성능을 높임 | 서버 대수를 늘림 |
| 예시 | CPU, RAM 증설 | App Server 여러 대 운영 |
| 구조 | 단순함 | 상대적으로 복잡함 |
| 장애 대응 | 서버 한 대 장애 시 영향 큼 | 일부 서버 장애 시 분산 처리 가능 |
| 확장 한계 | 물리적 한계 존재 | 서버 추가로 확장 가능 |
| 비용 구조 | 고성능 서버 비용 증가 | 여러 서버 운영 비용 발생 |
| 필요한 구성 | 고사양 서버 | 로드 밸런서, 무상태 설계, 공용 저장소 등 |
수평 확장을 위해 필요한 구성
수평 확장을 제대로 적용하려면 단순히 서버를 여러 대 띄우는 것만으로는 부족합니다.
1. 로드 밸런서
로드 밸런서는 클라이언트 요청을 여러 서버로 나누어 보내는 역할을 합니다.
Nginx, 클라우드 로드 밸런서, L4/L7 로드 밸런서 등을 사용할 수 있습니다.
2. 무상태 서버
무상태 서버는 요청을 처리할 때 서버 내부에 사용자 상태를 저장하지 않는 구조입니다.
예를 들어 로그인 정보를 특정 서버 메모리에만 저장하면 다음 요청이 다른 서버로 전달되었을 때 사용자를 식별하지 못할 수 있습니다. 따라서 JWT를 사용하거나, 세션을 Redis 같은 외부 저장소에 저장해 어느 서버가 요청을 받아도 동일하게 처리할 수 있도록 구성해야 합니다.
3. 공용 저장소
이미지나 파일을 서버 로컬 디스크에 저장하면 서버가 여러 대일 때 문제가 생길 수 있습니다.
따라서 파일은 Object Storage, S3 같은 외부 저장소에 저장하고, 애플리케이션 서버는 파일의 URL이나 메타데이터만 관리하는 방식이 더 적합할 수 있습니다.
4. 데이터베이스 병목 고려
애플리케이션 서버를 여러 대로 늘려도 모든 요청이 하나의 데이터베이스로 몰리는 DB가 병목이 될 수 있습니다.
따라서 조회 부하가 커지면 캐시, 읽기 복제본, 인덱스 최적화, 쿼리 개선 같은 추가적인 전략도 함께 고려해야 합니다.
어떤 방식을 선택해야할까?
수직 확장과 수평 확장은 어느 하나가 무조건 더 좋은 방식은 아닙니다.
초기 서비스에서는 구조가 단순한 수직 확장이 더 현실적일 수 있습니다. 하지만 트래픽이 계속 증가하고 장애 대응이 중요해지면 수평 확장을 고려해야 합니다.
초기 단계 → 수직 확장으로 단순하게 대응
트래픽 증가 / 고가용성 필요 → 수평 확장 고려
대규모 서비스 → 수직 확장 + 수평 확장 + 캐시 + DB 확장 전략 함께 사용
실제 서비스에서는 수직 확장과 수평 확장을 함께 사용하는 경우도 많습니다. 먼저 서버 사양을 어느 정도 높이고, 이후 트래픽 증가에 따라 서버 대수를 늘리는 방식으로 확장할 수 있습니다.
이번 글에서는 확장성과 수평/수직 확장에 대해서 학습해봤습니다. 다음 시간에는 마이그레이션에 대해서 알아보도록 하겠습니다. 수고하셨습니다.
'백엔드 공부' 카테고리의 다른 글
| 웹 서버 - Nginx와 Apache로 이해하는 요청 처리 구조 (0) | 2026.06.01 |
|---|---|
| 실시간 통신 방식 WebSocket (0) | 2026.05.31 |
| 그래프 데이터베이스 - Neo4j (0) | 2026.05.30 |
| GraphQL - REST API와 차이 (0) | 2026.05.29 |
| 컨테이너화 VS 가상화 - Docker란 무엇인가 (0) | 2026.05.28 |