UUID 생성기

UUID란?

UUID(Universally Unique Identifier)는 128비트의 고유 식별자로, RFC 4122 / RFC 9562에 정의되어 있습니다. 중앙 발급기관 없이도 충돌 가능성이 사실상 0에 가깝게 식별자를 생성할 수 있어 데이터베이스 기본 키, 분산 시스템, 파일 식별자 등에 널리 사용됩니다.

버전별 차이

• v4(랜덤) - 122비트 난수로 생성. 가장 흔히 쓰이며 예측 불가능합니다. 충돌 확률은 사실상 0에 수렴합니다.
• v7(시간 기반, 권장) - 앞 48비트가 Unix 밀리초 타임스탬프라 정렬 시 시간 순서가 보장됩니다. 데이터베이스 인덱스 친화적이며 최신 분산 시스템에서 v4의 대체재로 권장됩니다.
• NIL - 모든 비트가 0인 특수 UUID(00000000-0000-0000-0000-000000000000). 빈값을 표현할 때 사용합니다.

v7을 권장하는 이유

UUID v4는 완전 무작위라 데이터베이스 B-tree 인덱스에 삽입할 때 단편화가 발생하기 쉽습니다. v7은 시간 순으로 단조 증가하므로 인덱스 끝에 추가되어 INSERT 성능이 좋고, 생성 시각을 UUID 자체에서 추출할 수 있습니다.

UUID를 JSON 페이로드에 담아 처리한다면 JSON 포매터ㆍ변환기를, 구조화 데이터의 @id 값으로 활용한다면 JSON-LD 생성기도 함께 참고하세요.

UUID 사용 시 흔한 오해와 함정

UUID는 거의 무한히 생성 가능하지만 잘못 쓰면 데이터베이스 성능을 갉아먹거나 보안 문제를 일으킬 수 있습니다.

"v4 UUID는 절대 충돌하지 않는다"는 오해

v4는 122비트 무작위라 충돌 확률이 사실상 0이지만 수학적으로는 0이 아닙니다. 대규모 시스템에서는 그래도 DB의 UNIQUE 제약을 함께 두는 것이 안전합니다. 또한 약한 난수 생성기(예: Math.random())를 쓰면 예측이 가능해져 보안 토큰으로는 부적절합니다. 암호학적 안전 난수(crypto.getRandomValuesㆍcrypto.randomUUID)를 사용해야 합니다.

UUID를 DB 기본 키로 쓸 때 흔한 함정

• v4의 인덱스 단편화 - 무작위 순서로 INSERT되어 B-tree 인덱스 페이지가 자주 분할됩니다. 쓰기 성능 저하ㆍ인덱스 크기 비대화. v7(시간 정렬)이 대안.
• 16바이트 vs 36자 문자열 저장 - 문자열로 저장하면 36바이트(하이픈 포함). MySQL BINARY(16)ㆍPostgreSQL uuid 타입을 쓰면 16바이트로 절반 이하. 인덱스 크기ㆍ조회 속도 모두 유리.
• JOIN 성능 - 정수 ID(4ㆍ8바이트) 대비 UUID는 2~4배 큽니다. 대규모 JOIN이 많은 테이블은 정수 ID + UUID 별도 컬럼이 절충안.
• URL에 노출 - UUID 자체는 노출돼도 안전(추측 불가)하지만 36자라 URL이 길어집니다. 짧은 식별자가 필요하면 nanoidㆍbase62 인코딩 고려.

버전 선택 가이드

흔한 실수

• UUID를 그대로 비밀번호 토큰으로 사용 - v4는 안전하지만 v1ㆍv3ㆍv5는 예측 가능합니다. 비밀번호 재설정ㆍ세션 토큰은 v4 또는 별도 secure random 사용.
• 대소문자 검증 누락 - UUID 표기는 대소문자 무관(F47AC10Bㆍf47ac10b이 같은 값). DB 비교 시 대소문자 통일하지 않으면 중복 키처럼 보입니다.
• 하이픈 유무 혼용 - f47ac10b-58cc-...와 f47ac10b58cc...가 같은 UUID지만 문자열 비교에서는 다릅니다. 저장 형식 통일 필요.
• v1 사용 - MAC 주소를 포함해 호스트 식별이 가능합니다. 보안ㆍ프라이버시 이슈로 권장하지 않음.

자주 묻는 질문