한 줄 정의
시스템 디자인 면접 피드백은 교과서적 패턴과 아키텍처 다이어그램 암기에서 벗어나 트래픽 제약 조건, 물리적 한계점, 장애 복구 메커니즘, 트레이드오프(trade-off) 근거를 치열하게 입증해야 함을 보여주는 시니어 엔지니어링 면접 프레임워크다.
핵심 요지
- 구글 L7 스태프 엔지니어 면접 사례에서 단순 URL 단축기 설계 요구(QPS 1,000만 쓰기) 시 NoSQL/Redis 박스 그리기 수준의 암기식 접근은 WAL(Write-Ahead Log) 경합 및 물리적 한계 질문에 바로 무너진다.
- “노드를 무작정 추가하면 된다”는 식의 단순 수평 확장(Horizontal Scaling)은 네트워크 홉과 조율 비용(coordination overhead)을 증가시키며, 핫 키(Hot Key) 및 Thundering Herd 병목을 오히려 악화시킨다.
- 캐시는 무조건 응답을 빠르게 만드는 치트키가 아니며, 롱테일 데이터 구조에서 캐시 히트율이 저조할 경우 불필요한 오버헤드만 가중시킨다.
- L7 수준 평가의 핵심은 시스템 정상 구동 모습이 아니라 예외적 장애 상황(데이터 센터 장애, 디스크 풀, 캐시 다운)에서의 자가 치유(self-healing) 및 트레이드오프 판단 능력에 있다.
상세
수평 확장과 핫 키(Hot Key)의 맹점
URL 단축기 서비스에 대형 이벤트로 폭발적 트래픽이 몰릴 때, 앱 서버 노드만 늘리면 수많은 서버가 DB의 동일한 행이나 캐시의 동일한 키를 일제히 후려치게 된다. 문을 10개로 늘렸으나 내부의 컵케이크 쟁반이 단 하나인 상황(Thundering Herd)과 같다.
이 경우 수평 확장은 병목으로 들이치는 동시 요청의 총량만 증폭시키므로, 동일 요청을 단 1회의 DB 읽기로 병합해 대기시키는 요청 병합(request collapsing) 기술이나 **어댑티브 캐싱(adaptive caching)**을 도입해야 한다.
‘캐시 없음’ 사고방식과 지연 시간 공식
생성된 단축 URL의 90%가 단 1회 클릭 후 버려지는 롱테일 데이터 패턴에서는 캐시 히트율이 고작 10%에 불과하다. 요청의 90%가 캐시 실패(cache miss) 후 DB 조회를 고스란히 거치므로 무조건적인 분산 캐시 도입은 오히려 요청 전체에 불필요한 오버헤드(예: 5ms)와 상태 불일치 리스크만 가중시킨다.
장애의 아키텍처와 카오스 엔지니어링
분산 시스템에서 장애는 필연적이다. 넷플릭스가 프로덕션 서버를 무작위 강제 종료하는 카오스 멍키(Chaos Monkey)를 가동하는 이유는 엔지니어가 시스템 자가 치유(self-healing)를 전제로 아키텍처를 작성하도록 강제하기 위함이다.
L7 스태프 레벨 준비 4대 규칙
- 상자 다이어그램에 비용과 오버헤드 명시: 로드 밸런서나 큐 추가 시 발생하는 지연 시간 및 금전적 비용을 설명한다.
- Naked(무형) 상태에서 출발: 서버 1대와 DB 1대의 기본 아키텍처에서 출발해 물리적 한계 수치에 도달했을 때 점진 확장한다.
- 용량 및 대역폭 기초 산수: 초당 쿼리 수(QPS), 5년 축적 스토리지 용량, 네트워크 대역폭 요구량을 즉석 산정한다.
- 글로벌 장애 리포트(Post-mortem) 탐독: 빅테크 기업들의 실제 설계가 예기치 못한 검은 백조(Black Swan) 이벤트에 무너진 사후 보고서를 분석한다.
예시
- 일관성 vs 가용성: 사용자에게 100% 실시간 최신 데이터를 보여줄 것인가, 지연이 발생하더라도 페이지 로딩을 성사시킬 것인가?
- 복잡도 vs 유지보수성: 50개 마이크로서비스로 쪼갤 것인가, 소수 인원이 관리가능한 모듈러 모놀리스를 유지할 것인가?
충돌
대규모 면접이나 아키텍처 리뷰 시 Redis 등 분산 캐시를 필수 요소로 배치하는 것이 불문율처럼 여겨지지만, 접근 패턴이 롱테일인 영역에서는 캐시 노드가 전체 응답 시간을 늘리는 병목 지점이 되므로 용기 있게 “현시점에는 캐시가 필요 없다”고 주장하는 판단력이 요구된다.