사용 방법
- 버전을 고릅니다. 특별한 이유가 없으면 v4, 데이터베이스 기본키처럼 정렬 순서가 중요하면 v7을 씁니다.
- 개수(1~1,000)를 입력하면 바로 그만큼 만들어집니다. 새로 생성을 누를 때마다 새 값이 나옵니다.
- 대문자, 하이픈 없이, 중괄호
{ }형식을 골라 복사하거나.txt로 내려받습니다. 줄마다 UUID 하나씩 들어갑니다. - 아래 UUID 분석에 아무 UUID나 붙여넣으면 버전과 변형(variant)을 알려주고, v1·v6·v7이면 안에 담긴 생성 시각을 꺼내 보여줍니다.
UUID 구조와 버전
UUID(RFC 9562, 이전 RFC 4122)는 128비트 값을 8-4-4-4-12 형태의 16진수 36자로 씁니다. 세 번째 묶음의 첫 글자가 버전, 네 번째 묶음의 첫 글자(8·9·a·b)가 표준 변형을 나타냅니다.
| 버전 | 만드는 방법 | 특징 |
|---|---|---|
| v1 | 시각(100ns 단위) + 노드(MAC 주소) | 생성 기기·시각이 드러남 |
| v4 | 122비트 난수 | 가장 흔함, 순서 없음 |
| v6 | v1의 시각 필드를 정렬 가능하게 재배열 | v1 호환이 필요할 때 |
| v7 | 48비트 Unix 시각(ms) + 74비트 난수 | 생성 순서대로 정렬됨 |
v7 예시 017f22e2-79b0-7cc3-98c4-dc0c0c07398f의 앞 12자리 017f22e279b0을 10진수로 바꾸면 1,645,557,742,000ms, 즉 2022-02-22 19:22:22 UTC입니다(RFC 9562 부록 예시).
v4와 v7 중 무엇을 쓸까
- v4: 값만 봐서는 아무 정보도 알 수 없어야 할 때(공개 URL의 ID 등). 122비트 난수라 10억 개를 만들어도 충돌 확률은 약 10⁻¹⁹ 수준입니다.
- v7: DB 기본키나 로그 ID처럼 생성 순서가 중요할 때. 새 값이 항상 인덱스 끝에 붙어서 B-tree 인덱스 조각화가 줄어듭니다. 대신 생성 시각(ms)이 그대로 드러나므로 노출되면 안 되는 곳에는 쓰지 마세요.
- 이 도구의 v7은 같은 밀리초 안에서 만든 값도 순서가 유지되도록 RFC 9562 §6.2의 카운터 방식을 씁니다.
자주 묻는 질문
GUID와 UUID는 다른가요?
같은 것입니다. GUID는 마이크로소프트가 쓰는 이름이고, 윈도우·.NET에서는 대문자와 중괄호 표기({...})가 흔합니다. 옵션으로 같은 형식을 만들 수 있습니다.
만든 UUID가 서버에 저장되나요?
아니요. 브라우저의 암호학적 난수 생성기(crypto.getRandomValues, 지원 시 crypto.randomUUID)로 이 기기에서 만들고, 어디에도 보내거나 기록하지 않습니다. 사람이 외울 비밀 값이 필요하다면 비밀번호 생성기가 더 알맞고, v7의 시각만 따로 확인하려면 유닉스 타임스탬프 변환기에 ms 값을 넣어 보세요.