UUID 형식과 버전 차이 완벽 정리 - v1부터 v7까지 어떤 버전을 써야 할까
8-4-4-4-12 형식의 의미부터 버전 번호 읽는 법, v4와 v7의 결정적 차이까지. 데이터베이스 기본 키로 어떤 UUID를 써야 하는지 한 번에 정리했습니다.
개발을 하다 보면 로그 파일이나 데이터베이스에서 550e8400-e29b-41d4-a716-446655440000 같은 문자열을 하루에도 수십 번씩 마주칩니다. 대부분 UUID라는 건 알지만, 중간에 있는 숫자 하나가 버전을 뜻한다는 사실이나 버전마다 생성 원리가 완전히 다르다는 점은 의외로 모르는 분이 많습니다. UUID 형식과 버전 차이를 제대로 이해하면 데이터베이스 성능 문제까지 예방할 수 있습니다.
UUID란 무엇인가
UUID(Universally Unique Identifier)는 128비트 크기의 고유 식별자입니다. 중앙 서버에서 번호를 발급받지 않아도, 서로 다른 컴퓨터에서 각자 생성한 값이 사실상 겹치지 않도록 설계되어 있습니다. 분산 시스템에서 ID 충돌 걱정 없이 식별자를 만들 수 있다는 점이 핵심 가치입니다.
UUID 표준은 오랫동안 RFC 4122(2005년) 문서가 담당했습니다. 그러다 2024년 5월에 RFC 9562가 발표되면서 기존 표준을 대체했고, 이때 버전 6, 7, 8이 공식으로 추가되었습니다. 현재 UUID는 총 8개 버전이 정의되어 있습니다.
UUID 형식 구조 - 8-4-4-4-12의 의미
UUID는 16진수 32자리를 하이픈으로 나눠 8-4-4-4-12 형태, 총 36자로 표기합니다. 예시로 살펴보겠습니다.
550e8400-e29b-41d4-a716-446655440000
- 버전 번호: 세 번째 그룹의 첫 글자입니다. 위 예시에서는 41d4의 4, 즉 버전 4(랜덤 기반)라는 뜻입니다.
- 변형(variant) 비트: 네 번째 그룹의 첫 글자입니다. RFC 표준을 따르는 UUID는 이 자리에 8, 9, a, b 중 하나가 옵니다. 예시의 a716이 여기에 해당합니다.
- 나머지 자리: 버전에 따라 타임스탬프, 랜덤 값, 해시 값 등으로 채워집니다.
즉 처음 보는 UUID라도 세 번째 그룹 첫 글자만 확인하면 어떤 방식으로 생성되었는지 바로 알 수 있습니다. 이것이 UUID 형식과 버전 차이를 이해하는 첫걸음입니다.
UUID 버전별 차이 한눈에 보기
버전 1부터 5까지는 RFC 4122 시절부터 있던 클래식 버전입니다. 생성 재료가 무엇인지에 따라 성격이 완전히 달라집니다.
| 버전 | 생성 재료 | 특징 | 주 용도 |
|---|---|---|---|
| v1 | 타임스탬프 + MAC 주소 | 시간 정보 포함, MAC 노출 우려 | 레거시 시스템 |
| v2 | DCE 보안 정보 | 사실상 사용되지 않음 | 특수 환경 |
| v3 | 네임스페이스 + 이름의 MD5 해시 | 같은 입력이면 항상 같은 결과 | 결정적 ID 생성 |
| v4 | 난수 122비트 | 가장 널리 사용, 완전 무작위 | 범용 식별자 |
| v5 | 네임스페이스 + 이름의 SHA-1 해시 | v3의 개선판, 해시 충돌에 더 강함 | 결정적 ID 생성 |
v1 - 시간과 MAC 주소의 조합
버전 1은 1582년 10월 15일부터 흐른 시간을 100나노초 단위로 센 60비트 타임스탬프와 생성한 장비의 MAC 주소를 조합합니다. 생성 시점과 생성 장비를 역추적할 수 있어 개인정보 노출 이슈가 지적되어 왔습니다.
v3와 v5 - 같은 입력이면 같은 UUID
두 버전은 네임스페이스와 이름을 해시해서 만듭니다. 예를 들어 URL 네임스페이스에 example.com을 넣으면 언제 어디서 실행해도 항상 동일한 UUID가 나옵니다. v3는 MD5, v5는 SHA-1을 사용하며, 새로 도입한다면 v5가 권장됩니다.
v4 - 사실상의 표준
버전 4는 버전과 변형 비트 6비트를 제외한 122비트 전체를 난수로 채웁니다. 만들 수 있는 조합이 약 5.3 x 10^36개에 달해, 현실적인 규모에서 충돌 확률은 무시해도 될 수준입니다. 대부분의 언어와 프레임워크에서 기본 UUID 생성 함수가 v4입니다.
RFC 9562가 추가한 v6, v7, v8
v4는 완전 무작위라는 장점이 곧 단점이 됩니다. 값에 순서가 없어서 데이터베이스 인덱스가 조각나는 문제가 생기기 때문입니다. 새 버전들은 이 문제를 해결하기 위해 등장했습니다.
- v6: v1과 같은 재료를 쓰되 타임스탬프 비트 순서를 재배열해 시간순 정렬이 가능하도록 만든 버전입니다. v1 호환이 필요한 경우가 아니면 v7이 우선 권장됩니다.
- v7: 앞 48비트에 유닉스 밀리초 타임스탬프를 넣고 나머지 74비트를 난수로 채웁니다. 생성 시간순으로 자연스럽게 정렬되면서도 무작위성을 유지합니다.
- v8: 형식만 지키면 내용을 자유롭게 채울 수 있는 실험용, 커스텀용 버전입니다.
UUID 버전 선택의 본질은 무작위성과 정렬 가능성 사이의 균형입니다. v4는 무작위성에 전부를 걸었고, v7은 앞부분에 시간을 넣어 정렬 가능성을 확보했습니다. 데이터베이스 기본 키처럼 순서가 성능에 직결되는 자리라면 v7이 구조적으로 유리합니다.
실무에서 어떤 버전을 선택해야 할까
상황별로 정리하면 선택 기준은 명확합니다.
- 데이터베이스 기본 키: v7을 권장합니다. 시간순 정렬 덕분에 B-tree 인덱스 삽입이 순차적으로 일어나 성능 저하가 적습니다. PostgreSQL은 18 버전부터 uuidv7() 함수를 기본 제공합니다.
- 세션 토큰, 일회성 식별자: v4가 적합합니다. 생성 시간이 노출되지 않는 것이 오히려 장점입니다.
- 같은 입력에서 항상 같은 ID가 필요할 때: v5를 사용합니다. 외부 데이터를 반복 수집하면서 중복을 걸러내는 파이프라인에서 유용합니다.
- 신규 프로젝트에서 v1, v3: 특별한 호환성 요구가 없다면 선택할 이유가 없습니다.
실무 팁과 주의사항
UUID를 문자열 그대로 저장하면 36바이트, 바이너리로 저장하면 16바이트입니다. 1억 건 기준으로 단순 계산해도 문자열은 약 3.6GB, 바이너리는 약 1.6GB로 2배 이상 차이가 납니다. 인덱스까지 고려하면 격차는 더 벌어집니다. 이런 바이트 단위 용량 계산이 헷갈린다면 단위 변환기로 빠르게 확인할 수 있습니다.
또 하나 주의할 점은 v7의 타임스탬프 노출입니다. UUID 앞 48비트만 읽으면 레코드 생성 시각을 밀리초 단위로 알 수 있으므로, 생성 시간 자체가 민감 정보인 서비스라면 외부 노출용 ID는 v4로 분리하는 설계를 고려해야 합니다.
정리하면 두 가지만 기억하면 됩니다. 첫째, 지금 쓰는 시스템의 UUID 버전을 세 번째 그룹 첫 글자로 직접 확인해 보세요. 둘째, 새로 설계하는 테이블의 기본 키라면 v4 대신 v7 도입을 검토해 보세요. 이 작은 선택이 데이터가 쌓인 뒤의 인덱스 성능을 좌우합니다.
