시스템 디자인 면접 2025 완전 정복: FAANG이 묻는 30문제와 AI 시대의 새로운 유형

질문 예시:
- "사용자가 할 수 있는 핵심 동작 3가지는 무엇인가요?"
- "읽기와 쓰기 비율이 어느 정도인가요?"
- "데이터는 얼마나 보존해야 하나요?"

확인 사항:
- 가용성: 99.9% vs 99.99% (연간 다운타임 8.7시간 vs 52분)
- 지연 시간: p99 < 200ms 등 구체적 수치
- 일관성: 강한 일관성 vs 최종 일관성
- 규모: DAU, 동시 접속자 수, 데이터 크기

예시: 채팅 시스템의 규모 추정

- DAU: 5천만 명
- 하루 평균 메시지: 40건/사용자
- 총 메시지: 5천만 x 40 = 20억 건/일
- QPS: 20억 / 86,400 = 약 23,000 QPS
- 피크 QPS: 평균의 3배 = 약 70,000 QPS
- 메시지 크기: 평균 100바이트
- 일일 저장소: 20억 x 100B = 200GB/일
- 연간 저장소: 200GB x 365 = 73TB/년

전형적인 고수준 아키텍처 구성:

Client --> Load Balancer --> API Gateway
                               |
                    +----------+----------+
                    |          |          |
                Service A  Service B  Service C
                    |          |          |
                 DB (SQL)  Cache     Message Queue
                              |          |
                           DB (NoSQL)  Worker

딥다이브 영역 예시:

1. 데이터베이스 스키마 설계
   - 테이블 구조, 인덱스, 파티셔닝 전략

2. API 설계
   - 엔드포인트, 요청/응답 형식, 에러 처리

3. 핵심 알고리즘
   - 뉴스 피드: Fan-out on write vs Fan-out on read
   - 검색: 역인덱스 구조
   - 추천: 협업 필터링 vs 콘텐츠 기반 필터링

체크리스트:
- 단일 장애점(SPOF) 식별 및 제거
- 데이터 복제 전략 (리더-팔로워, 멀티 리더)
- 장애 감지 및 자동 복구 (Health Check, Circuit Breaker)
- 모니터링 지표 (Latency, Error Rate, Throughput)
- 알림 체계 (PagerDuty, Slack 연동)

수직 확장 예시:
  서버 1대 (4 CPU, 16GB RAM) → 서버 1대 (32 CPU, 128GB RAM)

수평 확장 예시:
  서버 1대 → 서버 10대 (각 4 CPU, 16GB RAM) + Load Balancer

L7 로드 밸런서 라우팅 예시:

/api/users/*  --> User Service Cluster
/api/orders/* --> Order Service Cluster
/api/search/* --> Search Service Cluster
/static/*     --> CDN Origin

읽기 요청 흐름:
1. 캐시에서 데이터 조회
2. 캐시 히트 → 데이터 반환
3. 캐시 미스 → DB에서 조회 → 캐시에 저장 → 반환

장점: 필요한 데이터만 캐시, 캐시 장애 시 DB로 폴백
단점: 첫 요청 항상 느림, 캐시와 DB 불일치 가능

쓰기 요청 흐름:
1. 캐시에 데이터 쓰기
2. 캐시가 동기적으로 DB에 기록
3. 완료 응답

장점: 캐시와 DB 항상 일치
단점: 쓰기 지연 증가, 불필요한 데이터도 캐시

쓰기 요청 흐름:
1. 캐시에 데이터 쓰기
2. 즉시 완료 응답
3. 비동기적으로 배치 처리하여 DB에 기록

장점: 쓰기 성능 극대화
단점: 캐시 장애 시 데이터 유실 위험

1. 범위 기반 샤딩 (Range-based)
   - user_id 1~100만 → Shard 1
   - user_id 100만~200만 → Shard 2
   - 장점: 범위 쿼리 효율적
   - 단점: 핫스팟 발생 가능

2. 해시 기반 샤딩 (Hash-based)
   - hash(user_id) % N → Shard 번호
   - 장점: 균등 분배
   - 단점: 범위 쿼리 비효율, 리밸런싱 복잡

3. 디렉토리 기반 샤딩
   - 조회 테이블로 관리
   - 장점: 유연한 매핑
   - 단점: 조회 테이블이 단일 장애점

Kafka 아키텍처 예시:

Producer --> Topic (Partition 0) --> Consumer Group A
                                 --> Consumer Group B
         --> Topic (Partition 1) --> Consumer Group A
                                 --> Consumer Group B
         --> Topic (Partition 2) --> Consumer Group A
                                 --> Consumer Group B

- 파티션: 병렬 처리 단위
- Consumer Group: 독립적 소비
- Offset: 소비 위치 추적

CDN 동작 원리:

사용자(한국) --> 한국 엣지 서버 (캐시 히트) --> 즉시 응답
                                (캐시 미스) --> 오리진 서버(미국) --> 캐시 저장 --> 응답

Pull CDN: 첫 요청 시 오리진에서 가져와 캐시 (CloudFront, Cloudflare)
Push CDN: 미리 콘텐츠를 배포 (대용량 정적 파일에 적합)

REST 예시:
GET /api/v1/users/123
GET /api/v1/users/123/orders?page=1&limit=10

gRPC 예시:
service UserService {
  rpc GetUser(GetUserRequest) returns (User);
  rpc ListOrders(ListOrdersRequest) returns (stream Order);
}

GraphQL 예시:
query {
  user(id: "123") {
    name
    orders(first: 10) {
      id
      total
    }
  }
}

기본 해싱의 문제:
  hash(key) % N = 서버 번호
  N이 변경되면 거의 모든 키가 재매핑됨

Consistent Hashing:
  - 해시 공간을 원형(0 ~ 2^32-1)으로 구성
  - 서버와 키 모두 원 위에 배치
  - 키는 시계 방향으로 가장 가까운 서버에 할당
  - 서버 추가/삭제 시 인접 구간만 영향

가상 노드 (Virtual Nodes):
  - 각 물리 서버를 여러 가상 노드로 매핑
  - 부하를 더 균등하게 분배
  - 서버 성능 차이에 따라 가상 노드 수 조절 가능

동작 원리:
1. 고정 크기의 버킷에 일정 속도로 토큰 추가
2. 요청마다 토큰 1개 소비
3. 토큰이 없으면 요청 거부 (HTTP 429)

파라미터:
- 버킷 크기: 100 (순간 최대 요청)
- 리필 속도: 10개/초 (평균 처리 속도)

동작 원리:
1. 각 요청의 타임스탬프를 정렬된 로그에 기록
2. 현재 시간 기준 윈도우(예: 1분) 밖의 기록 제거
3. 윈도우 내 요청 수가 한계를 초과하면 거부

장점: 정확한 윈도우 경계 처리
단점: 메모리 사용량 높음 (모든 타임스탬프 저장)

방법 1: 중앙 집중식 (Redis 기반)
  - 모든 서버가 Redis의 카운터 공유
  - 정확하지만 Redis가 병목/장애점

방법 2: 로컬 + 동기화
  - 각 서버에서 로컬 카운팅
  - 주기적으로 중앙과 동기화
  - 빠르지만 약간의 초과 허용

핵심 설계 포인트:
1. 단축 URL 생성: Base62 인코딩 vs 해시 (MD5/SHA256 절단)
2. 충돌 처리: DB 유니크 제약 + 재시도 vs 카운터 기반
3. 리다이렉션: 301 (영구) vs 302 (임시) 선택 근거
4. 캐시: 자주 접근되는 URL을 Redis에 캐시 (80/20 법칙)
5. 분석: 클릭 수, 지역, 디바이스 추적

Fan-out on Write (Push 모델):
- 글 작성 시 모든 팔로워의 피드에 즉시 기록
- 장점: 읽기 빠름
- 단점: 팔로워가 많은 사용자(셀럽)의 쓰기 비용 높음

Fan-out on Read (Pull 모델):
- 피드 조회 시 팔로워 목록에서 실시간 집계
- 장점: 쓰기 비용 낮음
- 단점: 읽기 느림

하이브리드 (실전 해답):
- 일반 사용자: Push 모델
- 셀럽 (팔로워 100만+): Pull 모델
- 합쳐서 최종 피드 생성

아키텍처:
1. 접속 관리: WebSocket 서버 + 연결 상태 저장소
2. 메시지 전달: 1:1은 직접 전달, 그룹은 Fan-out
3. 오프라인 처리: 메시지 큐에 저장 후 재접속 시 전달
4. 읽음 확인: 별도 서비스로 분리
5. 메시지 저장: 시간순 정렬에 최적화된 DB 선택
   - HBase/Cassandra (넓은 열 저장소)

추천 시스템 전체 파이프라인:

데이터 수집 --> Feature Store --> 모델 훈련 --> 모델 레지스트리
     |                              |                |
사용자 행동 로그              오프라인 배치         A/B 테스트
클릭, 구매, 시청            일일/주간 갱신      챔피언/챌린저
     |                              |                |
     v                              v                v
실시간 특성 계산  -->  후보 생성  -->  랭킹  -->  재랭킹  -->  표시
                    (Retrieval)  (Scoring)  (Re-ranking)

핵심 컴포넌트:
1. Feature Store: 오프라인(배치) + 온라인(실시간) 특성 관리
2. Candidate Generation: ANN(근사 최근접 이웃)으로 후보 1000개 선별
3. Ranking Model: 후보를 정밀 모델로 점수화 (딥러닝)
4. Re-ranking: 비즈니스 규칙, 다양성, 신선도 적용

LLM 서빙 아키텍처:

요청 --> API Gateway --> 요청 라우터 --> GPU 클러스터
                           |               |
                      토큰 제한기     모델 인스턴스 (vLLM)
                      큐 관리자          |
                           |         KV Cache 관리
                      응답 스트리밍 <---  |
                           |
                      비용 추적기

핵심 최적화 기법:
1. KV Cache: 이전 토큰의 Key/Value를 캐싱하여 중복 계산 방지
2. Continuous Batching: 동적으로 요청을 배치 처리
3. PagedAttention: 메모리를 페이지 단위로 관리 (vLLM)
4. 양자화: FP16 → INT8/INT4로 모델 크기 축소
5. Speculative Decoding: 작은 모델로 초안 생성 후 큰 모델로 검증

GPU 오토스케일링 고려사항:
- GPU 인스턴스 시작 시간: 3-10분 (CPU 대비 매우 느림)
- 예측 기반 스케일링: 시간대별 트래픽 패턴 사전 학습
- 큐 깊이 기반: 대기 중인 요청 수로 스케일링 트리거
- 비용 최적화: 스팟 인스턴스 활용 + 온디맨드 폴백

RAG 파이프라인 아키텍처:

문서 수집 --> 청킹 --> 임베딩 생성 --> 벡터 DB 저장
                                        |
사용자 질문 --> 쿼리 임베딩 --> 유사도 검색 --> 상위 K개 문서 검색
                                                    |
                              프롬프트 구성 <---------+
                                   |
                              LLM 생성 --> 응답 + 출처 인용

핵심 설계 결정:
1. 청킹 전략: 고정 크기 vs 의미 기반 (문단/섹션)
2. 임베딩 모델: OpenAI Ada-002, Cohere Embed, 오픈소스 모델
3. 벡터 DB: Pinecone (관리형), Milvus (자체 호스팅), pgvector
4. 검색 방식: 순수 벡터 검색 vs 하이브리드 (벡터 + 키워드)
5. 리랭킹: Cross-encoder로 검색 결과 정밀 재정렬

실시간 ML 파이프라인:

이벤트 소스 --> Kafka --> Stream Processor (Flink) --> Feature 계산
                                                         |
                                                    Feature Store
                                                         |
API 요청 --> Model Server --> 추론 결과 --> 비즈니스 로직
                |
           Model Registry (MLflow)

사용 사례:
- 이상 거래 탐지: 결제 이벤트 → 실시간 특성 → 사기 점수
- 실시간 추천: 사용자 행동 → 실시간 임베딩 갱신 → 추천 갱신
- 동적 가격 책정: 수요/공급 신호 → 가격 모델 → 가격 조정

AI 안전장치 아키텍처:

사용자 입력 --> 입력 필터 --> LLM --> 출력 필터 --> 사용자 응답
                 |                      |
            콘텐츠 분류기          환각 감지기
            프롬프트 인젝션 탐지    사실 검증기
            PII 감지/마스킹        독성 필터
                 |                      |
            차단 or 경고           수정 or 차단

설계 포인트:
1. 다층 방어: 입력/처리/출력 각 단계에 필터
2. 비동기 감사: 전체 대화 로그를 비동기로 분석
3. 적응형 규칙: 새로운 공격 패턴에 대한 빠른 규칙 업데이트
4. 인간 참여 루프: 자동화가 불확실한 케이스에 인간 검토
5. 레이턴시 예산: 안전장치가 추가하는 지연 시간 최소화 (목표: 50ms 이하)

연산                          시간
---------------------------  ----------
L1 캐시 참조                   1 ns
L2 캐시 참조                   4 ns
메인 메모리(RAM) 참조           100 ns
SSD 랜덤 읽기                  100 us (마이크로초)
HDD 탐색                      10 ms
같은 데이터센터 네트워크 왕복    0.5 ms
대륙 간 네트워크 왕복           150 ms

기억 팁:
- L1은 RAM보다 100배 빠름
- SSD는 RAM보다 1000배 느림
- HDD는 SSD보다 100배 느림
- 네트워크는 로컬 I/O보다 항상 느림

QPS (Queries Per Second):
  QPS = DAU * 평균 요청 수 / 86,400
  피크 QPS = 평균 QPS * 2~5 (서비스 특성에 따라)

저장소:
  일일 데이터 = 일일 신규 레코드 * 평균 레코드 크기
  연간 데이터 = 일일 데이터 * 365
  총 저장소 = 연간 데이터 * 보존 기간(년) * 복제 계수(보통 3)

대역폭:
  인바운드 = 쓰기 QPS * 평균 요청 크기
  아웃바운드 = 읽기 QPS * 평균 응답 크기

주요 서비스의 대략적 규모:

서비스        DAU          QPS(평균)    저장소
------       --------     ---------   --------
Twitter      5억          30만        매일 수 TB
Instagram    20억         100만       매일 수십 TB
YouTube      20억+        50만+       분당 500시간 업로드
WhatsApp     20억+        수백만      매일 100억 메시지
Google 검색  85억 쿼리/일  10만+       수백 PB 인덱스

2의 거듭제곱 (자주 사용):
- 2^10 = 1,024 (약 1천)
- 2^20 = 1,048,576 (약 100만)
- 2^30 = 1,073,741,824 (약 10억)
- 2^40 = 약 1조 (1TB)

주차별 학습 계획:

1-2주: 기초 개념 (DDIA 핵심 챕터)
  - 확장성, 가용성, 일관성 원리
  - 데이터베이스, 캐시, 메시지 큐 기초

3-4주: 프레임워크 연습 (Alex Xu Vol.1)
  - 45분 프레임워크 체화
  - 쉬운 문제 5개 풀기

5-8주: 실전 문제 풀이 (Alex Xu Vol.2 + Codemia)
  - 중급 문제 10개
  - 주 3-4문제, 타이머 사용

9-10주: 고급 주제 + AI/ML 시스템
  - 분산 시스템 심화
  - LLM 서빙, 추천 시스템

11-12주: 모의 면접
  - 동료와 모의 면접 3-5회
  - 약점 보완 집중 학습

좋은 명확화 질문 예시:
- "파일 업로드와 다운로드 중 어디에 집중할까요?"
- "사용자 규모가 어느 정도인가요? 1억 명 수준인가요?"
- "실시간 공동 편집도 범위에 포함되나요?"
- "모바일과 웹 모두 지원해야 하나요?"

트레이드오프 분석 예시:

질문: "메시지 저장소로 Cassandra와 MySQL 중 어떤 것을 선택하시겠습니까?"

좋은 답변 구조:
1. 요구사항 확인: "채팅 메시지는 쓰기가 많고 (Write-heavy),
   시간순 조회가 대부분이며, 강한 일관성보다 가용성이 중요합니다."

2. 옵션 비교:
   - MySQL: ACID 보장, 조인 가능, 하지만 수평 확장이 어렵고
     샤딩 복잡성이 높음
   - Cassandra: 수평 확장 용이, 쓰기 최적화,
     시간순 데이터에 적합, 하지만 조인 불가

3. 결론: "우리 요구사항에서는 쓰기 성능과 수평 확장성이
   핵심이므로 Cassandra를 선택합니다. 사용자 프로필처럼
   관계가 복잡한 데이터는 별도 MySQL에 저장합니다."

확장 시나리오 대응 프레임워크:

현재 규모 (100만 DAU):
- 단일 DB, 읽기 복제본 2대, 캐시 서버 1대

10배 성장 (1000만 DAU):
- DB 샤딩 도입 (사용자 ID 기반)
- 캐시 클러스터 확장 (Redis Cluster)
- CDN 도입 (정적 자산)
- 읽기/쓰기 분리

100배 성장 (1억 DAU):
- 멀티 리전 배포
- 마이크로서비스 분리
- 이벤트 기반 아키텍처 전환
- 전용 검색 엔진 (Elasticsearch)

효과적인 커뮤니케이션 기법:

1. 화이트보드 활용
   - 항상 그림과 함께 설명
   - 데이터 흐름을 화살표로 표시
   - 컴포넌트 이름을 명확히 표기

2. 체크포인트 설정
   - "여기까지 괜찮으시면 다음으로 넘어가겠습니다"
   - "이 부분을 더 깊이 들어갈까요?"

3. 생각 과정 공유
   - 침묵하며 생각하지 말고 사고 과정을 소리 내어 공유
   - "두 가지 옵션이 있는데, A는... B는..."