UUID v4 생성기

Generate cryptographically random UUID v4

포맷

개수:

UUID v4는 현대 소프트웨어에서 가장 널리 배포된 UUID 버전입니다. 타임스탬프나 네임스페이스 해시에서 비트를 파생하는 다른 버전과 달리, UUID v4는 완전히 랜덤 데이터로 구성됩니다. 원본에 대한 메타데이터 없이 고유 식별자가 필요할 때 가장 단순하고 이식성 높은 선택입니다.

이 생성기는 crypto.randomUUID()를 사용합니다. 이는 네이티브 브라우저 및 Node.js API로, 운영 체제의 암호학적으로 안전한 난수 생성기에서 엔트로피를 가져옵니다——TLS 키 자료에 사용되는 것과 동일한 소스입니다.

UUID v4란 무엇인가요?

UUID(Universally Unique Identifier)는 RFC 4122에서 표준화된 128비트 레이블입니다. 일반적으로 하이픈으로 8-4-4-4-12 패턴으로 그룹화된 32개의 16진수 문자로 표현됩니다:

550e8400-e29b-41d4-a716-446655440000

UUID v4에서 128비트 중 122비트가 무작위입니다. 나머지 6비트는 스펙에서 의무화한 고정 필드입니다: 4비트는 버전(0100 = 4)을 인코딩하고, 2비트는 RFC 4122 변형(10)을 인코딩합니다. 이 고정 비트 때문에 세 번째 그룹은 항상 4로 시작하고 네 번째 그룹은 항상 8, 9, a, 또는 b로 시작합니다.

UUID v4 구조 분석

550e8400-e29b-41d4-a716-446655440000 분해:

세그먼트비트의미
550e840032비트 무작위time_low (이름은 역사적——v4에서 완전히 무작위)
e29b16비트 무작위time_mid (역사적 이름——v4에서 완전히 무작위)
41d44비트 고정 + 12비트 무작위버전 니블 4 (이진 0100) + 12비트 무작위
a7162비트 고정 + 14비트 무작위변형 비트 10 (첫 번째 바이트의 MSB) + 14비트 무작위
44665544000048비트 무작위노드 (v4에서 완전히 무작위)
Note:네 번째 그룹 시작의 변형 니블은 항상 8, 9, a, 또는 b 중 하나입니다——해당 바이트의 상위 2비트가 10(RFC 4122 변형 마커)으로 고정되어 나머지 2비트가 자유롭게 변할 수 있기 때문입니다.

UUID v4 대 다른 버전

RFC 4122는 5개의 UUID 버전을 정의합니다. 각각 다른 문제를 해결합니다:

UUID v1타임스탬프 + MAC

60비트 타임스탬프(1582년 10월부터 100나노초 간격)와 호스트 MAC 주소를 결합합니다. 동일 머신 내에서 단조 증가합니다.

Use when: 시간 순서 ID가 필요하고 서버 신원 및 생성 시간 노출을 신경 쓰지 않을 때.

UUID v3MD5 해시

결정론적: 동일한 네임스페이스 + 이름은 항상 동일한 UUID를 생성합니다. MD5 해싱 사용.

Use when: 알려진 네임스페이스(예: DNS 이름)에서 재현 가능한 ID가 필요할 때. v3보다 v5를 선호하세요.

UUID v4무작위

암호학적으로 안전한 122비트 무작위성. 타임스탬프, MAC, 네임스페이스 없음. 가장 일반적인 범용 선택.

Use when: 구조적 의미 없이 최대 프라이버시를 가진 고유 ID가 필요할 때.

UUID v5SHA-1 해시

v3과 유사하지만 SHA-1 사용. 네임스페이스 + 이름에서 여전히 결정론적.

Use when: 재현 가능한 콘텐츠 주소 지정 식별자(예: URL로 식별된 리소스의 안정적 ID)가 필요할 때.

UUID v7시간 순서 무작위

신규 버전(RFC 9562, 2024). 상위 비트에 Unix 밀리초 타임스탬프를 인코딩하고 무작위 비트가 뒤따릅니다. 정렬 가능하고 데이터베이스 친화적.

Use when: 자연적인 시간 순서를 가진 데이터베이스 인덱스 친화적 ID가 필요할 때 (새 프로젝트에서 v1보다 선호).

UUID v4를 사용할 때

추가 제약 없이 단순히 "고유 ID"가 필요한 대다수의 상황에서 UUID v4가 올바른 선택입니다:

사용자 및 계정 ID

계정 생성 시간이나 서버 신원을 드러내지 않는 불투명한 사용자 ID. 열거하거나 추측할 수 없습니다.

데이터베이스 기본 키

모든 데이터베이스 엔진과 함께 작동합니다. UUID v4는 클라이언트 측에서 안전하게 생성하고 조율 없이 분산 소스에서 병합할 수 있습니다——시퀀스 테이블이나 중앙 ID 서비스가 필요 없습니다.

세션 및 토큰 ID

122비트의 무작위성은 무차별 대입 추측을 계산적으로 불가능하게 만듭니다——122비트 무작위 토큰과 동등한 강도입니다.

파일 및 객체 이름

업로드, S3 객체 키, 또는 캐시 항목을 위한 중복 제거 안전 파일명. 두 클라이언트가 동일한 키에 쓸 위험이 없습니다.

멱등성 키

요청을 제출하기 전에 클라이언트에서 UUID를 생성합니다. 서버는 공유 카운터 없이 재시도 요청을 안전하게 중복 제거할 수 있습니다.

상관 및 추적 ID

모든 로그 라인과 분산 추적 스팬에 UUID를 첨부합니다. 서비스나 머신 간 조율이 필요 없습니다.

Note:사용 사례가 정렬 가능한 ID를 필요로 하는 경우(예: 데이터베이스 행을 삽입 시간별로 클러스터링하고 싶을 때), 대신 UUID v7을 고려하세요. UUID v4는 의도적으로 무작위이며 높은 삽입 속도에서 B-tree 인덱스의 인덱스 단편화를 유발합니다.

충돌 확률

122개의 무작위 비트로 UUID v4 공간에는 2122 ≈ 5.3 × 1036개의 가능한 값이 있습니다. 충돌 확률은 생일 문제를 따릅니다:

생성된 UUID 수충돌 확률
10억(109)약 1/5.3 × 1018
1조(1012)약 1/5.3 × 1012
1018(1엑사바이트 분량)약 1/5,300

일반적으로 인용되는 기준: 단일 충돌이 발생할 50% 확률을 갖기 위해서는 약 2.71 × 1018개의 UUID를 생성해야 합니다. 초당 10억 개의 UUID 속도로 약 85년의 지속적인 생성이 필요합니다. 실제 애플리케이션에서 충돌은 실질적인 우려 사항이 아닙니다.

코드 예제

JavaScript — 브라우저 및 Node.js 14.17+

crypto.randomUUID() 메서드는 모든 최신 브라우저(Chrome 92+, Firefox 95+, Safari 15.4+)와 Node.js 14.17+에서 네이티브로 사용 가능합니다. 패키지 설치가 필요 없습니다.

js
// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"

// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())

Node.js — 구 버전(uuid 패키지)

js
const { v4: uuidv4 } = require('uuid')

const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"

Python

python
import uuid

# Generate a UUID v4
id = str(uuid.uuid4())
# → '110e8400-e29b-41d4-a716-446655440000'

# The uuid module uses os.urandom() — cryptographically secure
print(uuid.uuid4().hex)  # without hyphens
# → '110e8400e29b41d4a716446655440000'

Go

go
import "github.com/google/uuid"

id := uuid.New().String()
// → "110e8400-e29b-41d4-a716-446655440000"

// Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic)
// Always prefer github.com/google/uuid for production use

Rust

toml
# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }
rust
use uuid::Uuid;

let id = Uuid::new_v4().to_string();
// → "110e8400-e29b-41d4-a716-446655440000"

자주 묻는 질문

UUID v4는 암호학적으로 안전한가요?

UUID v4 자체는 보안 프리미티브가 아닙니다——식별자 형식입니다. 그러나 crypto.randomUUID()(브라우저 또는 Node.js)나 동등한 OS 수준 API를 통해 생성될 때 기반 엔트로피는 암호학적으로 안전합니다. 즉 UUID v4 값은 예측 불가능성이 중요한 세션 토큰이나 멱등성 키로 사용하기에 적합합니다. 보안에 민감한 컨텍스트에서는 Math.random() 기반 UUID 생성기를 사용하지 마세요——OS CSPRNG에서 명시적으로 가져오는 API만 사용하세요.

두 UUID v4가 같을 수 있나요?

이론적으로는 가능하지만 실제로는 그렇지 않습니다. 현실적인 데이터셋(수십억 개의 ID) 내에서 중복을 생성할 확률은 천문학적으로 작습니다——하드웨어 결함으로 인한 데이터 손상보다 훨씬 가능성이 낮습니다. UUID v4 충돌은 프로덕션 시스템 설계에서 불가능한 것으로 취급됩니다.

UUID v4 대 nanoid——어느 것을 써야 하나요?

둘 다 CSPRNG로 지원되는 무작위 ID 생성기입니다. 주요 차이점:

  • UUID v4는 RFC 4122 표준을 따르고, 모든 데이터베이스와 프레임워크에서 인식되며, 의존성이 없습니다(네이티브 crypto.randomUUID()).
  • nanoid는 URL 안전 알파벳을 사용하고 기본적으로 더 짧습니다(21자 대 36자). URL 길이나 가독성이 중요할 때 유용합니다. npm 패키지가 필요합니다.

외부 시스템과의 상호 운용성이 중요할 때(API, 데이터베이스, 로깅 인프라) UUID v4를 선호하세요. 더 짧은 ID를 원하고 전체 스택을 제어할 때 nanoid를 선호하세요.

UUID를 데이터베이스에 문자열로 저장해야 하나요 아니면 이진수로 저장해야 하나요?

대부분의 데이터베이스에서 VARCHAR(36) 문자열(36바이트)보다 UUID 또는 BINARY(16) 열(16바이트)로 저장하는 것이 더 효율적입니다. PostgreSQL은 네이티브 uuid 타입을 가집니다. MySQL과 MariaDB는 BINARY(16)UUID_TO_BIN() / BIN_TO_UUID() 헬퍼와 잘 작동합니다. SQLite 사용자는 일반적으로 TEXT로 저장합니다.

UUID v4에 하이픈이 있는 이유는 무엇인가요——생략할 수 있나요?

하이픈은 RFC 4122에 정의된 UUID의 표준 표현의 일부입니다. 순수하게 장식적입니다——정보를 전달하지 않으며 128비트 값에 영향을 미치지 않습니다. 생략하면 기능적으로 동등한 압축된 32자 16진 문자열을 얻습니다. 대부분의 UUID 파서는 두 형식을 모두 받아들입니다.

js
const id = crypto.randomUUID()              // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '')     // "550e8400e29b41d4a716446655440000"