UUID v1 대 v4 대 v5: 어떤 버전을 사용해야 합니까?
빠른 답변
기본적으로 UUID v4(임의)를 사용합니다. 조정이 필요하지 않으며 충돌 위험도 미미합니다. v1(시간 기반)은 시간 순서에 따른 ID가 필요하고 노드 ID를 확보할 수 있는 경우에만 사용하세요. 이름에서 파생된 결정적 ID가 필요한 경우 v5(네임스페이스+이름)를 사용하세요. 무료 UUID 생성기를 사용하여 모든 버전을 생성하세요.
소개
UUID(범용 고유 식별자)는 8-4-4-4-12 16진수 그룹의 36자로 렌더링된 128비트 식별자입니다. 123e4567-e89b-12d3-a456-426614174000. RFC 9562는 여러 버전을 정의합니다. 가장 많이 접하게 될 세 가지는 v1(시간 + MAC), v4(임의) 및 v5(네임스페이스 + 이름, SHA-1)입니다. 각각은 고유성 보장, 정렬 가능성 및 결정성 사이에서 서로 다른 균형을 유지합니다.
단계별
-
UUID v1 —시간 및 노드 기반
v1은 현재 60비트 타임스탬프(1582-10-15 이후 100ns 간격)와 48비트 노드 ID(일반적으로 MAC 주소)를 인코딩합니다. 동일한 노드에서 생성된 ID는 단조 증가하며 시간 정렬이 가능합니다. 위험: MAC 주소로 인해 하드웨어 ID가 유출되고 노드 간 시계 오차로 인해 순서가 깨질 수 있습니다.
-
UUID v4 —무작위
v4는 122개의 임의 비트를 사용합니다(버전/변형의 경우 6비트가 고정됨). 122개의 임의 비트를 사용하면 2조 7100억 개의 ID 간의 충돌 확률은 50%입니다. 즉, 현실적인 작업 부하의 경우 확률은 사실상 0입니다. v4는 조정이 필요하지 않으며 호스트 정보를 공개하지 않으므로 가장 안전한 기본값입니다.
-
UUID v5 —네임스페이스 및 이름(SHA-1)
v5는 SHA-1로 네임스페이스 UUID 및 이름 문자열을 해시하여 결정적 128비트 ID를 생성합니다. 동일한(네임스페이스, 이름) 쌍은 항상 동일한 UUID을 생성합니다. 이는 자연 키에서 파생된 중복 제거 및 안정적인 ID에 이상적입니다. v3도 같은 아이디어이지만 MD5을 사용합니다(피하세요).
-
장단점 비교
v1은 정렬 가능하지만 MAC이 누출되고 시계 동기화가 필요합니다. v4는 무작위이고 비공개이지만 정렬할 수 없습니다. v5는 결정적이며 중복을 제거하지만 무작위가 아닙니다. 이름을 추측하면 공격자가 UUID을 재현할 수 있습니다. 순서, 무작위성 또는 결정성이 필요한지 여부에 따라 선택하세요.
-
귀하의 케이스에 적합한 버전을 선택하세요
데이터베이스 기본 키: v4(또는 시간 주문 가능성을 위해 최신 시스템에서는 v7). 조정이 없는 분산 시스템: v4. 자연 키의 결정적 ID(예: URL →UUID): v5. 시간 순서의 이점을 활용하는 감사 로그: 보안된 임의 노드 ID가 있는 v1.
예
UUID v1(시간 기반, 정렬 가능)
입력: 노드 00:11:22:33:44:55에서 2026-08-28T12:00:00Z에 생성됨
산출: 1ef7c1d0-2d3b-11f0-8000-001122334455(버전 숫자 '1', 시간 정렬 가능)
UUID v4(임의)
입력: Random generation
산출: f47ac10b-58cc-4372-a567-0e02b2c3d479(버전 숫자 '4', 임의 비트)
UUID v5(네임스페이스+이름으로 결정적)
입력: 네임스페이스 DNS (6ba7b810-9dad-11d1-80b4-00c04fd430c8) + 이름 'freeonlinetoolsgo.com'
산출: 74738ff5-5367-5958-9aeb-0c1f1f1f1f1f (동일한 입력은 항상 동일한 출력을 생성합니다)
일반적인 문제
- 기본 16바이트 BINARY/UUID 유형 대신 UUID를 VARCHAR(36)으로 저장: 이는 2배의 저장 공간을 낭비하고 인덱스 성능을 저하시킵니다. 가능한 경우 기본 UUID 열 유형을 사용하세요.
- 노드 ID를 보호하지 않고 v1 사용: 기본 MAC 주소는 하드웨어 ID를 유출하며 개인 정보 보호 문제가 됩니다. 이를 노드당 암호화된 임의의 48비트 값으로 바꿉니다.
- v4 충돌이 불가능하다고 가정하면 그렇지 않습니다. 천문학적으로 가능성이 낮습니다. 122개의 랜덤 비트를 사용하면 50%의 확률을 얻으려면 ~2조 7100억 개의 ID가 필요합니다. 10억 개의 ID에 대해 확률은 ~0.0000000000000001입니다.
- v5(SHA-1 기반) 대신 v3(MD5 기반) 사용: MD5이 손상되었으므로 v5가 선호됩니다. 둘 다 결정적이지만 v5는 충돌 저항이 더 강력합니다.
팁
- 거의 모든 사용 사례에 대해 기본값은 v4입니다. 이는 조정 없이 임의적이고 비공개이며 충돌로부터 안전합니다.
- 시간 정렬 가능한 임의 ID가 필요한 경우 Unix 타임스탬프와 임의 비트를 결합한 UUID v7(RFC 9562, 2024)을 살펴보세요. 최신 데이터베이스의 경우 v1보다 좋습니다.
- v5를 사용하여 자연 키(URLs, 이메일 주소)에서 안정적인 ID를 생성하면 동일한 입력이 항상 동일한 UUID에 매핑되므로 중복 제거 및 멱등성 APIs에 유용합니다.
- 서버 왕복을 피하기 위해 가능한 경우 클라이언트에서 UUID를 생성합니다. UUID 생성기는 crypto.getRandomValues()를 사용하여 브라우저에서 완전히 실행됩니다.