식별자 표준의 변화는 데이터베이스 설계와 분산 시스템 운영에 직접적인 영향을 줍니다. 최신 UUID 규격인 RFC 9562가 2024년 5월에 정식 발표되면서 기존 RFC 4122를 대체하게 되었고, v6, v7, v8 같은 새로운 버전이 정식 표준에 편입되었습니다. 이 글에서는 새롭게 정리된 UUID 명세와 각 버전별 특징, 그리고 현업에서 가장 많이 도입되고 있는 UUIDv7을 어떻게 활용할 수 있는지 정리해 드립니다.
RFC 9562로 정리된 UUID 표준의 변화
2024년 5월, IETF는 기존 RFC 4122를 대체하는 RFC 9562를 정식 발표했습니다. 약 20년 가까이 유지되어 온 UUID 명세가 현대적인 분산 환경에 맞게 재정비된 것이 핵심입니다. 새로운 명세에서는 시간 기반 정렬을 강화한 버전과 사용자 정의 영역을 허용하는 버전이 함께 추가되었습니다.
가장 큰 변화는 시간 기반 UUID의 정렬 효율을 끌어올렸다는 점입니다. 기존 v1이 노드 MAC 주소를 포함해 개인정보 유출 우려가 있었다면, v6는 같은 구조를 정렬 가능하도록 재배열했고, v7은 Unix 타임스탬프를 사용해 인덱스 성능을 크게 개선했습니다.
UUID 버전별 특징과 차이점 비교
현재 통용되는 UUID 버전은 총 일곱 가지입니다. 각 버전이 어떤 상황에서 적합한지 한눈에 비교해 보시면 도움이 됩니다.
| 버전 | 생성 방식 | 정렬 가능 | 주요 용도 |
|---|---|---|---|
| v1 | 타임스탬프 + MAC | 부분적 | 레거시 시스템 |
| v3 | MD5 해시 | 불가 | 이름 기반 식별 |
| v4 | 완전 랜덤 | 불가 | 범용 식별자 |
| v5 | SHA-1 해시 | 불가 | 네임스페이스 기반 |
| v6 | 재배열된 타임스탬프 | 가능 | v1 마이그레이션 |
| v7 | Unix epoch + 랜덤 | 가능 | DB 기본키, 분산 ID |
| v8 | 사용자 정의 | 구현에 따라 | 특수 목적 |
v4는 여전히 가장 널리 쓰이지만, 데이터베이스 기본키로 사용할 때 인덱스 단편화 문제가 자주 발생합니다. 반면 v7은 시간 순서대로 생성되기 때문에 B-Tree 인덱스 친화적이라는 평가를 받고 있습니다.
UUIDv7이 빠르게 확산되는 이유
UUIDv7은 상위 48비트에 밀리초 단위 Unix 타임스탬프를 담고, 나머지 영역을 랜덤 값으로 채웁니다. 이 구조 덕분에 생성 순서가 곧 정렬 순서가 되며, 시간 정보를 추출하기도 수월합니다.
- 시간순 정렬: 별도 created_at 컬럼 없이도 ID만으로 생성 시점을 파악할 수 있습니다.
- 인덱스 효율: B-Tree 인덱스에 순차 삽입되므로 페이지 분할이 줄어듭니다.
- 분산 환경 적합: 단일 시퀀스가 필요 없어 샤드 간 충돌 없이 생성 가능합니다.
- 호환성 유지: 기존 UUID 컬럼(16바이트)을 그대로 사용할 수 있어 마이그레이션이 쉽습니다.
PostgreSQL 18 이상에서는 uuidv7() 함수를 내장 지원하기 시작했고, MySQL 8과 SQL Server에서도 함수 또는 확장으로 사용할 수 있습니다. 직접 ID를 만들어 테스트해 보고 싶다면 UUID 생성기를 통해 v4와 v7을 나란히 비교해 보면 두 버전의 구조 차이를 직관적으로 확인할 수 있습니다.
데이터베이스에서 UUIDv7 도입 시 고려사항
UUIDv7을 기본키로 도입할 때는 저장 방식과 정렬 특성을 함께 고려해야 합니다. 단순히 문자열로 저장하면 36바이트가 필요하지만, 바이너리(16바이트)로 저장하면 공간을 절반 이상 줄일 수 있습니다.
- 컬럼 타입을 UUID 또는 BINARY(16)으로 지정해 저장 공간을 최소화합니다.
- 기본키와 클러스터 인덱스를 함께 설정해 시간순 삽입 이점을 살립니다.
- 로그 테이블이나 이벤트 테이블처럼 시계열 데이터에 우선 적용해 봅니다.
- 기존 v4 키를 한 번에 교체하기보다, 신규 테이블부터 점진적으로 적용합니다.
상황별 UUID 버전 선택 가이드
모든 시스템이 v7로 옮겨 갈 필요는 없습니다. 사용 목적에 따라 다음 기준으로 판단해 보시면 좋습니다.
- 외부 공개 식별자: v4 권장 (예측 불가능성 우선)
- DB 기본키, 로그 ID: v7 권장 (정렬 성능 우선)
- 이름 기반 결정적 ID: v5 권장 (해시 일관성 필요)
- 레거시 호환: v1 또는 v6 (기존 시스템 유지)
- 특수 포맷이 필요한 사내 ID: v8 (커스텀 비트 배치)
특히 새 프로젝트를 시작한다면 처음부터 v7을 채택하는 것을 권장드립니다. 라이브러리 지원도 충분히 성숙해졌고, 운영 환경에서의 성능 이점이 명확하기 때문입니다. 마이그레이션을 계획 중이라면 신규 테이블부터 적용해 보면서 안정성을 검증하는 단계적 접근이 안전합니다.