회원 테이블에 기본키를 뭘로 잡을지 고민하다가, 선배 개발자가 "UUID 쓰면 돼"라고 했다. 자동 증가 정수(AUTO_INCREMENT)를 쓰면 안 되나 싶었는데, 분산 환경에서는 사정이 다르다.
UUID가 뭔가
UUID(Universally Unique Identifier)는 128비트 길이의 고유 식별자다. 형태는 이렇게 생겼다.
550e8400-e29b-41d4-a716-44665544000016진수 32자를 하이픈으로 구분한 구조다. 전 세계 어디서 생성하든 겹칠 확률이 사실상 0에 가깝다. 조합 가능한 수가 약 3.4 × 10³⁸개이기 때문이다.
자동 증가 정수 대신 UUID를 쓰는 이유
| 비교 항목 | AUTO_INCREMENT | UUID |
|---|---|---|
| 고유성 범위 | 단일 DB 내에서만 | 전 세계적으로 고유 |
| 예측 가능성 | 순차적 (다음 ID 추측 가능) | 랜덤 (추측 불가) |
| 분산 환경 | 서버 간 충돌 위험 | 충돌 없음 |
| 크기 | 4~8바이트 | 16바이트 |
| 가독성 | 짧고 간결 | 길고 복잡 |
마이크로서비스 아키텍처에서 여러 서버가 동시에 데이터를 생성하면 AUTO_INCREMENT로는 충돌이 생긴다. UUID는 중앙 서버 없이도 각 서버에서 독립적으로 생성해도 겹치지 않는다.
UUID 버전별 차이
- v1 (시간 기반)
- 현재 시각과 MAC 주소를 조합한다. 생성 시각을 역추적할 수 있어 프라이버시 문제가 있다.
- v4 (랜덤)
- 122비트를 순수 난수로 채운다. 가장 널리 쓰이는 버전이다. 시간이나 기기 정보가 포함되지 않는다.
- v5 (이름 기반)
- 네임스페이스와 이름을 SHA-1 해시해서 만든다. 같은 입력이면 항상 같은 UUID가 나온다.
- v7 (시간 정렬형)
- 2024년 표준화된 최신 버전. 시간 정보를 포함하면서 정렬도 가능하다. 데이터베이스 인덱스 효율이 v4보다 좋다.
바로 생성하기
UUID 생성기에서 버튼 하나로 v4 UUID를 뽑을 수 있다. 최대 1,000개까지 한번에 대량 생성도 가능하고, 하이픈 제거, 대문자 변환, 중괄호 감싸기 같은 포맷 옵션도 지원한다. 테스트 데이터를 만들 때 한꺼번에 뽑아서 텍스트 파일로 다운로드하면 편하다.
실무에서 주의할 점
- 인덱스 성능 — UUID v4는 완전 랜덤이라 B-tree 인덱스에서 비효율적이다. 대용량 DB에서는 v7이나 ULID를 고려할 것.
- URL에 노출 —
/users/550e8400-e29b-41d4...형태의 URL은 길지만, 순차 정수보다 보안 면에서 유리하다. 다음 사용자 ID를 추측해서 접근하는 공격을 막을 수 있다. - 저장 공간 — UUID는 16바이트다. 정수(4바이트)보다 크지만, 현대 시스템에서 이 차이가 문제가 되는 경우는 드물다.
고유 ID는 시스템의 기본 중 기본이다. 규모가 작은 프로젝트에서는 정수로 충분하지만, 확장 가능성을 열어두고 싶다면 처음부터 UUID를 쓰는 게 나중에 덜 고생한다.