범용 고유 식별자: 두 판 사이의 차이

Gaon12 (토론 / 기여)
버전 6, 7, 8 내용 보강
Gaon12 (토론 / 기여)
문서 개선
 
(같은 사용자의 중간 판 2개는 보이지 않습니다)
1번째 줄: 1번째 줄:
== 개요 ==
== 개요 ==
UUID(Universally Unique Identifier)는 전 세계적으로 고유한 식별자를 만들기 위해 고안된 표준이다. UUID는 128비트 길이의 숫자이며, 주로 소프트웨어 시스템에서 객체, 엔티티 등을 고유하게 식별하기 위해 사용된다. UUID는 [https://datatracker.ietf.org/doc/html/rfc4122 RFC 4122 표준]에 정의되어 있으며, 다양한 버전과 생성 방법이 존재한다.
'''UUID'''(Universally Unique Identifier)는 전 세계적으로 고유한 식별자를 만들기 위해 고안된 '''128비트''' 표준 식별자이다. '''GUID'''(Globally Unique Identifier)라고도 불린다.


UUID는 일반적으로 32자리의 16진수 숫자로 표현되며, 하이픈(-)으로 구분된 5개의 그룹으로 나뉜다. 예를 들어, <code>123e4567-e89b-12d3-a456-426614174000</code>와 같은 형태이다. 이 구조는 <code>8-4-4-4-12</code> 형태로 구성되어 있다.
2024년 5월 7일, RFC 9562가 발표되어 3개의 새로운 "버전"이 도입되고 일부 모호함이 명확해졌다. 2005년의 RFC 4122를 대체하는 최신 규격으로, 새로운 버전 6, 7, 8이 정식 표준에 포함되었다.


또한 최근에는 UUID의 새로운 표준 제안으로써 버전 6, 7, 8 등이 포함된 [https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis 개정판이 논의되고 있으며], 특히 버전 7은 밀리초 단위의 [[Unix 타임스탬프]] 기반으로 정렬이 용이하도록 설계되었다.
UUID는 32자리 16진수 숫자를 <code>8-4-4-4-12</code> 형식으로 하이픈으로 구분하여 표현한다.
<pre>
예시: 123e4567-e89b-12d3-a456-426614174000
</pre>
 
버전 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바이트)로 구성되며, 다음과 같은 필드로 나뉜다:
 
<pre>
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx
</pre>
 
* '''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 (사용자 정의) ===
* '''구성''': 애플리케이션이 자유롭게 정의
* '''용도''': 특수한 요구사항이 있는 커스텀 구현
* '''주의''': 표준 호환성은 보장되지 않음


== 장단점 ==
== 장단점 ==
=== 장점 ===
=== 장점 ===
* '''전 세계적 고유성''': UUID는 분산 시스템에서 중복 없이 고유한 식별자를 생성할 수 있다.
* '''전 세계적 고유성''': 분산 환경에서도 중복 없이 고유한 식별자 생성 가능
* '''충돌 가능성 낮음''': 128비트 길이로 인해 충돌 가능성이 극히 낮다.
* '''충돌 가능성 극히 낮음''': 2<sup>122</sup> (≈5.3 × 10<sup>36</sup>)개의 조합
* '''독립성''': UUID는 생성 시 외부 시스템이나 중앙 서버와의 통신 없이도 고유한 식별자를 만들 수 있다.
* '''독립성''': 중앙 서버 없이도 생성 가능
* '''범용성''': 다양한 프로그래밍 언어와 플랫폼에서 UUID를 지원하며, 표준화된 형식을 가지고 있다.
* '''범용성''': 대부분의 프로그래밍 언어와 플랫폼에서 지원
* '''표준화''': RFC 표준으로 상호 운용성 보장


=== 단점 ===
=== 단점 ===
* '''크기''': UUID는 128비트(16바이트) 길이로, 메모리와 저장 공간을 많이 차지할 수 있다. 특히 대규모 데이터베이스에서 인덱싱 성능에 영향을 미칠 수 있다.
* '''크기''': 16바이트로 대규모 데이터베이스에서는 부담
* '''가독성''': 인간이 읽기에는 길고 복잡하여 식별하기 어렵다.
* '''가독성''': 사람이 읽고 기억하기 어려움
* '''정렬''': 기존 UUID는 생성 시점에 따라 순서가 보장되지 않기 때문에, 삽입 순서대로 정렬하거나 시간순 정렬을 원할 경우 부적합할 수 있다. 그러나 버전 1, 6, 7은 시간 정보를 포함하여 시간순 정렬이 가능하다.
* '''정렬 문제''': 버전 4는 무작위 생성으로 인덱스 파편화 심각
* '''보안''': UUID 버전 1의 경우 MAC 주소와 타임스탬프를 포함하기 때문에 개인 정보가 의도치 않게 노출될 위험이 있다.
* '''보안 이슈''': 버전 1, 6은 MAC 주소 노출 위험
 
== 충돌 확률 ==
UUID의 충돌 확률은 '''천문학적으로 낮다'''.
 
* '''이론적 계산''': 초당 10억 개의 UUID를 100년간 생성해도 50% 충돌 확률에 도달하지 않음
* '''실제 사례''': 지금까지 공개된 UUID 충돌 사례는 '''0건'''
* '''비교''': 로또 1등 당첨(약 10<sup>-8</sup>)보다 10<sup>28</sup>배 더 낮은 확률
 
== 구현 및 채택 현황 ==
=== 데이터베이스 ===
* '''PostgreSQL''': <code>uuid_generate_v7()</code> 함수 제공 (<code>pg_uuidv7</code> 확장)
* '''MySQL''': <code>UUID()</code>, <code>UUID_TO_BIN()</code> 함수 지원
* '''SQLite''': <code>hex(randomblob(16))</code> 형태로 구현
* '''DuckDB''': 1.3.0에서 v7 지원 추가
 
=== 프로그래밍 언어 ===
==== Python ====
RFC 9562를 참조하여 UUID 버전 7과 8 구현에 대한 논의가 Python 커뮤니티에서 활발히 진행되고 있다.
 
<syntaxhighlight lang="python">
import uuid
 
# 버전 4 (가장 일반적)
uuid4 = uuid.uuid4()
 
# 버전 1
uuid1 = uuid.uuid1()
 
# 버전 7은 아직 표준 라이브러리에 없음
# 외부 라이브러리 사용 필요
</syntaxhighlight>
 
==== JavaScript/Node.js ====
<syntaxhighlight lang="javascript">
// crypto 모듈 사용
const { randomUUID } = require('crypto');
const uuid = randomUUID(); // 버전 4
 
// uuid 패키지 사용
const { v4: uuidv4, v7: uuidv7 } = require('uuid');
</syntaxhighlight>
 
==== Java ====
OpenJDK에서 RFC 9562에 정의된 UUID 버전 7(UUIDv7) 지원 추가를 위한 작업이 진행 중이다.


== 특징 ==
<syntaxhighlight lang="java">
UUID는 다음과 같은 특징을 갖는다:
// 표준 라이브러리 (버전 4만 지원)
* 고유성''': 각 UUID는 전 세계적으로 유일하다.
UUID uuid = UUID.randomUUID();
* 확장성''': 네트워크 환경과 무관하게 고유 식별자를 생성할 수 있다.
* '''독립적 생성''': UUID는 독립적으로 생성할 수 있으며, 중앙 서버 없이도 분산 환경에서 사용이 가능하다.
* 표준화''': RFC 4122 표준에 의해 정의되어 있어, 다양한 시스템과 플랫폼에서 일관성 있게 사용할 수 있다.
* 다양한 버전''': 다양한 생성 방법에 따라 여러 버전이 존재하며, 각각의 버전은 고유한 용도와 생성 방법을 갖는다.
* '''지원 라이브러리 풍부''': 대다수의 프로그래밍 언어 및 프레임워크에서 UUID 생성 함수를 기본 혹은 확장 라이브러리로 제공한다.


== UUID의 버전 ==
// 버전 7은 외부 라이브러리 필요
UUID는 전통적으로 다섯 가지 주요 버전이 존재했으며, 최근에는 새로운 버전 6, 7, 8이 제안되었다.
</syntaxhighlight>


=== 버전 1: 타임스탬프 기반 ===
==== .NET/C# ====
UUID 버전 1은 생성 시점의 시간과 공간(주로 MAC 주소)을 기반으로 UUID를 생성한다. 이 방식은 고유성이 보장되지만, 타임스탬프와 MAC 주소를 포함하기 때문에 개인 정보 유출의 가능성이 있다.
.NET의 새로운 버전에서 Guid.CreateVersion7() 기능이 추가되었으며, 이를 .NET Framework에 백포트하는 노력이 있다.


=== 버전 2: DCE 보안 ===
<syntaxhighlight lang="csharp">
UUID 버전 2는 DCE(Security Domain)의 보안 목적으로 사용된다. 버전 1과 유사하게 시간과 공간 기반으로 생성되지만, 추가적으로 POSIX UID/GID 정보를 포함한다. 실무에서는 거의 사용되지 않는다.
// .NET 9.0 이상
var guid = Guid.CreateVersion7();


=== 버전 3: 이름 기반(MD5 해시) ===
// 이전 버전에서는 외부 구현 필요
UUID 버전 3은 이름(Name)과 네임스페이스를 기반으로 MD5 해시를 사용해 UUID를 생성한다. 동일한 입력값에 대해 동일한 UUID를 보장한다.
</syntaxhighlight>


=== 버전 4: 난수 기반 ===
==== Go ====
UUID 버전 4는 난수를 기반으로 생성되며, 가장 일반적으로 사용된다. 난수 기반이므로 충돌 가능성이 매우 낮다.
<syntaxhighlight lang="go">
// google/uuid 패키지
import "github.com/google/uuid"


=== 버전 5: 이름 기반(SHA-1 해시) ===
// 버전 4
UUID 버전 5는 SHA-1 해시를 사용하며, 버전 3과 동일한 방식이지만 해시 알고리즘이 다르다.
uuid := uuid.New()


=== (제안) 버전 6, 7, 8 ===
// 버전 7 (일부 라이브러리에서 지원)
RFC 4122bis 문서에서 새롭게 제안된 UUID 버전 6, 7, 8은 다음과 같다:
</syntaxhighlight>


* 버전 6: 기존 UUID 버전 1을 개선하여 시간순 정렬성을 강화.
=== 다중 언어 구현 ===
* 버전 7: 밀리초 단위의 Unix 타임스탬프를 기반으로 정렬이 용이하게 설계.
JavaScript에서 Zig까지, 제3자 종속성 없이 33개 언어로 구현된 UUIDv7이 있다.
* 버전 8: 새로운 사용자 정의 UUID 생성 방식을 포함.


== 충돌 확률 ==
=== 주요 서비스 채택 ===
UUID 버전 4의 충돌 확률은 극히 낮으며, <math>2^{122}</math> (약 <math>5.3 \times 10^{36}</math>)개의 가능한 UUID가 존재한다. 예를 들어, 초당 10억 개의 UUID를 100년 동안 생성해도 50% 충돌 확률에 도달하지 않는다.
* '''GitHub''': API 리소스 식별자
* '''Discord''': 스노우플레이크 ID (UUID 유사 구조)
* '''MongoDB''': ObjectId (UUID와 유사한 12바이트 식별자)
* '''AWS''': 다양한 리소스 식별자
* '''Microsoft''': COM, .NET GUID
 
== 성능 고려사항 ==
=== 데이터베이스 인덱스 ===
{| class="wikitable"
! 버전 !! 인덱스 성능 !! 비고
|-
| 버전 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, 토큰
* 파일명, 임시 디렉토리명
 
'''사용하지 않는 것이 좋은 경우'''
* 순차적 번호가 필요한 경우 (주문번호 등)
* 사용자가 직접 입력해야 하는 경우
* 메모리/저장공간이 매우 제한적인 환경
* 초고성능이 필요한 정수 연산
 
=== 버전 선택 가이드 ===
{| class="wikitable"
! 용도 !! 권장 버전 !! 이유
|-
| 일반적인 식별자 || '''v4''' || 간단하고 안전
|-
| 데이터베이스 PK || '''v7''' || 인덱스 성능 우수
|-
| 시간 순서 중요 || '''v7''' || 밀리초 단위 정렬
|-
| 결정적 생성 || '''v5''' || 같은 입력 → 같은 결과
|-
| 레거시 호환 || '''v1''' || 기존 시스템과의 호환성
|}
 
== 최신 동향 및 발전 방향 ==
=== RFC 9562의 주요 변화 ===
* '''새로운 버전 추가''': 버전 6, 7, 8의 정식 표준화
* '''명확화''': 기존 사양의 모호한 부분들 정리
* '''현대적 요구사항 반영''': 대용량 데이터베이스와 분산 시스템에 최적화
 
=== 업계 채택 동향 ===
* '''데이터베이스 엔진''': PostgreSQL, DuckDB 등에서 버전 7 지원 추가
* '''프로그래밍 언어''': .NET 9.0에서 네이티브 지원, Java OpenJDK에서 구현 검토 중
* '''라이브러리 생태계''': 다양한 언어에서 제3자 라이브러리 형태로 빠른 채택
 
== 트리비아 ==
* UUID의 '''nil UUID'''는 모든 비트가 0인 <code>00000000-0000-0000-0000-000000000000</code>이다
* 브라켓 표기법도 존재한다: <code>{123e4567-e89b-12d3-a456-426614174000}</code>
* Microsoft는 UUID를 '''GUID'''(Globally Unique Identifier)라고 부른다
* PostgreSQL에서 UUID는 native 타입으로 지원되어 저장 공간을 절약할 수 있다
* 버전 7의 등장으로 '''Twitter의 Snowflake ID'''와 유사한 기능을 표준으로 사용할 수 있게 되었다
 
== 같이 보기 ==
* [[RFC]]
* [[해시 함수]]
* [[데이터베이스]]
* [[분산 시스템]]
* [[API]]
* [[식별자]]
 
== 각주 ==
<references />


== 결론 ==
== 외부 링크 ==
UUID는 전 세계적으로 고유한 식별자를 생성하기 위한 표준으로, 다양한 시스템과 환경에서 널리 사용된다. 각 버전은 고유한 생성 방법과 용도를 가지며, 특정 상황에 맞는 UUID 버전을 선택하여 사용할 수 있다. 최신 표준에서 제안된 UUID 버전 6, 7, 8은 정렬성과 활용성을 강화하여 향후 더욱 널리 사용될 것으로 기대된다.
* [https://datatracker.ietf.org/doc/html/rfc9562 RFC 9562 - Universally Unique IDentifiers (UUIDs)]
* [https://www.uuidgenerator.net/ UUID Generator Online]
* [https://uuid6.github.io/uuid6-ietf-draft/ New UUID Formats]
* [https://antonz.org/uuidv7/ UUIDv7 in 33 languages]


<!-- 분류 -->
[[분류:식별자]]
[[분류:컴퓨터 과학]] [[분류:소프트웨어 개발]] [[분류:식별자]] [[분류:데이터베이스]] [[분류:네트워크]] [[분류:확률]]
[[분류:컴퓨터 과학]]
[[분류:데이터베이스]]
[[분류:인터넷 표준]]

2025년 6월 8일 (일) 21:20 기준 최신판

개요[편집 / 원본 편집]

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 (사용자 정의)[편집 / 원본 편집]

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

장단점[편집 / 원본 편집]

장점[편집 / 원본 편집]

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

단점[편집 / 원본 편집]

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

충돌 확률[편집 / 원본 편집]

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

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

구현 및 채택 현황[편집 / 원본 편집]

데이터베이스[편집 / 원본 편집]

  • 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와 유사한 기능을 표준으로 사용할 수 있게 되었다

같이 보기[편집 / 원본 편집]

각주[편집 / 원본 편집]


외부 링크[편집 / 원본 편집]