개발자 도구 · UUID 생성기
RFC 4122 대 RFC 9562: 2024 UUID 표준에서 변경된 사항
· 배경
uuid 암호화 브라우저 API
UUID에 대해 두 개의 RFC가 인용되어 있지만 완전히 동일한 내용은 아닙니다. 이 게시물은 RFC 4122과 관련하여 RFC 9562에 추가, 명확화 및 더 이상 사용되지 않는 사항을 안내합니다.
어떤 RFC를 인용해야 합니까? — 문서와 라이브러리가 서로 다른 표준을 참조할 때 발생하는 혼란
두 개의 RFC가 UUID 문서에서 일상적으로 인용되며 동일한 내용을 나타내지 않습니다. 2005에 게시된 RFC 4122은 UUID와 해당 5개 버전(v1~v5)을 정의했습니다. 2024에 게시된 RFC 9562은 RFC 4122를 완전히 폐기하고 실무자가 해결한 모호성을 명확히 하며 세 가지 새 버전(v6, v7, v8)을 추가하고 무작위성 구현에 대한 지침을 업데이트합니다. 라이브러리가 RFC 4122을 인용하는 것은 잘못된 것이 아닙니다. 즉, RFC 9562이 게시되기 전에 라이브러리가 릴리스되었거나 관리자가 문서를 업데이트하지 않았을 수 있습니다. RFC 인용을 확인하면 라이브러리가 마지막으로 크게 업데이트된 시기를 알 수 있습니다. 새로운 사양을 작성하거나 구현을 평가할 때 RFC 9562가 표준 참조입니다.
형식을 대체하지 않고 폐기합니다. RFC 4122에 따라 유효한 모든 항목은 여전히 유효합니다. 레이아웃 및 변형 비트는 변경되지 않습니다.
RFC 9562는 익숙한 128 비트 표현, 16진수 그룹, 버전 위치 및 주요 변형 레이아웃을 유지하면서 현재 참조 문서인 RFC 4122을 공식적으로 폐기합니다. 새로운 RFC가 존재한다는 이유만으로 기존에 저장된 UUID 문자열을 재발급할 필요는 없습니다. 실제 마이그레이션은 문서, 생성기 및 유효성 검사 정책에 있습니다. 현재 표준을 인용하고, 추가된 버전을 이해하고, 이전 코드가 개정판에서 명확해진 모호성에 의존했는지 확인합니다. 호환성은 여전히 시스템 경계에서 테스트되어야 하며, 특히 라이브러리가 Microsoft GUID 구조를 직렬화하거나 표준에서 설명하는 것보다 더 좁은 버전 집합을 적용하는 경우 더욱 그렇습니다.
세 가지 새로운 버전 — v6(시간 순서 변경), v7(Unix 시대 시간 순서) 및 v8(구현 정의)
RFC 9562는 표준에 세 가지 새로운 버전을 추가합니다. 버전 6은 v1 타임스탬프 비트를 재정렬하여 더 나은 데이터베이스 성능을 위해 사전순으로 정렬 가능한 식별자를 생성합니다. 버전 7는 48비트 Unix 밀리초 타임스탬프와 임의 비트를 사용하여 v1의 개인 정보 보호 문제 없이 시간 순서대로 생성을 제공합니다. 버전 8는 구현 정의 레이아웃을 위한 탈출구입니다. 이러한 버전 중 어느 것도 v1-v5의 작동 방식이나 의미를 변경하지 않습니다. 2005의 v1 UUID 및 2024의 v7 UUID은 동일한 데이터베이스에 공존할 수 있으며 각각의 버전 비트는 생성 방법을 식별합니다. 세 가지 새로운 버전은 실제로 나타난 공통 패턴을 다룹니다.
Max UUID는 Nil에 합류합니다 — 모두 0인 값과 함께 정의된 모두 F 값
RFC 4122는 예제와 문서에서 Nil UUID(모두 0 비트)를 특수 참조 값으로 문서화했습니다. RFC 9562에는 동일한 Nil 정의가 포함되어 있지만 공식적으로 범위 경계에 대한 Max UUID(모든 비트가 1로 설정됨)을 정의합니다. Nil과 Max는 올바른 버전과 변형 비트가 없기 때문에 4 무작위 UUID 버전이 아닙니다. Max UUID는 데이터베이스 쿼리의 상한 범위 경계로 유용합니다. WHERE uuid_column <= MAX_UUID는 가능한 모든 UUID와 일치합니다. Nil은 nullable UUID 열에서 할당되지 않은 것에 대한 감시자로 유용합니다. RFC 9562는 애플리케이션 데이터에서의 사용을 의무화하지 않고 두 가지를 모두 문서화합니다.
명확한 지침 — 무작위 필드, 밀리초 내의 단조 카운터 및 데이터베이스 지역성을 위해 시간 순서 버전 선호에 대해 CSPRNG를 사용하라는 명시적 조언
RFC 9562의 모범 사례 지침은 충돌 저항성과 추측 불가능성을 구별합니다. 무작위 필드는 애플리케이션의 위협 모델에 적합한 소스와 CSPRNG에 대한 보안에 민감한 불투명 호출을 사용해야 합니다. 시간 기반 생성기는 여러 식별자가 하나의 타임스탬프 틱을 공유하는 경우 별도의 단조성 문제가 있습니다. 표준에서는 각각 상태 및 롤오버 규칙이 있는 카운터 및 추가 타임스탬프 정밀도를 가능한 방법으로 설명합니다. 이름 기반 버전은 진위 증명이 아닌 결정적 식별자로 유지됩니다. 생성 요구 사항과 정보 공개 속성이 다르더라도 하나의 UUID 구문 분석기가 모든 레이아웃을 수용할 수 있기 때문에 이러한 설명이 중요합니다.
ULID의 아이디어가 나타나는 곳 - 커뮤니티 형식이 v7 디자인에 어떤 영향을 미쳤는가
RFC 9562 작성자는 새로운 레이아웃을 개발하는 동안 ULID, Snowflake 및 KSUID를 포함한 여러 기존 정렬 가능한 식별자 체계를 분석했다고 밝혔습니다. 이는 적당한 결론을 뒷받침합니다. 시간 순서에 따라 분산된 식별자에 대한 운영 수요가 개정에 영향을 미쳤습니다. 한 커뮤니티 형식이 7 버전에 정확한 필드 레이아웃을 제공했다는 사실을 증명하지는 않습니다. 아키텍처 작업에는 실질적인 유사성만으로도 충분합니다. 이러한 패밀리는 시간 정보를 앞쪽에 배치하므로 일반 순서로 광범위한 생성 순서를 보존한 다음 인코딩, 조정 및 틱 내 동작이 다를 수 있습니다. 직접적인 조상을 주장하기보다는 생태계 호환성과 문서화된 보증을 기준으로 둘 중 하나를 선택하세요.
여기서 다루지 않는 내용 — 줄별 차이; 이 게시물은 구현자에 대한 실제적인 결과를 따릅니다.
이 포괄적인 게시물은 RFC 4122에 대한 라인별 차이점이 아니라 구현자와 사용자를 위한 RFC 9562의 실제 결과와 구현을 따릅니다. 전체 사양은 표준 기관에서 구할 수 있으며 언어나 플랫폼에서 UUID 처리를 구현하는 데 읽어볼 가치가 있습니다. 텍스트는 개요에서 다룰 수 있는 것 이상의 권위 있는 세부 정보를 제공합니다. 이 게시물에서는 v6이 v1 바이트를 재정렬하는 방법이나 v7이 Unix 밀리초를 인코딩하는 방법에 대한 비트 수준 메커니즘을 설명하지 않습니다. 표준과 구현 가이드 모두 비트 레이아웃, 인코딩 또는 규정 준수 확인과 관련된 구현 질문에 대한 주요 권위 있는 참조 자료로 남아 있습니다.
요약: 인용 및 기본값 업데이트 - ToolAcre 생성기는 두 RFC가 공유하는 CSPRNG 지침을 따릅니다.
새로운 작업의 경우 문서와 사양을 업데이트하여 RFC 9562을 인용하세요. RFC 4122의 모든 UUID은 RFC 9562에 따라 유효합니다. 마이그레이션은 본질적으로 순전히 미래 지향적이고 관리적입니다. 암호화 무작위성에 대한 명확한 지침은 식별자가 프로덕션 시스템의 암호화된 보안 소스에서 나와야 한다는 점을 강화합니다. ToolAcre는 브라우저의 Web Crypto API를 독점적으로 사용하여 두 RFC의 암호화 임의성 지침을 따릅니다. 로그, 데이터베이스 내보내기 또는 API 응답에서 UUID가 발생하면 ToolAcre의 올바른 형식 검사는 RFC 9562에 대한 버전과 변형을 보고합니다. RFC 9562는 이미 안정된 표준을 명확하게 하고 현대화한 것입니다.