테마

인기 도구

UUID 생성기

무작위 UUID v4나 시간순 UUID v7을 바로 생성하거나, 최대 10,000개를 한 번에 만들 수 있습니다. 새 GUID도 같은 종류의 128비트 값이므로 온라인 GUID 생성기로도 쓸 수 있습니다. UUID를 붙여넣으면 버전, 생성 시각, 모든 필드를 디코드합니다.

RFC 9562 · crypto.getRandomValues · 브라우저에서 만들고 읽으며, 아무것도 전송하지 않음

색이 칠해진 숫자가 버전입니다. 모든 UUID에서 세 번째 그룹의 첫 자리입니다.

v4 · 무작위36자 · 무작위 122비트
xxxxxxxx-xxxx-4xxx-Nxxx-xxxxxxxxxxxx
구조 · RFC 9562 §5.4128비트 · 16진수 32자리 · 36자
필드에 마우스를 올리거나 탭하면 설명이 나옵니다

crypto.getRandomValues로 브라우저에서 만들고 읽습니다. 아무것도 전송되지 않습니다.

형식

UUID란 무엇인가요? UUID의 뜻과 약자

UUID는 Universally Unique Identifier(범용 고유 식별자)의 약자입니다. 어느 컴퓨터든 혼자서 만들 수 있으면서도, 다른 컴퓨터가 같은 값을 만들지 않으리라고 기대할 수 있는 128비트 레이블입니다. 919108f7-52d1-4320-9bac-f847db4148a8처럼 16진수 32자리를 다섯 그룹으로 나누어 씁니다.

형식은 RFC 9562(2024년 5월)에 정의되어 있습니다. RFC 9562는 RFC 4122를 대체하며 버전 6, 7, 8을 추가했습니다. UUID를 발급하는 중앙 등록 기관은 없습니다. 고유성은 버전에 따라 무작위성, 타임스탬프, 이름의 해시 중 하나에서 나옵니다.

데이터베이스는 기본 키로, API는 요청과 객체의 ID로, 운영체제는 디스크, 파티션, 소프트웨어 구성 요소의 식별에 UUID를 씁니다. GUID(Globally Unique Identifier)는 같은 것을 가리키는 Microsoft의 이름입니다.

값 하나, 네 가지 크기RFC 9562 §4

UniversallyUniqueIDentifier

  1. 128 비트
  2. 16 바이트
  3. 32 자리(16진수)
  4. 36 자(하이픈 포함)919108f7-52d1-4320-9bac-f847db4148a8

GUID같은 값을 가리키는 Microsoft의 이름

RFC 9562의 버전 4 예시를 네 가지 방법으로 센 것입니다. 텍스트 형식은 16진수 32자리에 하이픈 4개를 더해 36자가 됩니다.
UUID 생성기: 타임스탬프, 버전, 무작위 비트를 필드별로 표시한 UUID v7과 일괄 생성한 v7 UUID 목록UUID 생성기: 타임스탬프, 버전, 무작위 비트를 필드별로 표시한 UUID v7과 일괄 생성한 v7 UUID 목록버전 선택무작위 v4, 시간순 v7, 이름 기반 v5 등 버전마다 고유한 색이 있습니다.클릭 한 번복사하거나 새로 만들 수 있고, 최대 10,000개의 일괄 생성 결과는 텍스트, CSV, JSON, SQL로 내보냅니다.모든 필드이 버전에 대해 RFC 9562가 정의하는 비트를 보여 주고, v7에 담긴 시각도 읽어 냅니다.어떤 형식이든중괄호, 하이픈 없음, 대문자, Base64url, 정수, .NET 바이트 순서로 표시합니다.
UUID v7을 분해한 모습입니다. 48비트 타임스탬프, 버전 숫자, 변형 비트, 무작위 부분으로 이루어집니다. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

UUID 형식과 길이: 36자

UUID는 128비트이며, 16진수 32자리와 하이픈 4개를 8, 4, 4, 4, 12자리 그룹으로 나누어 36자로 씁니다. 세 번째 그룹의 첫 자리는 버전이고, 네 번째 그룹의 첫 자리는 변형을 나타내며 RFC 9562 UUID에서는 8, 9, a, b 중 하나입니다.

따라서 017f22e2-79b0-7cc3-98c4-dc0c0c07398f는 버전 7, RFC 변형입니다. 대문자, 소문자, 혼합 모두 유효하며, 대부분의 도구는 소문자로 출력하지만 macOS의 uuidgen은 대문자로 출력합니다. 하이픈 없이는 32자, 중괄호로 감싸면 38자(.NET의 B 형식), urn:uuid: 형식은 45자, Base64url로는 22자입니다.

RFC 형식을 검사하는 정규 표현식은 ^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$에 대소문자 무시 플래그를 붙인 것입니다. 유효하지만 특수한 값인 Nil UUID와 Max UUID는 걸러지며, 위의 디코더는 이 둘도 식별합니다.

텍스트 형식RFC 9562 §4
017f22e28-79b04-7cc34-98c44-dc0c0c07398f12

16진수 32자리 + 하이픈 4개 = 36자

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxxM 버전: 1–8N 변형: 8, 9, a, b
정규 표현식 · 대소문자 무시^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$
같은 128비트의 다른 표기
  • 표준017f22e2-79b0-7cc3-98c4-dc0c0c07398f36
  • 하이픈 없음017f22e279b07cc398c4dc0c0c07398f32
  • 중괄호 {…}{017f22e2-79b0-7cc3-98c4-dc0c0c07398f}38
  • urn:uuid:urn:uuid:017f22e2-79b0-7cc3-98c4-dc0c0c07398f45
  • Base64urlAX8i4nmwfMOYxNwMDAc5jw22
  • Base64AX8i4nmwfMOYxNwMDAc5jw==24
  • Base58BihbxwwQ4NZZpKRH9JDCz21
  • Base3201FWHE4YDGFK1SHH6W1G60EECF26
  • 정수1989357241971137676463954034883508623최대 39
  • 바이너리01 7f 22 e2 79 b0 7c c3 98 c4 dc 0c 0c 07 39 8f16바이트
RFC 9562의 v7 예시를 각 형식으로 쓴 것입니다. 정규 표현식이 Nil UUID와 Max UUID를 걸러 내는 것은 의도된 것입니다. 이 둘에는 버전이 없습니다.

UUID 버전 설명: v1부터 v8까지

버전은 UUID를 만든 방식을 나타냅니다. v4는 무작위 비트로, v7은 시각과 무작위 비트로 만들고, 타임스탬프와 노드 ID로 만드는 것은 v1과 v6, 이름을 해시해서 만드는 것은 v5와 v3입니다. v8은 생성자 고유의 레이아웃을 씁니다.

버전 2와 0은 여기서 생성하지 않습니다. v2(DCE 보안)는 예약되어 있지만 RFC 9562가 레이아웃을 정의하지 않으며, 0은 버전이 아닙니다. 두 특수 값에는 버전이 없습니다. Nil UUID는 모든 비트가 0이고 Max UUID는 모든 비트가 1입니다(ffffffff-ffff-ffff-ffff-ffffffffffff, RFC 9562에서 새로 추가).

새 시스템에는 RFC 9562가 v1과 v6보다 v7을, v3보다 v5를 권장합니다. 값이 생성 시점에 대해 아무것도 드러내지 않아야 한다면 여전히 v4가 무난한 선택입니다.

버전128비트 구성생성 방식시간순 정렬
v1시간 + 노드 · §5.1시각(100나노초) + 클럭 시퀀스 + 노드아니요
v2DCE 보안: 예약됨, RFC 9562에 레이아웃 정의 없음생성하지 않음: 레이아웃 정의 없음–
v3이름 · MD5 · §5.3네임스페이스 + 이름의 MD5아니요
v4무작위 · §5.4무작위 비트아니요
v5이름 · SHA-1 · §5.5네임스페이스 + 이름의 SHA-1아니요
v6정렬 가능한 v1 · §5.6v1의 필드, 시각의 상위 비트가 앞예
v7시간순 · §5.7Unix 시간(ms) + 무작위 비트예
v8사용자 지정 · §5.8생성자 고유의 레이아웃아니요
Nil§5.9모두 0: “값 없음”–
Max§5.10모두 1: 센티널 값–
  • 시각
  • 무작위
  • 해시
  • 클럭 시퀀스
  • 노드
  • 버전
  • 변형
각 막대는 RFC 9562의 테스트 벡터를 바탕으로 각 버전의 128비트를 RFC의 레이아웃대로 나타낸 것입니다. 시각을 맨 앞에 두는 것은 v7과 v6뿐이므로, 텍스트로 시간순 정렬이 되는 것도 이 둘뿐입니다.

UUID v4와 v7 비교: 무엇을 써야 하나요?

데이터베이스 키나 정렬하거나 인덱스를 거는 모든 것에는 v7을 쓰세요. 생성 시각으로 시작하므로 새 행이 인덱스 끝에 들어갑니다. ID가 생성 시점을 드러내면 안 될 때는 v4를 쓰세요. 자유롭게 쓸 수 있는 122비트가 모두 무작위입니다.

무작위 v4 키는 삽입할 때마다 B-tree 인덱스 곳곳에 흩어져 페이지 분할을 일으키고, 인덱스의 더 많은 부분을 메모리에 올려 두게 만듭니다. v7 키는 자동 증가 숫자처럼 순서대로 들어오면서도, 어느 서버든 데이터베이스에 묻지 않고 만들 수 있습니다. v7은 밀리초마다 무작위 비트 74개를 가지므로, 두 서버가 같은 순간에 만들어도 충돌하지 않습니다.

대신 v7을 보는 사람은 누구나 그것이 생성된 밀리초를 읽을 수 있습니다(위의 디코더에 붙여넣어 보세요). 그것이 문제라면 v4를 쓰거나, v7은 내부에서만 쓰고 외부에는 다른 ID를 보여 주세요.

B-tree 인덱스에 12번 삽입리프 페이지 8개 · 각 키 16개
v4 키는 아무 데나 들어감8페이지 중 7페이지에 삽입 · 페이지 분할 3회
첫 바이트별 페이지
00–1f분할
20–3f
40–5f
60–7f
80–9f
a0–bf
c0–df분할
e0–ff분할
c100eb4b-4f3f-4b29-ad77-da7cd9d1eda592c97333-2db8-4fc2-b5b6-cedd8c7abede
v7 키는 끝에 들어감8페이지 중 1페이지에 삽입 · 페이지 분할 0회
키가 생성된 날짜별 페이지
10월 17일
10월 18일
10월 19일
10월 20일
10월 21일
10월 22일
10월 23일
10월 24일
01a16d3e-e1c0-70f6-99ec-6d454991b2fa01a16d3e-e1c0-70f6-99ec-6d45c2f6b35b
  • 인덱스에 이미 있는 키
  • 빈 자리
  • 새 v4
  • 새 v7
  • 페이지 분할: 키의 절반이 새 페이지로 이동
벤치마크가 아니라 모델입니다. 리프 페이지마다 키가 16개 들어갑니다. 무작위 키는 거의 꽉 찬 오래된 페이지로 들어가 분할을 일으키고, v7은 첫 바이트가 시각이므로 12개 모두 아직 여유가 있는 최신 페이지로 들어갑니다.

GUID와 UUID: 차이가 있나요?

GUID와 UUID는 같은 텍스트 형식의 같은 128비트 값이며, GUID는 Microsoft가 붙인 이름입니다. .NET의 Guid.NewGuid()는 무작위 버전 4 UUID를, .NET 9의 Guid.CreateVersion7()은 버전 7 UUID를 만듭니다.

차이는 메모리에 있습니다. Microsoft의 GUID 구조체는 앞의 세 그룹을 리틀 엔디언 정수로 저장하므로, .NET의 ToByteArray()는 앞 8바이트를 RFC 9562의 네트워크 바이트 순서와 다른 순서로 내놓습니다. 919108f7-52d1-…은 바이트로 f7 08 91 91 d1 52 …가 됩니다. 텍스트는 같지만, 시스템 간에 옮기는 원시 바이트는 변환이 필요합니다. 디코더는 두 순서를 모두 보여 줍니다.

SQL Server의 uniqueidentifier는 마지막 6바이트를 먼저 기준으로 정렬하므로, 그곳에서는 v7 값도 시간 순서를 유지하지 못합니다. NEWSEQUENTIALID()는 순서를 유지하는 값을 만들지만, 재시작 후 다시 더 작은 값부터 시작할 수 있고 추측하기도 쉽습니다. 오래된 COM GUID는 RFC 9562의 변형 비트 대신 Microsoft 고유의 변형 비트를 가질 수 있으며, 디코더는 그 변형의 이름을 알려 줍니다.

GUID 하나, 바이트 순서 세 가지16바이트
919108f7-52d1-4320-9bac-f847db4148a8
RFC 9562 네트워크 바이트 순서
.NET Guid.ToByteArray()
SQL Server uniqueidentifier 순서마지막 6바이트가 순서를 결정
  • Data1 · 4바이트, 역순
  • Data2 · 역순
  • Data3 · 역순
  • Data4 · 그대로
같은 텍스트가 메모리에 놓이는 모습입니다. .NET은 앞의 세 그룹을 리틀 엔디언으로 저장하고, SQL Server는 마지막 6바이트를 먼저 기준으로 정렬하므로, 시간순인 v7 키도 그곳에서는 순서를 유지하지 못합니다.

코드로 UUID 생성하는 방법

대부분의 언어는 v4 UUID를 한 줄로 만들고, 이제 v7을 만드는 언어도 많습니다. Python 3.14의 uuid.uuid7(), .NET 9의 Guid.CreateVersion7(), Java 26의 UUID.ofEpochMillis(), Go 1.27의 uuid.NewV7(), Node.js 26.1의 crypto.randomUUIDv7(), PostgreSQL 18의 uuidv7()입니다. 브라우저에는 여전히 v4를 만드는 crypto.randomUUID()뿐입니다.

언어를 고르면 한 줄짜리 코드가 나옵니다. 모든 v7이 같은 밀리초에 만든 UUID의 순서를 지키지는 않습니다. Python과 Go는 지키지만 .NET과 Node.js는 보장하지 않습니다. 또 MySQL의 UUID()는 버전 1 UUID를 반환하며, Linux와 Windows에서는 서버의 실제 MAC 주소가 담깁니다.

언어별 내장 UUID 함수

Python
import uuid

uuid.uuid4()   # v4
uuid.uuid7()   # v7, Python 3.14+
uuid.uuid5(uuid.NAMESPACE_DNS, "www.example.com")  # v5

uuid7()은 42비트 카운터를 유지하므로 같은 밀리초의 UUID도 순서가 유지됩니다.

각 언어의 공식 문서에 나온 버전입니다. 마크는 각 프로젝트의 공식 로고입니다.

두 UUID가 같을 수 있나요?

이론적으로는 그렇지만 실제로는 아닙니다. v4 UUID는 무작위 비트가 122개로, 가능한 값이 약 5.3 × 10³⁶개입니다. 어떤 두 개가 일치할 확률이 10억분의 1이 되려면 약 103조 개를, 확률이 반반이 되려면 약 270경 개를 만들어야 합니다.

이것이 생일 문제의 경계(birthday bound)입니다. N개 중에서 무작위 값 n개를 고르면 중복이 생길 확률은 약 1 − e^(−n(n−1)/2N)입니다. 1초에 UUID를 10억 개씩 만들어도 확률이 50%가 되려면 약 86년이 걸립니다. 실제 중복은 고장 난 생성기에서 생깁니다. 무작위가 아닌 시드, 난수 상태째 복제된 가상 머신, 손으로 복사한 ID 같은 경우입니다.

v7에서는 같은 밀리초에 만든 UUID끼리만 일치할 수 있고, 무작위 비트 74개가 그것들을 구별합니다. 이 페이지의 생성기는 한 밀리초 안에서도 일괄 생성 순서를 유지하므로(RFC 9562 §6.2), 한 번에 10,000개를 만들어도 모두 고유하고 정렬되어 있습니다.

생일 문제의 경계저희 계산
어떤 두 개가 같을 확률1.1 × 1019분의 1p ≈ 9.4 × 10−20

1초에 10억 개씩 만들어도 그만큼 만들려면 1초 걸립니다.

p ≈ 1 − e^(−n(n−1)/2N)이며, N은 v4에서 2¹²², v7에서는 밀리초당 2⁷⁴입니다. RFC 9562는 충돌 확률을 제시하지 않으므로, 이 값은 페이지가 쓰는 것과 같은 함수로 저희가 계산한 것입니다.

UUID 디코더: UUID에서 타임스탬프를 읽는 방법

위의 UUID 디코더 겸 검증기인 “디코드 및 검증” 탭에 UUID를 붙여넣으세요. 정해진 두 위치에서 버전과 변형을 읽은 다음, 그 버전이 정의하는 필드를 읽습니다. v7에서는 생성된 밀리초를, v1이나 v6에서는 100나노초 단위의 시각과 클럭 시퀀스, 노드 ID를 알 수 있습니다.

v1이나 v6의 노드에서 멀티캐스트 비트가 0이면 네트워크 카드의 실제 MAC 주소일 수 있습니다. MAC 주소 조회에서 제조사를 찾아보세요. 개인정보를 존중하는 생성기는 이 비트를 1로 설정하고 무작위 노드를 쓰며, 이 생성기도 그렇습니다.

시각은 생성기가 기록한 것이며 UUID가 만들어진 시점의 증거가 아닙니다. v4에는 시각 없이 무작위 비트만 있고, v3, v5, v8에는 해시가 들어 있어 읽어 낼 것이 없으며, 해시를 되돌려 이름을 알아낼 수도 없습니다. 목록을 붙여넣으면 최대 1,000개를 한 번에 검사해 잘못된 줄, 중복, 시간 기반 UUID의 순서를 확인합니다.

같은 순간을 쓰는 두 가지 방법RFC 9562 · Appendix A
017f22e2-79b0-7cc3-98c4-dc0c0c07398f
  1. unix_ts_ms0x017f22e279b0
  2. 1970년부터의 밀리초1 645 557 742 000
  3. UTC2022-02-22T19:22:22.000Z
c232ab00-9414-11ec-b3c8-9f6bdeced846
  1. time_high · time_mid · time_low1ec 9414 c232ab00
  2. 1582-10-15부터 100나노초 단위138 648 505 420 000 000
  3. UTC2022-02-22T19:22:22.0000000Z

같은 순간입니다. RFC 9562의 예시는 함께 만들어졌습니다.

v7은 1970년부터의 밀리초로 시작합니다. v1은 시각의 하위 부분을 먼저 저장하므로, 디코더는 세 부분을 원래 순서로 되돌린 뒤 1582년 10월 15일부터 셉니다.

이름 기반 UUID: v5와 v3

v5 UUID는 네임스페이스 UUID와 이름을 합친 값의 SHA-1 해시를 128비트로 자르고 버전과 변형을 설정한 것이며, 같은 일을 MD5로 하는 것이 v3입니다. 네임스페이스와 이름이 같으면 어느 컴퓨터에서든 항상 같은 UUID가 나옵니다. 위에서 v5를 고르면 이 페이지를 UUID v5 생성기로 쓸 수 있습니다.

RFC 9562는 네임스페이스 네 가지를 정의합니다. 도메인 이름용 DNS, URL, OID, X.500입니다. 그래서 DNS 네임스페이스의 www.example.com은 v5로 항상 2ed6657d-e927-568b-95e1-2665a8aea6a2입니다. 이미 고유한 이름이 있는 대상에 매핑을 저장하지 않고 안정적인 ID를 붙이고 싶을 때 이름 기반 UUID를 쓰세요.

v3보다 v5를 고르세요. MD5가 더 약하고, RFC 9562도 v5를 권장합니다. 둘 다 이름을 숨기는 방법은 아닙니다. 이름을 추측할 수 있는 사람은 누구나 같은 UUID를 계산할 수 있습니다. 이 페이지의 v8 옵션은 RFC 자체의 v8 예시처럼 SHA-256을 같은 방식으로 씁니다.

네임스페이스 + 이름 → v5RFC 9562 §5.5
  1. 네임스페이스6ba7b810-9dad-11d1-80b4-00c04fd430c8DNS · 16바이트
  2. 이름"www.example.com"UTF-8 · 15바이트
  3. SHA-1 다이제스트, 160비트2ed6657de927468b55e12665a8aea6a22dee3e35앞 128비트를 사용
  4. 결과 UUID2ed6657d-e927-568b-95e1-2665a8aea6a2버전 자리 4 → 5 · 변형 자리 5 → 9
  • DNS6ba7b810…
  • URL6ba7b811…
  • OID6ba7b812…
  • X.5006ba7b814…
RFC 9562의 v5 예시로, DNS 네임스페이스의 www.example.com입니다. 같은 네임스페이스와 이름을 해시하면 어느 컴퓨터에서든 같은 UUID가 나옵니다.

ULID와 UUID v7 비교(그리고 다른 ID들)

ULID와 UUID v7은 둘 다 48비트 밀리초 타임스탬프로 시작하고 시간순으로 정렬됩니다. 차이는 ULID가 나머지 80비트를 모두 무작위성에 쓰고 Base32 26자로 표기하는 반면, v7은 6비트를 버전과 변형에 쓰고 모든 UUID 열과 라이브러리에 그대로 맞는다는 점입니다.

데이터베이스, ORM, API가 이미 UUID를 지원한다면 v7을 쓰면 새 타입 없이 시간 순서를 얻을 수 있습니다. NanoID 같은 짧은 ID는 정한 길이의 무작위 문자열로, 시각도 표준 레이아웃도 없습니다. 어떤 UUID든 더 짧게 쓸 수도 있습니다. Base64url로는 22자, Base58에서는 최대 22자입니다.

ID 세 개, 각 128비트실제 비율
UUID v7시각, 그다음 무작위
36자시간순 정렬
ULID시각, 그다음 무작위
26자시간순 정렬
UUID v4무작위만
36자순서 없음
  • 1970년부터의 밀리초
  • 무작위
  • 버전과 변형
UUID v7과 ULID는 48비트 밀리초 시계를 공유합니다. v7은 버전과 변형에 6비트를 쓰고, ULID는 80비트를 모두 무작위성에 씁니다. v4는 무작위뿐이며, Base64url로는 어떤 UUID든 22자입니다.

UUID를 토큰으로 써도 안전한가요?

아니요. RFC 9562는 UUID가 추측하기 어렵다고 가정하지 말고, 보안 권한 증표(security capability), 즉 가지고 있는 것만으로 접근이 허용되는 ID로는 절대 쓰지 말라고 합니다. 비밀번호 재설정 링크나 API 키가 그런 예입니다.

좋은 생성기로 만든 v4는 무작위이지만, v1, v6, v7은 생성 시각을 드러내고 v3·v5는 이름으로 다시 계산할 수 있습니다. 비밀 값에는 암호학적 생성기로 만든 256비트 무작위 값처럼 그 용도로 만든 토큰을 쓰고, 요청마다 권한을 확인하세요. 접근 권한을 따로 확인한다면 UUID를 공개 ID로 써도 괜찮습니다.

ID보는 사람이 알 수 있는 것비밀 값으로
v1, v6생성 시각, 그리고 어쩌면 네트워크 카드의 MAC 주소불가
v7생성된 밀리초불가
v5, v3새로운 정보는 없지만, 이름을 추측하면 같은 UUID가 나옴불가
v4정상적인 생성기라면 아무것도 없음불가
256비트 토큰없음: 비밀 값용으로 만들어짐가능
RFC 9562는 UUID가 추측하기 어렵다고 가정하거나 보안 권한 증표로 쓰지 말라고 합니다. 비밀 값에는 암호학적 생성기로 만든 토큰을 쓰고, 요청마다 접근 권한을 확인하세요.

UUID 생성기: 질문과 답변

UUID는 어떻게 생성하나요?

이 페이지를 열면 무작위 UUID v4가 복사할 수 있게 준비되어 있고, 새 UUID 버튼을 누르면 하나 더 만듭니다. v7을 고르면 UUID v7 생성기로 쓸 수 있고, 개수를 정하면 최대 10,000개를 한 번에 만들며, 중괄호나 Base64url 같은 형식도 고를 수 있습니다. 코드에서는 JavaScript의 crypto.randomUUID(), Python의 uuid.uuid4(), C#의 Guid.NewGuid()가 각각 한 줄로 v4를 만듭니다.

UUID의 뜻은 무엇이며, 무엇의 약자인가요?

Universally Unique Identifier(범용 고유 식별자)의 약자입니다. 919108f7-52d1-4320-9bac-f847db4148a8처럼 36자로 쓰는 128비트 값으로, 컴퓨터들이 중앙 등록 기관 없이 각자 만들어도 고유하리라고 기대할 수 있습니다. RFC 9562가 이를 정의합니다. Microsoft는 같은 값을 GUID(Globally Unique Identifier)라고 부릅니다.

GUID와 UUID는 같은 것인가요?

실무상으로는 같습니다. 128비트도 텍스트 형식도 같고, Guid.NewGuid()는 표준 버전 4 UUID를 만듭니다. 다른 점은 두 가지입니다. .NET은 앞의 세 그룹을 리틀 엔디언으로 저장하므로 원시 바이트 배열의 순서가 다르고, SQL Server는 uniqueidentifier 값을 마지막 그룹부터 정렬합니다. GUID를 생성하려면 이 페이지를 무작위 GUID 생성기로 쓰세요. 복사한 텍스트는 양쪽 모두에서 통합니다.

어떤 UUID 버전을 써야 하나요?

데이터베이스 키와 정렬하는 모든 것에는 버전 7을 쓰세요. 생성 시각으로 시작해서 인덱스가 조밀하게 유지됩니다. ID가 생성 시점을 드러내면 안 될 때는 버전 4, 같은 이름이 항상 같은 ID에 대응해야 할 때는 버전 5입니다. 새 작업에는 v1을 피하세요. RFC 9562는 대신 v7을 권장하며, v1에는 실제 MAC 주소가 담길 수 있습니다.

두 UUID가 같아질 수 있나요?

생성기가 정상이라면 천문학적으로 작은 확률로만 가능합니다. v4는 무작위 비트가 122개이므로, UUID를 약 103조 개 만들어야 중복이 한 번 생길 확률이 10억분의 1이 되고, 확률 50%에는 약 270경 개가 필요합니다. 실제 중복은 수학이 아니라 결함 있는 생성기, 복제된 가상 머신, 복사된 데이터에서 생깁니다.

UUID를 디코드할 수 있나요?

일부는 가능합니다. 모든 UUID는 버전과 변형을 보여 줍니다. v7은 생성된 밀리초도 드러내고, v1과 v6에서는 100나노초 단위의 시각, 클럭 시퀀스, 노드 ID를 알 수 있으며, 노드 ID가 실제 MAC 주소인 경우도 있습니다. v4에는 무작위 비트만 있고, v5와 v3에는 이름으로 되돌릴 수 없는 해시가 들어 있습니다. “디코드 및 검증” 탭에 붙여넣어 보세요.

UUID의 길이는 얼마인가요?

128비트, 즉 16바이트입니다. 텍스트로는 36자로, 16진수 32자리와 하이픈 4개를 8-4-4-4-12 그룹으로 씁니다. 하이픈 없이는 32자, 중괄호로 감싸면 38자, urn:uuid: 접두사를 붙이면 45자, Base64url로는 22자, 10진수 정수로는 최대 39자리입니다. 가능하면 텍스트가 아닌 네이티브 UUID 타입이나 16바이트로 저장하세요.

빈 GUID 또는 Nil UUID란 무엇인가요?

128비트가 모두 0인 값, 00000000-0000-0000-0000-000000000000입니다. RFC 9562는 이를 Nil UUID라고 부르며, .NET의 Guid.Empty도 같은 값으로, 흔히 ID가 설정되지 않았음을 뜻하는 데 쓰입니다. RFC 9562는 모든 비트가 1인 Max UUID, ffffffff-ffff-ffff-ffff-ffffffffffff도 센티널 값으로 정의합니다(.NET 9: Guid.AllBitsSet). 둘 다 무작위가 아니므로 실제 ID로 쓰지 마세요.

UUID v7은 정렬할 수 있나요?

네. 앞의 48비트가 밀리초 단위 Unix 시간이므로, v7 UUID를 텍스트나 바이트로 정렬하면 밀리초 단위까지 생성 시각순으로 정렬됩니다. 같은 밀리초 안의 순서는 생성기에 따라 다르며, 이 생성기는 RFC 9562 6.2절에 설명된 대로 일괄 생성한 값을 엄격하게 증가시킵니다. 예외는 SQL Server의 uniqueidentifier로, 마지막 그룹부터 비교합니다.

UUID를 비밀번호나 액세스 토큰으로 써도 안전한가요?

아니요. RFC 9562는 UUID가 추측하기 어렵다고 가정하거나 보안 권한 증표로 쓰지 말라고 경고합니다. 시간 기반 버전은 생성 시점을 드러내고, 이름 기반 버전은 다시 계산할 수 있습니다. 비밀 값에는 암호학적 생성기로 만든 무작위 토큰을 쓰고, UUID는 접근 권한을 따로 확인하는 공개 ID로 다루세요. 비밀번호는 비밀번호 생성기로 만드세요.

여기서 만든 UUID는 어딘가로 전송되나요?

아니요. UUID는 브라우저의 암호학적으로 안전한 난수 생성기인 crypto.getRandomValues로 브라우저 안에서 만들어지고, 붙여넣은 UUID도 내 기기에서 디코드됩니다. 생성하거나 붙여넣은 어떤 것도 저희나 다른 누구에게 전송되지 않습니다. 공유 링크에는 내가 고른 것, 즉 버전, 개수, 형식, v5의 이름, 또는 디코더에 붙여넣은 UUID만 담기므로, 그 내용을 공유할 때처럼 신중하게 공유하세요.

부족한 점이 있습니까?기능 또는 새 도구 제안하기

관련 도구