UUID 생성기

UUID 만드는 방법

1. v4 (무작위)와 v7 (시간순) 중 하나를 고릅니다.
2. 개수를 정합니다. 한 번에 1개부터 1,000개까지 만들 수 있습니다.
3. 형식을 고릅니다. 대문자, 32자로 짧게 쓰는 하이픈 없이, Windows 레지스트리 파일이나 일부 .NET 코드에서 쓰는 모양인 중괄호로 감싸기 { }가 있고, 여러 옵션을 함께 켤 수 있습니다.
4. 복사로 목록 전체를 클립보드에 담거나, .txt 다운로드로 한 줄에 하나씩 저장합니다. 생성을 누르면 새 목록이 만들어집니다.

옵션을 바꾸면 지금 목록의 모양만 바뀌는 것이 아니라 새 목록이 만들어집니다. 필요한 목록은 형식을 바꾸기 전에 복사해 두세요.

UUID의 구조

UUID(universally unique identifier)는 128비트 숫자로, 보통 16진수 32자리를 8-4-4-4-12의 다섯 묶음으로 나눠 씁니다. 두 자리는 정해진 정보를 담습니다. 세 번째 묶음의 첫 자리는 버전이고, 네 번째 묶음의 첫 자리는 변형(variant)입니다. 2024년에 RFC 4122를 대체한 표준인 RFC 9562가 정의한 표준 버전에서는 변형 자리가 항상 8, 9, a, b 중 하나입니다.

v4와 v7 중 무엇을 쓸까

버전 4는 흔히 아는 무작위 UUID로, JavaScript의 crypto.randomUUID()나 Python의 uuid.uuid4()처럼 대부분의 라이브러리가 기본으로 만드는 것입니다. ID가 아무 정보도 드러내지 않아야 하고 순서가 상관없을 때 씁니다. URL에 드러나는 공개 ID, 파일 이름, 로그의 상관관계 ID 같은 곳입니다.

버전 7은 타임스탬프로 시작하므로 나중에 만든 ID가 먼저 만든 ID보다 뒤에 정렬됩니다. 텍스트로 비교해도, 바이트로 비교해도 마찬가지입니다. 이것은 데이터베이스 기본 키에서 중요합니다. 무작위 v4 키를 B-트리 인덱스에 넣으면 쓰기가 인덱스 전체에 흩어지지만, v7 키는 순서대로 들어와 끝부분에 붙으므로 인덱스가 촘촘하게 유지되고 삽입이 빠릅니다. 이 생성기는 같은 밀리초 안에서 12비트 카운터(무작위 값에서 시작)를 써서, v7 UUID 1,000개를 한 번에 만들어도 순서가 엄격하게 증가합니다.

예: v7 UUID 속 시각 읽기

019b76da-a800-7a3c-9f12-5c0e8b4d71e6을 예로 들어 봅시다. 앞의 16진수 12자리 019b76daa800이 생성 시각입니다. 이것을 진법 변환기의 16진수 칸에 붙여 넣으면 1767225600000이 나오고, 이 값을 유닉스 타임스탬프 변환기에 넣으면 2026년 1월 1일 00:00:00.000 UTC(한국 시간 오전 9시)입니다. 같은 방법으로 레코드가 언제 만들어졌는지 알 수 있으며, 바로 그 때문에 생성 시각이 비밀이어야 하는 곳에는 v7 ID를 쓰지 않는 것이 좋습니다.

얼마나 ‘고유’한가

v4 UUID가 가질 수 있는 값은 2¹²²개, 약 5.3 × 10³⁶개입니다. 생일 역설에 따르면 중복이 하나라도 생길 확률이 50%에 이르려면 약 2.7 × 10¹⁸개를 만들어야 합니다. v4 UUID를 1조 개 만드는 시스템에서도 그중 두 개가 같을 확률은 약 10조분의 1입니다. 이는 좋은 난수원을 전제로 하며, 이 페이지는 브라우저의 암호학적으로 안전한 난수 생성기인 crypto.getRandomValues를 씁니다. 실제로 생기는 중복은 우연이 아니라 버그, 즉 복사된 시드, 재사용한 목록, 운영 환경에 남겨 둔 테스트용 생성기 때문입니다.

다른 버전 간단히 보기

• v1과 v6은 타임스탬프와 노드 식별자(예전에는 네트워크 카드의 MAC 주소)를 합친 것입니다. v6은 v1의 필드 순서를 바꿔 시간순으로 정렬되게 했지만, RFC 9562는 새 시스템에는 v7을 권합니다.
• v3과 v5는 무작위가 아닙니다. 네임스페이스와 이름을 각각 MD5와 SHA-1로 해시하므로, 같은 이름은 언제나 같은 UUID가 됩니다.
• v8은 업체별 독자 형식을 담는 용도입니다.
• nil UUID는 모두 0인 00000000-0000-0000-0000-000000000000이며, 흔히 ‘값 없음’을 나타내는 데 씁니다.

실무 팁

• 데이터베이스가 지원한다면 UUID는 36자 문자열보다 전용 uuid 열이나 16바이트 바이너리로 저장하세요. 비교가 빠르고 인덱스가 작아집니다.
• UUID는 대소문자를 구분하지 않고 비교하세요. 표준은 소문자로 쓰고 Microsoft 도구는 대문자로 쓰는 경우가 많지만 둘은 같은 값입니다.
• 하이픈을 뺀 UUID도 같은 숫자입니다. 어떤 시스템이 값을 거부한다면 ID를 의심하기 전에 하이픈이나 중괄호를 요구하는지부터 확인하세요.

자주 묻는 질문

GUID와 UUID는 같은 것인가요?

네. GUID는 같은 128비트 형식을 Microsoft에서 부르는 이름이며, 보통 중괄호 안에 대문자로 씁니다: {3F2C8E91-6B0D-4A57-9C1E-27D4F08B6A3E}. 대문자와 중괄호를 함께 켜면 이 모양이 됩니다.

UUID를 비밀번호나 비밀 토큰으로 써도 되나요?

피하세요. v4 UUID는 추측하기 어렵지만 식별자로 설계된 것이고, 많은 시스템이 ID를 로그나 URL에 그대로 남깁니다. v7 UUID는 무작위 비트가 더 적고 생성 시각까지 드러냅니다. 비밀 값에는 그 용도로 만든 무작위 토큰을 쓰세요.

여러 서버에서 만든 v7 UUID도 순서가 보장되나요?

서버들의 시계가 맞는 만큼만 보장됩니다. 한 생성기 안에서는 순서가 정확하지만, 여러 서버에서 같은 밀리초에 만들었거나 시계가 어긋나 있으면 순서가 섞일 수 있습니다.

왜 모든 UUID의 두 번째 하이픈 뒤에 4나 7이 있나요?

그 자리가 버전 필드이고, 세 번째 하이픈 뒤 첫 자리가 변형 필드입니다. 둘 다 표준이 정해 두었기 때문에 v4 UUID의 무작위 비트는 128개가 아니라 122개입니다. 이 자리들은 ID를 만든 방식을 알려 줄 뿐, 생성기의 난수가 좋았는지까지 증명하지는 못합니다.