로그 추적용 식별자 생성
장애 분석이나 요청 추적용으로 임시 UUID를 빠르게 만들어 복사해야 할 때 바로 사용할 수 있습니다.
UUID 생성기
브라우저 내부 처리
crypto.randomUUID() 기반 랜덤 생성과 hex(binary16) 상호 변환을 제공합니다.
UUID 변환기가 필요한 대표 상황
DB 저장 형식 점검
문자열 UUID를 hex(binary16) 형태로 바꿔 저장 공간이나 이진 컬럼 사용 전략을 검토할 때 유용합니다.
레거시 값 복구
32자리 hex 값만 남아 있는 데이터를 다시 표준 UUID 형식으로 복원해 사람이 읽기 쉬운 형태로 비교할 수 있습니다.
실무에서 자주 묻는 점
hex(binary16)은 왜 쓰나요?
하이픈이 포함된 UUID 문자열보다 더 짧고, 일부 데이터베이스에서는 이진 컬럼으로 저장할 때 인덱스나 저장 공간 측면에서 유리할 수 있습니다.
UUID v7이 더 나은가요?
정렬 친화적인 식별자가 필요하면 위 생성 옵션에서 UUID v7을 고르세요. v7은 앞 48비트가 밀리초 타임스탬프라 생성 순서대로 정렬됩니다. 무작위여야 하면 v4, 문자열 가독성이 중요하면 ULID를 씁니다.
입력값이 서버로 전송되나요?
이 페이지의 UUID 생성과 형식 변환은 브라우저 안에서 수행됩니다. 민감한 값 검증 전에 브라우저 확장이나 외부 스크립트 정책은 별도로 점검하세요.
식별자를 고를 때 확인할 점
v7은 생성 시각을 값에 드러냅니다
UUID v7의 앞 48비트는 밀리초 타임스탬프이므로 값만 보고 언제 만들어졌는지 알 수 있습니다. 사용자 ID가 v7이고 공개 프로필 URL에 들어간다면 그 사람의 가입 시각이 공개됩니다. 공개되는 식별자에는 v4를 따로 두는 편이 안전합니다.
UUID는 비밀이 아닙니다
v4도 추측하기 어려울 뿐이고 비밀 토큰이 아닙니다. "URL을 아는 사람만 볼 수 있다"는 설계는 UUID 버전과 무관하게 취약합니다. 접근 제어는 별도로 두어야 합니다.
저장 형식이 인덱스 크기를 좌우합니다
CHAR(36)으로 저장하면 하이픈까지 36바이트, BINARY(16)이면 16바이트입니다. 기본키에서 이 20바이트 차이는 모든 세컨더리 인덱스에 곱해집니다. 대신 로그에서 눈으로 읽기 어려워지는 대가가 있습니다.
사용 순서와 입력 예시 더 보기
이 도구를 가장 실용적으로 쓰는 순서
1. 새 식별자가 필요하면 먼저 생성
장애 추적, 요청 상관관계, 임시 테스트 데이터처럼 지금 바로 식별자가 필요할 때는 상단 생성 영역에서 UUID v4나 ULID를 먼저 만듭니다.
2. 저장 형식 문제는 UUID ↔ hex 변환으로 확인
DB 바이너리 컬럼, 로그에 남은 32자리 값, 레거시 시스템 데이터처럼 표현이 다른 값은 상호 변환으로 같은 식별자인지 먼저 확인하는 편이 안전합니다.
3. 시간 정렬이 중요하면 UUID v7로 이어가기
정렬 가능한 식별자가 목적이라면 생성 옵션을 UUID v7로 바꿔 같은 화면에서 v4와 비교해보세요. 개념 차이는 UUID v4 vs v7 가이드에 정리해 두었습니다.