UUID 생성기

UUID는 중앙에서 번호를 나눠 주지 않아도 겹치지 않게 만드는 128비트 ID입니다

UUID(Universally Unique IDentifier)는 128비트, 곧 16바이트짜리 식별자입니다. 보통 0192f3a1-7c4e-7b21-9a3f-5c2d8e1f4a6b처럼 16진수 32자리를 8-4-4-4-12로 끊어 씁니다. 순번을 관리하는 서버가 없어도 서로 다른 컴퓨터가 각자 만든 값이 사실상 겹치지 않는다는 점이 핵심입니다. Microsoft 환경에서는 같은 것을 GUID라고 부릅니다.

지금 표준은 2024년 5월에 나온 RFC 9562이며, 오래 쓰던 RFC 4122를 대신합니다. 이 표준은 버전 번호 1부터 8까지를 다루는데, 새로 만들 때 실제로 고르는 버전은 대개 셋입니다. v4는 거의 전부가 무작위인 값, v7은 앞부분에 만든 시각을 넣어 정렬되는 값, v5는 같은 이름을 넣으면 언제나 같은 값이 나오는 이름 기반 값입니다. 이 도구는 세 버전을 모두 만들고, 어떤 UUID든 붙여 넣으면 그 안의 버전과 시각을 읽어 줍니다.

UUID를 직접 만들어 쓰는 때

데이터베이스가 알아서 번호를 붙여 주는데 왜 따로 ID를 만들까요? 번호를 정하는 곳이 한 군데가 아니거나, 저장하기 전에 ID가 먼저 필요할 때가 있기 때문입니다.

테스트·샘플 데이터: 회원 30명, 주문 200건 같은 가짜 데이터를 넣을 때 서로 다른 ID가 한꺼번에 필요합니다. 개수를 정해 만들고 JSON 배열이나 SQL 목록으로 바로 붙여 넣습니다.
저장하기 전에 정하는 ID: 오프라인에서 쓰는 앱이나 여러 단계로 나눠 저장하는 화면은 서버에 보내기 전에 ID를 정해 두어야 연결 관계를 유지할 수 있습니다. UUID는 어디서 만들어도 겹치지 않으니 서버 응답을 기다리지 않아도 됩니다.
여러 곳의 데이터를 합칠 때: 지점마다 1번부터 번호를 매긴 표를 합치면 번호가 부딪힙니다. 처음부터 UUID로 두면 합칠 때 다시 번호를 매기지 않아도 됩니다.
파일·객체 이름: 업로드한 파일 이름을 UUID로 바꾸면 같은 이름의 파일이 서로 덮어쓰지 않습니다.
요청·작업 추적: 요청 하나가 여러 서비스를 거칠 때 같은 UUID를 로그에 남기면 흩어진 기록을 한 줄로 이을 수 있습니다.
같은 대상에 같은 ID: 주소나 상품 코드처럼 이미 고유한 이름이 있는 대상에 늘 같은 UUID를 붙이고 싶다면 v5를 씁니다. 어느 서버에서 계산해도 결과가 같아서 서로 ID 표를 주고받을 필요가 없습니다.

쓰는 법

위쪽에서 버전을 고릅니다. 무엇을 골라야 할지 모르겠다면 아래 버전 비교를 보세요. 처음 화면에는 v4 10개가 이미 만들어져 있습니다.
v4·v7은 개수(1~1,000)를 넣고 새로 만들기를 누릅니다. 1·10·100·1,000 단추를 누르면 그 개수로 바로 만듭니다. v5는 이름 공간을 고르고 이름을 한 줄에 하나씩 적으면 줄마다 UUID가 나옵니다.
출력판에서 글자(소문자·대문자), 모양(8-4-4-4-12·하이픈 없음·중괄호·urn:uuid:), 묶기(한 줄씩·JSON 배열·SQL 목록)를 고릅니다. 값은 그대로 두고 표기만 바뀌며, 목록에 보이는 모양 그대로 복사되고 저장됩니다.
목록에서 줄을 누르면 그 UUID가 해부도에 펼쳐집니다. 줄 끝의 복사 아이콘이나 해부도의 복사로 한 개를, 전체 복사나 파일로 저장으로 목록 전체를 옮깁니다. 목록에서는 방향키로 이동하고 Enter로 그 줄을 복사합니다.
다른 곳에서 받은 UUID를 확인하려면 해부도 위의 확인 칸에 붙여 넣습니다. 중괄호, urn:uuid:, 따옴표, 하이픈 없는 32자리도 읽고, 버전·변형과 v7·v1·v6이면 만든 시각까지 보여 줍니다.

v4·v7·v5, 무엇을 고를까

RFC 9562 기준, 새로 만들 때 주로 고르는 세 버전
버전	무엇으로 만드나	정렬하면	값에서 드러나는 것	맞는 곳
v4	난수 122비트	뒤죽박죽	없음	외부에 보이는 ID, 보안과 관련된 식별자, 대부분의 일반 용도
v7	밀리초 시각 48비트 + 난수(또는 순번) 74비트	만든 순서	만든 시각(밀리초)	데이터베이스 기본 키, 시간순으로 쌓이는 기록
v5	이름 공간 UUID + 이름의 SHA-1	뒤죽박죽	이름을 알면 같은 값을 다시 만들 수 있음	이미 고유한 이름(URL·도메인 등)에 늘 같은 ID 붙이기

v7을 고르는 가장 큰 이유는 정렬입니다. RFC 9562는 시간순 UUID를 쓰면 새 값이 인덱스 안에서 서로 가까이 들어가 데이터베이스 인덱스의 지역성이 좋아지고, 무작위 값을 넣을 때와의 차이가 실제로 10배 이상 날 수 있다고 설명합니다. 반대로 같은 문서의 보안 절은 UUID를 보안 작업에 쓴다면 v4를 쓰라고 합니다. v7은 만든 시각을 그대로 담고 있어서, 공개된 ID만 보고도 언제 만든 데이터인지 알 수 있기 때문입니다.

v1과 v6도 시각을 담지만 장치의 MAC 주소를 노드 값으로 넣는 방식이라, RFC 9562는 가능하면 v1·v6 대신 v7을 쓰라고 권합니다. v3은 v5와 같은 이름 기반이지만 MD5를 쓰며, 표준은 가능하면 v3 대신 v5를 쓰라고 합니다. 그래서 이 도구는 v4·v7·v5만 만들고, 나머지 버전은 확인 칸에서 읽기만 합니다.

UUID 한 개를 읽는 법

36자 안에서 자리가 정해진 글자는 둘뿐입니다. 하이픈을 빼고 센 13번째 글자(세 번째 묶음의 첫 글자)가 버전이고, 17번째 글자(네 번째 묶음의 첫 글자)의 앞 두 비트가 변형(variant)입니다. RFC 9562 방식이면 변형 비트가 10이어서 17번째 글자는 8·9·a·b 가운데 하나가 됩니다. 나머지 122비트를 무엇으로 채우는지가 버전마다 다릅니다.

다섯 묶음의 비트 배치(RFC 9562 5.4·5.5·5.7)
묶음	글자	비트	v4	v7	v5
1	8	32	난수	시각(밀리초) 앞 32비트	SHA-1
2	4	16	난수	시각 뒤 16비트	SHA-1
3	4	16	버전 4 + 난수 12	버전 7 + rand_a 12	버전 5 + SHA-1 12
4	4	16	변형 2 + 난수 14	변형 2 + 난수 14	변형 2 + SHA-1 14
5	12	48	난수	난수	SHA-1

RFC 9562 부록에 실린 예시값을 확인 칸에 붙여 넣으면 해부도에서 같은 배치를 볼 수 있습니다.

RFC 9562 부록 A의 예시값
버전	UUID	읽어 낸 값
v4	`919108f7-52d1-4320-9bac-f847db4148a8`	13번째 글자 4, 17번째 글자 9(이진수 1001, 앞 두 비트 10)
v7	`017f22e2-79b0-7cc3-98c4-dc0c0c07398f`	앞 12글자 017f22e279b0 = 1,645,557,742,000밀리초 = 2022-02-22 19:22:22.000 UTC
v5	`2ed6657d-e927-568b-95e1-2665a8aea6a2`	DNS 이름 공간 + www.example.com의 SHA-1 앞 128비트, 버전·변형 자리만 덮어씀

v7의 rand_a 12비트는 만드는 쪽이 고를 수 있습니다. 그냥 난수로 채워도 되고, 같은 밀리초 안에서 1씩 늘리는 순번이나 밀리초보다 잘게 나눈 시각을 넣어도 됩니다(RFC 9562 6.2). 이 도구는 순번 방식(Method 1)을 씁니다. 새 밀리초가 되면 순번을 11비트 난수로 시작하고, 같은 밀리초 안에서는 1씩 올리며, 4,095를 넘으면 시각을 1밀리초 앞당깁니다. 그래서 한 번에 1,000개를 만들어도 목록 순서와 문자열 정렬 순서가 같습니다. 이어지는 62비트는 매번 새 난수입니다.

표기 모양과 길이

표기를 바꿔도 128비트 값은 그대로입니다. 받는 프로그램이 요구하는 모양에 맞추면 됩니다.

RFC 9562 예시 v4 값 하나를 여러 모양으로 쓴 경우
모양	예	글자 수	쓰는 곳
기본(소문자)	`919108f7-52d1-4320-9bac-f847db4148a8`	36	가장 흔한 표기, 브라우저 crypto.randomUUID()의 결과
대문자	`919108F7-52D1-4320-9BAC-F847DB4148A8`	36	macOS uuidgen 출력처럼 대문자를 쓰는 도구
하이픈 없음	`919108f752d143209bacf847db4148a8`	32	파일 이름, 길이를 줄여야 하는 키
중괄호	`{919108f7-52d1-4320-9bac-f847db4148a8}`	38	RFC 9562가 Microsoft 등 일부 구현의 출력 예로 든 모양
URN	`urn:uuid:919108f7-52d1-4320-9bac-f847db4148a8`	45	URN이 필요한 문서·메타데이터

RFC 9562는 16진수 글자를 대문자로 써도, 소문자로 써도, 섞어 써도 같은 값이라고 정합니다. 그런데 프로그램이 UUID를 그냥 문자열로 비교하면 대문자와 소문자를 다른 값으로 봅니다. 한 시스템 안에서는 한 가지 표기로 통일해 두세요.

코드·데이터베이스·터미널에서 만드는 법

2026년 10월 22일 공식 설명서 기준
환경	v4	v7
브라우저·Node.js	`crypto.randomUUID()`	기본 기능 없음
Python 3.14 이상	`uuid.uuid4()`	`uuid.uuid7()`
PostgreSQL 18	`gen_random_uuid()`, `uuidv4()`	`uuidv7()`
.NET 9 이상	`Guid.NewGuid()`	`Guid.CreateVersion7()`
PowerShell	`New-Guid`	기본 기능 없음
macOS 터미널	`uuidgen`	기본 기능 없음
리눅스(util-linux)	`uuidgen`	`uuidgen -7`

브라우저·Node.js: W3C Web Cryptography의 randomUUID는 v4만 만듭니다.
Python 3.14 이상: 3.14에서 uuid6·uuid7·uuid8이 추가됐고, uuid7은 42비트 순번으로 같은 밀리초 안의 순서를 지킵니다.
PostgreSQL 18: uuid_extract_version(), uuid_extract_timestamp()로 버전과 시각을 읽습니다.
.NET 9 이상: NewGuid는 v4를 만듭니다.
PowerShell: 무작위 GUID를 만듭니다.
macOS 터미널: 대문자로 출력합니다.
리눅스(util-linux): 좋은 난수원이 있으면 기본이 무작위 방식입니다. v5는 uuidgen --sha1 --namespace @dns --name www.example.com으로 만듭니다. 배포판의 util-linux 판에 따라 -7이 없을 수 있습니다.

중복 확률은 얼마나 작은가

v4는 122비트가 무작위이므로 가능한 값이 2¹²²개, 약 5.3 × 10³⁶개입니다. 이 가운데 n개를 뽑을 때 같은 값이 한 쌍이라도 나올 확률은 생일 문제 공식 1 − e^{−n(n−1)/(2·2¹²²)}로 어림합니다.

v4 UUID n개 가운데 같은 값이 한 쌍이라도 나올 확률
만든 개수	확률
100만 개	약 9.4 × 10⁻²⁶
10억 개	약 9.4 × 10⁻²⁰
1조 개	약 9.4 × 10⁻¹⁴
1,000조 개	약 9.4 × 10⁻⁸
약 2.7 × 10¹⁸개	50%

확률이 50%가 되는 2.7 × 10¹⁸개는 1초에 10억 개씩 만들어도 약 86년이 걸리는 양입니다. 다만 이 계산은 난수가 고르게 나온다는 전제를 둡니다. RFC 9562가 암호학적으로 안전한 난수 생성기를 쓰라고 하는 이유이고, 이 도구도 브라우저의 crypto.getRandomValues()를 씁니다. 확률이 0은 아니므로 운영 데이터에는 고유 제약 조건을 걸고, 충돌로 저장이 거부되면 새 값을 다시 만드는 처리를 둡니다.

v7은 같은 밀리초에 만든 값끼리만 겹칠 수 있습니다. 한 생성기 안에서는 순번이 늘어나므로 겹치지 않고, 서로 다른 기기가 같은 밀리초에 만들 때는 뒤쪽 62비트 난수가 구분합니다.

v7을 데이터베이스 키로 쓸 때

바이너리로 저장하기: RFC 9562는 UUID를 글자로 저장하면 128비트 값에 288비트를 쓰게 되니, 가능하면 128비트 바이너리로 저장하라고 합니다. PostgreSQL의 uuid 형처럼 전용 형식이 있으면 그것을 씁니다.
정렬은 바이트 순서로: v7은 바이트를 앞에서부터 비교하거나, 같은 대소문자로 쓴 글자를 사전순으로 정렬하면 만든 순서가 됩니다. 대문자와 소문자를 섞으면 글자 정렬이 깨집니다.
시각은 참고값: v7 앞 48비트는 만든 기기의 시계입니다. RFC 9562는 그 시각이 실제 시각에 얼마나 가까운지 보장하지 않는다고 적고, PostgreSQL 설명서도 꺼낸 시각이 만든 시각과 꼭 같지는 않다고 적습니다. 정확한 생성 시각이 필요하면 따로 열을 둡니다.
데이터베이스가 만들게 하기: RFC 9562는 데이터베이스 하나에 모든 데이터를 두는 경우 데이터베이스가 만든 UUID가 순서를 가장 잘 지킨다고 말합니다. 이 도구로 만든 값은 테스트 데이터나 미리 정해야 하는 ID에 쓰고, 운영 중 계속 쌓이는 키는 데이터베이스나 서버의 함수로 만드는 편이 낫습니다.

자주 틀리는 경우

앞 8글자만 잘라 쓰기: 8글자는 32비트라서 약 7만 7천 개만 모여도 같은 값이 나올 확률이 50%가 됩니다. 짧게 쓰고 싶다면 자른 값을 UUID만큼 고유하다고 보지 마세요.
UUID를 아는 것만으로 접근을 허락하기: RFC 9562 보안 절은 UUID를 추측하기 어렵다고 가정하지 말고, 갖고 있다는 사실만으로 권한을 주는 값으로 쓰면 안 된다고 정합니다. 공유 주소에 UUID가 들어가도 권한 확인은 따로 해야 합니다.
v7로 만든 공개 ID: 주소창에 보이는 회원 번호를 v7로 만들면 가입 시각이 드러납니다. 시각이 드러나면 안 되는 곳에는 v4를 씁니다.
v5 이름의 작은 차이: www.example.com과 www.example.com., 앞뒤 빈칸, 대소문자 차이는 모두 다른 이름이라 다른 UUID가 나옵니다. RFC 9562도 같은 이름이라도 표기가 여러 가지일 수 있고, 표기마다 다른 UUID가 나온다고 설명합니다. 이 도구는 이름을 고치지 않고 적은 그대로 UTF-8로 계산합니다.
바이트 순서가 다른 GUID: .NET의 Guid.ToByteArray()는 앞 세 묶음의 바이트 순서를 뒤집어 돌려줍니다. 문자열로 주고받을 때는 같지만 바이트로 옮길 때는 순서를 확인합니다.
이름 기반 UUID를 기본 키로: RFC 9562는 우편번호나 면허 번호처럼 변하지 않을 것 같던 값이 나중에 바뀌는 일이 흔하다며, 이름 기반 UUID를 기본 키로 쓰지 말라고 합니다.

한계와 주의

한 번에 1,000개까지 만듭니다. v5는 이름 1,000줄까지 계산합니다.
v7의 순서는 이 페이지 안에서만 이어집니다. 다른 탭이나 기기에서 같은 밀리초에 만든 값과의 순서는 보장하지 않습니다.
v7 시각은 이 기기의 시계를 씁니다. 기기 시계가 틀리면 UUID 속 시각도 틀립니다.
v5는 SHA-1을 씁니다. RFC 9562는 SHA-256 같은 다른 해시로 만드는 이름 기반 UUID는 v5가 아니라 v8로 만들라고 하며, 이 도구는 v8을 만들지 않습니다.
v1·v3·v6·v8은 확인 칸에서 읽기만 합니다. v1·v6의 노드 값은 장치의 MAC 주소일 수 있습니다.
만든 UUID는 새로 고치면 사라집니다. 필요한 목록은 복사하거나 파일로 저장해 두세요.

출처

기준일 RFC 9562와 W3C Web Cryptography, PostgreSQL 18·Python·.NET·PowerShell·util-linux 설명서는 2026년 10월 22일에 원문으로 확인했습니다. 예시 표의 v4·v7·v5 값은 이 도구와 Python 3.14 uuid 모듈로 같은 결과가 나오는지 대조했고, 확률 표는 위 공식으로 계산했습니다.

01IETF RFC 9562 — Universally Unique IDentifiers (UUIDs)2024년 5월, RFC 4122 대체. 4장 표기, 5.4 v4, 5.5 v5, 5.7 v7, 6.2 단조 증가, 6.11 정렬, 6.13 DB, 8장 보안, 부록 A 예시
02W3C — Web Cryptography API, randomUUID버전 4 UUID를 소문자 문자열로 만드는 절차
03PostgreSQL 18 — 9.14 UUID Functionsgen_random_uuid·uuidv4·uuidv7, uuid_extract_timestamp·uuid_extract_version
04Python 설명서 — uuid3.14에서 uuid6·uuid7·uuid8 추가, uuid7의 42비트 순번
05Microsoft Learn — Guid.CreateVersion7.NET 9부터, RFC 9562 버전 7
06Microsoft Learn — Guid.NewGuid버전 4 UUID, 122비트 엔트로피
07Microsoft Learn — Guid.ToByteArray앞 네 바이트 묶음과 두 바이트 묶음 두 개의 순서를 뒤집음
08Microsoft Learn — New-Guid무작위 GUID를 만드는 PowerShell 명령
09uuidgen(1) — util-linux 설명서기본 무작위 방식, -7(--time-v7), --sha1 --namespace @dns

자주 묻는 질문

UUID v4와 v7 중 무엇을 써야 하나요?

데이터베이스 기본 키처럼 새 값이 인덱스 끝에 차례로 쌓이는 편이 좋은 곳에는 v7이 맞습니다. 앞 48비트가 만든 시각이라 문자열로 정렬해도 만든 순서가 됩니다. 만든 시각이 드러나면 안 되는 값이나 보안과 관련된 식별자에는 v4를 씁니다. RFC 9562도 보안 작업에 쓰는 UUID라면 v4를 쓰라고 합니다.

UUID는 몇 글자인가요?

기본 표기는 16진수 32자리와 하이픈 4개를 합친 36자입니다. 하이픈을 빼면 32자, 중괄호를 붙이면 38자, 앞에 urn:uuid:를 붙이면 45자입니다. 값 자체는 128비트, 곧 16바이트입니다.

UUID 버전은 어떻게 확인하나요?

세 번째 묶음의 첫 글자, 곧 하이픈을 빼고 센 13번째 글자가 버전입니다. 네 번째 묶음의 첫 글자가 8·9·a·b 중 하나면 RFC 9562 변형입니다. 이 도구의 확인 칸에 붙여 넣으면 버전과 변형, v7·v1·v6이면 만든 시각까지 읽어 줍니다.

UUID v4가 중복될 확률은 얼마인가요?

v4는 122비트가 무작위라서 10억 개를 만들어도 그중 같은 값이 한 쌍이라도 나올 확률은 약 9.4 × 10⁻²⁰입니다. 겹칠 확률이 50%가 되려면 약 2.7 × 10¹⁸개가 필요합니다. 0은 아니므로 운영 데이터에는 고유 제약 조건을 함께 둡니다.

UUID v7에서 만든 시각을 알 수 있나요?

네. 앞 12글자(48비트)가 1970년 1월 1일 UTC부터 센 밀리초입니다. 확인 칸에 붙여 넣으면 기기 시간대와 UTC로 보여 줍니다. 다만 만든 기기의 시계를 그대로 담은 값이라 정확한 기록 시각으로 믿을 수는 없습니다.

UUID v5는 언제 쓰나요?

같은 이름에서 언제나 같은 UUID가 필요할 때 씁니다. 이름 공간 UUID와 이름을 이어 SHA-1을 구하고 앞 128비트를 씁니다. 예를 들어 DNS 이름 공간과 www.example.com은 어디서 계산해도 2ed6657d-e927-568b-95e1-2665a8aea6a2입니다. 이름이 한 글자만 달라도 전혀 다른 값이 됩니다.

UUID를 비밀번호나 인증 토큰으로 써도 되나요?

아니요. RFC 9562는 UUID를 추측하기 어렵다고 가정하지 말고, 갖고 있다는 것만으로 접근을 허락하는 값으로 쓰지 말라고 합니다. UUID가 들어간 주소에도 권한 확인이 필요하고, 비밀 토큰은 목적에 맞는 방식으로 따로 발급합니다.

GUID와 UUID는 다른 것인가요?

같은 128비트 식별자를 부르는 다른 이름입니다. RFC 9562도 UUID를 GUID라고도 부른다고 적습니다. 다만 Microsoft 방식은 바이너리로 저장할 때 리틀 엔디언을 씁니다. 예를 들어 .NET의 Guid.ToByteArray()는 앞 네 바이트 묶음과 이어지는 두 바이트 묶음 두 개의 순서를 뒤집어 돌려주므로, 바이트로 주고받을 때는 순서를 확인합니다.