JPA UUID 조회 실패 원인 분석: MySQL BINARY 패딩 문제와 해결책

JPA 엔티티의 Id 컬럼 타입을 UUID로 지정했을 때, 개발 환경의 MySQL 데이터베이스에서 조회가 실패하는 이슈가 발생했다. 테스트 환경의 H2 인메모리 DB에서는 정상 동작했으나, 실제 DB에서는 repo.findById() 호출 시 null을 반환하며 예외가 발생했다.

원인은 Hibernate가 UUID를 binary로 저장하는 기본 동작과 MySQL의 BINARY 타입 처리 방식의 차이였다. 엔티티 스키마가 BINARY(255)로 설정되어 있었으며, MySQL은 BINARY 값 저장 시 지정된 길이까지 오른쪽으로 패딩(right-padded) 처리한다. UUID는 RFC 4122 기준 16바이트이므로, 저장된 데이터는 16바이트 데이터와 239바이트의 패딩으로 구성된다.

조회 실패의 핵심은 쿼리 조건에 패딩이 포함되지 않았기 때문이다. WHERE id = unhex(replace(...)) 조건으로 조회하면 16바이트 값과 255바이트 패딩 값이 불일치하여 결과가 나오지 않는다. 이를 해결하기 위해 조회 조건에 rpad(unhex(replace(...)), 255, '\0')를 적용하여 패딩을 명시적으로 포함시키면 데이터를 정상적으로 조회할 수 있다.

근본적인 해결책으로는 @Column(columnDefinition = "BINARY(16)") 어노테이션을 추가하여 컬럼 길이를 UUID의 실제 크기인 16바이트로 변경하는 방법이 제시되었다. 이를 통해 불필요한 패딩 문제를 제거하고 테스트 및 실제 환경 모두에서 정상 동작을 확인할 수 있었다.