버전(v4 무작위·v7 시간순)과 개수를 고르면 브라우저의 암호학적 난수로 UUID 를 만들어요. 대문자·하이픈 제거 형식을 지원하고, 생성값은 이 페이지를 벗어나지 않아요.
v4 는 122bit 를 crypto.getRandomValues 로 채워요 — Math.random 이 아니라서 예측·충돌 걱정 없이 쓸 수 있어요.
v7 은 앞 48bit 가 생성 시각(Unix ms)이라 문자열 정렬이 곧 시간 정렬이에요. DB 인덱스 단편화를 줄이려는 기본키에 적합해요.
생성·복사 전부 브라우저 안에서 끝나요. 네트워크 요청이 없어서 생성값이 기록에 남지 않아요.
UUID(범용 고유 식별자)는 128bit 식별자예요. 표기는 hex 32자를 8-4-4-4-12 로 나눈 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 형태고, RFC 9562 가 표준이에요.
핵심 성질은 중앙 발급기관 없이 어디서 만들어도 겹치지 않는다는 거예요. 서버·클라이언트·오프라인 어디서 만든 ID 든 나중에 한 DB 에 모아도 충돌하지 않아요.
hex 한 자리가 4bit 라 32자 = 128bit 예요. 이 중 6bit 는 버전·변형 표기에 쓰여요.
v4 는 전부 무작위예요(122bit). 값에 아무 정보가 없어서 노출돼도 생성 시각·순서를 추측할 수 없어요. 세션 토큰 조각·외부 노출 ID 처럼 추측 불가능성이 중요한 곳에 맞아요.
v7 은 앞 48bit 가 생성 시각(Unix 밀리초)이고 나머지 74bit 가 무작위예요. 문자열로 정렬하면 곧 시간순이라 DB 기본키로 쓸 때 인덱스가 순서대로 자라요 — v4 를 기본키로 쓰면 삽입 위치가 무작위라 B-tree 인덱스가 단편화돼요.
대신 v7 은 값에 생성 시각이 드러나요. 시각 노출이 문제가 되는 곳(외부 공개 ID)에는 v4 를 쓰세요.
v4 의 무작위 공간은 2¹²² ≈ 5.3 × 10³⁶ 이에요. 10억 개씩 100년을 만들어도 충돌이 하나라도 날 확률이 백만분의 일에 못 미쳐요(생일 역설 기준).
실무에서 UUID 충돌을 걱정할 필요는 없어요 — 충돌이 난다면 난수 생성기가 고장난 경우지, 확률의 문제가 아니에요.
그래서 Math.random 같은 예측 가능한 난수로 UUID 를 만들면 안 돼요. 이 도구는 crypto.getRandomValues 만 써요.
RFC 9562 는 소문자 출력을 표준으로 정하고, 읽을 때는 대문자도 받아들이라고 해요. 즉 A1B2… 와 a1b2… 는 같은 UUID 예요 — 비교할 때는 한쪽으로 통일해서 비교하세요.
하이픈은 사람이 읽기 위한 구분이에요. DB 컬럼·URL·파일명처럼 글자 수가 아까운 곳에서는 하이픈 없는 32자를 쓰기도 해요(이 도구의 «하이픈 제거» 옵션). 저장 자체는 문자열 36자보다 16바이트 바이너리(예: PostgreSQL 의 uuid 타입)가 절반 이하로 작아요.
일부 시스템(옛 Microsoft GUID 표기)은 {…} 중괄호를 두르기도 해요 — 값은 같고 포장만 달라요.
v1 은 시각 + MAC 주소예요. 생성한 기기가 값에 드러나는 프라이버시 문제로 요즘은 v4·v7 에 밀렸어요. 시간순 정렬이 목적이면 v7 이 같은 성질을 더 깔끔하게 줘요.
v3/v5 는 무작위가 아니라 이름을 해시해서 만들어요(각각 MD5·SHA-1). 같은 입력이면 언제나 같은 UUID 가 나와서, «이 URL 의 UUID» 처럼 결정적 ID 가 필요할 때 써요 — 생성기가 아니라 계산기에 가까워요.
그래서 온라인 생성기가 다루는 건 사실상 v4 와 v7 둘이에요. 무작위 ID 가 필요하면 v4, 정렬되는 ID 가 필요하면 v7 — 이 둘로 거의 모든 경우가 덮여요.
crypto.getRandomValues 로 16바이트를 채우고 RFC 9562 가 정한 버전(13번째 hex 자리)·변형(17번째 자리) 비트만 덮어써요.
v7 은 Date.now() 밀리초를 앞 48bit 에 빅엔디언으로 넣어요 — 같은 밀리초 안에서는 나머지 74bit 무작위가 순서를 가르니, 엄밀한 단조 증가가 필요하면 DB 시퀀스를 함께 쓰세요.
생성값은 서버로 전송되지 않아요. 생성·복사 전부 브라우저 안에서 끝나고, 페이지를 벗어나면 사라져요.
모르겠으면 v4 예요 — 표준적인 무작위 UUID 로 어디서나 통해요. 생성 순서대로 정렬되어야 하는 값(DB 기본키·이벤트 ID)이면 v7 이 인덱스 성능에 유리해요.
이론상 가능하지만 실질적으로 없어요. v4 는 122bit 무작위라 초당 10억 개를 100년 만들어도 충돌 확률이 사실상 0 이에요.
아니요. 브라우저의 암호학적 난수로 만들고 네트워크 요청을 보내지 않아요. 페이지를 벗어나면 값도 사라져요.