UUID 완벽 가이드: 언제, 어떻게 사용해야 할까

Server room abstract

UUID(Universally Unique Identifier)는 128비트 식별자로, 일반적으로 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 형태로 표기됩니다. 개발자들은 UUID를 기본 키(primary key), 상관 ID(correlation ID), 불투명 토큰(opaque token)으로 활용합니다. 중앙 조정자 없이도 생성할 수 있으면서 충돌 가능성이 극히 낮기 때문입니다.

정수를 쓰면 안 되는 이유

자동 증가 정수는 단순하고 간결하지만 정보가 노출됩니다. 경쟁사가 주문 수를 추측하거나 ID를 순차적으로 탐색해 리소스를 수집할 수 있습니다. UUID는 사실상 추측이 불가능하며, URL이나 클라이언트 측 코드에 노출해도 안전합니다.

UUID 자체는 보안 기능이 아닙니다. 인가(authorization)가 필요하다면 서버에서 반드시 별도로 처리해야 합니다.

주요 UUID 버전

버전	생성 방식	일반적인 사용처
v1	MAC 주소 + 타임스탬프	레거시 용도; 개인정보 보호가 중요하다면 지양
v4	랜덤 비트	새로운 시스템의 기본 선택
v5	네임스페이스 + 이름의 SHA-1 해시	고정된 입력값으로 결정론적 ID 생성

현재 대부분의 애플리케이션은 기본 키로 UUID v4를 사용합니다. 시간 정렬 가능한 문자열이 필요한 팀은 ULID나 Snowflake ID를 선호하기도 하지만, UUID는 여전히 가장 널리 지원되는 방식입니다.

충돌 확률

v4의 경우, 초당 수십억 개의 ID를 생성하기 전까지는 충돌 가능성이 천문학적으로 낮습니다. 일반적인 웹 애플리케이션에서는 충돌이 발생하지 않는다고 봐도 무방합니다. 단, 랜덤 소스가 암호학적으로 안전해야 합니다. 보안에 민감한 ID에는 Math.random() 대신 OS나 언어의 CSPRNG를 사용하세요.

// 브라우저: 가능하면 crypto.randomUUID() 사용 권장
const id = crypto.randomUUID();
console.log(id); // 예: 9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d

실용적인 팁

데이터베이스 인덱스: 랜덤 UUID는 순차 ID보다 B-트리 인덱스를 더 많이 단편화합니다. 대용량 환경에서 삽입 성능이 중요하다면 PostgreSQL의 gen_random_uuid(), 시간 순서 기반의 UUID v7, 또는 COMB 방식을 고려해보세요.
로그 및 트레이싱: 요청마다 UUID를 상관 ID로 사용하면 여러 서비스에 걸친 로그를 쉽게 추적할 수 있습니다.
테스트: 고정된 값에 의존하지 않도록 픽스처에서 새 UUID를 생성하세요. 재현 가능성이 필요한 경우에는 v5나 시드 기반 생성기가 적합할 수 있습니다.

브라우저에서 직접 사용해보기

무료 UUID Generator를 사용하면 v4 방식의 식별자를 즉시 생성할 수 있습니다. 회원가입 불필요, 모든 처리가 브라우저 탭 안에서 로컬로 실행됩니다.

관련 작업으로는 체크섬을 위한 Hash Generator나, API에서 UUID와 함께 자주 사용되는 토큰을 디버깅할 때 유용한 JWT Decoder도 살펴보세요.