데이터베이스 기본키로 UUID를 쓰면 좋은 점과 나쁜 점

데이터베이스 테이블을 설계할 때 기본키(PK)를 AUTO_INCREMENT로 할지 UUID로 할지 고민됩니다. UUID의 장단점을 비교해보겠습니다.

Auto Increment의 한계

숫자 ID(1, 2, 3...)는 단순하고 빠릅니다. 하지만 분산 시스템에서는 문제가 생깁니다. 서버 A에서 ID 1을 만들고, 서버 B에서도 ID 1을 만들면 충돌합니다.

UUID의 장점

• 전역 유일성: 어디서 생성해도 겹칠 확률 거의 0
• 분산 시스템: 중앙 서버 없이 ID 생성 가능
• 예측 불가: 다음 ID를 추측할 수 없어 보안에 유리
• 사전 생성: DB 삽입 전에 ID를 미리 알 수 있음

UUID의 단점

• 저장 공간: 36자 vs 숫자 (4~8바이트)
• 인덱스 성능: 랜덤이라 B-tree 삽입 성능 저하
• 가독성: 550e8400-e29b-41d4-a716... 외우기 어려움
• URL 길이: /user/123 vs /user/550e8400-e29b-...

UUID 버전 선택

테스트용 UUID 생성

개발 중 테스트 데이터에 UUID가 필요하면 UUID 생성기에서 바로 만들 수 있습니다. 여러 개를 한 번에 생성하는 것도 가능합니다.

ULID - 대안

UUID v4의 정렬 문제를 해결한 ULID도 있습니다. 시간순 정렬이 가능하면서도 고유합니다. 최근 많은 프로젝트에서 채택하고 있습니다.

언제 UUID를 써야 할까?

MSA(마이크로서비스), 분산 데이터베이스, 오프라인 클라이언트 동기화 등에서는 UUID가 필수입니다. 단일 서버 단순 CRUD라면 Auto Increment도 충분합니다.

하이브리드 접근

내부 ID는 Auto Increment, 외부 노출 ID는 UUID를 쓰는 방식도 있습니다. 고유 식별자 생성 도구로 외부용 ID를 만들어 별도 컬럼에 저장하면 됩니다.