흩어진 블로그·논문·강의를 한 권의 학습 백과로 모은, 빅테크 시스템 디자인 인터뷰의 사실상 표준 교재.
왜 이 리포가 표준 교재가 됐는가.
"코딩 인터뷰"는 알고리즘 1문제를 30분에 푸는 게임이라면, 시스템 디자인 인터뷰는 "Bitly 같은 URL 단축기를 1억 명 사용자가 쓰게 설계해보세요"를 45분에 화이트보드에 그리는 게임이다. 답이 하나가 아니라 트레이드오프의 연속이고, 면접관은 후보자가 어떻게 사고하는지를 본다.
문제는 이 영역의 지식이 블로그·논문·강의·실제 회사 사례에 흩어져 있다는 것. 도네 마틴(Donne Martin, Facebook 테크 리드)이 그 흩어진 자료를 한 권의 GitHub 학습 백과로 모은 결과물이 이 리포다. 그것도 무료, 그것도 20개 언어 이상으로.
한 문장으로 줄이면.
핵심 산출물은 세 가지 — (1) 이론 백과 (CAP·캐싱·샤딩·메시지 큐를 ASCII 다이어그램·표로 정리), (2) 실전 예제 (Pastebin·Twitter·웹크롤러·Mint.com 인터뷰 시뮬레이션), (3) Anki 플래시카드(스페이스드 리피티션으로 영구 학습).
"책장에서 찾고, 인덱스 카드로 외우고, 실전 문제로 적용하는 3중 학습 구조"가 이 리포의 진짜 무기다.
시대적 배경 + 경쟁 우위.
구글·메타·아마존·넷플릭스·우버는 시니어 이상 채용에서 시스템 디자인 인터뷰를 코딩 인터뷰만큼 비중 있게 다룬다. 면접관이 "URL 단축기 Bitly를 설계해보세요"라고 하면, 후보자는 화이트보드에 컴포넌트와 데이터 흐름을 그려야 한다. 이 리포는 그 질문 패턴의 사실상 표준 교재로 자리잡았다.
주니어 → 시니어 전환기에 "시스템 디자인 공부 어떻게 하지?" 질문이 나오면 거의 모든 답변에 등장한다. 한국어 번역도 이슈 #102에서 진행 중.
LLM이 코드를 대신 짜더라도, "이 시스템이 100만 명의 동시접속을 견딜까?"를 판단하는 능력은 사람의 영역으로 남는다. AI에게 좋은 설계 요구를 던지려면 사람이 먼저 시스템 설계의 언어를 알아야 한다.
| 비교 축 | System Design Primer | 유료 강의 / 책 |
|---|---|---|
| 비용 | 완전 무료, CC-BY-4.0 | 수십~수백 달러 |
| 업데이트 | 커뮤니티 PR로 계속 갱신 | 책 출간 시점에 고정 |
| 예제 코드 | Python Jupyter 노트북 포함 | 별도 다운로드 |
| Anki 덱 | 3종 제공 (SD / Exercises / OO) | 대부분 없음 |
| 다국어 | 일·중·한 등 20개 언어 이상 | 원서 언어 한정 |
레이어별로 익혀야 할 기술 전체.
이 리포는 학습 콘텐츠 리포다. npm install이나 docker compose up 같은 게 없다. 대신 우리가 다룰 "기술 스택"은 리포가 가르치는 시스템 설계 기술의 지도다.
| 프로토콜 | 특징 | 대표 사용처 |
|---|---|---|
| HTTP | 요청/응답, 무상태, 캐싱 가능 | 웹 API 표준 |
| TCP | 연결형, 순서 보장, 재전송 | 웹·SMTP·FTP·SSH |
| UDP | 비연결형, 빠름, 손실 허용 | VoIP·게임·스트리밍 |
| RPC | 원격 함수 호출 (gRPC/Thrift/Avro) | 내부 마이크로서비스 |
| REST | 자원 중심 URI + HTTP 동사 | 퍼블릭 API |
0명 → 1,000만 명, 단계별 진화도.
[Stage 1] 단일 서버 (수십 명)
[사용자] ──HTTP──▶ [웹+앱+DB 한 서버]
[Stage 2] 웹/DB 분리 (수천 명)
[사용자] ──▶ [웹 서버] ──▶ [DB 서버]
[Stage 3] LB + 다중 웹 (수만 명)
┌─▶ [웹1]
[사용자] ──▶ [LB] ──┼─▶ [웹2] ──▶ [DB]
└─▶ [웹3]
[Stage 4] CDN + 캐시 + 마스터-슬레이브 (수십만 명)
[사용자] ──▶ [CDN] ──정적──▶ (브라우저)
│
└─▶ [LB] ──▶ [웹들] ──▶ [캐시(Redis)]
──▶ [DB 마스터] ──복제──▶ [DB 슬레이브들]
[Stage 5] 마이크로서비스 + 샤딩 + 큐 (수백만~수천만)
┌─▶ [User 서비스] ──▶ [User DB 샤드1..N]
[사용자] ──▶ [LB] ──┼─▶ [Feed 서비스] ──▶ [Feed DB] ──▶ [캐시]
├─▶ [Search 서비스] ──▶ [Elasticsearch]
└─▶ [Upload 서비스] ──▶ [Kafka] ──▶ [워커] ──▶ [S3]
Stage 1은 가장 단순하지만 한 대 죽으면 끝(SPOF). Stage 3부터 수평 확장(horizontal scaling)이 시작되고, 웹 서버는 반드시 무상태(stateless)여야 한다 — 세션은 Redis 같은 별도 저장소로. Twitter·Pinterest·Instagram이 모두 Stage 5로 진화했다.
네트워크가 분리(파티션)될 때, 일관성(Consistency)과 가용성(Availability) 중 하나만 선택할 수 있다.
CP 시스템 — 일관성 우선. 파티션 발생 시 응답 거부. 은행·금융처럼 정확함이 생명일 때.
AP 시스템 — 가용성 우선. 오래된 데이터라도 일단 응답. SNS 피드·DNS·이메일처럼 잠깐 다른 값이어도 괜찮을 때.
단톡방에서 누군가 메시지를 보냈는데 잠시 인터넷이 끊겼다 다시 연결되면 메시지가 시간차로 표시된다. 그 사이에는 누구는 봤고 누구는 못 본 상태. SNS는 그래도 일단 동작하니 AP, 은행 송금은 절대 그러면 안 되니 CP.
| 가용성 | 연간 다운타임 | 월간 다운타임 |
|---|---|---|
| 99.9% (three 9s) | 8시간 45분 | 43분 49초 |
| 99.99% (four 9s) | 52분 35초 | 4분 23초 |
| 99.999% (five 9s) | 5분 15초 | 26초 |
SaaS의 SLA는 보통 99.9% ~ 99.99%. five 9s는 통신·금융처럼 미션 크리티컬한 시스템에서나 시도한다.
L1 캐시 참조 0.5 ns L2 캐시 참조 7 ns 메인 메모리 참조 100 ns 1KB를 1Gbps로 전송 10,000 ns (10 µs) SSD에서 4KB 랜덤 읽기 150,000 ns (150 µs) 같은 데이터센터 왕복 500,000 ns (500 µs) HDD 탐색 10 ms 캘리포니아 ↔ 네덜란드 150 ms
이 표가 왜 중요한가? 면접에서 "이 시스템이 1초에 몇 요청 처리 가능할까?"를 봉투 뒷면 계산으로 추정할 때 쓰인다. 메모리 vs 디스크 vs 네트워크 호출의 비용 차이를 머릿속에 박아두는 게 시스템 설계의 출발점.
읽기 트래픽은 슬레이브로, 쓰기는 마스터로. 읽기:쓰기가 보통 9:1인 서비스에서 가장 먼저 도입하는 스케일 기법. 단점은 복제 지연(replication lag)과 마스터가 죽었을 때의 페일오버 복잡도.
큰 DB를 키 기반으로 여러 DB에 분산. 단순 모듈로(user_id % 4)는 샤드 추가 시 거의 모든 데이터가 이동한다. 컨시스턴트 해싱이 이 이동량을 최소화하는 표준 해법 — 캐시·DB·CDN 어디서나 쓰인다.
"이메일 발송·썸네일 생성·알림 전송"처럼 사용자가 기다릴 필요 없는 작업은 큐로 보내고 워커가 비동기 처리. 응답 시간 단축 + 트래픽 평탄화 + 실패 재시도를 한 번에 얻는다.
면접관이 어떤 시스템을 설계하라 할 때 가장 먼저 "사용자 수, 트래픽, 읽기:쓰기 비율, 데이터 크기"를 확인한다. 9:1 읽기 우세면 Replication·Cache가 먼저, 쓰기 우세면 Sharding·큐가 먼저. 이 4가지가 모든 설계 결정의 시작점.
어디에 뭐가 있는지.
system-design-primer/ ├── README.md # 본체. 1,767줄짜리 시스템 디자인 백과 ├── README-ja.md # 일본어 번역 ├── README-zh-Hans.md # 중국어 간체 ├── README-zh-TW.md # 중국어 번체 ├── TRANSLATIONS.md # 번역 가이드 ├── CONTRIBUTING.md # 기여 가이드 │ ├── solutions/ │ ├── system_design/ # 실전 인터뷰 문제 풀이 │ │ ├── pastebin/ # URL 단축기 / Pastebin 설계 │ │ ├── twitter/ # 트위터 타임라인 + 검색 │ │ ├── web_crawler/ # 분산 웹 크롤러 │ │ ├── mint/ # Mint.com (가계부 + 카테고라이저) │ │ ├── social_graph/ # 소셜 네트워크 친구 그래프 │ │ ├── query_cache/ # 검색엔진용 K-V 스토어 │ │ ├── sales_rank/ # 아마존 카테고리별 판매 랭킹 │ │ ├── scaling_aws/ # AWS에서 수백만 사용자까지 스케일 │ │ └── template/ # 새 문제용 템플릿 │ │ │ └── object_oriented_design/ # OO 디자인 인터뷰 │ ├── hash_table/ # Hash Map 직접 구현 │ ├── lru_cache/ # LRU 캐시 직접 구현 │ ├── call_center/ # 콜센터 라우팅 시뮬레이터 │ ├── deck_of_cards/ # 카드 덱 모델링 │ ├── parking_lot/ # 주차장 시스템 │ └── online_chat/ # 채팅 서버 │ ├── resources/ │ └── flash_cards/ # Anki .apkg 덱 (장기 기억화) │ ├── System Design.apkg │ ├── System Design Exercises.apkg │ └── OO Design.apkg │ ├── images/ # 다이어그램 PNG 모음 ├── epub-metadata.yaml # EPUB 변환 메타데이터 └── generate-epub.sh # README → EPUB 변환 스크립트
solutions/system_design/pastebin/부터 보라. URL 단축기는 시스템 디자인 인터뷰의 "Hello World"이고, 이 폴더 안 README가 요구사항 → 백오브엔벨로프 계산 → 컴포넌트 설계 → 스케일 확장의 4단계 흐름을 그대로 보여준다.
기술 영역마다 무엇을 가져갈지 + 실습 아이디어.
실습: Docker로 MySQL 마스터 1 + 슬레이브 2를 띄우고 binlog 기반 복제 설정. mysqlslap으로 읽기 부하를 슬레이브에 분산했을 때 처리량 변화 측정.
실습: FastAPI 또는 Express로 간단 API + Redis cache-aside 패턴 구현. 일부러 캐시 일관성 문제를 만들고 TTL · write-through로 해결.
실습: 이미지 업로드 → 큐에 작업 발행 → 워커가 썸네일 4개 사이즈 생성. 처음에 동기로 짠 응답 지연과, 큐로 바꾼 후 응답 시간을 비교.
Step 1 — 요구사항 명확화: 사용자는 누구? 트래픽은? 읽기:쓰기 비율은? 데이터 크기는?
Step 2 — 고수준 설계: 주요 컴포넌트와 연결을 화이트보드에 스케치
Step 3 — 핵심 컴포넌트 상세: DB 스키마, API 설계, 알고리즘 깊이
Step 4 — 병목 식별 + 스케일: 어디서 터질지 추론 → LB, 캐시, 샤딩 도입
최소 요구사항과 선택 사항.
| 구성 | 용도 | 비고 |
|---|---|---|
| 웹 브라우저 | README 읽기 | GitHub에서 바로 가능 |
| Anki 데스크탑/모바일 | .apkg 플래시카드 학습 | Win/Mac/Linux/iOS/Android |
| Jupyter Notebook | OO Design .ipynb 실행 | Python 3.x (선택) |
| Pandoc + LaTeX | EPUB 책 변환 | generate-epub.sh (선택) |
실제 실습 환경은 학습 주제에 따라 다르다. "캐싱 실습"이면 Redis Docker 컨테이너, "샤딩 실습"이면 MySQL 여러 인스턴스 식으로 별도 구성.
Docker Desktop은 WSL2 백엔드를 권장한다. 메모리는 최소 8GB를 Docker에 할당해야 MySQL 3대 + Redis + RabbitMQ를 한 번에 띄울 수 있다. 일부 도커 이미지는 ARM(Apple Silicon) 호환 태그를 따로 골라야 한다.
난이도별 실습 — Easy → Hard.
1) solutions/system_design/pastebin/README.md를 먼저 보지 않고 종이에 직접 설계 2) 요구사항 → 백오브엔벨로프 → 컴포넌트 → 스케일 4단계로 자기 답안 작성 3) 그 후 정답 README와 비교 4) 무엇을 놓쳤는지 정리.
배우는 것: 4단계 프레임워크 체화, 인터뷰 답안 작성 감각
1) resources/flash_cards/System Design.apkg 다운로드 2) Anki에 임포트 3) 매일 30장 복습 — 7일이면 200장 1회독 4) CAP·ACID·BASE·sharding·replication이 입에 붙을 때까지 반복.
배우는 것: 스페이스드 리피티션, 시스템 디자인 어휘 영구 기억화
1) FastAPI + PostgreSQL + Redis로 mini-Bitly 2) Base62 해시로 단축 URL 생성 3) Cache-aside 적용 4) Docker Compose로 3개 컨테이너 구성 5) locust로 1시간에 100만 요청 부하 테스트 → 병목 측정.
배우는 것: 실제 API 설계, 캐싱 통합, 부하 테스트, 병목 분석
1) RabbitMQ로 URL 큐 구성 2) 워커가 URL 받아 크롤링 → 결과를 PostgreSQL에 저장 3) 워커 1대 → 5대로 늘리며 처리량 변화 측정 4) 중복 URL 필터(Bloom filter) 추가 5) 워커 죽었을 때 메시지 재배달 확인.
배우는 것: 메시지 큐 패턴, 분산 워커 스케일링, 멱등성 처리
1) 팔로워가 적은 사용자는 fan-out on write(미리 팔로워 타임라인에 푸시) 2) 셀럽(팔로워 100만+)은 fan-out on read(요청 시 가져오기) 3) Redis Sorted Set으로 타임라인 캐싱 4) 두 전략을 하이브리드로 결합.
배우는 것: 핫스팟 회피, 하이브리드 아키텍처, Redis 자료구조 활용
1) 본인이 만든 프로젝트(블로그·웹앱) 하나 선택 2) "사용자 100만 명까지 스케일하려면?" 가정 3) 본 리포 4단계 프레임워크에 따라 설계 문서 작성 4) 면접용 포트폴리오 / 회사 내 RFC로 활용 가능.
배우는 것: 본인 프로젝트를 시스템 디자인 관점으로 재해석, 문서화 능력
주차별로 따라가면 시스템 디자인 인터뷰 통과 수준.
Step 1 영상 + Performance vs Scalability 섹션. 외부 자료: Harvard Scalability Lecture (YouTube).
CAP + Consistency/Availability Patterns 섹션. 외부 자료: Designing Data-Intensive Applications 5~7장.
DNS · CDN · Load balancer 섹션. 외부 자료: NGINX 공식 가이드.
Database 섹션 전체. 외부 자료: High Performance MySQL.
Key-Value / Document / Wide-Column / Graph. 외부 자료: DynamoDB 논문, Cassandra 아키텍처.
Cache 섹션. 외부 자료: Redis in Action.
Asynchronism 섹션. 외부 자료: Kafka: The Definitive Guide.
solutions/system_design/ 전체 풀이. 실제 모의 면접 시뮬레이션.
자주 마주칠 단어들.
user_id % 4로 4개 샤드에 분산. 핫스팟이 단점.공식 · 강의 · 학습 리소스.
resources/flash_cards/System Design.apkg를 Anki에 임포트하고 첫 30장 복습. 단어가 입에 붙기 시작한다.