System Design 전체 지도
3줄 요약
- System Design은 기술 이름을 나열하는 일이 아니라 요구사항을 API, 트래픽, 상태, 장애 경계, 운영 지표로 번역하는 일이다.
- 좋은 설계는 먼저 가장 단순한 구조를 잡고, 어떤 요구사항 때문에 cache, queue, replica, shard, circuit breaker가 필요한지 단계적으로 설명한다.
- 설계 선택은 항상 성능, 정합성, 장애 격리, 운영 복잡도 중 무엇을 개선하고 무엇을 악화시키는지 함께 남겨야 한다.
핵심 정리
- 입력은 기능 요구사항, 비기능 요구사항, 트래픽 추정, 데이터 보존, 일관성 요구, 장애 허용 범위다.
- 출력은 API 계약, 컴포넌트 배치, 상태 저장 위치, read/write 경로, 동기/비동기 경계, 관측 지표다.
- 첫 질문은 “사용자가 성공으로 기대하는 결과는 무엇인가?”다.
- 두 번째 질문은 “절대 깨지면 안 되는 상태와 늦게 처리해도 되는 작업은 무엇인가?”다.
- 세 번째 질문은 “피크, 장애, 재시도, 배치가 어느 컴포넌트에 몰리는가?”다.
- 핵심 지표는
p95 latency, error rate, saturation, queue age, cache hit ratio, replication lag다.
판단 흐름
- 요구사항을 쓰기 API, 읽기 API, 운영 API로 나눈다.
- 각 API의 성공, 지연, 실패 응답을 정의한다.
- 상태의 owner와 최종 진실의 원천을 정한다.
- 동기 처리와 비동기 처리를 나눈다.
- 병목 후보를 계산하고 가장 단순한 완화책부터 검토한다.
- 장애가 났을 때 포기할 기능과 지킬 기능을 나눈다.
- 운영자가 볼 지표와 알림 기준을 문서에 남긴다.
상세본 구성
01. 요구사항에서 구조로 가는 흐름 상세.md는 기능 문장을 API, 상태, 병목, 장애 경계로 바꾸는 순서를 다룬다.02. 백엔드 시스템 구성 요소 지도 상세.md는 Gateway, Spring App, DB, Cache, Queue, 외부 API, Observability의 책임을 분리한다.03. 성능 확장성 신뢰성 트레이드오프 상세.md는 빠르게 만드는 선택이 정합성, 비용, 복구 난이도를 어떻게 바꾸는지 비교한다.04. 개인 프로젝트와 기업 설계 수준 비교 상세.md는 같은 구조라도 증거, 관측, 복구, 책임 분리 수준이 어떻게 달라지는지 정리한다.05. System Design 학습 로드맵 상세.md는 암기 순서가 아니라 설계 판단을 쌓는 연습 순서를 제시한다.
헷갈리는 지점
- System Design을 큰 그림부터 그리는 일로 오해하기 쉽다. 그림은 설계 결과처럼 보이기 때문이다.
- 실제 시작점은 사용자 결과, 트래픽, 상태, 실패 응답이다.
- 많은 컴포넌트가 있으면 좋은 설계라고 착각하기 쉽다. 복잡한 구조가 성숙해 보이기 때문이다.
- 컴포넌트는 요구사항과 실패 비용을 설명할 수 있을 때만 추가한다.
- 성능 개선은 항상 이득이라고 생각하기 쉽다. p95가 낮아지면 성공처럼 보이기 때문이다.
- cache, queue, replica는 stale data, 중복 처리, lag, 운영 절차를 같이 만든다.
확인 질문
- 확인 질문: System Design에서 가장 먼저 바꿔야 하는 것은 무엇인가?
- 답변: 기능 목록을 사용자 성공 기준, API 계약, 상태 owner, 트래픽, 장애 경계로 바꾸는 것이다.
- 확인 질문: 기술 이름만 나열한 설계가 부족한 이유는 무엇인가?
- 답변: 어떤 요구사항 때문에 필요한지, 없으면 무엇이 깨지는지, 새로 생기는 실패 비용이 무엇인지 알 수 없기 때문이다.
- 확인 질문: 설계 선택은 어떤 축으로 평가해야 하는가?
- 답변: 성능, 정합성, 장애 격리, 운영 복잡도 중 무엇이 좋아지고 무엇이 나빠지는지 함께 평가해야 한다.
참고 자료 기준