URL Shortening
URL을 입력받아 짧게 줄여주고, Shortening된 URL을 입력하면 원래 URL로 리다이렉트하는 URL Shortening Service
문제를 딱 봤을 때 약간혼란스러움을 느꼈다. 쉬운건가? 어려운건가? 최근에 적용시킨 서비스중에 url shortening api를 쓴적 있지만 그건 bitly의 이미 구현된 api를 가져다 쓴거라 bitly를 직접 만들라는 이경우와는 조금 다른 케이스 였다. 최근 만든 작업은 https://abc.com?key=77 이라는 우리 사이트가 있다고 가정하자 이 때 77은 회원이 접수한 건에 주어지는 고유한 일련번호이고 이게 노출되면 보안적으로 위험한 상황이었다. 그래서 이숫자를 먼저 해쉬로 암호화 해서 숨겨주었다.
https://abc.com?key=77 => https://abc.com?key=qwkmcx0+1dmxa1dsdsd
이걸 기존의 단축 api 를 가져다가 써서 짧게 만들어서 고객에게 보내주려고 했다. 처음에는 네이버의 me2.do 를 쓰려 했는데 이게 bitly 보다 무료로 단축할 수 있는 갯수도 압도적으로 많고 단축된 모양도 깔끔할거 같아 선택했었다. 하지만 ... 네이버는 +와 같은 특수문자를 api에 태우는 순간 무조건 변환시켜버린다. %~로 바꿔버리고 이건 내가 의도한 바가 아니었기 때문에 bitly api를 사용하기로 했다.
https://abc.com?key=qwkmcx0+1dmxa1dsdsd => https://bitly.com/demx6xqpa
그런데 j.mp 또한 bitly가 구매한 주소라고 한다. 이왕이면 더 줄여보자 라는생각에 이걸 한번 더 줄였다.
https://bitly.com/demx6xqpa => https://j.mp/demx6xqpa
최종적으로 위와 같은 주소를 받은 고객이 여기로 접속하면 bitly가 원래 주소를 반환해주고 난 해당 주소를 받으면 뒤에 있는 키값만 다시 해쉬 디코더를 태워서 고유 일련번호를 찾은 다음 연결해주면 되는거였다. 또 해당 페이지는 상황이 맞는 접수건에만 접속이 가능하게 해야해서 이 때 데이터베이스에 가서 그 번호가 맞는 지 한번 check 하고 아니면 404를 뱉어버리게 구성했었다.
그럼 내가 URL Shortening Algorithm 구현 하기
그럼 지금까지 저기서 bitly가 해주던 일을 내가 구현하면 되는것 그렇다면 원래의 주소를 j.mp/ 뒤에 있는 8개의 문자로 줄여주는 과정이 필요하다. 이 부분을 보고 내가 일련번호를 해쉬로 암호화 시킨것과 비슷하다 생각했다. 하지만 길이 제한이 있고 +나 / 같은 특수문자를 쓰면 안된다. 또 단순 랜덤 변환은 안되는 게 같은 URL주소는 같은 결과를 뱉어야 하고 해당 URL로 접근 횟수도 기록해야 한다. 이거까지 보고 나서 조건에 써있던 "DataBase는 꼭 사용하지 않아도 됨" 이 살짝 이해가 안됐던게 이걸 DB없이 쓰려면 너무 어려울것 같은 느낌이었다.
찾아보니 Base 62 를 이용해서 8자리의 랜덤 문자열로 바꿔주는 방법이 있다. 64와 다르게 url에서 변환되는 /와 +를 빼준 진법이라는데 이렇게 좋은게 있을 줄이야. 62의 8제곱은 대략 21조개로 변경된 코드가 겹칠 걱정은 안해도 될거같다. 굳이 걱정되면 한번 검증하는 코드를 넣어도 되고(이거 굳이가 아니라 그냥 넣어야 할거 같다.) 자 그럼 구현 자체는 안어려운데 나는 왜 고민을 하고 있나. 바로 리눅스를 통해서 서버를 돌릴 수 있어야 하고 git의 readme에 해당 방법을 적어서 git에 올려야 한다. 이 과정에서 swagger를 이용한 문서와 테스트코드가 들어가야 한다는데 나는 이런 일련의 과정을 해본적이 없다 ... 차라리 코드가 어려우면 좋을텐데 내가 이걸 일주일만에 가능한것일까
댓글
댓글 쓰기