짧은 후속: 대규모 URL Shorteners에서 실제로 먼저 깨지는 것은 무엇인가
Source: Dev.to
배경
이 글은 *Creating Short URLs at Scale via API (Without Reinventing the Wheel)*에 대한 후속 글입니다. myapi.rest가 대규모로 짧은 URL을 처리하는 방식을 공유한 뒤, 팀이 자체 URL 단축기를 구축할 때 실제로 가장 먼저 무엇이 잘못되는지에 대한 여러 질문이 나왔습니다.
흔한 문제점
빠른 리다이렉트 엔드포인트는 보통 가장 쉽게 구현할 수 있는 부분입니다. 실제 문제는 그 리다이렉트를 둘러싼 모든 것에서 발생합니다. 초기 단계에서 나타나는 고통 포인트는 다음과 같습니다:
- 트래픽이 증가하거나 배치 생성이 늘어날 때 발생하는 짧은 코드 충돌
- 스파이크 시 발생하는 분석 데이터 쓰기 압력 (캠페인, SMS 대량 발송, QR 스캔 등)
- 시간이 지나면서 조용히 복잡해지는 만료 규칙
- 첫날부터 계획되지 않았던 악용 패턴
- 운영 오버헤드 (모니터링, 재시도, 엣지 케이스)
각 이슈는 개별적으로 관리할 수 있지만, 함께 모이면 지속적인 병목이 됩니다.
나중에 드러나는 노력
대부분의 팀은 기본적인 단축기를 빠르게 만들 수 있습니다. 그러나 서비스가 실제로 사용되기 시작하면 다음과 같은 노력들이 뒤늦게 나타납니다:
- 기존 링크를 깨뜨리지 않으면서 변경하기
- 환경 간 동작 일관성 유지하기
- 실제 트래픽에서만 나타나는 엣지 케이스 처리하기
- 팀이 담당하는 다른 모든 작업과 함께 단축기 지원하기
이러한 고민들은 개별적으로는 크게 눈에 띄지 않지만, 시간이 지날수록 조용히 누적됩니다.
독립 서비스로 전환
짧은 URL 로직을 여러 번 재구축하면서, 제품의 핵심이 아닌 인프라에 너무 많은 노력을 쏟고 있음을 깨달았습니다. 그래서 로직을 독립 서비스로 추출했으며, 현재는 myapi.rest를 통해 동일한 서비스를 제공하고 있습니다. 목표는 영리해지는 것이 아니라:
- 반복 작업 제거
- 동작 표준화
- API를 단순하고 예측 가능하게 유지
매우 맞춤형 요구가 있는 경우 자체 단축기 서비스를 구축하는 것이 의미가 있을 수 있지만, 대부분의 팀에게는 복잡성의 긴 꼬리를 직접 관리하지 않는 것이 큰 가치입니다. 이것이 제가 myapi.rest로 메우고자 하는 격차입니다.
요약
궁금하시거나 강한 의견이 있으시면 언제든지 이야기 나누고 싶습니다.