UUID v4 vs v7 가이드

버전 4비트와 variant 2비트를 뺀 122비트가 난수입니다. 그래서 같은 값이 두 번 나올 확률을 걱정할 필요가 없고, 값을 보고 언제 만들어졌는지 알 수 없습니다. 문자열 14번째 자리가 항상 4인 것이 버전 표시입니다.

Unix epoch 밀리초가 그대로 앞에 오고, 버전 4비트(0111, 즉 문자열 14번째 자리가 7), variant 2비트, 나머지 74비트가 난수입니다. 앞부분이 시간이라 문자열을 그냥 사전순으로 정렬하면 생성 순서대로 정렬됩니다. 이게 v7의 전부입니다.

01a013ab-09ca-7958-88e4-7f9866134ad6와 01a013ab-09d0-7ec6-ac2e-079d51b83123는 같은 밀리초대에 연속 생성된 v7 두 개입니다. 앞 8자리가 같고 그다음이 조금 늘어난 것이 보입니다. v4를 두 번 뽑으면 앞부터 전혀 다릅니다.

타임스탬프가 같으므로 남은 74비트 난수로 갈립니다. 같은 밀리초 안에서의 순서는 보장되지 않습니다. "완전한 단조 증가"가 필요하면 RFC가 허용하는 카운터 방식을 쓰는 구현을 골라야 하고, 대부분의 애플리케이션에는 밀리초 단위 정렬로 충분합니다.

앞 48비트가 밀리초 타임스탬프이므로 누구든 v7 값에서 생성 시각을 밀리초 단위로 복원할 수 있습니다. 사용자 ID가 v7이고 그것이 공개 프로필 URL에 들어간다면, 그 사람의 가입 시각이 공개되는 것입니다. 주문 ID라면 주문 시각이, 문서 ID라면 작성 시각이 노출됩니다.

v7 값 두 개를 비교하면 어느 것이 먼저 만들어졌는지 알 수 있습니다. 경쟁사가 자사 서비스에 가입해 받은 ID와 다른 ID를 비교해 그 사이에 몇 건이 생성됐는지 추정하는 것도 가능합니다. 난수 74비트가 있어 정확한 카운트는 아니지만 시각 범위는 확실히 드러납니다.

실무에서 흔한 절충은 내부용과 외부용을 분리하는 것입니다. 데이터베이스 기본키는 v7로 두어 인덱스 이득을 챘고, 외부에 노출되는 URL에는 별도의 v4나 짧은 슬러그를 씁니다. 컬럼 하나가 늘지만 정렬 이득과 비노출을 동시에 가질 수 있습니다.

시각이 노출되지 않는다는 점에서는 안전합니다. 다만 v4도 비밀은 아닙니다. 추측하기 어려울 뿐이므로 접근 제어를 대신할 수 없습니다. "URL을 아는 사람만 볼 수 있다"는 설계는 UUID 버전과 무관하게 취약합니다.

이미 저장된 v4 값을 v7로 바꿀 방법은 없습니다. 그 값에는 생성 시각 정보가 애초에 없습니다. 그래서 전환은 항상 "지금부터 새로 만드는 것만 v7"이 되고, 테이블에는 두 버전이 섞여 남습니다.

"기본키로 정렬하면 시간순"이라는 가정으로 쿼리나 페이지네이션을 짜면, v4 시절 행들이 무작위 위치에 끼어 있어 결과가 이상해집니다. 전환 시점을 기록해 두고 그 이전 데이터는 별도의 created_at 컬럼으로 정렬하는 편이 안전합니다. 애초에 시간 정렬이 필요하면 인덱스된 타임스탬프 컬럼을 두는 것이 UUID 버전에 의존하는 것보다 명시적입니다.

v7은 비교적 최근 표준이라 언어와 라이브러리 버전에 따라 지원이 갈립니다. 데이터베이스 드라이버, ORM, 그리고 값을 검증하는 스키마(예: JSON Schema의 format: uuid) 모두가 버전 7을 받아들이는지 봐야 합니다. 브라우저 crypto.randomUUID()는 v4만 만듭니다.

요청 추적 ID, 멱등성 키, 파일명 등에도 UUID가 쓰입니다. 이 자리에서는 정렬이 이득이 아니고 오히려 시각 노출만 생기는 경우가 많습니다. "전부 v7로 통일"보다 자리별로 판단하는 편이 낫습니다.