UUID란 무엇인가요?
UUID(범용 고유 식별자)는 128비트 값으로 550e8400-e29b-41d4-a716-446655440000과 같은 36자 문자열로 표현됩니다. 형식과 버전 의미는 v1~v5는 RFC 4122가, 더 새로운 v6·v7·v8은 RFC 9562가 정의합니다. 이 도구는 v4(완전 무작위), v1(타임스탬프 + 무작위 노드 ID), v7(Unix 밀리초 타임스탬프 접두부 + 무작위 접미부, 생성 시각 순 정렬 가능)을 모두 브라우저에서 플랫폼의 Web Crypto API로 생성합니다. 어떤 데이터도 서버로 전송되지 않습니다.
UUID 생성은 어떻게 작동하나요?
버전마다 결정성, 정렬 가능성, 엔트로피의 균형이 다릅니다. 도구는 선택에 따라 알맞은 알고리즘을 사용합니다:
- v4(무작위)는 브라우저의
crypto.randomUUID()를 호출하여 122비트의 암호학적 난수를 반환하며, 6개의 고정 비트(버전0100과 변종10)는 올바른 위치에 설정됩니다. 충돌은 천문학적으로 드뭅니다 — 한 번의 중복을 50% 확률로 만나려면 약 2.71 × 10^18개의 v4 UUID를 생성해야 합니다. - v1(타임스탬프 + 노드)은 60비트 그레고리력 타임스탬프(1582-10-15 이후의 100나노초 틱)를
time_low/time_mid/time_hi_and_version에 채워 넣고, 버전 니블을0001로 설정하고, 변종 비트가 설정된 14비트 클록 시퀀스를 선택하며, 멀티캐스트 비트가 강제로 켜진 48비트 무작위 노드 ID를 사용합니다(RFC 4122 §4.5는 하드웨어 MAC이 없을 때 무작위 노드 ID 사용을 명시적으로 허용하며, 멀티캐스트 비트가 이를 MAC 아님으로 표시합니다). - v7(정렬 가능한 타임스탬프)은 RFC 9562 §5.7에 따라 48비트 big-endian Unix 밀리초 타임스탬프, 4비트 버전
0111, 12비트 난수, 2비트 변종10, 그리고 62비트의 추가 난수 순으로 배치합니다. 타임스탬프가 최상위 비트에 있기 때문에 v7 UUID는 생성 순서대로 사전순 정렬되며, 이는 다른 UUID 버전이 추가 인코딩 없이는 제공하지 못하는 특성입니다. - 모든 난수성은 브라우저의 암호학적으로 안전한 RNG인
crypto.getRandomValues()에서 옵니다. v1과 v7 모두 동일 틱 내 단조성 가드를 포함하여, 같은 클록 틱 안에서 연속 호출하더라도 두 번째 값이 첫 번째 위로 정렬되도록 보장합니다 — 밀리초 시계를 앞지르는 대량 생성에 중요합니다. - 생성 후 형식화 파이프라인이 실행됩니다. 하이픈을 제거하거나, 대문자로 바꾸거나, 값을 중괄호로 감싸거나(
{…}— Microsoft의 GUID 관례), 원본 16바이트를 base64(22자 출력, padding 없음)로 표현할 수 있습니다. base64 모드는 다른 형식 옵션을 무효화합니다 — base64 자체가 별도의 표현이기 때문입니다.
이 UUID 생성기를 사용하는 이유는 무엇인가요?
- 어떤 것도 브라우저 밖으로 나가지 않습니다. Web Crypto API는 로컬에서 실행되며, 페이지는 최초 문서 로딩 이후 네트워크 요청을 한 번도 보내지 않습니다. DevTools를 열고 생성을 누르면 Network 패널은 침묵을 유지합니다.
- RFC 준수 출력. v4는 RFC 4122 §4.4를, v1은 §4.2와 §4.5를, v7은 RFC 9562 §5.7을 따릅니다. 버전 니블과 변종 비트는 표준이 명시한 자리에 위치하며, 모든 UUID는 해당 버전의 표준 정규식 검증을 통과합니다.
- 데이터베이스 키용 정렬 가능한 v7. Postgres·MySQL·SQL Server에서 v7 UUID를 클러스터링 기본 키로 사용하면 인덱스에 append-only로 삽입되어 페이지 분할도, 무작위 I/O도 없으면서 전 세계적으로 유일성을 유지합니다. v4는 비트가 무작위이기 때문에 이를 할 수 없습니다.
- 속도 제한 없는 대량 생성. 한 번에 1, 10, 100 또는 1,000개의 UUID를 생성합니다. 할당량도, 가입도 없습니다 — 도구가 탭 안에서 실행되므로 한도는 벤더의 API 등급이 아니라 당신의 CPU입니다.
UUID의 일반적인 활용 사례는 무엇인가요?
UUID는 중앙 기관과 협조하지 않고도 전역적으로 고유한 식별자가 필요한 곳이라면 어디든 사용됩니다:
- 데이터베이스 기본 키. 자동 증가 정수는 행 수를 노출하고 샤딩을 망가뜨립니다. UUID는 샤드 간에 안정적이고 지역 간 병합에 안전하며, (v7과 함께라면) B-트리 삽입을 페이지 분할 없이 핫 영역에 유지합니다. 일반적인 애플리케이션은 클라이언트에서 UUID를 생성해 INSERT에 함께 보내며, 키를 얻기 위해 서버 왕복을 하지 않습니다.
- 요청 상관관계 ID. HTTP 미들웨어는 들어오는 요청마다 v4 UUID를 부착하고 모든 span에 기록하며 다운스트림으로 전파합니다(흔히
X-Request-Id헤더로). 고객이 버그를 보고하면 지원 엔지니어가 ID를 붙여 넣고, 서비스와 시간대를 가로지른 요청의 전체 추적이 모호함 없이 떠오릅니다. - 멱등성 키. 결제 API(Stripe, Adyen, Square)는
Idempotency-Key헤더를 받아 재시도된 요청이 고객에게 두 번 청구되지 않도록 합니다. 클라이언트에서 생성한 UUID는 키가 논리적 작업당 유일함을 보장하며, 그것이 바로 이 API들이 요구하는 계약입니다.
UUID 예시는 어떻게 생겼나요?
Node.js나 최신 브라우저에서 한 줄짜리 crypto.randomUUID()는 새 v4 UUID를 반환합니다 — 예를 들어 3f50b5a8-2c54-4b9c-9c1f-3e5c7e2b8d12. 이 값을 요청 ID나 멱등성 키로 쓰면 됩니다. UUID가 클러스터링 기본 키가 될 데이터베이스 컬럼에 들어간다면 v7을 생성하세요. 0190a3b0-7d4f-7c9e-8b21-a4d6f0bd9c11과 0190a3b0-7d50-7f15-9c4e-72b3e0c1d8a4처럼 1밀리초 간격으로 만들어진 두 v7 값은 생성 순서대로 사전순 정렬됩니다. Postgres의 uuid 타입은 두 버전을 동일하게 저장하지만, 차이는 인덱스 기록 시점에 드러납니다 — v7은 B-트리 오른쪽에 추가되는 반면 v4는 삽입이 흩어져 무작위 I/O를 강요합니다.
이 UUID 생성기는 단 한 가지 일을 합니다: 클릭 한 번을 RFC 준수 식별자 한 개 또는 여러 개로 바꾸되, 당신이 원하는 형식으로, 서버에 요청을 보내지 않고 처리합니다. 버전을 고르고, 개수를 고르고, 형식을 고르세요 — 생성하고, 복사하고, 다음 일로 넘어가세요.