단일 v4 UUID
입력
count: 1 uppercase: off
출력
550e8400-e29b-41d4-a716-446655440000
13번째 글자는 항상 `4`(버전), 17번째 글자는 `8`·`9`·`a`·`b` 중 하나(배리언트)입니다. 나머지 122비트(`e8400`·`e29b`·`1d4` 등)가 완전 랜덤 부분입니다.
Loading…
모든 처리는 브라우저 내부에서 실행됩니다 — 파일·입력은 서버로 전송되지 않습니다.
사용법
생성할 UUID개수(1~100)를 설정하고 Generate를 누릅니다. 각각은 새로운 v4 UUID이며, 브라우저의 WebCrypto API에서 가져온 암호학적으로 안전한 122비트 랜덤 값입니다. 시각·MAC주소·카운터 같은 정보는 일절 포함되지 않습니다. 다운스트림 시스템이 16진수를 대문자로 저장한다면(옛 SQL Server나 Oracle 일부 설정 등) Uppercase를 켜세요.
조율 없이 고유한 식별자가 필요한 상황에서 사용합니다. DB INSERT 이전의 드래프트 레코드 ID, HTTP재시도용 멱등성 키, 로그 트레이스용 상관 ID 같은 경우입니다. 출력은 완전 랜덤이라 정렬 가능하지 않습니다. 생성 시각 순으로 정렬해야 한다면 UUID v7이나 ULID를 검토하세요. 생성은 모두 브라우저 안에서 이루어지며 어떤 값도 서버로 전송되지 않습니다.
예제
시드 파일용 일괄 생성
입력
count: 5 uppercase: off
출력
a1b2c3d4-5e6f-4a7b-8c9d-0e1f2a3b4c5d f9e8d7c6-b5a4-4392-8170-6f5e4d3c2b1a 7c8d9e0f-1a2b-4c3d-9e8f-0a1b2c3d4e5f 3b4c5d6e-7f80-4192-a3b4-c5d6e7f80a1b 12345678-9abc-4def-9012-3456789abcde
일괄 모드(최대 100건)는 테스트 픽스처 시드 데이터 투입, 스테이징용 `WHERE id IN (…)` 절 작성, 배치 작업용 멱등성 키 사전 발급 같은 때 유용합니다. Copy All로 한 번에 전체 목록을 복사할 수 있습니다.
레거시 시스템용 대문자
입력
count: 1 uppercase: on
출력
550E8400-E29B-41D4-A716-446655440000
RFC 4122 §3은 생성 측에 "소문자 출력 권장"이라 명시하지만, 파싱 측은 양쪽을 모두 받아야 합니다. SQL Server의 UNIQUEIDENTIFIER나 Oracle의 RAW(16)는 기본적으로 대문자로 표시하므로, 입력 측에서 그 표기에 맞추면 픽스처의 시각적 diff 잡음을 피할 수 있습니다.
자주 묻는 질문
같은 UUID가 중복 생성될 수 있나요?
실무적으로는 없습니다. v4는 122비트 랜덤 값으로 약 5.3 × 10^36개의 서로 다른 값을 가집니다. 생일 역설로 50% 충돌이 발생하는 지점은 약 2.71 × 10^18개 생성. 초당 10억 개를 100년 만들어도 충돌 확률은 검지 임계 아래에 머뭅니다. v4 UUID의 중복은 확률 사건이 아니라 코드 버그(초기화되지 않은 난수 생성기, 버퍼 재사용 등)를 의심하세요.
v4는 데이터베이스의 기본 키로 적합한가요?
기능적으로는 가능하지만 성능 면에서는 권장되지 않는 경우가 많습니다. 랜덤 ID는 B-tree 전체에 INSERT를 흩뿌려 페이지 단편화와 버퍼 캐시 히트율 저하를 일으킵니다. 쓰기 빈도가 높은 테이블에서는 PostgreSQL·MySQL·SQL Server 모두 영향이 나타납니다. UUID v7(시각 순)이나 ULID는 무조율 성질을 유지한 채 지역성 문제를 해결합니다. 굳이 v4를 써야 한다면 클러스터링용으로 연번 `bigserial`을 두고 UUID는 보조 조회 키로 쓰는 방안을 검토하세요.
v1·v4·v7의 차이는?
v1은 60비트 타임스탬프와 호스트의 MAC주소를 결합합니다. 정렬 가능하지만 어디서 ID를 만들었는지가 누설됩니다. v4는 완전 랜덤. 누설은 없지만 정렬 불가. v7(RFC 9562, 2024년)은 앞쪽에 48비트 Unix밀리초 타임스탬프를 두고 뒤를 랜덤으로 채웁니다. 정렬 가능, MAC누설 없음, v4 저장 컬럼에 그대로 들어갑니다. v3·v5는 네임스페이스와 이름에 대한 결정론적 해시로, 같은 입력으로 항상 같은 UUID를 얻어야 할 때 사용합니다.
`crypto.randomUUID()`는 토큰 용도로 암호학적으로 충분히 안전한가요?
대부분의 용도에서는 충분합니다. 배후 CSPRNG는 WebCrypto의 subtle 키 생성과 동일합니다. 다만 122 랜덤 비트는 장수명 베어러 토큰이나 세션 ID에 대해 OWASP ASVS가 권장하는 128비트 하한을 밑돕니다. 그런 용도에는 UUID 대신 전용 랜덤 바이트 함수(`crypto.getRandomValues(new Uint8Array(32))` + base64url 등)를 사용하세요.
하이픈 없는 UUID도 받을 수 있나요?
직접은 안 됩니다. 이 도구는 정규형(8-4-4-4-12)으로 출력합니다. 복사 후 하이픈을 제거하려면 `s/-//g`(sed), `replace(/-/g, "")`(JS), 또는 수동 찾아 바꾸기를 사용하세요. RFC 4122는 파서에 양쪽 형식 수용을 허용하지만, 로그나 API가 가정하는 것은 대개 이 정규형입니다.
UUID·ULID·nanoid — 언제 무엇을 쓰나요?
UUID는 상호 운용성의 기본입니다. 어떤 언어와 데이터베이스도 128비트 형식을 이해합니다. ULID는 같은 128비트를 Crockford base32 26글자로 표현하고, 시각이 앞에 오며 사전 순 정렬이 가능해 URL에 적합합니다. nanoid는 21글자 URL안전 랜덤 문자열로 충돌 내성은 UUID v4와 비슷하지만 라이브러리 풋프린트가 훨씬 작습니다. 시스템 간 주고받는 식별자라면 UUID, URL에 노출되는 짧은 ID라면 ULID나 nanoid가 합리적입니다.
관련 개념
UUID(Universally Unique Identifier)는 32자리 16진수와 하이픈 4개로 표현되는 128비트 값입니다(`xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx`). `M` 니블이 버전, `N` 니블이 배리언트를 나타내며 버전에 따라 최대 122비트가 페이로드로 남습니다. 형식은 RFC 4122(2005년)에서 처음 정해졌고 RFC 9562(2024년 5월)에서 갱신되어 v6·v7·v8이 도입되었습니다.
각 버전은 정렬 가능성·프라이버시·결정성 세 가지를 저울질합니다. **v1**(타임스탬프 + MAC)은 정렬 가능하지만 발행 호스트를 식별할 수 있습니다. **v3 / v5**(네임스페이스 + 이름의 해시, MD5 / SHA-1)는 결정론적이며 같은 입력에서 항상 같은 UUID가 나옵니다. 외부 식별자에서 안정적인 ID를 유도하고 싶을 때 유용합니다. **v4**(랜덤)는 프라이버시를 지키지만 정렬 불가능한 기본값이며, 이 도구는 이 v4를 생성합니다. **v6**은 v1의 타임스탬프를 바이트 순 정렬에 맞게 재배열한 것입니다. **v7**은 앞에 48비트 Unix밀리초 타임스탬프, 뒤에 랜덤 비트를 두며 현재 DB 기본 키 권장 형식입니다.
UUID는 인접한 두 아이디어의 중간에 위치합니다. 오토 인크리먼트 정수(`bigserial`·`AUTO_INCREMENT`)는 단일 코디네이터가 필요하고 레코드 수가 노출되지만 작고 정렬하기 좋습니다. 암호학적으로 랜덤한 토큰(`crypto.getRandomValues(32)` → base64url)은 UUID v4보다 엔트로피가 큽니다(256비트 대 122비트). 세션 쿠키나 비밀번호 재설정 링크에 적합한 선택입니다. UUID는 그 중간입니다. 분산 생성에 충분한 랜덤성, 모든 DB드라이버가 이해하는 표준 형식을 갖춘 반면, 보안 임계 토큰으로 쓰기에는 엔트로피가 부족합니다.