마이크로서비스 아키텍처에서 각 서비스가 독립적으로 데이터를 생성한다. 이때 1, 2, 3... 같은 순차 ID를 쓰면 서비스 간에 같은 번호가 겹칠 수 있다. UUID는 이 문제를 해결하기 위해 만들어진 전 세계적으로 고유한 식별자다.
UUID 구조
UUID는 128비트(16바이트) 크기의 식별자로, 보통 하이픈으로 구분된 32자리 16진수로 표기한다.
550e8400-e29b-41d4-a716-4466554400008자리-4자리-4자리-4자리-12자리 형태이고, 약 3.4 x 1038가지 조합이 가능하다. 매초 10억 개씩 생성해도 충돌까지 수백 년이 걸리는 수준이다.
버전별 차이
| 버전 | 생성 방식 | 특징 |
|---|---|---|
| v1 | 타임스탬프 + MAC 주소 | 생성 시간 추적 가능, 장비 정보 노출 위험 |
| v3 | MD5 해시 (네임스페이스 기반) | 같은 입력이면 같은 UUID 생성 |
| v4 | 완전 랜덤 | 가장 널리 사용, 추적 불가 |
| v5 | SHA-1 해시 (네임스페이스 기반) | v3의 SHA-1 버전 |
실무에서 가장 많이 쓰이는 건 v4다. 난수 기반이라 생성 환경에 의존하지 않고, 개인정보(MAC 주소 등)가 포함되지 않아 보안 면에서도 안전하다.
어디에 쓰이나
- DB 기본키 — 분산 시스템에서 ID 충돌 없이 레코드를 생성할 수 있다
- 파일명 — 업로드 파일명 중복 방지 (예: 프로필 이미지 저장)
- 세션/토큰 — 예측 불가능한 세션 ID 생성
- API 요청 추적 — 각 요청에 고유 ID를 붙여 로그에서 추적
빠르게 생성하려면
코드에서 라이브러리로 생성할 수도 있지만, 테스트 데이터를 준비하거나 설정 파일에 고유 키를 넣어야 할 때는 웹에서 바로 뽑는 게 빠르다. UUID 생성기에서 버튼 한 번으로 v4 UUID가 만들어지고, 하이픈 제거, 대문자, 중괄호, URN 등 형식도 선택할 수 있다. 테스트용으로 여러 개가 필요하면 최대 1,000개까지 일괄 생성해서 텍스트 파일로 다운로드할 수 있다.
TIP UUID를 DB 기본키로 쓸 때는 인덱스 성능을 고려해야 한다. 랜덤 UUID는 삽입 시 B-Tree 인덱스가 분산되어 쓰기 성능이 떨어질 수 있다. 이 문제가 신경 쓰인다면 시간순 정렬이 가능한 UUIDv7이나 ULID를 검토해볼 만하다.
고유 ID 하나가 시스템 전체의 데이터 정합성을 좌우한다. 순차 ID의 한계가 보이기 시작했다면 UUID 도입을 진지하게 고려할 시점이다.