단축url

URL 단축 서비스는 긴 URL에 대응하는 짧은 주소를 만들고, 그 짧은 주소를 방문한 사용자를 원래 페이지로 보내는 시스템입니다. 핵심은 문자열을 단순히 줄이는 것이 아니라 짧은 키 → 원래 URL의 대응 관계를 안전하게 저장하고 매우 빠르게 조회하는 데 있습니다.

브라우저는 먼저 단축 URL 서버에 GET 요청을 보냅니다. 서버는 짧은 키에 대응하는 원래 URL을 찾은 뒤 301 또는 302 상태 코드와 Location 헤더를 반환하고, 브라우저는 그 주소로 다시 요청합니다.

먼저 무엇을 제공할지와 어느 규모까지 견뎌야 하는지를 정해야 합니다. 단축 URL 생성, 리디렉션, 만료, 사용자 지정 별칭 같은 기능 요구사항과 응답 속도, 가용성, 데이터 보존 기간 같은 품질 요구사항을 구분하면 이후 선택의 기준이 생깁니다.

생성 API는 긴 URL을 받아 짧은 URL을 반환하고, 리디렉션 API는 짧은 키를 받아 원래 URL로 이동시킵니다. 데이터베이스에는 최소한 고유 ID, 짧은 키, 원래 URL을 저장하며 짧은 키에는 중복을 막는 제약을 둡니다.

json { "id": 2009215674938, "shortKey": "zn9edcu", "longUrl": "https://en.wikipedia.org/wiki/Systems_design" }

숫자 10개, 소문자 26개, 대문자 26개를 합치면 한 자리에 62개의 값을 넣을 수 있기 때문입니다. 길이가 n인 문자열의 이론적 조합 수는 62^n이며, 7자리면 약 3조 5,216억 개를 표현할 수 있습니다.

긴 URL에 해시 함수를 적용하고 결과의 일부를 짧은 키로 사용합니다. 짧게 잘라 쓰면 서로 다른 URL이 같은 키를 가질 수 있으므로 데이터베이스에서 중복을 확인하고 충돌을 해결해야 합니다.

서로 다른 URL에 서로 다른 숫자 ID를 먼저 부여하고, 그 ID를 Base62로 일대일 변환하기 때문입니다. ID가 중복되지 않는 한 결과 문자열도 중복되지 않으며, Base62는 해시가 아니라 표현 방식을 바꾸는 인코딩입니다.

서버는 URL을 검증하고 기존 매핑 정책을 확인한 뒤 새로운 고유 ID를 발급합니다. ID를 Base62로 바꾸고 id, shortKey, longUrl을 하나의 레코드로 저장한 다음 완성된 단축 URL을 반환합니다.

사용자 요청은 로드밸런서를 거쳐 무상태 웹 서버로 전달되고, 웹 서버는 먼저 캐시에서 shortKey → longUrl을 찾습니다. 캐시에 없을 때만 데이터베이스를 조회하고 결과를 캐시에 넣은 뒤 리디렉션 응답을 반환합니다.

웹 서버와 데이터베이스의 확장뿐 아니라 악용 방지, 장애 복구, 데이터 분석을 함께 설계해야 합니다. 단축 링크는 외부에 널리 퍼지므로 한 번의 장애나 악성 링크가 많은 사용자에게 영향을 줄 수 있습니다.

고유 ID를 안정적으로 만들 수 있고 단순한 충돌 없는 흐름을 원한다면 Base62 방식이 이해하고 운영하기 쉽습니다. 중앙 ID 발급이 병목이 되거나 예측 가능한 키가 큰 문제라면 무작위 키나 해시 기반 방식을 고려할 수 있으며, 결국 요구사항에 맞는 절충이 중요합니다.

먼저 생성 경로와 리디렉션 경로를 각각 한 줄로 말할 수 있어야 합니다. 그다음 키 생성 방식, 데이터 모델, 캐시, 확장과 장애 대응 순서로 설명하면 개념이 서로 연결됩니다.

prompt 당신은 시스템 설계 면접관입니다. URL 단축 서비스에 대해 한 번에 한 질문씩 해주세요. 제 답변이 끝나면 틀린 점, 빠진 점, 다음에 공부할 개념을 초보자 수준으로 피드백해주세요.