# timezone 로컬-서버 시간대 차이 문제 해결하기
서버에서 개발된 코드를 원격 깃에 올리고, 다시 로컬로 받아서 수정하고 서버에 올리고.. 를 반복하다 보면 env 나 명시된 일경로 등의 누락이나 차이로 인해 신경써줘야 하는 상황들이 생긴다.
이번에 예측 test-bed 리펙토링 과정에서 그동안 본적 없었던, 시간 설정으로 인한 문제를 해결했다.
# 원래 의도한 흐름
데이터분석(예측) 아웃풋을 간편히 확인할 수 있는 데모사이트인데, API 호출을 통해 결과물을 만들어낸다. 이때 유저 입력값을 적절히 가공하여 납득 가능한 그래프 파형을 그려줘야 하는데, API 서버는 request json의 'request time'과 'record time'의 날짜 가 동일한지 검증하는 과정을 거친다. 그날의 액티비티를 기준으로 예측을 제공하기 때문
1. 사용자가 “07:11” 같은 시간 입력
2. 현재 날짜와 입력 시간을 합쳐 “2024-12-12 07:11” 형식으로 만듦
3. 이 문자열을 datetime 객체로 변환
4. datetime을 UTC 타임스탬프로 바꿈
# 문제 원인
- 시간대 차이: 로컬은 한국 시간, 서버는 UTC 사용
- 시간 조정: 로컬에서 9시간 빼는 로직을 그대로 적용할 때 날짜가 바뀌어버림
- API 검증 로직: API가 record_time과 request_time 의 날짜가 같은지 확인하고 다르면 오류 발생
로컬은 KST, 서버는 UTC 사용 중임을 확인했다.
# 해결 방법
1. UTC 기준 사용: 모든 시간 계산은 UTC로 하고 필요할 때만 로컬 시간으로 바꾼다.
2. 시간 변환 로직 수정: 로컬 시간 변환 시 서버 시간대 고려해 UTC로 바꾼 후 필요한 시간대로 변환한다.
3. 테스트 환경 개선: 로컬 테스트 환경을 서버와 같은 시간대로 맞추거나 시간대 변환 테스트 환경을 만든다.
# Unix timestamp 라는 놈
유닉스 계열 운영체제에서 시간을 표시하는 방법인, 1970년 1월 1일 00:00:00 UTC부터 지난 시간(초)을 밀리세컨 단위까지 표현하는 수이다.
시간대와 관계 없이 UTC 기준으로 동작하기 때문에 컴퓨터 시스템에서 사용하기에 합리적인 측면이 있겠고 모두가 잘 사용하고 있는 시간대이지만 시간이라는 값을 다루는 시스템을 개발 할때 일반 시간대와의 양방향 변환을 꼭 챙겨줘야 한다. Unix to KST 시간 변환 공식을 사용하거나 https://www.unixtimestamp.com/ (opens new window) 이런 서비스에 넣어보면서 확인하기. 수가 직관적이지도 않아서 두통을 유발함.
32비트를 사용하므로 당연히 끝이 존재한다. 2038년 문제(Y2K38)로 말해지는 오버플로우 문제도 예정되어 있으며 그때까지 운영될 시스템이라면(?) 이에 대한 예외처리가 필요하다.
# 결론
시간대 차이 문제는 분산 시스템에서 자주 발생한다. UTC 기준으로 시간 처리하고 로컬-서버 간 시간대 차이를 고려하는 게 중요하다. 시간 관련 로직 꼼꼼히 검토하고 테스트해서 오류상황은 미리 방지하자.