UUID 생성기

UUID v4를 클릭 한 번으로 생성 (대량·옵션 지원)

UUID 생성기 소개

UUID는 128비트짜리 식별자로, 중앙에서 번호를 나눠 주는 서버 없이도 각자 만든 값이 서로 겹치지 않게 하려고 씁니다. 2005년 RFC 4122로 정리되었고, 2024년 5월 RFC 9562가 이를 대체하면서 버전 6·7·8이 추가되었습니다.

이 도구는 버전 4, 즉 무작위 UUID만 만듭니다. 브라우저의 crypto.getRandomValues로 16바이트를 뽑은 뒤 버전 자리(13번째 16진 문자)를 4로, 변형 자리(17번째 문자)를 8·9·a·b 중 하나가 되도록 고정합니다. 한 번에 최대 1,000개까지 만들 수 있고, 대문자나 하이픈 없는 32자 형태로도 바꿀 수 있습니다.

UUID 문자열 읽는 법

2d7f7b60-80d6-4402-8639-8e0992715d01에서 세 번째 묶음의 첫 글자 4가 버전입니다. 네 번째 묶음의 첫 글자 8은 변형(variant)으로, 이 UUID가 RFC 규격을 따른다는 표시입니다. 규격 UUID라면 이 자리는 항상 8, 9, a, b 중 하나입니다. 이 두 자리를 빼면 128비트 중 122비트가 무작위입니다.

RFC 9562는 16진 문자를 출력할 때 소문자로 쓰고, 입력받을 때는 대소문자를 구분하지 말라고 합니다. 대문자 옵션은 대문자를 요구하는 옛 시스템(일부 Windows 레지스트리 GUID 표기 등)과 맞출 때만 쓰면 됩니다. 하이픈 없는 32자 형태도 같은 값이지만, 데이터베이스에 문자열로 저장한다면 한 가지 형태로 통일해 두어야 비교가 어긋나지 않습니다.

충돌 확률을 실제 숫자로 계산하면

무작위 비트가 122개이므로 가능한 값은 2^122(약 5.3×10^36)개입니다. 생일 문제 근사식 p ≈ 1 − e^(−n²/2N)에 넣어 보면, 10억(10^9)개를 만들었을 때 한 쌍이라도 겹칠 확률은 약 9.4×10^−20입니다. 1조 개를 만들어도 약 9.4×10^−14이고, 충돌 확률이 50%가 되려면 약 2.7×10^18개, 즉 27억의 10억 배를 만들어야 합니다.

이 계산은 난수 생성기가 제대로 된 경우에만 성립합니다. 현실에서 UUID가 겹친 사례는 대부분 확률이 아니라 구현 문제입니다. 가상 머신 이미지를 복제해 난수 상태가 같아졌거나, 암호학적이지 않은 난수(Math.random 등)를 썼거나, 테스트용 고정 값을 운영에 그대로 둔 경우입니다. 이 도구는 Math.random으로 대체하지 않습니다. Web Crypto API가 없는 환경에서는 생성 버튼을 막고 안내를 띄우는데, 현재 쓰이는 브라우저에는 모두 Web Crypto가 있습니다.

v4와 v7: 데이터베이스 기본 키라면 무엇을 쓸까

UUIDv7은 앞 48비트에 밀리초 단위 유닉스 시각을 넣고, 나머지 74비트(버전·변형 제외)를 무작위나 순서 보장용 카운터로 채웁니다. 그래서 나중에 만든 값이 문자열로 정렬해도 뒤에 옵니다. RFC 9562는 가능하면 v1·v6 대신 v7을 쓰라고 권고합니다.

차이가 크게 드러나는 곳은 B-tree 인덱스입니다. v4는 새 값이 인덱스 전체에 흩어져 들어가므로 매번 다른 페이지를 읽고 쪼개야 하고, 캐시에 올라와 있지 않은 페이지를 건드리는 일이 잦습니다. v7은 새 값이 항상 인덱스 끝부분에 붙어 자동 증가 정수와 비슷하게 동작합니다. RFC 9562도 시간 순서가 없는 UUID가 인덱스에서 서로 가깝지 않게 들어가 성능에 악영향을 준다고 적고 있습니다.

반대로 v7에는 생성 시각이 그대로 드러납니다. 주문 번호나 사용자 ID처럼 외부에 노출되는 값에서 가입 시점이나 생성 속도를 숨기고 싶다면 v4가 낫습니다. 이 도구는 v4만 만들므로, v7이 필요하면 데이터베이스나 언어의 UUID 라이브러리에서 생성하세요.

UUID를 비밀 토큰으로 써도 될까

v4의 122비트 무작위성은 추측하기 매우 어렵지만, RFC 9562는 UUID를 보안 능력(추측 불가능해야 하는 접근 토큰 등)으로 쓴다고 가정하지 말라고 권합니다. 모든 구현이 암호학적 난수를 쓴다는 보장이 없고, v1·v7처럼 일부 비트가 예측 가능한 버전도 있기 때문입니다. 비밀번호 재설정 링크 같은 용도에는 목적에 맞게 만든 무작위 토큰을 쓰는 편이 안전합니다.

예시

기본 출력 3개

입력
개수 3, 기본 옵션
결과
2d7f7b60-80d6-4402-8639-8e0992715d01 9bba9b5f-1591-4dcb-8868-c86de213d8f6 f791f531-9479-4b86-b466-6e177cc7bbe7

세 값 모두 세 번째 묶음이 4로 시작하고, 네 번째 묶음은 8·8·b로 시작합니다. 값은 매번 달라집니다.

대문자, 하이픈 없음

입력
개수 1, 대문자 켬, 하이픈 끔
결과
3F160309A63D43538F70D0C6292876C0

13번째 글자 4와 17번째 글자 8이 버전과 변형입니다. 하이픈이 없어도 같은 자리에 있습니다.

10억 개를 만들면

입력
n = 10^9, N = 2^122
결과
충돌 확률 ≈ 9.4×10^−20

n²/2N = 10^18 / (2×5.32×10^36) ≈ 9.4×10^−20. 1조 개면 10^6배 커져 약 9.4×10^−14입니다.

사용 방법

  1. 필요한 개수(1~1,000)를 입력합니다.
  2. 쓸 곳에 맞게 대문자·하이픈 옵션을 고릅니다. 특별한 이유가 없으면 소문자·하이픈 포함이 표준입니다.
  3. 생성 후 복사하거나 목록째 받아 씁니다.

자주 묻는 질문

GUID와 UUID는 다른 건가요?

같은 128비트 식별자를 가리키는 이름입니다. GUID는 마이크로소프트 쪽에서 주로 쓰는 명칭이고, Windows 도구가 대문자와 중괄호 표기를 쓰는 경우가 많을 뿐 값의 구조는 같습니다.

UUID로 생성 순서를 알 수 있나요?

v4로는 알 수 없습니다. 순서가 필요하면 v7을 쓰거나 별도의 생성 시각 컬럼을 두세요.

데이터베이스에 문자열로 저장해도 되나요?

가능하지만 36바이트 문자열은 16바이트 바이너리의 두 배 이상 공간을 씁니다. PostgreSQL의 uuid 타입처럼 전용 타입이 있으면 그것을 쓰는 편이 저장 공간과 비교 속도 모두 유리합니다.

만든 UUID가 이미 누군가 쓰고 있지는 않나요?

확인할 방법은 없지만, 위의 계산처럼 제대로 된 난수로 만든 v4가 겹칠 확률은 현실적으로 무시할 수 있는 수준입니다.

출처

기준일:

개인정보와 저장 방식