다른 사람이 만든 것과 겹치지 않고, 들어본 적도 없는 기기에서, 누구의 허락도 받을 필요 없이 만들 수 있는 식별자가 필요하신가요? 그것이 바로 UUID가 하는 일입니다. UUID는 친숙한 8-4-4-4-12 패턴의 36자로 표기되는 128비트 숫자이며, 누가 어떤 식별자를 가지는지 아무도 조율하지 않아도 두 개의 값이 절대 같을 수 없도록 설계되었습니다. 이 무료 생성기는 브라우저에서 직접 UUID를 만들어 냅니다. '버전'에서 버전을 선택하고, '생성 개수'에 필요한 개수를 입력한 다음 '결과 생성'을 누르세요. 페이지는 대부분의 프로젝트에서 요구하는 v4 하나를 생성한 상태로 열리므로, 클릭 한 번이면 첫 번째 식별자를 얻을 수 있습니다.
모든 식별자는 Web Crypto API를 통해 브라우저에서 생성됩니다. 버전 4는 브라우저가 지원하는 경우 crypto.randomUUID()를 사용하고, 그렇지 않은 경우 crypto.getRandomValues()를 사용합니다. 이는 Math.random()과 같은 JavaScript 의사 난수 함수가 아니라 암호학적으로 강력한 난수 소스입니다. 버전 7은 앞부분에 48비트 밀리초 타임스탬프를 배치하고, 동일한 밀리초 내에서 증가하는 12비트 카운터를 둔 다음 62개의 무작위 비트를 추가합니다. 이것이 바로 RFC 9562에 설명된 정렬 방법이며, 이 카운터 덕분에 수천 개의 배치가 뒤섞이지 않고 순서대로 출력됩니다. 버전 1은 타임스탬프를 멀티캐스트 비트가 설정된 무작위 노드 식별자와 결합하므로, 1990년대의 초기 구현 방식처럼 네트워크 카드의 주소를 전달하지 않습니다. 버전 3과 버전 5는 무작위가 아닙니다. 각각 MD5와 SHA-1을 사용하여 네임스페이스와 이름을 함께 해시하며, 이 해싱 과정 역시 사용자 기기에서 발생합니다. 어떤 데이터도 서버로 전송되거나 기록되지 않으며, 페이지가 로드된 후에는 인터넷 연결이 끊겨도 계속 작동합니다.
'버전'은 다른 모든 것을 결정하는 필드입니다. 버전 4는 122개의 무작위 비트로 구조가 전혀 없습니다. 기본값이며, 식별자가 고유하기만 하면 될 때 가장 적합한 선택입니다. 버전 7은 62개의 무작위 비트를 유지하되 생성된 시간으로 시작하므로, 세트를 생성된 순서대로 정렬할 수 있습니다. 그래서 식별자가 데이터베이스 키가 될 때 선택해야 하는 버전입니다. 버전 1은 원래의 시간 기반 체계로, 이를 여전히 요구하는 시스템을 위해 여기에 유지됩니다. 버전 3과 5는 특이한 쌍으로, 결정론적입니다. 즉, 동일한 입력은 항상 동일한 식별자를 생성하며 두 개의 추가 필드를 필요로 합니다. 하나는 DNS, URL, OID, X.500 등의 표준 공간이거나 사용자가 직접 지정하는 '사용자 지정'인 '네임스페이스'이고, 다른 하나는 식별되는 문자열인 '이름'입니다. URL 네임스페이스와 https://example.com/a를 v5에 입력하면 오늘이든 내일이든, 혹은 다른 사람의 컴퓨터에서든 동일한 UUID를 얻게 됩니다. 그렇기 때문에 v3나 v5를 선택하면 '생성 개수' 필드가 사라집니다. 하나의 결정론적 값을 천 번 복사해 봐야 결국 똑같은 결정론적 값의 천 개 복사본일 뿐이기 때문입니다. 다른 모든 버전에 대해 '생성 개수'는 1에서 1000까지 입력할 수 있습니다.
네 개의 스위치는 밑바탕이 되는 128비트는 변경하지 않고 출력 형태를 바꿉니다. '대문자'는 16진수 숫자를 대문자로 출력하고, '하이픈 제외'는 일부 열이나 파일 이름에서 선호하는 간결한 32자 형식을 제공하며, '중괄호'는 값을 { } 기호로 감쌉니다. 이는 Windows와 .NET 환경에서 GUID라고 부르는 형태입니다. '고급 옵션' 아래의 urn:uuid:는 이를 공식적인 URN으로 만드는 접두사를 추가합니다. 이 옵션이 켜져 있는 동안에는 '중괄호' 및 '하이픈 제외'를 끕니다. 표준에서 허용하는 URN 형식은 정확히 하나뿐이며, 하이픈이 포함된 정식 형태이기 때문입니다. '복사 형식'은 가져갈 배치를 결합하는 방법을 결정합니다. 한 줄에 하나씩 놓거나, 쉼표로 구분하거나, 코드의 배열에 바로 붙여넣을 수 있도록 각 값을 따옴표로 묶고 끝에 쉼표를 붙입니다. 결과 아래에는 v4의 경우 122, v7의 경우 62 등 무작위성(비트)을 알려주는 줄이 표시되며, v7의 경우 배치의 첫 번째 식별자에 인코딩된 타임스탬프도 표시되므로 값 내부의 시간이 암시적인 것이 아니라 명시적으로 보입니다. '모두 복사'와 '파일로 저장' 모두 '복사 형식'을 따릅니다. '기록'은 브라우저에 최근 10개의 배치를 유지합니다. 하나를 클릭하여 다시 불러오거나, 단일 항목을 복사 또는 삭제하거나, 전체를 지울 수 있습니다. '지우기'는 설정은 그대로 두고 결과만 비우며, 50개를 초과하는 식별자 목록은 50개의 행 대신 스크롤 가능한 하나의 블록이 됩니다.
이 페이지에서 가장 중요한 것은 기본 키(primary key)로서의 v4와 v7 간의 차이이며, 이는 취향의 문제가 아닙니다. 데이터베이스 인덱스는 정렬된 순서로 유지되는 트리이며, 새로운 키가 해당 순서의 어디에 위치하는지가 삽입 작업의 부하를 결정합니다. v4 키는 무작위이므로 연속된 삽입이 인덱스의 서로 무관한 구석에 위치하게 됩니다. 꽉 찬 페이지는 분할되고, 데이터베이스가 메모리에 유지하는 트리의 부분은 다음 삽입에 필요한 부분인 경우가 드물며, 인덱스는 가리키는 행보다 훨씬 더 크고 단편화된 상태로 끝납니다. v7 키는 현재 밀리초로 시작하므로 연속된 삽입이 트리의 오른쪽 끝에 모이게 됩니다. 이는 자동 증가하는 정수(auto-incrementing integer)가 생성하는 패턴이자 인덱스 구조가 구축된 기준 패턴입니다. 이것이 핵심적인 트레이드오프입니다. v7은 순차적인 키의 삽입 성능을 얻는 동시에, 중앙 서버에 요청하지 않고도 식별자를 생성할 수 있는 UUID 본연의 이점을 유지합니다. 그 대가로 생성 시간이 식별자 내부에서 읽힐 수 있게 되며, 이것이 문제가 되는지 여부는 포맷이 아니라 데이터의 특성에 관한 문제입니다.
어떤 것도 UUID의 고유성을 확인하지 않습니다. 크기 자체가 보장입니다. 레지스트리도, 서버 왕복도, 조회도 없습니다. 생성기가 숫자를 생성하여 건네줄 뿐이며, 두 값이 충돌하지 않는 이유는 단순히 2^122개의 가능한 버전 4 값이 있기 때문입니다. 이는 약 5.3 × 10^36입니다. 생일 문제(birthday problem)는 이를 평가하는 가장 정직한 방법입니다. 단 두 개라도 일치할 확률이 50%가 되려면 대략 2.7 × 10^18개의 식별자가 필요하며, 이는 86년 동안 초당 10억 개의 새로운 UUID를 생성해야 하는 수치입니다. 이 수치가 약속하는 것과 약속하지 않는 것을 정확히 아는 것이 중요합니다. 이는 산술적인 보장이 아닌 통계적 보장이며, 기반이 되는 무작위성이 진짜일 때만 성립합니다. 시드가 잘못된 생성기나 엔트로피 풀과 함께 복제된 가상 머신은 포맷이 감지할 수 없는 방식으로 이 보장을 깨뜨립니다. 버전 7은 질문을 더 좁힙니다. 단일 밀리초 내에서 하나의 생성기는 자신을 전혀 반복할 수 없습니다. 카운터가 무작위 주사위를 굴리는 대신 증가하기 때문이며, 독립적인 생성기 사이에서는 62개의 무작위 비트가 그 역할을 수행합니다.
UUID는 식별자일 뿐, 비밀번호가 아닙니다. 버전 4는 예측할 수 없으며, 이는 사람들이 비밀번호 재설정 링크, 추측 불가능한 URL, 세션 토큰, API 키 등 비밀 데이터로 취급하도록 유혹합니다. 예측 불가능성은 사실이지만 비밀성은 값이 처리되는 방식의 속성입니다. 식별자는 설계상 부주의하게 다뤄집니다. URL에 배치되고, 브라우저 기록, 서버 로그, 리퍼러 헤더, 분석 시스템에 남으며, 채팅 메시지에 복사됩니다. 다른 버전들은 상황이 더 안 좋습니다. 버전 1과 버전 7은 모두 생성 시점을 인코딩하므로 이를 가진 사람은 누구나 언제 만들어졌는지 대략 알 수 있고 함께 만들어진 모든 것의 범위를 좁힐 수 있습니다. 버전 3과 5는 의도적으로 결정론적입니다. 이메일 주소의 v5 UUID는 해시된 비밀이 아니며 동일한 주소를 가진 누구나 1초 안에 계산할 수 있는 값입니다. 대상을 명명하는 데 UUID를 사용하세요. 값이 알려지지 않아야 하는 경우에는 비밀번호 생성기나 비밀 데이터를 위해 구축된 라이브러리의 토큰을 사용해야 합니다.
왜 이 UUID 생성기를 선택해야 할까요?
- 브라우저 전용 생성: 식별자는 사용자 기기에서 만들어지며 외부로 전송되지 않습니다
- Web Crypto API 무작위성: Math.random()이 아닌 암호학적으로 안전한 방식
- 한 곳에 모인 5가지 버전: 도구를 바꿀 필요 없이 v1, v3, v4, v5, v7 지원
- 진정한 순서의 v7: RFC 9562에 명시된 밀리초 내부의 카운터
- 4개의 표준 네임스페이스 또는 사용자 지정을 통한 결정론적 v3 및 v5
- 한 번에 최대 1000개 생성, 50개 초과 시 간결한 스크롤 목록 제공
- 모든 일반적인 형태: 하이픈 포함, 제외, 대문자, 중괄호 또는 urn:uuid: URN
- 코드에 바로 붙여넣을 수 있도록 줄바꿈, 쉼표 또는 따옴표 값으로 복사
- 무제한 및 무료: 가입이나 사용 제한이 없으며 저희 서버에 남는 데이터도 없습니다
UUID는 이름이 사용 가능한지 확인하기 전에 무언가의 이름을 지정해야 하는 모든 곳에 등장합니다. 애플리케이션 코드는 삽입하려는 행을 위해 이를 생성하여 객체가 데이터베이스에 도달하기도 전에 정체성을 갖도록 하고, 쓰기 작업이 진행되는 동안 클라이언트가 이를 참조할 수 있게 합니다. 분산 시스템은 더 많이 의존합니다. 하나의 테이블에 쓰는 여러 서비스, 비행기 안에서 오프라인으로 레코드를 생성하는 모바일 클라이언트, 이미 처리한 메시지를 인식해야 하는 대기열(queue) 등 이들 중 어느 것도 공유 카운터의 순서를 기다릴 수 없습니다. 버전 5는 이미 가지고 있는 것에서 파생된 안정적인 식별자라는 다른 요구를 충족시킵니다. 동일한 문서, 동일한 URL 또는 동일한 계정은 항상 동일한 UUID에 매핑되므로 중복 없이 가져오기를 두 번 실행할 수 있습니다. 그 외의 곳에서는 단순히 시스템이 요구하는 형식입니다. 로그와 추적(trace)을 관통하는 상관 식별자, 수천 명의 사용자가 업로드한 파일이 하나의 버킷에 모일 때 충돌하지 않을 파일 이름, Windows 레지스트리 키, 실제 데이터처럼 보여야 하는 테스트 픽스처(test fixture) 등이 있습니다.
알아두면 좋은 몇 가지 정직한 한계가 있습니다. 하나의 배치는 하나의 버전입니다. '버전' 필드의 값은 배치 내의 모든 항목에 적용되므로 v4 배치와 v7 배치는 두 개의 서로 다른 배치입니다. 이것은 생성기이지 검사기가 아닙니다. 버전을 읽거나 타임스탬프를 확인하기 위해 UUID를 붙여넣는 것은 이 페이지에서 지원하지 않습니다. '파일로 저장' 기능은 CSV나 JSON이 아닌 일반 텍스트 파일을 작성합니다. 버전 7은 결함이 아니라 진정한 트레이드오프로서 언제 생성되었는지 밀리초 단위까지 공개하며, 버전 1 역시 같은 방식으로 시간을 노출합니다. 데이터에 있어 이것이 문제가 된다면, 버전 4가 아무런 정보도 누출하지 않는 선택이 됩니다. 표준에서 온 두 가지 특수 값은 버전이 아니므로 '버전' 필드의 옵션에는 없지만, 여기서 복사할 수는 있습니다. 바로 nil UUID인 00000000-0000-0000-0000-000000000000과 max UUID인 ffffffff-ffff-ffff-ffff-ffffffffffff입니다. 이 페이지의 모든 것은 2024년에 RFC 4122를 대체한 사양인 RFC 9562를 따르므로, 출력 결과는 UUID를 다루는 모든 라이브러리, 데이터베이스 또는 API에서 수용됩니다. 이러한 한계 내에서 보장은 강력합니다. 모든 식별자는 사용자 컴퓨터에서 암호학적으로 안전한 무작위성을 바탕으로 표준에 맞게 생성되며, 다른 누구도 이를 절대 볼 수 없습니다.