UUID 생성기

v4 UUID는 암호학적으로 안전한 122비트의 무작위 값으로, 멱등성 키·세션 ID처럼 순서가 필요 없고 불투명한 식별자가 필요한 곳에 널리 쓰입니다. v7 UUID는 앞쪽 48비트에 Unix 밀리초 타임스탬프를 담아 시간적으로 가까운 값이 사전식 정렬에서도 가까이 놓이도록 만들어요. 그래서 삽입 때문에 B-트리 인덱스가 흩어지기 쉬운 데이터베이스 기본 키에는 v7이 더 잘 맞습니다.

예시

v4 UUID 세 개 (무작위, 순서 없음):

f47ac10b-58cc-4372-a567-0e02b2c3d479
6ba7b810-9dad-11d1-80b4-00c04fd430c8
d1b2c3e4-5678-4abc-9def-0123456789ab

같은 밀리초 안에 만든 v7 UUID 세 개 (앞부분이 공유되는 것을 확인하세요):

018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90
018f8e50-fcaa-7c3d-a41f-8c9b07e2c0d1
018f8e50-fcab-7c01-b3e7-1d9a4f5c6e82

자주 겪는 문제와 해결법

실제 애플리케이션에 UUID를 붙일 때 흔히 마주치는 함정들이에요:

• 삽입 순서가 중요한 곳에 v4를 쓰는 경우. 무작위 v4를 1천만 건 색인하면 B-트리에서 페이지 분할이 많이 발생해요. v4를 유지한다면 쓰기 증폭을 감수하거나, 기본 키를 v7로 바꾸세요.
• 하이픈을 없애다가 버전 니블(nibble)을 놓치는 경우. f47ac10b58cc4372a5670e02b2c3d479도 여전히 32자짜리 유효한 16진 UUID지만, 13번째 글자(4)는 무작위가 아니라 버전 표식이에요. 32자 전체가 무작위라고 가정하지 마세요.
• Math.random()에 의존하는 경우. Math.random() 기반의 오래된 라이브러리는 암호학적으로 안전하지 않고 예측 가능할 수 있어요. 브라우저와 Node 19+의 crypto.randomUUID()를 쓰거나, crypto에서 읽는 v7 라이브러리를 사용하세요.
• v7을 타임스탬프처럼 다루는 경우. 앞쪽 48비트는 시간이지만 나머지는 무작위라서, 같은 밀리초에 만든 두 v7은 결정론적으로 정렬되지 않아요. 타이 브레이킹에 의존하지 마세요.
• VARCHAR(36)으로 저장하는 경우. 동작은 하지만, 네이티브 16바이트 UUID나 BINARY(16) 컬럼 대비 저장 공간이 두 배가 되고 조인도 느려져요. 데이터베이스의 네이티브 타입(Postgres의 uuid, SQL Server의 UNIQUEIDENTIFIER)을 사용하세요.
• 특정 버전을 강제하는 정규식을 쓰는 경우. /[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-.../i 는 v4만 매칭합니다. 나중에 v7을 발행하면, 이 정규식이 유효한 ID를 조용히 거부하게 돼요.

UUID v4와 v7의 차이는 무엇인가요?

v4는 버전과 변종 표식을 제외하면 시간 성분 없이 122비트가 모두 무작위예요. v7은 앞에 48비트 Unix 밀리초 타임스탬프를 붙이고 나머지를 무작위로 채워서, 시간적으로 가까운 값이 사전식 정렬에서도 가까이 놓입니다. 데이터베이스 기본 키라면 B-트리 삽입을 국소화하기 위해 v7을, 순서 신호가 전혀 없어야 한다면 v4를 쓰세요.

중복된 UUID가 나올 수도 있나요?

사실상 없어요. v4는 무작위 122비트라서 10억 개 배치에서 두 값이 겹칠 확률이 대략 10^-18 정도입니다. 단 한 번의 충돌이 50% 확률로 일어나려면 약 2.7퀸틸리언(2.7 × 10^18) 개의 v4를 만들어야 해요. 고유 생성은 당연하게 여기고, 별도의 중복 검사 로직은 넣지 마세요.

v4는 암호학적으로 무작위인가요?

이 도구는 crypto.randomUUID()를 사용하는데, 이 함수는 사양상 암호학적으로 안전한 PRNG에서 값을 가져와야 합니다. 세션 ID, 멱등성 키, 대부분의 보안 토큰에는 충분해요. 다만 서명된 토큰이나 긴 API 비밀 키를 대체하는 용도는 아니고, UUID에서 암호 키를 파생해서도 안 됩니다.

UUID v7은 표준화되어 있나요?

네. UUID v7은 RFC 9562(2024년 5월)에 정의되어 있고, 이 RFC가 RFC 4122를 대체하면서 기존 버전들과 함께 v6·v7·v8을 공식화했어요. 대부분의 최신 언어에 v7 구현이 있고, Postgres·MySQL·SQL Server 모두 v7 값을 UUID 컬럼에 그대로 저장할 수 있습니다.

바이너리 형식은 어떻게 생겼고 엔디안이 중요한가요?

UUID는 16바이트입니다. 표준 텍스트 형식에서는 8-4-4-4-12로 16진수를 묶어요. RFC 9562에 따라 바이트는 네트워크(빅 엔디안) 순서로 기록되므로, 018f8e50-fcaa-7c3c-8d2a-6f5b72e1fd90 은 0x01 바이트로 시작합니다. 과거 Microsoft GUID는 메모리상 앞 세 그룹을 리틀 엔디안으로 저장해 왔으니, .NET 바이너리 덤프와 연동할 때 주의하세요.

이 도구에서 생성한 UUID를 저장하나요?

아니요. 여기서 생성한 UUID는 저장하지 않습니다. 모든 값은 출력 영역에만 표시되고, 새로고침하거나 탭을 닫는 순간 사라져요 — 아무것도 저장되지 않고, 생성한 값에 대한 텔레메트리도 수집하지 않습니다. 브라우저 개발자 도구에서 직접 확인해 보셔도 됩니다.