UUID v4 대 UUID v7 대 ULID: 어떤 고유 ID를 사용해야 합니까?

자동으로 증가하는 정수들은 수십 년 동안 기본 기본 키였습니다. 그것들은 작고 빠르고, 숫자를 배포하기 위해 중앙 데이터베이스를 필요로 하고, 얼마나 많은 기록이 있는지 누출하고, 여러 시스템에서 데이터를 통합하는 것을 고통스럽게 만듭니다. 글로벌 고유 식별자는 이러한 문제를 해결합니다. 어떤 서버, 모바일 앱 또는 오프라인 클라이언트도 충돌하지 않는 ID를 만들 수 있습니다. 문제는 어떤 종류의 것인지입니다. 이 가이드는 2026년 가장 인기있는 3가지 옵션을 비교합니다. UUID 버전 4, UUID 버전 7, ULID.

UUID에 대한 빠른 업데이트

UUID (Universally Unique Identifier) 는 128비트 값으로, 일반적으로 5개의 그룹으로 32개의 헥사데시마를 기록한다.

550e8400-e29b-41d4-a716-446655440000

현재 표준인 RFC 9562 (RFC 4122를 대체하는 2024년에 발표) 는 여러 버전을 정의한다. 몇 비트가 버전과 변종을 암호화합니다. 나머지는 버전에 달려 있습니다. 세 번째 그룹은 항상 버전 번호로 시작합니다. 그래서 v4와 v7를 한눈에 구분할 수 있습니다.

UUID v4: 순수 무작위

버전 4 UUID는 122개의 무작위 비트와 버전 및 변종에 대한 6개의 고정 비트들을 포함합니다.

강점

• 생성하는 것이 사소한 것: 모든 언어와 데이터베이스에는 자바스크립트에서 crypto.randomUUID() 또는 PostgreSQL에서 gen_random_uuid()와 같은 내장 기능이 있습니다.
• 시간표, 기계 식별자, 순서가 없습니다.
• 충돌 가능성은 무시할 수 있습니다. 두 배의 확률이 50%를 차지하기 위해서는 2.7 × 10^18 ID를 생성해야 합니다.

약점

• 무작위 순서는 데이터베이스 인덱스를 손상시킵니다. PostgreSQL, MySQL 및 SQL Server에서 사용하는 B 트리 인덱스는 새로운 키가 증가하는 순서로 도착하면 가장 잘 작동합니다. 무작위 키는 전체 인덱스에 떨어집니다. 페이지 분할과 캐시 로컬리티가 떨어지고 기록 증폭이 발생합니다. 큰 테이블에서 삽입 처리량은 크게 떨어질 수 있으며 인덱스는 필요 이상으로 커질 수 있습니다.
• 생성 시간에 따라 정렬할 수 없으므로 시간적 질의에 별도의 created_at 열이 필요합니다.

UUID v7: 시간 순서

버전 7은 48비트 유닉스 타임스테ంపు를 밀리초로 앞쪽에 배치하고, 그 다음 74비트 무작위성을 (일부 구현은 같은 밀리초 내에서 순서를 정하는 카운터로 일부를 사용합니다.)

01928c3e-5b7a-7c4d-9f3e-2a1b4c5d6e7f
└─timestamp─┘ └version 7

강점

• 새로운 ID는 대략 증가하고 있습니다. 그래서 삽입자는 자동 증가 키처럼 인덱스의 끝으로 추가됩니다. 이렇게 하면 인덱스가 콤팩트하고 빠르게 쓰일 수 있습니다.
• 생성 시간에 따라 ID 정렬로 정렬하여 커서 기반 페이징을 간단하게 만듭니다: WHERE id > :last_id ORDER BY id LIMIT 50.
• 여전히 표준 UUID입니다: 이미 UUID를 받아들이는 uuid 열, ORM 및 API에 적합합니다.
• 디버깅을 위해 ID에서 생성 시간을 추출할 수 있습니다.

약점

• ID를 보는 모든 사람이 제작 시간을 볼 수 있습니다. 대부분의 기록에는 무해하지만, 개인 정보 보호에 민감한 제품에 있는 사용자 계정과 같이, 어떤 사람이 언제 가입했는지 알 수 있습니다.
• 상당히 정확한 시계를 필요로 합니다. 큰 시계 점프로 인해 기존의 ID보다 먼저 정렬되는 ID가 생성될 수 있습니다. 좋은 도서관은 단조로운 카운터로 처리합니다.
• 네이티브 생성 기능은 더 새로운 것입니다. PostgreSQL 18은 uuidv7()을 추가했습니다. 이전 버전에서는 응용 프로그램 코드에서 생성합니다.

ULID: 정렬 가능하고 컴팩트한 텍스트

ULID (Universally Unique Lexicographically Sortable Identifier) 는 UUID v7보다 오래되었고 동일한 아이디어를 사용합니다. 48 비트 밀리초 시간표가 80 개의 무작위 비트로 이어집니다. 차이점은 텍스트 형태입니다: 크록포드 베이스32의 26자

01J9Z3K8M2Q7X4V5B6N8P0R2T4

강점

• 36자 줄 UUID보다 짧고 URL 안전합니다.
• 대문자 민감하지 않고 모호한 글자 (I, L, O, U) 를 제외하므로 소리 높게 읽거나 입력하기가 쉽습니다.
• 사전적 문자열 정렬은 시간 순서 정렬과 같으며, 이는 키-값 저장소 또는 로그 파일 이름과 같은 텍스트로 ID를 저장하는 시스템에 도움이 됩니다.

약점

• UUID가 아니기 때문에 변환 없이 네이티브 UUID 컬럼 타입에 맞지 않습니다. 128비트는 하나에 저장할 수 있습니다.
• IETF 표준이 아닌 커뮤니티 사양으로, 라이브러리들 사이에서 약간 다른 동작을 합니다.
• V7처럼 창조시간을 노출합니다.

나란히 비교

재산	UUID v4	UUID v7	ULID
크기	128 비트	128 비트	128 비트
텍스트 길이가	36	36	26
시간 순서	아니	그래요	그래요
누출된 창작 시간	아니	네 (ms)	네 (ms)
표준	RFC 9562	RFC 9562	유럽연합 특포
네이티브 DB 타입	uuid	uuid	보통 문자 또는 바이너리
인덱스 친화적 인 삽입	가난한 사람	좋아	좋아

보관 팁

어떤 것을 선택하든, 16바이트로 저장하세요, 텍스트로 저장하지 마세요. 36자 문자열은 두 배 이상의 공간을 차지하고, 이를 참조하는 모든 인덱스와 외국 키는 비용을 곱합니다. 포스트그레SQL에는 네이티브 uuid 타입이 있습니다. MySQL 사용자는 BINARY(16)와 UUID_TO_BIN(uuid, 1)를 사용할 수 있습니다. 두 번째 인항이 v1 타임스테ంపు를 다시 순서 지정하는 경우 v7의 경우 이미 시간 순서 지정되어 있기 때문에 기본 순서를 사용합니다.

API의 ID를 정규 텍스트 형태로 노출합니다. 고객들은 그것들을 불투명한 문자열으로 취급해야 하며 결코 의미들을 분석하지 않아야 합니다.

안전성 문제

이 신분증들은 비밀이 아닙니다. 암호 재설정 토큰이나 세션 식별자로 사용하지 마십시오. v4 UUID는 측정할 수 없는 충분한 무작위성을 가지고 있지만, v7와 ULID는 효과적인 엔트로피를 감소시키는 예측 가능한 시간표 접두어를 가지고 있습니다. 비밀의 경우 암호 생성기로 최소 128개의 무작위 비트 (random bit) 를 생성하고 암호처럼 취급하여, 이상적으로 해시 (hash) 를만 저장합니다. [MD5 vs SHA-256]

또한 수치를 고려하십시오. 연속 정수들은 누구나 /orders/1001, /orders/1002를 추측할 수 있습니다. 무작위 또는 시간 순서로 된 ID는 그것을 실용적이지 않지만 모든 요청에 대한 허가 검사를 대체 할 수 없습니다.

어느 쪽을 선택해야 할까요?

• ** 새로운 시스템에서 데이터베이스 기본 키:** UUID v7. 분산된 생성과 좋은 인덱스 성능을 얻을 수 있습니다.
• ** 생성 시간이 비공개로 유지되어야 하는 공개 식별자:** UUID v4, 또는 v7 내부 키와 별도의 무작위 공개 ID가 결합되어 있습니다.
• ** 텍스트 기반 저장소, 파일 이름 또는 ID 사람들은 입력 할 수 있습니다:** ULID, 더 짧은, 대문자 민감하지 않은 형태.
• ** 성능 문제가 있는 v4의 기존 시스템:** 새로운 테이블을 위해 v7을 고려하십시오. 두 가지 모두 유효한 UUID이기 때문에 한 열의 버전을 혼합하는 것은 기술적으로 좋습니다.

ID를 생성합니다.

빠른 작업을 위해 시드 데이터, 테스트 픽처, 수동 삽입 브라우저 기반의 [UUID 생성자] (/ 도구/uuid) 는 crypto.getRandomValues을 사용하여 한 번에 최대 1,000개의 v4, v7 또는 ULID 값을 생성할 수 있습니다. 응용 프로그램 코드에서, 언어의 표준 라이브러리 또는 잘 유지 된 패키지를 사용 하 여 기록 생성에 가능한 한 가까운 ID를 생성 합니다.

요약

UUID v4는 무작위적이고 개인적이지만 데이터베이스 인덱스를 흩어집니다. UUID v7는 표준 UUID로 유지하면서 삽입을 빠르게하고 ID를 정렬할 수 있도록 타임 스탬프 접두어를 추가합니다. ULID는 짧고 친근한 텍스트 형식으로 동일한 순서를 제공합니다. 대부분의 새로운 애플리케이션에서는 UUID v7이 가장 좋은 기본값입니다. 타이밍이 숨겨져야 할 때 v4에 도달하고 인간이나 텍스트 기반 시스템이 ID를 처리 할 때 ULID에 도달합니다.