UUID 생성기 - 고유 식별자 UUID v4/v7 생성과 활용 완벽 가이드
전 세계적으로 유일한 식별자 UUID의 원리, 버전별 차이, 데이터베이스 기본 키 활용까지 개발자 필수 지식을 총정리합니다.
UUID란 무엇인가?
UUID(Universally Unique Identifier)는 전 세계적으로 고유한 128비트(16바이트) 식별자입니다. UUID 생성기를 사용하면 중앙 관리 서버 없이도 충돌 확률이 사실상 0에 가까운 고유 ID를 즉시 생성할 수 있습니다.
UUID의 핵심 가치는 분산 환경에서의 고유성입니다. 수십 대의 서버가 동시에 UUID를 생성해도 같은 값이 나올 확률은 천문학적으로 낮습니다. UUID v4 기준으로 약 5.3 × 10^36개의 가능한 값이 존재하며, 매초 10억 개씩 생성해도 중복이 발생할 확률이 50%가 되려면 약 850억 년이 걸립니다.
UUID vs GUID
GUID(Globally Unique Identifier)는 Microsoft가 사용하는 용어로, 기술적으로 UUID와 동일합니다. Windows 환경에서는 GUID, 그 외에서는 UUID라고 부르는 것이 일반적입니다.
UUID의 구조와 형식
표준 형식
UUID는 32개의 16진수 문자를 하이픈으로 구분한 5개 그룹으로 표현됩니다: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. 예시: 550e8400-e29b-41d4-a716-446655440000.
| 그룹 | 길이 | 의미 |
|---|---|---|
| 1번째 (8자) | 32비트 | time-low (v1) 또는 랜덤 |
| 2번째 (4자) | 16비트 | time-mid (v1) 또는 랜덤 |
| 3번째 (4자) | 16비트 | 버전(M) + time-high 또는 랜덤 |
| 4번째 (4자) | 16비트 | 변형(N) + clock-seq 또는 랜덤 |
| 5번째 (12자) | 48비트 | 노드(MAC) 또는 랜덤 |
버전과 변형 식별
3번째 그룹의 첫 문자(M)가 UUID 버전을 나타냅니다. 4번째 그룹의 첫 문자(N)가 변형을 나타냅니다. 예: 550e8400-e29b-41d4-a716-446655440000에서 4는 v4, a는 RFC 4122 변형입니다.
UUID 버전별 비교
| 버전 | 생성 기반 | 정렬 가능 | 프라이버시 | 주요 용도 |
|---|---|---|---|---|
| v1 | 타임스탬프 + MAC 주소 | 부분적 | MAC 노출 위험 | 레거시 시스템 |
| v3 | 네임스페이스 + MD5 해시 | 불가 | 안전 | 동일 이름 → 동일 UUID |
| v4 | 완전 무작위(122비트) | 불가 | 안전 | 가장 범용적 사용 |
| v5 | 네임스페이스 + SHA-1 해시 | 불가 | 안전 | 결정적 UUID 필요 시 |
| v7 | Unix 밀리초 + 랜덤 | 시간순 정렬 가능 | 안전 | DB 기본 키(최신 추천) |
UUID v4 - 가장 널리 사용되는 버전
UUID v4는 122비트의 랜덤 데이터로 생성되어 가장 간단하고 널리 사용됩니다. 중앙 서버, MAC 주소, 타임스탬프 없이 어디서든 생성할 수 있습니다. UUID v4 생성기에서 즉시 만들어보세요.
UUID v7 - 차세대 표준
2024년 RFC 9562에서 표준화된 UUID v7은 상위 48비트에 Unix 밀리초 타임스탬프를 포함합니다. 이로 인해 시간순 정렬이 가능하여 데이터베이스 B-tree 인덱스에서 삽입 성능이 v4보다 크게 향상됩니다.
UUID 생성기 사용법
단일 UUID 생성
생성 버튼을 클릭하면 즉시 UUID가 생성됩니다. 기본적으로 v4가 생성되며, 결과를 클립보드에 복사하여 사용합니다.
대량 UUID 생성
한 번에 수십~수백 개의 UUID를 생성할 수 있습니다. 테스트 데이터 준비, 마이그레이션 스크립트 작성, 대량 레코드 삽입 등에 유용합니다.
UUID 검증
기존 UUID 문자열이 올바른 형식인지 검증하고, 어떤 버전인지 식별할 수 있습니다. 잘못된 형식의 UUID는 시스템 오류의 원인이 될 수 있으므로 검증이 중요합니다.
실무 활용 사례
데이터베이스 기본 키(Primary Key)
자동 증가 정수(auto-increment) 대신 UUID를 기본 키로 사용하면 여러 서버에서 독립적으로 레코드를 생성해도 키 충돌이 발생하지 않습니다. 마이크로서비스, 분산 데이터베이스, 데이터 병합 등에서 특히 유용합니다.
API 요청 추적(Request ID)
각 API 요청에 UUID를 부여하면 로그에서 특정 요청의 전체 흐름을 추적할 수 있습니다. 마이크로서비스 간 호출 체인을 추적하는 분산 트레이싱의 기본 요소입니다.
파일 고유 이름 생성
사용자가 업로드한 파일에 UUID 이름을 부여하면 파일명 충돌을 방지하고, 원본 파일명에 포함된 특수문자나 한글로 인한 문제를 예방합니다.
세션 ID 및 토큰
사용자 세션 식별, 일회용 링크(비밀번호 재설정, 이메일 인증), 임시 접근 토큰 등에 UUID를 사용하면 예측 불가능한 고유한 값을 보장합니다.
데이터베이스에서의 UUID
UUID vs Auto-Increment 비교
| 항목 | UUID | Auto-Increment |
|---|---|---|
| 고유성 범위 | 전역(서버 간) | 테이블 내 |
| 분산 생성 | 가능 | 불가 (중앙 관리 필요) |
| 예측 가능성 | 불가능 | 쉽게 예측 가능 |
| 저장 크기 | 16바이트 | 4~8바이트 |
| 인덱스 성능 | v4: 낮음 / v7: 높음 | 높음 |
| URL 노출 시 위험 | 낮음 | 높음 (순차 접근 가능) |
DB별 UUID 타입
PostgreSQL은 UUID 네이티브 타입을 제공하여 16바이트로 효율적으로 저장합니다. MySQL 8.0+에서는 UUID_TO_BIN() 함수로 BINARY(16)에 저장하는 것이 권장됩니다. 고유 식별자 생성기로 테스트 데이터용 UUID를 대량 생성할 수 있습니다.
UUID v7을 DB 키로 추천하는 이유
UUID v4는 완전 무작위이므로 B-tree 인덱스에서 랜덤 위치에 삽입되어 페이지 분할이 빈번합니다. UUID v7은 시간순으로 증가하므로 인덱스 끝에 순차 삽입되어 auto-increment에 가까운 성능을 보이면서도 분산 생성이 가능합니다.
자주 묻는 질문
Q. UUID가 절대 충돌하지 않나요?
이론적으로 충돌 가능성은 0이 아니지만, 실질적으로 불가능합니다. UUID v4 기준으로 103조 개를 생성했을 때 충돌 확률이 10억분의 1입니다. 이는 운석에 맞을 확률보다 낮습니다.
Q. UUID에서 하이픈을 빼도 되나요?
하이픈은 가독성을 위한 것으로, 제거해도 기능상 문제는 없습니다. 저장 공간을 아끼려면 하이픈 없이 32자로 저장하거나, 바이너리 16바이트로 저장할 수 있습니다.
Q. UUID를 URL에 사용해도 되나요?
네, UUID는 URL에 안전한 문자(영문, 숫자, 하이픈)로만 구성되어 있어 URL에 직접 사용할 수 있습니다. 예: /users/550e8400-e29b-41d4-a716-446655440000.
Q. UUID가 너무 길어서 불편합니다. 짧은 대안이 있나요?
NanoID(21자), ULID(26자), KSUID(27자), ShortUUID(22자) 등이 대안입니다. 다만 이들은 UUID 표준(RFC)이 아니므로 호환성을 고려해야 합니다.
