시스템 디자인 면접 완전 가이드 2025: 대규모 시스템 설계, 확장성, 가용성 패턴

면접관: "URL 단축 서비스를 설계해 주세요."

좋은 질문 예시:
Q: "일간 활성 사용자(DAU)는 어느 정도인가요?"
A: "1억 명입니다."

Q: "URL 단축과 리디렉션 중 어느 것이 더 중요한가요?"
A: "리디렉션이 더 중요합니다. 읽기가 훨씬 많습니다."

Q: "단축 URL의 길이에 제한이 있나요?"
A: "가능한 한 짧게요."

Q: "커스텀 URL을 지원해야 하나요?"
A: "네, 선택적으로 지원해 주세요."

┌──────────┐     ┌──────────────┐     ┌──────────────┐
│  Client  │────▶│ Load Balancer│────▶│  Web Server  │
└──────────┘     └──────────────┘     └──────┬───────┘
                                             │
                    ┌────────────────────────┤
                    ▼                        ▼
             ┌──────────┐            ┌──────────────┐
             │  Cache   │            │  Database    │
             └──────────┘            └──────────────┘

수직 확장 전:           수직 확장 후:
┌─────────────┐        ┌─────────────┐
│  4 CPU      │        │  32 CPU     │
│  16GB RAM   │   ──▶  │  256GB RAM  │
│  500GB SSD  │        │  4TB SSD    │
└─────────────┘        └─────────────┘

수평 확장:
                    ┌─────────────┐
              ┌────▶│  Server 1   │
              │     └─────────────┘
┌──────────┐  │     ┌─────────────┐
│   Load   │──┼────▶│  Server 2   │
│ Balancer │  │     └─────────────┘
└──────────┘  │     ┌─────────────┐
              ├────▶│  Server 3   │
              │     └─────────────┘
              │     ┌─────────────┐
              └────▶│  Server N   │
                    └─────────────┘

Bad (Stateful):
┌──────────┐  session  ┌──────────┐
│  Client  │──────────▶│ Server A │  (Server A가 죽으면 세션 유실)
└──────────┘           └──────────┘

Good (Stateless):
┌──────────┐     ┌──────────┐     ┌──────────┐
│  Client  │────▶│   Any    │────▶│  Redis   │
└──────────┘     │  Server  │     │ (Session) │
                 └──────────┘     └──────────┘

# AWS Auto Scaling 설정 예시
AutoScalingGroup:
  MinSize: 2
  MaxSize: 20
  DesiredCapacity: 4
  TargetTrackingScaling:
    TargetValue: 70.0          # CPU 70% 유지
    PredefinedMetricType: ASGAverageCPUUtilization

  # 스케줄 기반 스케일링 (예측 가능한 트래픽)
  ScheduledActions:
    - Schedule: "0 8 * * MON-FRI"   # 평일 오전 8시
      MinSize: 6
    - Schedule: "0 22 * * *"        # 매일 오후 10시
      MinSize: 2

1. Round Robin (순차 배분)
   Request 1 → Server A
   Request 2 → Server B
   Request 3 → Server C
   Request 4 → Server A  (다시 처음부터)

2. Weighted Round Robin (가중 순차)
   Server A (weight=5): 5개 요청 처리
   Server B (weight=3): 3개 요청 처리
   Server C (weight=2): 2개 요청 처리

3. Least Connections (최소 연결)
   Server A: 10 connections ← 새 요청은 여기로
   Server B: 25 connections
   Server C: 18 connections

4. IP Hash (IP 기반 분배)
   hash(client_ip) % server_count = target_server
   → 같은 클라이언트는 항상 같은 서버로

L4 (전송 계층):
┌────────┐    TCP/UDP     ┌──────────┐
│ Client │──────────────▶│ L4 LB    │── IP:Port 기반 분배
└────────┘               └──────────┘
  속도 빠름, 단순함, SSL 오프로드 불가

L7 (애플리케이션 계층):
┌────────┐    HTTP/HTTPS   ┌──────────┐
│ Client │──────────────▶│ L7 LB    │── URL, Header, Cookie 기반 분배
└────────┘               └──────────┘
  콘텐츠 기반 라우팅, SSL 종료, 더 유연함

일반 해싱:
hash(key) % 3 = 서버 번호
→ 서버 추가시: hash(key) % 4 = 대부분 다른 서버로!

Consistent Hashing (해시 링):

        Server A
        /      \
       /   0    \
      /          \
  Server D     Server B
      \          /
       \   key  /
        \  ↓  /
        Server C

→ 서버 추가시: 인접한 키만 이동 (전체의 약 1/N만)

class ConsistentHash:
    def __init__(self, nodes, virtual_nodes=150):
        self.ring = SortedDict()
        self.virtual_nodes = virtual_nodes

        for node in nodes:
            for i in range(virtual_nodes):
                key = self._hash(f"node-vn-i")
                self.ring[key] = node

    def get_node(self, data_key):
        if not self.ring:
            return None
        hash_val = self._hash(data_key)
        # 해시 링에서 시계 방향으로 가장 가까운 노드
        idx = self.ring.bisect_right(hash_val)
        if idx == len(self.ring):
            idx = 0
        return self.ring.peekitem(idx)[1]

    def _hash(self, key):
        return int(hashlib.md5(key.encode()).hexdigest(), 16)

1. Cache-Aside (Lazy Loading):
   ┌────────┐  1.읽기  ┌───────┐
   │  App   │────────▶│ Cache │
   └────┬───┘  miss   └───────┘
        │ 2.DB 읽기      ▲
        ▼             3.캐시 저장
   ┌────────┐
   │   DB   │
   └────────┘

2. Write-Through:
   ┌────────┐  1.쓰기  ┌───────┐  2.동기 쓰기  ┌────────┐
   │  App   │────────▶│ Cache │─────────────▶│   DB   │
   └────────┘         └───────┘              └────────┘
   (항상 일관성 보장, 쓰기 지연 증가)

3. Write-Back (Write-Behind):
   ┌────────┐  1.쓰기  ┌───────┐  2.비동기 배치 쓰기  ┌────────┐
   │  App   │────────▶│ Cache │ ═════════════════▶│   DB   │
   └────────┘         └───────┘                   └────────┘
   (쓰기 성능 우수, 데이터 유실 위험)

4. Write-Around:
   ┌────────┐  1.쓰기  ┌────────┐
   │  App   │────────▶│   DB   │
   └────┬───┘         └────────┘
        │ 2.읽기시 캐시 로드
        ▼
   ┌───────┐
   │ Cache │
   └───────┘

# Redis - 다양한 데이터 구조 지원
import redis

r = redis.Redis(host='localhost', port=6379)

# String
r.set('user:1001:name', 'Alice', ex=3600)  # 1시간 TTL

# Hash
r.hset('user:1001', mapping={
    'name': 'Alice',
    'email': 'alice@example.com',
    'login_count': 42
})

# Sorted Set (리더보드)
r.zadd('leaderboard', {'player_a': 1500, 'player_b': 1800})
top_10 = r.zrevrange('leaderboard', 0, 9, withscores=True)

# Pub/Sub
r.publish('notifications', 'New message!')

CDN이 없는 경우:
사용자(서울) ──── 5000km ────▶ Origin Server(미국)
RTT: ~200ms

CDN이 있는 경우:
사용자(서울) ──── 50km ────▶ CDN Edge(서울) ── cache hit
RTT: ~5ms

Cache Miss시:
사용자(서울) → CDN Edge(서울) → Origin(미국)
                ↓ 캐시 저장
         다음 요청부터 Edge에서 응답

1. TTL 기반: Cache-Control: max-age=86400
2. 버전 관리: /static/app.v2.3.1.js
3. 수동 무효화: CloudFront Invalidation
4. 태그 기반: Surrogate-Key 헤더로 선택적 무효화

1. Cache Stampede (캐시 쓰나미):
   TTL 만료 → 수천 요청이 동시에 DB로
   해결: 뮤텍스 락 + 사전 갱신

2. Cache Penetration (캐시 관통):
   존재하지 않는 키 반복 조회 → 매번 DB 조회
   해결: Bloom Filter + 빈 결과도 캐싱

3. Hot Key Problem:
   특정 키에 트래픽 집중 → 단일 캐시 노드 과부하
   해결: 로컬 캐시 + 키 복제 (key_1, key_2, ...)

SQL 선택 기준:
- 데이터 관계가 복잡하고 조인이 빈번
- ACID 트랜잭션이 필수 (금융, 결제)
- 데이터 무결성이 최우선
- 스키마가 안정적

NoSQL 선택 기준:
- 데이터 구조가 자주 변경
- 초대량 데이터 (수 TB 이상)
- 매우 낮은 지연 시간 필요
- 수평 확장이 필수
- 비정형 데이터 (로그, 소셜 미디어)

Master-Slave 복제:
┌──────────┐     동기/비동기 복제     ┌──────────┐
│  Master  │ ═══════════════════▶│  Slave 1 │  ← 읽기 전용
│ (Write)  │ ═══════════════════▶│  Slave 2 │  ← 읽기 전용
└──────────┘                     └──────────┘

Multi-Master 복제:
┌──────────┐ ◀═══════════════▶ ┌──────────┐
│ Master 1 │    양방향 복제     │ Master 2 │
│ (R/W)    │                   │ (R/W)    │
└──────────┘                   └──────────┘
(충돌 해결 필요)

샤딩 전:
┌─────────────────────┐
│   Single Database   │
│   10TB, 지연 증가    │
└─────────────────────┘

샤딩 후 (Hash 기반):
hash(user_id) % 4 = shard_number

┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Shard 0 │ │ Shard 1 │ │ Shard 2 │ │ Shard 3 │
│ 2.5TB   │ │ 2.5TB   │ │ 2.5TB   │ │ 2.5TB   │
└─────────┘ └─────────┘ └─────────┘ └─────────┘

1. 조인 쿼리: 샤드 간 조인 불가 → 비정규화 또는 애플리케이션 레벨 조인
2. 리밸런싱: 데이터 증가시 샤드 재분배 → Consistent Hashing 활용
3. 핫스팟: 특정 샤드에 트래픽 집중 → 샤드 키 재설계
4. 트랜잭션: 분산 트랜잭션 → Saga 패턴 또는 2PC
5. 고유 ID: 글로벌 유니크 ID 필요 → Snowflake ID, UUID

-- 정규화된 설계 (조인 필요):
SELECT u.name, o.total, p.name AS product_name
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id;

-- 비정규화된 설계 (단일 테이블):
-- orders 테이블에 user_name, product_name 포함
SELECT user_name, total, product_name
FROM denormalized_orders
WHERE user_id = 1001;

       Consistency (일관성)
         /          \
        /            \
       /     CA      \
      /  (single DC)  \
     /________________\
    |                  |
 CP |    분산 시스템    | AP
    |  P는 피할 수 없음  |
    |__________________|
         Availability
         (가용성)

네트워크 파티션 발생시:
CP 시스템 → 일관성 유지, 일부 요청 거부
AP 시스템 → 가용성 유지, 일시적 불일치 허용

if (Partition) then
    Choose between Availability and Consistency
else
    Choose between Latency and Consistency

예시:
- DynamoDB: PA/EL (가용성 + 낮은 지연)
- MongoDB:  PC/EC (일관성 우선)
- Cassandra: PA/EL (가용성 + 낮은 지연)
- PostgreSQL(single): PC/EC (일관성 + 일관성)

동기 처리:
Client → API → 이메일 전송(3s) → 이미지 리사이즈(2s) → 로그 저장(1s) → Response
총 6초 대기

비동기 처리:
Client → API → Message Queue → Response (즉시)
                    ↓
             ┌──────┴──────┐
             ▼             ▼
       Email Worker   Image Worker
         (3s)           (2s)
총 0.1초 대기

Apache Kafka:
┌──────────┐     ┌─────────────────────────┐
│ Producer │────▶│  Topic: orders          │
└──────────┘     │  ┌─────┬─────┬─────┐   │
                 │  │ P0  │ P1  │ P2  │   │
                 │  └──┬──┴──┬──┴──┬──┘   │
                 └─────┼─────┼─────┼──────┘
                       ▼     ▼     ▼
                 ┌──────────────────────┐
                 │  Consumer Group A    │
                 │  (각 파티션 1 소비자) │
                 └──────────────────────┘

1. At-Most-Once (최대 1회):
   Producer → Broker (ACK 안 기다림)
   빠르지만 메시지 유실 가능
   사용: 로그, 메트릭 (유실 허용)

2. At-Least-Once (최소 1회):
   Producer → Broker → ACK
   ACK 실패시 재전송 → 중복 가능
   사용: 대부분의 시스템 (멱등 처리 필요)

3. Exactly-Once (정확히 1회):
   트랜잭션 기반 또는 멱등 키 사용
   성능 오버헤드 있음
   사용: 금융, 결제 (정확성 필수)

import time
import threading

class TokenBucket:
    def __init__(self, capacity, refill_rate):
        self.capacity = capacity        # 버킷 최대 토큰 수
        self.tokens = capacity           # 현재 토큰 수
        self.refill_rate = refill_rate   # 초당 추가 토큰
        self.last_refill = time.time()
        self.lock = threading.Lock()

    def allow_request(self):
        with self.lock:
            now = time.time()
            # 토큰 보충
            elapsed = now - self.last_refill
            self.tokens = min(
                self.capacity,
                self.tokens + elapsed * self.refill_rate
            )
            self.last_refill = now

            # 요청 허용 여부
            if self.tokens >= 1:
                self.tokens -= 1
                return True
            return False

# 초당 10개 요청, 버스트 최대 20개
limiter = TokenBucket(capacity=20, refill_rate=10)

import time
from collections import deque

class SlidingWindowLog:
    def __init__(self, window_size, max_requests):
        self.window_size = window_size   # 윈도우 크기 (초)
        self.max_requests = max_requests
        self.requests = deque()

    def allow_request(self):
        now = time.time()
        # 윈도우 밖의 오래된 요청 제거
        while self.requests and self.requests[0] < now - self.window_size:
            self.requests.popleft()

        if len(self.requests) < self.max_requests:
            self.requests.append(now)
            return True
        return False

# 1분에 최대 100개 요청
limiter = SlidingWindowLog(window_size=60, max_requests=100)

Sliding Window Counter (메모리 효율적):

이전 윈도우 카운트: 84
현재 윈도우 카운트: 36
윈도우 크기: 60초
현재 위치: 윈도우의 25% 지점

가중 카운트 = 84 * (1 - 0.25) + 36 = 84 * 0.75 + 36 = 99

max_requests = 100 → 허용 (99 < 100)

쓰기: 1억 DAU * 평균 0.1 URL/day = 1000만/day
QPS(쓰기) = 10,000,000 / 86,400 = ~116 QPS
QPS(읽기) = 116 * 100 = ~11,600 QPS
피크 QPS = 11,600 * 3 = ~35,000 QPS

저장 용량 (5년):
10,000,000 * 365 * 5 = 182.5억 레코드
각 레코드 ~500 bytes → 182.5억 * 500B = ~9.1TB

┌────────┐     ┌──────┐     ┌─────────────┐
│ Client │────▶│  LB  │────▶│  API Server │
└────────┘     └──────┘     └──────┬──────┘
                                   │
                    ┌──────────────┼──────────────┐
                    ▼              ▼              ▼
              ┌──────────┐  ┌──────────┐  ┌──────────┐
              │  Redis   │  │ MySQL    │  │ Analytics│
              │  Cache   │  │ (Sharded)│  │  (Kafka) │
              └──────────┘  └──────────┘  └──────────┘

import hashlib
import base64

def generate_short_url(long_url, counter):
    # 방법 1: Base62 인코딩 (auto-increment ID)
    chars = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
    short = ""
    n = counter
    while n > 0:
        short = chars[n % 62] + short
        n //= 62
    return short  # 예: "dK4x9Z"

    # 방법 2: MD5 해시 + Base62 (처음 7자)
    hash_val = hashlib.md5(long_url.encode()).hexdigest()
    num = int(hash_val[:12], 16)
    short = ""
    for _ in range(7):
        short = chars[num % 62] + short
        num //= 62
    return short

# 62^7 = 약 3.5조 개의 고유 URL 가능

Fan-out on Write (Push 모델):
사용자가 트윗 작성시 모든 팔로워의 타임라인에 미리 저장

User A 트윗 → Fan-out Service
                ├─▶ Follower 1의 타임라인 캐시에 추가
                ├─▶ Follower 2의 타임라인 캐시에 추가
                └─▶ Follower N의 타임라인 캐시에 추가

장점: 읽기가 매우 빠름 (미리 계산됨)
단점: 팔로워가 많으면 쓰기 부하 엄청남

Fan-out on Read (Pull 모델):
타임라인 요청시 팔로잉 중인 사용자들의 트윗을 실시간 조합

User B 타임라인 요청 → 팔로잉 사용자 조회
                        ├─▶ User X의 최신 트윗
                        ├─▶ User Y의 최신 트윗
                        └─▶ User Z의 최신 트윗
                        → 병합 + 정렬 → 반환

장점: 쓰기가 단순
단점: 읽기 시 여러 DB 조회 필요

일반 사용자 (팔로워 < 10,000): Fan-out on Write
셀러브리티 (팔로워 > 10,000): Fan-out on Read

타임라인 조회:
1. 캐시에서 미리 팬아웃된 트윗 가져오기
2. 팔로잉 중인 셀러브리티의 최신 트윗 조회
3. 두 결과를 병합 + 시간순 정렬

WebSocket 기반 실시간 통신:

┌────────┐  WebSocket  ┌─────────────┐
│ User A │◀══════════▶│  Chat       │
└────────┘             │  Server    │
                       │  Cluster   │
┌────────┐  WebSocket  │            │
│ User B │◀══════════▶│            │
└────────┘             └─────┬──────┘
                             │
                    ┌────────┼────────┐
                    ▼        ▼        ▼
              ┌────────┐ ┌──────┐ ┌────────┐
              │ Redis  │ │Kafka │ │Message │
              │Presence│ │      │ │   DB   │
              └────────┘ └──────┘ └────────┘

방법 1: 서버 타임스탬프 (단순하지만 시계 동기화 문제)
방법 2: Snowflake ID (시간 + 서버 + 시퀀스)

Snowflake ID 구조 (64비트):
┌─────────────┬────────┬──────────┬──────────────┐
│  Timestamp  │Datactr │ Machine  │   Sequence   │
│   41 bits   │ 5 bits │  5 bits  │   12 bits    │
└─────────────┴────────┴──────────┴──────────────┘
→ 시간순 정렬 가능 + 전역 고유
→ 초당 4096 * 1024 = ~400만 ID 생성 가능

Heartbeat 방식:
- 클라이언트가 5초마다 heartbeat 전송
- 30초 동안 heartbeat 없으면 offline 처리
- Redis에 마지막 heartbeat 시간 저장

상태 변경 알림:
- 변경시 해당 사용자의 친구 목록에 알림
- 친구가 많으면 Fan-out 부하 → 접속 중인 친구에게만 알림

비디오 업로드 파이프라인:

┌──────────┐    ┌──────────┐    ┌─────────────────┐
│ Uploader │───▶│  Object  │───▶│  Transcoding    │
│          │    │  Store   │    │  Pipeline       │
└──────────┘    │  (S3)    │    │                 │
                └──────────┘    │  ┌───────────┐  │
                                │  │ 240p      │  │
                                │  │ 480p      │  │
                                │  │ 720p      │  │
                                │  │ 1080p     │  │
                                │  │ 4K        │  │
                                │  └───────────┘  │
                                └────────┬────────┘
                                         ▼
                                ┌─────────────────┐
                                │    CDN에 배포    │
                                │ (전 세계 Edge)  │
                                └─────────────────┘

사용자 네트워크 상태에 따라 화질 자동 조정:

대역폭 10Mbps → 1080p 세그먼트 요청
대역폭 3Mbps  → 480p 세그먼트로 전환
대역폭 회복   → 점진적으로 화질 올림

HLS (HTTP Live Streaming) 방식:
1. 비디오를 2~10초 세그먼트로 분할
2. 각 세그먼트를 여러 화질로 인코딩
3. m3u8 매니페스트 파일로 세그먼트 목록 제공
4. 클라이언트가 대역폭에 맞는 세그먼트 선택

지연 시간:
- L1 캐시 참조: ~1ns
- L2 캐시 참조: ~4ns
- 메인 메모리 참조: ~100ns
- SSD 랜덤 읽기: ~150us
- HDD Seek: ~10ms
- 동일 DC 왕복: ~0.5ms
- 미국 ↔ 유럽 왕복: ~75ms

용량:
- 1 char = 1 byte (ASCII) / 2~4 bytes (UTF-8)
- 1 UUID = 36 bytes (문자열) / 16 bytes (바이너리)
- 1 이미지 (중간) = ~200KB
- 1 비디오 (1분, 720p) = ~50MB

일간 환산:
- 1일 = 86,400초 = ~100,000초 (간단 계산)
- 1백만 요청/일 = ~12 QPS
- 1억 요청/일 = ~1,200 QPS

Twitter 규모 추정:
- DAU: 3억 명
- 평균 트윗 조회: 100회/일
- 읽기 QPS = 3억 * 100 / 86,400 = ~347,000 QPS
- 피크 QPS = 347,000 * 3 = ~1,000,000 QPS

- 평균 트윗 작성: 2회/일
- 쓰기 QPS = 3억 * 2 / 86,400 = ~6,944 QPS

저장소:
- 트윗 크기: ~300 bytes (텍스트 + 메타데이터)
- 하루: 6억 트윗 * 300B = ~180GB/일
- 5년: 180GB * 365 * 5 = ~328TB
- 미디어 포함: ~5배 = ~1.6PB

1. 요구사항 확인 없이 바로 설계 시작
   → 반드시 5분은 질문에 투자

2. 하나의 컴포넌트에만 집중
   → 전체 그림을 먼저, 면접관이 요청한 부분을 깊이

3. 완벽한 설계를 추구
   → 트레이드오프를 설명하는 것이 더 중요

4. 숫자 없는 설계
   → QPS, 저장량, 대역폭을 반드시 계산

5. 일방적으로 말하기
   → 면접관과 대화하며 피드백 수용

6. 과도한 기술 도입
   → 문제에 맞는 적절한 기술 선택

1. 구조화된 접근:
   - 4단계 프레임워크를 항상 따르기
   - 각 단계에서 시간 관리

2. 트레이드오프 설명:
   - "이 방법의 장점은 A이고, 단점은 B입니다."
   - "대안으로 C가 있지만, 우리 상황에서는 D가 더 적합합니다."

3. 실제 사례 언급:
   - "Netflix는 이 문제를 X 방식으로 해결했습니다."
   - "이전 프로젝트에서 비슷한 문제를 경험했습니다."

4. 화이트보드 활용:
   - 깔끔한 다이어그램
   - 데이터 흐름 화살표
   - 숫자/메트릭 표시

5. 면접관 힌트 수용:
   - 면접관의 질문은 곧 힌트
   - "좋은 지적입니다, 그 부분을 개선하면..."