글로벌 서비스에서 시간 다루기 (1) — 시간은 어떻게 정의되었을까?
안녕하세요! 퍼블의 소프트웨어 엔지니어 정주형입니다. 퍼블은 기술 없이 나만의 플랫폼으로 수익을 창출할 수 있는 노코드 플랫폼 빌더입니다. 또한 퍼블은 나만의 브랜디드 앱을 만드는 멋진 서비스도 제공하고 있답니다.
개발자라면 한번쯤은 시간과 관련된 이슈를 겪은 적이 있을 것입니다. 스케쥴링된 작업이 원하는 시간이 동작하지 않는다던지, 포스트를 등록했는데 등록 시간이 9시간 전으로 나온다던지 등등요.
소프트웨어 개발에 있어 시간을 다루는 것은 생각보다 복잡합니다. 어떤 국가는 서머타임을 사용하고, 어떤 국가는 서머타임을 사용하지 않습니다. 시간을 지칭하는 용어들도 어렵고 복잡하죠. GMT, UTC, TAI, DST 등등 약자만 봐도 헷갈립니다.
글로벌 서비스에서 시간 다루기 글은 2부로 이루어져 있습니다.
1부에서는 시간과 관련된 도메인 지식에 대해서 알아볼 것입니다. 시간이 어떻게 정의되어 왔는지 그 역사에 대해서 간단하게 알아보고, 각 용어들에 대해 설명하도록 하겠습니다.
그리고 2부에서는 실제로 코드에서 어떻게 시간 관련 문제들을 다루어야 할지 실전 예제를 통해서 알아보도록 하겠습니다.
옛날 옛적에 태양시가 살았어요
히스토리 관리는 소프트웨어 개발에 있어서도 중요합니다!
프로덕트의 히스토리는 중요합니다. 웹 개발에서 사용되는 Flux 패턴을 예로 들어 봅시다.
히스토리를 제외하고 단순히 Flux 패턴을 설명하면 다음과 같습니다.
Flux 패턴은 단방향 데이터 흐름을 사용하여 웹 애플리케이션의 상태를 관리하는 아키텍처 패턴입니다.
그렇군요. 히스토리를 같이 설명해 보자면 어떨까요?
페이스북에서는 빈 알림 문제가 계속되고 있었습니다. 빨간 불이 떠 있었지만 막상 알림을 눌러 보면 아무것도 보이지 않는 문제였죠.
기존의 MVC 패턴이 문제라는 것을 깨달은 그들은 데이터를 단방향으로 흐르게 하는 방식을 고안해 냅니다. 이것이 바로 Flux 패턴입니다.
비록 같은 설명이라도 명쾌하게 이해가 되지 않나요? 이처럼 우리는 프로덕트의 개발 과정을 통해 이것이 무엇을 해결하려고 하는지, 무엇을 의미하는지 알 수 있습니다.
시간의 정의 또한 하나의 제품이라고 생각해 봅시다. 이것이 어떻게 바뀌어 왔는지, 그리고 또 어떤 문제를 해결하려고 하는지 이해하는 것이 더 시간을 잘 이해하게 해 줄 것입니다.
Back to the 19th century
우리가 일반적으로 생각하는 시간이 도입된 것은 그리 오래되지 않았습니다. 19세기 중반까지 거의 모든 도시는 태양에 주기에 따른 자체적인 현지 시간을 지켰습니다. 시간을 측정하는 법은 각자가 사는 곳마다 달랐죠.
현대적인 의미의 ‘공통된 시간’이란 존재하지 않았습니다. 그러나 기술의 발전에 따라 생활권이 넓어짐에 따라 조금씩 문제가 생기기 시작하였습니다.
Photo:Anirban Ghosh
예를 들어 봅시다. 19세기 영국에서는 기차가 발명되었습니다. 운행하기 시작한 뒤 얼마 되지 않아 많은 문제들이 생겼습니다. 각 도시마다 시간이 달랐기 때문에 기차의 출발과 도착 시간이 정확하지 않았습니다.
영국의 브리스톨은 같은 나라에 위치한 도시임에도 불구하고 런던보다 시간이 10분 늦었습니다. 브리스톨에서 런던으로 온 여행자는 기차를 놓치기 일쑤였죠. 심지어 시간 때문에 기차들끼리 충돌 사고가 발생하기 일쑤였습니다.
이러한 문제를 해결하기 위해서 영국에서는 1884년 그리니치 표준시(이하 GMT, Greenwich Mean Time) 이라는 것을 만들게 됩니다. 이것이 우리가 지금 사용하는 시간입니다. 정확히 말하자면 지구에 사는 사람들이 모두 사용하는 공용 시간인 것이죠.
그리니치 표준시는 다음과 같이 시간을 정의하였습니다. 태양의 위치를 기준으로 그리니치의 시간을 먼저 정의합니다. 태양이 그리니치 천문대 위에 가장 높이 떠 있을 때가 낮 12시입니다.
그리고 그리니치의 위치를 시작으로 남극과 북극을 잇는 선들을 사용해 지구를 경도 15도마다 나누었습니다. 이 같은 선들을 자오선, 그리고 그리니치에서 시작되는 기준선을 그리니치 자오선 혹은 본초 자오선이라고 부릅니다.
그리니치 천문대에서는 레이저로 그리니치 자오선을 나타내고 있습니다
그리고 GMT는 이렇게 잘린 자오선마다 (15도마다) 1시간의 차이를 두었습니다. 이와 같이 잘린 단면들을 우리는 타임존 (Timezone) 이라고 부릅니다.
대한민국을 기준으로 이야기 해 보겠습니다. 대한민국이 속한 자오선 영역은 그리니치 자오선을 기준으로 동경 135도에 위치해 있습니다. 따라서 15 * 9 = 135 이므로 대한민국의 시간은 그리니치의 시간보다 9시간이 빠르게 됩니다. 이것을 GMT+09:00과 같이 표현합니다.
이렇게 GMT가 도입되게 되면서 영국은 아까 말했던 문제들을 해결하게 되었습니다. 브리스톨과 런던은 이제 같은 타임존에 위치하고 있으므로 (GMT+0:00) 두 곳에서의 시간은 같아졌습니다. 이제 여행객들은 기차를 놓치지 않고 기차들끼리 충돌하는 일은 없어졌습니다.
영국 뿐만 아니라 세계가 그리니치 표준시를 기준으로 사용하게 되므로 기차가 아니라 이메일, 심지어 스케쥴링된 잡들도 우리가 의도한 시간에 동작하게 되었습니다.
UTC
그러나 GMT는 위에서 말했듯이 천문학적인 관측-태양을 기반으로 하므로 선천적인 한계를 지니고 있었습니다.
GMT의 1초는 평균 태양일의 1/86,400, 즉 지구가 자전하여 태양을 한바퀴 도는데 걸리는 시간을 나눈 값이었습니다. 그러나 지구의 자전축은 기울어져 있는데다 자전 속도가 일정하지 않았으므로 이는 정확한 값이 아니었습니다.
따라서 이를 보완하기 위해 1949년 원자시계가 발명되게 됩니다. 원자 시계는 세슘원자로부터 나오는 특정 빛의 진동수를 기준으로 하기에 훨씬 정확했죠. (해당 내용까지 설명하기에는 너무 복잡하므로 설명하지 않겠습니다) 이제 1초는 세슘-133 원자가 9,192,631,770번 진동하는데 걸리는 시간이 되었습니다.
원자시계의 모습. 인테리어 소품으로 딱입니다.
그리고 1972년 GMT는 원자시계를 기반으로 하는 협정 세계시 (이하 UTC, Universal Time Coordinated)로 대체되었습니다. 이렇게 해서 우리가 알고 있는 UTC가 탄생하게 된 것입니다.
UTC는 GMT가 사용하던 타임존의 개념을 그대로 사용합니다. 따라서 둘의 차이점은 단순히 UTC가 소숫점 단위로 더 정확하다는 것 밖에 없습니다. 하지만 당연히 더 정확한 단위를 쓰는 것이 좋겠죠?
따라서 글을 쓰는 현재 기준으로 다시 한번 대한민국의 표준시를 정리하면 다음과 같습니다. 대한민국은 그리니치 천문대를 기준으로 동경 135도에 위치해 있으므로 대한민국의 표준시는 UTC+09:00 입니다.
타임존은 말랑말랑해
아까 위에서 그리니치를 기준으로 15도마다 1시간의 차이를 둔 것이 타임존이라고 설명했습니다. 해당 사진은 2023년 기준 타임존입니다.
자, 자오선은 남극과 북극을 가상의 선으로 자른 것입니다. 그러나 그림에서 보이듯이 자오선은 일자가 아닙니다. 엥, 가상의 선인데 어떻게 일자가 아닐 수 있죠? 라는 궁금증이 드신다면 대답해 드리는게 인지상정.
자오선이 일자가 아닌 이유, 즉 타임존이 멋대로인 이유는 타임존의 지정이 과학적인 이유로만 이루어진게 아니기 때문입니다.
다시 대한민국을 예로 들어보겠습니다. 그림에서 보시면 대한민국은 UTC+09:00에 위치해 있습니다.
그러나 타임존이 일자로 되어 있었다면 대한민국은 UTC+08:00에 있어야 합니다. 그런데 왜 볼록 튀어나온 UTC+09:00 타임존에 위치해 있는 걸까요?
왜냐하면 박정희 군사정부 시절, 공산국가인 중국과 같은 타임존에 위치할 수 없다는 정치적인 이유로 일본과 같은 타임존인 UTC+09:00에 위치하게 되었습니다. (사실 정확히 한다면 대한민국의 타임존은 UTC+08:30에 위치해야 합니다. 다만 30분 단위 타임존은 드뭅니다)
이처럼 타임존의 지정은 정치적, 문화적 이유를 따릅니다. 따라서 언제 바뀔지 모릅니다. 즉 절대적인 기준이 없는 것입니다. 그런데 우리는 소프트웨어 개발을 하고 있고, 해당 지역의 시간을 보여주어야 합니다. 그런데 뭐를 기준으로 해야 하죠?
정답: IANA 데이터베이스
답은 IANA 데이터베이스에 적혀 있는 타임존을 기준으로 하면 됩니다.
IANA는 인터넷 할당 번호 관리 기관으로써 인터넷 프로토콜(IP) 주소, 도메인 이름, 프로토콜 포트 번호 및 기타 인터넷 관련 식별자를 할당하고 관리하는 책임이 있는 비영리 단체입니다. 그리고 타임존 데이터베이스도 유지 관리하고 있죠.
타임존에 대한 절대적인 기준은 없지만 우리는 해당 데이터베이스를 통해서 현재 타임존의 상태, 국가가 어떤 타임존을 가지고 있는지, 혹은 섬머 타임 (DST Daylight saving time) 을 사용하고 있는지 알 수 있습니다.
타임존의 변경은 일어나지만, 실제로 그렇게 자주 일어나는 일이 아니니 사실 IANA 타임존 데이터베이스가 기준이라고 생각해도 문제는 없습니다. 자바스크립트 말고도 많은 언어 (Python, C#, Java) 들도 해당 데이터 베이스를 이용해서 타임존 관련 기능을 지원하고 있습니다.
List of tz database time zones
- 해당 위키피디아는 데이터베이스를 쉽게 볼 수 있도록 표 형태로 정리해 놓은 문서로써 각 국가들이 어느 타임존에 속하는지, 서머타임을 사용하는지와 같은 사항들을 나타내고 있습니다.
TL;DR
- 특정 국가의 ‘시간’은 협정세계시(UTC) 를 해당 국가의 시간대 규칙(타임존)에 따라 변경한 시간입니다
- 우리는 지금 대한민국에 살고 있습니다. 그리고 대한민국의 시간은 엄밀히 말하면 다음과 같습니다.
- 그리니치의 시간(UTC+09:00)을 기준으로 한국의 타임존(KST)은 UTC+09:00 이므로 한국의 시간은 영국보다 9시간 앞선 시간입니다.
이렇게 해서 시간의 역사에 대해서 알아보았습니다. 다음 글에서는 코드에서 이를 어떻게 다뤄야 하는지에 대해 알아보도록 하겠습니다. 다음 글에서 다시 만나요!
레퍼런스
Time zone and daylight saving time data
https://ko.ibos.co.at/what-is-greenwich-mean-time
글로벌 서비스에서 시간 다루기 (1) — 시간은 어떻게 정의되었을까? was originally published in 퍼블 팀 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.