🆔 UUID 생성기
브라우저의 안전한 난수로 UUID v4와 시간순 정렬형 v7을 만들어요. 최대 1,000개까지 한 번에, 원하는 형식으로 복사하세요.
사용법
- 버전을 고릅니다. 특별한 이유가 없으면 v4, 데이터베이스 기본키처럼 생성 순서대로 정렬되어야 하면 v7을 쓰세요.
- 개수를 입력하거나 빠른 버튼(1·10·50·100·1000)을 누르면 바로 생성됩니다. ↻ 다시 생성을 누를 때마다 새 값이 나옵니다.
- 대문자, 하이픈 제거, 중괄호, 구분 방식(줄바꿈·쉼표·JSON 배열·SQL IN)을 바꾸면 같은 값의 표기만 바뀝니다. 전체 복사로 한 번에 복사하세요.
- 맨 아래 UUID 분석에 아무 UUID나 붙여넣으면 버전과, v1·v6·v7이라면 생성 시각까지 알려줍니다.
UUID란?
UUID(Universally Unique Identifier, 마이크로소프트에서는 GUID)는 550e8400-e29b-41d4-a716-446655440000처럼 생긴 128비트 식별자입니다. 중앙 서버에 "다음 번호"를 물어보지 않고도 각자 만들어 쓸 수 있고, 사실상 겹치지 않는다는 것이 핵심이에요. 16진수 32자를 8-4-4-4-12로 나눠 쓰며, 세 번째 묶음의 첫 글자가 버전, 네 번째 묶음의 첫 글자(8·9·a·b)가 variant입니다. 표준은 2024년에 RFC 4122를 대체한 RFC 9562입니다.
v4와 v7 차이
| UUID v4 | UUID v7 | |
|---|---|---|
| 구성 | 랜덤 122비트 | Unix 밀리초 48비트 + 랜덤 74비트 |
| 정렬 | 무작위 순서 | 생성 시간순 정렬 |
| 생성 시각 노출 | 없음 | 앞 12자리로 알 수 있음 |
| DB 기본키 성능 | 인덱스 단편화 발생 | 순차 삽입이라 유리 |
| 적합한 곳 | 토큰, 외부 공개 ID, 일반 식별자 | DB 기본키, 로그·이벤트 ID |
v4는 완전히 랜덤이라 B-Tree 인덱스(MySQL InnoDB, PostgreSQL 등)에 넣으면 새 행이 인덱스 곳곳에 흩어져 들어가 페이지 분할과 캐시 미스가 늘어납니다. v7은 맨 앞이 타임스탬프라 항상 뒤쪽에 쌓이므로 자동 증가 정수 키와 비슷한 삽입 성능을 내면서도 분산 환경에서 따로 생성할 수 있습니다.
생성·분석 예시
2026-10-16 00:00 KST에 만든 v7 UUID를 UUID 분석 칸에 넣으면 이렇게 풀어 줘요.
| 항목 | 값 |
|---|---|
| 입력 | 01a14013-c580-7c3e-9b1f-5d2a8e4f6c07 |
| 버전 | v7 (세 번째 묶음 첫 글자 7) |
| variant | RFC 9562 (네 번째 묶음 첫 글자 9) |
| Unix ms | 앞 12자리 01a14013c580(16진수) = 1792076400000 |
| 생성 시각 | 2026-10-16 00:00:00.000 KST |
같은 값을 옵션으로 바꾸면 대문자 01A14013-C580-7C3E-9B1F-5D2A8E4F6C07, 하이픈 제거 01a14013c5807c3e9b1f5d2a8e4f6c07, SQL IN 구분은 IN ('01a14013-…', '…') 형태가 돼요.
생성 방식과 중복 확률
- v4 — 브라우저의
crypto.randomUUID()를 사용합니다. 암호학적으로 안전한 난수 생성기(CSPRNG) 기반입니다. - v7 —
Date.now()밀리초 타임스탬프 뒤에crypto.getRandomValues()난수를 붙여 직접 조립합니다. 같은 밀리초에 여러 개를 만들면 RFC 9562의 방법대로 12비트 카운터를 1씩 올려 한 번에 생성한 목록도 순서가 보장됩니다.
v4가 겹칠 확률은 10억 개를 만들어도 약 10-19 수준으로, 현실적으로 0이라고 봐도 됩니다(생일 문제 계산 기준 50% 확률로 충돌하려면 약 2.7×1018개가 필요).
| 만든 v4 개수 | 한 쌍이라도 겹칠 확률 (≈ n² ÷ 2123) |
|---|---|
| 100만 개 | 약 9.4 × 10-26 |
| 10억 개 | 약 9.4 × 10-20 |
| 1조 개 | 약 9.4 × 10-14 |
| 1000조 개 | 약 9.4 × 10-8 (1,000만분의 1) |
| 2.71 × 1018개 | 약 50% |
RFC 9562 비트 구조 한눈에 보기
128비트 가운데 6비트는 형식 표시(버전 4비트 + variant 2비트)라서 v4의 실제 랜덤은 122비트예요. v7은 맨 앞 48비트가 Unix 밀리초, 나머지 74비트가 랜덤(이 도구는 그중 12비트를 같은 밀리초 안의 순서 카운터로 써요)이에요. 원문은 RFC 9562 (IETF, 2024년 5월)에서 볼 수 있어요.
| 위치 (16진수 글자) | v4 | v7 |
|---|---|---|
| 1~12번째 (48비트) | 랜덤 | unix_ts_ms — 1970-01-01부터의 밀리초 |
| 13번째 (4비트) | 4 고정 | 7 고정 |
| 14~16번째 (12비트) | 랜덤 | rand_a (단조 증가 카운터로 쓸 수 있음) |
| 17번째 앞 2비트 | 10 → 글자는 8·9·a·b 중 하나 | 같음 |
| 나머지 62비트 | 랜덤 | rand_b 랜덤 |
v7 앞 12자리는 날짜가 바뀌면 이렇게 커져요. 그래서 문자열로 정렬해도 시간순이 맞아요. 48비트 밀리초는 서기 10889년까지 담을 수 있어요.
| 시각 (KST) | Unix ms | v7 앞 12자리 |
|---|---|---|
| 1970-01-01 09:00 | 0 | 000000000000 |
| 2026-01-01 00:00 | 1767193200000 | 019b74ec4580 |
| 2026-10-18 00:00 | 1792249200000 | 01a14a607d80 |
| 2030-01-01 00:00 | 1893423600000 | 01b8d8d75180 |
버전별 용도와 고르는 법
| 버전 | 만드는 방법 | 지금 쓸 곳 |
|---|---|---|
| v1 | 100나노초 시각 + MAC 주소 | 새로 쓰지 않음 (기기 주소 노출) |
| v3 / v5 | 이름공간 + 이름을 MD5 / SHA-1 해시 | 같은 입력에 늘 같은 ID가 필요할 때 (v5 권장) |
| v4 | 랜덤 122비트 | 외부 공개 ID, 일반 식별자 |
| v6 | v1 시각을 정렬 가능하게 재배치 | 기존 v1 시스템 호환 |
| v7 | Unix ms + 랜덤 | DB 기본키, 이벤트·로그 ID (RFC가 v1·v6보다 권장) |
| v8 | 형식만 맞춘 사용자 정의 | 자체 규칙이 있을 때 |
예시 3가지
- 버전 읽기 —
550e8400-e29b-41d4-a716-446655440000를 분석 칸에 넣으면 세 번째 묶음이4로 시작해 v4, 네 번째 묶음이a로 시작해 RFC 9562 variant로 나와요. v4라 생성 시각은 없어요. - 특수 값 —
00000000-0000-0000-0000-000000000000은 Nil UUID,ffffffff-ffff-ffff-ffff-ffffffffffff는 Max UUID로 표시돼요. "아직 값 없음"이나 범위의 끝을 나타낼 때 RFC가 정해 둔 값이에요. - 저장 크기 — 같은 UUID를
CHAR(36)에 넣으면 36바이트, 하이픈을 빼CHAR(32)면 32바이트,BINARY(16)이나 PostgreSQLuuid타입이면 16바이트예요. 1억 행이면 문자열과 바이너리의 차이가 키 하나에만 약 2GB예요.
흔한 실수
| 실수 | 바로잡기 |
|---|---|
Math.random()으로 직접 UUID 조립 | 예측 가능한 난수라 충돌·추측 위험이 커져요. crypto.randomUUID()를 쓰세요. |
| 대소문자가 다르면 다른 값으로 비교 | RFC는 출력은 소문자, 비교는 대소문자 무시를 권해요. 저장 전에 소문자로 맞추세요. |
| v4를 MySQL 클러스터드 기본키로 사용 | 삽입이 흩어져 느려져요. 순서가 필요하면 v7을 쓰세요. |
| v7 앞자리로 정확한 생성 시각을 믿음 | 생성한 기기의 시계 기준이라 시계가 틀리면 시각도 틀려요. |
v7에 담긴 밀리초를 날짜로 바꿔 보려면 타임스탬프 변환기에 앞 12자리를 10진수로 바꾼 값을 넣으면 돼요.
v7은 앞부분에 생성 시각이 그대로 담기므로, 가입 시각처럼 노출되면 안 되는 정보를 담은 ID를 외부에 공개할 때는 v4를 쓰세요. UUID는 추측하기 어려운 값이지만 비밀번호나 인증 토큰을 대신하도록 설계된 것은 아닙니다. 생성은 모두 브라우저 안에서 이뤄지고 서버에 기록되지 않습니다.