데이터베이스 테이블에 레코드를 추가할 때 ID를 1, 2, 3으로 순서대로 매기면 간단하다. 그런데 서버가 여러 대이거나, 외부 시스템과 데이터를 주고받아야 하면 ID가 충돌할 수 있다. UUID는 전 세계 어디서 생성해도 겹치지 않는 고유 식별자다.
UUID의 구조
UUID는 128비트 숫자를 16진수 32자리로 표현한 것이다. 하이픈으로 5개 블록으로 나뉜다.
550e8400-e29b-41d4-a716-446655440000이 중 가장 많이 쓰이는 v4는 무작위 난수로 생성된다. 이론적으로 충돌 확률은 10억 개를 만들어도 사실상 0에 가깝다.
auto increment와 뭐가 다른가
| 항목 | auto increment | UUID |
|---|---|---|
| 고유성 범위 | 단일 테이블 내 | 전 세계적으로 고유 |
| 예측 가능성 | 다음 ID 추측 가능 | 추측 불가 |
| 분산 시스템 | 충돌 위험 | 충돌 없음 |
| 크기 | 4~8바이트 | 16바이트 |
| 인덱스 성능 | 빠름(순차) | 상대적으로 느림(랜덤) |
참고 UUID가 만능은 아니다. 순차적이지 않아서 B-Tree 인덱스 성능이 떨어질 수 있고, 문자열로 저장하면 용량도 커진다. 소규모 단일 서버 프로젝트에서는 auto increment가 더 효율적이다.
UUID를 쓰는 실무 사례
- 마이크로서비스: 서비스 간 데이터 동기화 시 ID 충돌 방지
- API 리소스 식별: URL에 노출되는 ID를 추측 불가능하게 처리
- 세션/토큰: 로그인 세션 ID, 비밀번호 재설정 토큰
- 파일명: 업로드 파일의 고유 이름 생성
- 이벤트 로깅: 분산 시스템 로그의 추적 ID
UUID 생성 방법
코드에서 직접 생성할 수도 있지만, 테스트 데이터를 만들거나 빠르게 하나 뽑아야 할 때는 UUID 생성기가 편하다. 한 번에 최대 1,000개까지 대량 생성이 되고, 하이픈 제거·중괄호·URN 등 형식도 선택할 수 있다. 결과를 텍스트 파일로 다운로드하는 기능도 있어서 테스트 데이터셋을 만들 때 유용하다.
ID 체계를 뭘로 가져갈지는 프로젝트 규모와 구조에 따라 달라진다. 다만 한 번 정하면 나중에 바꾸기 어려우니, 초기 설계 단계에서 결정하는 게 좋다.