식별자를 접근 제어로 사용하는 경우
UUID는 레코드를 식별할 뿐 그 레코드를 읽거나 바꿀 권한을 증명하지 않습니다. 값이 추측하기 어려워 보여도 인증과 인가 검사를 유지하고, 비밀번호·bearer token·비공개 링크의 비밀값으로 사용하지 마세요.
UUID v4 생성기 | Web Crypto 기반 RFC 9562 GUID 일괄 생성
변환브라우저에서 실행(업로드 없음)
브라우저가 제공하는 암호학적으로 강한 난수로 UUID 버전 4 식별자를 1개부터 100개까지 생성합니다. 생성 엔진은 RFC 9562의 버전 비트와 IETF variant 비트를 설정하고, 약한 난수 대체 경로를 거부하며, 같은 배치에서 중복이 나오면 제한된 횟수만큼 다시 시도합니다. 모든 값은 기기 안에서 처리되며 정규형·compact 형식과 대소문자를 선택해 그대로 복사하거나 내려받을 수 있습니다.
다음에 할 작업
관련 작업 흐름을 이어가거나 이 작업 다음에 자주 사용하는 도구를 열어보세요.
작업 가이드
SHA-256으로 파일 체크섬 확인하기
로컬 파일 모드와 명시적인 체크섬 비교 기능으로 릴리스 파일, 백업, 설치 프로그램의 바이트 동일성을 확인합니다. 일치는 배포자의 신뢰나 악성 코드 부재를 인증하지 않습니다.
열기관련 도구CSV JSON 양방향 변환기 | 로컬·손실 방지 변환
문자열 보존 타입 처리, 엄격한 구조 검사, 보호된 스프레드시트 출력으로 CSV와 JSON을 로컬 변환합니다.
열기관련 도구파일 해시·체크섬 생성기
UTF-8 텍스트나 파일 원본 바이트를 해시하고 전체 체크섬을 로컬에서 비교합니다.
열기관련 도구JSON 포매터 | 원문을 보존해 보기 좋게 정리·압축
중복 키와 숫자 원문을 보존하며 엄격한 JSON을 로컬에서 정리하거나 압축합니다.
열기이 도구 사용 방법
1부터 100 사이의 정수 개수를 입력합니다. 이 한도는 동기 실행 시간과 다운로드 결과 크기를 제한합니다.
일반적인 8-4-4-4-12 정규형이면 하이픈을 유지하고, 대상 시스템이 32자리 16진수를 허용할 때만 하이픈을 끕니다.
관례적인 표시는 소문자로 두고, 기존 계약이 요구하는 경우에만 대문자 옵션을 켭니다.
생성을 실행합니다. 브라우저는 시도마다 암호학적으로 강한 난수 16바이트를 만들고 v4 버전과 IETF variant 비트를 설정합니다.
복사하기 전에 줄 수, 버전 숫자 4, variant 시작 문자 8·9·a·b, 대상 스키마 형식을 확인합니다.
전체 결과를 복사하거나 UTF-8 .txt 파일로 내려받고, 충돌 영향이 있는 저장소에는 UNIQUE 제약을 유지합니다.
이 도구를 써야 할 때
데이터베이스 레코드와 seed 행
서비스마다 독립적으로 레코드·migration·seed 식별자를 만들고, 최종 저장 단계에서는 데이터베이스 UUID 타입과 UNIQUE 제약으로 검증합니다.
관측용 상관관계 ID
API, queue, background worker를 지나는 요청·event·job에 상관관계 ID를 붙여 중앙 번호 발급기 없이 로그 흐름을 추적합니다.
결정론적 테스트 fixture
복사한 운영 식별자를 생성 값으로 교체하고, 검토가 끝난 ID를 mock·snapshot·API 응답 fixture에 고정합니다.
로컬 산출물 이름
비밀성이 필요하지 않지만 이름 충돌을 줄여야 하는 임시 파일, export 묶음, 오프라인 초안과 로컬 산출물에 사용합니다.
분산 식별자 할당
연결이 끊긴 client나 분산 producer가 동기화 전에 식별자를 할당하고, 서버의 충돌 처리는 최종 안전장치로 유지합니다.
흔한 실수
데이터베이스 고유성 제약을 제거하는 경우
UUID v4 충돌 가능성은 극히 작지만 수학적으로 0은 아닙니다. 중복이 데이터 손상을 일으키는 저장소에는 UNIQUE 제약을 유지하고, 충돌 insert가 거절되는 경로도 처리해야 합니다.
스키마 확인 없이 표시 형식을 바꾸는 경우
많은 스키마는 소문자 8-4-4-4-12 정규형을 요구합니다. 하이픈 없는 compact 값과 대문자 값도 같은 128비트를 나타내지만 엄격한 parser가 거부할 수 있으므로 대상 계약을 먼저 확인하세요.
시간 순 정렬을 기대하는 경우
무작위 UUID v4는 생성 시각 순서로 정렬되지 않습니다. 쓰기가 많은 테이블에서는 데이터베이스에 따라 인덱스 단편화가 생길 수 있으므로 시간 순서가 중요하면 키와 인덱스 전략을 따로 결정하세요.
결정론적 fixture를 매번 다시 생성하는 경우
snapshot이나 golden-file 테스트를 실행할 때마다 새 ID를 만들면 기대 결과가 계속 달라집니다. UUID를 한 번 생성해 검토한 뒤 fixture에 고정하고, 난수 자체를 시험하는 경우에만 실행 중 생성을 사용하세요.
예시
데이터베이스 seed 레코드 ID
데이터베이스 UNIQUE 제약을 유지하면서 서로 다른 레코드에 넣을 정규형 식별자 3개를 준비합니다.
입력
개수: 3; 하이픈: 포함; 대문자: 사용 안 함출력
9f8f12a4-7b9e-4e7d-a8c2-4f6c9ad12701
47d9d9d2-4a15-47bf-8f90-bd2a6f5e1c6a
c7aaf71d-b25d-4e2f-9a5e-7d250df3c8a9요청과 background job 상관관계
실제 운영 ID를 재사용하지 않고 요청과 background job에 별도 식별자를 붙여 복사한 로그를 연결합니다.
입력
개수: 2; 소문자 정규형 출력출력
d9428888-122b-4d70-9f63-35c1db6c3f9e
6ba7b810-9dad-4f11-80b4-00c04fd430c8고정 API fixture 식별자
한 번 생성한 값을 검토하고 fixture에 저장해 이후 테스트 실행의 결과를 고정합니다.
입력
개수: 3; 생성한 줄을 테스트 fixture에 저장출력
3f2e2b6a-7f2c-4e3a-9a21-6e98785f4c20
7a6b3d94-44e3-4a70-85c0-31278f7d1b42
b91d1c0e-6ef2-49e5-9f59-1f81d4f3be76RFC 9562 UUID v4 생성 엔진의 동작 방식
RFC 9562는 UUID를 128비트로 정의하며 RFC 4122를 대체합니다. 버전 4에서는 버전 4비트와 IETF variant 2비트를 제외한 122비트가 난수 또는 의사난수입니다.
도구는 시도마다 crypto.getRandomValues()에서 16바이트를 받습니다. 6번 octet 상위 4비트를 0100으로 설정해 버전 4를 표시하고, 8번 octet 상위 2비트를 10으로 설정해 IETF variant를 표시합니다.
정규형은 xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx이며 y는 8, 9, a, b 중 하나입니다. 하이픈 제거와 대문자 변환은 128비트 식별자 자체를 바꾸지 않습니다.
1~100개로 제한된 현재 배치의 값을 Set으로 추적합니다. 난수 공급자가 같은 값을 반환하면 고정된 한도까지 재시도하고, 중복을 반환하거나 약한 공급자로 전환하는 대신 오류로 중단합니다.
난수는 충돌을 매우 드물게 만들 뿐 불가능하게 하지 않으며 어떤 인가 의미도 제공하지 않습니다. 저장소는 고유성을 강제하고, 보호된 리소스는 목적에 맞는 인증과 인가로 별도 보호해야 합니다.
자주 묻는 질문
UUID v4 두 개가 같아질 수 있나요?
가능하지만 제대로 생성한 UUID v4끼리 충돌할 확률은 극히 작습니다. 버전과 variant 필드를 제외한 122비트가 난수이기 때문입니다. 중복의 영향이 있는 시스템은 그래도 고유성 제약을 적용하고 충돌을 처리해야 합니다.
왜 RFC 4122 대신 RFC 9562를 표시하나요?
RFC 9562는 현재 IETF UUID 표준이며 RFC 4122를 대체합니다. UUID v4의 익숙한 8-4-4-4-12 텍스트 형식, 버전 숫자 4, IETF variant는 유지되므로 기존 정규형 v4 값과 호환됩니다.
UUID v4와 UUID v7 중 무엇을 써야 하나요?
무작위 식별자와 폭넓은 호환성이 우선이면 v4를 사용합니다. UUID v7은 Unix 밀리초 시각을 포함해 시간 순 정렬을 위해 설계됐지만, 수신 시스템이 해당 버전과 정렬 동작을 명시적으로 지원할 때 선택하세요.
생성한 UUID가 업로드되거나 로그에 남나요?
생성한 UUID 값은 애플리케이션 서버로 전송하지 않습니다. 브라우저의 crypto.getRandomValues()로 생성하며 분석에는 요청 개수 같은 집계 옵션만 기록하고 생성된 식별자는 넣지 않습니다.
UUID v4로 비공개 리소스를 보호할 수 있나요?
아니요. 무작위 UUID는 비밀값이 아니며 인증, 인가, 비밀번호 또는 전용 bearer token을 대신할 수 없습니다. ID가 노출되는 문제와 그 리소스를 사용할 권한은 별도로 다뤄야 합니다.
UUID v4를 데이터베이스 primary key로 써도 되나요?
중앙 번호 발급기 없이 만들 수 있어 분산 primary key로 실용적입니다. 쓰기가 많은 테이블에 적용하기 전에는 UNIQUE 제약, 인덱스 지역성, 저장 크기, 데이터베이스의 UUID 전용 타입을 함께 검토하세요.
하이픈 없는 UUID나 대문자 UUID는 다른 ID인가요?
하이픈과 문자 대소문자는 표시 방식만 바꿉니다. 정규형은 8-4-4-4-12 형태의 소문자 16진수이며, 대상 계약이 허용할 때만 compact 또는 대문자 출력을 사용하세요.
이 도구를 검증한 방법
관리 및 검수 SimpleWebUtils검토일
검증 방법: UUID v4 생성기 검증에는 “운영 형태의 API 식별자 세 개 교체”에 적힌 정확한 입력을 사용했습니다. 정상 경로에서 “식별자 필드와 관계를 전부 매핑하기”, “제한된 배치와 정규 형식 선택하기” 단계를 실행한 뒤 생성된 값이나 파일을 문서 결과와 맞춰 봤습니다. 위험 검토 항목은 “같은 entity를 서로 다른 값으로 교체”, “충돌이 드물다는 이유로 UNIQUE 제약 제거”였습니다.
기대 결과: 교체 ID 세 개는 모두 소문자 정규형 UUID v4를 만족하고 저장한 fixture에서 고정됐으며, 복사된 운영 식별자를 포함하지 않았습니다.
공식 출처와 표준
- RFC 9562: Universally Unique IDentifiers (UUIDs)RFC Editor / IETF
관련 작업 가이드
도구를 열기 전에 자주 쓰는 작업 흐름과 예시를 확인하세요.
작업 가이드
SHA-256으로 파일 체크섬 확인하기
로컬 파일 모드와 명시적인 체크섬 비교 기능으로 릴리스 파일, 백업, 설치 프로그램의 바이트 동일성을 확인합니다. 일치는 배포자의 신뢰나 악성 코드 부재를 인증하지 않습니다.
작업 가이드운영 데이터를 복사하지 않고 테스트 픽스처 만들기
대표 픽스처는 실제 사람, 식별자, 비밀값을 유지하지 않으면서 운영 레코드의 형태와 제약을 보존해야 합니다. 이 흐름은 대상 스키마를 먼저 기록하고 제한된 정상 값만 생성한 뒤 최솟값, 최댓값, 중복, 빈 값, 잘못된 형식을 의도적으로 추가합니다. 실제 가져오기 경로에서 인코딩을 검증하고 재현성이 필요한 테스트에는 결과를 고정합니다.
작업 가이드운영 ID를 복사하지 않고 UUID v4 테스트 fixture 만들기
운영 식별자를 생성한 UUID v4로 교체하면서 각 필드의 문법과 관계를 보존하는 작업 흐름입니다. 스키마 매핑, 브라우저 로컬 일괄 생성, 버전·중복 검사, 고정 fixture 저장, 데이터베이스 제약, 그리고 레코드 식별자와 인가 사이의 보안 경계를 함께 다룹니다.
관련 도구
관리 중인 다른 작업 흐름을 이어서 사용해 보세요
CSV JSON 양방향 변환기 | 로컬·손실 방지 변환
문자열 보존 타입 처리, 엄격한 구조 검사, 보호된 스프레드시트 출력으로 CSV와 JSON을 로컬 변환합니다.
변환
파일 해시·체크섬 생성기
UTF-8 텍스트나 파일 원본 바이트를 해시하고 전체 체크섬을 로컬에서 비교합니다.
인코딩
JSON 포매터 | 원문을 보존해 보기 좋게 정리·압축
중복 키와 숫자 원문을 보존하며 엄격한 JSON을 로컬에서 정리하거나 압축합니다.
포맷팅
랜덤 테스트 데이터 워크벤치 | 숫자·문자열 생성
편향 없는 숫자와 설정 가능한 고유 문자열을 생성하고 줄, CSV, JSON으로 내보냅니다.
변환
Unix 타임스탬프 변환기
정확한 Unix epoch 단위, 복사한 로그, 시간대 ISO 날짜를 로컬에서 변환합니다.
변환