UUID v4는 무엇으로 만들어지는가
UUID는 128비트(16바이트) 식별자를 8-4-4-4-12 자리 16진수로 적은 것입니다. v4는 그중 122비트를 난수로 채우고, 나머지 6비트는 버전(세 번째 묶음의 첫 글자가 항상 4)과 변형(네 번째 묶음의 첫 글자가 8, 9, a, b 중 하나)을 표시하는 데 씁니다. 이 도구는 crypto.randomUUID()를, 그것이 없는 구형 브라우저에서는 crypto.getRandomValues()로 직접 조립합니다. Math.random()은 예측 가능해서 쓰지 않습니다. 생성은 브라우저 안에서만 이루어지고 서버로 보내지 않습니다.
충돌은 걱정할 필요가 없나
2^122 ≈ 5.3×10^36 가지입니다. 초당 10억 개를 100년 동안 만들어도 충돌 확률이 사실상 0에 가깝습니다(생일 역설을 고려해도 약 10^18개를 만들어야 50%에 근접). 그래서 중앙 발급 서버 없이 여러 기기가 각자 ID를 만들어도 됩니다. 단, 난수 출처가 약하면 이 계산은 무의미하므로 암호학적 난수를 쓰는 것이 중요합니다.
DB 기본키로 쓸 때의 주의
v4는 완전히 무작위라서 B-tree 인덱스에 삽입할 때 페이지가 흩어져 쓰기 성능이 떨어질 수 있습니다(특히 MySQL InnoDB의 클러스터드 인덱스). 시간순으로 정렬되는 UUID v7이나 ULID는 이 문제를 완화합니다. PostgreSQL은 uuid 타입으로 16바이트에 저장하므로 문자열(36바이트)로 저장하는 것보다 효율적입니다. 대소문자는 의미가 없으며 RFC는 소문자 출력을 권장합니다.
GUID와의 관계
GUID는 Microsoft에서 쓰는 같은 개념의 이름입니다. .NET이나 레지스트리에서는 {…}로 감싼 대문자 형태가 흔해 옵션으로 제공합니다. 하이픈을 뺀 32자 형식은 URL이나 파일명에 넣을 때 편리하고, 대부분의 라이브러리가 하이픈 유무에 관계없이 파싱합니다.
자주 묻는 질문
v1, v7과 무엇이 다른가요?
v1은 타임스탬프와 MAC 주소를 섞어 생성 장치가 드러날 수 있습니다. v7은 앞부분에 밀리초 타임스탬프를 넣어 시간순 정렬이 되며 DB 인덱스에 유리합니다. v4는 순수 난수로 가장 널리 쓰입니다.
생성한 UUID가 기록되나요?
아닙니다. 브라우저 안에서 만들어져 화면에만 표시되고, 페이지를 새로 고치면 사라집니다.