v1 — 타임스탬프 기반
UUID v1은 현재 시각(100나노초 단위)과 생성 장치의 MAC 주소를 조합하여 만들어집니다. 시간 정보가 포함되어 있으므로 생성 순서에 따른 정렬이 가능하며, 같은 장치에서 동시에 생성되더라도 클럭 시퀀스로 충돌을 방지합니다.
단, MAC 주소가 노출되므로 프라이버시 우려가 있습니다. 대부분의 최신 구현체는 실제 MAC 주소 대신 랜덤 노드 ID를 사용하지만, 외부에 노출하는 식별자로는 v4나 v7을 권장합니다.
UUID를 버전별로 생성하고 검증합니다. v1, v3, v4, v5, v7 지원.
36b27d1c-e307-4b2d-9945-cc7d3153b7c1| 버전 | 기반 | 고유성 보장 | 정렬 가능 | 추천 용도 |
|---|---|---|---|---|
| v1 | 타임스탬프 + MAC 주소 | 시간 + 노드 | O | 로깅, 이벤트 추적 |
| v3 | MD5 해시 | 결정적 (입력 기반) | X | URL·이름 매핑 |
| v4 | 랜덤 | 통계적 (122비트 랜덤) | X | 범용 고유 식별자 |
| v5 | SHA-1 해시 | 결정적 (입력 기반) | X | 네임스페이스 매핑 |
| v7 | 타임스탬프 + 랜덤 | 시간 + 랜덤 | O | DB 기본키, 분산 시스템 |
UUID v1은 현재 시각(100나노초 단위)과 생성 장치의 MAC 주소를 조합하여 만들어집니다. 시간 정보가 포함되어 있으므로 생성 순서에 따른 정렬이 가능하며, 같은 장치에서 동시에 생성되더라도 클럭 시퀀스로 충돌을 방지합니다.
단, MAC 주소가 노출되므로 프라이버시 우려가 있습니다. 대부분의 최신 구현체는 실제 MAC 주소 대신 랜덤 노드 ID를 사용하지만, 외부에 노출하는 식별자로는 v4나 v7을 권장합니다.
UUID v3은 네임스페이스 UUID와 이름 문자열을 결합하여 MD5 해시를 계산합니다. 같은 네임스페이스 + 같은 이름이면 항상 같은 UUID가 생성되는 결정적(deterministic) 방식입니다.
URL, 도메인 이름 등 고정된 입력값을 고유 식별자로 변환할 때 유용합니다. 다만 MD5의 보안 취약성 때문에 새로운 프로젝트에서는 SHA-1 기반의 v5 사용을 권장합니다.
UUID v4는 122비트의 순수 랜덤 데이터로 구성되며, 가장 널리 사용되는 UUID 버전입니다. 암호학적으로 안전한 난수 생성기(CSPRNG)를 사용하므로 충돌 확률이 극히 낮습니다.
시간 정보가 없어 정렬이 불가능하고, 데이터베이스 B-Tree 인덱스에서 랜덤 삽입으로 인한 성능 저하가 발생할 수 있습니다. 정렬이 필요 없는 일반적인 고유 식별자로 적합합니다.
UUID v5는 v3과 동일한 결정적 방식이지만 해시 알고리즘으로 SHA-1을 사용합니다. 같은 네임스페이스 + 같은 이름으로 항상 같은 UUID가 생성되며, MD5보다 충돌 저항성이 높습니다.
고정된 입력으로부터 재현 가능한 식별자가 필요할 때 v3보다 v5를 권장합니다.
UUID v7은 2024년 발표된 RFC 9562에서 새롭게 정의된 최신 UUID 버전입니다. 상위 48비트에 Unix 타임스탬프(밀리초)가, 나머지에 랜덤 데이터가 배치됩니다. 타임스탬프가 상위 비트에 있으므로 사전순 정렬 = 시간순 정렬이 됩니다.
v1과 달리 MAC 주소를 사용하지 않아 프라이버시 문제가 없으며, v4처럼 랜덤성을 가지면서도 시간순으로 정렬됩니다. 데이터베이스 기본키로 사용할 경우 B-Tree 인덱스에 순차적으로 삽입되므로 v4 대비 쓰기 성능이 크게 향상됩니다.
새 프로젝트에서 DB 기본키나 정렬이 필요한 식별자로는 v7이 최선의 선택입니다.
정렬이 필요 없다면 v4가 가장 범용적입니다. 대부분의 라이브러리에서 기본값으로 v4를 생성합니다.
시간순 정렬과 인덱스 성능이 중요하다면 v7을 추천합니다. 분산 시스템에서도 안전합니다.
결정적(deterministic) UUID가 필요하다면 v5를 사용하세요. v3도 가능하지만 SHA-1 기반인 v5가 권장됩니다.