UUID(Universally Unique Identifier) 128비트 비트 구조 및 충돌 가능성 분석
UUID(Universally Unique Identifier) 또는 Microsoft 호환 명칭인 GUID(Globally Unique Identifier)는 분산 컴퓨팅 환경에서 중앙 서버나 조율 기관(Central Authority)의 개입 없이 독립된 노드들이 고유한 데이터 식별자를 안전하게 생성할 수 있도록 설계된 128비트 규격 표준입니다.
IETF RFC 9562(기존 RFC 4122 계승) 사양에 따라 16진수 32자리 문자열과 4개의 하이픈(-)으로 조합된 8-4-4-4-12 형태(예: f47ac10b-58cc-4372-a567-0e02b2c3d479)로 표현됩니다. 본 생성기는 웹 브라우저의 crypto.getRandomValues() 엔트로피 원천을 통해 클라이언트 사이드에서 즉시 연산됩니다.
W3C Web Crypto API 기반 엔트로피
의사 난수(Math.random) 대신 암호학적으로 안전한 웹 크립토 난수를 적용하여 예측 불가능한 128비트 고유성을 제공합니다.
v1, v4, v7 3대 핵심 버전 완벽 지원
가장 널리 쓰이는 무작위 v4, 시간 순차 정렬 DB 최적화 v7, 레거시 v1 버전을 선택하여 즉시 일괄 연산할 수 있습니다.
대량 생성 & 텍스트 내보내기
1회 클릭으로 최대 100개의 UUID를 연산하며, 클립보드 복사 및 즉시 다운로드 가능한 .txt 파일 내보내기를 지원합니다.
1. RFC 9562 표준 주요 UUID 버전별 비교 및 선택 기준표
각 UUID 버전의 내부 비트 구조와 권장 실무 사용 시나리오입니다.
| UUID 버전 (Version) | 주요 구성 요소 (Structure) | 충돌 위험성 (Safety) | 특징 및 실무 권장 분야 | |
|---|---|---|---|---|
| UUID v4 | 122-bit Crypto Random | 사실상 0% | 가장 보편적 기본 표준 (API 토큰, 세션 ID, 웹 서비스) | 중앙 조율 없는 완전 무작위 생성 |
| UUID v7 | 48-bit Unix Time + 74-bit Random | 사실상 0% | 차세대 DB PK 최적화 (PostgreSQL, MySQL B-Tree 인덱싱) | 시간 순 정렬 가능, DB 파편화 방지 |
| UUID v1 | 60-bit Timestamp + MAC Address | 동일 MAC/시간 중복 주의 | 레거시 분산 환경 (MAC 주소 노출 보안 주의) | 하드웨어 위치 추적 가능성 존재 |
| UUID v3 / v5 | MD5 (v3) / SHA-1 (v5) Name-based | 네임스페이스 동일시 확정 충돌 | 네임스페이스 및 도메인 이름 기반 결정론적 식별자 | 동일 입력 시 항상 동일한 UUID 반환 |
2. UUID v4 수학적 충돌 확률 및 생일 역설(Birthday Paradox) 공식
① UUID v4의 총 가능한 조합 수:
- 128비트 중 버전(4bit) 및 버라이언트(2bit)를 제외한 122비트가 무작위 난수입니다. 가능 조합 수 개입니다.
② 개의 UUID를 생성했을 때 최소 1개 이상 중복이 발생할 생일 문제 확률 공식:
-
③ 실무적인 충돌 가능성 체감 비유:
- 1초에 10억 개의 UUID v4를 85년 동안 계속 생성하더라도, 단 한 번이라도 충돌이 일어날 확률은 미만입니다. 따라서 모든 분산 DB에서 유일성 검사 없이 안전하게 식별자로 채택할 수 있습니다.
3. RFC 9562 UUID v7의 B-Tree 인덱스 파편화 방지 매커니즘 심층 분석
① 기존 UUID v4의 RDBMS 데이터베이스 성능 저하 이유:
- UUID v4는 완전 무작위 128비트이므로, PostgreSQL이나 MySQL(InnoDB)의 Primary Key로 사용 시 Clustered B-Tree 인덱스의 임의 위치에 데이터가 난잡하게 삽입됩니다. 이로 인해 디스크 Random I/O 폭증 및 B-Tree Page Split(페이지 분할) 현상이 발생하여 데이터 양이 커질수록 쓰기 성능이 급격히 저하됩니다.
② UUID v7의 시간 정렬(Time-Ordered) 혁신 구조:
- RFC 9562로 정식 제정된 UUID v7은 상위 48비트에 Unix Epoch 밀리초 타임스탬프를 배치하고 하위 74비트에 암호학 무작위 엔트로피를 조합합니다.
- 데이터가 생성된 시간 순서대로 B-Tree 인덱스 끝부분에 연속적(Sequential Write)으로 삽입되므로, Auto Increment BigInt PK 수준의 높은 인덱스 쓰기 성능과 90% 이상의 디스크 파편화 절감 효과를 동시에 얻을 수 있습니다.
4. 고유 식별자 표준 사양 비교: UUID v7 vs ULID vs NanoID
현대 웹/백엔드 개발에서 널리 비교되는 3대 식별자 포맷 비교입니다.
| 식별자 표준 (Format) | 길이 / 인코딩 (Length & Encoding) | 시간 정렬 가능 (Sortable) | URL-Safe 지원 | 주요 실무 사용 환경 |
|---|---|---|---|---|
| UUID v7 | 36자 (16진수 + 4 하이픈) | 가능 (48-bit Unix Time) | 지원 (표준 16진수) | 국제 RFC 9562 표준, 모든 DB Native 타입 지원 |
| ULID | 26자 (Crockford Base32) | 가능 (48-bit Unix Time) | 지원 (Base32 대문자) | 문자열 길이 단축 선호 백엔드 및 로그 시스템 |
| NanoID | 21자 (Custom Alphabet) | 불가 (Pure Random) | 완벽 지원 | 단축 URL 생성, 클라이언트 단축 ID, 프론트엔드 키 |
5. 프로그래밍 언어별 UUID 생성 실무 코드 예시 (Code Cheatsheets)
// Node.js v14.17+ / Browser Native API
const uuidv4 = crypto.randomUUID();
console.log("Generated UUID v4:", uuidv4);import uuid
# UUID v4 (Random)
uuid_v4 = uuid.uuid4()
print("UUID v4:", str(uuid_v4))
# UUID v1 (Timestamp)
uuid_v1 = uuid.uuid1()
print("UUID v1:", str(uuid_v1))import java.util.UUID;
public class UuidDemo {
public static void main(String[] args) {
UUID uuid = UUID.randomUUID();
System.out.println("Generated UUID: " + uuid.toString());
}
}# Standard Terminal CLI uuidgen # Lowercase output uuidgen | tr '[:upper:]' '[:lower:]'
자주 묻는 질문 (FAQ)
Q.UUID v4와 UUID v7 중 DB Primary Key로 어떤 것을 써야 하나요?
최신 RDBMS(PostgreSQL, MySQL InnoDB 등)의 Primary Key로는 UUID v7을 강력히 권장합니다. UUID v4는 완전 무작위 방식이라 B-Tree 인덱스 삽입 시 무작위 디스크 I/O 파편화를 유발하지만, UUID v7은 상위 48비트에 Unix 밀리초 타임스탬프가 포함되어 시간순으로 정렬되므로 DB 인덱스 성능이 대폭 향상됩니다.
Q.UUID와 GUID는 완전히 다른 기술인가요?
동일한 기술입니다. UUID는 IETF/ISO 표준 공식 명칭이며, GUID(Globally Unique Identifier)는 Microsoft 호환 환경에서 사용하는 명칭입니다. 128비트 바이너리 구조 및 8-4-4-4-12 표현 포맷이 정확히 일치합니다.
Q.UUID v4 생성 시 보안상 안전한 무작위성이 보장되나요?
네, 보장됩니다. 본 도구는 일반 Math.random()을 사용하지 않고, 웹 브라우저 하드웨어 가속 암호화 난수 생성기인 crypto.getRandomValues()를 사용하므로 엔트로피 품질이 매우 높고 예측 불가능합니다.
Q.생성한 UUID가 외부 서버에 기록되거나 저장되나요?
저장되지 않습니다. 모든 연산은 사용자의 웹 브라우저 메모리 상에서 클라이언트 사이드로 실행되며 서버와의 통신이 발생하지 않습니다.
Q.대문자(UPPERCASE)와 소문자(LOWERCASE) 중 어느 것을 써야 하나요?
RFC 9562 표준 명세상 기본 표현은 소문자(lowercase)입니다. 다만 일부 레거시 시스템이나 Windows C# 호환 환경에서는 대문자를 선호하므로, 필요에 따라 상단 스위치로 대소문자를 전환할 수 있습니다.