2026년 UUID v4 vs v7: 비트 레이아웃, 정렬, 인덱스 비용

모든 UUID는 16바이트이며, 필드는 텍스트의 하이픈이 아니라 위치로 정의됩니다. 바이트 6의 상위 니블에는 버전이 들어갑니다. 바이트 8의 상위 두 비트에는 변형이 들어갑니다. 나머지는 모두 버전에 따라 달라집니다. 정규 문자열에서 13번째 16진수 문자가 버전이고, 17번째가 변형입니다.

v4의 경우 버전과 변형을 제외한 122비트가 무작위입니다. v7의 경우 처음 48비트가 빅엔디언 Unix 밀리초 타임스탬프이며, 그래서 v7 값은 원시 바이트로도 생성 순서대로 정렬됩니다. 나머지 74비트는 기본적으로 무작위이지만, RFC 9562는 그중 일부를 밀리초 내 단조성을 위한 카운터로 사용할 수 있도록 허용합니다.

v4 UUID는 6개의 고정 비트를 가진 난수입니다. 바이트 6의 상위 니블은 0100이므로 정규 문자열의 13번째 문자는 항상 4입니다. 바이트 8의 상위 두 비트는 10이므로 17번째 문자는 항상 8, 9, a, b 중 하나입니다. 이것이 유일하게 예측 가능한 문자이며, 나머지 30개의 16진수 숫자는 무작위입니다.

무작위성이 곧 보안 속성입니다. v4 값에는 타임스탬프도, 시퀀스도, 머신 식별자도 없으므로 언제 어디서 생성되었는지 전혀 드러나지 않습니다. 따라서 열거될 수 없어야 하는 공개 식별자에 합리적인 선택이며, 단 암호학적으로 안전한 난수 소스로 생성되어야 합니다. 122비트 공간은 충돌을 무시할 수 있는 수준으로 만듭니다: 10억 개의 값에서 충돌 확률은 대략 2^-63입니다.

v7 UUID는 시간 순서를 따릅니다. 바이트 0부터 5까지는 Unix 에포크 이후 밀리초 수를 빅엔디언으로 담습니다. 바이트 6의 상위 니블은 0111입니다. 바이트 6의 하위 니블과 바이트 7 전체가 rand_a를 이루고, 바이트 8의 상위 두 비트가 변형이며, 나머지 62비트가 rand_b입니다. 즉 74개의 무작위 비트와 검사만으로 읽을 수 있는 타임스탬프입니다.

타임스탬프는 48비트로, 10889년까지 밀리초를 표현하기에 충분하므로 오버플로는 실질적인 문제가 아닙니다. 같은 밀리초에 생성된 두 v7 값은 무작위 또는 카운터 비트에서만 차이가 나며, 시계가 뒤로 가지 않는 한 나중에 생성된 값은 항상 바이트 문자열로 비교했을 때 더 큽니다. 그 정렬이 바로 핵심입니다.

정규 텍스트의 사전순 정렬은 바이트 순서와 일치합니다. 하이픈이 고정된 위치에 있고, 소문자일 때 16진수 숫자가 그 값과 같은 순서로 정렬되기 때문입니다. 텍스트 형식으로 정렬하든 16바이트로 정렬하든 생성 순서를 얻습니다. 이는 조정 없이도 여러 머신에 걸쳐 성립하며, 그래서 v7이 이벤트 로그와 정렬 키의 일부가 되는 식별자에 매력적입니다.

문제는 단일 밀리초 내부입니다. 기본적으로 같은 밀리초에 생성된 두 값은 무작위 비트로 정렬되며, 이는 생성 순서가 아닙니다. RFC 9562는 rand_a 필드 또는 가장 왼쪽의 무작위 비트를, 각 타임스탬프 틱마다 무작위로 시드되는 카운터로 사용하는 방법을 설명합니다. 이 방법을 쓰면 실용적인 목적에서 밀리초 내 단조성이 확보되지만, 무작위성이 약간 줄고 동시 생산자가 신중히 다뤄야 하는 공유 카운터가 생깁니다.

무작위 v4 기본 키는 인덱스의 무작위 위치에 삽입됩니다. B-tree에서는 거의 모든 삽입마다 다른 리프 페이지를 건드리고, 버퍼 풀에서 페이지를 밀어내며, 페이지를 중간에서 분할해 절반만 채워진 상태로 남깁니다. 테이블이 커질수록 인덱스가 커지고 쓰기 증폭이 증가하며 캐시 적중률이 떨어집니다.

v7 키는 오른쪽 끝 근처에 삽입되므로 작업 집합이 작게 유지되고 페이지 분할이 저렴한 끝에서 일어납니다. 대가는 경합입니다: 모든 쓰기 작업이 같은 맨 오른쪽 페이지를 원합니다. 단일 데이터베이스에서는 초당 수백 건의 쓰기라면 보통 문제없지만, 동시성이 매우 높아지면 핫스팟이 되며, 일반적인 완화책은 배치 처리, 연결 수준의 인터리빙, 또는 상위 비트에 약간의 지터를 주는 것입니다.

v7 값은 그것을 가진 누구에게나 대략 언제 생성되었는지를 밀리초 단위로 알려주며, 따라서 그 시점 전후에 얼마나 많은 다른 레코드가 생성되었는지도 알려줍니다. 내부 키와 이벤트 ID에는 괜찮습니다. 가입량, 주문 빈도, 계정 나이를 드러내서는 안 되는 공개 식별자에는 적합하지 않습니다.

정렬과 불투명성이 모두 필요하다면, v7은 내부에 두고 별도의 무작위 공개 ID를 노출하거나, 시스템을 떠나는 모든 것에는 v4를 사용하는 것이 선택지입니다. 어느 버전이든 UUID를 능력 토큰으로 취급하지 마십시오. 둘 다 식별자이지 인가 수단이 아닙니다. v4 ID는 실무적으로 추측 불가능하지만, 그래도 모든 요청에서 접근 제어와 대조해 확인해야 합니다.

저장 크기의 답은 두 버전 모두 16바이트입니다. 정규 텍스트 형식은 36자이며, 그중 32자가 16진수 숫자이고 4자가 하이픈입니다. 텍스트 형식을 저장하면 크기가 두 배가 되고 비교가 느려지므로, 네이티브 UUID 타입이 있으면 그것을, 없으면 BINARY(16)을 사용하고 경계에서만 형식을 지정하십시오.

SQL Server에는 테스트해 볼 만한 특이점이 있습니다: uniqueidentifier 타입은 정규 문자열과 다른 바이트 순서로 정렬되며, 내부 바이트 순서가 RFC 4122와 다릅니다. v7 정렬에 의존하는 코드는 해당 플랫폼에서 정렬 동작을 가정하지 말고 검증해야 합니다. 컴팩트한 텍스트 형식이 필요하다면 패딩 없는 base64url이 22자를 제공하지만, 표준 UUID 표현이 아니므로 정규 형식을 기대하는 도구를 혼란스럽게 합니다.

식별자가 데이터베이스 키이거나, 별도 컬럼 없이 생성 시간으로 정렬하고 싶거나, 추가 위주 테이블을 만들 때는 v7을 선택하십시오. 값이 공개적으로 노출되거나, 생성 시간이 민감하거나, 시스템이 이미 타임스탬프 컬럼을 저장해 정렬에서 얻을 것이 없을 때는 v4를 선택하십시오. 둘 다 서로 다른 제약에 대한 올바른 선택이며, 한 테이블에서 둘을 섞는 것은 보통 실수입니다.

테스트는 값이 아니라 구조를 검증해야 합니다. 파싱 후 버전 니블, 변형 니블, 바이트 길이를 확인하십시오. v7의 경우 내장 타임스탬프가 테스트 윈도 내에 있는지, 순서대로 생성된 두 값이 올바르게 비교되는지 검증하십시오. 테스트에 리터럴 UUID를 스냅샷으로 저장하지 말고, 생성기가 카운터를 쓰지 않는 한 v7이 이전 값보다 엄격히 크다고 단정하지 마십시오. 카운터가 없으면 같은 밀리초 내 순서는 무작위입니다.