시스템 설계 개요
시스템 설계 개요¶
개요¶
이 문서에서는 시스템 설계(System Design)의 기본 개념과 면접에서의 접근법을 다룹니다. 대규모 시스템을 설계하기 위한 기본 프레임워크와 규모 추정(Back-of-the-envelope) 계산 방법을 학습합니다.
난이도: ⭐ 예상 학습 시간: 2시간 선수 지식: 프로그래밍 기초, 웹 서비스 기본 개념
목차¶
1. 시스템 설계란?¶
1.1 정의¶
시스템 설계는 복잡한 소프트웨어 시스템의 아키텍처를 정의하는 과정입니다. 요구사항을 분석하고, 컴포넌트를 설계하며, 확장성과 신뢰성을 갖춘 시스템을 만드는 것이 목표입니다.
┌─────────────────────────────────────────────────────────────────┐
│ 시스템 설계란? │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 요구사항 → 아키텍처 → 구현 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 기능적 │ │ 컴포넌트 │ │ 코드 │ │
│ │ 요구사항 │ ──▶ │ 설계 │ ──▶ │ 구현 │ │
│ │ │ │ │ │ │ │
│ │ 비기능적 │ │ 데이터 │ │ 테스트 │ │
│ │ 요구사항 │ │ 흐름 │ │ │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ 시스템 설계 = 요구사항 → 아키텍처 결정 │
│ │
└─────────────────────────────────────────────────────────────────┘
1.2 시스템 설계가 중요한 이유¶
┌─────────────────────────────────────────────────────────────────┐
│ 시스템 설계의 중요성 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. 확장성 (Scalability) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 사용자 100명 → 1,000,000명으로 성장할 때 │ │
│ │ 시스템이 감당할 수 있어야 함 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 2. 신뢰성 (Reliability) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 서버 장애가 발생해도 서비스가 계속되어야 함 │ │
│ │ 데이터 손실이 없어야 함 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 3. 유지보수성 (Maintainability) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 새로운 기능 추가가 쉬워야 함 │ │
│ │ 버그 수정이 다른 부분에 영향을 주지 않아야 함 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 4. 성능 (Performance) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ 응답 시간이 빨라야 함 │ │
│ │ 처리량(throughput)이 충분해야 함 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
1.3 시스템 설계 vs 코딩 면접¶
| 구분 | 코딩 면접 | 시스템 설계 면접 |
|---|---|---|
| 목적 | 알고리즘 능력 평가 | 아키텍처 설계 능력 평가 |
| 정답 | 명확한 정답 존재 | 여러 정답 가능 (트레이드오프) |
| 형태 | 코드 작성 | 화이트보드/다이어그램 |
| 평가 | 정확성, 효율성 | 사고 과정, 의사소통 |
| 레벨 | 주니어~시니어 | 주로 시니어 이상 |
2. 면접 평가 기준¶
2.1 주요 평가 항목¶
┌─────────────────────────────────────────────────────────────────┐
│ 면접 평가 기준 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 1. 문제 이해 및 범위 정의 (Problem Scoping) │ │
│ │ • 요구사항을 명확히 파악하는가? │ │
│ │ • 적절한 질문을 하는가? │ │
│ │ • 가정을 명시하는가? │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ▼ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 2. 고수준 설계 (High-Level Design) │ │
│ │ • 주요 컴포넌트를 식별하는가? │ │
│ │ • 데이터 흐름이 명확한가? │ │
│ │ • API를 적절히 설계하는가? │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ▼ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 3. 상세 설계 (Deep Dive) │ │
│ │ • 핵심 컴포넌트를 깊이 있게 다루는가? │ │
│ │ • 데이터 모델이 적절한가? │ │
│ │ • 잠재적 병목을 식별하는가? │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ▼ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 4. 트레이드오프 논의 (Trade-offs) │ │
│ │ • 여러 선택지의 장단점을 아는가? │ │
│ │ • 왜 특정 기술을 선택했는지 설명하는가? │ │
│ │ • 제약 조건을 고려하는가? │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
2.2 레벨별 기대 수준¶
┌─────────────────────────────────────────────────────────────────┐
│ 경력 수준별 기대치 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 주니어 (0-2년) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 기본 컴포넌트 이해 (웹서버, DB, 캐시) │ │
│ │ • 단순한 시스템의 데이터 흐름 설명 │ │
│ │ • 기본적인 API 설계 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 미드레벨 (2-5년) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 확장 가능한 아키텍처 설계 │ │
│ │ • 캐싱, 로드밸런싱 적용 │ │
│ │ • 데이터베이스 선택 및 스키마 설계 │ │
│ │ • 기본적인 트레이드오프 논의 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 시니어 (5년+) │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 대규모 분산 시스템 설계 │ │
│ │ • 복잡한 트레이드오프 분석 │ │
│ │ • 장애 복구, 보안 고려 │ │
│ │ • 비용 최적화 │ │
│ │ • 마이크로서비스 아키텍처 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
3. 문제 접근 프레임워크¶
3.1 4단계 접근법¶
┌─────────────────────────────────────────────────────────────────┐
│ 시스템 설계 4단계 프레임워크 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ STEP 1: 요구사항 명확화 (5분) │ │
│ │ │ │
│ │ "Twitter 같은 서비스를 설계해주세요" │ │
│ │ │ │
│ │ 질문할 것들: │ │
│ │ • 핵심 기능은? (트윗 작성, 타임라인, 팔로우?) │ │
│ │ • 사용자 규모는? (DAU 1백만? 1억?) │ │
│ │ • 읽기/쓰기 비율은? (보통 100:1) │ │
│ │ • 미디어 지원? (이미지, 동영상) │ │
│ │ • 실시간 알림 필요? │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ STEP 2: 규모 추정 (5분) │ │
│ │ │ │
│ │ • QPS (Queries Per Second) 계산 │ │
│ │ • 저장 용량 추정 │ │
│ │ • 대역폭 계산 │ │
│ │ • 서버 수 추정 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ STEP 3: 고수준 설계 (15-20분) │ │
│ │ │ │
│ │ • 시스템 아키텍처 다이어그램 │ │
│ │ • 주요 컴포넌트 (클라이언트, 서버, DB, 캐시 등) │ │
│ │ • 데이터 흐름 │ │
│ │ • API 설계 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ STEP 4: 상세 설계 (15-20분) │ │
│ │ │ │
│ │ • 데이터베이스 스키마 │ │
│ │ • 핵심 알고리즘/데이터 구조 │ │
│ │ • 확장 전략 (샤딩, 복제) │ │
│ │ • 병목 해결 │ │
│ │ • 장애 대응 │ │
│ └──────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
3.2 요구사항 명확화 질문 예시¶
기능 요구사항 (Functional Requirements):
┌─────────────────────────────────────────────────────────────────┐
│ • 이 시스템의 핵심 기능 3가지는 무엇인가요? │
│ • 사용자는 어떤 작업을 수행할 수 있나요? │
│ • 모바일/웹/API 중 어떤 클라이언트를 지원하나요? │
│ • 인증/인가가 필요한가요? │
│ • 검색 기능이 필요한가요? │
└─────────────────────────────────────────────────────────────────┘
비기능 요구사항 (Non-Functional Requirements):
┌─────────────────────────────────────────────────────────────────┐
│ • 예상 사용자 수는? (DAU, MAU) │
│ • 응답 시간 요구사항은? (p99 < 200ms?) │
│ • 가용성 요구사항은? (99.9%? 99.99%?) │
│ • 데이터 일관성 vs 가용성 중 무엇이 더 중요한가요? │
│ • 글로벌 서비스인가요? 지역 서비스인가요? │
└─────────────────────────────────────────────────────────────────┘
3.3 고수준 설계 예시¶
Twitter 고수준 설계
┌─────────┐ ┌─────────────┐ ┌────────────────┐
│ Mobile │ │ │ │ │
│ App │────▶│ Load │────▶│ Web/API │
│ │ │ Balancer │ │ Servers │
└─────────┘ │ │ │ │
└─────────────┘ └───────┬────────┘
┌─────────┐ │ │
│ Web │ │ │
│ Browser │───────────┘ │
│ │ ▼
└─────────┘ ┌────────────────────┐
│ │
┌──────────────┤ Service Layer │
│ │ │
│ └────────────────────┘
│ │
┌────────┴────────┐ │
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ Cache │ │ Database │ │ Message │
│ (Redis) │ │ (MySQL) │ │ Queue │
└────────────┘ └────────────┘ └────────────┘
│
▼
┌────────────┐
│ Object │
│ Storage │
│ (S3) │
└────────────┘
4. Back-of-the-envelope 계산¶
4.1 QPS (Queries Per Second) 계산¶
┌─────────────────────────────────────────────────────────────────┐
│ QPS 계산 방법 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 예시: Twitter 트윗 읽기 QPS │
│ │
│ 주어진 조건: │
│ • DAU (Daily Active Users): 300백만 명 │
│ • 평균 사용자당 일일 트윗 조회: 100회 │
│ │
│ 계산: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 일일 총 조회 수 = 300,000,000 × 100 = 30,000,000,000 │ │
│ │ │ │
│ │ 평균 QPS = 30,000,000,000 / 86,400 ≈ 350,000 QPS │ │
│ │ │ │
│ │ 피크 QPS = 평균 QPS × 2~3 ≈ 700,000 ~ 1,000,000 QPS │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
│ 참고: 86,400 = 24시간 × 60분 × 60초 │
│ │
└─────────────────────────────────────────────────────────────────┘
4.2 저장 용량 계산¶
┌─────────────────────────────────────────────────────────────────┐
│ 저장 용량 계산 방법 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 예시: Twitter 5년간 저장 용량 │
│ │
│ 주어진 조건: │
│ • DAU: 300백만 명 │
│ • 하루 평균 트윗 작성: 2개 (전체 사용자의 10%만 작성) │
│ • 트윗 평균 크기: 250 bytes (텍스트만) │
│ • 이미지 포함 비율: 20%, 평균 이미지 크기: 500KB │
│ │
│ 계산: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 일일 트윗 수 = 300M × 10% × 2 = 60M │ │
│ │ │ │
│ │ 텍스트 저장: │ │
│ │ 일일 = 60M × 250B = 15GB │ │
│ │ 연간 = 15GB × 365 = 5.5TB │ │
│ │ 5년 = 5.5TB × 5 = 27.5TB │ │
│ │ │ │
│ │ 이미지 저장: │ │
│ │ 일일 = 60M × 20% × 500KB = 6TB │ │
│ │ 연간 = 6TB × 365 = 2.2PB │ │
│ │ 5년 = 2.2PB × 5 = 11PB │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
4.3 대역폭 계산¶
┌─────────────────────────────────────────────────────────────────┐
│ 대역폭 계산 방법 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 예시: 동영상 스트리밍 서비스 │
│ │
│ 주어진 조건: │
│ • 동시 시청자: 100만 명 │
│ • 평균 비트레이트: 5 Mbps (1080p 기준) │
│ │
│ 계산: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 총 필요 대역폭 = 1,000,000 × 5 Mbps = 5,000,000 Mbps │ │
│ │ = 5,000 Gbps = 5 Tbps │ │
│ │ │ │
│ │ 일일 데이터 전송량 (평균 시청 시간 2시간 가정): │ │
│ │ = 100M 시청자 × 5Mbps × 7200초 │ │
│ │ = 3.6 × 10^15 bits = 450 TB/일 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
5. 자주 사용하는 수치¶
5.1 2의 거듭제곱¶
| 거듭제곱 | 근사값 | 이름 | 바이트 |
|---|---|---|---|
| 2^10 | 1,000 | 1 Thousand | 1 KB |
| 2^20 | 1,000,000 | 1 Million | 1 MB |
| 2^30 | 1,000,000,000 | 1 Billion | 1 GB |
| 2^40 | 1,000,000,000,000 | 1 Trillion | 1 TB |
| 2^50 | - | 1 Quadrillion | 1 PB |
5.2 시간 단위 변환¶
┌─────────────────────────────────────────────────────────────────┐
│ 시간 단위 참조표 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1일 = 86,400초 (≈ 100,000초로 근사) │
│ 1주 = 604,800초 (≈ 600,000초로 근사) │
│ 1달 = 2,592,000초 (≈ 2.5M초로 근사) │
│ 1년 = 31,536,000초 (≈ 30M초로 근사) │
│ │
│ 빠른 계산용: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ 1일 ≈ 10^5 초 │ │
│ │ 1년 ≈ 3 × 10^7 초 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
5.3 지연 시간 비교¶
┌─────────────────────────────────────────────────────────────────┐
│ 지연 시간 참조표 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 작업 │ 지연 시간 │
│ ───────────────────────────────────────────────────────────── │
│ L1 캐시 참조 │ 0.5 ns │
│ L2 캐시 참조 │ 7 ns │
│ 메인 메모리 참조 │ 100 ns │
│ SSD 랜덤 읽기 │ 150 μs │
│ HDD 디스크 탐색 │ 10 ms │
│ 같은 데이터센터 네트워크 왕복 │ 0.5 ms │
│ 다른 리전 네트워크 왕복 │ 150 ms │
│ │
│ 시각화 (1 ns = 1초로 환산): │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ L1 캐시: 0.5초 │ │
│ │ 메인 메모리: 100초 (1분 40초) │ │
│ │ SSD: 150,000초 (약 2일) │ │
│ │ HDD: 10,000,000초 (약 4개월) │ │
│ │ 네트워크 (같은 DC): 500,000초 (약 6일) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
5.4 가용성 수치 (9's)¶
| 가용성 | 연간 다운타임 | 월간 다운타임 |
|---|---|---|
| 99% (two 9s) | 3.65일 | 7.3시간 |
| 99.9% (three 9s) | 8.77시간 | 43.8분 |
| 99.99% (four 9s) | 52.6분 | 4.38분 |
| 99.999% (five 9s) | 5.26분 | 26초 |
5.5 일반적인 서비스 처리량¶
┌─────────────────────────────────────────────────────────────────┐
│ 서비스별 처리량 참조 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 웹 서버 (Nginx) │ 10,000 ~ 100,000 req/s │
│ 데이터베이스 (MySQL) │ 10,000 ~ 50,000 QPS │
│ 캐시 (Redis) │ 100,000 ~ 500,000 ops/s │
│ 메시지 큐 (Kafka) │ 1,000,000 msg/s │
│ │
│ 단일 서버 추정치: │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ • 웹 서버: ~1,000 동시 연결 │ │
│ │ • 데이터베이스: ~10,000 QPS │ │
│ │ • 캐시: ~100,000 ops/s │ │
│ └────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
6. 연습 문제¶
문제 1: QPS 계산¶
Instagram 같은 서비스에서 이미지 업로드 QPS를 계산하세요.
조건: - DAU: 500백만 - 일일 이미지 업로드 비율: 10% 사용자가 평균 2장 업로드
문제 2: 저장 용량 추정¶
채팅 앱의 1년간 메시지 저장 용량을 추정하세요.
조건: - DAU: 100백만 - 평균 일일 메시지: 50개/사용자 - 평균 메시지 크기: 100 bytes
문제 3: 서버 수 추정¶
100,000 QPS를 처리하기 위해 필요한 웹 서버 수를 추정하세요.
조건: - 단일 서버 처리량: 1,000 QPS - 가용성을 위해 20% 여유 필요
문제 4: 요구사항 명확화¶
"URL 단축 서비스를 설계해주세요"라는 문제가 주어졌을 때, 면접관에게 할 질문 5가지를 작성하세요.
문제 5: 시스템 설계 연습¶
간단한 파일 공유 서비스의 고수준 아키텍처를 그려보세요.
정답¶
문제 1 정답¶
이미지 업로드 수/일 = 500M × 10% × 2 = 100M
평균 QPS = 100M / 86,400 ≈ 1,160 QPS
피크 QPS = 1,160 × 3 ≈ 3,500 QPS
문제 2 정답¶
일일 메시지 수 = 100M × 50 = 5B
일일 저장량 = 5B × 100B = 500GB
연간 저장량 = 500GB × 365 ≈ 180TB
문제 3 정답¶
기본 필요 서버 = 100,000 / 1,000 = 100대
여유분 포함 = 100 × 1.2 = 120대
고가용성 고려 (이중화) = 120 × 2 = 240대
문제 4 정답¶
- 예상 DAU와 MAU는 얼마인가요?
- 단축 URL의 예상 길이/형식은?
- URL 만료 기능이 필요한가요?
- 커스텀 단축 URL 지원이 필요한가요?
- 분석 기능(클릭 수 통계)이 필요한가요?
문제 5 정답¶
┌─────────┐ ┌─────────────┐ ┌──────────────┐
│ Client │────▶│ Load │────▶│ Web Server │
└─────────┘ │ Balancer │ └──────┬───────┘
└─────────────┘ │
┌┴─────────────┐
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ Metadata │ │ Object │
│ DB │ │ Storage │
└──────────┘ └──────────┘
7. 다음 단계¶
시스템 설계 기초를 이해했다면, 확장성 개념을 학습하세요.
다음 레슨¶
- 02_Scalability_Basics.md - 수평/수직 확장, CAP 정리
관련 레슨¶
- 03_Network_Fundamentals_Review.md - DNS, CDN, HTTP
- 04_Load_Balancing.md - 트래픽 분산
추천 실습¶
- 자주 사용하는 서비스의 규모 추정해보기
- 화이트보드에 시스템 아키텍처 그려보기
- 소리 내어 설계 과정 설명하기
8. 참고 자료¶
도서¶
- System Design Interview - Alex Xu
- Designing Data-Intensive Applications - Martin Kleppmann
온라인 자료¶
연습 사이트¶
- Pramp - 모의 면접
- Interviewing.io
문서 정보 - 최종 수정: 2024년 - 난이도: ⭐ - 예상 학습 시간: 2시간