UUID 네 번째 그룹 첫 글자, 아무도 안 보는 그 한 글자의 의미

가이드 · 2026.08.21 최종 확인

UUID를 볼 때 대부분은 32자리 16진수 덩어리를 통째로 "고유한 무작위 문자열"로만 인식합니다. 하지만 550e8400-e29b-41d4-a716-446655440000처럼 하이픈으로 나뉜 세 번째 그룹의 첫 글자와 네 번째 그룹의 첫 글자는 무작위가 아닙니다. 이 두 자리는 RFC 4122 표준이 의도적으로 예약해 둔 메타데이터 비트이고, 이 글자만 읽어도 그 UUID가 몇 번 버전으로 만들어졌는지, 표준을 따르는 값인지 즉시 판별할 수 있습니다.

1. 세 번째 그룹 첫 글자: 버전 번호

UUID는 8-4-4-4-12 형식으로 하이픈이 4개 들어간 32자리 16진수입니다. 이 중 세 번째 그룹(4자리)의 첫 글자는 항상 UUID 버전을 나타내도록 설계되어 있습니다. 값은 1부터 5까지이며, 각각 생성 방식이 다릅니다.

즉 UUID 문자열에서 15번째 문자(하이픈 포함 인덱스 기준)만 떼어 봐도 "이건 v4구나" 하고 바로 알 수 있습니다. 실제로 UUID 변환기의 분석 로직도 정확히 이 원리로 동작합니다 — 입력값의 15번째 문자가 1~5 범위인지 확인해서 버전을 표시하고, 범위를 벗어나면 억지로 추측하지 않고 "Unknown"이라고 정직하게 표시합니다.

2. 네 번째 그룹 첫 글자: variant(변형) 비트

버전보다 훨씬 덜 알려진 것이 네 번째 그룹의 첫 글자, 즉 variant 비트입니다. 이 자리는 하나의 16진수 문자(4비트)지만, 그중에서도 상위 2~3비트만 의미를 가지는 구조입니다. RFC 4122가 정의하는 표준 variant는 이진수로 10xx 패턴(맨 앞 두 비트가 1, 0)을 요구하며, 이 패턴에 해당하는 16진수 문자는 8, 9, a, b 네 가지뿐입니다.

UUID 변환기는 이 판별도 정확히 코드로 구현되어 있습니다 — 네 번째 그룹 첫 글자를 16진수 정수로 파싱해 8 미만이면 NCS, 12(0xc) 미만이면 RFC 4122, 14(0xe) 미만이면 Microsoft, 그 이상이면 예약됨으로 분류합니다. 단 한 가지 예외가 있는데, 모든 비트가 0인 NIL UUID(00000000-0000-0000-0000-000000000000)는 RFC 4122가 별도로 정의한 특수값이라 이 도구는 variant 자리에 일반 규칙을 적용하지 않고 "—"로 표시합니다.

3. 두 글자로 UUID를 감별하는 실전 예시

다음 표는 같은 자리처럼 보이지만 전혀 다른 정보를 담은 UUID 3개를 비교한 예시입니다.

세 번째 예시처럼 버전 자리가 6이나 7, 8처럼 1~5 범위를 벗어나면 그 UUID는 이 도구가 다루는 RFC 4122 v1~v5 규격 밖의 값입니다. 실무에서는 이런 값이 최신 규격(정렬 가능한 UUID v7 등)이거나, 혹은 UUID가 아닌 다른 랜덤 문자열이 UUID 형식에 우연히 맞아떨어진 경우일 수 있으므로, 버전란이 Unknown으로 뜬다면 원본 데이터 소스를 다시 확인하는 것이 좋습니다.

4. 이 지식이 실제로 쓸모 있는 순간

• 디버깅: 로그에 찍힌 UUID가 세션 토큰인지 DB 기본키인지 헷갈릴 때, 버전 글자만 보고 어떤 생성기가 만들었는지 추정할 수 있습니다(예: v4가 압도적으로 흔하므로 v1이나 v3이 보이면 특정 레거시 시스템을 의심).
• 보안 점검: v1 UUID는 MAC 주소와 타임스탬프를 인코딩하므로, 외부에 노출되면 서버의 네트워크 인터페이스 정보나 생성 시각이 유출될 수 있습니다. 버전 글자 하나로 이런 위험을 즉시 스크리닝할 수 있습니다.
• 데이터 정합성 검증: 대량의 UUID 컬럼에 형식은 맞지만 표준 밖의 값(버전 6~f)이 섞여 있는지 UUID 추출기로 뽑아낸 뒤 하나씩 검사하면 손상되거나 임의 생성된 값을 걸러낼 수 있습니다.

대량으로 표준 UUID를 뽑아야 한다면 UUID 대량 생성기로 한 번에 생성하는 편이, 손으로 만든 값보다 버전/variant 비트가 항상 정확하게 맞습니다.

자주 묻는 질문