홈 › 시스템 사례 › URL 단축 서비스 CASE · BEGINNER 읽기 20분 검토일 2026-08-29
URL 단축 서비스
짧은 문자열을 발급하는 것보다 이미 퍼진 링크를 되돌리는 일이 더 어렵습니다. 캐시·삭제·만료·악성 URL 차단이 같은 목적지를 보도록 회수 경계를 먼저 정합니다.
운영자 직접 작성·기술 검토 · 최종 검토 2026.08.29
리다이렉트 정책 장애 대응 운영 관점 진도 저장
↗ 30초 핵심 요약
영구 redirect는 성능 옵션이 아니라 회수 가능성을 포기하는 약속입니다. 변경 가능한 링크는 302와 짧은 cache에서 시작하고, 삭제한 short key는 다른 목적지에 재사용하지 않아 오래된 캐시가 새 주소로 연결되지 않게 합니다.
키 발급 Base62 + unique insert
읽기 우선순위 Edge cache → DB
철회 안전성 Tombstone + purge
DESIGN DECISION · 설계 판단
짧은 링크의 목적지를 언제 영구로 약속할 것인가?
예시 새 링크
200만/day
설계 가정
예시 피크 읽기
약 34,700 req/s
계산 결과
Base62 7자 공간
약 3.52조
계산 결과
최종 선택
가변 링크는 302·짧은 캐시, 확정 링크만 301/308
목적지 변경·삭제 가능성이 있으면 302와 짧은 Cache-Control에서 시작합니다. 영구 redirect는 회수할 수 없음을 수용할 때만 사용하고 short key는 재사용하지 않습니다.
선택 이유
잘못된 목적지를 고쳐도 브라우저·프록시의 오래된 영구 캐시가 남는 위험을 줄입니다. 삭제·차단 뒤에도 과거 key가 새 목적지로 연결되는 보안 사고를 막습니다. 서비스 캐시와 HTTP redirect 캐시의 purge·TTL을 분리 관측할 수 있습니다.
포기한 대안
모든 링크에 308과 긴 freshness 적용
캐시 효율은 높지만 목적지 오타·철회·정책 변경 뒤 서버가 기존 클라이언트의 이동을 즉시 회수할 수 없습니다.
감수한 단점
302와 짧은 TTL은 원본 redirect 서비스 요청을 늘립니다. 새 short key 교체는 배포 채널과 분석 연속성을 바꿉니다. 영구 정책은 실제 변경률과 삭제 약속을 먼저 검증해야 합니다.
01 · REQUIREMENTS
짧은 주소와 안전한 철회를 함께 만든다 # 요구사항 작성자·방문자·운영자의 경로는 다릅니다. 데이터 모델과 캐시 정책은 리다이렉트 성능뿐 아니라 목적지를 나중에 제거할 수 있는지까지 결정합니다.
R1 생성과 alias 자동 키와 사용자 alias를 같은 도메인 namespace에서 유일하게 관리합니다.
R2 빠른 리다이렉트 GET/HEAD는 cache hit에서 저장소 왕복 없이 목적지로 보냅니다.
R3 수명과 철회 만료·삭제·차단 상태는 어떤 cache layer에서도 목적지보다 먼저 확인합니다.
R4 남용 제어 악성 URL 신호와 계정·도메인·IP 기반 운영 제어를 구분합니다.
02 · HIGH-LEVEL DESIGN
생성·저장·캐시·검사를 서로 분리한다 # 아키텍처 생성의 비동기 검사와 클릭 분석은 리다이렉트의 p99를 막지 않습니다. 단, cache value에는 URL만 아니라 상태·만료·정책 버전이 포함되어야 합니다.
URL 단축 서비스의 두 경로 SVG DIAGRAM · 생성 / 저장 / 캐시 리다이렉트 / Safe Browsing
URL 단축 서비스의 생성, 저장, 캐시 리다이렉트와 악성 URL 검사 흐름 작성자 요청이 키 발급과 링크 저장소를 거쳐 Safe Browsing 검사와 운영자 검토로 이어지고, 방문자는 edge cache나 redirect service를 통해 목적지로 이동한다. 쓰기 경로 · 인증된 작성자 읽기 경로 · 방문자 생성 API auth · idempotency 키 발급 · URL 정책 Base62 · unique insert Link DB status · expiry 악성 URL 검사 Safe Browsing signal 운영자 검토 · 차단 account / domain abuse controls 방문자 GET /aZ91kQ Edge / Redirect cache URL + status + version Redirect service cache miss → DB Location 301/302… 검사 통과 → active 위험 신호 → pending / blocked 중요: 리다이렉트 cache의 TTL과 브라우저·공유 cache가 HTTP 응답을 저장하는 기간은 같은 값이 아닙니다. 삭제·차단은 cache purge와 짧은 TTL로 돕되, 이미 장기 저장된 영구 리다이렉트를 즉시 회수할 수 있다고 가정하지 않습니다.
03 · WRITE / READ FLOW
충돌은 DB에서 확정하고, 읽기는 상태까지 캐시한다 # 쓰기·읽기 무작위 키는 확률적으로 겹칠 수 있습니다. 후보를 다시 뽑는 것과 UNIQUE(domain, short_key)가 거부하는 것을 함께 써야 잘못된 목적지 연결을 막을 수 있습니다.
1 입력·멱등 확인 허용 scheme와 alias를 검사하고 이전 동일 요청 결과를 돌려줍니다.
2 Base62 후보 유일 ID 인코딩 또는 CSPRNG 후보 생성 뒤 고유 삽입을 시도합니다.
3 상태 저장·검사 pending_scan으로 저장하고 검사·정책 판정 뒤 active로 전환합니다.
4 캐시 우선 조회 cache hit에서도 status, expiry, version을 보고 redirect 여부를 결정합니다.
5 비동기 계측 클릭 이벤트는 응답 뒤에 보내고 삭제·차단은 purge로 전파합니다.
04 · TRADEOFFS
리다이렉트 코드는 캐시 수명과 메서드에 관한 약속이다 # 트레이드오프 301·308은 빠르고 캐시에 유리하지만 목적지 변경과 삭제를 되돌리기 어렵습니다. 처음부터 영구로 확정하기보다 링크의 변경 가능성과 메서드 보존 요구를 확인한 뒤 코드를 선택합니다.
선택 캐시·메서드 의미 장점 URL 단축에서의 판단 301 Moved Permanently heuristic freshness 가능, POST→GET 변경 가능 안정된 목적지의 반복 방문 효율 목적지가 정말 고정일 때만 긴 freshness와 함께 사용 302 Found 명시적 캐시 정책 권장, POST→GET 변경 가능 변경·철회 가능한 링크의 보수적 시작점 일반 GET 링크와 짧은 Cache-Control에 적합 307 Temporary Redirect 명시적 캐시 정책 권장, 메서드 보존 임시 이동에서도 메서드·body 보존 비-GET 전달이 의도된 특수 경로만 검토 308 Permanent Redirect heuristic freshness 가능, 메서드 보존 영구 이동의 명시적 메서드 보존 회수 어려움이 허용되는 영구 목적지에 한정 무작위 Base62 후보 충돌 가능, unique insert로 확정 순번 추측을 낮춤 재시도율·난수 품질·키 길이를 운영 지표로 관리
05 · FAILURE MODES
네 가지를 넘는 장애를 상태·지표·복구 검증으로 다룬다 # 장애 6가지 ≋ 캐시 stampede
인기 키가 동시에 miss되어 DB와 redirect p99를 밀어 올립니다.
대응 · single-flight, stale 정책, hot-key rate limit. 피크 재현에서 DB read와 p99를 검증합니다.
# 키 충돌·alias 경쟁
무작위 후보가 겹치거나 두 사용자가 같은 alias를 요청합니다.
대응 · DB unique constraint, 후보 재생성, 원자적 alias 예약. 중복 key 0건을 확인합니다.
× 삭제 purge 지연
철회한 링크가 edge나 L1의 오래된 값으로 잠시 열릴 수 있습니다.
대응 · tombstone, purge 재시도, 짧은 TTL, version 검사. 모든 계층의 버전을 대조합니다.
▣ DB/리전 장애
origin miss가 실패해 정상 링크도 리다이렉트하지 못합니다.
대응 · 다중 AZ 읽기·제한적 stale cache·쓰기 보호. failover 뒤 status/expiry 일치를 확인합니다.
! 검사 공급자 지연
새 링크 판정이 늦거나 타임아웃되어 공개 여부가 불명확해집니다.
대응 · pending 유지, 재시도, 수동 검토. 검사 큐 age와 판단 감사 가능성을 검증합니다.
↯ 피싱 대량 생성
봇이 계정·도메인·IP를 바꾸며 링크와 검사 비용을 폭증시킵니다.
대응 · 단계적 rate limit, CAPTCHA, account kill switch. 우회율과 정상 오류율을 함께 봅니다.
06 · OPERATIONS
보안·관측·비용은 redirect 경로 밖에서 준비한다 # 운영 ⌾ 보안과 개인정보 Safe Browsing은 URL 위험 신호이고, 관리자 abuse control은 계정·도메인·IP·신고를 다루는 별도 제어 평면입니다. URL query의 토큰과 클릭 원문 로그를 최소화합니다.
allowlist · pending_scan · audit
⌁ 관측 가능성 cache hit ratio, redirect p99, key collision retry, purge lag, scan queue age, blocked/expired 응답을 분리해 봅니다. 목적지 URL은 trace에 원문 대신 ID·안전한 해시를 씁니다.
purge_lag_seconds · decision_total
₩ 비용 모델 redirect 본문이 작아도 edge 요청·egress·DB miss·복제·tombstone·검사 호출·수동 검토 비용이 듭니다. hit ratio 95%→90%는 origin read를 두 배로 만듭니다.
cache miss × DB read × replica
면접 모드 · 추가 질문 05:00
“하루 2억 번 열리는 URL 단축 서비스를 설계해 보세요. Base62 키 충돌을 어떻게 확정적으로 막고, 301/302/307/308은 어떤 기준으로 고르며, 이미 캐시된 위험 링크의 철회와 Safe Browsing·관리자 abuse control을 어떻게 설명하겠습니까?”
읽기:쓰기와 cache unique insert redirect cache tombstone + purge 검사와 운영 제어 분리
답변 구조 보기 6단계
먼저 링크 생성/리다이렉트/관리, 공개 여부, 목적지 변경 가능성, 만료·삭제 SLA를 확인한다.
읽기:쓰기가 큰 예시를 세우고 domain + short_key 캐시 우선 조회와 DB fallback을 제안한다.
Base62 순번 방식과 무작위 방식의 충돌·예측 가능성 차이를 설명한다. 무작위 방식은 반드시 unique insert로 확정한다고 말한다.
301/302/307/308의 캐시 기본값과 메서드 보존 차이를 말한 뒤, redirect cache는 즉시 회수할 수 없음을 명시한다.alias·만료·삭제는 상태와 tombstone, purge, 짧은 TTL로 처리하고, 악성 URL 검사와 관리자 abuse control을 서로 다른 계층으로 제시한다.
마지막으로 cache hit ratio, purge lag, scan queue age, blocked/expired 응답, 비용과 오탐을 운영 지표로 연결한다. 이번 선택: 변경 가능성에 맞춰 redirect 상태와 캐시 수명을 함께 정한다. 깨지는 신호: DB 목적지와 실제 사용자 이동 목적지가 다르거나 purge lag가 TTL보다 길어진다. 다음 검증: 브라우저·프록시 캐시를 유지한 상태에서 목적지 변경·삭제·재생성을 시험한다.
INTERVIEW ↔ PRACTICE · 면접과 실무의 차이
잘못 캐시된 308을 회수할 수 없는 상황 설명하기
INTERVIEW · 면접
상태 코드 의미보다 목적지 변경 가능성과 캐시 수명을 먼저 답합니다.
가변 링크는 302와 명시적 짧은 TTL을 씁니다. 영구 redirect는 운영 약속이며 즉시 회수할 수 없음을 말합니다. 삭제된 short key를 재사용하지 않고 tombstone을 남깁니다.
PRACTICE · 실무
브라우저·프록시 캐시를 유지한 채 변경·삭제를 검증합니다.
DB 목적지와 실제 사용자 이동을 비교합니다. purge lag와 영구 cache hit를 관측합니다. 오류 링크는 새 key로 교체하고 구 key는 추적합니다.
NEXT CASE STUDY 실시간 채팅 시스템 설계
→
EDITORIAL NOTES
작성·검토·참고 자료
콘텐츠 원칙 이 문서는 독립적으로 재작성한 한국어 학습 자료입니다. 사실과 학습용 설계 가정을 구분합니다.
작성·기술 검수 프로젝트 운영자가 직접 작성·기술 검토했습니다. 주제별 공식·1차 자료와 명시적인 설계 가정을 확인하며, 독립적인 제3자 검수가 아닙니다. 경력 범위와 검수 원칙 보기
최종 검토 2026-08-29
예상 학습 시간 20분
사실 오류·출처 정정은 문의·정정 페이지 로 알려 주세요.