UUID 생성기
표준 UUID v4(무작위)를 원하는 개수만큼 생성합니다. 고유 식별자가 필요할 때 사용하세요.
🔒 값은 브라우저의 암호학적 난수 생성기(crypto.getRandomValues)로 만들어지며 서버로 전송되지 않습니다.
UUID 생성기란?
데이터베이스 기본 키, API 요청 ID, 파일명 등 전 세계에서 중복되지 않는 고유 식별자가 필요할 때 UUID를 사용합니다. 툴즈25시 UUID 생성기는 가장 널리 쓰이는 UUID v4(무작위)와 데이터베이스 정렬에 유리한 최신 표준인 UUID v7(시간순)을 모두 지원합니다. 원하는 버전을 선택하고 개수를 입력한 뒤 '생성' 버튼만 누르면 됩니다. 생성된 UUID는 대소문자, 하이픈 유무, 중괄호 표기 등 다양한 서식으로 즉시 변경할 수 있으며, '전체 복사' 또는 '저장' 버튼으로 간편하게 가져갈 수 있습니다. 모든 UUID는 브라우저의 암호학적 난수 생성기를 통해 사용자 컴퓨터 안에서만 안전하게 만들어지며, 서버로 어떤 데이터도 전송하지 않으므로 안심하고 사용하셔도 좋습니다.
사용 방법
- 화면 상단의 "v4 (무작위)" 또는 "v7 (시간순 정렬)" 버튼을 눌러 생성할 UUID 버전을 선택합니다.
- "개수" 입력칸에 원하는 숫자를 입력합니다. 한 번에 최대 500개까지 생성할 수 있습니다.
- "생성" 버튼을 누르면 아래 "생성 결과" 영역에 UUID 목록이 즉시 나타납니다.
- "대문자", "하이픈 제거", "중괄호 표기" 체크박스를 이용해 원하는 형식으로 실시간 변경합니다. 다시 생성할 필요가 없습니다.
- "전체 복사" 버튼으로 목록 전체를 클립보드에 복사하거나, "저장" 버튼을 눌러 .txt 파일로 다운로드합니다.
UUID 생성기 사용 가이드
실제 작업에서 이 도구를 어떻게 쓰는지, 무엇을 조심해야 하는지 정리했습니다.
v4 냐 v7 이냐 — 실무에서 진짜 갈리는 지점
두 버전은 "정렬되느냐"만 다릅니다. v4는 122비트가 전부 무작위라 생성 순서를 알 수 없고, v7은 앞 48비트가 밀리초 타임스탬프라 문자열 정렬이 곧 생성순 정렬이 됩니다. 결과 창에서 v7으로 여러 개를 만들어 보면 앞자리가 거의 같고 뒤로 갈수록 값이 커지는 것이 보입니다.
이 차이가 왜 중요하냐면, 대부분의 UUID는 결국 데이터베이스 기본키로 들어가기 때문입니다.
| v4 | v7 | |
|---|---|---|
| 무작위 비트 | 122 | 74 |
| 생성 순서 파악 | 불가능 | 가능 (밀리초 단위) |
| DB 인덱스 삽입 | 무작위 위치 — 페이지 분할 잦음 | 끝에 순차 추가 — B-tree 에 유리 |
| 생성 시각 노출 | 없음 | 있음 (값에서 바로 읽힘) |
| 표준 | RFC 4122 | RFC 9562 (2024) |
| 적합한 곳 | 외부 노출 식별자, 순서가 의미 없는 값 | DB 기본키, 시간순이 자연스러운 로그·주문 |
UUID를 기본키로 쓸 때 — 인덱스 단편화 이야기
MySQL InnoDB는 기본키 순서대로 데이터를 물리적으로 정렬해 저장합니다(클러스터형 인덱스). 여기에 v4 UUID를 넣으면 새 행이 매번 인덱스의 무작위 위치에 끼어듭니다. 그러면 이미 꽉 찬 페이지를 쪼개는 일(페이지 분할)이 계속 일어나고, 페이지가 반쯤 빈 채로 늘어나면서 같은 데이터가 더 많은 디스크와 버퍼풀을 차지합니다. 데이터가 버퍼풀보다 커지는 순간부터 삽입 성능이 눈에 띄게 나빠집니다.
v7은 값이 시간순으로 커지므로 항상 인덱스의 오른쪽 끝에 추가됩니다. AUTO_INCREMENT 와 비슷한 삽입 패턴이 되어 페이지 분할이 거의 없습니다. 새로 설계하는 테이블에 UUID 기본키가 필요하다면 v7이 기본 선택지가 되는 이유입니다.
- 저장 타입 — MySQL이라면 CHAR(36) 대신 BINARY(16)이 절반 이하 크기입니다. 다만 눈으로 확인이 어려워지므로 팀 합의가 필요합니다. "하이픈 제거" 옵션은 CHAR(32)로 저장하는 곳에 씁니다.
- 보조 인덱스 — InnoDB는 보조 인덱스마다 기본키 값을 함께 저장합니다. 36바이트 기본키에 보조 인덱스가 5개면 그 비용이 5배로 붙습니다.
- PostgreSQL은 힙 저장이라 InnoDB만큼 극적이진 않지만, 인덱스 삽입 지역성은 v7이 유리한 것이 맞습니다.
- 이미 v4로 운영 중이라면 굳이 갈아엎지 마세요. 데이터 규모가 버퍼풀 안에서 놀 정도면 체감 차이가 없습니다.
v7의 대가 — 생성 시각이 값에 드러납니다
v7의 앞부분은 밀리초 타임스탬프 그대로입니다. 특별한 도구 없이도 그 계정·주문이 언제 만들어졌는지 읽힙니다. 공개 URL에 v7 UUID를 노출하면 그 리소스가 언제 생성됐는지를 정확히 알려 주게 됩니다.
경쟁사에 가입자 증가 시점을 유추당하거나, 특정 사용자의 가입 시각이 드러나는 것이 문제가 되는 서비스라면 외부 노출용 식별자는 v4로 따로 두고 내부 기본키만 v7로 가는 구성이 안전합니다.
표기 옵션은 왜 있나
세 가지 체크박스는 모양만 바꿉니다. 값은 그대로이므로 다시 만들 필요 없이 켜고 끄면 됩니다. 다만 붙여넣을 곳이 어디냐에 따라 필요한 모양이 정해져 있습니다.
- 하이픈 제거 — CHAR(32) 컬럼, URL의 짧은 경로, 파일명 접두어에 씁니다. 32자 hex 문자열이 됩니다.
- 중괄호 표기 — 윈도우·닷넷 계열의 GUID 관습입니다. 레지스트리나 COM 관련 설정이 이 모양을 요구합니다.
- 대문자 — 역시 닷넷·윈도우 문서에서 자주 보이는 표기입니다. 표준은 소문자 생성·대소문자 무시 비교이므로, DB에 저장할 때는 한쪽으로 통일해 두는 편이 사고가 없습니다.
정말 안 겹치나 · 이 값을 믿어도 되나
v4의 무작위 비트는 122개입니다. 감을 잡자면, 초당 10억 개를 100년 동안 만들어도 충돌 확률이 무시할 수준입니다. 실무에서는 고유하다고 가정하고 설계해도 됩니다.
다만 그 전제는 난수가 제대로 된 것일 때입니다. 이 도구는 브라우저의 crypto.getRandomValues 를 쓰므로 문제가 없지만, 예전 언어·라이브러리 중에는 시간이나 프로세스 ID를 씨앗으로 쓰는 약한 난수로 UUID를 만드는 구현도 있었습니다. 그런 값은 예측이 가능해 UUID의 고유성 논리가 통하지 않습니다.
v7은 같은 밀리초 안의 순서가 실제 문제가 됩니다. 이 도구는 같은 밀리초에 여러 개를 만들 때 뒷부분을 1씩 올려(RFC 9562 monotonic random) 생성 순서를 보장합니다. 그래서 500개를 한 번에 만들어도 위에서 아래로 정렬이 유지됩니다. 직접 구현할 때 이 처리를 빠뜨리면 같은 밀리초 안에서 순서가 뒤섞입니다.
자주 묻는 질문
UUID v4는 정말 안 겹치나요?
이론상 중복 가능성은 있지만, 그 확률이 우주적 규모로 낮아 실무에서는 사실상 고유하다고 간주합니다. 전 세계 모든 사람이 수백 년간 초당 수십억 개를 생성해도 충돌을 걱정할 필요가 없는 수준입니다.
UUID v4와 v7은 어떤 차이가 있나요?
v4는 전체가 거의 무작위 값이라 생성 순서를 알 수 없습니다. 반면 v7은 앞부분에 생성 시각(타임스탬프) 정보가 포함되어 있어 값 자체로 시간순 정렬이 가능합니다. 데이터베이스 기본 키로 사용할 경우 v7이 쓰기 성능 면에서 더 유리합니다.
UUID와 GUID는 다른 건가요?
GUID(Globally Unique Identifier)는 Microsoft가 구현한 UUID 표준의 다른 이름입니다. 기술적으로는 약간의 차이가 있을 수 있지만, 현재는 대부분의 시스템에서 UUID와 GUID를 같은 의미로 사용하며, 특히 UUID v4를 가리키는 경우가 많습니다.
생성된 UUID가 서버로 전송되나요?
아닙니다. 모든 UUID 생성 과정은 사용자의 웹 브라우저 안에서만 실행됩니다. 브라우저의 안전한 암호학적 난수 생성기(crypto.getRandomValues)를 사용하며, 입력값이나 생성 결과 등 어떤 정보도 저희 서버로 전송되지 않습니다.