UUID v7 생성기: 타임스탬프 기반 정렬 가능한 식별자
UUID v7은 48비트 Unix 밀리초 타임스탬프로 시작하고 이어서 무작위 비트가 붙는 128비트 식별자입니다. 이 페이지는 사용자가 지정한 개수(1~100개)와 표시 옵션(대문자, 하이픈 포함 여부)에 따라 즉시 UUID v7 목록을 생성합니다. 생성된 모든 ID는 시간순으로 정렬되며, 개별 복사 또는 전체 복사가 가능합니다.
UUID v4는 완전 무작위라서 데이터베이스 B-트리 인덱스에서 페이지 분할이 잦아 삽입 성능이 떨어지는 반면, UUID v7은 앞부분에 타임스탬프가 있어 새로 생성된 ID가 인덱스의 끝부분에 모여 삽입됩니다. 이것이 이 도구의 핵심 차별점입니다. 다만 같은 밀리초 내에서 생성된 ID 간에는 엄격한 순서가 보장되지 않습니다.
입력과 출력
입력
- 형식 선택기에서 UUID v7 선택 (현재 페이지 전용)
- 개수: 1 이상 100 이하 정수
- 대문자 토글: UUID를 대문자로 표시 (기본값 소문자)
- 하이�픈 포함 토글: 36자 형식에서 하이픈을 넣거나 뺌 (기본값 포함)
출력
- 생성된 UUID v7 식별자 목록
- ID 개수 표시
- 상태 메시지: "Ready."(대기), "Generated."(생성 완료), "Copied all!"(전체 복사 완료)
- 개별 ID 클릭 시 해당 ID만 클립보드에 복사
옵션을 변경하면 즉시 재생성됩니다. 모든 생성은 브라우저 내에서 이루어지며, 서버로 데이터가 전송되지 않습니다.
UUID v7의 구조와 표준
UUID v7는 RFC 9562(이전에는 RFC 4122의 개정안)에 정의된 형식 중 하나입니다. 128비트는 다음과 같이 구성됩니다:
- 48비트: Unix 에폭 이후의 밀리초 타임스탬프 (상위 32비트 + 하위 16비트)
- 4비트: 버전 식별자 (고정값
0111= 7) - 12비트: 변형 식별자 (고정값
10xx) - 62비트: 암호학적 무작위 비트 (보안 강도)
텍스트 표현은 36자로, xxxxxxxx-xxxx-7xxx-axxx-xxxxxxxxxxxx 형태입니다. 타임스탬프는 처음 32비트(8자) + 다음 16비트(4자) 순서로 들어갑니다. 예를 들어 018f9a3e-7b2c-7000-8000-000000000000에서 첫 12자 018f9a3e7b2c가 타임스탬프를 나타냅니다.
하이픈을 제거하면 32자 문자열이 되지만, 표준 UUID 파서는 하이픈을 무시하므로 저장 시에는 하이픈을 유지하거나 제거해도 동일한 식별자입니다. 대문자/소문자는 표준에서 구분하지 않지만, 데이터베이스에서 문자열 비교 시 대소문자를 구분하는 환경에서는 주의가 필요합니다.
정렬 가능성과 한계
UUID v7의 타임스탬프는 밀리초 단위까지 정렬을 보장합니다. 따라서 생성 시간 순서대로 ID를 나열하면 시간순이 됩니다. 이는 로그, 이벤트 소싱, 감사 추적 등에서 유용합니다.
그러나 같은 밀리초 내에서 생성된 여러 ID는 타임스탬프가 동일하므로 순서가 무작위입니다. 이는 ULID도 동일한 한계를 가집니다. 엄격한 전역 순서가 필요하다면 분산 시퀀서(예: Snowflake ID)나 타임스탬프+카운터 방식이 필요합니다. UUID v7은 동시성과 병렬성을 희생하지 않으면서 시간 기반 정렬을 제공하는 절충안입니다.
또한 타임스탬프가 48비트이므로, Unix 시간 기준으로 약 8,925년(2^48 밀리초)까지 고유하게 표현할 수 있습니다.
실제 사용 사례와 주의사항
- 데이터베이스 기본 키: UUID v4 대신 v7을 사용하면 인덱스 파편화가 줄어들어 INSERT 성능이 최대 20~30% 향상될 수 있습니다.
- 분산 시스템: 서로 다른 노드에서 생성해도 시간순 정렬이 가능하므로 병합 충돌이 적습니다.
- 메시지 큐: 메시지 ID를 v7으로 하면 생성 시간 기준으로 소비 순서를 정할 수 있습니다.
- 보안: 무작위 부분(62비트)은 브라우저의
crypto.getRandomValues()와 같은 강력한 난수 생성기에서 만들어지므로, 추측이 어렵습니다. 단, 타임스탬프가 노출되므로 생성 시간을 숨겨야 한다면 다른 형식을 고려해야 합니다.
자주 하는 실수: 같은 밀리초 내에서 엄격한 순서를 가정하거나, 타임스탬프가 시스템 시간에 의존하므로 시스템 시간이 되돌아가면 ID 순서가 깨질 수 있습니다. 또한 하이픈 없이 저장할 경우 UUID 표준 파싱 라이브러리와 호환성 문제가 없지만, 사람이 읽을 때는 가독성이 떨어집니다.
FAQ
Q: UUID v7과 ULID의 차이는 무엇인가요? A: UUID v7은 36자 표준 형식(하이픈 포함 128비트)이고, ULID는 26자 base32 문자열(128비트)입니다. ULID는 크로키드 인코딩을 사용하고 타임스탬프 정밀도가 밀리초로 동일하지만, UUID v7은 RFC 표준이라는 장점이 있습니다.
Q: 같은 밀리초에 생성된 ID끼리 순서를 보장할 수 없나요? A: 아닙니다. 타임스탬프가 같으면 나머지 무작위 비트가 정렬 순서를 결정하므로 순서가 무작위입니다. 엄격한 순서가 필요하면 시퀀스 번호를 추가하거나 다른 형식을 사용하세요.
Q: 왜 개수가 100개로 제한되나요? A: 사용자 인터페이스의 가독성과 브라우저 성능을 고려한 합리적인 한계입니다. 대량 생성이 필요하면 여러 번 나누어 생성하면 됩니다.
Q: 대문자와 하이픈 옵션은 어떻게 데이터베이스에 영향을 주나요? A: 대소문자는 데이터베이스가 문자열 비교를 어떻게 하는지에 따라 영향을 줍니다. 예를 들어 MySQL은 기본적으로 대소문자를 구별하지 않지만, PostgreSQL은 구별합니다. 하이픈은 표준 UUID 형식일 때만 파싱 라이브러리와 호환됩니다. 저장 공간은 하이픈을 포함하면 36바이트, 제거하면 32바이트입니다.
Q: 이 도구는 서버에 데이터를 보내나요?
A: 아닙니다. 모든 UUID v7 생성은 브라우저 내에서 crypto.randomUUID()(또는 유사한 API)를 사용하여 로컬에서 이루어집니다. BroBroGo 서버로 전송되는 정보는 없습니다.
Q: UUID v7 생성 시 타임스탬프는 어느 시간 기준인가요? A: 사용자 컴퓨터의 시스템 시간을 기준으로 합니다. 시스템 시간이 부정확하면 생성된 ID의 타임스탬프도 부정확해지므로, 신뢰할 수 있는 시간 소스와 동기화하는 것이 좋습니다.