식별자 생성
버전 1, 3, 4, 5, 6, 7의 UUID나 ULID를 하나씩 또는 최대 천 개씩 생성하고, 식별자를 분석해 버전, 변형, 그리고 담겨 있는 날짜를 확인하세요. 브라우저에서 시스템의 암호학적 난수 생성기로 계산됩니다.
122비트 난수. 고유 식별자만 필요할 때 가장 많이 쓰입니다.
형식
결과
UUID 또는 ULID 분석
하이픈, 중괄호, urn:uuid: 접두사 또는 26자 ULID를 받습니다
유형
버전 7: 정렬 가능한 Unix 날짜
변형
RFC 9562(이전 RFC 4122)
생성 날짜
2022. 2. 22. PM 4:22:22 2022-02-22T19:22:22.000Z · 1645557742000 ms
표준 형식017f22e2-79b0-7cc3-98c4-dc0c0c07398f
대문자017F22E2-79B0-7CC3-98C4-DC0C0C07398F
중괄호 GUID{017F22E2-79B0-7CC3-98C4-DC0C0C07398F}
URNurn:uuid:017f22e2-79b0-7cc3-98c4-dc0c0c07398f
ULID로01FWHE4YDGFK1SHH6W1G60EECF
16진수017f22e279b07cc398c4dc0c0c07398f
10진 정수1989357241971137676463954034883508623
Base64AX8i4nmwfMOYxNwMDAc5jw==

작동 방식

UUID는 다섯 그룹(8-4-4-4-12)으로 나눈 16진수 32자리로 쓰는 128비트 숫자입니다. 값이 이미 쓰였는지 누구에게도 묻지 않고 레코드를 식별할 수 있어서, 서버 두 대나 모바일 앱 두 개, 프로세스 두 개가 조율 없이 동시에 식별자를 만들어도 충돌하지 않습니다. 형식은 RFC 9562가 정의하며, 2024년에 RFC 4122를 대체하고 버전 6, 7, 8을 추가했습니다.

세 번째 그룹의 첫 자리가 버전을 나타내며, 버전마다 비트 배치가 다릅니다. 버전 4는 순수한 난수입니다. 버전 7은 밀리초 단위 날짜로 시작하므로 식별자가 생성 순서대로 정렬됩니다. 버전 3과 5에는 무작위 요소가 없습니다. 네임스페이스와 이름의 해시에서 만들어지므로 항상 같은 결과가 나옵니다. 버전 1과 6은 100나노초 정밀도의 날짜와, 역사적으로 컴퓨터의 MAC 주소였던 노드를 담습니다.

분석기는 그 반대로 동작합니다. 버전과 변형을 읽고, v1·v6·v7 UUID와 ULID에서 날짜를 복원하며, 같은 값을 GUID, URN, 16진수, 정수, Base64로 보여 줍니다. 모든 계산은 브라우저에서 이루어지며 어떤 식별자도 서버로 전송되지 않습니다.

예시

v5 · DNS · www.example.com2ed6657d-e927-568b-95e1-2665a8aea6a2RFC 9562의 테스트 벡터입니다. 버전 5를 올바르게 구현한 라이브러리라면 DNS 네임스페이스의 이 이름에 대해 정확히 이 값을 반환해야 합니다.
017F22E2-79B0-7CC3-98C4-DC0C0C07398F2022-02-22T19:22:22.000Zv7 UUID의 앞 12자리는 16진수로 쓴 Unix 밀리초입니다. 0x017F22E279B0은 1645557742000입니다.
C232AB00-9414-11EC-B3C8-9F6BDECED8461EC9414C-232A-6B00-B3C8-9F6BDECED846같은 시각을 버전 1과 버전 6으로 나타낸 것입니다. 버전 6은 날짜 비트를 상위에서 하위 순으로 재배열해 문자열이 시간순으로 정렬되게 합니다. 클럭 시퀀스와 노드는 바뀌지 않습니다.
01ARZ3NDEKTSV4RRFFQ69G5FAV01563e3a-b5d3-d676-4c61-efb99302bd5bULID는 UUID와 같은 128비트를 차지하므로 uuid 열에 저장할 수 있습니다. 하지만 버전도 변형도 없어서 UUID로 읽으면 그 자리는 무작위 값의 일부입니다.

활용 사례

  • 데이터베이스의 자동 증가 값을 기다리지 않고 클라이언트나 여러 서비스에서 동시에 기본 키를 만들기.
  • 재시도된 결제나 주문이 두 번 처리되지 않도록 멱등성 키를 생성하기.
  • 각 요청에 상관 ID를 붙여 여러 마이크로서비스의 로그에서 추적하기.
  • v5로 자연 키(이메일, URL, SKU)에서 안정적인 식별자를 도출해, 두 시스템이 테이블을 공유하지 않고도 같은 값에 도달하게 하기.
  • 로그나 오류 보고서에 나타난 v7 UUID나 ULID로 레코드가 언제 만들어졌는지 알아내기.
  • 수백 개의 유효한 식별자로 테스트 데이터를 한 번에 채우기.

자주 묻는 질문

기본 키로는 v4와 v7 중 무엇이 좋을까요?

생성 날짜를 숨길 이유가 없다면 v7입니다. B-트리 인덱스는 키를 순서대로 저장하는데, v4는 인덱스 아무 곳에나 들어가므로 삽입할 때마다 다른 페이지를 건드리고 페이지 분할이 일어나며 캐시 효율도 떨어집니다. v7은 자동 증가 값처럼 항상 끝에 추가됩니다. SQL Server는 주의하세요. uniqueidentifier 타입은 마지막 6바이트부터 비교해 정렬하므로 거기서는 v7도 순차적이지 않습니다.

v4 UUID 두 개가 겹칠 수 있나요?

이론상으로는 가능하지만 실제로는 일어나지 않습니다. v4에는 122비트의 난수가 있어서, 적어도 한 번 겹칠 확률이 50 %가 되려면 약 2.7 × 10¹⁸개, 즉 초당 10억 개씩 85년 넘게 생성해야 합니다. 조건은 암호학적 난수 생성기를 쓰는 것입니다. 실제로 보고되는 중복은 수학이 아니라 잘못 초기화된 시드 때문입니다.

UUID와 GUID는 같은 것인가요?

네. GUID는 Microsoft가 쓰는 이름이고 문자열은 동일합니다. Windows에서는 보통 대문자로 중괄호에 감싸 표시됩니다. 차이는 바이너리 표현에 있습니다. .NET의 Guid.ToByteArray는 앞의 세 그룹을 리틀 엔디언으로 저장하므로, 그 원시 바이트를 다른 언어에서 읽으면 앞자리가 뒤집혀 보입니다.

UUID를 비밀 토큰으로 써도 되나요?

제대로 생성된 v4는 예측할 수 없는 122비트를 가지고 있어 추측하기 어려운 링크에는 충분합니다. 하지만 RFC 9562는 UUID가 자격 증명용으로 설계되지 않았다고 명시합니다. 많은 라이브러리가 암호학적 난수 생성기를 보장하지 않고, 버전 1, 6, 7은 생성 날짜를 드러냅니다. 세션이나 비밀번호 재설정 토큰에는 전용 난수 바이트를 생성하는 편이 낫습니다.

ULID와 UUID v7 중 무엇이 좋을까요?

둘 다 거의 같은 정보를 담습니다. 48비트 밀리초와 나머지 난수입니다. ULID는 하이픈이나 헷갈리는 문자 없이 26자로 쓰여 URL에서 더 편리합니다. v7은 표준 UUID이므로 변환 없이 PostgreSQL의 uuid 열과 모든 검증기에 맞습니다. 처음부터 시작하고 데이터베이스에 uuid 타입이 있다면 v7을 고르세요.

제 v1 UUID의 노드가 왜 제 MAC이 아닌가요?

네트워크 카드의 MAC을 노출하면 각 식별자를 어느 기기가 만들었는지 추적할 수 있기 때문입니다. 1999년 Melissa 바이러스 제작자도 이렇게 밝혀졌습니다. RFC 9562는 멀티캐스트 비트를 켠 무작위 노드를 권장하며, 이 도구도 그렇게 합니다. v1 UUID에 실제 MAC이 들어 있으면 분석기가 알려 줍니다.

관련 항목