UUID · 짧은 ID 만들기
UUID를 한 번에 여러 개 만듭니다. v4는 완전 난수라 만든 순서를 알 수 없고, v7은 앞부분이 시각이라 만든 순서대로 정렬됩니다. 데이터베이스 기본키로 쓸 것이라면 v7 쪽이 인덱스에 유리합니다.
만든 순서대로 정렬됩니다
브라우저에서 만듭니다. 서버를 거치지 않으므로 같은 값이 다른 사람에게 갔을 걱정이 없습니다. 난수는 crypto.getRandomValues 를 씁니다.
v7 을 읽는 법
앞 열두 자리 16진수가 유닉스 시각(밀리초)입니다. 그 뒤 7 이 판이고, 열일곱째 글자가 8~b 이면 표준 변형입니다. 7 뒤 세 자리는 같은 밀리초 안의 차례입니다 — 시각이 바뀌면 난수에서 다시 시작하고, 같은 밀리초 안에서는 하나씩 오릅니다. 그래서 목록에서 앞 열여섯 자리가 거의 같고 뒤만 다른 것이 정상입니다. 시각은 이 기기의 시계라, 시계가 틀린 기계에서 만든 것과 섞이면 순서도 그만큼 어긋납니다.
짧은 ID 의 실체
A–Z·a–z·0–9·_·- 예순네 글자에서 스물한 자를 뽑습니다. 한 글자가 6비트라 126비트 — v4 의 난수 122비트보다 많습니다. 짧아서 약한 것이 아니라 표기가 촘촘한 것입니다. 하이픈으로 나뉘지 않고 주소에 넣어도 인코딩할 것이 없습니다. 길이를 바꾸는 칸은 없습니다.
난수는 어디서 오나
셋 모두 브라우저의 crypto 를 씁니다. Math.random 은 예측할 수 있어 식별자에 쓰면 안 되는데, 여기서는 쓰지 않습니다. 값은 열 때와 종류·개수를 바꿀 때마다 새로 만들어지고 어디에도 저장되지 않으니, 필요한 것은 복사해 두세요. 새로 만들면 앞의 것은 사라집니다.
자주 묻는 질문
v4와 v7 중 무엇을 쓸까요?
기본키로 쓸 것이라면 v7입니다. v4는 완전 난수라 새 값이 인덱스 여기저기에 흩어져 쓰기 성능이 떨어집니다. v7은 앞 48비트가 밀리초 시각이라 뒤에 차곡차곡 쌓입니다. 다만 만든 시각이 값에 드러나므로, 그것이 곤란한 자리라면 v4를 쓰세요.
한 번에 여러 개 만들면 순서가 섞이지 않나요?
섞이지 않습니다. 같은 밀리초 안에서도 순서를 지키도록 12비트 counter를 두었습니다. 시각만으로 만들면 한꺼번에 뽑은 것들이 전부 같은 밀리초라 뒤쪽 난수로 뒤섞이는데, 그러면 v7을 쓰는 이유가 없어집니다.
v4 가 겹칠 일은 없나요?
실질적으로 없습니다. 122비트가 난수라 초당 십억 개씩 백 년을 만들어도 겹칠 확률이 무시할 만합니다. 다만 그것은 난수가 제대로일 때 이야기이고, 여기서는 브라우저의 암호용 난수를 씁니다.
짧은 ID 는 안전한가요?
이 화면의 짧은 ID 는 21자로, 담긴 무작위성은 126비트입니다 — UUID v4 의 122비트보다 오히려 많습니다. 짧은 것은 글자 수이지 안전성이 아닙니다. 위험해지는 것은 그것을 사람이 더 잘라 쓸 때입니다. 주소창에 드러나도 되는 값이면 무엇이든 되고, 남이 맞히면 안 되는 값도 이 길이면 충분합니다.
대문자로 나오나요?
소문자입니다. RFC 9562 는 만들 때 소문자로 적고 읽을 때는 둘 다 받으라고 합니다. 받는 쪽이 대개 가리지 않지만, 문자열로 견주는 코드가 있다면 한쪽으로 통일하세요.
v1 이나 v5 는 없나요?
없습니다. v1 은 MAC 주소가 들어가 어느 기계에서 만들었는지 드러나고, v5 는 이름을 해시하는 것이라 난수 생성기가 아닙니다. 순서가 필요하면 v7, 아니면 v4 로 충분합니다.
붙여넣은 코드가 서버로 가나요?
가지 않습니다. 브라우저 안에서만 처리하고 어디에도 보내거나 저장하지 않습니다. 사내 설정 파일이나 운영 쿼리처럼 밖으로 내보내기 곤란한 것도 그래서 쓸 수 있습니다. 인터넷을 끊고도 동작합니다.