날짜 & 시간 문제 (Star-Breaker-Raid)

Star-Breaker-Raid는 일정 관리와 모집 글 작성이 핵심 기능이므로 날짜와 시간이 매우 중요한 요소입니다. 하지만 여러 기능이 시간과 관련되어 작동하는 과정에서 예상치 못한 문제가 발생했습니다. 이 글에서는 그 문제의 원인과 해결 방법을 정리하려 합니다.

문제발생

1. 시간 차이 문제 (로컬 환경 vs 배포 환경)
   로컬 환경에서 포맷팅한 시간이 배포 후 시간이 달라지는 문제가 발생했습니다.

2. DB 저장 및 함수 실행 문제
   로컬 환경과 배포 환경에서 날짜 및 시간을 저장하는 방식이 다르고, 이로 인해 시간 관련 함수 실행 결과에도 차이가 발생했습니다.

3. 서버 랜더링(SSR) vs 브라우저 랜더링(CSR) 문제
   서버에서 랜더링할 때와 브라우저에서 랜더링할 때의 시간 차이가 발생했습니다.

문제 원인

1. 배포 환경과 로컬 환경의 시간 차이
   Star-Breaker-Raid는 Vercel에 배포되었으며, Vercel의 서버 및 DB 시간대는 UTC로 설정되어 있습니다.
   하지만 한국 시간(KST)은 UTC+9이므로, 배포 후 9시간의 차이가 발생했습니다.

이로 인해, 시간을 포맷팅하거나 계산할 때 UTC 기준으로 저장된 데이터를 한국 시간에 맞춰 변환해야 하는 문제가 생겼습니다.

2. 서버 랜더링(SSR)과 클라이언트 랜더링(CSR)의 차이
   DB에서 가져온 시간 데이터는 UTC로 저장되어 있습니다.

• 서버에서 랜더링(SSR) → UTC 시간을 변환하지 않고 HTML을 생성
• 브라우저에서 랜더링(CSR) → 브라우저가 자동으로 시간 데이터를 사용자의 현지 시간대(KST)로 변환
  즉, 서버에서 UTC로 랜더링된 시간이 브라우저에서 +9시간이 추가되면서 중복 변환되는 문제가 발생했습니다.

해결

1. 환경 변수 사용
   로컬과 배포 환경의 시간 차이를 해결하기 위해 환경 변수를 도입했습니다.

# 배포 환경
TIMEZONE_OFFSET=0

# 로컬 환경 (한국 시간 기준)
TIMEZONE_OFFSET=9

이 변수를 활용하여 시간 포맷팅 시 addHours 함수를 적용해, 모든 환경에서 동일한 시간대를 유지하도록 했습니다.

이제 로컬과 배포 환경에서 일관된 시간을 유지할 수 있습니다.

2. SSR과 CSR에서 다른 포맷팅 적용
   랜더링 방식(SSR vs CSR)에 따라 시간 변환 방법을 다르게 적용했습니다.

• SSR(서버 측 랜더링) → UTC를 KST로 변환하여 포맷팅
• CSR(클라이언트 측 랜더링) → 브라우저의 자동 변환을 고려하여 별도로 변환하지 않음
  이제 서버와 브라우저에서 동일한 시간대를 유지하면서도, 예상치 못한 추가 변환을 방지할 수 있습니다.

결론

이번 문제를 해결하면서 서버와 클라이언트의 시간 처리 방식 차이를 정확히 이해하는 것이 중요하다는 것을 깨달았습니다. 초기에는 원인을 몰라 많은 시행착오를 겪었지만, 환경 변수와 랜더링 방식에 따른 포맷팅 차이를 고려하면서 문제를 해결할 수 있었습니다.