UUID 형식과 버전 차이 완벽 정리 - 1부터 8까지 한눈에 이해하기
UUID 형식과 버전 차이가 헷갈리셨나요? 8-4-4-4-12 구조부터 v1, v4, v7까지 어떤 상황에 무엇을 써야 하는지 실무 기준으로 깔끔하게 정리했습니다.
![]()
회원 ID를 만들거나 주문 번호를 설계할 때 UUID를 한 번쯤 마주칩니다. 그런데 막상 라이브러리를 열어보면 uuid4(), uuid1(), 심지어 uuid7()까지 버전이 줄줄이 나옵니다. 무엇을 골라야 할지 막막하셨을 겁니다.
UUID 형식과 버전 차이를 제대로 알면 선택이 단순해집니다. 데이터베이스 성능, 보안, 정렬 가능 여부까지 버전 하나로 갈리기 때문입니다. 이 글에서 구조부터 버전별 특징까지 실무 기준으로 정리해 드립니다.
UUID가 정확히 무엇인가요
UUID는 Universally Unique Identifier의 약자입니다. 우리말로는 '범용 고유 식별자'입니다. 핵심은 128비트 크기의 숫자라는 점입니다. 이 값을 16진수로 표현한 것이 우리가 흔히 보는 36자리 문자열입니다.
가장 큰 장점은 중앙 서버 없이도 고유성을 보장한다는 데 있습니다. 여러 대의 서버가 동시에 ID를 만들어도 충돌할 확률이 사실상 0에 수렴합니다. 그래서 분산 시스템, 마이크로서비스, 오프라인 앱에서 널리 쓰입니다.
128비트는 약 3.4 곱하기 10의 38승 가지 조합을 만듭니다. 매초 10억 개씩 UUID를 생성해도 한 번 충돌하려면 수십억 년이 걸린다는 계산이 나옵니다. 실무에서 충돌은 걱정하지 않아도 되는 수준입니다.
표준은 오랫동안 RFC 4122가 기준이었고, 2024년 5월 이를 대체하는 RFC 9562가 발표되었습니다. v6, v7, v8은 이 새 표준에서 정식으로 추가된 버전입니다.
UUID 형식 구조 뜯어보기
UUID는 항상 8-4-4-4-12 패턴으로 끊어집니다. 하이픈 4개를 포함해 전체 36자입니다.
예시를 보겠습니다.
550e8400-e29b-41d4-a716-446655440000
여기서 그냥 무작위처럼 보이는 자리에도 의미가 숨어 있습니다. 두 자리가 특히 중요합니다.
- 버전 비트: 세 번째 그룹의 첫 글자입니다. 위 예시에서는
41d4의4이므로 버전 4입니다. - 변형(variant) 비트: 네 번째 그룹의 첫 글자입니다. 보통
8,9,a,b중 하나가 옵니다. RFC 표준 UUID라는 표시입니다.
00000000-0000-0000-0000-000000000000은 Nil UUID라고 부르며 '값 없음'을 뜻합니다. 반대로 모든 자리가 F인 Max UUID는 RFC 9562에서 새로 정의된 특수값입니다.대소문자는 구분하지 않습니다. A716과 a716은 같은 값입니다. 다만 출력할 때는 소문자가 표준 권장 방식입니다. 시스템 간 비교 시 한쪽으로 통일해 두는 편이 안전합니다.
UUID 버전별 차이 정리
버전마다 값을 만드는 방식이 완전히 다릅니다. 핵심을 표로 정리했습니다.
| 버전 | 생성 방식 | 정렬 가능 | 주요 용도 |
|---|---|---|---|
| v1 | 타임스탬프 + MAC 주소 | 부분적 | 시간순 추적, 레거시 시스템 |
| v2 | DCE 보안용 | 부분적 | 거의 사용 안 함 |
| v3 | 이름 + MD5 해시 | 불가 | 같은 입력에 같은 ID 필요 시 |
| v4 | 완전 무작위 | 불가 | 가장 보편적, 범용 |
| v5 | 이름 + SHA-1 해시 | 불가 | v3의 보안 강화판 |
| v6 | v1 재배열(시간 우선) | 가능 | v1 대체, DB 인덱스 |
| v7 | Unix 타임스탬프 + 무작위 | 가능 | 최신 권장, DB 기본키 |
| v8 | 커스텀/실험용 | 구현 따라 | 자체 규칙 설계 |
v1과 v4: 오래된 양대 축
v1은 시간과 기기의 MAC 주소를 섞습니다. 시간순 추적에 유리하지만 MAC 주소가 노출되어 보안에 약하다는 단점이 있습니다. v4는 122비트를 통째로 무작위로 채웁니다. 가장 단순하고 안전해서 지금도 압도적으로 많이 쓰입니다.
v3과 v5: 이름 기반 해시
같은 입력값을 넣으면 항상 같은 UUID가 나옵니다. 예를 들어 같은 도메인 이름을 넣으면 어디서 실행해도 동일한 ID가 생성됩니다. v3는 MD5, v5는 SHA-1을 씁니다. 보안이 중요하면 v5를 고르는 게 맞습니다.
v7: 요즘 가장 주목받는 버전
v7은 앞부분에 밀리초 단위 Unix 타임스탬프를 넣고 나머지를 무작위로 채웁니다. 그래서 생성 순서대로 정렬이 됩니다. 데이터베이스 기본키로 쓰면 인덱스 성능이 v4보다 크게 좋아집니다.
어떤 버전을 써야 할까
고민을 줄이는 기준은 의외로 명확합니다.
- 그냥 고유 ID가 필요하다: v4를 쓰세요. 모든 언어, 모든 라이브러리가 지원합니다.
- 데이터베이스 기본키로 쓴다: v7을 권장합니다. 정렬이 되어 인덱스 단편화가 줄어듭니다.
- 같은 입력에 같은 ID가 나와야 한다: v5를 쓰세요. 중복 데이터 식별에 유용합니다.
실무에서 데이터를 다루다 보면 UUID 외에도 자잘한 변환 작업이 끊이지 않습니다. 디자인 시스템 색상값을 HEX와 RGB 사이에서 바꿔야 할 때는 색상 변환기 같은 도구가 손이 빠르고, 제품 식별자를 라벨로 뽑아야 할 때는 바코드 생성기로 바로 만들어 쓰면 편합니다. UUID가 시스템 내부 식별자라면 바코드는 물리적 식별자라는 점에서 역할이 나뉩니다.
실무에서 자주 나오는 질문
UUID를 기본키로 쓰면 느리지 않나요
v4를 쓰면 무작위라 인덱스가 흩어져 쓰기 성능이 떨어질 수 있습니다. 하지만 v7을 쓰면 시간순 정렬이 되어 이 문제가 거의 사라집니다. 정수 자동증가 키만큼은 아니어도 충분히 실용적입니다.
UUID는 절대 중복되지 않나요
절대라는 말은 정확하지 않습니다. 확률이 무시할 수 있을 만큼 낮을 뿐입니다. v4 기준 충돌 확률은 현실적으로 0에 가깝습니다. 다만 난수 생성기가 제대로 된 것을 써야 합니다. 보안용 난수가 아닌 약한 난수를 쓰면 예측 위험이 생깁니다.
URL에 UUID를 그대로 노출해도 되나요
v4처럼 무작위 버전은 노출해도 추측이 어렵습니다. 하지만 v1, v6, v7은 생성 시각이 담겨 있어 언제 만들어졌는지 유추가 가능합니다. 민감한 데이터의 외부 식별자로는 v4가 더 안전합니다.
UUID 형식과 버전 차이를 이해했다면 다음은 실천입니다. 새 프로젝트라면 DB 기본키에 v7을 적용해 보고, 단순 식별자에는 v4를 유지하세요. 지금 쓰는 라이브러리가 v7을 지원하는지 한 번 확인해 두면, 다음 설계 결정이 훨씬 빨라집니다.