728x90
반응형
1. 실무에서 UUID를 쓰는 "진짜" 이유
예전에는 Long 타입의 AUTO_INCREMENT를 많이 썼지만, 요즘 실무(특히 규모가 큰 서비스)에서 UUID를 고집하는 이유는 크게 3가지입니다.
- ID 예측 불가능 (보안): example.com/user/101이라고 하면 다음 유저가 102인 걸 누구나 압니다. 하지만 UUID를 쓰면 URL만 보고 데이터를 추측하거나 크롤링하기가 매우 힘들어집니다.
- 분산 환경에서의 유일성: 여러 개의 DB 서버나 서버 인스턴스가 있을 때, DB에 물어보지 않고도 애플리케이션 레벨에서 절대 겹치지 않는 ID를 즉시 생성할 수 있습니다.
- DB 마이그레이션 용이성: 여러 DB의 데이터를 하나로 합칠 때, Long 타입은 ID가 겹쳐서 난리가 나지만 UUID는 그냥 합쳐도 충돌이 없습니다.
2. MariaDB와 JPA의 UUID 궁합
MariaDB 10.7 버전부터 Native UUID 타입이 나오면서 그동안의 단점(성능, 가독성)이 대부분 해결되었습니다.
MariaDB 관점
- MySQL보다 편리함: MySQL은 BINARY(16)에 넣고 조회할 때 귀찮은 변환을 해야 하지만, MariaDB는 SELECT 하면 하이픈 붙은 문자열로 바로 보여줍니다.
- 성능 최적화: 내부적으로는 16바이트 이진 데이터로 관리하므로 CHAR(36)보다 인덱스 속도가 훨씬 빠르고 용량도 적게 차지합니다.
JPA(Hibernate) 관점
- 매핑의 편리함: Hibernate 6 버전부터 MariaDB UUID 타입을 아주 잘 지원합니다. @JdbcTypeCode(SqlTypes.UUID) 한 줄이면 복잡한 변환 로직(AttributeConverter 등) 없이도 자바의 java.util.UUID와 DB 타입을 깔끔하게 연결해 줍니다.
3. 실무에서의 트레이드오프 (장단점)
실무자들이 UUID 도입을 망설이는 유일한 이유는 "성능" 때문이었습니다.
구분 AUTO_INCREMENT (Long) UUID (v4) UUID (v7 - 최근 실무 트렌드)
| 가독성 | 매우 좋음 (1, 2, 3...) | 나쁨 (복잡한 문자열) | 나쁨 (복잡한 문자열) |
| 인덱스 성능 | 최상 (순차적) | 최악 (무작위라 파편화 발생) | 좋음 (시간 순 정렬 가능) |
| 보안성 | 취약함 | 매우 우수 | 매우 우수 |
| 분산 환경 | 부적합 (DB 의존) | 매우 적합 | 매우 적합 |
💡 핵심 팁: 예전에는 UUID v4의 무작위성 때문에 DB 성능이 떨어지는 문제가 있었지만, 요즘 실무에서는 **시간 순서로 생성되는 "UUID v7"**을 사용해 성능과 유일성을 모두 잡는 것이 대세입니다.
4. 실무 코드 적용 예시 (Spring Boot 3 + MariaDB 10.11)
실무에서는 보통 이렇게 엔티티를 구성합니다.
@Entity
@Table(name = "users")
public class User {
@Id
@JdbcTypeCode(SqlTypes.UUID) // MariaDB native UUID와 매핑
@Column(columnDefinition = "UUID")
private UUID id;
// UUIDv7 생성 로직을 넣거나, 라이브러리를 사용합니다.
@PrePersist
public void createId() {
if (this.id == null) {
this.id = UUIDV7 Generator..; // 애플리케이션에서 직접 생성
}
}
}
728x90
반응형