Devlime에서 Time zone 설계 경험
1. 배경
Devlime의 개발 목적 중 하나는 시간과 장소에 제약 없이 협업이 가능한 글로벌 개발 환경을 구축하는 것입니다. 이에 따라 다국어 및 Time zone 도입을 포함한 글로벌 환경 구축을 담당하게 되었으며, 여러 국가의 사용자가 동일한 시스템에서 함께 작업할 수 있도록 하는 것이 목표였습니다.
초기 시스템은 모든 시간을 UTC 기준으로 저장하거나, 로컬 시간으로 저장하는 단순 구조였고, Time zone을 고려하지 않은 상태로 개발되어 있었습니다. 이로 인해 해외 근무자 또는 다국가 협업 환경에서 시간에 대해 혼선이 발생할 수 있었습니다. 특히 근태 시스템과 스프린트 시스템은 날짜와 시간 개념이 중요하기 때문에 단순 시간 저장 방식이 아닌 사용자 기준 시간 처리를 고려한 설계가 필요하다고 판단하였습니다.
2. 기존 방식의 문제점
초기 구현에서 근태 시스템의 출근 로직에선 클라이언트에서 ‘dayjs().utc()’를 사용하여 UTC 기준으로 시간을 생성하고, 이를 서버에서 그대로 저장하는 방식을 사용하였습니다. 반면 휴가 및 결근 데이터는 로컬 시간 기준으로 저장되고 있었습니다. 이 과정에서 다음과 같은 문제가 발생하였습니다.
첫째, 근태 유형 간 시간 처리 기준 불일치 문제로 출근 데이터는 UTC 기준, 휴가 및 결근 데이터는 로컬 기준으로 처리되면서 하나의 시스템에서 사용되는 데이터임에도 서로 다른 기준이 적용되었습니다. 이로 인해 ‘TeamAttendanceDay’와 같은 집계(쿼리)모델에서 데이터 일관성이 깨지는 문제가 발생하였습니다.
둘째, 사용자 기준 날짜 불일치 문제가 발생하였습니다. UTC 변환 과정에서 특정 국가의 경우 날짜가 하루 이전으로 저장되는 문제가 발생하였으며, 동일한 날의 데이터가 서로 다른 날짜로 인식되는 문제가 발생하였습니다.
셋째, 글로벌 확장에 대한 구조적 한계입니다. 단일 시간 기준(UTC)에 의존한 구조로 인해 사용자별 Time zone을 고려한 시간 처리가 불가능하였고, 모든 나라에서 일관되게 적용하기 어려운 구조입니다.
3. 개선 방향 및 설계
문제를 해결하기 위해 단순 UTC 기반 처리에서 벗어나, 사용자 기준 시간과 시스템 처리 기준을 분리하는 구조로 설계를 진행하였습니다.
3.1 Time zone 정보 관리
사용자 또는 팀 단위로 ZoneId를 관리하도록 설계하였습니다. 이를 통해 시간 데이터가 “어느 기준의 시간인지”를 명확하게 표현할 수 있도록 하였습니다.
3.2 시간 데이터 처리 구조 정의
시간 처리 방식은 다음과 같이 명확히 분리하였습니다.
- 데이터 생성 및 개인 화면 표시: 사용자 로컬 시간 기준
- 도메인 처리: LocalDateTime + ZoneId 기반 처리
- 통계/관리자 조회: 기준 ZoneId로 변환하여 통일된 기준 제공
이 구조를 통해 사용자 경험과 관리자 관점 모두 헷갈리지 않도록 설계하였습니다.
3.3 시간 표현 방식 개선
기존에는 단순 시간 값만을 사용하였다면, 개선 이후에는 LocalDateTime과 ZoneId를 함께 사용하는 방식으로 변경하였습니다. 특히, 근태 도메인에서는 시간이 아닌 “어떤 Time zone 기준의 날짜인지”가 중요하다고 판단하여, 모든 날짜 비교 및 집계는 ZoneId를 기반으로 해석하도록 설계하였습니다.
4. 적용 과정
프론트엔드에서는 ‘dayjs().utc()’ 사용을 제거하고, 사용자 zoneId를 기준으로 로컬 시간을 생성하도록 변경하였습니다. 또한 API 요청 시 시간 데이터의 의미를 명확히 전달할 수 있도록 구조를 개선하였습니다.
백엔드에서는 Java의 LocalDateTime과 ZoneId를 활용하여 시간 처리 로직을 재구성하였습니다. 특히, 근태 집계 로직에서 단순 날짜 비교를 제거하고, Time zone 변환 이후 비교하는 방식으로 변경하였습니다. 또한 시간 데이터의 처리 시점을 다음과 같이 정의하였습니다.
- 입력: 사용자 로컬 시간 기준 생성
- 처리: LocalDateTime + ZoneId 기반 도메인 로직 수행
- 조회: 사용자 또는 관리자 기준 ZoneId로 변환
이를 통해 시간 데이터의 흐름을 일관되게 유지할 수 있도록 하였습니다.
5. 적용 결과
Time zone 적용 이후 다음과 같은 기술적 개선을 확인할 수 있었습니다.
- LocalDateTime + ZoneId 기반으로 시간 처리 구조 통일
- 날짜 경계 문제 및 집계 오류 제거
- 사용자 및 관리자 관점에 따른 시간 표현 분리 구조 확립
이를 통해 글로벌 환경에서도 안정적으로 동작하는 시간 처리 구조를 구축할 수 있었습니다.
Bignow