UUID 해설 — v4 vs v7

UUID(범용 고유 식별자)는 중앙 기관이 번호를 나눠주지 않고도 무언가를 고유하게 식별하기 위한 128비트 라벨입니다. 고유한 행 ID, 충돌하지 않는 파일 이름, 분산 시스템용 키가 필요해 본 적이 있다면 UUID를 만나본 적이 있을 것입니다. UUID 생성기는 Web Crypto를 써서 v4·v1·v7을 로컬에서 만듭니다 — 서버로는 아무것도 보내지 않습니다.

TL;DR

UUID는 128비트 식별자이며, 고르는 버전에 따라 그 비트들의 의미가 달라집니다.

v4는 완전 무작위(기본값) — 그저 고유한 ID가 필요할 때의 표준 선택입니다.
v7은 시간 정렬 가능 — Unix 밀리초 타임스탬프를 품어 시간순으로 정렬되므로, 훨씬 더 나은 데이터베이스 인덱스 키가 됩니다.
Web Crypto로 로컬 생성 — crypto.getRandomValues가 브라우저 안에서 무작위성을 담당하므로, 서버는 관여하지 않고 값은 결코 기기를 떠나지 않습니다.

UUID란 무엇인가

UUID는 128비트의 데이터로, 관행상 하이픈으로 구분된 다섯 그룹에 32개의 16진수 숫자로 표현됩니다 — 8-4-4-4-12 배치입니다.

550e8400-e29b-41d4-a716-446655440000

몇 비트는 버전(위 세 번째 그룹의 4는 v4를 뜻함)과 변형(네 번째 그룹의 맨 앞 a/b/8/9) 표시용으로 예약되어 있습니다. 나머지가 실제 식별 데이터를 담으며, 그 데이터가 무엇인지는 버전에 따라 다릅니다. 전체 공간 — 가능한 값 2¹²⁸개 — 은 너무 방대해서, 현실적인 규모에서는 무작위 UUID가 사실상 결코 충돌하지 않습니다.

UUID가 아닌 것이 하나 있습니다. 비밀이 아니라는 것입니다. 식별자이며, 차량 번호판 같은 것입니다. 하나를 안다고 해서 다른 것을 도출할 수 있는 건 아니지만, UUID 자체로는 접근 제어를 제공하지 않습니다 — 비밀번호나 토큰으로 쓰지 마세요.

UUID v4 — 무작위 기본값

사람들이 “UUID”라고 말할 때 대부분 v4를 뜻합니다. 128비트 중 122비트가 무작위(6비트는 버전과 변형으로 고정)이며, 암호학적 무작위원에서 가져옵니다. 그 결과 시간·장소·다른 값과 무관한 식별자가 됩니다.

무작위 공간이 이렇게 크기 때문에, 독립적으로 생성된 두 v4 UUID가 충돌할 확률은 천문학적으로 작습니다 — 그럴듯해지려면 매초 수십억 개를 수년간 생성해야 합니다. 그래서 v4는 고유한 ID가 필요하고 순서가 상관없을 때 — 요청 ID, 세션 키, 파일 이름 — 언제나 올바른 선택입니다. 단점은 v4 값이 공간 전체에 균일하게 흩어진다는 것이며, 이는 데이터베이스 인덱스에 불리합니다(아래 참조).

UUID v7 — 시간 정렬 가능한 것

v7은 맨 앞 비트에 Unix 밀리초 타임스탬프를 품고, 나머지 비트는 무작위입니다. 결정적인 결과는, v7 UUID가 만들어진 순서대로 정렬된다는 것입니다.

이는 데이터베이스에서 중요합니다. 기본 키 인덱스는 삽입이 연속적일 때 가장 잘 작동합니다. 새 행이 페이지 전체에 무작위로 흩어지지 않고 인덱스 안에서 서로 옆에 자리 잡기(‘추가’ 패턴) 때문입니다. 반면 v4 삽입은 무작위 페이지를 칩니다 — 무작위 디스크 입출력, 페이지 분할, 테이블이 커짐에 따른 인덱스 파편화를 일으킵니다. v7 삽입은 뭉치므로, 데이터베이스는 순차적으로 쓰고 인덱스는 컴팩트하게 유지됩니다.

시간이 지나며 커지는 모든 테이블 — 주문, 이벤트, 로그 행 — 에서 v7이 보통 더 나은 기본 키입니다. 조정 없이도 기계 간 고유성은 유지되면서 인덱스는 제대로 작동합니다.

UUID v1 — 레거시

v1 역시 타임스탬프(1582년 이후 100나노초 클록 60비트)와 노드 식별자를 인코딩합니다. 이 노드 식별자는 역사적으로 기기의 MAC 주소에서 파생됐습니다. v7과 같은 의미에서 정렬 가능하지만, 지금은 거의 올바른 선택이 되지 않게 만드는 두 가지 단점이 있습니다.

프라이버시 유출 — 모든 UUID에 MAC 주소를 품으면, 생성한 기기의 네트워크 하드웨어가 드러나고 한 노드의 UUID가 너무 쉽게 연결됩니다. 기본적으로 프라이버시를 중시하는 세상에서, 이는 실질적 비용입니다.
v7에 비해 실질적 이점 없음 — v7은 깔끔한 Unix 밀리초 타임스탬프와 하드웨어 지문 없이 시간순을 주므로, v1으로 갈 이유는 대부분 사라졌습니다.

기존 v1 데이터가 있다면 여전히 잘 작동합니다. 단지 새 시스템을 v1로 시작하지 마세요. v4(순서가 중요하지 않을 때) 또는 v7(중요할 때)이 현대의 거의 모든 요구를 덮습니다.

단계별: UUID 생성하기

UUID 생성기는 Web Crypto를 써서 전적으로 브라우저 안에서 돌아가므로, 무작위 바이트는 로컬에서 생성되고 아무것도 업로드되지 않습니다. 흐름은 이렇습니다.

버전을 고릅니다. v4 / v1 / v7 버튼으로 생성할 UUID 버전을 선택합니다(기본값은 v4).
개수를 고릅니다. 개수 선택지로 몇 개를 생성할지 정합니다: 5, 10, 25, 50, 100(최대 100). 기본값은 10입니다.
형식을 고릅니다. 일곱 가지 출력 형식이 결과를 다듬습니다:
- plain — 표준 8-4-4-4-12 형태, 550e8400-e29b-41d4-a716-446655440000처럼.
- UPPER — 모두 대문자, 대문자를 선호하는 시스템용.
- 하이픈 없음 — 32자리 16진수를 이어 붙임, 550e8400e29b41d4a716446655440000처럼.
- {중괄호} — {...}로 감쌈, Microsoft GUID 스타일.
- “string” — 큰따옴표로 감싸, JSON 값에 바로 붙여 넣을 수 있게.
- SQL IN — ('...','...') 형식으로, SQL IN (...) 절용.
- JS array — ["...","..."] 형식으로, 바로 쓸 수 있는 JavaScript 배열 리터럴.
생성합니다. 새로 생성을 누르면 단일 UUID가, 생성을 누르면 지정한 개수 전체를 한 번에(대량 생성) 만듭니다.
복사합니다. 복사를 누르면 생성된 모든 값을 클립보드에 복사합니다.

버전을 바꾸면 그 버전의 새 단일 값이 즉시 생성되므로, 형식을 나란히 비교할 수 있습니다.

자주 묻는 질문

UUID는 비밀인가요?

아니요. UUID는 식별자이지 비밀이 아닙니다. 하나를 안다고 해서 다른 것을 예측할 수 있는 건 아니며, v4/v7 값 자체로는 접근을 허락하지 않습니다. 추측하기 어려워야 할 것 — 비밀번호, API 토큰, 세션 비밀 — 이 필요하면, 비밀번호·토큰 생성기로 진짜 비밀을 생성하세요. UUID는 고유성을 위한 것이지 접근 제어를 위한 것이 아닙니다.

제 데이터베이스에는 v4와 v7 중 어느 것?

시간이 지나며 커지는 테이블이라면, 보통 v7이 더 나은 기본 키입니다. 생성 시각순으로 정렬되므로 삽입이 연속적이고, 인덱스가 무작위 입출력으로 파편화되는 대신 컴팩트하게 유지됩니다. 순서가 중요하지 않고 폭넓은 호환성을 원할 때 — 요청 ID, 캐시 키, 값이 단순한 라벨인 곳 — 는 v4를 쓰세요. 망설여지면, 새 기본 키에는 v7, 그 외에는 v4를 고르세요.

어떤 형식을 골라야 하나요?

값이 어디로 가는지에 따라 다릅니다. plain은 안전한 기본값이자 대부분의 시스템이 기대하는 것입니다. UPPER는 GUID를 대문자로 저장하는 시스템에 맞습니다. 하이픈 없음은 4바이트를 아끼고 빡빡한 형식에 들어맞습니다. **{중괄호}**는 Microsoft GUID 관행을 따릅니다. **“string”**은 JSON 값에 직접 들어가고, SQL IN은 데이터베이스 쿼리에, JS array는 JavaScript 소스 코드에 들어갑니다. 목적지에 맞는 형태를 고르세요.

한 번에 많이 생성할 수 있나요?

네. 개수(최대 100)를 설정하고 생성을 누르면 그 수의 UUID를 한 번에 만들고, 이어 복사로 전부 가져올 수 있습니다. 하나만 필요하다면, 새로 생성이 개수에 영향을 주지 않고 단일 값을 만듭니다.