그알것 — 그럼에도 알아야 할 것들
홈질문커뮤니티
로그인
그알것 — 그럼에도 알아야 할 것들

Service

  • 홈
  • 소개
  • 질문
  • 커뮤니티

My

  • 내 워크스페이스
  • 저장한 질문
  • 작성한 답변

Policy

  • 이용약관
  • 개인정보처리방침
  • 문의

© 2026 그알것 · What Still Matters

질문 목록Infra
Infra

스케일 업과 스케일 아웃의 차이가 뭔가요?

실무4/5
설계4/5
인간3/5
기초3/5

면접관의 질문 의도

둘의 정의를 외워 왔는지, 아니면 비용·가용성·코드 구조·상태 관리까지 함께 보고 선택 기준을 풀 수 있는지를 가른다.

큐레이션 답변

학습 자료

스케일 업은 기존 서버의 CPU·메모리·디스크를 키우는 수직 확장이다. 코드 변경 없이 처리 가능량이 늘어 단순하지만, 한 노드의 물리적 한계와 단일 장애점(SPOF) 위험을 그대로 안고 간다. 스케일 아웃은 같은 역할의 서버를 여러 대로 늘려 부하를 분산하는 수평 확장이다. 가용성과 탄력성에 강하지만, 로드 밸런싱·세션 공유·상태 동기화·관측 가능성 같은 "여러 대를 운영하기 위한" 코드와 인프라 부담이 따라온다. DB처럼 상태가 강한 시스템은 스케일 아웃이 본질적으로 더 어렵고, 스테이트리스한 애플리케이션 서버는 상대적으로 쉽다.

좋은 답변 구조

  1. 01스케일 업(수직)과 스케일 아웃(수평)을 한 줄씩 정의한다
  2. 02비용·가용성·운영 복잡도·코드 구조 같은 핵심 축에서 차이를 비교한다
  3. 03스테이트풀(DB) vs 스테이트리스(API 서버)에 따라 적정 전략이 어떻게 갈리는지 분기로 든다
  4. 04초기·중기·고트래픽 단계에서 어느 쪽이 먼저 와야 하는지로 마무리한다

자주 실수하는 포인트

성능 측면만 보고 가용성·비용·운영 복잡도를 함께 다루지 못한다
수평 확장 시 세션·캐시·DB 상태 동기화 문제를 무시한다
미래 트래픽 예측 없이 처음부터 큰 사양·많은 인스턴스를 "확장 대비"로 깔아 둔다
DB도 "그냥 인스턴스 늘리면 된다"는 식으로 단순화한다

실무 맥락

  • 초기 트래픽이 가파르게 늘어 "한 대 키우기"부터 시작했지만 곧 한계에 부딪히는 스타트업 서비스
  • 장애 허용도가 낮아 단일 장애점을 만들면 안 되는 결제·인증 시스템
  • 피크·오프피크 트래픽 격차가 커서 오토스케일링이 필요한 이벤트성 서비스

본인 경험에 녹이는 힌트

인스턴스 사양만 올려 가다 한계에 부딪혀 수평 확장 + 세션 외부화로 옮긴 경험이 있다면 "전환 시점"의 사례로 풀어낼 수 있다

오토스케일링 임계값과 그레이스풀 종료를 조정해 본 경험이 있다면 "수평 확장은 정책이 절반이다"는 일반화로 이어갈 수 있다

DB 스케일 업의 한계 때문에 읽기 레플리카·샤딩 같은 전략을 도입한 경험이 있다면 스테이트풀 시스템의 어려움 사례로 보여 줄 수 있다

커뮤니티 인기 답변

전체 0개

아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.

관련 꼬리 질문

Q1수평 확장 시 세션·캐시 같은 상태는 어떻게 처리하나요
Q2스케일 업의 단일 장애점은 어떻게 완화하나요
Q3오토스케일링 임계값은 어떤 지표 기준으로 잡나요
아직 답을 쓰지 않았어요.
큐레이션 답변과 다른 사람 답변을 보고, 자기 언어로 답을 정리해보면 학습 효과가 가장 큽니다.
목차
  • 01면접관의 질문 의도
  • 02큐레이션 답변
  • 03좋은 답변 구조
  • 04자주 실수하는 포인트
  • 05실무 맥락
  • 06본인 경험에 녹이는 힌트
  • 07커뮤니티 인기 답변준비중
  • 08관련 꼬리 질문