Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

"The only new thing in the world is the history you don't know." — Harry Truman "Software architecture is the set of decisions which, if made well, will prevent you from having to make them again." — Ralph Johnson

Staff+ 인터뷰에서 System Design 라운드가 결정적이다. 왜? 코딩은 LeetCode로 벼락치기 가능하지만, 시스템 디자인은 실전 경험만이 쌓는다.

이 글은 2024~2025년 실제 대규모 시스템 아키텍처를 분해하고, 그 안에 들어간 수십 개 의사결정의 Trade-off 수학을 체계화한다. 1B QPS·Multi-region·Data Lakehouse·Consensus·Cost·Observability 6대 축.

입문서 아니라 Staff+의 방어 무기로 설계.

1. 스케일의 분수령 — QPS 단위의 의미

1.1 QPS 단위별 아키텍처 분수령

QPS	아키텍처	사례
10~100	Single Server + DB	MVP
1K	LB + N App + Single DB	Startup MVP+
10K	Cached Reads + Replicated DB	Growth stage
100K	Sharded DB + Async + CDN	Scale up
1M	Multi-region + Specialized data stores	Hyperscaler
10M+	Custom infra + Edge everywhere	FAANG

관찰: 10배씩 오를 때마다 아키텍처 근본 재설계.

1.2 1B QPS란 무엇인가

10^9 req/s = 초당 10억.
Google Search: 피크 ~100K QPS (하루 ~9B).
Meta Newsfeed: 수백만 QPS.
Twitter Timeline: ~300K QPS 읽기.
1B QPS는 주로 Network Level (DNS·CDN·Edge Cache).

진짜 Application 1B QPS는 매우 드물다. 보통 "스케일 문제"는 100K~1M 구간.

1.3 스케일이 바꾸는 것

확률적 사고: 1 in 1M 버그가 하루에 수백 번.
Tail Latency: 평균이 아니라 P99·P999.
비용 선형 증가의 탈출: Cost 기하급수 피하기.
사람 운영 한계: 자동화 필수.
Monitoring 복잡도 지수: Observability에 특수 투자.

2. Multi-Region 아키텍처

2.1 왜 Multi-Region인가

지리적 지연 감소: 한국 사용자에게 한국 리전.
재해 복구 (DR): 한 리전 죽어도 서비스 유지.
데이터 주권: GDPR·지역 규제.
부하 분산: 글로벌 트래픽 분산.

2.2 3가지 패턴

Active-Passive (Cold Standby): 한 리전 서비스, 다른 리전 대기.
- 간단, 비용 ↓, RTO·RPO 길다.
Active-Active Read-Only Replica: 읽기는 로컬, 쓰기는 Primary.
- 읽기 지연 ↓, 쓰기는 왕복.
Active-Active Multi-Master: 양쪽 리전 모두 쓰기 가능.
- 복잡, Conflict 해결 필요, 지연 ↓.

2.3 Conflict Resolution 전략

Last Write Wins (LWW): 단순, 데이터 유실 가능.
Vector Clocks: 정확, 복잡.
CRDT (Conflict-free Replicated Data Type): 수학적 Merge 보장.
Strong Consistency: Spanner·CockroachDB, 글로벌 TrueTime 기반.

2.4 실전 케이스 — Discord 2024 Multi-region

US·EU·AP 3개 리전.
Voice는 지역 Pin (Latency 민감).
Text·Media는 Eventually Consistent.
Guild 라우팅: User → 가장 가까운 리전의 복제본.

2.5 Cost 고려

Multi-region은 2~3배 비용 증가. 정당성:

다운타임 분당 손실 $X.
규제 요구.
사용자 지연 민감도.

계산 없이 Multi-region 하지 말 것. "Vanity Architecture"의 함정.

3. Data Lakehouse — 2024~2025 데이터 아키텍처

3.1 Data Warehouse vs. Data Lake vs. Lakehouse

Warehouse (Snowflake·BigQuery·Redshift): SQL·정형·비용 ↑·빠름.
Lake (S3·HDFS): 비정형·저비용·느림.
Lakehouse: 둘의 장점 결합.

3.2 Lakehouse 3대 Table Format

Format	주도	특징
Apache Iceberg	Netflix·AWS	Schema Evolution·Time Travel·Partition Evolution
Delta Lake	Databricks	ACID·SCD·Unity Catalog
Apache Hudi	Uber	Incremental·MERGE·CDC

2024~2025 트렌드: Iceberg가 표준화 움직임 (Snowflake, Databricks, AWS 모두 지원).

3.3 Lakehouse 아키텍처

Source -> Bronze (Raw) -> Silver (Cleansed) -> Gold (Aggregated)
                                                  |
                                                  v
                                     BI / ML / Analytics

Medallion 아키텍처 (Databricks 대중화).

3.4 Streaming + Batch Unified

Kappa Architecture: 스트리밍으로 통일.
Lambda Architecture: Batch + Stream 이중 (Legacy).
2025 트렌드: Flink·Spark Structured Streaming으로 Kappa.

3.5 Query Engine

Trino / Presto: Federated Query.
DuckDB: Embedded Analytical.
Apache Drill·Impala: Legacy.
Polars·DataFusion (Rust): Performance 최전선.

4. Consistency 모델과 Consensus

4.1 CAP 정리

Consistency: 모든 노드 동시 같은 값.
Availability: 모든 요청 응답.
Partition Tolerance: 네트워크 분단 시 작동.

현실: Network Partition은 일어난다 → P는 포기 불가 → C와 A 중 선택.

CP: HBase·MongoDB (strong mode)·Zookeeper.
AP: Cassandra·DynamoDB (default)·Riak.

4.2 PACELC (Abadi 확장)

Partition 시: C vs. A.
Else (정상 시): L(Latency) vs. C(Consistency).

더 현실적. 예: MongoDB = PA/EC (분단 시 A, 정상 시 C).

4.3 Raft vs. Paxos

Paxos (Lamport 1990): 원조, 이해 난해.
Raft (Ongaro 2014): 교육용으로 명확, etcd·Consul·CockroachDB.
Multi-Paxos: Spanner의 기반.

기본 흐름:

Leader Election.
Log Replication.
Safety Invariant.

4.4 Linearizability vs. Serializability

Linearizability: 단일 Object, 실시간.
Serializability: 여러 Object 트랜잭션, 순서.
Strict Serializability: 둘 다.

대부분 DB의 "Strong Consistency" 모드 = Strict Serializability.

4.5 실전 Trade-off

Latency 민감 (게임): Eventual Consistency 수용.
금융 트랜잭션: Strict Serializability 필수.
Social Feed: Eventual OK.
Booking: Strong (이중 예약 방지).

의사결정 공식: C를 줄이면 A·L 얻는다. 반대도 성립.

5. 1B QPS 시스템 패턴

5.1 Read-heavy 시스템 패턴

예: Twitter Timeline.

Fan-out on Write: 팔로워들 Timeline에 미리 Push.
Fan-out on Read: 요청 시 계산.
Hybrid: Celebrity는 Fan-out on Read, 일반은 Write.

트레이드오프: Write 비용 vs. Read 복잡도.

5.2 Write-heavy 시스템

예: Log Aggregation·Metrics.

LSM Tree: Cassandra·RocksDB·ScyllaDB.
Append-only Log: Kafka.
Shard by Time·Key: 파티션 분산.

5.3 Search 시스템

예: Google·Elastic.

Inverted Index: 단어 → 문서 ID.
Sharding by Term: 단어별 분산.
Replica for Read.
Query Parse → Index Lookup → Ranking → Highlight.

5.4 Chat 시스템

예: Slack·WhatsApp·Discord.

Long Polling / WebSocket.
Message Queue (Kafka·NATS).
Persistent Storage (C / Mongo).*
Presence State (Redis).
Notification (Push Service).

5.5 Payment 시스템

예: Stripe.

Strong Consistency (Exactly-once 필수).
Idempotency Key.
Saga Pattern for Multi-step.
Reconciliation Batch (매일).
Audit Log (Immutable).

6. Cost 최적화 수학

6.1 AWS 주요 비용 3위

Compute (EC2·Fargate·Lambda).
Storage (S3·EBS·RDS).
Data Transfer (Egress가 비쌈).

6.2 Spot·Reserved·Savings Plan

Spot: 70~90% 할인, 중단 가능 → Batch·Async에.
Reserved (1·3년): 40~60% 할인.
Savings Plan: 유연, 40~50% 할인.

Rule of Thumb: 정상 운영 Compute 70% Reserved/SP, 나머지 On-demand.

6.3 Storage 최적화

S3 Tier: Standard → IA → Glacier.
Lifecycle Policy: 90일 후 IA, 1년 후 Glacier.
Compression: Parquet·ORC (3~10배 ↓).
Columnar: BigQuery·Snowflake·Iceberg.

6.4 Network 최적화

Same AZ > Same Region > Cross-region > Internet.
VPC Endpoint: S3 Egress 줄임.
CloudFront: Origin 부하 ↓.
AZ 이동도 비쌈: Cross-AZ Traffic 수수료.

6.5 FinOps Principles

Team 비용 Attribution.
Tag 의무화.
월간 리뷰 + 이상치 경보.
Engineering Efficiency Metric.
Reserved Instance 비용·활용률 분석.

6.6 Cost-aware Design 예

Data Lake 압축: Parquet + Zstd → 비용 5~10배 ↓.
Cold Storage 활용: 30일 이상 미사용 로그 Glacier.
Serverless Ingestion: 낮은 처리량에 Lambda.
Aurora Serverless v2: 트래픽 변동 큰 DB.

7. Observability 3축 실전

7.1 Metric

RED: Rate·Error·Duration.
USE: Utilization·Saturation·Errors.
Four Golden Signals (Google SRE): Latency·Traffic·Errors·Saturation.

툴: Prometheus·Datadog·New Relic·Grafana.

비용 고려: Metric Cardinality 폭발 주의. User ID 레이블 위험.

7.2 Log

Structured Logging (JSON).
Correlation ID: Trace ID + Span ID.
Sampling: Trace 1% 샘플.
Retention: 90일 Hot + 1년 Cold.

툴: ELK·Splunk·Datadog Log Management.

비용: Log는 쉽게 월 수만 달러.

7.3 Trace

OpenTelemetry: Vendor-neutral 표준.
Distributed Tracing: 서비스 간 호출 체인.
Jaeger·Zipkin·Tempo.

적용 팁: Sampling + Head-based vs. Tail-based.

7.4 Alert 설계

SLI/SLO 기반: "P99 Latency 500ms 이하 99.9%".
Error Budget: 월간 허용 실패율.
Page-worthy: 즉각 대응 필요한 것만 Page.
Ticket-worthy: 24h 내 대응 → 티켓.
Dashboard: 현재 상태 관찰.

7.5 2024~2025 Observability 트렌드

OpenTelemetry 표준화.
eBPF 기반 Observability: Pixie·Cilium.
Continuous Profiling: Pyroscope·Parca.
AI for Observability: Anomaly Detection 자동화.

8. Scale Failure 모드 — 대표 장애 패턴

8.1 Thundering Herd

캐시 만료 순간 모든 요청이 DB로. 해법: Request Coalescing, Cache Warming, TTL Jitter.

8.2 Cache Stampede

비슷한 패턴, Lock 기반 단일 쿼리. 해법: Probabilistic Early Expiration (XFetch).

8.3 Retry Storm

실패 → 재시도 폭탄 → 더 큰 실패. 해법: Exponential Backoff + Jitter, Circuit Breaker.

8.4 Gray Failure

완전히 죽지 않고 느림. 해법: Health Check에 Latency 포함, SLO 기반 자동 제외.

8.5 Memory Leak in Pod

오랜 기간 천천히 누수. 해법: Memory Limit + Auto-restart, Profiling 주기적.

8.6 Disk Full

관찰 안 되는 채로 급격. 해법: Alert 80%, 자동 Retention.

8.7 DNS 문제

TTL 무시·Cache·Propagation 딜레이. 해법: 낮은 TTL, 중복 DNS.

8.8 Cascading Failures

한 서비스 죽으면 상류도 다 죽음. 해법: Bulkhead (격리), Circuit Breaker, Timeout·Retry 제한.

9. Database 선택 매트릭스

9.1 Decision Tree

Q: Strong Transaction 필요?
  Yes → Relational (Postgres·MySQL·CockroachDB·Spanner)
  No → Q: Scale 요구?
    Massive → Q: Access Pattern?
      Key-Value → DynamoDB·Cassandra·ScyllaDB
      Document → MongoDB·Couchbase
      Time-Series → InfluxDB·TimescaleDB·Prometheus
      Graph → Neo4j·Neptune
      Full-text → Elasticsearch·OpenSearch

9.2 대중적 선택 2024~2025

OLTP 기본: PostgreSQL.
글로벌 OLTP: CockroachDB·Spanner.
Time-Series: TimescaleDB·InfluxDB·VictoriaMetrics.
Analytics: ClickHouse·BigQuery·Snowflake.
Cache: Redis·Memcached·Dragonfly.
Queue: Kafka·NATS·SQS·RabbitMQ.
Search: OpenSearch·Elastic·Typesense·Meilisearch.
Vector: pgvector·Pinecone·Weaviate·Qdrant·Milvus.

9.3 PostgreSQL의 부상 2025

Everything Postgres: pgvector·pg_cron·pg_partman·TimescaleDB.
Managed: Supabase·Neon·Nile·Xata.
Scalability: Citus·Timescale HA·Aurora PG.

단순성·기능의 조합으로 "기본값" 자리 확고.

10. 사례 Deep Dive — Discord 2024

10.1 규모

일간 사용자 200M+.
메시지 4B+/일.
Voice Users 수백만 동시.

10.2 Voice 아키텍처

WebRTC: 표준, 브라우저·앱.
SFU (Selective Forwarding Unit): MCU 대신, 비용 ↓.
Nearest Region 라우팅.
Opus Codec: 저비용 고품질.

10.3 Chat 스토리지 이동

2015~2017: Cassandra.
2017~2023: Cassandra + 버그 많음.
2023: ScyllaDB 이전 (C++ 재구현, Latency ↓, 노드 수 ↓).

교훈: 같은 데이터 모델도 Engine 성능 차이 거대.

10.4 사례에서 배울 것

초기 단순한 선택 → 성장하며 Optimize.
10배마다 재설계 각오.
Benchmark 실제로.

11. System Design 인터뷰 Framework

11.1 RESHADED Framework

Requirements 명확화.
Estimate (QPS·Storage·Bandwidth).
Service 간 interface.
High-Level Architecture.
API 세부.
Data Model·DB 선택.
Edge Cases·Failures.
Dive deeper into one component.

11.2 단계별 시간 배분 (45분)

Requirements: 5분.
Estimate: 5분.
High-level: 10분.
Deep Dive: 15분.
Trade-off·Edge Case: 5분.
Q&A·Follow-up: 5분.

11.3 Top 20 경험 시나리오

URL Shortener.
Rate Limiter.
Twitter Feed.
Chat System.
Video Streaming.
File Storage (Dropbox).
Search (Google).
Notification System.
Ride Hailing (Uber).
Payment System.
Booking System (Airbnb).
Ads System.
Fraud Detection.
Leaderboard.
Analytics Pipeline.
Job Scheduler.
Metrics System.
Log System.
Cache System.
CI/CD System.

각 시나리오 3회 이상 실습. Grokking·ByteByteGo·System Design Primer.

12. System Design 체크리스트 12

13. System Design 안티패턴 10

"Kubernetes 먼저": 10명 팀에 과스펙.
Premature Multi-region.
Microservices 숭배: 적정 크기 무시.
NoSQL 유행: SQL이면 되는 것에 NoSQL.
"우리도 Uber처럼": 트래픽 10K인데 1M 설계.
SLO 없는 Alert: 시끄러운 경보.
Single Point Vendor Lock.
수동 Scaling: Autoscaling 없음.
Observability 사후약방문.
Cost 무감각: 월 말 청구서에 놀라움.

14. 추천 자료 Top 15

14.1 책

"Designing Data-Intensive Applications" — Kleppmann.
"System Design Interview" — Alex Xu (Vol 1·2).
"Database Internals" — Alex Petrov.
"Streaming Systems" — Akidau.
"Site Reliability Engineering" — Google.

14.2 블로그·유튜브

Netflix Tech Blog.
Uber Engineering.
Discord Engineering.
High Scalability.
ByteByteGo YouTube.

14.3 오픈소스 소스

Kubernetes.
Kafka.
Redis.
PostgreSQL.
etcd.

15. 마무리 — System Design은 Opinion의 공학

"Architecture is about the important stuff. Whatever that is." — Ralph Johnson

System Design은 정답의 과학이 아니라 Trade-off의 공학이다. 같은 문제에 여러 해답이 있고, 각 해답은 다른 가치 (Latency·Cost·Complexity·Availability)를 우선한다.

Staff+ 엔지니어에게 System Design은 의견의 근거 설계다:

"왜 Cassandra 대신 Postgres?"
"왜 Multi-region 필요?"
"왜 이 Alert Threshold?"

각 질문에 실제 숫자와 Trade-off 수학으로 답할 수 있는 것이 Staff+와 Senior의 분수령.

시작은 3가지면 된다:

이번 주 회사 시스템 한 컴포넌트 수학으로 분석 (QPS·Latency·Cost).
이번 달 20 시나리오 중 3개 직접 설계.
다음 분기 Top 5 오픈소스 소스 1개 Deep Dive.

Staff+ 정체성은 오늘 읽는 코드의 근거에서 시작된다.

다음 글 예고 — "Rust 완전 가이드: Ownership·Lifetime·async·Tokio·Axum·실전 프로젝트까지"

Season 2의 두 번째는 언어 Deep Dive. 다음 글은:

Rust의 언어적 야망
Ownership·Borrowing·Lifetime 완전 이해
Trait·Generic·Zero-cost Abstraction
async/await·Tokio 동시성 모델
Axum·Actix Web Framework
실전 Rust 프로젝트 5가지
2024~2025 Rust 생태계 현황

시스템 프로그래밍의 현대적 표준, 다음 글에서 이어진다.