LocalDatetime To Instant
#️⃣ 연관 이슈 #115
현재 프로젝트는 ISO8601 표준 UTC 시간 표기 방식 ( YYYY-MM-DDThh:mm:ssZ 형식 ) 을 기준으로 날짜 정보를 프론트엔드 - 백엔드 간 통신하고 있습니다. 이때, 백엔드 내부적으로 이용하고 있는 시간 표현은 LocalDateTime으로, 타임존 정보가 존재하지 않는다는 특징이 있습니다.
문제는 서버측에서 다루는 시간에 타임존이 없어 DB에서 가져온 UTC 시간을 왜곡하는 부분에서 발생했습니다. 프론트엔드 측은 UTC 타임존 정보를 포함하여 데이터를 전달하지만, 해당 값을 LocalDatetime으로 변환하는 과정에서 UTC가 아닌 KST(한국 시간 = UTC+9)로 인식되고 있었습니다. 마찬가지로 DB에는 UTC 시간을 기준으로 datetime(6) 데이터를 저장하지만, 이를 Spring으로 가져와 다룰 때는 KST로 인식되어 의도와는 달리 9시간의 시간 오차가 지속적으로 발생하고 있었습니다.
정보를 조사한 결과, Spring 어플리케이션의 타임존 설정, 시간 변환 converter 구현 등의 방식으로 스프링 수준에서 한국 시간으로 식별할 수 있다는 것을 알게 되었지만 본질적으로 서버에서 시간을 다루는데 LocalDatetime이 적합한가에 대한 고민이 생겼습니다.
현재 "서버의 현지 시간"이 중요한 상황은 거의 존재하지 않습니다. 대부분의 경우 DB에 저장된 UTC 시간을 기준으로 값을 비교하더라도 문제가 없으며, 일부 당일 액션 체크가 필요한 경우에는 LocalDateTime을 UTC 시간 기준으로 변경해서 처리할 수 있습니다.
확장성 측면에서도 DB에 한국의 로컬 시간 대신 UTC 시간을 저장하는 경우, 다른 서비스에서 DB를 접근할 때 타임존을 신경쓰지 않고 통일된 시간대로 문제를 처리할 수 있다는 점이 장점이라고 생각했습니다. 장기적으로 볼 때 현재 어드민 시스템은 국내 뿐만 아니라 다양한 국외 환경에 대응해야 할지 모릅니다. 이 상황을 가정하면 DB와 어플리케이션 양 측면에서 UTC라는 동일한 표준 시간대를 이용하는 것이 오해의 소지가 없을 것이라고 판단했습니다. 서버에서 UTC 시간을 사용한다면 LocalDatetime보다는 Instant를 이용하여 명확하게 UTC 시간을 따르고 있다고 명시하는 편이 오해를 줄일 수 있습니다. 또한, 하나의 서버에서 해당 국가의 이벤트만 처리하는 것이 아니라, 다양한 국가의 현지 시간을 기준으로 이벤트를 다뤄야 하는 등의 상황이 발생하면 LocalDatetime 현지 시간에서 오프셋 차이를 구하는 것 보다는 UTC 기준으로 오프셋을 더해 처리하는 것이 훨씬 효율적입니다.
위와 같은 이유로 LocalDateTime을 걷어내고 UTC 기준으로 동작하는 시간 API인 Instant로 전환했습니다. 장기적으로 현재 시스템을 확장해나갈 예정이라면 이벤트에 타임존 필드를 추가, 해당 타임존을 기반으로 하루를 계산할 수 있도록 구성하면 더 확장적인 서비스가 될 수 있을 것이라 생각합니다.
- LocalDatetime 대신 Instant를 사용하도록 변경: 동일 서버를 어떤 국가에 배포하더라도 DB 상의 데이터를 동일한 UTC 시간으로 인식하고 처리할 수 있도록 구성.
- 이벤트 키 수명 48시간으로 지정: 현재 가장 시간이 빠른 나라와 가장 느린 나라는 UTC-12, UTC+12의 시간대를 가질 수 있으며, 시차는 24시간에 해당한다. 하루에 해당하는 24시간 + 시차 24시간을 더해 키 수명을 48시간으로 지정하여 어떤 나라에서도 이벤트 키를 충돌 없이 생성할 수 있도록 구성 ( 각 지역이 동일한 db를 사용할 수 있다고 가정 )
- 서머 타임에 의한 시간 변동을 반영하는 ZoneId 대신 엄밀한 시간 차이를 반영하는 ZoneOffset을 이용: 서버 측에서는 혼란을 줄 수 있는 서머 타임을 반영하는 대신 UTC 기준으로 고정된 시간 편차를 보여주는 것이 더 적합하다고 생각했습니다.