데이터베이스에 사용자 ID를 1, 2, 3 순서로 넣고 있었는데, 분산 서버를 도입하면서 문제가 생겼다. 두 서버가 동시에 같은 번호를 만들어낸 것이다. 순차적 번호가 아닌 전 세계에서 겹치지 않는 고유 식별자가 필요했고, 그게 UUID다.
UUID 기본 구조
UUID(Universally Unique Identifier)는 128비트 길이의 식별자다. 보통 하이픈으로 구분된 32자리 16진수로 표기한다.
550e8400-e29b-41d4-a716-4466554400008-4-4-4-12 자리로 나뉘고, 전체 경우의 수는 약 3.4 × 10^38개다. 지구상의 모래알 수보다 많으니, 무작위로 생성해도 충돌 확률은 사실상 0에 가깝다.
버전별 차이
| 버전 | 생성 방식 | 특징 |
|---|---|---|
| v1 | 타임스탬프 + MAC 주소 | 생성 시각을 역추적 가능, 프라이버시 문제 |
| v3 | MD5 해시 (이름 기반) | 같은 입력이면 같은 UUID 출력 |
| v4 | 완전 랜덤 | 가장 많이 쓰임, 충돌 확률 극히 낮음 |
| v5 | SHA-1 해시 (이름 기반) | v3보다 해시 강도 높음 |
| v7 | 타임스탬프 + 랜덤 | 시간순 정렬 가능, DB 인덱싱에 유리 |
실무에서 가장 많이 쓰는 건 v4다. 암호학적 난수 생성기를 사용하므로 예측이 불가능하고, 별도 서버 없이 클라이언트에서도 생성할 수 있다.
어디에 쓰이나
- 데이터베이스 Primary Key: 분산 환경에서 ID 충돌 없이 레코드 생성
- API 요청 추적: 각 요청에 UUID를 붙여 로그 추적 (Request ID)
- 파일명 생성: 업로드된 파일에 고유 이름을 부여해 덮어쓰기 방지
- 세션 토큰: 사용자 세션을 식별하는 고유값
- 메시지 큐: Kafka, RabbitMQ에서 메시지 중복 처리 방지
UUID 형식 옵션
상황에 따라 하이픈을 빼거나 중괄호를 붙여야 할 때가 있다.
- 기본 형식
550e8400-e29b-41d4-a716-446655440000(표준, RFC 4122)- 하이픈 제거
550e8400e29b41d4a716446655440000(DB 저장 시 용량 절약)- 중괄호 형식
{550e8400-e29b-41d4-a716-446655440000}(Windows GUID 표기)- URN 형식
urn:uuid:550e8400-e29b-41d4-a716-446655440000(RFC 규격 참조용)
테스트 데이터를 만들거나 개발 중에 빠르게 UUID가 필요할 때는 UUID 생성기에서 형식을 선택하고 원하는 개수만큼 한꺼번에 뽑으면 된다. 최대 1,000개까지 대량 생성이 되고, 텍스트 파일로 다운로드도 가능하다.
자주 묻는 질문
UUID와 GUID는 다른 건가요?
본질적으로 같다. GUID(Globally Unique Identifier)는 마이크로소프트가 쓰는 용어이고, UUID는 RFC 4122 표준 명칭이다. 형식과 생성 방식 모두 동일하다.
UUID를 DB Primary Key로 쓰면 성능이 떨어지나요?
v4 UUID는 랜덤이라 B-Tree 인덱스에서 삽입 성능이 떨어질 수 있다. 이게 신경 쓰인다면 시간순 정렬이 가능한 v7이나 ULID를 고려해볼 만하다. 다만 대부분의 서비스 규모에서는 v4로도 체감할 만한 성능 차이가 없다.
UUID v4가 중복될 확률은 얼마나 되나요?
1초에 10억 개씩 생성해도 중복이 발생하려면 약 85년이 걸린다. 실무에서 UUID 충돌을 걱정할 필요는 없다.
고유 식별자가 필요한 순간은 개발하다 보면 수시로 온다. 원리를 이해해두면 버전 선택이나 형식 결정에서 헤매지 않는다.