[hot deal] UUID의 사용 범위에 대한 고민

서비스를 개발할 때 UUID를 Primary Key로 사용하는 방법이 있습니다.

 

하지만 저는 Member 클래스에만 UUID를 필드로 추가하였고, 그 이유를 정리해 보았습니다.

 

---

1. 왜 UUID 사용하지 않아야 할까?

UUID는 전역적으로 고유한 식별자를 생성할 수 있어 데이터베이스의 ID로 자주 사용됩니다.

하지만 프로젝트를 진행하면서 저장 공간 효율성과 검색 성능을 고려해 UUID를 ID로 사용하지 않기로 결정 했습니다.

 

1.1. 저장 공간 효율성

UUID는 128비트로 길이가 길어, 숫자형 ID보다 더 많은 저장 공간을 차지합니다.

 

1.2. 검색 성능

UUID는 랜덤하게 생성되기 때문에 데이터베이스에서 인덱스를 생성할 때 정렬되지 않은 상태로 저장됩니다.

이로 인해 데이터베이스 검색 시 성능이 떨어질 수 있습니다.

 

프로젝트에서 사용하는 Member 클래스의 경우, UUID를 필드로서 추가는 해주었지만, Primary Key로 만들어 주지는 않았습니다.

검색 속도가 중요하다고 판단하여 ID로 사용하기에 적합하지 않다고 생각했기 때문입니다.

 

2. UUID 사용의 보안적 고려 사항

로그를 통해 전체 사용자 수가 추정될 수 있는 상황을 피하고자 UUID를 직접적인 ID로 사용하는 대신 별도 필드로 두어 내부 로깅 용도로만 사용하게 설정했습니다.

 

순차적인 ID의 경우 로그에 해당 값이 남게 되면 해당 서비스에 얼마나 많은 Member가 존재하는지 노출될 수 있는 위험이 있습니다.

 

제일 중요한 데이터라고 판단된 Member 클래스에는 이런 보안적인 우려를 고려하여 UUID를 별도의 필드로 추가하기로 했습니다.

 

결과적으로 설계된 Member 클래스는 다음과 같습니다.

public class Member extends BaseTimeEntity {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private UUID uuid;

    @Column(nullable = false)
    private String name;

    @Column(nullable = false, unique = true)
    private String email;

    @Column(name = "password_hash", nullable = false)
    private String passwordHash;
}