데이터베이스에 새 레코드를 추가하는데 ID를 뭘로 할지 고민이다. 1, 2, 3 순번으로 매기면 서버가 여러 대일 때 충돌이 생긴다. 이런 상황에서 UUID를 쓰면 전 세계 어디서 동시에 생성해도 겹치지 않는 고유 ID를 만들 수 있다.
UUID가 뭔가
UUID(Universally Unique Identifier)는 128비트 길이의 식별자다. 보통 이런 형태로 표시된다:
550e8400-e29b-41d4-a716-4466554400008-4-4-4-12 자리로 하이픈을 넣어 총 36자(하이픈 포함)다. 가능한 조합의 수가 약 3.4 × 10³⁸개라서 우연히 같은 값이 나올 확률은 사실상 0이다. GUID(Globally Unique Identifier)는 마이크로소프트에서 쓰는 용어인데, UUID와 같은 것이다.
왜 순번(1, 2, 3) 대신 UUID를 쓸까
| 비교 항목 | 순차 ID (Auto Increment) | UUID |
|---|---|---|
| 중복 가능성 | 단일 DB에서는 없음 | 사실상 없음 |
| 분산 환경 | 서버 간 충돌 위험 | 각자 생성해도 안전 |
| 보안 | 다음 ID 예측 가능 (user/5 → user/6) | 예측 불가 |
| 크기 | 4~8바이트 | 16바이트 |
| 가독성 | 짧고 읽기 쉬움 | 길고 읽기 어려움 |
마이크로서비스처럼 여러 서비스가 독립적으로 데이터를 생성하는 구조에서는 UUID가 거의 필수다. 중앙 서버에 "다음 번호 달라"고 물어볼 필요 없이 각자 ID를 만들면 되니까.
UUID 버전별 차이
- v1 (타임스탬프 기반)
- 생성 시각과 MAC 주소를 조합한다. 시간 순서 정렬이 가능하지만 MAC 주소가 노출돼서 프라이버시 문제가 있다.
- v4 (랜덤)
- 가장 많이 쓰인다. 완전한 난수로 생성되어 예측이 불가능하다. 대부분의 프레임워크가 기본으로 v4를 지원한다.
- v7 (타임스탬프 + 랜덤, 최신)
- 2024년에 표준화된 새 버전이다. 시간 순서 정렬이 가능하면서도 v1의 프라이버시 문제를 해결했다. DB 인덱스 성능도 v4보다 낫다.
포맷 종류
- 기본(하이픈):
550e8400-e29b-41d4-a716-446655440000 - 하이픈 제거:
550e8400e29b41d4a716446655440000(32자) - 중괄호:
{550e8400-e29b-41d4-a716-446655440000}(Windows 레지스트리 스타일) - URN:
urn:uuid:550e8400-e29b-41d4-a716-446655440000
테스트나 개발 중에 UUID가 필요하면 UUID 생성기에서 바로 뽑을 수 있다. 1개부터 1,000개까지 대량 생성이 되고, 포맷과 대소문자도 선택 가능하다. 생성된 목록은 텍스트 파일로 다운로드할 수 있어서 테스트 데이터 준비에 쓸 만하다.
참고 RFC 4122 표준에 따르면 UUID는 소문자로 표기하는 것이 권장이다. 하지만 대소문자를 구분하지 않으므로A716이든a716이든 같은 UUID다.
ID 설계는 프로젝트 초기에 결정하면 나중에 바꾸기 어렵다. 분산 환경이 예상되거나 URL에 ID가 노출되는 구조라면 처음부터 UUID를 고려하는 게 맞다.