본문으로 바로가기

UUID 생성기 (v4 · v7)

UUID 버전 4와 버전 7을 한 번에 1 ~ 1000개 만들고, 붙여넣은 UUID의 버전·변형과 버전 7에 담긴 생성 시각을 읽어 줍니다.

UUID 생성

버전
1 ~ 1000개까지 한 번에 만들 수 있습니다.

생성 결과

UUID 분석기

입력한 내용은 이 브라우저 안에서만 처리되며 서버로 전송되지 않습니다. 어떻게 동작하나요?

UUID v4 예시와 8-4-4-4-12 글자 그룹 구조

사용 방법

페이지를 열면 버전 4 UUID 10개가 이미 만들어져 있습니다. UUID 생성에서 다음을 바꿀 수 있습니다.

  • 버전: “v4 (완전 무작위)“와 “v7 (시간순 정렬)” 중에서 고릅니다. 고르는 즉시 새로 만듭니다.
  • 생성 개수: 1 ~ 1000 사이의 정수입니다. 범위를 벗어난 값을 넣으면 칸을 벗어날 때 1이나 1000으로 맞춥니다.
  • 대문자, 하이픈 제거, 중괄호 { }: 결과를 적는 방식입니다.
  • 생성하기: 같은 설정으로 새 값을 만듭니다.
  • 전체 복사, .txt로 다운로드: 결과 전체를 한 줄에 하나씩 가져갑니다. 내려받는 파일 이름은 uuid.txt입니다. 줄마다 있는 복사 버튼으로 하나만 가져갈 수도 있습니다.

100개를 넘게 만들면 화면에는 처음 100개만 보이고 “모두 보기”를 눌러야 나머지가 보입니다. 전체 복사와 다운로드에는 보이지 않는 값도 모두 들어갑니다.

아래 UUID 분석기는 UUID 하나를 붙여넣으면 “버전”, “변형(variant)”, “내장된 타임스탬프”를 보여 줍니다.

버전 4와 버전 7의 차이

UUID는 128비트 값이고, 그중 6비트는 버전과 변형을 적는 자리로 고정되어 있습니다. 나머지 122비트를 어떻게 채우느냐가 버전의 차이입니다.

자리 버전 4 버전 7
앞 48비트 무작위 1970년 1월 1일(UTC)부터 센 밀리초
4비트 버전 (4) 버전 (7)
12비트 무작위 RFC 9562는 무작위 자리로 두지만 이 도구는 카운터로 씁니다
2비트 변형 변형
62비트 무작위 무작위

버전 4는 값만 보고는 아무것도 알 수 없습니다. 대신 정렬 순서가 없어서 데이터베이스 기본 키로 쓰면 새 값이 인덱스 곳곳에 끼어듭니다. 그만큼 B-tree 페이지 분할이 잦아지고 캐시 적중률이 떨어집니다.

버전 7은 앞자리가 시각이라 값을 문자열로 정렬하면 만든 순서가 됩니다. 기본 키로 쓰면 새 값이 인덱스 끝에 쌓입니다. 그 대가로 값에 생성 시각이 밀리초까지 드러납니다. 가입 시각이나 주문 시각을 외부에서 짐작하면 안 되는 식별자에는 버전 4가 맞습니다.

버전 4는 브라우저의 crypto.randomUUID()로 만들고, 버전 7의 무작위 부분은 crypto.getRandomValues()로 채웁니다. 둘 다 암호학적으로 안전한 난수입니다.

한 번에 만든 버전 7이 순서대로 나오는 이유

버전 7을 여러 개 만들면 그 묶음 전체에 같은 밀리초를 씁니다. 타임스탬프가 같으니 순서는 그 뒤의 12비트 카운터가 정합니다.

  • 묶음의 첫 값은 카운터를 0 ~ 2047 사이의 무작위 수로 시작합니다. 12비트로 적을 수 있는 수는 4095까지인데 절반만 쓰는 것은 넘침에 대비한 여유입니다.
  • 다음 값부터 카운터를 1씩 올립니다. 한 번에 최대 1000개이므로 가장 큰 시작값 2047에서 출발해도 3046에서 끝나고, 카운터가 넘치지 않습니다.
  • 뒤쪽 62비트는 값마다 새로 뽑습니다.

예를 들어 타임스탬프가 2026년 1월 1일 00:00:00.000(UTC)이고 카운터가 2047에서 시작하면, 연달아 나오는 세 값의 앞부분은 019b76da-a800-77ff, 019b76da-a800-7800, 019b76da-a800-7801입니다. 셋째 묶음의 맨 앞 7은 버전이고 그 뒤 세 자리가 카운터입니다.

카운터는 묶음끼리 이어지지 않습니다. “생성하기”를 다시 누르면 그 순간의 시각으로 새로 시작하므로, 나중에 만든 묶음이 타임스탬프에서 앞 묶음보다 뒤에 옵니다. 그 사이에 기기 시계가 뒤로 맞춰졌다면 이 순서는 지켜지지 않습니다.

충돌 가능성

버전 4는 122비트가 무작위입니다. 생일 문제로 계산하면 같은 값이 한 번이라도 나올 확률이 50%에 이르려면 약 2.7 × 10^18개를 만들어야 합니다. 1초에 10억 개씩 만들어도 약 86년이 걸리는 양입니다.

이 도구가 만드는 버전 7은 값마다 새로 뽑는 무작위가 62비트입니다. 한 묶음 안에서는 카운터가 서로 달라서 값이 겹치지 않습니다. 서로 다른 기기나 탭에서 같은 밀리초에 만든 값끼리는 카운터와 62비트 무작위가 모두 같아야 겹칩니다.

분석기가 읽는 것

분석기에 018f4d2e-7c3a-7b21-9e2f-1a2b3c4d5e6f를 넣으면 버전 7, 변형은 “RFC 9562 (표준)”, 내장된 타임스탬프는 2024년 5월 6일 09:14:03(UTC)으로 나옵니다. 시각은 이 브라우저의 시간대로 표시되므로 UTC+9 시간대에서는 오후 6:14:03입니다.

  • 버전은 셋째 묶음의 첫 자리(13번째 16진수)를 숫자 그대로 보여 줍니다. 표준에 없는 값이어도 그대로 표시합니다.
  • 변형(variant)은 넷째 묶음 첫 자리의 비트로 정해집니다.
화면 표시 넷째 묶음 첫 자리 뜻
NCS (구버전 호환) 0 ~ 7 옛 NCS 방식과의 호환용으로 남겨 둔 값
RFC 9562 (표준) 8, 9, a, b 지금 쓰는 표준 UUID
Microsoft (구버전 GUID) c, d 옛 Microsoft GUID와의 호환용
향후 사용을 위해 예약됨 e, f 아직 정의되지 않은 값
  • 모든 자리가 0이면 “Nil UUID”, 모든 자리가 f이면 “Max UUID” 표시가 붙습니다. RFC 9562는 Nil을 “값 없음”, Max를 목록의 끝 같은 표지로 쓸 수 있다고 설명합니다. 자리 값에 따라 Nil은 버전 0에 NCS 변형, Max는 버전 15에 예약된 변형으로 표시됩니다.

분석기는 모양만 봅니다. 16진수 32자리이기만 하면 통과하므로, 통과했다고 해서 실제로 발급된 UUID라는 뜻은 아닙니다. 손으로 고친 값의 버전 자리가 7이면 타임스탬프도 그 자리 숫자대로 읽어 보여 줍니다.

참고 자료

자주 묻는 질문

대문자나 하이픈 제거 옵션을 바꾸면 UUID가 새로 만들어지나요?

아니요. "대문자", "하이픈 제거", "중괄호 { }"는 이미 만든 값을 적는 방식만 바꿉니다. 값이 새로 만들어지는 때는 "생성하기"를 누를 때, "버전"을 바꿀 때, "생성 개수"를 고치고 칸을 벗어날 때입니다.

하이픈 제거나 중괄호 옵션은 언제 쓰나요?

하이픈 없는 32자리 형식은 파일명이나 일부 데이터베이스 컬럼에 쓰기 편하고, 중괄호로 감싼 형식은 Windows 레지스트리나 COM 컴포넌트의 GUID 표기에 주로 쓰입니다. 세 옵션을 모두 켜면 {018F4D2E7C3A7B219E2F1A2B3C4D5E6F} 같은 모양이 됩니다.

분석기에 버전 1 UUID를 넣으면 생성 시각이 나오나요?

나오지 않습니다. 분석기는 버전 7의 타임스탬프만 읽습니다. 버전 1이나 버전 6처럼 시각을 다른 방식으로 담는 UUID를 넣으면 버전과 변형은 표시되지만 "내장된 타임스탬프" 칸에는 "이 도구는 버전 7 UUID의 타임스탬프만 읽습니다."가 나옵니다.

urn:uuid:로 시작하는 값이나 따옴표로 감싼 값도 분석되나요?

안 됩니다. 분석기가 받는 것은 16진수 32자리이고, 하이픈과 대소문자, 양쪽을 감싼 중괄호까지만 허용합니다. urn:uuid: 접두사나 따옴표가 붙어 있으면 "올바른 UUID 형식이 아닙니다."가 나오니 떼고 넣으세요.

최종 수정일: