얼마 전 한 기업의 코딩 과제에서 다음과 같은 요구사항을 받았다.
구매 상담 내역이 등록된 일자를 기반으로 필터링 조회할 수 있는 기능을 구현해주세요.
(ex. 2025-03-01 ~ 2025-03-31 사이에 등록된 구매 상담 내역만 조회)
간단해 보이는 이 요구사항 뒤에는 중요한 질문이 숨어 있었다. 바로 시간을 어떻게 저장하고 처리할 것인가 하는 문제였다.
국내 서비스를 운영한다면 KST(한국 표준시)를 기준으로 시간을 저장하고 처리하는 것이 직관적일 수 있다. 하지만, 서비스가 글로벌하게 확장될 경우, 여러 시간대를 지원해야 하는 상황에서 UTC(협정 세계시)를 사용하는 것이 더 적합할지도 모른다.
따라서 이 문제를 제대로 풀어내기 위해서는 단순히 KST와 UTC의 차이점을 아는 것에 그치지 않고, 타임존에 대한 근본적인 이해가 필요하다. 1부에서는 타임존과 관련된 표준을 정리하고, 2부에서는 실제로 클라이언트와 백엔드 사이에서 타임존을 어떻게 처리할 수 있을지에 대해 논의해보자.
날짜 및 시간 관련 기본 개념
Timezone
타임존은 동일한 로컬 시간을 따르는 지역을 의미하며, 주로 해당 국가에 의해 법적으로 지정된다. 보통 국가별로 각자의 고유한 타임존을 사용하고 있으며, 미국이나 러시아처럼 면적이 넓은 나라인 경우 지역별로 각기 다른 타임존을 사용하기도 한다. 반면 중국은 광활한 영토에도 불구하고 하나의 타임존을 이용하고 있다. 중국 서부 사람들은 아침 10시에 출근하고 1시 반에서 2시 사이에 점심을 먹고 저녁 8시에 퇴근해서 새벽 1~2시에 취침한다고..
GMT (Greenwich Mean Time)
한국의 타임존은 보통 GMT+09:00 으로 표현된다. GMT는 경도 0도에 위치한 영국 그리니치 전문대 기준으로 태양 시간을 의미한다. GMT 시간은 1925년 2월 5일부터 사용하기 시작하였으며, 1972년 1월 1일까지 세계 표준시로 사용되었다.
UTC (Coordinated Universal Time)
일상적으로 GMT와 UTC는 거의 같은 의미로 사용하는 경우가 많지만, 엄밀히 따지면 둘은 다른 기준을 가지고 있다. UTC는 1972년에 도입된 시간 기준으로, 세슘 원자의 진동수를 기반으로 측정하는 국제 원자시(TAI)에 맞춰 만들어진 새로운 표준 시간이다. 이는 지구의 자전 속도가 점점 느려지는 문제를 보완하기 위한 목적도 포함하고 있다. 즉, GMT는 태양의 움직임을 기준으로 한 ‘천문학적 시간’, UTC는 원자시계를 기반으로 한 ‘과학적·기술적 시간’이라고 볼 수 있다.
둘 시간의 차이는 거의 없지만, 정확성을 요구하는 소프트웨어나 시스템 개발에서는 ‘UTC’라는 용어를 사용하는 것이 더 적절하다고 할 수 있다.
Offset
오프셋은 현재 시간이 UTC 기준에서 얼마나 빠르거나 느린지를 나타내는 값이다. 예를 들어, UTC+09:00는 UTC보다 9시간 빠른 지역을 의미하고, UTC-03:00은 UTC보다 3시간 느린 지역을 의미한다. 만약 UTC 기준 시간이 낮 12시라면, UTC+09:00 지역은 오후 9시가 된다.
참고로, 대부분의 오프셋은 1시간 단위이지만, 예외적으로 30분 또는 45분 단위도 있다. 예를 들어, 북한은 UTC+08:30을 사용하고, 호주의 일부는 UTC+08:45, UTC+09:30을 사용한다.
KST (Korea Standard Time)
보통 국가나 지역에서는 오프셋에 자신만의 이름을 붙여서 사용하기도 한다. 예를 들어, KST는 한국 표준 시간, JST는 일본 표준 시간, EST 미 동부 표준 시간을 나타낸다. 이러한 이름들은 보통 약어 형태의 로컬 시간대 이름인데, 동일한 오프셋을 여러 나라가 공유할 수 있기 때문에 오프셋과 타임존 이름은 1:1 관계가 아니라 1:N 관계이다. 따라서 오프셋만으로는 어느 나라의 시간인지 구분이 어렵다.
Timezone과 Offset은 다르다?
그렇다면 KST는 무조건 UTC+09:00로 볼 수 있을까? 정확하게는 타임존과 오프셋은 같지 않다. 그 이유는 크게 두 가지이다.
서머타임(Daylight Saving Time, DST)의 존재
하나의 타임존은 계절에 따라 오프셋이 달라질 수 있는 가변 개념이다.
해외에서는 여름철에 표준시보다 1시간 빠른 시각을 사용하는 제도, 즉 DST(일광 절약 시간제)를 도입하는 경우가 많다. 예를 들어, 미국 캘리포니아는 일반적으로 PST (UTC-08:00) 를 사용하지만, 하절기에는 PDT (UTC-07:00) 를 사용한다. 이 둘을 묶어서 PT (Pacific Time)이라고 부르기도 한다.
타임존은 나라의 정책에 따라 변할 수 있다
오프셋은 단순한 시차 숫자지만, 타임존은 국가가 지정하는 법적 시간이다. 따라서 한 나라의 정치적, 경제적 이유로 언제든지 바뀔 수 있다. 예를 들어, 사모아 섬의 경우 2011년까지 UTC-10:00을 사용하다가 무역상 이점을 위해 UTC+14:00으로 변경됐다. 이 과정에서 2011년 12월 30일 하루가 사라졌다! 미국의 경우 2005년에 조지 부시 대통령이 서명한 에너지 정책법에 의해 2007년부터 DST의 시작일과 종료일이 변경됐다.
타임존과 오프셋은 1:N 관계
위에서 살펴본 내용을 정리해보자면, 한 지역의 타임존은 하나 혹은 그 이상의 오프셋을 가지며, 어느 시점에 어떤 오프셋을 기준시로 이용할지는 해당 지역의 정치/경제적 상황에 따라 계속해서 달라진다고 할 수 있다.
일상 생활에서는 이런 상황이 큰 문제가 없을지도 모르지만, 이를 규칙에 따라 시스템화 시키려고 하면 문제가 발생한다. 예를 들어, 어떤 사용자가 3월 31일에 일정을 저장한다고 해보자. 이 날짜는 DST가 적용되는 시점인지 아닌지에 따라 적용되는 오프셋이 달라질 것이다. 또 다른 예로는, 미국의 경우 2007년을 기준으로 DST 를 적용하는 시점이 변경되었기 때문에, 2006년 3월 31일은 PDT(-07:00)가 기준시가 되지만, 2007년 3월 31일은 PST(-08:00)가 기준시가 되어야 할 것이다. 즉, 특정 지역의 타임존을 지칭하기 위해서는 역사적으로 표준시간대 혹은 DST 적용 룰이 언제 변경되었는지에 대한 데이터를 모두 갖고 있어야만 정확한 시간을 계산할 수 있는 것이다.
그러면 우리는 특정 지역의 타임존을 오프셋이 아닌 무엇으로 지칭해야 할까? 바로 지역명이다. 정확히 이야기하면 역사적으로 표준시간대나 DST의 변경이 동일하게 적용되었던 지역을 하나의 타임존으로 묶어서 지칭할 수 있을 것이다. 앞서 잠깐 언급했던 PT (Pacific Time)과 같은 명칭이 이용될 수도 있겠지만, 이는 현재의 표준시와 DST만을 묶어놓은 개념이기 때문에 역사적인 변경내역을 모두 포함한다고 할 수는 없을 것이다. 또한 PT는 미국/캐나다 지역에서만 사용되는 이름이기 때문에, 소프트웨어에서 범용적으로 사용하기 위해서는 신뢰할 수 있는 기관에서 관리하는 표준이 필요하게 된다.
IANA Time Zone Database
이런 이유로 타임존은 단순히 몇 가지 규칙으로 정의할 수 없고, 이를 시간에 따른 정책 변경 이력까지 포함한 데이터베이스로 관리해야 한다. 현재 가장 널리 사용되고 신뢰받는 타임존 데이터베이스는 바로 IANA Time Zone Database이다. IANA Time Zone Database는 보통 tz database (tz data) 라고 불리며, 전 세계 모든 지역의 표준시와 DST 변경 내역을 담고 있다. 현재 역사적으로 확인할 수 있는 모든 데이터가 들어있다고 볼 수 있는데, UNIX 시간 (1970.01.01 00:00:00) 이후의 데이터의 정확도를 보장하도록 정리되었다. (즉, 1970년 이전의 데이터도 있지만 이 시기의 데이터는 완벽한 정확성을 보장하지는 않는다.)
IANA는 Area/Location 형식으로 타임존을 명명한다. Area는 대륙 또는 대양 이름, Location은 주로 큰 도시 이름을 사용한다. 예를 들어, 대한민국은 Asia/Seoul, 일본은 Asia/Tokyo 이다. 국가 이름이 아니라 도시 이름을 사용하는 이유는, 국가는 수십 년 안에도 해체되거나 통합될 수 있지만, 도시는 비교적 더 오랫동안 유지되기 때문이다.
이 데이터베이스는 많은 개발자들, 역사학자들, 커뮤니티에 의해 관리되고 있으며, 역사적 발견이 추가되거나 정부 정책이 바뀌는 경우 바로 갱신되기 때문에 신뢰도가 높다. 실제로 리눅스, macOS등 유닉스 기반의 OS들이나 자바, PHP 등 유명 프로그래밍 언어들 등 이미 많은 시스템에서 이 데이터베이스를 내부적으로 사용하고 있다.
참고로 Windows는 IANA 대신 자체적으로 관리하는 Microsoft Time Zone Database를 사용한다. 그래서 이 데이터는 역사적 변경 내역이 불완전하고, 오직 Microsoft만이 관리하기 때문에 정확성이나 신뢰도 면에서 IANA보다 낮다고 평가받는 경우가 많다. 그래서 개발자들 사이에서는 가능하면 IANA 기준을 따르자는 분위기가 많다.
자바스크립트와 IANA time zone database
그런데… 이렇게 중요한 타임존 처리에 있어서 자바스크립트는 믿고 쓰기엔 조금 불안한 면이 존재한다. 자바스크립트는 기본적으로 OS에 설정된 로컬 타임존을 따른다. 즉, 기본 Date 객체 기준으로 명시적으로 타임존을 설정하거나 변경할 수 있는 방법이 없다. 게다가 타임존 연산에 사용되는 데이터베이스 표준도 명확히 명시되어 있지 않다.
ES2015의 모호한 타임존 스펙
자바스크립트의 핵심 스펙인 ECMAScript 2015(ES6)를 살펴보면, 타임존과 관련된 정의는 놀랍게도 두세 줄 밖에 안된다.
An implementation dependent algorithm using best available information on time zones to determine the local daylight saving time adjustment DaylightSavingTA(t), measured in milliseconds.
한 마디로 요약하면 “타임존? DST? 알아서 최대한 잘 구현해봐~” 라는 느낌이다.
즉, 각 브라우저 벤더가 자율적으로 구현하게 되어 있다는 의미이다. 당연히 브라우저마다 타임존 처리 결과가 조금씩 다를 수 있다.
그래도 혹시나 싶어 문서를 더 내려보면, 이런 노트가 하나 있다.
NOTE: It is recommended that implementations use the time zone information of the IANA Time Zone Database.
“IANA DB 쓰는 걸 권장하긴 한다 ”
”정말로 이렇게 단 한줄이다. 표준은 아니고, 그냥 “추천”일 뿐이다.
그나마 다행인 것은 자바스크립트가 타임존 관련해서 아예 방법이 없는 건 아니다. Intl.DateTimeFormat에서 IANA timezone을 사용하는 옵션이 추가되긴 했지만, 여전히 다른 언어에 비해서는 신뢰할만한 타임존 지원이 많이 부족하다고 볼 수 있다.
마무리하며
타임존은 단순한 시간 계산을 넘어, 역사적 변경과 지역적 특성까지 반영해야 하는 꽤 복잡한 개념이다. 이를 정확히 처리하려면 표준화된 데이터베이스와 언어 차원의 지원이 필요한데, 자바스크립트는 아쉽게도 이 부분에서 부족한 편이다. 2부에서는 실제로 클라이언트와 백엔드 사이에서 타임존을 어떻게 처리할 수 있을지에 대해 논의해보자.
