UUID 생성기 (RFC 4122 v4)

중앙 서버 없이 겹치지 않는 ID

데이터에 고유 번호를 붙이는 가장 쉬운 방법은 1, 2, 3… 자동 증가입니다. 그런데 이건 중앙에서 번호를 나눠 줘야 합니다 — 서버가 여럿이거나, 오프라인에서 만들거나, 합치기 전에 미리 ID가 필요하면 충돌이 납니다. UUID는 이 문제를 다르게 풉니다. 조율 없이 각자 만들어도 사실상 절대 겹치지 않을 만큼 큰 무작위 값을 쓰는 것이죠.

얼마나 클까요. v4 UUID는 128비트 중 122비트가 무작위입니다. 경우의 수가 약 5.3 × 10³⁶— 10억 개를 만들어도 두 개가 겹칠 확률은 무시할 수준입니다. 그래서 “미리 ID를 정하고 나중에 저장”, “여러 기기가 동시에 생성” 같은 일이 안전해집니다.

v4 UUID의 속을 들여다보면

UUID는 아무 16진수 32자가 아닙니다. 정해진 자리에 버전과 변형 표시가 박혀 있습니다.

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
              │    │
              │    └ 변형: y 는 8·9·a·b 중 하나 (RFC 4122)
              └ 버전: 4 (무작위)

이 도구는 crypto 로 만든 16바이트에서 7번째 바이트의 상위 4비트를 0100(버전 4)으로, 9번째 바이트의 상위 2비트를 10(변형)으로 고정하고 나머지는 무작위로 둡니다. 그래서 어떤 UUID든 세 번째 그룹은 4로, 네 번째 그룹은 8·9·a·b로 시작합니다 — 이게 “제대로 만든 v4”의 표식입니다.

난수의 품질이 고유성을 지탱한다

UUID의 안전함은 ‘무작위’에 달렸는데, 무작위에도 급이 있습니다. 예측 가능한 Math.random 으로 만들면 이론적 충돌 확률과 별개로 추측 위험이 생깁니다. 이 도구는 브라우저의 crypto.getRandomValues(암호학적 난수)를 써서, 생성된 값을 되짚어 예측할 수 없게 합니다. 생성은 전부 여러분 기기 안에서 일어나고 서버로 나가지 않습니다.

v4의 약점: 정렬이 안 된다

완전 무작위라는 게 장점이자 단점입니다. v4 UUID는 시간 순서가 없어서, 기본키로 쓰고 그대로 정렬하면 생성 순서와 뒤죽박죽이 됩니다. 데이터베이스 인덱스 성능에도 불리할 수 있습니다. 시간 순 정렬이 중요하면 ULID나 UUID v7(앞부분에 타임스탬프를 담아 정렬 가능)을 고려하세요. 단순히 겹치지 않는 ID만 필요하다면 v4로 충분합니다.

정리하면

• 조율 없이 고유한 128비트 ID. 그래서 분산 환경에서 강력합니다.
• v4는 버전·변형 비트를 뺀 122비트가 무작위. crypto 로 만들어 예측 불가.
• 정렬이 필요하면 v4는 안 맞습니다. ULID·UUID v7 을 보세요.