URL 단축기 시스템 설계 예시 (URL Shortener System Design Example)

목차

이 문서를 왜 보나

URL 단축기(URL Shortener) 는 시스템 디자인 면접에서 가장 자주 쓰이는 입문형 문제 중 하나입니다.

이 문제는 기능이 단순해서 요구사항 정리와 고수준 구조 설명이 빠르고,
그 안에서 읽기 중심 트래픽, 캐시, 키 생성, 비동기 통계 처리, 확장 방향까지 자연스럽게 설명할 수 있습니다.

즉, URL 단축기는 복잡한 도메인 규칙 없이도
시스템 디자인 답변의 기본 프레임을 보여 주기 좋은 예제입니다.

문제 풀이 순서 자체를 먼저 정리하고 싶다면 실전 화이트보드 면접 가이드 (Whiteboard Interview Guide)를 같이 보면 좋습니다.

문제 정의와 요구사항

예를 들어 다음 문제를 받았다고 가정하겠습니다.

긴 URL을 짧은 URL로 바꾸고, 짧은 URL 접속 시 원본 URL로 리다이렉트하는 시스템을 설계해 보세요.

초기 답변에서는 다음 정도로 범위를 고정하는 편이 좋습니다.

  • 기능적 요구사항
    • 긴 URL을 짧은 URL로 생성
    • 짧은 URL로 접속하면 원본 URL로 리다이렉트
    • 기본 통계는 이번 범위에서 제외하거나 옵션으로 둠
  • 비기능적 요구사항
    • 읽기 트래픽이 쓰기보다 훨씬 많음
    • 리다이렉트 지연 시간은 짧아야 함
    • 같은 short key 충돌은 없어야 함
    • 일부 장애가 나도 조회는 최대한 유지되어야 함

좋은 답변은 “기능은 간단합니다”로 끝나지 않고,
무엇을 이번 범위에 넣고 무엇을 뺄지 먼저 정한다는 점이 중요합니다.

규모 추정

숫자는 정답이 아니지만, 설계 선택을 설명하기 위해 필요합니다.

예를 들어 다음처럼 빠르게 잡을 수 있습니다.

  • 하루 1천만 리다이렉트 요청
  • 하루 100만 단축 URL 생성
  • 읽기:쓰기 비율은 대략 10:1
  • short URL 메타데이터는 비교적 작음

여기서 바로 설계 판단으로 연결합니다.

  • 읽기가 훨씬 많으니 캐시를 먼저 검토
  • short key 충돌이 없도록 키 생성 전략이 중요
  • 리다이렉트는 짧은 지연 시간이 필요하니 읽기 경로를 단순하게 유지

즉, 숫자를 길게 계산하는 것보다
왜 캐시, 복제, 키 생성 이야기를 꺼내는지 근거를 만드는 것이 핵심입니다.

고수준 설계

가장 기본 구조는 다음처럼 잡을 수 있습니다.

Client
  -> Load Balancer
    -> URL Shortener API
      -> Cache
      -> Primary DB
      -> Async Worker (optional)

각 구성 요소의 역할은 다음과 같습니다.

  • API 서버: short URL 생성, 조회 처리
  • Cache: short key -> 원본 URL 매핑 캐시
  • DB: 원본 URL, short key, 메타데이터 저장
  • Worker: 클릭 통계, 비동기 집계 같은 부가 기능 처리

좋은 답변은 그림의 복잡함보다
각 박스가 왜 필요한지와 요청 흐름이 자연스러운지가 중요합니다.

데이터 모델과 저장 전략

화이트보드 면접에서는 “어떤 DB를 쓰느냐”보다
“왜 그 선택이 이 문제에 맞느냐”가 중요합니다.

URL 단축기에서는 보통 다음 정도로 설명하면 충분합니다.

  • 저장소: key-value 성격이 강하므로 RDBMS나 NoSQL 모두 가능
  • 핵심 요구: short key uniqueness, 빠른 조회, 단순한 매핑
  • 초기 선택: 운영 단순성을 위해 RDBMS로 시작 가능
  • 확장 시: 읽기 트래픽 증가에 따라 cache와 replica를 먼저 붙임

키 생성 전략은 자주 꼬리질문으로 이어집니다.

전략 장점 주의점
Auto-increment + Base62 구현이 단순하고 짧은 키 생성 가능 단일 시퀀스 의존, 예측 가능성
랜덤 문자열 분산 생성이 쉬움 충돌 검사 필요
Snowflake 계열 ID + 인코딩 분산 생성에 유리 길이와 운영 복잡도 증가

좋은 답변은 하나를 절대화하지 않고,
초기에는 단순한 키 생성으로 시작하고, 분산 생성 필요가 커지면 전략을 바꿀 수 있다고 말하는 편이 좋습니다.

관련 확장성 감각은 확장성 (Scalability), 저장 전략은 데이터베이스 설계 (Database Design) 와 연결됩니다.

핵심 데이터 흐름

그림 다음에는 생성 흐름과 조회 흐름을 나눠 말하면 안정적입니다.

생성 흐름

  1. 사용자가 긴 URL을 보냄
  2. API 서버가 short key 생성
  3. DB에 short key -> original URL 저장
  4. 결과 short URL 반환

조회 흐름

  1. 사용자가 short URL로 접근
  2. API 서버가 cache에서 short key 조회
  3. cache miss면 DB 조회 후 cache 채움
  4. 원본 URL로 redirect 응답

이렇게 나누면 면접관이 캐시, 저장소, 확장성 중 어느 쪽으로 질문해도 분기하기 쉽습니다.

예를 들어 다음처럼 말하면 좋습니다.

  • 쓰기 경로는 상대적으로 짧고 단순하게 유지하겠습니다.
  • 읽기 경로는 cache hit 비율이 중요하므로 최대한 가볍게 두겠습니다.
  • 클릭 통계는 redirect 경로에서 동기 처리하지 않고 비동기로 넘기겠습니다.

즉, 핵심 요청 경로와 부가 처리 경로를 분리해서 설명하는 것이 좋습니다.

확장 전략

URL 단축기는 단순하지만, 트래픽이 커지면 다음 확장 포인트가 자연스럽게 나옵니다.

  • 읽기 경로 최적화: cache hit를 높여 DB 직접 조회를 줄임
  • 읽기 확장: replica 추가 검토
  • 키 생성 확장: 단일 시퀀스 병목이면 분산 키 생성 전략 검토
  • 부가 기능 분리: 통계, 분석, 만료 cleanup은 비동기 처리

좋은 답변은 처음부터 샤딩이나 복잡한 분산 구조를 꺼내기보다,
단순한 구조로 시작하고 병목이 생기면 점진적으로 확장한다는 방향을 보여주는 답변입니다.

장애와 운영 포인트

대표 병목과 운영 포인트는 다음과 같습니다.

  • DB read hotspot: 인기 short URL에 조회 집중
  • cache miss 증가: DB 부하 상승
  • 키 생성기 병목: 단일 시퀀스나 충돌 검사 비용
  • redirect 경로에 통계 처리 포함: 지연 증가

그래서 다음처럼 방어 전략을 설명할 수 있습니다.

  • 조회가 많은 short key는 cache hit로 최대한 흡수
  • 통계 기록은 비동기 큐로 분리
  • DB는 읽기 확장을 위해 replica를 검토
  • 캐시 장애 시에도 DB 경로로 fallback 가능하게 설계

좋은 답변은 “캐시를 둡니다”보다
어느 병목을 줄이기 위해 어떤 장치를 두는지를 연결해서 설명하는 편이 좋습니다.

트레이드오프 말하는 방법

URL 단축기처럼 간단한 문제도 트레이드오프를 말해야 답변이 단단해집니다.

선택 장점 대가
RDBMS로 시작 운영 단순, 강한 무결성 초대형 읽기 부하에는 별도 확장 필요
Cache 적극 활용 리다이렉트 지연 감소 정합성과 캐시 무효화 고려 필요
랜덤 키 생성 분산 생성 쉬움 충돌 검사 비용
통계 비동기 처리 읽기 경로 단순화 즉시성 포기

말하는 방식도 중요합니다.

  • “초기에는 운영 단순성이 중요하므로 RDBMS + cache로 시작하겠습니다.”
  • “트래픽이 커지면 replica와 더 공격적인 캐싱을 붙이겠습니다.”
  • “클릭 통계는 핵심 redirect 경로를 오염시키지 않도록 비동기로 분리하겠습니다.”

즉, 지금 선택과 나중 확장 방향을 같이 말하는 것이 좋습니다.

면접관이 자주 던지는 꼬리질문

short key 충돌은 어떻게 막나요?

  • auto-increment + encoding이면 충돌을 구조적으로 줄일 수 있음
  • 랜덤 키면 충돌 검사와 재시도 필요
  • 분산 환경에서는 중앙 시퀀스 병목 여부를 같이 설명

특정 URL이 갑자기 엄청 인기 많아지면요?

  • cache hit 비율이 중요해짐
  • 인기 키는 메모리 캐시나 CDN redirect 정책 검토 가능
  • DB 직접 조회를 줄이는 방향으로 설명

통계는 어디서 수집하나요?

  • redirect 응답 자체는 빠르게 끝내고
  • 클릭 이벤트는 비동기로 큐에 넣어 집계
  • 실시간성이 아주 중요하지 않으면 eventual consistency 허용

키 생성기가 죽으면요?

  • 단일 장애점이면 가용성이 떨어짐
  • 분산 키 생성 전략이나 failover 구조 검토 가능
  • 다만 문제 범위가 단순하면 초기에는 운영 단순성을 우선한다고 말해도 됨

삭제나 만료 기능이 들어가면요?

  • soft delete 또는 expiration timestamp 추가
  • cache invalidation과 cleanup 배치 설명
  • 조회 경로에서 만료 검사 위치를 함께 언급

좋은 답변은 꼬리질문마다 새 아키텍처를 갈아엎는 것이 아니라,
기존 구조에서 어느 부분을 확장하는지를 이어서 설명하는 것입니다.

면접 포인트

  • URL 단축기는 단순한 문제라서 답변 구조를 보여 주기 좋은 예제입니다.
  • 요구사항 확인, 규모 추정, 고수준 구조, 데이터 흐름, 병목, 트레이드오프 순서로 설명하면 안정적입니다.
  • 좋은 답변은 cache, 키 생성, 비동기 통계 처리의 이유를 같이 설명합니다.
  • 예시 문제는 단순할수록 좋고, 단순한 문제일수록 꼬리질문 대응이 중요합니다.
  • 지금 선택과 나중 확장 방향을 함께 말하면 답변이 더 실무적으로 들립니다.

참고 자료