확장성 (Scalability)

확장성이란

확장성(Scalability) 은 사용자 수, 트래픽, 데이터 양이 늘어나도 시스템이 성능과 안정성을 유지하도록 처리 능력을 키울 수 있는 성질입니다.

이 문서는 시스템 설계 관점에서 언제 어떤 확장 전략을 선택할지를 설명합니다.
샤딩 키, 복제 지연, 파티셔닝 운영처럼 데이터베이스 구현 상세는 데이터베이스 스케일링 문서를 함께 보면 연결이 잘 됩니다.

특정 사용자나 tenant의 과도한 사용으로 병목이 커지는 상황은 레이트 리미팅 (Rate Limiting) 문서와 같이 보면 더 자연스럽습니다.

중요한 점은 단순히 “서버를 많이 붙일 수 있다”가 아니라 다음을 함께 만족해야 한다는 점입니다.

처리량 증가: 요청 수가 늘어도 병목 없이 감당할 수 있어야 합니다.
운영 가능성: 확장 후에도 배포, 장애 대응, 모니터링이 유지돼야 합니다.
비용 효율: 트래픽 2배 증가에 비용이 10배로 튀지 않아야 합니다.
일관성 유지: 확장 과정에서 데이터 품질과 사용자 경험이 망가지지 않아야 합니다.

그래서 확장성은 인프라 개수 문제가 아니라 병목을 어느 계층에서 어떻게 분산할지 정하는 설계 문제에 가깝습니다.

확장성을 볼 때 먼저 확인할 것

확장성 면접에서는 곧바로 샤딩이나 Kubernetes를 말하기보다, 먼저 어떤 축이 먼저 커지는지 정리하는 편이 좋습니다.

트래픽 증가: QPS, 동시 접속 수, 피크 트래픽 배수
데이터 증가: 테이블 크기, 로그 적재량, 객체 저장 용량
읽기/쓰기 비율: 캐시와 복제본의 효과가 달라집니다.
지연 시간 목표: 몇 초까지 허용되는지에 따라 구조가 달라집니다.
장애 허용 범위: 일부 기능 저하를 허용할지, 강한 일관성을 지킬지 판단해야 합니다.

예를 들어:

조회가 대부분이면 캐시, CDN, 읽기 복제본이 먼저 효과를 냅니다.
쓰기가 많고 특정 키에 집중되면 큐, 파티셔닝, 샤딩이 더 중요해집니다.
애플리케이션 서버는 쉽게 늘어나도 데이터베이스가 병목이면 전체 시스템은 잘 안 커집니다.

즉, 확장성은 “무엇을 얼마나 늘릴 것인가”를 먼저 정의해야 올바른 해법이 나옵니다.

수직 확장과 수평 확장

확장 전략은 보통 수직 확장(Scale-Up) 과 수평 확장(Scale-Out) 으로 나눕니다.¹

항목	수직 확장	수평 확장
방식	더 큰 CPU, 메모리, 스토리지를 가진 장비로 교체	서버 수를 늘려 부하를 분산
장점	구조가 단순하고 초기 도입이 쉽다	확장 한계가 더 높고 장애 격리에 유리하다
단점	장비 한계와 SPOF가 남는다	라우팅, 일관성, 운영 복잡도가 커진다
적합한 경우	초기 서비스, 단일 DB, 빠른 대응 필요 시	대규모 트래픽, 다중 인스턴스, 글로벌 서비스

실무에서는 보통 다음 순서가 자연스럽습니다.

먼저 수직 확장으로 빠르게 버틴다.
애플리케이션 계층은 수평 확장으로 전환한다.
데이터 계층은 캐시, 복제본, 파티셔닝, 샤딩 순서로 점진적으로 확장한다.

중요한 포인트는 수평 확장이 더 고급 기술이라서 무조건 정답은 아니라는 점입니다.

서비스가 아직 작으면 수직 확장이 더 단순하고 안전합니다.
수평 확장은 인스턴스를 늘리는 순간부터 로드 밸런싱, 세션, 설정 동기화, 배포 전략이 함께 따라옵니다.
데이터 계층은 애플리케이션보다 수평 확장이 훨씬 어렵습니다.

관련 세부 내용은 로드 밸런싱, 고가용성, 데이터베이스 스케일링 문서와 함께 보면 연결이 잘 됩니다.

상태 유지와 무상태 서비스

애플리케이션을 수평 확장할 때 가장 자주 나오는 질문은 상태 유지(Stateful) 와 무상태(Stateless) 구조의 차이입니다.

항목	상태 유지 서비스	무상태 서비스
상태 저장 위치	인스턴스 메모리나 로컬 디스크	외부 저장소나 토큰에 상태 보관
장점	구현이 단순할 수 있다	수평 확장과 장애 복구에 유리하다
단점	sticky session, 재배치, 장애 복구가 어렵다	외부 저장소 설계가 필요하다
예시	메모리 세션 서버, 로컬 캐시 의존 서비스	API 서버, 토큰 기반 인증 서비스

면접에서는 보통 무상태 애플리케이션이 수평 확장에 유리하다고 설명하는 편이 안전합니다.

이유는 다음과 같습니다.

요청을 어느 인스턴스로 보내도 처리 가능
오토스케일링 시 새 인스턴스를 쉽게 붙일 수 있음
인스턴스 장애가 나도 상태 손실 영향이 작음
배포와 롤백이 쉬움

반대로 상태 유지 구조는 다음 문제가 따라옵니다.

특정 사용자가 특정 서버에 붙어야 할 수 있음
캐시나 세션이 인스턴스 로컬에 묶이면 확장성이 떨어짐
장애나 재시작 시 사용자 상태가 사라질 수 있음

그래서 확장이 필요한 서비스는 보통 다음 방향을 택합니다.

세션 외부화: Redis, 데이터베이스, 토큰 기반 인증
파일 외부화: 오브젝트 스토리지 사용
설정 외부화: 환경 변수, 설정 저장소, 서비스 디스커버리

단, 무상태가 항상 무료는 아닙니다.

외부 저장소 호출이 늘어 지연이 늘 수 있음
인증과 캐시 전략을 더 정교하게 설계해야 함
상태를 애플리케이션 바깥으로 밀어낸 만큼 다른 계층이 중요해짐

샤딩 전략 개요

확장성 이야기를 하다 보면 결국 데이터 계층에서 샤딩(Sharding) 이 등장합니다. 샤딩은 데이터를 여러 노드에 분산 저장해 저장량과 쓰기 처리량 한계를 넘기 위한 수평 확장 방식입니다.¹

샤딩이 필요한 대표 상황은 다음과 같습니다.

단일 데이터베이스 인스턴스의 CPU, I/O, 저장 공간이 한계에 도달함
쓰기 처리량이 너무 높아 primary 하나로 버티기 어려움
테이블 크기가 너무 커서 백업, 복구, 유지보수 시간이 과도해짐

대표 전략은 다음과 같습니다.

전략	장점	주의점	적합한 경우
범위 기반 샤딩	범위 조회에 유리	특정 구간에 hotspot이 생길 수 있음	시간, 지역, ID 구간 기반 조회
해시 기반 샤딩	고른 분산에 유리	범위 조회 효율이 떨어질 수 있음	균등 분산이 더 중요한 쓰기 중심 서비스
지리 기반 샤딩	지역 지연과 규제 대응에 유리	국가 간 조회와 이동이 복잡함	멀티 리전, 데이터 레지던시 요구

샤딩에서 가장 중요한 것은 샤딩 키입니다.

분산이 고르게 되는가
핵심 조회가 특정 샤드만 타는가
시간이 지나도 hot shard가 생기지 않는가

면접에서는 “샤딩으로 확장한다”에서 멈추지 말고, 샤딩 키를 잘못 잡으면 리샤딩 비용이 커진다는 점까지 말해야 답변이 강해집니다.

여기서는 샤딩이 필요한 시점과 대가를 중심으로 설명하고, 샤딩 키 선택과 리밸런싱 운영 포인트는 데이터베이스 스케일링 에서 더 구체적으로 다룹니다.

또한 샤딩은 마지막 카드에 가깝습니다.

먼저 캐시
그다음 읽기 복제본
그다음 파티셔닝
마지막에 샤딩

이런 순서로 가는 경우가 많습니다. 이유는 샤딩이 join, transaction, 운영 난이도를 크게 올리기 때문입니다.

오토스케일링과 병목 이전

오토스케일링은 확장성 설계의 중요한 도구이지만, 병목을 해결하는 도구와 병목을 감추는 도구를 구분해야 합니다.²

오토스케일링이 잘 맞는 경우는 다음과 같습니다.

애플리케이션 인스턴스가 대부분 무상태다
CPU, 메모리, 큐 길이 같은 지표가 부하와 잘 연결된다
인스턴스 추가 후 효과가 빠르게 나타난다

반대로 오토스케일링만으로 해결되지 않는 병목도 많습니다.

데이터베이스 connection pool 한계
락 경합
느린 외부 API
특정 hot key 집중
단일 파티션이나 단일 샤드 병목

즉, 서버 수를 늘렸는데 성능이 그대로라면 병목이 이미 다른 계층으로 이동한 것입니다.

특히 비정상 트래픽이나 일부 고객의 과도한 사용이 병목을 키우는 경우에는 오토스케일링만 늘리기보다 레이트 리미팅 (Rate Limiting) 같은 보호 계층을 같이 검토하는 편이 좋습니다.

확장성 설계에서 자주 보는 흐름은 다음과 같습니다.

애플리케이션 서버가 먼저 병목이 된다
로드 밸런서와 오토스케일링으로 완화한다
이후 캐시나 DB가 새 병목이 된다
그다음 읽기 분리, 큐, 파티셔닝, 샤딩을 검토한다

면접에서는 오토스케일링 설명 시 다음까지 같이 말하는 편이 좋습니다.

스케일 기준 지표: CPU, 메모리, QPS, queue lag
워밍업 시간: 새 인스턴스가 실제 트래픽을 받기까지 걸리는 시간
스케일 다운 안정성: 너무 빠른 축소로 흔들리지 않게 해야 함
병목 이전 지점: DB, 캐시, 외부 의존성이 다음 병목이 되는지 확인

좋은 답변은 “트래픽이 늘면 서버를 자동으로 늘립니다”가 아니라,
늘린 뒤 어디가 다음 한계인지까지 예측하는 답변입니다.

확장성의 트레이드오프

장점: 확장성이 좋아지면 사용자 증가와 피크 트래픽에 더 유연하게 대응할 수 있습니다.
단점: 수평 확장으로 갈수록 네트워크, 일관성, 운영 복잡도가 커집니다.
주의점: 확장성은 애플리케이션만의 문제가 아니라 데이터와 운영 체계까지 함께 설계해야 합니다.

특히 다음 오해를 피해야 합니다.

서버를 여러 대 두면 자동으로 확장성 문제가 해결되는 것은 아님
오토스케일링을 넣으면 병목이 사라지는 것은 아님
샤딩을 하면 성능이 무조건 좋아지는 것도 아님

좋은 설계는 단순한 구조로 오래 버티다가, 병목이 확인되면 단계적으로 분산하는 전략을 갖습니다.

면접 포인트

확장성은 서버를 많이 두는 문제가 아니라 병목을 어느 계층에서 분산할지 정하는 문제입니다.
애플리케이션 계층은 수평 확장이 비교적 쉽지만, 데이터 계층은 훨씬 어렵습니다.
무상태 서비스는 수평 확장과 오토스케일링에 유리합니다.
샤딩은 강력하지만 마지막 카드에 가깝고, 샤딩 키 선정 기준까지 설명해야 합니다.
오토스케일링을 말할 때는 다음 병목이 어디로 이동하는지도 같이 말해야 답변이 강해집니다.