고유 식별자(UUID) 생성 및 포맷 변환
테이블의 고유 식별자로 사용
세션 ID 또는 API 키 생성
고유한 파일명으로 충돌 방지
중앙 서버 없이 고유 ID 생성
UUID(Universally Unique Identifier)는 전 세계적으로 고유한 128비트 식별자 표준입니다. RFC 4122 표준에 따라 8-4-4-4-12 형식의 16진수 문자열로 표현됩니다. 중앙 서버의 조율 없이도 독립적으로 생성할 수 있어 분산 시스템에서 고유 식별자가 필요할 때 특히 유용합니다.
UUID v1은 현재 시간과 MAC 주소를 기반으로 생성되어 시간순 정렬이 가능하지만 생성 시스템의 MAC 주소가 노출될 수 있습니다. UUID v4는 완전히 무작위로 생성되어 보안상 안전하며 현재 가장 많이 사용됩니다. UUID v7은 최신 표준으로 타임스탬프 기반이면서 무작위성도 포함하여 데이터베이스 인덱스 성능에 유리합니다.
UUID v4 기준으로 이론적 충돌 확률은 매우 낮습니다. 10억 개의 UUID를 생성해도 충돌 확률이 0.00000000001% 미만으로 실용적으로는 충돌이 발생하지 않습니다. 단, 암호학적으로 안전한 난수 생성기(CSPRNG)를 사용해야 하며 Math.random() 같은 일반 난수 함수는 피해야 합니다.
데이터베이스의 기본 키(Primary Key)로 사용하면 여러 서버에서 독립적으로 레코드를 생성하고 나중에 병합할 수 있습니다. 파일 저장 시 UUID를 파일명으로 사용하면 이름 충돌 없이 안전하게 저장할 수 있습니다. API 요청 추적, 세션 관리, 이벤트 소싱 등 고유 식별이 필요한 모든 시스템에서 활용됩니다.
UUID는 RFC 4122에 정의된 국제 표준으로 32개의 16진수와 4개의 하이픈으로 구성된 총 36자리 문자열입니다. 내부적으로 버전 번호와 변형(variant) 정보를 포함하며, 이를 통해 UUID가 어떤 방식으로 생성되었는지 식별할 수 있습니다. 현재 v1부터 v8까지 여러 버전이 표준화되어 있으며 용도에 따라 적합한 버전을 선택해야 합니다.
UUID를 데이터베이스 기본 키로 사용하면 마이크로서비스 아키텍처에서 서비스 간 데이터 통합이 용이해집니다. 그러나 UUID는 순차적이지 않아 B-트리 인덱스 성능을 저하시킬 수 있으므로 UUID v7이나 ULID 같은 순서 보장 ID를 대안으로 고려할 수 있습니다. PostgreSQL은 uuid 네이티브 타입을, MySQL 8.0 이상은 UUID_TO_BIN() 함수를 제공하여 효율적으로 저장할 수 있습니다.
단순 고유 식별자가 필요하다면 UUID v4가 가장 적합하며 생성이 간단하고 보안성이 높습니다. 시간순 정렬이 필요한 로그나 이벤트 시스템에는 UUID v1이나 v7이 적합합니다. 네임스페이스 기반의 결정론적 UUID가 필요하다면 v3(MD5 기반) 또는 v5(SHA-1 기반)를 사용하면 같은 입력에 대해 항상 같은 UUID를 생성할 수 있습니다.