Spring Boot 3 / Hibernate 6 업그레이드 후 자정 무렵 배송 매니저 앱 로그인이 막힌 장애를, "저장은 되는데 조회 시 음수 나노초로 DateTimeException"이라는 현상부터 Hibernate의 LocalTime↔Time 변환 로직 변경까지 추적한 RCA다.
핵심 포인트- 에러는 DateTimeException: Invalid value for NanoOfSecond ... -843000000으로, DB TIME 컬럼을 LocalTime으로 변환하는 조회 과정에서 음수 나노초가 나와 발생했다.
- Hibernate 5.6→6.5 업그레이드로 LocalTime을 Time으로 변환할 때 이전엔 버리던 밀리초(나노초)를 반영하게 바뀌어, 배포 후 데이터에 나노초가 생겼다.
- KST(UTC+9) 타임존에서 0~8시 시각을 epoch(1970-01-01 UTC) 기준으로 계산하면 fastTime이 음수가 되고, ms를 1000으로 나눈 나머지가 음수가 돼 예외가 터진다.
- 버그 수정 버전이 아직 릴리스 전이라, LocalTime의 나노초를 truncatedTo로 제거하는 AttributeConverter를 문제 컬럼에 적용해 임시 조치했다.
상세 정리- 발단: AWS MSK 대응으로 Spring Boot를 3.x로 올렸고 QA·배포 후 정상 같았으나, 다음 날 자정 직전부터 로그인 불가 알림이 발생해 신속 롤백 후 원인 분석에 들어갔다.
- 데이터 관찰: DB엔 음수 나노초가 없고 모두 0/양수인데, 배포 전엔 나노초가 없다가 배포 후 데이터엔 나노초가 생긴 차이를 발견했다.
- 의심1(Java 11→17): LocalTime 로직 변경이 없었고 저장 시 나노초를 버리는 동작도 배포 전부터 동일해 제외했다.
- 의심2(Hibernate): LocalTimeJavaType.unwrap가 5.6.5에선 ms를 0으로 고정했으나 6.5.5에선 나노초에서 ms를 추출해 Time에 반영하도록 바뀐 것을 확인했다.
- 저장 경로: TimeJdbcType.doBind에서 unwrap을 거쳐 new Time(... + roundToPrecision(nano,3)/1000000)로 ms가 정상 양수로 저장된다.
- 조회 경로: doExtract에서 LocalTimeJavaType.wrap으로 Time을 LocalTime으로 되돌릴 때 ms 계산이 음수가 되는 문제가 있었다.
- 근본 원인: LocalTime엔 날짜가 없어 epoch를 임의 기준으로 쓰는데, KST는 UTC를 맞추려 9시간을 빼면서 0~8시 구간의 fastTime이 음수가 되고 그 나머지 연산이 음수 ms를 만든다.
- 재현 조건: KST(UTC+ 타임존) + 0~8시 + 나노초 존재(소수점 3자리)일 때 발생하고, UTC나 9시 이후·나노초 없음이면 발생하지 않았다.
- 조치: 릴리스된 수정본이 없어 나노초 제거 Converter를 적용해 재발을 차단하고, 추후 수정 버전에서 업그레이드할 예정이다.
- 회고: 인수·통합 테스트가 있었다면 큰 버전업에서 조기 발견했을 것이고, 가설-검증식 디버깅이 원인 규명에 도움이 됐다는 교훈을 남겼다.
왜 읽나Spring Boot 3 / Hibernate 6 업그레이드 후 시간·타임존 관련 장애를 겪는 백엔드 개발자에게 LocalTime 변환 내부 동작과 임시 우회를 알려주는 RCA.