『가상 면접 사례로 배우는 대규모 시스템 설계 기초』를 읽는 대신 각 장을 직접 만들어보기로 했다
시스템 설계 인터뷰 책 한 권을 요약하는 대신, 처리율 제한 장치부터 유튜브·구글 드라이브 설계까지 각 장의 시스템을 실제로 Docker/미니 서비스로 구현하며 검증하는 학습 로드맵. 13개 시리즈 계획과 우선순위.
왜 요약이 아니라 구현인가
『가상 면접 사례로 배우는 대규모 시스템 설계 기초』(System Design Interview - An Insider's Guide)는 면접 대비용으로 잘 알려진 책이다. 처리율 제한 장치, 안정 해시, 키-값 저장소, URL 단축기, 채팅 시스템 등 15개 장이 각각 하나의 시스템 설계 문제를 다룬다.
문제는 책을 읽고 다이어그램을 눈으로 따라가는 것과, 그 설계가 실제로 그렇게 동작하는지 아는 것은 다른 문제라는 점이다. "안정 해시를 쓰면 노드 추가 시 재배치되는 키가 적다"는 문장을 읽는 것과, 실제로 노드를 하나 추가했을 때 몇 퍼센트가 재배치되는지 코드로 재보는 것 사이에는 큰 차이가 있다. DevOps 학습 로드맵에서 "실제로 손을 움직여야 뭐가 어떻게 망가지는지 안다"는 걸 이미 겪었던 터라, 이 책도 같은 방식으로 접근하기로 했다 - 각 장의 시스템을 실제로 Docker/미니 서비스로 구현하고, 책이 말하는 트레이드오프가 실측으로도 성립하는지 확인한다.
목표
15개 장 중 13장(규모 확장성 기초, 개략적 추정, 면접 공략법)은 특정 시스템이 아니라 개념·방법론이라 1장 하나로 묶고, 415장(처리율 제한 장치 ~ 구글 드라이브)은 각 장마다 실제로 구현 가능한 미니 시스템이라 하나씩 만든다. 총 13개 시리즈.
진행 원칙: 책의 완성된 아키텍처를 먼저 베끼지 않는다. 문제 상황(예: "고정 크기 윈도우 알고리즘은 경계에서 트래픽이 튄다") → 직접 구현해서 그 문제를 재현 → 책이 제시하는 해법으로 고쳐서 실제로 해소되는지 확인, 순서로 간다. DevOps 로드맵의 "기록 원칙"(막혔다가 뚫은 지점을 남긴다)을 그대로 가져온다.
계획: 13개 시리즈
각 시리즈의 완료 조건은 동일하다 - 실제 구현 + 부하/시나리오 테스트로 트레이드오프 검증 + 블로그 글 1편.
| 시리즈 | 책 장 | 직접 구현 범위 | 상태 |
|---|---|---|---|
| 1. 사용자 수에 따른 규모 확장성 | 1~3장 | 단일 서버 → LB+캐시+DB 복제까지 Docker Compose로 단계적 확장, 단계마다 처리량 실측 | 절차 정리됨 |
| 2. 처리율 제한 장치 | 4장 | Redis+Lua 슬라이딩 윈도우 로그 구현, 고정 윈도우와 경계 트래픽 비교 실측 | 계획 |
| 3. 안정 해시 | 5장 | 해시 링 시뮬레이터 구현, 노드 추가/제거 시 재배치 비율을 일반 모듈러 해싱과 비교 | 계획 |
| 4. 키-값 저장소 | 6장 | 벡터 시계 기반 버전 관리 + 일관성 없는 해싱 복제를 갖춘 미니 KV 스토어 | 계획 |
| 5. 유일 ID 생성기 | 7장 | Snowflake 알고리즘 직접 구현 (aws-k8s-lab에서 다룬 것과 별개로 순수 알고리즘 검증) | 계획 |
| 6. URL 단축기 | 8장 | 실제 배포 + Base62 인코딩, 캐시 적용 전/후 응답시간 비교 | 계획 |
| 7. 웹 크롤러 | 9장 | robots.txt 준수, 중복 URL 필터링(블룸 필터), 정중한 크롤링(rate limit) 구현 | 계획 |
| 8. 알림 시스템 | 10장 | 큐 기반 발송 + 재시도 + 우선순위, 실패 시나리오 주입 | 계획 |
| 9. 뉴스 피드 시스템 | 11장 | Fan-out on write / read 둘 다 구현해 팔로워 수에 따른 지연·저장공간 트레이드오프 실측 | 계획 |
| 10. 채팅 시스템 | 12장 | WebSocket 기반 미니 채팅 서버, 온라인 상태·읽음 확인 | 계획 |
| 11. 검색 자동완성 | 13장 | Trie 직접 구현, 데이터 늘어날 때 응답시간 변화 실측 | 계획 |
| 12. 유튜브 설계 | 14장 | 영상 업로드 → 트랜스코딩 파이프라인 미니 버전 (실제 트랜스코딩 포함) | 계획 |
| 13. 구글 드라이브 설계 | 15장 | 파일 동기화 + 버전 관리 + 청크 단위 업로드 미니 버전 | 계획 |
"절차 정리됨"은 무엇을 어떤 순서로 구현할지 정리해둔 상태를 뜻하고, "계획"은 아직 그 단계도 시작 전이라는 뜻이다. 시리즈 1을 끝낸 뒤 순서대로 진행하되, 막히면 다음 시리즈를 먼저 진행해도 된다.
원리 체크리스트
시리즈를 마쳤다고 표시하기 전에, 아래를 남에게 설명할 수 있는지 스스로 확인한다.
| 시리즈 | 스스로 설명할 수 있어야 하는 것 |
|---|---|
| 1 | 수직 확장의 한계, 로드밸런서가 단일 장애점을 어떻게 없애는지, DB 복제가 읽기/쓰기 분리에 왜 유리한지, 캐시가 왜 만능이 아닌지(cache invalidation) |
| 2 | 토큰 버킷·누출 버킷·고정 윈도우·슬라이딩 윈도우 알고리즘의 차이, 왜 분산 환경에서 rate limiter 상태를 Redis 등으로 중앙화해야 하는지 |
| 3 | 왜 노드 추가/삭제 시 모든 키가 재배치되면 안 되는지, 가상 노드(virtual node)가 데이터 쏠림을 어떻게 완화하는지 |
| 4 | CAP 정리에서 이 설계가 어느 쪽을 포기했는지, 벡터 시계가 인과관계를 어떻게 표현하는지 |
| 5 | 시간 기반 ID가 왜 분산 환경에서 그냥 auto-increment로 안 되는지, 시계가 역행하면 어떻게 되는지 |
| 6 | 캐시가 응답시간에 실제로 얼마나 기여하는지, 캐시 미스가 몰릴 때(cache stampede) 무슨 일이 생기는지 |
| 7 | 블룸 필터가 "없다"는 확신은 주지만 "있다"는 확신은 못 주는 이유, 정중한 크롤링이 왜 인프라 문제이기도 한지 |
| 8 | at-least-once 전달과 정확히 한 번(exactly-once) 전달의 차이, 재시도가 왜 멱등성을 요구하는지 |
| 9 | fan-out on write가 유명인 계정(하이팬아웃)에서 왜 무너지는지, 하이브리드 접근이 이 문제를 어떻게 완화하는지 |
| 10 | WebSocket이 왜 폴링보다 나은지와 그 대가(커넥션 유지 비용), 온라인 상태를 어떻게 스케일 가능하게 관리하는지 |
| 11 | Trie가 일반 문자열 검색보다 자동완성에 유리한 이유, 데이터가 커질 때 이 구조가 어떻게 무너지기 시작하는지 |
| 12 | 트랜스코딩이 왜 비동기·큐 기반이어야 하는지, CDN이 없으면 어떤 병목이 생기는지 |
| 13 | 청크 단위 업로드가 왜 필요한지, 여러 기기 간 동시 편집 충돌을 어떻게 다루는지 |
기록 원칙
DevOps 로드맵과 동일하다 - 핵심 개념이 걸린 부분은 완성본부터 베끼지 않고 개념 → 뼈대 → 직접 채우기 순서로 가고, 막혔다가 뚫은 지점을 삭제하지 않고 기록한다. 각 시리즈는 "책이 맞다고 확인됨"으로 끝나는 게 아니라, 필요하면 "이 랩 규모에서는 책의 해법이 오히려 과했다" 같은 반대 결론도 그대로 남긴다.