본문 바로가기
Bigdata

데이터베이스에서 UUID 사용의 주요 문제점

by 올엠 2025. 7. 10.
반응형

UUID는 분산 시스템이나 외부 노출 식별자 등 특정 상황에서 유용하지만, 데이터베이스의 기본 키(primary key)로 무분별하게 사용하는 것은 권장되지 않습니다. 성능, 저장 공간, 관리 효율성 측면에서 충분히 고려한 후에 사용해야 하며, 대안으로는 순차적인 정수형 PK 또는 정렬 가능한 UUID를 사용하는 것이 좋습니다.
이유는 다음과 같습니다.
UUID 사용의 주요 문제점

성능 저하

UUID는 일반적으로 16바이트(128비트)로, 전통적인 정수형(4~8바이트)보다 크기가 큽니다. 이로 인해 인덱스 크기가 커지고, 디스크 I/O와 메모리 사용량이 증가해 쿼리 성능이 저하될 수 있습니다.
특히 클러스터형 인덱스(primary key index)로 UUID를 사용할 경우, 값이 무작위로 생성되어 데이터가 테이블에 비순차적으로 삽입됩니다. 이로 인해 인덱스 단편화가 심해지고, 데이터베이스의 성능이 떨어질 수 있습니다.

가독성과 관리성 저하

UUID는 사람이 읽고 기억하기 어렵습니다. 예를 들어, b3c5e7e2-1d3a-4b9a-9c2d-2d1e4b9a9e4f와 같은 값은 숫자 ID에 비해 관리와 추적이 어렵습니다.

스토리지 낭비

UUID는 정수형보다 훨씬 많은 공간을 차지합니다. 대규모 테이블에서는 이로 인한 저장 공간 낭비가 커질 수 있습니다.

샤딩 및 파티셔닝 비효율

UUID의 무작위성 때문에, 데이터베이스 샤딩이나 파티셔닝 전략을 적용할 때 데이터가 고르게 분산되지 않고, 특정 노드에 부하가 집중될 수 있습니다.

권장 사항은 아래와 같습니다.

Auto Increment 정수형 PK 사용

대부분의 경우, 순차적인 정수형(primary key, auto increment)을 사용하는 것이 성능과 관리 측면에서 유리합니다.

정렬 가능한 UUID(Ordered UUID)

부득이하게 UUID를 써야 한다면, Laravel의 Str::orderedUuid처럼 정렬이 가능한 UUID를 활용해 인덱스 단편화를 줄일 수 있습니다.

반응형