2. 사이트 등록 시 timezone을 받도록 설계한 이유

사용자가 등록한 사이트에는 전 세계의 방문자가 접속할 수 있다. 사이트 운영자는 미국에 거주하더라도 방문자는 서울, 도쿄, 런던 등 서로 다른 지역에 있을 수 있다. 내가 우려한 문제는 바로 이 지점에서 발생한다.

사이트를 등록한 운영자와 다른 시간대에 사는 방문자가 접속하면 이벤트가 미래 혹은 과거의 데이터로 보여질 텐데, 운영자에게 혼동을 주지 않을까?

어떠한 기준없이 방문자의 현지 시간을 기준으로 데이터를 집계하면 이처럼 사이트의 하루가 방문자마다 달라질 수 있다. 예를 들어 서울에서는 8월 15일인 순간에 뉴욕은 아직 8월 14일일 수 있다. 반대로 뉴욕이 8월 15일인 순간에 UTC+14 지역인 키리티마티는 이미 8월 16일일 수도 있다.

즉, 같은 순간에 발생한 이벤트라도 방문자의 위치에 따라 날짜가 다르게 해석될 수 있다.

그렇다면 모든 이벤트를 UTC라는 하나의 공통 기준으로 나누고, 이를 사용하면 방문자 위치에 따라 같은 이벤트가 서로 다른 날짜에 집계되는 문제는 해결할 수 있다고 보았다. 하지만 UTC의 날짜 경계가 사이트 운영자가 생각하는 하루의 경계와 일치한다는 보장이 없다는 것을 알게됐다.

예를 들어 **"8월 15일의 데이터"**라고 한다면 일반적으로 아래의 범위를 떠올린다:

8월 15일 00:00 ~ 8월 15일 23:59

하지만 위 범위는 UTC의 날짜 경계와 다르기 때문에, UTC 기준으로만 데이터를 나눈다면 운영자가 생각하는 사이트의 하루와 대시보드의 날짜가 달라질 수 있었다. 예를 들어 운영자가 8월 15일 데이터를 확인하려고 했지만, 대시보드에서는 UTC 기준으로 일부 이벤트가 전날이나 다음 날에 포함될 수 있다.

해결 방법: 사이트 타임존 도입

결국 대시보드에서 이벤트를 해석하는 올바른 기준이 필요했고, 이것을 사이트 타임존으로 해결했다.

분석 데이터의 날짜는 단순히 이벤트가 발생한 지역의 날짜가 아니라, 사이트 운영자가 데이터를 해석하는 기준이 되어야 한다. 그래서 사이트를 등록할 때 해당 사이트의 타임존을 입력받아 함께 저장한다. 이 타임존은 방문자의 위치나 서버의 위치가 아니라, 해당 사이트의 분석 보고서에 사용할 기준 시간대다.

사이트 타임존이 America/New_York이라면 다음과 같이 처리한다.

즉, 이벤트 발생 시각과 이벤트 집계 시각의 기준을 따로 분리하는 것이다. UTC는 전 세계에서 공유할 수 있는 일관된 시각 기준이기 때문에, 원본 이벤트를 UTC로 저장하면 지역별 날짜 표현이 달라져도 실제 발생 시점을 잃지 않는다.

따라서 이벤트 발생 시각은 UTC 기준의 timestamp로 전송하고 저장한다. 반면 이벤트 집계는 사이트 타임존을 사용한다.

이벤트 발생
  → UTC 시각으로 전송
  → UTC 시각으로 원본 저장
  → 사이트 타임존 기준으로 날짜와 시간 경계 계산
  → 사이트 기준 일별·시간별 데이터로 집계
  → 대시보드에 표시

타임존으로 해결할 수 있는 문제들

예시 1 — 방문자의 현지 날짜와 사이트 보고 날짜가 다른 경우

사이트의 타임존이 America/New_York이라고 가정하고, 서울에 있는 방문자가 다음 시각에 사이트에 접속한다:

방문자 현지 시간: 8월 15일 09:00, 서울
UTC:          8월 15일 00:00
뉴욕 시간:      8월 14일 20:00

방문자는 자신의 현지 시간으로 8월 15일에 접속했다. 그러나 같은 순간 뉴욕은 아직 8월 14일이다. 따라서 이 이벤트는 다음과 같이 집계한다:

방문자 현지 날짜: 8월 15일
사이트 보고 날짜: 8월 14일

해당 사이트의 보고 기준을 뉴욕으로 정했기 때문에, 이벤트가 뉴욕 시간으로 속한 날짜에 집계된다. 이 기준을 사용하면 방문자가 어느 지역에 있든 사이트 운영자는 자신의 사이트 타임존을 기준으로 데이터를 일관되게 확인할 수 있게 된다.

예시 2 — UTC 기준 집계로 등록 이후 데이터가 등록일 전날처럼 보이는 경우

이번에는 사이트 타임존이 Tokyo 라고 가정한다. 운영자가 도쿄 시간으로 8월 15일 00:30에 사이트를 등록했다:

사이트 생성 시각: 8월 15일 00:30, 도쿄
UTC 시각:      8월 14일 15:30

사이트가 생성된 10분 후에 이벤트가 발생했다:

이벤트 발생 시각: 8월 15일 00:40, 도쿄
UTC 시각:      8월 14일 15:40

이벤트는 사이트가 생성된 뒤에 발생했으므로 실제로는 등록 이후 데이터다. 이때 사이트 타임존을 사용하지 않고 UTC 날짜만 기준으로 집계하면 이 이벤트는 UTC 기준 8월 14일 데이터로 분류된다. 그러면 운영자는 다음과 같은 의문이 들게 된다:

사이트는 분명 8월 15일에 등록했는데 왜 8월 14일의 데이터가 표시되는 거지?

이 의문은 굉장히 합당하다. 이벤트는 사이트 생성 시각 이후에 발생했기 때문에 데이터가 잘못 집계된 것은 아니다. 다만, UTC 날짜와 운영자가 이해하는 도쿄 현지 날짜가 다르고 UTC를 기준으로 집계했기 때문에 등록 이후 이벤트가 등록일 전날의 날짜로 표시된 것이다.

만약 사이트 타임존을 사용하면 이 이벤트는 도쿄 시간 8월 15일 00:40에 발생한 이벤트로 해석되어 혼동을 줄일 수 있다.

사용자가 등록한 사이트에는 전 세계의 방문자들이 방문할 수 있다. 사용자는 미국에 거주하더라도 방문자는 서울, 일본, 영국 등에 있을 수 있다.

이때 방문자의 현지 시간으로 데이터를 집계하면 같은 사이트의 하루가 방문자마다 달라지는 문제를 겪게 된다. 어떤 방문자에게는 8월 15일인 이벤트가 다른 방문자에게는 8월 14일 또는 8월 16일 일 수 있기 때문이다.

반대로 서버가 사용하는 UTC를 기준으로 하루를 나누면 기준은 통일되지만, 사이트 운영자가 생각하는 하루와 맞지 않을 수 있다. 예를 들어, 뉴욕에 있는 운영자에게 8월 15일의 데이터는 뉴욕 시간 기준 8월15일 00:00 ~ 23:59 까지의 데이터여야 한다.

즉, 하나의 사이트에는 하나의 보고 기준이 필요하다고 판단했다.

분석 데이터가 발생한 날짜는 단순히 이벤트가 발생한 지역의 날짜일 뿐만 아니라, 사이트 운영자가 데이터를 해석하는 기준이 되어야 한다고 봤다. 그래서 사이트를 등록할 때 해당 사이트의 타임존을 함께 저장하게 설계했다. 이 타임존으로 사이트의 일별 데이터를 나눌 수 있다.

예를 들어 사이트의 타임존이 America/New_York이라면:

데이터는 UTC로 저장하고, 화면에서 타임존으로 변환한다.

이벤트 자체는 특정 지역의 날짜가 아니라 하나의 시점이다. 따라서 서버에는 이벤트 발생 시각을 UTC 기준으로 전송하고 저장한다. (UTC는 전 세계에서 공유할 수 있는 일관된 기준) 대시보드에서 저장된 UTC 시각을 사이트의 타임존으로 변환한 뒤, 일별·시간별 데이터로 집계한다.

이벤트 발생
  → UTC 시각으로 전송·저장
  → 대시보드 조회 요청
  → 사이트 타임존으로 변환
  → 사이트 기준 날짜와 시간대로 집계
  → 대시보드에 표시

예를 들어:

사이트 타임존: 뉴욕
방문자의 타임존: 서울
방문자의 사이트 접속 날짜: 8월 15일

이때 방문자는 8월 15일에 접속했지만 뉴욕과 서울은 타임존이 다르기 때문에, 해당 이벤트가 발생했을 때 뉴욕은 8월 14일이다. 그래서 데이터도 8월 14일로 집계하여 표시한다. 이는 사이트 등록일 관점에서도 유용하게 사용된다.

예를 들어, 뉴욕 기준 8월 14일에 사이트를 등록했

결국, 사이트 타임존을 활용해서 전 세계에서 발생하는 이벤트를 하나의 사이트 기준으로 일관되게 묶고, 운영자가 자신의 시간대에 맞는 데이터를 해석할 수 있게 된다.