TimeZone 및 날짜 포맷 이슈

이슈 공유(1)

소프트웨어 개발 및 운영 과정에서는 다양한 예기치 않은 이슈가 발생할 수 있습니다. 이번에는 저희 팀이 실제로 겪었던 타임존 및 날짜 포맷 관련 문제와 그 해결 과정을 공유하고자 합니다. 이 사례를 통해 유사한 문제를 겪는 개발자들이 참고할 수 있기를 바랍니다.

배경

서비스 운영 중 고객의 문의가 들어왔습니다. 로그를 확인해보니 서버에서 날짜 데이터를 파싱할 때 에러가 발생한 것을 확인했습니다. 이는 서버에 전달된 날짜 데이터가 예상 포맷과 일치하지 않아서 발생한 문제였습니다. 문제의 기능은 앱 네이티브 코드에서 건강 데이터를 받아 날짜별로 재포맷하여 서버에 보내는 기능이었습니다. 기존 코드에는 오전/오후 혹은 AM/PM 포맷에 대한 처리가 누락되어 있었습니다.

문제의 원인  

    클라이언트 데이터 가공 문제: 클라이언트 측 코드에서 데이터들을 한번 가공해서 서버에 보내고 있었는데, 가공되지 않은 데이터가 서버로 전송된 것으로 보입니다. 이 부분은 명확한 이유를 확인할 수 없었습니다.  

    아이폰 사용자: 문제는 아이폰 사용자에게서 발생했습니다. Swift에서 처리되지 않은 데이터가 서버로 넘어와 에러를 발생시킨 것으로 보입니다. 이는 OS 버그일 가능성도 고려되었습니다.  

문제 해결  

    서버에서 포맷 체크 추가: 서버 측에서 다양한 포맷을 처리할 수 있도록 날짜 파싱 로직을 수정했습니다.  

    DateUtils.parseDateStrictly 사용: 여러 포맷 패턴을 추가하여 파싱하도록 개선했습니다.  

추가 문제 발생

포맷을 추가하여 테스트를 진행하고 배포했지만, 여전히 파싱 에러가 발생했습니다. 개발 환경에서는 정상적으로 동작했지만, 배포 환경에서는 문제가 계속되었습니다.

원인 분석

배포된 서버의 Locale 설정은 개발 환경(ko_kr)과 달리 en_us으로 설정되어 발생한 문제였습니다. 

DateUtils.parseDateStrictly은 기본적으로 서버의 환경변수에 등록된 Locale을 Default로 설정하는데, 서버의 Locale이 KOREAN으로 되어있지 않으면 오전/오후 포맷을 인식하지 못하는 상황이 발생했습니다.

추가 해결

서버의 Locale값을 수정하거나 코드에서 Locale을 명시적으로 설정하는 방식 중 혹여나 사이드 이펙트를 우려해 후자를 택해 문제를 해결했습니다.

결론

이번 사례는 서버와 클라이언트 간의 날짜 데이터 포맷 및 서버간의 Locale 설정 차이로 인해 발생한 문제였습니다. 이러한 문제를 방지하기 위해서는 클라이언트와 서버 양쪽에 validation 체크와 예외에 대한 케이스를 고려하여 미리미리 대비해두는것이 좋을 것 같습니다. 혹시나 이와 같은 문제를 겪는 개발자들이 참고할 수 있도록 공유합니다.