7강

시스템 설계 기초 — 대규모 서비스 설계 면접 완전 정복

3 조회 1

시스템 설계 면접의 구조와 접근법을 익히고, URL 단축기·채팅 서비스·뉴스피드 등 자주 출제되는 설계 문제를 단계별로 풀어가는 프레임을 완성한다.

이번 강에서 배울 것

  • 시스템 설계 면접 4단계 프레임
  • 핵심 개념: 수평 확장, 로드 밸런서, 캐시, CDN, 샤딩
  • CAP 정리 — 분산 시스템의 기본 원리
  • 자주 출제되는 설계 문제 3가지 풀이
  • 면접관이 원하는 답변 스타일

시스템 설계 면접이란?

시스템 설계 면접은 "인스타그램을 설계하라", "URL 단축 서비스를 만들어라" 같은 열린 질문에 답하는 면접입니다. 정답이 없으며, 면접관은 설계 과정과 트레이드오프 이해도를 봅니다. 보통 45~60분 진행됩니다.

시스템 설계에서 "완벽한" 설계는 없습니다. 면접관은 트레이드오프를 인식하고, 요구사항에 맞게 합리적인 선택을 내리는 능력을 봅니다.

시스템 설계 면접 4단계 프레임

Step 1. 요구사항 명확화 (5분)
기능적 요구사항:
- "어떤 기능이 핵심인가요?"
- "읽기와 쓰기 중 어느 게 더 빈번한가요?"

비기능적 요구사항:
- "예상 사용자 수는요? DAU?"
- "데이터 보존 기간은요?"
- "가용성이 중요한가요, 일관성이 중요한가요?"

Step 2. 개략적 설계 (10분)
클라이언트, API, 서버, DB, 캐시 큰 그림 그리기
"일단 단순하게 시작하고 이후 확장합니다"

Step 3. 상세 설계 (20분)
병목 지점 식별 후 해결 방안 제시
핵심 컴포넌트 상세 설명

Step 4. 마무리 (5분)
개선 가능한 부분, 모니터링, 장애 대응 언급
"제가 놓친 부분이 있을까요?" 질문

핵심 개념 6가지

개념설명사용 시점
수평 확장(Scale-out)서버 수 늘리기트래픽 급증, 무중단 확장 필요 시
로드 밸런서요청을 여러 서버에 분산서버 2대 이상 운용 시 필수
캐시자주 쓰는 데이터 메모리 저장 (Redis)DB 부하 줄이기, 읽기 성능 향상
CDN정적 파일을 사용자 가까운 서버에서 제공이미지, JS, CSS, 동영상
메시지 큐비동기 작업 처리 (Kafka, RabbitMQ)이메일 발송, 알림, 로그 처리
DB 샤딩데이터를 여러 DB에 분산 저장단일 DB 한계 돌파, 대용량 데이터

CAP 정리

분산 시스템은 세 가지 속성 중 두 가지만 동시에 보장할 수 있다:

C — Consistency (일관성): 모든 노드에서 같은 데이터
A — Availability (가용성): 모든 요청에 응답
P — Partition Tolerance (분단 내성): 네트워크 분리 시에도 동작

실제 분산 시스템:
네트워크 분리(Partition)는 피할 수 없음 → P는 항상 필요
따라서 선택은 CP vs AP

CP 시스템 (일관성 우선):
예: HBase, ZooKeeper
언제: 은행 잔고, 재고 수량 (정확성이 중요)

AP 시스템 (가용성 우선):
예: Cassandra, DynamoDB, DNS
언제: 소셜 미디어 피드, 캐시 (약간의 불일치 허용)

자주 출제되는 설계 문제 — URL 단축기

요구사항:
- 기능: 긴 URL을 짧은 URL로 변환, 리디렉션
- DAU: 100만, 읽기:쓰기 = 10:1

핵심 설계 결정:

단축 키 생성:
방법 1: MD5 해시 → 처음 7자리 사용
         충돌 가능성 → DB 확인 필요
방법 2: Base62 인코딩 (0-9, a-z, A-Z)
         7자리 = 62^7 = 약 3.5조 가지 → 충분
방법 3: 분산 ID 생성기 (Snowflake)

DB 선택:
읽기 많고 데이터 간 관계 없음 → NoSQL (Cassandra, DynamoDB)
key: short_url, value: {original_url, created_at, user_id}

캐시 전략:
자주 접근하는 URL (인기 링크) Redis 캐시
LRU (최근 미사용 제거) 정책으로 메모리 관리

리디렉션:
301 (영구): 브라우저 캐시 → 서버 부하 감소
302 (임시): 매번 서버 통과 → 분석/추적 가능

자주 출제되는 설계 문제 — 채팅 서비스

핵심 기술 선택:

실시간 연결 방식:
폴링(Polling): 클라이언트가 주기적으로 새 메시지 요청 → 비효율
롱 폴링: 서버가 새 메시지 있을 때까지 연결 유지
WebSocket: 양방향 지속 연결 → 채팅에 최적

메시지 저장:
최근 메시지: Redis (빠른 접근)
오래된 메시지: Cassandra (시계열 데이터, 수평 확장 유리)

1:1 채팅 vs 그룹 채팅:
1:1: 두 사용자 ID로 고유 채널 ID 생성
그룹: 채널 ID 기반, 멤버 목록 관리

온라인 상태:
Heartbeat: 클라이언트가 5초마다 신호 전송
Redis에 "user:online:{id}" TTL=10초로 저장
TTL 초과 시 오프라인으로 표시

강의 핵심 요약

  • 4단계 프레임: 요구사항 명확화 → 개략 설계 → 상세 설계 → 마무리
  • CAP 정리: 은행은 CP(일관성), 소셜 피드는 AP(가용성) 우선
  • 채팅은 WebSocket, URL 단축기는 Base62 + NoSQL + Redis 캐시
  • 다음 강: CS 단골 질문 — 네트워크, OS, DB 완전 정리

관련 검색어  ·  시스템 설계 면접, 대규모 서비스 설계, CAP 정리, URL 단축기 설계, 채팅 서비스 설계, 로드 밸런서, DB 샤딩

채용정보
공지사항
인사이트
MY