UUID v7 생성

RFC 9562로 표준화된, 밀리초 단위 타임스탬프 48비트를 앞에 내장해 생성 순서대로 정렬 가능한 새로운 UUID「UUID v7」을 브라우저에서 대량으로 생성합니다. 표준·대문자·하이픈 없음·중괄호·URN 형식을 모두 지원하며, 기존 UUID 타입 컬럼에 그대로 저장할 수 있습니다.

UUID v7·UUID v4·ULID 비교

형식 길이 생성 순서로 정렬 가능 여부 기존 UUID 타입 컬럼과의 호환성 설명
UUID v7 36자(하이픈 4개 포함) 예(앞 48비트가 밀리초 타임스탬프) 있음(표준 UUID 타입·16진수 표기 그대로) RFC 9562로 표준화. Unix 타임스탬프와 무작위 값으로 구성되어 생성 순서 정렬과 기존 UUID 자산과의 호환성을 동시에 확보한다. 이 도구가 생성하는 형식.
UUID v4 36자(하이픈 4개 포함) 아니오(완전 무작위) 있음(표준 UUID 타입) RFC 9562로 표준화된 완전 무작위 128비트 식별자. 생성 출처 정보를 포함하지 않으며 가장 널리 쓰이는 형식이다.
ULID 26자 예(앞 10자가 타임스탬프) 없음(Base32이므로 별도 컬럼 타입 변환 필요) UUID 표준(RFC 4122/9562)과는 별개인 Crockford Base32 형식 규격. UUID v7보다 짧지만 기존 UUID 타입 컬럼에는 직접 저장할 수 없다.

사용 팁

  • 생성한 UUID v7은 브라우저 내 JavaScript(Web Crypto API)에서 처리되며, toolbase.cc 서버로는 전혀 전송되지 않습니다.
  • UUID v7은 앞 48비트가 밀리초 단위 Unix 타임스탬프이므로, 생성된 순서대로 문자열 정렬만 해도 시간순으로 나열됩니다.
  • 기존에 UUID v4를 저장하던 데이터베이스 컬럼(CHAR(36)이나 PostgreSQL의 uuid 타입 등)에 그대로 저장할 수 있어, 애플리케이션 쪽 타입 변경 없이 마이그레이션할 수 있습니다.
  • "하이픈 없음" 형식은 URL 경로 세그먼트나 파일명으로 쓰기 편리하며, "중괄호 포함" 형식은 Windows COM/레지스트리에서 쓰이는 GUID 표기와 동일합니다.
  • UUID v7과 ULID(Crockford Base32, 26자) 중 무엇을 쓸지 고민된다면, 기존 시스템이 UUID 타입 컬럼을 전제로 한다면 UUID v7을, 짧은 문자열을 우선한다면 ULID를 선택하면 좋습니다.

자주 묻는 질문

가장 큰 차이는 생성 시각순으로 정렬 가능한지 여부입니다. UUID v4는 완전히 무작위인 128비트 값이라 생성 순서로 정렬할 수 없지만, UUID v7은 앞 48비트가 밀리초 단위 Unix 타임스탬프이므로 문자열 비교만으로 생성 시각 순서를 알 수 있습니다.

둘 다 생성 시각순 정렬이 가능하다는 점은 같지만 표기 형식이 다릅니다. UUID v7은 기존 UUID 타입 컬럼·라이브러리와의 호환성을 유지한 채 마이그레이션할 수 있는 반면, ULID는 26자의 Crockford Base32라는 더 짧은 독자 형식을 씁니다. 기존 시스템이 UUID 타입을 전제로 한다면 UUID v7을, 신규 시스템에서 글자 수를 줄이고 싶다면 ULID가 적합합니다.

2024년 5월 IETF RFC 9562로 정식 표준화되었습니다. 이를 통해 기존 UUID v1〜v5에 더해, 타임스탬프를 재배치한 v6과 Unix 타임스탬프 방식의 v7이 표준 규격에 새로 추가되었습니다.

예. UUID v4처럼 완전히 무작위인 값은 인덱스 내 삽입 위치가 무작위가 되어 B-tree 인덱스 단편화를 일으키기 쉽지만, UUID v7은 시간순으로 정렬되므로 새 행이 인덱스 끝부분 근처에 추가되기 쉬워 삽입 성능이 향상됩니다. PostgreSQL 18에는 uuidv7() 함수가 표준으로 추가되는 등 주요 데이터베이스의 지원도 확대되고 있습니다.
ツールくん

여담 ― UUID에 「시간」을 되찾아준 UUID v7

UUID v7은 2024년 5월 IETF RFC 9562로 표준화되었습니다. 이는 UUID의 원조 규격인 RFC 4122(2005년) 이후 약 20년 만의 대규모 개정으로, 생성 순서 정렬이 가능한 v6·v7과 사용자 정의 필드를 다룰 수 있는 v8이 새로 추가되었습니다. 그 배경에는 UUID v4의 완전한 무작위성이 데이터베이스 인덱스 효율에 불리하다는, 오랫동안 지적되어 온 과제가 있습니다.

UUID v7의 설계는 본 사이트의 자매 도구인 ULID와 매우 흡사합니다. 둘 다 앞부분에 밀리초 단위 타임스탬프를 두고 나머지를 무작위 값으로 채우는 구조는 공통되지만, 결정적 차이는 표기 형식입니다. ULID는 UUID 표준과는 독립된 규격으로 26자의 Crockford Base32를 채택한 반면, UUID v7은 RFC 4122 이래의 36자·16진수 표기를 그대로 유지합니다. 이 차이 덕분에 UUID v7은 기존 UUID 타입 컬럼·라이브러리·API 사양을 그대로 이어서 쓸 수 있다는 큰 장점을 가집니다.

실제로 UUID v7은 등장한 지 얼마 지나지 않아 주요 데이터베이스·언어 런타임의 지원이 빠르게 확산되었습니다. PostgreSQL은 버전 18부터 uuidv7() 함수를 표준으로 탑재했고, 다른 주요 언어·ORM에서도 v7 생성을 지원하는 라이브러리가 빠르게 늘고 있습니다. "생성 순서로 정렬할 수 있다"는 편의성과 "기존 UUID 자산을 깨뜨리지 않는다"는 보수성을 동시에 만족시킬 수 있다는 점이, UUID v7이 ULID와 함께 빠르게 채택되고 있는 이유입니다.