범용 고유 식별자

개요

UUID(Universally Unique Identifier)는 전 세계적으로 고유한 식별자를 만들기 위해 고안된 128비트 표준 식별자이다. GUID(Globally Unique Identifier)라고도 불린다.

2024년 5월 7일, RFC 9562가 발표되어 3개의 새로운 "버전"이 도입되고 일부 모호함이 명확해졌다. 2005년의 RFC 4122를 대체하는 최신 규격으로, 새로운 버전 6, 7, 8이 정식 표준에 포함되었다.

UUID는 32자리 16진수 숫자를 8-4-4-4-12 형식으로 하이픈으로 구분하여 표현한다.

예시: 123e4567-e89b-12d3-a456-426614174000

버전 7 UUID(UUIDv7)는 고부하 데이터베이스와 분산 시스템의 키를 위해 설계되었으며, 48비트 빅엔디안 Unix Epoch 타임스탬프로 시작하여 대략 밀리초 단위의 정밀도를 제공한다.

역사

• 1987년: 아폴로 네트워크 컴퓨팅 시스템(NCS)에서 최초 개념 등장
• 1990년대: OSF DCE(Open Software Foundation Distributed Computing Environment)에서 표준화 시작
• 2005년: RFC 4122로 공식 표준화
• 2024년 5월 7일: RFC 9562로 대체, 버전 6·7·8 추가

구조

UUID는 총 128비트(16바이트)로 구성되며, 다음과 같은 필드로 나뉜다:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

• M: 버전 정보 (4비트)
• N: 변형(variant) 정보 (2~3비트)
• 나머지: 버전별로 다른 데이터

버전별 상세

버전 1 (타임스탬프 + MAC 주소)

• 구성: 60비트 타임스탬프 + 14비트 클록 시퀀스 + 48비트 MAC 주소
• 장점: 시간 순서 보장, 높은 고유성
• 단점: MAC 주소 노출로 인한 개인정보 이슈
• 사용 사례: 마이크로소프트 COM, 일부 데이터베이스 시스템

버전 2 (DCE 보안)

• 구성: 버전 1 + POSIX UID/GID
• 특징: 실무에서 거의 사용되지 않음
• 용도: DCE(Distributed Computing Environment) 보안 컨텍스트

버전 3 (이름 기반 + MD5)

• 구성: 네임스페이스 UUID + 이름을 MD5 해시
• 특징: 동일한 입력에 동일한 UUID 생성 (결정적)
• 단점: MD5의 보안 취약점
• 사용 사례: DNS 이름, URL 기반 식별자

버전 4 (난수 기반)

• 구성: 122비트 의사난수
• 장점: 가장 간단하고 널리 사용됨
• 단점: 완전 무작위라 정렬 불가, B-tree 인덱스 파편화 심각
• 사용 사례: 웹 애플리케이션, API 키, 세션 ID

버전 5 (이름 기반 + SHA-1)

• 구성: 네임스페이스 UUID + 이름을 SHA-1 해시
• 특징: 버전 3의 개선판, MD5 대신 SHA-1 사용
• 용도: 보안이 중요한 이름 기반 식별자

버전 6 (시간순 정렬 강화)

• 구성: 버전 1의 타임스탬프를 big-endian으로 재배치
• 장점: 시간 순 정렬 가능, MAC 주소 포함
• 단점: 여전한 개인정보 노출 위험
• 개선점: 버전 1의 정렬 문제 해결

버전 7 (Unix 에포크 밀리초)

• 구성: 48비트 Unix 타임스탬프(밀리초) + 74비트 난수
• 장점:
  • 시간 순 정렬 완벽 지원
  • 개인정보 노출 없음
  • 데이터베이스 인덱스 친화적
• 특징: 현재 가장 권장되는 버전
• 버전 7은 시간순 정렬이 바람직할 때 좋은 대안으로, 무작위성과 정렬 가능성 사이의 좋은 균형을 제공한다.

버전 8 (사용자 정의)

• 구성: 애플리케이션이 자유롭게 정의
• 용도: 특수한 요구사항이 있는 커스텀 구현
• 주의: 표준 호환성은 보장되지 않음

장단점

장점

• 전 세계적 고유성: 분산 환경에서도 중복 없이 고유한 식별자 생성 가능
• 충돌 가능성 극히 낮음: 2¹²² (≈5.3 × 10³⁶)개의 조합
• 독립성: 중앙 서버 없이도 생성 가능
• 범용성: 대부분의 프로그래밍 언어와 플랫폼에서 지원
• 표준화: RFC 표준으로 상호 운용성 보장

단점

• 크기: 16바이트로 대규모 데이터베이스에서는 부담
• 가독성: 사람이 읽고 기억하기 어려움
• 정렬 문제: 버전 4는 무작위 생성으로 인덱스 파편화 심각
• 보안 이슈: 버전 1, 6은 MAC 주소 노출 위험

충돌 확률

UUID의 충돌 확률은 천문학적으로 낮다.

• 이론적 계산: 초당 10억 개의 UUID를 100년간 생성해도 50% 충돌 확률에 도달하지 않음
• 실제 사례: 지금까지 공개된 UUID 충돌 사례는 0건
• 비교: 로또 1등 당첨(약 10^-8)보다 10²⁸배 더 낮은 확률

구현 및 채택 현황

데이터베이스

• PostgreSQL: uuid_generate_v7() 함수 제공 (pg_uuidv7 확장)
• MySQL: UUID(), UUID_TO_BIN() 함수 지원
• SQLite: hex(randomblob(16)) 형태로 구현
• DuckDB: 1.3.0에서 v7 지원 추가

프로그래밍 언어

Python

RFC 9562를 참조하여 UUID 버전 7과 8 구현에 대한 논의가 Python 커뮤니티에서 활발히 진행되고 있다.

import uuid

# 버전 4 (가장 일반적)
uuid4 = uuid.uuid4()

# 버전 1
uuid1 = uuid.uuid1()

# 버전 7은 아직 표준 라이브러리에 없음
# 외부 라이브러리 사용 필요

JavaScript/Node.js

// crypto 모듈 사용
const { randomUUID } = require('crypto');
const uuid = randomUUID(); // 버전 4

// uuid 패키지 사용
const { v4: uuidv4, v7: uuidv7 } = require('uuid');

Java

OpenJDK에서 RFC 9562에 정의된 UUID 버전 7(UUIDv7) 지원 추가를 위한 작업이 진행 중이다.

// 표준 라이브러리 (버전 4만 지원)
UUID uuid = UUID.randomUUID();

// 버전 7은 외부 라이브러리 필요

.NET/C#

.NET의 새로운 버전에서 Guid.CreateVersion7() 기능이 추가되었으며, 이를 .NET Framework에 백포트하는 노력이 있다.

// .NET 9.0 이상
var guid = Guid.CreateVersion7();

// 이전 버전에서는 외부 구현 필요

Go

// google/uuid 패키지
import "github.com/google/uuid"

// 버전 4
uuid := uuid.New()

// 버전 7 (일부 라이브러리에서 지원)

다중 언어 구현

JavaScript에서 Zig까지, 제3자 종속성 없이 33개 언어로 구현된 UUIDv7이 있다.

주요 서비스 채택

• GitHub: API 리소스 식별자
• Discord: 스노우플레이크 ID (UUID 유사 구조)
• MongoDB: ObjectId (UUID와 유사한 12바이트 식별자)
• AWS: 다양한 리소스 식별자
• Microsoft: COM, .NET GUID

성능 고려사항

데이터베이스 인덱스

버전	인덱스 성능	비고
버전 4	나쁨	B-tree 인덱스 파편화 심각
버전 7	우수	시간 순 정렬로 인덱스 성능 향상
버전 1, 6	보통	일부 정렬 가능하나 개인정보 노출

저장 공간

• UUID: 16바이트 (128비트)
• 정수 ID: 4~8바이트
• 문자열 표현: 36바이트 (하이픈 포함)

보안 고려사항

예측 가능성

• 버전 1, 6: MAC 주소와 시간 정보로 일부 예측 가능
• 버전 4, 7: 난수 기반으로 예측 불가능
• 버전 3, 5: 입력이 같으면 결과가 동일 (의도된 동작)

정보 노출 위험

• MAC 주소: 버전 1, 6에서 하드웨어 정보 노출
• 타임스탬프: 생성 시간 추정 가능
• 권장사항: 공개적으로 사용할 경우 버전 4나 7 사용

실무 사용 패턴

언제 UUID를 사용할까?

사용하면 좋은 경우

• 분산 시스템에서 고유 식별자 필요
• 마이크로서비스 간 데이터 교환
• API 리소스 식별자
• 세션 ID, 토큰
• 파일명, 임시 디렉토리명

사용하지 않는 것이 좋은 경우

• 순차적 번호가 필요한 경우 (주문번호 등)
• 사용자가 직접 입력해야 하는 경우
• 메모리/저장공간이 매우 제한적인 환경
• 초고성능이 필요한 정수 연산

버전 선택 가이드

용도	권장 버전	이유
일반적인 식별자	v4	간단하고 안전
데이터베이스 PK	v7	인덱스 성능 우수
시간 순서 중요	v7	밀리초 단위 정렬
결정적 생성	v5	같은 입력 → 같은 결과
레거시 호환	v1	기존 시스템과의 호환성

최신 동향 및 발전 방향

RFC 9562의 주요 변화

• 새로운 버전 추가: 버전 6, 7, 8의 정식 표준화
• 명확화: 기존 사양의 모호한 부분들 정리
• 현대적 요구사항 반영: 대용량 데이터베이스와 분산 시스템에 최적화

업계 채택 동향

• 데이터베이스 엔진: PostgreSQL, DuckDB 등에서 버전 7 지원 추가
• 프로그래밍 언어: .NET 9.0에서 네이티브 지원, Java OpenJDK에서 구현 검토 중
• 라이브러리 생태계: 다양한 언어에서 제3자 라이브러리 형태로 빠른 채택

트리비아

• UUID의 nil UUID는 모든 비트가 0인 00000000-0000-0000-0000-000000000000이다
• 브라켓 표기법도 존재한다: {123e4567-e89b-12d3-a456-426614174000}
• Microsoft는 UUID를 GUID(Globally Unique Identifier)라고 부른다
• PostgreSQL에서 UUID는 native 타입으로 지원되어 저장 공간을 절약할 수 있다
• 버전 7의 등장으로 Twitter의 Snowflake ID와 유사한 기능을 표준으로 사용할 수 있게 되었다

같이 보기

• RFC
• 해시 함수
• 데이터베이스
• 분산 시스템
• API
• 식별자

외부 링크

• RFC 9562 - Universally Unique IDentifiers (UUIDs)
• UUID Generator Online
• New UUID Formats
• UUIDv7 in 33 languages