시간대 규칙은 '법'이 정하는 거예요
우리는 흔히 시간을 자연의 법칙처럼 생각하지만, 사실 '지금 몇 시인가'는 사람이 정한 약속이에요. 특히 서머타임(일광 절약 시간제, 여름에 시계를 한 시간 앞당기는 제도)은 나라나 지역의 법으로 정해지고, 그 법은 언제든 바뀔 수 있어요. 최근 캐나다 브리티시컬럼비아주가 서머타임을 폐지하고 시간을 고정하는 방안을 논의하고 있는데, 이건 단순한 정치 이슈가 아니라 개발자들에게도 은근히 골치 아픈 문제예요.
무슨 말이냐면, 어떤 지역이 서머타임 규칙을 바꾸면 '미래의 특정 시각'이 실제로 몇 시인지가 달라져 버려요. 그리고 그 변화는 데이터베이스에 저장해둔 시간 값을 조용히 틀린 값으로 만들 수 있거든요.
Postgres는 시간을 어떻게 저장할까
PostgreSQL에는 시간을 다루는 타입이 크게 두 가지 있어요. 하나는 timestamp(시간대 정보가 없는 순수한 날짜·시각)이고, 다른 하나는 timestamptz(시간대를 고려하는 타입)예요. 이름은 비슷하지만 속은 꽤 달라요.
timestamptz는 사실 내부적으로 모든 시간을 UTC(세계 표준시, 시간대가 없는 기준 시각)로 바꿔서 저장해요. 예를 들어 '서울 시간으로 오후 3시'라고 넣으면, Postgres는 이걸 'UTC 오전 6시'라는 하나의 정확한 순간으로 변환해서 보관하죠. 그리고 우리가 꺼내 볼 때 다시 우리 시간대로 환산해서 보여줘요. 그래서 전 세계 사용자가 같은 데이터를 봐도 각자 자기 시간대로 올바르게 읽을 수 있는 거예요.
이 변환이 가능한 건 Postgres가 'IANA 시간대 데이터베이스(tz database)'라는 거대한 규칙표를 들고 있기 때문이에요. 이게 뭐냐면, '전 세계 모든 지역이 역사적으로 언제 서머타임을 켰고 껐는지, 표준시는 몇 시간인지'를 전부 정리해둔 사전이에요. America/Vancouver, Asia/Seoul 같은 이름이 다 여기 들어 있죠.
진짜 함정은 '미래의 약속'이에요
여기서 함정이 생겨요. 이미 지나간 시각이라면 문제가 없어요. 과거의 규칙은 더 이상 바뀌지 않으니까요. 하지만 '내년 11월 어느 날 오후 2시에 회의'처럼 미래의 시각을 저장할 때가 문제예요.
만약 이 미래 시각을 timestamptz로 저장하면, Postgres는 '지금 알고 있는 규칙'을 기준으로 UTC 순간을 계산해서 박아둬요. 그런데 그사이에 브리티시컬럼비아처럼 해당 지역이 서머타임 규칙을 바꿔버리면? 사람들이 기대하는 '현지 시각 오후 2시'와, DB에 박혀 있는 'UTC 순간'이 한 시간씩 어긋나 버려요. 회의가 갑자기 오후 1시나 3시에 잡히는 셈이죠.
그래서 베테랑 개발자들은 이렇게 조언해요. 미래의 이벤트는 UTC로 미리 못 박지 말고, '현지 시각 + 시간대 이름' 형태로 저장하라고요. 예를 들어 '2027-11-03 14:00, America/Vancouver'처럼 따로 들고 있다가, 실제로 그 시각이 다가왔을 때 최신 규칙으로 UTC를 계산하는 거예요. 그래야 중간에 법이 바뀌어도 항상 올바른 시각이 나와요.
규칙표도 꾸준히 업데이트해야 해요
또 하나 중요한 건, 이 tz database 자체가 계속 갱신된다는 점이에요. 어떤 나라가 서머타임을 바꾸면 IANA가 규칙표를 업데이트하고, Postgres나 운영체제도 그 최신판을 받아와야 올바르게 계산해요. SELECT * FROM pg_timezone_names;로 내 DB가 아는 시간대 목록을 확인할 수 있고, 시스템의 tzdata 패키지를 최신으로 유지하는 게 중요해요. 규칙표가 낡으면, 법은 바뀌었는데 DB만 옛날 규칙으로 계산하는 사고가 날 수 있거든요.
한국 개발자에게 주는 시사점
한국은 지금 서머타임을 쓰지 않고, 한국 표준시(KST)는 UTC+9로 고정돼 있어요. 그래서 '우리는 상관없겠지' 싶을 수 있는데, 꼭 그렇지 않아요. 글로벌 서비스를 만든다면 사용자의 시간대는 전 세계에 퍼져 있고, 그중 누군가의 나라는 언제든 규칙을 바꿀 수 있어요. 항공권 예약, 글로벌 화상회의, 구독 갱신일처럼 '미래의 현지 시각'을 다루는 기능이라면 이 문제를 반드시 고려해야 해요.
게다가 한국도 과거에 서머타임을 시행한 적이 있고(1980년대 올림픽 즈음), 정책적으로 다시 거론될 때가 있어요. 그러니 '시각을 UTC 한 점으로 저장할지, 현지 시각과 시간대를 따로 저장할지'를 설계 단계에서 구분해두는 습관이 중요해요. 이건 Postgres뿐 아니라 자바, 파이썬 등 모든 환경에 똑같이 적용되는 원칙이에요.
정리하며
한 줄로 정리하면, '시간대는 자연이 아니라 법이고, 법은 바뀌므로 미래 시각은 UTC로 못 박지 말라'예요. 여러분의 서비스는 미래의 약속 시각을 어떻게 저장하고 있나요? timestamptz 하나로 다 해결된다고 믿고 계셨다면, 오늘 한번 점검해보시는 건 어떨까요?
🔗 출처: Hacker News