UUID v7 생성

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

마지막 업데이트: 2026-09-06

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란

UUID v7이란 2024년 5월에 IETF의 RFC 9562로 표준화된, 시각순으로 정렬할 수 있는 새로운 UUID(Universally Unique Identifier)입니다. 그동안 널리 쓰여 온 UUID v4는 128비트 전부가 완전 무작위 값이라 생성 순서를 알 실마리가 없지만, UUID v7은 앞 48비트에 밀리초 단위의 유닉스 타임스탬프를 지니므로 문자열로 정렬하기만 해도 생성된 순서대로 늘어섭니다. 나머지 비트는 난수로 채워져 있어, 같은 밀리초 안에 생성해도 유일성은 지켜집니다.

이 도구는 Web Crypto API를 사용해 브라우저 안에서 UUID v7을 생성하고, 표준·대문자·하이픈 없음·중괄호·URN 가운데 원하시는 형식으로 한꺼번에 출력합니다. 표기는 기존 UUID v4용 데이터베이스 열과 완전히 호환되므로, 자료형을 바꾸지 않고 그대로 저장하실 수 있는 점이 특징입니다. 생성한 값이 타임스탬프순으로 늘어서는지 확인하고 싶으시면 자매 도구인 UUID v7 디코드 도구로 안에 들어 있는 시각을 꺼내 확인하실 수 있습니다.

UUID v7 생성 절차

생성 건수를 지정합니다 한 번에 필요한 UUID v7의 개수를 ‘생성 건수’에 입력합니다. 테스트 데이터를 한꺼번에 만들고 싶으시면 여러 건을 지정하실 수 있습니다.
표시 형식을 고릅니다 저장할 데이터베이스나 시스템의 사양에 맞추어 표준·대문자·하이픈 없음·중괄호·URN 가운데 고릅니다.
‘생성하기’ 버튼을 누릅니다 브라우저 안의 Web Crypto API로 곧바로 생성되어 결과란에 목록으로 표시됩니다. 서버로 전송되는 일은 없습니다.
결과를 복사합니다 1건씩은 ‘복사’ 버튼으로, 한꺼번에 쓰실 때는 ‘전체 복사’ 버튼으로 클립보드에 담으실 수 있습니다.

더 잘 활용하기 위한 팁

생성한 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 v7이 도움이 되는 상황

데이터베이스의 기본 키 설계

UUID v4보다 삽입 위치가 시계열 순이 되기 쉬우므로, B-tree 인덱스의 단편화를 억제하면서 기존 UUID 열을 그대로 계속 쓰실 수 있습니다.

분산 시스템에서의 ID 채번

여러 서버·마이크로서비스가 중앙의 시퀀스 발행자에 기대지 않고, 저마다 독립적으로 유일하면서 시각순인 ID를 생성할 수 있습니다.

로그·이벤트의 식별자

접근 로그나 이벤트 이력의 ID에 UUID v7을 쓰면 ID의 대소만으로 대략의 발생 순서를 파악할 수 있어, 별도의 타임스탬프 열을 따로 두지 않아도 됩니다.

테스트 데이터·더미 레코드의 일괄 작성

개발·검증 환경에 대량의 더미 레코드를 넣을 때, 여러 건을 한꺼번에 생성해 복사하면 SQL의 INSERT 문이나 API의 테스트 페이로드에 그대로 쓰실 수 있습니다.

생성 결과의 내용을 확인하고 싶을 때

생성한 UUID v7에 정말 올바른 타임스탬프가 들어 있는지 확인하고 싶으시면 UUID v7 디코드 도구로, 무작위 생성의 UUID v4가 필요하시면 UUID 생성 도구로 대응하실 수 있습니다.

UUID v7의 관련 용어

UUID v7: RFC 9562에서 표준화된, 앞 48비트에 밀리초 단위의 유닉스 타임스탬프를 지니는 UUID의 버전입니다. 시각순으로 정렬할 수 있으면서도 기존 UUID 열과의 호환성을 지키고 있습니다.
타임스탬프순 정렬 가능 ID: 값 자체에 생성 시각의 정보를 담고 있어, 문자열이나 숫자로 정렬하기만 하면 발생 순으로 늘어서는 식별자를 말합니다. UUID v7·ULID·Snowflake ID 등이 여기에 해당합니다.
UUID v4와의 차이: UUID v4는 128비트 전부가 완전 무작위여서 생성 순서의 정보를 지니지 않는 데 비해, UUID v7은 앞 48비트가 타임스탬프이므로 생성 순서를 알 수 있습니다. 표기 형식(36자·16진수) 자체는 둘이 같습니다.
단조성(monotonicity): 값이 생성 순으로 단조 증가하는 성질을 말합니다. UUID v7은 같은 밀리초 안에 여럿 생성한 경우 구현에 따라서는 랜덤 부분의 대소만이 순서를 좌우하므로, 엄밀한 단조성은 사양상의 필수 요건이 아니라 구현에 달려 있습니다.
인덱스 지역성: 데이터베이스의 B-tree 인덱스에서 새로 삽입되는 값이 기존 데이터의 가까이(대개는 끝)에 모이는 성질입니다. UUID v7은 타임스탬프순으로 값이 늘어서므로 지역성이 높아, 완전 무작위인 UUID v4보다 삽입 시의 페이지 분할이나 캐시 효율이 나아지기 쉽습니다.
RFC 9562: 2024년 5월에 IETF가 공개한, UUID의 사양을 정하는 표준 문서입니다. 기존의 RFC 4122를 대체하고, 시각순 정렬이 가능한 v6·v7과 사용자 정의 필드를 다룰 수 있는 v8을 새로 추가했습니다.

자주 묻는 질문

가장 큰 차이는 생성 시각순으로 정렬 가능한지 여부입니다. 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와 함께 빠르게 채택되고 있는 이유입니다.

모든 여담 보기