UUID 생성

데이터베이스에 저장하는 기본키라면 v7 을 권합니다. v7 은 앞 48비트가 만든 시각이라 값이 시간순으로 늘어서고, B-트리 인덱스의 끝에만 붙기 때문에 삽입이 인덱스 여기저기를 건드리지 않습니다. v4 는 완전히 무작위라 인덱스 전체에 흩뿌려져 쓰기가 느려지고 캐시 적중률이 떨어집니다. 반대로 값에서 시각이 읽히면 곤란한 자리(공개되는 초대 링크, 주문 번호처럼 순서를 감추고 싶은 곳)에는 v4 가 맞습니다. v1 은 예전에 쓰이던 방식인데 MAC 주소가 값에 들어가 권하지 않습니다.

v4 는 122비트가 무작위입니다. 초당 10억 개씩 100년을 만들어도 한 번이라도 겹칠 확률이 약 50억 분의 1입니다. 현실적으로는 겹치지 않는다고 봐도 됩니다. 다만 그 전제는 난수가 제대로 된 것이어야 한다는 점입니다 — 이 도구는 브라우저의 crypto.randomUUID(없으면 crypto.getRandomValues)를 씁니다. 서버 코드에서 Math.random 으로 UUID 를 만드는 구현은 실제로 충돌한 사례가 있습니다.

이 도구는 섞이지 않습니다. RFC 9562 가 제시한 방법 중 "12비트 전용 카운터"를 씁니다 — 같은 밀리초 안에서는 카운터를 1씩 올리므로 만든 순서와 문자열 정렬 순서가 정확히 같습니다. 밀리초가 바뀌면 카운터를 난수로 다시 뿌리되 위쪽 비트를 비워 두어 그 밀리초 안에서 넘치지 않게 합니다. 한 밀리초에 4,096개를 넘겨 만들면 시각을 1ms 당겨 써서 순서를 지킵니다. 시계가 거꾸로 가도(NTP 보정 등) 마지막에 쓴 시각을 유지합니다.

1970년 1월 1일 UTC 부터의 밀리초입니다. 앞 12자리(하이픈 제외)를 16진수로 읽으면 그 값이 그대로 나옵니다. "뜯어보기"에 넣으면 ISO 8601 로 바꿔 보여 줍니다. 이 시각은 값을 만든 기기의 시계에서 읽은 것이라, 시계가 틀린 기기에서 만들었다면 그 시각도 틀립니다.

윈도우의 레지스트리와 COM 에서 쓰는 GUID 표기입니다. {01234567-89ab-...} 처럼 중괄호로 감쌉니다. UUID 와 GUID 는 같은 것을 가리키는 다른 이름이고, 표기만 다릅니다. 이 도구는 하이픈을 지운 뒤 중괄호를 씌우므로 하이픈 없는 중괄호 표기도 만들 수 있습니다.

규격은 만들 때 소문자로 쓰고 읽을 때는 대소문자를 모두 받아들이라고 정합니다. 그래서 소문자가 기본이고, 대문자가 필요한 시스템(일부 윈도우 도구, 오래된 데이터베이스)에서만 대문자 옵션을 쓰면 됩니다. 문자열로 비교하는 코드에서는 대소문자가 섞이면 같은 UUID 가 다른 값으로 취급되니 한쪽으로 통일해 저장하세요.