시스템 설계 기초

🎯 학습 목표

이 강을 마치면 다음을 할 수 있습니다.

• 시스템 설계 면접의 6단계 프레임워크를 적용해 어떤 질문에도 구조적으로 답할 수 있습니다.
• 로드밸런서, CDN, 캐시, DB 분산의 역할과 언제 도입하는지 설명할 수 있습니다.
• URL 단축기 시스템을 처음부터 설계하는 전체 과정을 따라갈 수 있습니다.
• 면접관과 주도적으로 대화하면서 설계를 발전시키는 방법을 알 수 있습니다.

🏗️ 시스템 설계 면접이란 무엇인가

이 섹션에서는 시스템 설계 면접의 목적과 평가 기준, 주니어도 준비해야 하는 이유를 살펴보겠습니다.

시스템 설계 면접은 "트위터 같은 SNS를 설계해보세요"나 "카카오톡 같은 채팅 앱의 백엔드를 설계해보세요"처럼 대규모 시스템을 처음부터 설계하는 문제입니다. 정해진 정답이 없고, 면접관과 40~60분 동안 대화하면서 설계를 발전시켜 나갑니다.

"주니어 취준생에게 시스템 설계가 왜 필요한가요?"라는 질문을 자주 받습니다. 시니어 면접에서 주로 나오는 것은 사실이지만, 미드 레벨(경력 3~5년) 기업과 일부 대기업 공채에서도 나오기 시작했습니다. 또한 알고리즘 면접이 끝나고 "이 시스템을 실제 서비스에서 어떻게 확장하겠는가"라는 형태로 연결되는 경우도 많습니다. 기초 개념과 프레임워크만 알아도 완전히 막히는 상황은 피할 수 있습니다.

면접관이 평가하는 것은 "얼마나 완벽한 설계를 하는가"가 아닙니다. 요구사항을 빠르게 파악하는 능력, 트레이드오프를 인식하고 설명하는 능력, 막혔을 때 유연하게 방향을 전환하는 능력을 봅니다.

🔢 6단계 시스템 설계 프레임워크

이 섹션에서는 어떤 시스템 설계 질문이 나와도 구조적으로 접근할 수 있는 6단계 프레임워크를 살펴보겠습니다.

이 프레임워크를 외우고 있으면 갑자기 "인스타그램을 설계하세요"라는 질문을 받아도 당황하지 않습니다. 프레임워크가 다음에 무엇을 해야 하는지 알려주기 때문입니다.

1단계 — 요구사항 명확화 (5분)

설계를 시작하기 전에 반드시 요구사항을 명확히 해야 합니다. 면접관은 의도적으로 모호한 질문을 합니다. 이 단계에서 질문하지 않고 바로 설계를 시작하면 잘못된 방향으로 15분을 낭비할 수 있습니다.

물어봐야 할 질문의 예입니다. "이 서비스의 주요 기능은 무엇인가요?" (핵심 기능 3가지만 정하기), "예상 사용자 수는 얼마인가요? DAU는?", "읽기와 쓰기 중 어떤 것이 더 많이 발생하나요?", "데이터 일관성과 가용성 중 어디에 더 집중해야 하나요?"

2단계 — 규모 추정 (5분)

DAU(일 활성 사용자), 초당 요청 수(QPS), 저장 공간이 얼마나 필요한지 추정합니다. 정확한 수치보다 어느 정도 규모의 시스템을 설계하는가를 파악하는 것이 목적입니다. 예를 들어 DAU 1,000만 명, 사용자당 하루 10번 요청이면 QPS ≈ 1,000만 × 10 / 86,400 ≈ 1,157 QPS입니다.

3단계 — API 설계 (5분)

핵심 기능의 API 엔드포인트를 정의합니다. URL 단축 서비스라면 POST /shorten (긴 URL → 단축 URL 생성), GET /{shortUrl} (단축 URL → 원본 URL 리다이렉트) 두 가지가 핵심입니다.

4단계 — 데이터 모델 (5분)

어떤 데이터를 저장하고, SQL과 NoSQL 중 무엇을 쓸지 결정합니다. SQL은 관계형 데이터, 강한 일관성, 트랜잭션이 필요할 때. NoSQL은 대용량 비구조화 데이터, 수평 확장이 필요할 때 적합합니다.

5단계 — 고수준 설계 (10분)

시스템의 주요 컴포넌트와 그 흐름을 다이어그램으로 표현합니다. 클라이언트 → 로드밸런서 → 웹 서버 → 데이터베이스 같은 기본 아키텍처를 먼저 그리고, 캐시·CDN·메시지 큐 등 필요한 컴포넌트를 추가합니다.

6단계 — 상세 설계 (15분)

면접관이 관심 있는 특정 부분을 깊이 파고듭니다. "단축 URL 생성 알고리즘을 더 자세히 설명해주세요"나 "DB 장애 시 어떻게 대응하나요?" 같은 심화 질문을 받으면 이 단계에서 답합니다.

🔧 핵심 시스템 컴포넌트 이해

이 섹션에서는 시스템 설계에서 반복적으로 등장하는 핵심 컴포넌트들의 역할과 도입 시점을 살펴보겠습니다.

로드밸런서(Load Balancer)

다수의 서버에 요청을 고르게 분산시키는 컴포넌트입니다. 단일 서버로는 트래픽을 감당할 수 없을 때 수평 확장과 함께 도입합니다. 장점은 서버 하나가 죽어도 다른 서버로 요청을 전달해 가용성을 높인다는 것입니다. 라운드 로빈, 최소 연결 수, IP 해시 등 다양한 분산 알고리즘이 있습니다.

CDN(Content Delivery Network)

전 세계에 분산된 엣지 서버에 정적 콘텐츠(이미지, CSS, JS)를 캐싱합니다. 사용자에게 지리적으로 가까운 서버에서 콘텐츠를 제공해 응답 속도를 크게 줄입니다. 이미지·영상이 많은 서비스(인스타그램, 유튜브)에 필수적입니다.

캐시(Cache)

자주 조회되는 데이터를 메모리에 임시 저장해 DB 쿼리를 줄이는 것입니다. Redis, Memcached가 대표적입니다. 캐시의 핵심 전략은 캐시 미스 처리입니다. 캐시 어사이드(Cache Aside): 앱이 DB를 직접 조회하고 결과를 캐시에 저장. 라이트 스루(Write Through): 쓸 때 캐시와 DB에 동시에 저장. 캐시 데이터가 오래되어 DB와 다른 상태가 되는 캐시 무효화(Cache Invalidation)가 가장 어려운 문제 중 하나입니다.

DB 분산 — 복제와 샤딩

단일 DB가 부하를 감당하지 못할 때 두 가지 확장 방법이 있습니다. 복제(Replication)는 마스터-슬레이브 구조로 마스터에 쓰고 슬레이브에서 읽습니다. 읽기 부하가 많을 때 효과적입니다. 샤딩(Sharding)은 데이터를 여러 DB에 나누어 저장합니다. 예를 들어 사용자 ID 기준으로 홀수는 DB1, 짝수는 DB2에 저장합니다. 저장 용량과 쓰기 부하를 분산할 수 있지만, 조인 쿼리가 복잡해지는 단점이 있습니다.

📐 URL 단축기 설계 실전 예시

이 섹션에서는 면접에서 가장 자주 나오는 URL 단축기(bit.ly) 시스템을 6단계로 직접 설계해보겠습니다.

요구사항 명확화

• 핵심 기능: 긴 URL을 짧은 URL로 변환 + 짧은 URL 접속 시 원본으로 리다이렉트
• 비기능 요구사항: 단축 URL은 가능한 짧게 (7자), 리다이렉트는 최대 100ms 이내
• 쓰기:읽기 비율 = 1:100 (읽기 중심 서비스)

규모 추정

• 하루 URL 단축 요청: 1억 건 / 30일 ≈ 초당 1,157 QPS (쓰기)
• 리다이렉트: 쓰기의 100배 ≈ 초당 11만 5,700 QPS (읽기)
• URL 하나당 500바이트, 10년 운영: 1억 × 365 × 10 × 500B ≈ 182.5TB

API 설계

두 가지 엔드포인트가 핵심입니다. 단축 URL 생성: POST /api/v1/shorten, 요청 본문에 longUrl을 받아 shortUrl을 반환. 리다이렉트: GET /{shortUrl}, 301 Redirect로 원본 URL로 이동.

데이터 모델

URL 테이블 하나로 충분합니다. id(기본키), shortUrl(7자 문자열), longUrl(최대 2048자), createdAt, expiresAt. 쓰기보다 읽기가 100배 많으므로 shortUrl 컬럼에 인덱스를 걸어야 합니다. DB는 단순한 키-값 조회이므로 NoSQL(Cassandra, DynamoDB)도 적합합니다.

고수준 설계

클라이언트 → 로드밸런서 → 웹 서버 → 캐시(Redis) → DB 순서입니다. 읽기(리다이렉트)가 압도적으로 많으므로 캐시 히트율을 높이는 것이 핵심입니다. 인기 URL 상위 20%가 요청의 80%를 차지하는 패레토 법칙을 활용해, 인기 URL을 Redis에 캐싱하면 DB 부하를 대폭 줄일 수 있습니다.

단축 URL 생성 알고리즘

가장 간단한 방법은 자동 증가 ID를 62진수(0-9, a-z, A-Z)로 변환하는 것입니다. 62^7 = 약 3조 5천억 가지의 고유 URL을 생성할 수 있습니다. 분산 환경에서 ID 생성 충돌을 방지하기 위해 Snowflake ID 같은 분산 ID 생성기를 사용합니다.

🗣️ 면접관과 주도적으로 대화하는 요령

이 섹션에서는 시스템 설계 면접에서 면접관을 리드하는 대화 전략을 살펴보겠습니다.

시스템 설계 면접은 혼자 발표하는 것이 아니라 면접관과의 협업입니다. 면접관은 중간중간 방향을 수정하거나 깊이 파고들 힌트를 줍니다. 이것을 놓치지 마세요.

주도적 대화 4가지 패턴

1. 설계 전에 방향 확인: "A 방법과 B 방법이 있는데, 어느 쪽으로 집중할까요?" 면접관에게 선택권을 줌으로써 그가 보고 싶은 방향을 파악할 수 있습니다.
2. 트레이드오프 명시: "캐시를 도입하면 성능은 좋아지지만 캐시 무효화 로직이 복잡해집니다." 이처럼 트레이드오프를 항상 함께 언급합니다.
3. 면접관의 반응 관찰: 면접관이 "더 자세히 설명해주세요"라고 하면 그 부분이 핵심입니다. 다른 부분은 덜 중요하다는 신호입니다.
4. 모르면 솔직하게: "정확한 구현은 모르지만, 제가 이해한 바로는 ~와 비슷한 방식일 것 같습니다"라고 아는 것과 모르는 것을 구분합니다.

📝 핵심 요약

7강에서 배운 내용을 정리해 보겠습니다.

단계	핵심 행동	시간
1. 요구사항 명확화	핵심 기능 3개, QPS, 읽기/쓰기 비율 확인	5분
2. 규모 추정	DAU→QPS→저장 공간 계산	5분
3. API 설계	핵심 엔드포인트 2~3개	5분
4. 데이터 모델	SQL vs NoSQL 판단, 핵심 테이블 스키마	5분
5. 고수준 설계	컴포넌트 다이어그램 + 주요 흐름	10분
6. 상세 설계	면접관 관심 부분 + 병목·장애 대응	15분

다음 강인 8강 — CS 단골 질문 (네트워크·OS·DB)에서는 기술 면접에서 거의 반드시 나오는 CS 기초 질문들을 네트워크(HTTP·TCP/IP), 운영체제(프로세스·스레드·동기화), 데이터베이스(트랜잭션·인덱스·쿼리 최적화) 세 영역으로 완전히 정리합니다!