Base62 라이브러리, 역시 있었군요

안녕하세요, 하마연구소 입니다.

Base64 인코딩은 바이너리 데이터를 사람이 인지할 수 있는 ASCII 문자로 표현하기 위한 방법입니다.
영어 알파벳 대/소문자, 숫자, +(더하기), /(나누기,슬래시) 그리고 필요하다면 =(equal)만은 사용한 결과이기에 HTML이나 CSS 내부에 포함된 이미지 데이터 URL path 또는 쿼리파라미터 값으로 많이 사용됩니다.
일반적으로 바이너리 데이터를 Base62로 인코딩하면 결과물이 다소 길어서 용량은 증가하겠지만, 일반 텍스트 편집기로 확인할 수 있다는 장점이 있습니다.
또한 인코딩된 값을 직접 보면 무슨 의미인지 파악할 수 없으며 랜덤한 문자열로 보이기에 콘텐츠의 ID로 사용하기도 합니다.
YouTube의 영상 ID가 이렇게 사용된 예시입니다.

https://namu.wiki/w/BASE64

BASE64

---

필자는 약 10년 전 개발 프로젝트를 진행하면서 Base64 인코딩에 대해 깊게 생각한 경험이 있습니다.
의미를 한번에 유추할 수 없고 랜덤한 것처럼 보이는 문자열이 필요하였으며, 따라서 Base64 사용을 검토하였습니다.
프로젝트의 요구사항을 만족시키기에 Base64는 적합하였습니다.

하지만 한 가지 예상되는 문제점이 있었습니다.
문제점이라기 보다는 앞으로 불편한 점이 예상되었습니다.

Base64로 변환된 문자열은 URL에 직접 노출되어야 했는데, 64개의 문자 중 + 와 / 가 나중에 골치거리가 될 듯 하였습니다.
여기에 특별한 경우에 사용되는 = 도 있었습니다.
이 문자들이 URL인코딩 없이 URL에 직접 사용되면 그 URL은 잘못된 URL이고 올바르게 URL을 분석할 수 없습니다.
항상 이러한 점을 염두해두고 프로그래밍을 해야하는데, 경험이 어느정도되는 개발자는 공감하실 겁니다.

이 값이 인코딩되서 들어온겨? 그냥 들어온겨?
내가 디코딩해야해? 

진행하던 프로젝트는 상당히 큰 시스템을 구축하는 것이며 진행기간도 수년을 예상하였습니다.
따라서 초반 설계를 잘 닦아놓아야했습니다.
Base64를 그대로 도입해서 매번 인코딩/디코딩 생각해야하고 시간이 흐르고 담당자가 바뀌면 버그가 발생할 가능성이 예상되었습니다.

따라서 + , / 문자를 제외하고 사용하기로 하였습니다.
영문 대문자 26개, 소문자 26개, 숫자 10개만을 사용한 Base62인거죠.
사실 그 당시에는 Base62라는 용어까지 생각하지 않았으며 그냥 62개 문자만 사용하는 것에 중점을 두고 직접 구현하였습니다.
지금까지 이 시스템은 잘 운영되고 있으며 지금도 많은 사람이 제가 만든 URL을 이용하고 있습니다.
그 62개 문자로 만들어진 URL을 관심있게 보는 사람은 없겠지만요.

프로젝트 진행하면서 시간이 흘러 Base62를 검색해보니,
역시 이미 구현한 라이브러리가 다수 검색됩니다.
필자는 왜 당시에 검색해 볼 생각을 안했었는지...

뭐든 필요한 것이 있다면 검색부터 해보자!
요즘은 ChatGPT에게 먼저 물어보면 된다!

---

https://github.com/seruco/base62

GitHub - seruco/base62: Base62 Encoder/Decoder for Java

 

https://www.npmjs.com/package/base62

base62