1. 문제확인
펀딩 생성 성공시 크롬의 개발자도구 콘솔에서 표기되는 createdAt과 DB(RDS mysql)상에서 찍히는 createdAt이 모두 현재시간과 다르게 표기되는 문제를 발견하였다.
위의 사진과 같이 크롬의 개발자도구 콘솔에는 createdAt이 현재시간과 다르게 표기되고있다.
이때, DB에서도 콘솔에 찍힌 createdAt과 같은 값이 찍힌것을 확인하였다.
콘솔에도, DB에도 한국시간(KST)로 제대로 찍혔어야했는데 다른 시간대로 오기입된것이다.
2. 원인추론 :
createdAt은 JPA의 Audit 기능을 사용하여 DB에 값이 저장됐을 때 자동으로 생성된 값이다.
따라서, RDS mysql 을 사용중이었기때문에 RDS의 time zone 설정에 문제가 있는지부터 확인하였다.
해결시도 1 : AWS RDS 파라미터 그룹 설정 확인
SHOW VARIABLES LIKE '%time_zone%';select @@global.time_zone, @@session.time_zone, @@system_time_zone ;
혹시 system_time_zone이 UTC로 나오는데 이것때문에 발생한 문제인지 찾아보니
system_time_zone은 default 값과 같은 것이고 별도의 time_zone 값이 세팅되어있다면
세팅된 값으로 정상적으로 시간대가 표기되어야해 문제의 원인이 아니었다.
SQL 쿼리를 실행하여 현재 시간대 설정을 확인해보니 정상적으로 적용되어있었다.
사용중인 RDS에 할당해둔 파라미터 그룹의 time_zone 설정. 올바르게 Asia/Seoul로 설정되어있다.
하지만 설정 후 RDS 재부팅까지 마치고 재배포까지 해본 후 배포된 도메인에서 다시 테스트를 해봐도 동일한 문제가 똑같이 생겼다.
RDS 설정에는 문제가 없는 것 같아서… 다른 부분에서 놓친 부분이 있나 하고 확인해보았다.
해결시도 2 : FE 쪽의 Vercel 배포 세팅에서의 Region 설정
Vercel로 배포할때 Function Region 설정이 있었다. Vercel의 Serverless Function Region의 디폴트가 캘리포니아로 되어있어 Seoul로 바꾸면 배포 속도가 올라간다는 정보를 알게되어, 혹시 시간대와도 관련이 있는지 Seoul로 변경을 부탁드렸다.
하지만 역시 시간대관련 효과는 없었고 FE쪽의 배포속도가 1~2초 정도 빨라졌을 뿐이었다.
해결시도 3 :
spring.jpa.properties.hibernate.jdbc.time_zone=Asia/Seoul
application.yml 설정에서 JPA 및 Hibernate 설정하는 방법이 있으나 local의 mysql일때 적용되는 부분이지 이미 RDS상태에서 Asia/Seoul로 적용되어있어 상관이없었다.
해결시도 4 :
4-1. @DateTimeFormat 어노테이션이나 JPA 컨버터를 사용하여 애플리케이션 내에서 날짜와 시간을 처리할 때 명시적으로 시간대를 설정
@DateTimeFormat 어노테이션은 주로 스프링 MVC에서 컨트롤러를 통해 날짜 및 시간 데이터를 바인딩할 때 사용되는 반면, JPA의 Audit 기능을 사용하여 자동으로 시간대를 적용하고 있었으므로 올바른 해결방법이 되지못했다.
4-2. Spring 애플리케이션을 실행하는 JVM 시간대를 명시적으로 Asia/Seoul로 설정
TimeZone.setDefault(TimeZone.getTimeZone("Asia/Seoul"));java -Duser.timezone=Asia/Seoul -jar yourapp.jar와 같이 실행
이 방법 또한 Audit 기능을 사용하는 시점에서 해결방법이 되진 못하였다.
해결방법 :
의외로 너무 간단한부분에서 놓치고 있었다.
application.yml에 세팅해놓은 RDS mysql의 url부분에 끝에 serverTimezone=Asia/Seoul을 명시해주지 않아서 생긴 문제였다.
웹에서 파라미터 설정으로 Asia/Seoul로 시간대 설정을 해놓아도 애플리케이션 세팅 단계에서 명시되어있지 않아 올바르게 db에 KST 시간대로 찍히지 않았던 것.
올바르게 createAt이 DB에 들어왔다.
DB에는 올바르게 createAt이 들어오는 것을 확인하였다. 하지만 아직 크롬 개발자도구 콘솔상에서는 전과 같이 다른 시간대로 표기되고있었다.
왜 그런걸까?
실제로 데이터베이스에 저장된 시간이 특정 시간대(Asia/Seoul)를 반영하여 기록되더라도, 서버에서 클라이언트로 데이터를 전송할 때 사용되는 시간 포맷 처리 방식은 별개의 문제였다.
서버에서 클라이언트로 데이터를 전송할때는 일반적으로 사용되는 방식은 다음과 같다.
- UTC 기준의 ISO 8601 포맷 사용 :
많은 웹 애플리케이션과 API는 시간 정보를 표준화된 포맷(ISO 8601)로 전송하며, 이는 시간대 변환을 단순화하고 국제화를 용이하게 하고있다. - 클라이언트 사이드 시간대 변환 :
서버에서 사용된 UTC 시간 정보는 클라이언트 사이드(브라우저 등) 에서 사용자의 로컬 시간대로 변환하여 표시될 수 있었다. 이 변환은 브라우저의 JavaScript 등을 통해 사용자에게 로컬 시간대에 맞춘 시간 정보를 제공할 수 있다.
따라서 크롬 개발자도구 크롬 상에는 다르게 표시되고, DB에 제대로 찍힌다는 것은 서버에서 클라이언트로 데이터를 전송할 때 UTC 기준의 시간 정보로 변환하여 전송하고 있기 때문에 발생한 일반적인 상황이었다. 이는 클라이언트와 서버간의 시간대 독립성을 유지하고, 다양한 시간대(한국이 아닌 다른 나라에서 사용을 고려)에서 사용자가 있는 글로벌 애플리케이션의 필요성을 충족시키기 위함이었다.
이 글은 Obsidian으로 작성되었습니다. -
