무료 UUID 생성기 - v1부터 v7까지 모든 버전 지원

UUID란 무엇인가요?

UUID(Universally Unique Identifier)는 컴퓨터 시스템에서 정보를 고유하게 식별하는 데 사용되는 128비트 식별자입니다. UUID는 RFC 4122에 따라 표준화되어 있으며, 방대한 엔트로피 덕분에 충돌 확률이 사실상 0에 가깝습니다. 즉, 독립적으로 생성된 두 개의 UUID는 거의 확실하게 고유합니다.

UUID의 표준 형식은 xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx이며, 여기서 각 x는 16진수 숫자(0-9, a-f)이고, M은 UUID 버전을, N은 변형을 나타냅니다.

UUID 버전

UUID v1 (타임스탬프 + MAC 주소)

UUID v1은 현재 타임스탬프와 임의의 값(브라우저에서는 MAC 주소 대신)을 기반으로 합니다. 1582년 10월 15일(그레고리력)부터 100나노초 간격으로 사용됩니다.

사용 사례:

  • UUID의 시간 순서 정렬이 필요한 경우
  • 디버깅 및 로깅 (UUID에 생성 시간 정보 포함)
  • 시간 동기화가 필요한 분산 시스템

예시: 6ba7b810-9dad-11d1-80b4-00c04fd430c8

장점:

  • 생성 시간 순서에 따라 UUID를 정렬할 수 있습니다
  • 감사 및 디버깅에 유용합니다
  • 타임스탬프 정보가 포함됩니다

단점:

  • 잠재적인 보안 위험 – 타임스탬프 정보 포함
  • 브라우저에서는 실제 MAC 주소가 포함되지 않습니다 (임의의 값으로 대체)
  • DB 지역성 불량 (타임스탬프가 하위 비트에 있음)

UUID v3 (MD5 해시)

UUID v3은 네임스페이스 UUID와 이름의 MD5 해시를 사용하여 생성됩니다. 확정적입니다 – 동일한 네임스페이스 + 이름은 항상 동일한 UUID를 생성합니다.

사용 사례:

  • URL, DNS 이름 또는 기타 식별자를 UUID로 변환
  • 재현 가능한 UUID가 필요한 경우
  • 다양한 식별 시스템 간의 매핑

예시: a3bb189e-8bf9-3888-9912-ace4e6543002

장점:

  • 확정적 (동일한 입력 = 동일한 출력)
  • 알려진 식별자 변환에 이상적
  • 다른 입력에 대해 충돌 없음

단점:

  • MD5는 구식 알고리즘입니다 (v5를 선호)
  • 네임스페이스와 이름이 필요합니다
  • 원본 입력을 되돌릴 수 없습니다

UUID v4 (랜덤) - 권장

가장 널리 사용되는 UUID 버전입니다. UUID v4는 암호학적으로 안전한 난수 생성기(crypto.getRandomValues())를 사용하여 순전히 무작위로 생성됩니다.

사용 사례:

  • 데이터베이스 기본 키
  • 세션 식별자 (session IDs)
  • 고유 파일 이름
  • API 토큰
  • 고유 ID가 보장되어야 하는 일반적인 목적

예시: f47ac10b-58cc-4372-a567-0e02b2c3d479

장점:

  • 최대 엔트로피 및 보안
  • 시간 또는 시스템 매개변수에 대한 의존성 없음
  • 가장 간단한 구현

충돌 확률: 초당 10억 개의 UUID를 100년 동안 생성할 경우 충돌 확률은 약 0.00000006%입니다.

UUID v5 (SHA-1 해시)

UUID v5는 v3과 동일하지만 MD5 대신 SHA-1을 사용합니다. v3의 더 현대적이고 안전한 대안입니다.

사용 사례:

  • v3과 동일하지만 더 나은 보안
  • 새 프로젝트에서 v3보다 선호
  • URL, DNS 이름, OID, X.500 DN에서 UUID 생성

예시: 886313e1-3b8a-5372-9b90-0c9aee199e5d

장점:

  • 확정적
  • SHA-1은 MD5보다 강력합니다
  • 시스템 간 매핑에 적합

단점:

  • SHA-1도 구식으로 간주됩니다 (그러나 MD5보다 안전)
  • 네임스페이스와 이름이 필요합니다

UUID v6 (정렬된 타임스탬프)

UUID v6은 더 나은 DB 인덱싱을 위해 시간 비트가 재정렬된 v1의 개선된 버전입니다. 데이터베이스의 지역성 문제를 해결하도록 설계되었습니다.

사용 사례:

  • 시간 순서 정렬이 필요한 데이터베이스 기본 키
  • 시간 순서 정렬과 DB 성능이 모두 필요한 시스템
  • v1의 현대적인 대안

예시: 1ec9414c-232a-6b00-b3c8-9e6bdeced846

장점:

  • v1보다 더 나은 DB 지역성 (타임스탬프가 상위 비트에 있음)
  • 시간 순서 정렬
  • UUID 표준과 호환

단점:

  • v1/v4보다 덜 사용됨
  • 여전히 시간 정보 포함 (보안 위험)

UUID v7 (유닉스 타임스탬프)

UUID v7은 유닉스 타임스탬프 (1970년 이후 밀리초) + 임의의 비트를 사용합니다. 최고의 DB 지역성을 가진 최신 UUID 버전입니다.

사용 사례:

  • 현대적인 데이터베이스 기본 키
  • 성능 + 시간 순서 정렬이 필요한 시스템
  • 새 프로젝트에서 v1/v6 대체

예시: 017f22e2-79b0-7cc3-98c4-dc0c0c07398f

장점:

  • 모든 버전 중 최고의 DB 지역성
  • 유닉스 타임스탬프는 표준입니다
  • 무작위성과 시간 순서 정렬의 장점 결합

단점:

  • 비교적 새로운 사양 (RFC 4122bis)
  • 레거시 시스템에서 지원이 적음

어떤 UUID 버전을 사용해야 할까요?

선택 가이드

최대 보안 및 무작위성이 필요하신가요?UUID v4를 사용하세요 (가장 일반적인 선택)

시간 순서 정렬 및 DB 성능이 필요하신가요?UUID v7 (현대적) 또는 UUID v6 (표준)을 사용하세요

기존 식별자로부터 재현 가능한 UUID가 필요하신가요?UUID v5 (SHA-1) 또는 UUID v3 (MD5, 레거시)를 사용하세요

타임스탬프 및 감사 추적이 필요하신가요?UUID v1 (레거시, DB 성능 나쁨)을 사용하세요

데이터베이스

새 프로젝트의 경우: UUID v7 또는 v4

  • v7은 시간 순서 정렬 + 성능에 이상적입니다
  • v4는 시간 정보 없이 최대 무작위성을 제공합니다

레거시 시스템의 경우: UUID v1 또는 v6

  • v6는 v1보다 더 나은 DB 지역성을 가집니다
  • v1은 널리 지원됩니다

기본 키로서 UUID의 장점:

  • 전역 고유성 – 다른 데이터베이스의 데이터를 충돌 없이 병합할 수 있습니다
  • 보안 – 순차 ID(1, 2, 3…)와 달리 다음 값을 추측할 수 없습니다
  • 분산 시스템 – 여러 서버에서 조정 없이 독립적으로 UUID를 생성할 수 있습니다
  • 데이터베이스 병합 – 두 데이터베이스를 병합할 때 충돌이 발생하지 않습니다

단점:

  • 더 큰 크기 (정수형의 경우 4-8바이트 대 16바이트)
  • 일부 데이터베이스에서 더 느린 인덱싱 (더 나은 성능을 위해 v6/v7 사용)
  • 사람에게 덜 읽기 쉬움

API 및 웹 서비스

  • REST API – 리소스에 대한 고유 식별자
  • GraphQL – 노드에 대한 전역 식별자
  • 웹훅 – 요청 및 응답 추적
  • 토큰 – 세션 ID, 새로 고침 토큰

파일 및 스토리지

  • 파일 이름 – 업로드 시 충돌 방지
  • S3/클라우드 스토리지 – 객체에 대한 고유 경로
  • 캐시 키 – 캐시 시스템의 식별자

프론트엔드 애플리케이션

  • React/Vue 컴포넌트 – 목록에 대한 고유 키
  • 임시 ID – 데이터베이스에 저장하기 전 ID
  • 로컬 스토리지 – 저장된 데이터의 키
  • 오프라인 우선 애플리케이션 – 서버 연결 없이 ID 생성

고급 생성기 기능

사용자 지정 시간으로 UUID 생성

시간 기반 버전(v1, v6, v7)의 경우, 날짜-시간 선택기를 사용하여 임의의 타임스탬프를 선택할 수 있습니다. 이는 다음 상황에 유용합니다:

테스트:

  • 과거에 생성된 UUID 시뮬레이션
  • 데이터베이스에서 시간 순서 정렬 테스트
  • 디버깅을 위한 UUID 재현

데이터 마이그레이션:

  • 과거 타임스탬프를 가진 UUID 생성
  • 올바른 타임스탬프 값을 가진 데이터 백필
  • 다른 시간대의 데이터 가져오기

감사 및 규정 준수:

  • 레코드 생성 시간에 따른 UUID 재구성
  • 소급 식별자 생성

사용 예시:

  1. v1, v6 또는 v7 버전을 선택합니다
  2. 날짜-시간 선택기를 사용하여 날짜와 시간을 설정합니다
  3. 사용자 지정 타임스탬프로 UUID를 생성합니다

해시 기반 UUID (v3, v5)

확정적 UUID의 경우 v3 (MD5) 또는 v5 (SHA-1) 버전을 사용할 수 있습니다:

사용 방법:

  1. 식별자 유형에 따라 네임스페이스를 선택합니다
  2. 이름/값을 입력합니다
  3. UUID를 생성합니다

예시:

네임스페이스이름 (입력)사용 사례
DNSexample.com도메인 이름을 UUID로 변환
DNSgoogle.com각 웹 사이트는 고유한 UUID를 가집니다
URLhttps://example.com/pageURL을 UUID로 변환
URLhttps://api.example.com/users/123API 엔드포인트를 UUID로
OID1.3.6.1.4.1.343객체 식별자를 UUID로
X.500CN=John Doe,O=Company고유 이름을 UUID로

중요 특징:

  • 확정적: 동일한 입력 = 항상 동일한 UUID
  • 재현 가능: 언제든지 UUID를 다시 생성할 수 있습니다
  • 일관성: 다른 시스템 간에도 동일한 UUID
  • 디코딩 불가: UUID에서 원본 이름을 되돌릴 수 없습니다
  • ℹ️ 하나의 UUID: v3/v5의 경우 항상 하나의 UUID만 생성됩니다 (동일한 입력 = 동일한 출력)

실제 사용:

// 예시: URL을 UUID v5로 변환
Namespace: URL
이름: https://example.com/api/users/123
결과: 886313e1-3b8a-5372-9b90-0c9aee199e5d

// 동일한 입력 = 항상 동일한 UUID
Namespace: DNS
이름: google.com
결과: google.com에 대해 항상 동일한 UUID

UUID를 안전하게 사용하는 방법?

암호학적 보안

저희 생성기는 crypto.getRandomValues()를 사용하며, 이는 암호학적으로 안전한 난수 생성기입니다. 예측 가능하고 보안 목적에 부적합한 Math.random()과 달리, crypto.getRandomValues()는 다음 용도에 적합한 실제 엔트로피를 제공합니다:

  • 보안 토큰 생성
  • 세션 ID
  • API 키
  • 암호화 애플리케이션

UUID 버전 비교

버전기반충돌시간 정렬DB 성능사용
v1타임스탬프 + MAC낮음✅ 예❌ 나쁨레거시, 감사
v3MD5 해시없음 (확정적)❌ 아니요⚠️ 보통변환 (레거시)
v4랜덤매우 낮음❌ 아니요⚠️ 보통일반 용도
v5SHA-1 해시없음 (확정적)❌ 아니요⚠️ 보통변환 (권장)
v6정렬된 타임스탬프낮음✅ 예✅ 좋음시간 기반 현대 DB
v7유닉스 타임스탬프낮음✅ 예✅ 최상새 프로젝트

UUID와 다른 식별자 비교

유형크기충돌시간 정렬사용
자동 증가 ID4-8바이트테이블 내에서 고유 보장간단한 애플리케이션, 로컬 DB
UUID v416바이트사실상 불가능분산 시스템, API
UUID v716바이트사실상 불가능성능이 좋은 현대 DB
ULID16바이트사실상 불가능UUID + 사전식 정렬
Snowflake ID8바이트올바른 구성 시 고유 보장Twitter, 분산 시스템
NanoID구성 가능길이에 따라 다름URL 친화적 ID

다양한 언어에서의 구현

JavaScript/TypeScript

// UUID v4 - 가장 간단한 방법 (최신 브라우저)
const uuid = crypto.randomUUID();

// UUID v4 - 수동 구현
function generateUUIDv4() {
  return 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, (c) => {
    const r = (crypto.getRandomValues(new Uint8Array(1))[0] & 0x0f) >> (c === 'x' ? 0 : 2);
    const v = c === 'x' ? r : (r & 0x3) | 0x8;
    return v.toString(16);
  });
}

// UUID v7 - 데이터베이스에 권장
function generateUUIDv7() {
  const timestamp = Date.now();
  const timeHi = (timestamp >> 16).toString(16).padStart(8, '0');
  const timeLow = (timestamp & 0xFFFF).toString(16).padStart(4, '0');

  const randomBytes = crypto.getRandomValues(new Uint8Array(10));
  const randomHex = Array.from(randomBytes)
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');

  return `${timeHi}-${timeLow}-7${randomHex.substr(0, 3)}-${randomHex.substr(3, 4)}-${randomHex.substr(7)}`;
}

Python

import uuid

# UUID v4
uuid_v4 = str(uuid.uuid4())
# Output: '6ba7b810-9dad-11d1-80b4-00c04fd430c8'

# UUID v1
uuid_v1 = str(uuid.uuid1())

Java

import java.util.UUID;

// UUID v4
String uuidV4 = UUID.randomUUID().toString();

PHP

// UUID v4 (PHP 7+)
function generateUUID() {
    return sprintf('%04x%04x-%04x-%04x-%04x-%04x%04x%04x',
        mt_rand(0, 0xffff), mt_rand(0, 0xffff),
        mt_rand(0, 0xffff),
        mt_rand(0, 0x0fff) | 0x4000,
        mt_rand(0, 0x3fff) | 0x8000,
        mt_rand(0, 0xffff), mt_rand(0, 0xffff), mt_rand(0, 0xffff)
    );
}

C#

using System;

// UUID v4
Guid uuid = Guid.NewGuid();
string uuidString = uuid.ToString();

모범 사례

데이터베이스에 UUID 저장

PostgreSQL:

CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

MySQL 8.0+:

CREATE TABLE users (
    id BINARY(16) PRIMARY KEY DEFAULT (UUID_TO_BIN(UUID())),
    email VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

팁: MySQL에서는 공간 절약 및 더 빠른 인덱싱을 위해 CHAR(36) 대신 BINARY(16)으로 UUID를 저장하세요.

UUID 유효성 검사

function isValidUUID(uuid) {
  const regex = /^[0-9a-f]{8}-[0-9a-f]{4}-[1-5][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;
  return regex.test(uuid);
}

UUID 변환

// 하이픈 제거
const compact = uuid.replace(/-/g, '');

// 하이픈 다시 추가
function formatUUID(compactUuid) {
  return [
    compactUuid.substring(0, 8),
    compactUuid.substring(8, 12),
    compactUuid.substring(12, 16),
    compactUuid.substring(16, 20),
    compactUuid.substring(20, 32)
  ].join('-');
}

문제 해결 (Troubleshooting)

UUID v3/v5 작동하지 않음

문제: v3 또는 v5를 선택한 후 아무것도 생성되지 않습니다

해결책:

  1. ‘이름’ 필드를 채웠는지 확인하세요 - 필수입니다!
  2. ✅ 입력 유형에 따라 올바른 네임스페이스를 선택하세요
  3. ✅ 유효한 입력 예시:
    • DNS: example.com, google.com
    • URL: https://example.com/page
    • 모든 텍스트: my-application-v1

팁: 먼저 test와 같은 간단한 값과 DNS 네임스페이스를 시도해 보세요.

시간 기반 UUID (v1, v6, v7)에 이상한 시간이 표시됨

문제: 생성된 UUID에 예상치 못한 타임스탬프가 있습니다

해결책:

  1. ✅ 날짜-시간 선택기를 확인하세요 - 올바른 시간이 설정되어 있나요?
  2. ✅ 날짜-시간 선택기는 로컬 시간대를 사용합니다
  3. ✅ 현재 시간을 사용하려면 날짜-시간 선택기를 비워두세요

UUID를 복사할 수 없음

문제: ‘모두 복사’ 버튼이 작동하지 않습니다

해결책:

  1. ✅ UUID를 생성했는지 확인하세요 (비어 있지 않은지)
  2. ✅ 일부 브라우저는 클립보드 API에 HTTPS를 요구합니다
  3. ✅ 또는 텍스트 영역에서 텍스트를 선택하고 수동으로 복사하세요 (Ctrl+C)

자주 묻는 질문 (FAQ)

UUID 충돌이 발생할 수 있나요? 이론적으로는 가능하지만, 그 확률은 천문학적으로 낮습니다. 초당 10억 개의 UUID v4를 100년 동안 생성할 경우 충돌 확률은 약 0.00000006%입니다. 실제로는 충돌이 거의 발생하지 않습니다.
UUID가 데이터베이스의 기본 키로 적합한가요? 사용 사례에 따라 다릅니다. UUID는 분산 시스템 및 전역 고유성이 필요한 상황에 이상적입니다. 단일 데이터베이스를 사용하는 간단한 애플리케이션의 경우 자동 증가 ID가 더 효율적일 수 있습니다.
이 도구로 생성된 UUID는 안전한가요? 예, 암호학적으로 안전한 난수 값을 제공하는 웹 크립토 API(`crypto.getRandomValues()`)를 사용합니다. 모든 과정은 브라우저에서 로컬로 진행됩니다.
UUID 버전 간의 차이점은 무엇인가요? - **v1**: 타임스탬프 + MAC/랜덤 - 시간 순서 정렬, DB 성능 나쁨 - **v3/v5**: 해시 기반 - 확정적, 알려진 식별자 변환용 - **v4**: 랜덤 - 가장 안전하고 널리 사용됨 - **v6**: 재정렬된 타임스탬프 - v1보다 더 나은 DB 성능 - **v7**: 유닉스 타임스탬프 - 최고의 DB 성능 + 시간 순서 정렬
어떤 UUID 버전을 사용해야 하나요? 대부분의 경우 **v4** (랜덤)를 사용하세요. 시간 순서 정렬이 필요한 데이터베이스의 경우 **v7** (현대적) 또는 **v6** (표준)을 사용하세요. 알려진 식별자 (URL, DNS) 변환용으로는 **v5** (SHA-1)를 사용하세요.
UUID를 토큰 및 API 키로 사용할 수 있나요? UUID v4는 세션 ID 및 유사 토큰에 적합합니다. API 키의 경우 더 긴 임의 문자열 (예: 256비트 값) 또는 특수 라이브러리 사용을 고려하세요.
UUID의 크기는 얼마인가요? UUID는 128비트 (16바이트)입니다. 하이픈이 있는 문자열 형식으로는 36자리를 차지합니다. 하이픈이 없으면 32개의 16진수 문자입니다.

UUID 대안

ULID (Universally Unique Lexicographically Sortable Identifier)

  • 128비트 ID (UUID와 동일)
  • 생성 시간에 따라 사전식으로 정렬 가능
  • 더 간결한 표현 (36자리 대신 26자리)
  • 대소문자를 구분하지 않는 base32 인코딩

예시: 01ARZ3NDEKTSV4RRFFQ69G5FAV

NanoID

  • UUID보다 작은 크기 (표준 21자리)
  • URL 친화적 (특수 문자 없음)
  • 더 빠른 생성
  • 길이 및 알파벳 구성 가능

예시: V1StGXR8_Z5jdHi6B-myT

Snowflake ID (Twitter)

  • 64비트 ID (UUID보다 작음)
  • 시간 순서 정렬 가능
  • 워커 ID 및 시퀀스 번호 포함
  • 중앙 집중식 구성 필요

예시: 1234567890123456789

성능 및 최적화

생성 속도

저희 생성기는 다음을 생성할 수 있습니다:

  • 1 UUID: < 1 ms
  • 100 UUID: ~10-20 ms
  • 1000 UUID: ~100-200 ms

성능 팁

  1. 배치 생성 – 많은 UUID가 필요한 경우 하나씩 대신 한 번에 생성하세요
  2. DB 저장 – 빠른 검색을 위해 UUID 열에 인덱스를 만드세요
  3. 압축 – UUID를 문자열 (36바이트) 대신 이진 형식 (16바이트)으로 저장하세요
  4. 캐싱 – 경우에 따라 UUID를 미리 생성하여 캐싱할 수 있습니다

개발자를 위한 정보

UUID v4 구조

xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx
|        |    |    |    |
|        |    |    |    └─ 48비트 임의 데이터 (노드)
|        |    |    └────── 16비트 임의 데이터와 변형 (clock_seq)
|        |    └─────────── 12비트 임의 데이터 + 4비트 버전 (time_hi_and_version)
|        └──────────────── 16비트 임의 데이터 (time_mid)
└───────────────────────── 32비트 임의 데이터 (time_low)
  • 버전 (4비트): 항상 0100 (이진) = 4 (16진수)
  • 변형 (2-3비트): RFC 4122의 경우 항상 10 (이진)

UUID 테스트

// Jest 테스트
describe('UUID Generator', () => {
  test('generates valid UUID v4', () => {
    const uuid = generateUUIDv4();
    const regex = /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;
    expect(regex.test(uuid)).toBe(true);
  });

  test('generates unique UUIDs', () => {
    const uuid1 = generateUUIDv4();
    const uuid2 = generateUUIDv4();
    expect(uuid1).not.toBe(uuid2);
  });
});

보안 측면

UUID로 하지 말아야 할 것

민감한 애플리케이션에 UUID v1을 사용하지 마세요 – 타임스탬프가 포함되어 보안 위험이 될 수 있습니다

UUID 생성에 Math.random()을 사용하지 마세요 – 암호학적으로 안전하지 않습니다

권한 부여를 위해 UUID에 의존하지 마세요 – UUID는 추측될 수 있습니다 (확률은 매우 낮지만)

암호화 없이 쿠키에 UUID를 저장하지 마세요 – 서명된 쿠키 또는 JWT를 사용하세요

해야 할 것

대부분의 경우 UUID v4를 사용하세요 – 최고의 엔트로피와 보안

UUID를 다른 보안 조치와 결합하세요 – 세션 관리에는 HTTPS, HttpOnly 쿠키, 짧은 만료 시간을 사용하세요

서버에서 UUID 유효성 검사를 수행하세요 – 항상 UUID의 형식과 버전을 확인하세요

암호학적으로 안전한 난수 소스를 사용하세요 – 브라우저에서는 crypto.getRandomValues(), Linux에서는 /dev/urandom

흥미로운 사실

  • 가능한 UUID v4의 수: 2^122 ≈ 5.3 × 10^36 (340 운데실리온)
  • 50% 충돌 확률에 필요한 UUID 수: 2.71 × 10^18 (2.71 퀸틸리언)개의 UUID를 생성해야 합니다
  • 모든 가능한 UUID의 크기: 각 UUID를 16바이트로 저장한다면, 전체 공간은 85 제타바이트 (850억 테라바이트)를 차지할 것입니다
  • 기원: UUID는 1990년 DCE(Distributed Computing Environment)의 일부로 표준화되었습니다