UUID(Universally Unique Identifier)는 전역적으로 고유한 128비트 식별자입니다. 중앙 서버 없이도 분산 시스템에서 충돌 걱정 없이 고유한 ID를 만들 수 있어 소프트웨어 개발에서 광범위하게 활용됩니다. 표준 형식은 8-4-4-4-12 패턴의 32자리 16진수 문자열이며(예: 550e8400-e29b-41d4-a716-446655440000), 이 도구에서는 v7, v4, v1 세 가지 버전과 다양한 포맷 옵션을 지원합니다.

작동 원리

UUID(Universally Unique Identifier)는 128비트 값으로, 중앙 서버 없이도 전역적으로 고유한 식별자를 생성합니다. v4 UUID는 crypto.getRandomValues()로 122비트의 무작위 값을 생성하고, 4비트는 버전(0100), 2비트는 변형(10)으로 고정합니다. 형식은 8-4-4-4-12의 16진수 문자열(예: 550e8400-e29b-41d4-a716-446655440000)입니다. 충돌 확률은 천문학적으로 낮아 실질적으로 고유성이 보장됩니다.

이용 방법

페이지를 열면 상단 카드에 UUID 하나가 자동으로 생성되어 표시됩니다. 오른쪽의 새로고침 버튼을 누를 때마다 새 값이 만들어지고, 복사 버튼으로 바로 클립보드에 담을 수 있습니다.
버전 드롭다운에서 v7(시간순 정렬), v4(랜덤), v1(타임스탬프) 중 용도에 맞는 버전을 선택합니다. 어떤 것을 골라야 할지 모르겠다면 기본값인 v7을 그대로 쓰면 됩니다.
형식 옵션으로 16진수 문자를 소문자(a-f) 또는 대문자(A-F)로 지정하고, 구분자 옵션에서 하이픈 포함 여부를 정합니다. 하이픈 없는 32자리 형태는 일부 시스템의 키 형식에 맞출 때 유용합니다.
여러 개가 필요하면 대량 생성 영역에서 개수(1~100)를 입력하고 대량 생성 버튼을 누릅니다. 출력 영역에 줄 단위로 나열되며, 복사 버튼으로 전체를 한 번에 복사해 스프레드시트나 SQL 스크립트에 붙여 넣을 수 있습니다.

어디에 쓰이나요

데이터베이스 기본 키: 자동 증가 정수 대신 UUID를 기본 키로 쓰면 여러 서버나 서비스가 중앙 조율 없이 각자 ID를 만들어도 충돌하지 않고, 데이터 병합이나 샤딩이 훨씬 수월해집니다. 다만 완전 무작위인 v4는 삽입 위치가 흩어져 B-tree 인덱스 성능에 불리할 수 있는데, 앞부분에 타임스탬프가 들어가 시간순으로 정렬되는 v7을 쓰면 이 문제가 크게 완화됩니다. 새 프로젝트라면 v7이 무난한 기본 선택입니다.

테스트 데이터와 목업 준비: API 테스트용 픽스처, 시드 데이터, 문서 예제에 넣을 식별자를 만들 때 대량 생성 기능이 특히 편리합니다. 100개 단위로 뽑아 CSV나 INSERT 문에 붙여 넣으면 반복 작업이 사라집니다.

파일명과 외부 노출용 식별자: 업로드 파일 이름, 주문 번호, 웹훅 이벤트 ID처럼 예측 불가능해야 하는 값에도 자주 쓰입니다. 순번 기반 ID와 달리 UUID는 값만 보고 전체 규모나 다음 값을 추측할 수 없기 때문입니다.

충돌 걱정은 사실상 하지 않아도 됩니다. v4 UUID는 122비트의 무작위성을 가지므로 가능한 조합이 약 5.3x10^36개에 달하고, 초당 수십억 개를 수년간 만들어도 같은 값이 두 번 나올 확률은 무시할 수 있는 수준입니다. 이것이 분산 시스템들이 중앙 발급 서버 없이 UUID를 신뢰하는 이유입니다.

자주 묻는 질문

v1, v4, v7은 무엇이 다른가요?

v1은 생성 시각(타임스탬프)과 노드 정보를 조합하는 방식이고, v4는 전체를 난수로 채우는 방식, v7은 앞 48비트에 밀리초 단위 Unix 타임스탬프를 두고 나머지를 난수로 채우는 최신 방식입니다. v1은 생성 시점이 값에 드러나고, v4는 완전히 예측 불가능하며, v7은 무작위성과 시간순 정렬 가능성을 동시에 얻습니다.

데이터베이스 키로는 어떤 버전이 좋나요?

정렬 가능한 v7이 인덱스 지역성(locality) 면에서 유리해 최근에는 v7이 우선 권장됩니다. 이미 v4를 쓰고 있는 시스템이라면 문제없이 계속 써도 되지만, 대량 삽입이 잦은 테이블을 새로 설계한다면 v7을 고려해 보세요. 생성 시각을 값에서 숨겨야 하는 경우에는 반대로 v4가 적합합니다.

정말 한 번도 겹치지 않나요?

이론적으로 충돌이 불가능한 것은 아니지만, v4 기준 122비트 난수 공간에서 충돌이 일어날 확률은 천문학적으로 낮습니다. 생일 역설을 감안해도 약 10^18개(백경 개)를 생성해야 충돌 확률이 의미 있는 수준에 도달하므로, 실무에서는 고유하다고 간주하고 설계합니다.

생성된 UUID가 서버에 기록되나요?

아니요. 모든 값은 브라우저의 crypto.getRandomValues()로 사용자 기기에서 직접 생성되며, 어떤 서버로도 전송되거나 저장되지 않습니다. 페이지를 닫으면 생성 기록도 함께 사라집니다.

하이픈을 빼고 써도 되나요?

하이픈은 8-4-4-4-12 자리를 나누는 표기 규칙일 뿐 값 자체에는 영향이 없습니다. 32자리로 저장하고 표시할 때만 하이픈을 붙이는 시스템도 많습니다. 다만 표준 형식을 기대하는 라이브러리나 유효성 검사기와 주고받을 때는 하이픈 포함 형태가 안전합니다.

UUID를 비밀번호 재설정 토큰 같은 보안 토큰으로 써도 되나요?

v4는 암호학적 난수로 만들어져 예측이 어렵지만, UUID는 본래 식별자이지 비밀값 설계가 아닙니다. 세션 토큰이나 API 키처럼 유출 시 피해가 큰 값에는 전용 난수 토큰 생성 방식을 쓰고, v1처럼 시간과 장치 정보가 드러나는 버전은 보안 용도로 절대 사용하지 마세요.

100개보다 많은 UUID가 필요하면 어떻게 하나요?

대량 생성은 한 번에 최대 100개까지 지원하므로, 그 이상이 필요하면 여러 번 나눠 생성해 이어 붙이면 됩니다. 각 배치는 서로 독립적인 난수로 만들어지기 때문에 몇 번을 반복해도 중복을 걱정할 필요는 없습니다. 수만 건 이상이 정기적으로 필요한 경우라면 애플리케이션 코드나 데이터베이스의 UUID 생성 함수를 이용하는 편이 효율적입니다.

대문자와 소문자 중 어느 쪽이 표준인가요?

RFC 4122는 출력 시 소문자를 권장하되, 입력을 받을 때는 대소문자를 구분하지 않고 처리하도록 정하고 있습니다. 특별한 이유가 없다면 소문자를 쓰는 것이 관례이며, 레거시 시스템이 대문자를 요구할 때만 대문자 옵션을 사용하면 됩니다.

간단한 팁

결과를 그대로 코드에 붙여 넣기 전에 한 번 더 확인하는 습관을 들이면 실수를 줄일 수 있습니다. 특히 UUID 생성기 같은 변환 도구는 양방향 변환이 가능한 경우가 많아, 원본으로 되돌려 보면서 검증하는 게 안전합니다.

같이 보면 좋은 도구

SQL 포매터 - SQL 쿼리 정렬
XML ↔ JSON 변환 - XML과 JSON 상호 변환
텍스트 이스케이프 - 특수문자 이스케이프 처리
Lorem Ipsum - 더미 텍스트 생성
번인 테스트 - 화면 번인 현상 검사

함께 보면 도움되는 글

브라우저에서 이미지 편집

UUID 생성기

UUID 생성기란?