UUID 생성기
RFC 4122 표준을 준수하는 고유 식별자 생성
'UUID 생성'을 클릭하여 시작
UUID란?
UUID(Universally Unique Identifier)는 분산 시스템에서 정보를 식별하기 위한 128비트 식별자입니다. 표준 형식은 32개의 16진수로 8-4-4-4-12 형식, 총 36자입니다. UUID는 OSF에서 개발되어 RFC 4122로 표준화되었습니다. 여러 사람이 함께 사용할 때는 입력, 전제, 기대 결과를 미리 맞춰 결과가 잘못 해석되지 않도록 해야 합니다.
사용 방법
생성 단계
- UUID 버전을 선택하세요 (v1, v4 또는 Nil)
- 생성 수를 설정하세요 (1-100)
- 출력 대소문자를 선택하세요 (대문자 또는 소문자)
- 형식을 선택하세요 (하이픈 포함, 하이픈 없음 또는 중괄호)
- 생성 버튼을 클릭하여 요청한 식별자를 생성하세요
키보드 단축키
- Ctrl + GUUID 생성
- Ctrl + Shift + C모두 복사
식별자 참고
- UUID v4는 보통 랜덤 클라이언트 측 식별자에 적합한 선택입니다. 시간이나 장치 정보를 인코딩하지 않습니다.
- UUID를 비밀 값으로 사용하지 마세요. 레코드를 식별할 뿐 인증 토큰이나 액세스 키를 대체하지는 않습니다.
활용 사례
기술 원리
UUID는 표준 형식 8-4-4-4-12로 128비트 식별자이며, 총 36자(하이픈 4개 포함)입니다. 128비트는 time-low(32비트), time-mid(16비트), version-and-time-high(16비트, 상위 4비트는 버전), variant-and-clock-seq(16비트, 상위 2~3비트는 변형), node(48비트)로 나뉩니다. RFC 4122는 v1부터 v5까지 5가지 버전을 정의합니다. v1은 60비트 타임스탬프(100나노초 해상도, 1582년 10월 15일부터 카운트)에 48비트 MAC 주소, 14비트 클럭 시퀀스로 구성됩니다. 생성 시간순으로 정렬 가능하지만, 기기 식별자와 생성 시간이 유출됩니다. v4는 가장 널리 사용되는 버전으로, 암호학적으로 안전한 난수 소스로 122비트를 채우고 버전(4)과 변형(10) 비트를 고정합니다. 충돌 확률은 UUID 설계의 핵심 관심사입니다. v4는 122비트의 난수 공간을 가지며, 생일 역설에 따르면 초당 10억 개의 UUID를 85년 동안 연속 생성해야 50%의 단일 충돌 확률에 도달하며, 실용적으로는 충분합니다. 새롭게 등장하는 v7는 타임스탬프를 앞에, 난수 비트를 뒤에 배치하여 고유성과 시간 정렬의 균형을 맞추며, 데이터베이스 기본 키에 더 적합합니다.
- UUID v4: 122비트 난수에 고정 버전 비트 4, 변형 비트 10; 거의 모든 시나리오에 적합하며 프라이버시를 유출하지 않음
- UUID v1: 60비트 타임스탬프 + 48비트 MAC + 14비트 클럭 시퀀스; 시간순 정렬 가능하지만 기기 지문이 노출되므로 주의 필요
- UUID v7: 타임스탬프 앞, 난수 비트 뒤; 2024년 초안 표준으로 데이터베이스 기본 키를 위해 특별히 설계됨
- 충돌 확률: v4의 난수 공간은 2^122이며, 초당 10억 개의 UUID를 85년 동안 연속 생성해야 50%의 단일 충돌 확률에 도달
- Nil UUID: 모두 0인 00000000-0000-0000-0000-000000000000, 주로 자리 표시자 또는 기본값으로 사용
- 형식 변형: 표준 8-4-4-4-12 외에도 하이픈 없는 32자 형식, {중괄호} 형식, URN 형식(urn:uuid:...)이 있음
예시
UUID v4 (랜덤) 표준 형식
550e8400-e29b-41d4-a716-446655440000
버전 자릿수 (13번째 hex): 4 -> v4, 랜덤
Variant 비트 (17번째 hex): 8/9/a/b -> RFC 4122 variant
용도: 데이터베이스 기본 키, 요청 ID, 자산 ID — 순서가 중요하지 않을 때의 기본 선택지
RFC: RFC 4122 섹션 4.4가 v4 생성 방식을 정의UUID v1 (타임스탬프 + MAC) 형식
c232ab00-9414-11ec-b909-0242ac120002
버전 자릿수: 1 -> v1, 시간 기반
참고: 생성 시각이 time_low에 인코딩되며, 마지막 12개 hex는 노드 ID(주로 MAC 주소)
용도: 정렬 가능한 ID나 호스트별 결정적 출처가 필요할 때 유용하지만, MAC이 호스트 식별 정보를 노출하는 점에 주의
RFC: RFC 4122 섹션 4.1이 v1 레이아웃을 정의v4 ID 5개 일괄 생성
a1b2c3d4-e5f6-4789-a012-3456789abcde
f7e8d9c0-b1a2-43f4-95e6-7d8c9b0a1e2f
3c4d5e6f-7a8b-49c0-9d1e-2f3a4b5c6d7e
8e9f0a1b-2c3d-44e5-bf6a-7b8c9d0e1f2a
5f6a7b8c-9d0e-45f1-a2b3-c4d5e6f7a8b9
참고: 각 ID는 crypto.getRandomValues에서 독립적으로 추출되며, RFC 4122 부록 B에 따르면 2^122개 ID에 대한 충돌 확률은 무시할 수 있는 수준입니다자주 묻는 질문
UUID란 무엇인가요?
Universally Unique Identifier(범용 고유 식별자)는 128비트 값(RFC 4122/9562)으로, 보통 8-4-4-4-12 패턴의 32자리 16진수로 표기됩니다(예: 550e8400-e29b-41d4-a716-446655440000). 버전마다 시간, 랜덤 데이터, 해시 등을 인코딩하며, 중앙 조정자 없이도 시스템 간에 고유성을 갖추는 것이 목적입니다.
UUID v1, v4, v7의 차이는?
v1은 호스트 MAC 주소와 100ns 타임스탬프를 섞습니다(정렬에 좋지만 호스트 정보가 노출됩니다). v4는 순수 랜덤입니다(엔트로피 122비트, 정렬 불가). v7(RFC 9562)은 상위 비트에 48비트 Unix-ms 타임스탬프를 두고 하위 비트에는 랜덤을 둡니다 — v1처럼 정렬 가능하면서도 MAC 누출이 없습니다. v7은 데이터베이스 키의 최신 기본 선택입니다.
UUID는 정말 고유한가요?
통계적으로 그렇습니다. 초당 10억 개의 v4 UUID를 100년 동안 생성해도 충돌 확률은 약 50%(생일 역설 한계)입니다. 모든 실용 시스템에서 UUID는 조정 없이 고유한 것으로 간주할 수 있습니다.
UUID는 랜덤하고 추측 불가능한가요?
v4 UUID는 랜덤하며 사실상 추측 불가능합니다(엔트로피 122비트). v1 UUID는 전혀 랜덤이 아닙니다 — 호스트 MAC와 타임스탬프를 노출하니, 보안 토큰으로 사용하지 마세요. v7의 타임스탬프 접두사도 예측 가능하므로, 추측 불가능한 것은 뒤쪽 랜덤 비트뿐입니다.
UUID를 데이터베이스 기본 키로 사용해야 할까요?
사용은 가능하지만 트레이드오프가 있습니다. 랜덤한 v4 UUID는 기본 키로 클러스터링하는 데이터베이스(MySQL InnoDB)에서 B-tree 단편화를 일으켜 대규모 삽입 성능에 악영향을 줍니다. 정렬 가능한 v7 UUID는 이를 피합니다. 자동 증가 정수가 여전히 더 작고 빠릅니다 — 분산 생성이 중요한 경우에 UUID를 사용하세요.
UUID 생성은 브라우저에서 이루어지나요?
네. 페이지는 Web Crypto API의 일부인 crypto.randomUUID(또는 구형 브라우저용 crypto.getRandomValues)를 사용합니다. 어떤 데이터도 서버로 전송되지 않으며, 페이지를 새로 고치면 새로운 엔트로피 스트림이 제공됩니다.
왜 일부 UUID가 앞부분이 거의 똑같아 보이나요?
v1과 v7 UUID는 앞쪽 문자에 시간을 인코딩하므로, 동일한 밀리초 안에 생성된 UUID는 접두사를 공유하고 뒤쪽 바이트만 다릅니다. 이 속성 때문에 자연스럽게 정렬 가능합니다. v4 UUID는 랜덤이므로 이런 모습을 보이지 않습니다.