JPA 덕분에 DB에서 삽질한 이야기

UUID를 저장한 뒤 조회하면 결과가 나오지 않는 문제를 겪어, 테스트 케이스를 비교하며 H2 인메모리 DB와 개발용 MySQL의 차이를 확인했다. 엔티티의 UUID 컬럼이 BINARY(255)로 생성된 것이 원인이었고, UUID가 16바이트라는 점에 맞춰 컬럼을 BINARY(16)으로 지정하자 조회가 정상 동작했다. MySQL은 BINARY 값이 지정 길이보다 짧으면 오른쪽을 패딩하므로, 16바이트 UUID와 패딩된 컬럼 값이 일치하지 않아 조회가 실패할 수 있음을 SQL로 재현했다. 테스트 환경을 실제 DBMS와 맞추고, 컬럼 정의와 저장된 바이트를 확인하는 것이 문제를 정확히 진단하는 데 중요하다는 교훈을 얻었다.

• UUID는 16바이트이므로 MySQL의 BINARY 컬럼도 BINARY(16)으로 정의해야 합니다.
• MySQL은 BINARY 컬럼의 남는 공간을 오른쪽 패딩으로 채우므로, 컬럼 길이가 UUID보다 크면 저장한 값과 조회 조건의 바이트가 달라질 수 있습니다.
• H2와 개발용 MySQL처럼 테스트 환경이 다르면 같은 코드도 다르게 동작할 수 있으니, 실제 DBMS와 일치하는 환경에서 검증하세요.
• 문제가 재현되면 테스트 케이스의 목적과 컨텍스트를 점검하고, 스키마와 저장된 바이트를 직접 확인해 원인을 좁혀가세요.