개발을 하다 보면 날짜를 다루는 일은 쉽지 않다고 느끼게 됩니다. 어려운 이유는 여러 가지가 있지만, 그중 하나는 시간은 절대적이나 표기 방식은 상대적이란 사실을 뒤늦게 깨닫기 때문이죠. 웹프론트엔드 개발을 할 때, 지키면 좋은 3가지 날짜 규칙을 제시해볼까 합니다. 이 규칙들은 단순히 개발 편의성만을 위한 것은 아닙니다.
1. timestamp(Unix Time)로 통신하자
한국시간 오후 5시일 때 미국 워싱턴 DC는 오전 4시입니다. 절대적인 시간은 같더라도 지역마다 낮과 밤에 따라 적절한 차이(offset)를 둡니다. 반면 웹 이용자는 충분히 국경을 초월할 수 있죠. 기준이 되는 시간이 없다면 서버와 브라우저, 또는 브라우저와 브라우저 간 통신 때마다 서로의 지역을 고려해야 합니다. 이때 timestamp를 사용하면 훨씬 간단해집니다. 브라우저만 사용자의 지역 시간대와 timestamp 사이에서 바꾸기만 하면 되니깐요.
timestamp 대신 UTC(협정 세계시) 시간을 기준 삼아 날짜 형식으로 표기해도 괜찮습니다. 사람이 읽기에는 더 좋죠. 단 이때에는 또 서로 간 표기 형식을 신경 써야 하는 부담이 있습니다. 저는 읽기 편한 것보단 서로 맞추기 쉽고 값 계산이 편한 게 더 좋아 timestamp(Unix time)를 더 선호합니다. (KST(한국 표준시)가 아니라서 사실 읽기 그렇게 편하지 않다는 것도 한몫하구요)
2. 현재 시간을 서버로부터 내려받자
개발 시, 브라우저에서 제공하는 API를 통해 쉽게 가져올 수 있는 클라이언트 시간을 현재 시각으로 사용할 때가 많습니다. 하지만 브라우저 시간은 실제 시간과 다를 때가 종종 있습니다.
데스크톱 프로그램에서와 달리 웹페이지에 접속하는 사용자는 시간을 포함한 모든 데이터가 서버로부터 내려왔을 거라 기대합니다. 클라이언트의 잘못된 시간이 웹페이지에 영향을 주었을 것으로 생각하지 못하는 경향이 있죠. 서비스 품질에 대해 의심을 합니다. 최악의 경우, 서버로 잘못된 날짜를 보내 비즈니스에 큰 문제가 발생할 수도 있구요. 따라서 되도록이면 현재 시각을 서버로부터 내려받는 것이 좋습니다.
이 때, 라이브러리(servernow)를 사용하면 서버의 추가작업 없이도 간단하게 서버시간을 가져올 수 있습니다. (제가 만든 😅것이 오니) 많은 애용 부탁드리겠습니당 🙇
3. 언어(화면에 보여주는)를 기준으로 타임존(Timezone)을 지정하자
브라우저 기본값이 아닌 다른 지역 타임존 값을 지정하는 것은 여간 까다로운 일이 아닙니다. 라이브러리 도움 없이는 힘들죠. 그럼데도 언어(의 지역)를 기준으로 타임존을 지정해야 하는 이유는 무엇일까요?
화면상에 노출된 날짜로부터 가장 인접하게 지역 정보를 담고 있는 것이 언어란 점과 그동안 웹사이트들이 그래 왔었기(?) 때문입니다. 웹프론트엔드 역할이 부상하기 전까지 날짜 형식을 어떤 식으로 보여줄지 서버가 처리했었고, 애초 대부분의 웹사이트가 다국어 지원하지 않았기 때문에 오랫동안 많은 웹사이트의 날짜 타임존이 언어(의 지역)와 일치해 왔습니다. 이런 배경으로 인해 비록 브라우저(클라이언트) 지역 타임존과 다르더라 할지라도 화면상의 언어와 날짜 타임존 지역이 일치시키는 것이 덜 혼란스럽습니다.
(화면에 표시되는 언어가 영어처럼 지역이 광범위한 언어라면 날짜에 기준시를 같이 표기하는 것이 좋습니다. 시간이 매우 중요한 서비스 지점에서는 선택이 아닌, 필수!!)
결론
3가지 날짜 규칙을 한번 되짚어보면 1번 규칙은 개발 편의성을, 2번은 데이터 정합성, 3번은 사용자 혼란을 줄이기 위한 내용입니다. 이 규칙들은 절대적이지 않습니다. 상황에 따라 어떤 규칙은 들이는 노력에 비해 성과가 매우 미비할 수 있습니다. 지키면 좋다고 했지만 주어진 여건에 맞춰 적용하는 것이 바람직합니다. 감사합니다.
작성자
BYUNGI
https://github.com/skt-t1-byungiwrite less, do more