UUID 사용법을 제대로 익혀두면 서버가 여러 대로 늘어나도 중복 없는 고유 식별자를 만들 수 있습니다. 자동 증가 정수 키만 쓰다가 분산 환경이나 외부 공개 API를 만나면 반드시 마주치게 되는 주제이므로, 개념부터 실무 적용까지 순서대로 정리해 보겠습니다.
1단계: UUID의 구조와 표기 방식 이해하기
UUID는 128비트 길이의 값이며, 사람이 읽을 때는 16진수 32자리를 하이픈으로 나눈 8-4-4-4-12 형식으로 표기합니다. 하이픈을 포함하면 총 36자입니다.
550e8400-e29b-41d4-a716-446655440000세 번째 그룹의 첫 글자는 버전 번호를, 네 번째 그룹의 첫 글자는 변형(variant) 정보를 담습니다. 위 예시의 41d4에서 앞자리 4는 이 값이 버전 4 UUID라는 뜻입니다. 문자열만 보고도 어떤 방식으로 만들어진 값인지 바로 확인할 수 있습니다.
2단계: 버전별 차이를 알고 목적에 맞게 고르기
UUID는 생성 방식에 따라 여러 버전으로 나뉩니다. 무작정 v4만 쓰기보다는 용도에 맞는 버전을 선택하는 것이 좋습니다.
| 버전 | 생성 방식 | 주요 용도 |
|---|---|---|
| v1 | 타임스탬프 + 노드 정보 | 생성 시각 추적이 필요한 레거시 시스템 |
| v3 | 네임스페이스 + MD5 해시 | 같은 입력에 항상 같은 값이 필요한 경우 |
| v4 | 난수 기반 | 일반적인 식별자, 세션 키, 파일명 |
| v5 | 네임스페이스 + SHA-1 해시 | v3의 대체, 결정적 식별자 생성 |
| v7 | 유닉스 밀리초 시각 + 난수 | 데이터베이스 기본 키, 시간순 정렬 |
v7은 RFC 9562에 정식 포함된 비교적 최근 규격입니다. 앞부분이 시각 정보라서 생성 순서대로 대략 정렬되며, 뒤쪽 난수 덕분에 값 자체를 추측하기는 어렵습니다.
3단계: 환경별 UUID 생성 코드 작성하기
대부분의 언어는 표준 라이브러리만으로 UUID를 만들 수 있습니다. 외부 패키지를 먼저 찾기 전에 내장 기능부터 확인하시기 바랍니다.
- JavaScript:
crypto.randomUUID()한 줄로 v4 생성이 가능하며 최신 브라우저와 Node.js 모두 지원합니다. - Python:
import uuid후str(uuid.uuid4())를 사용합니다. - Java:
UUID.randomUUID().toString()으로 생성합니다. - PHP:
ramsey/uuid패키지의Uuid::uuid4()가 사실상 표준입니다. - MySQL:
SELECT UUID();는 v1을 반환하므로 버전 차이에 유의해야 합니다. - PostgreSQL: 13 버전 이상에서
gen_random_uuid()를 별도 확장 없이 쓸 수 있습니다.
테스트 데이터를 채우거나 설정 파일에 넣을 값이 몇 개만 필요한 상황이라면, 코드를 작성하는 대신 UUID 생성기로 즉시 뽑아 쓰는 편이 빠릅니다.
Math.random() 같은 일반 난수 함수는 암호학적으로 안전하지 않아 값이 예측될 수 있고, 버전 및 변형 비트가 어긋나면 표준 파서에서 오류가 발생합니다.4단계: 데이터베이스에 효율적으로 저장하기
UUID를 기본 키로 쓸 때 가장 흔한 실패 사례는 VARCHAR(36) 컬럼에 문자열 그대로 저장하는 것입니다. 저장 공간이 정수 키보다 훨씬 커지고, 인덱스가 커질수록 조회 성능도 떨어집니다.
- MySQL에서는
BINARY(16)컬럼을 쓰면 36바이트가 16바이트로 줄어듭니다. - PostgreSQL은
uuid전용 타입이 있으므로 이를 사용하면 내부적으로 16바이트로 저장됩니다. - 조회 편의가 필요하면 문자열 변환을 뷰나 애플리케이션 계층에서 처리합니다.
또 하나 고려할 점은 삽입 성능입니다. v4는 값이 완전히 무작위라서 인덱스 트리 여기저기에 삽입되고, 그 과정에서 페이지 분할이 잦아집니다. 데이터가 수백만 건 이상 쌓이는 테이블이라면 시간순으로 증가하는 v7을 쓰는 것만으로 쓰기 성능이 눈에 띄게 개선됩니다.
UUID_TO_BIN(uuid_value, 1)의 두 번째 인자를 1로 주면 v1 UUID의 시간 필드를 앞으로 재배치해 순차성을 확보할 수 있습니다. 반대 변환은 BIN_TO_UUID(col, 1)입니다.5단계: 실무 적용 전 점검 목록
도입 직전에 아래 항목을 확인하면 대부분의 시행착오를 줄일 수 있습니다.
- URL이나 파일명에 노출되는 값이라면 v1은 피합니다. 생성 시각과 장비 정보가 값에 남습니다.
- 대소문자 처리 규칙을 한쪽으로 통일합니다. 보통 소문자 표기를 표준으로 삼습니다.
- 하이픈 유무를 API 명세에 명확히 적어 둡니다. 클라이언트마다 다르게 처리하면 비교 로직이 깨집니다.
- UUID는 고유성을 보장할 뿐 인증 수단이 아닙니다. 값을 아는 사람에게 접근을 허용하는 설계는 위험합니다.
- 내부 관리용 순번이 필요하다면 정수 키를 별도로 두고 UUID는 외부 노출용으로만 쓰는 이중 키 구조도 좋은 선택입니다.
정리하면 UUID 사용법의 핵심은 버전 선택과 저장 방식 두 가지에 있습니다. 용도에 맞는 버전을 고르고 이진 형태로 저장하는 습관만 들여도, 식별자 때문에 생기는 문제 대부분을 미리 막을 수 있습니다.