프로덕션 장애 상황에서 실제 버그와는 전혀 상관없는, 특정한 반복적 고충이 있습니다. 그것은 바로 서로 다른 시간대 (Timezone)로 로깅하는 서비스들 사이에서 사건이 어떤 순서로 발생했는지 재구성하는 일입니다. 더 최악인 경우는 로그 라인 자체에 표시도 없이 일 년에 두 번씩 바뀌는 현지 시간 (Local time)으로 기록되는 경우입니다.

현지 시간 로그의 문제점

2026-03-08 02:30:15 - job started라고 읽히는 로그 라인은 다른 시간대에서 실행되는 다른 서비스의 로그 라인과 상관 관계를 파악해야 하거나, 혹은 과거 어느 시점에 시간대 설정이 조용히 변경된 서버에서 생성된 로그와 대조해야 하기 전까지는 정밀해 보입니다. 모든 타임스탬프 (Timestamp)에 명시적인 UTC 오프셋 (UTC offset)이 포함되어 있지 않다면, 여러분은 특정 서버가 어떤 시간대로 로그를 남기는지 기억하고 있는 누군가의 조직적 지식에 의존해야 합니다. 이는 팀 교체나 서비스 마이그레이션 과정에서 살아남지 못하는 바로 그 종류의 부족 지식 (Tribal knowledge)입니다.

특히 일광 절약 시간제 (DST, Daylight Saving Time) 전환 시기에는 이것이 매우 위험해집니다. 가을에 시간이 뒤로 밀리는 날의 현지 시간 로그 타임스탬프 02:30은 진정으로 모호합니다. 이는 한 시간 차이가 나는 두 개의 서로 다른 시점 중 어느 것이든 될 수 있으며, 아무런 표시가 없는 순수 현지 시간 로그 라인은 실제로 어떤 일이 일어났는지 알려주지 않습니다. 장애 발생 시 여러 시스템에 걸쳐 정확한 사건 순서를 파악하려고 할 때, 특히 장애가 전환 시점 자체에 걸쳐 있다면 이러한 모호함은 여러분을 완전히 잘못된 방향으로 인도할 수 있습니다.

UTC는 모호함의 범주 자체를 제거합니다

UTC 타임스탬프는 DST 전환이 없고 모호한 시간도 없습니다. 즉, UTC 로그 타임스탬프는 읽는 사람이나 시스템이 어떤 시간대에 있든 상관없이 항상 정확히 하나의 시점을 모호함 없이 가리킨다는 것을 의미합니다. 이것이 모든 곳에서 UTC로 로깅해야 한다는 논거의 핵심입니다. UTC가 어떤 추상적인 의미에서 더 "정확"하기 때문이 아니라, 여러분의 스택에 있는 모든 시스템이 추가적인 문맥 없이도 합의할 수 있는 유일한 시간대이며, 이를 통해 장애 발생 시 서비스 간 상관 관계 파악 (Cross-service correlation)을 획기적으로 빠르게 만들어 주기 때문입니다.

실제적인 패턴은 간단합니다. 모든 타임스탬프 (Timestamp)를 UTC로 저장 및 전송하고, 사람이 실제로 읽는 UI나 보고서의 가장 마지막 단계에서만 로컬 시간 (Local time)으로 변환하는 것입니다. 그보다 앞선 단계에서 발생하는 그 어떤 변환, 특히 데이터가 저장되거나 로깅되기 전에 발생하는 변환은 UTC가 제거하고자 했던 바로 그 모호함을 다시 불러옵니다.

팀들이 실무에서 실수하는 부분

가장 흔한 실수는 악의적이거나 판단 착오에 의한 것도 아닌, 바로 일관성 (Inconsistency)의 부재입니다. 어떤 서비스는 누군가 주의 깊게 설정했기 때문에 UTC로 로깅합니다. 다른 서비스는 아무도 명시적으로 설정하지 않았기 때문에 서버의 기본 OS 시간대 (Timezone)를 따라 로깅합니다. 세 번째 서비스는 가독성을 위해 로깅 미들웨어 (Logging middleware) 어딘가에서 로컬 시간으로 변환하는데, 이 변환이 일어나고 있다는 사실을 아무도 인지하지 못합니다. 이 각각의 사례는 개별적으로 보면 틀려 보이지 않습니다. 하지만 세 서비스 모두에 걸쳐 발생하는 장애 상황에서 이들이 모이면, "언제 무엇이 일어났는지"에 대해 적극적으로 오해를 불러일으키는 그림을 만들어내며, 이러한 불일치를 디버깅하는 과정은 실제 장애 상황에서 당신에게 허락되지 않은 바로 그 시간을 소모하게 만듭니다.

이번 주에 실행해 볼 만한 구체적인 감사 (Audit)

독립적으로 로깅하는 스택 내의 서비스 중 아무거나 세 개를 골라 각 서비스의 로그 라인 샘플을 추출하십시오. 타임스탬프가 오프셋 (Offset)을 명시하고 있는지(UTC를 나타내는 Z 또는 명시적인 +00:00 / -05:00 스타일의 오프셋), 아니면 시간대 정보가 전혀 붙어 있지 않은 순수 로컬 타임스탬프인지 확인하십시오. 오프셋이 없는 순수 타임스탬프가 실제 위험 요소입니다. 왜냐하면 기본 서버의 시간대 설정이 변경되거나, 로그가 생성된 지역과 다른 지역에서 로그를 읽게 될 경우 사후에 이를 구분할 방법이 없기 때문입니다.

구조화된 로깅 (Structured logging)은 이를 지속적인 규율의 문제가 아닌, 단 한 번의 수정 사항으로 만듭니다

만약 로깅이 가공되지 않은 문자열 포맷팅 (raw string formatting) 대신 구조화된 로깅 (structured logging) 라이브러리를 통해 이루어진다면, 이는 개별 로그 호출마다 올바르게 수행해야 할 작업이 아니라 대개 라이브러리 수준에서의 단 한 줄의 설정 변경만으로 해결됩니다. 해당 계층에서 이를 수정하면 "모두가 UTC를 사용해야 함"을 "로깅 라이브러리는 UTC만 생성할 수 있음"으로 전환할 수 있으며, 이는 모든 신규 입사자와 모든 신규 서비스에 걸쳐 모든 사람이 이를 무기한으로 정확하게 기억해야 하는 팀 컨벤션 (team convention)보다 훨씬 더 의미 있게 지속 가능한 해결책이 됩니다.

structlog와 같은 라이브러리는 설정 시점에 UTC 타임스탬프 프로세서 (timestamp processor)를 한 번만 부착할 수 있게 함으로써 이를 명시적으로 처리하며, 따라서 하위의 모든 로그 호출은 자동으로 동일한 동작을 상속받습니다. 핵심은 특정 라이브러리가 반드시 필요하다는 것이 아니라, 결정을 공유된 설정 (shared configuration)으로 밀어 넣음으로써 개별 엔지니어가 작성하는 모든 로그 호출마다 올바르게 수행해야 하는 작업 목록에서 이를 제거하는 것입니다.

클록 스큐 (Clock skew)는 "정확한" 타임스탬프를 잘못된 그림으로 만든다

스택 내의 모든 서비스가 UTC로 올바르게 로깅하더라도, 기반 시스템 시계 (system clocks)가 서로 일치하지 않는다면 여전히 오해의 소지가 있는 이벤트 순서를 얻을 수 있습니다. 서버의 시계보다 4초 앞서 있는 클라이언트 머신의 시계는, 서버가 실제로 요청을 받은 시점보다 (정확하게도) 4초 앞선 UTC 타임스탬프를 생성할 것입니다. 두 타임스탬프 모두 틀린 것은 아닙니다. 단지 서로 어긋난 두 개의 서로 다른 물리적 시계를 기준으로 측정했을 뿐입니다.

이것은 장애 발생 시 인과관계 (causality)를 재구성할 때, 즉 한 머신의 이벤트 A가 다른 머신의 이벤트 B보다 먼저 발생했는지 여부를 결정해야 할 때 가장 중요합니다. 만약 두 머신의 시간이 단 몇 초라도 어긋나 있다면, 실제로 순차적인 한 쌍의 이벤트가 잘못된 순서로 발생한 것처럼 보이거나, 실제로는 겹치지 않았음에도 불구하고 겹쳐서 발생한 것처럼 보일 수 있습니다. 대부분의 운영 환경 (production environments)에서는 이러한 드리프트 (drift)를 작게 유지하기 위해 NTP 또는 이와 유사한 시간 동기화 (time-sync) 서비스를 실행하지만, 단순히 그렇다고 가정할 것이 아니라 모든 호스트에서 실제로 활성화되어 있고 정상적으로 작동하는지 확인하는 것이 가치가 있습니다. 동기화를 조용히 멈춘 호스트는 인지되지 않는 매일의 시간 동안 점점 더 많은 드리프트가 발생하기 때문입니다.

로그 집계 도구가 모호함을 조용히 다시 불러올 수 있습니다

소스에서 올바르게 저장된 UTC 타임스탬프라 할지라도, 로그 뷰어 (log viewer)에 도달하면 온콜 (on-call) 엔지니어를 혼란스럽게 만들 수 있습니다. 대부분의 집계 대시보드 (aggregation dashboards)는 기본적으로 타임스탬프를 표시할 때 뷰어의 로컬 브라우저 시간대 (timezone)로 변환하기 때문입니다. 책상에 앉아 로그를 살펴보는 한 개인에게는 합리적인 편의 기능이지만, 서로 다른 시간대에 있는 두 엔지니어가 동일한 장애를 바라보며 통화 중에 서로의 타임스탬프를 소리 내어 읽는 순간 이는 심각한 문제가 됩니다.

기저의 데이터는 모호하지 않으며, 오직 디스플레이 레이어 (display layer)만이 모호할 뿐입니다. 실질적인 해결책은 한 개 이상의 시간대에 있는 사람들이 참여하는 장애 상황에서는 뷰어를 명시적으로 UTC 표시 모드로 전환하는 것이며, 이 전환을 누군가 요청해야 기억해내는 것이 아니라 인시던트 대응 체크리스트 (incident response checklist)의 일부로 만드는 것입니다. 이는 비용이 들지 않으면서도, 장애 대응 도중에 발생하는 "잠깐, 우리가 지금 같은 이벤트를 말하고 있는 건가요?"라는 부류의 혼란을 완전히 제거해 줍니다.

이것이 방지할 수 있는 구체적인 장애 패턴

이러한 원칙이 방지할 수 있는 한 가지 구체적인 장애 유형은 두 마이크로서비스 (microservices) 간의 타임스탬프 (timestamps)를 비교할 때만 나타나는 레이스 컨디션 (race condition)입니다. 결제 서비스 (payment service)가 "결제 성공" 이벤트를 기록하고, 잠시 후 재고 서비스 (inventory service)가 결제 완료 후에만 발생해야 하는 "재고 예약" 이벤트를 기록한다고 가정해 봅시다. 만약 이 두 서비스가 서로 다른 시간대 (timezones)로 로깅하거나, 배포 (deploy) 중에 하나가 몰래 현지 시간 (local time)으로 드리프트 (drift)된다면, 사후에 장애를 검토하는 엔지니어는 실제 작업 순서를 잘못 읽을 수 있습니다. 이로 인해 레이스 컨디션이 실제로 존재함에도 불구하고 존재하지 않는다고 결론 내리거나, 시스템이 정상적으로 동작했음에도 불구하고 레이스 컨디션이 존재한다고 잘못 판단할 수 있습니다. UTC 타임스탬프 자체가 레이스 컨디션 그 자체를 해결해주지는 않지만, 나머지 조사 과정을 신뢰할 수 있을 만큼 충분히 빠르게 이벤트의 실제 순서를 확립할 수 있게 해줍니다.

이는 시스템이 반복적인 작업 (recurring jobs)을 실행하는 경우 알아두면 좋은 더 넓은 범위의 스케줄링 신뢰성 문제와 연결됩니다: 일광 절약 시간제 (daylight saving) 전환은 이와 관련이 있지만 별개의 클래스인 스케줄링 버그를 유발하며, 현지 벽시계 시간 (wall-clock time)을 기준으로 예약된 작업은 매년 두 번의 전환 날짜에 두 번 실행되거나 아예 실행되지 않을 수 있습니다. 여기서 설명한 '모든 곳에서 UTC 사용' 로깅 원칙이 해당 스케줄링 문제를 직접 해결하지는 않지만, 문제가 발생했을 때 진단 속도를 극적으로 높여줍니다. 실제 버그 위에 타임스탬프의 모호함과 싸울 필요가 없기 때문입니다.

관련 표준에 대해 더 자세히 알고 싶다면, 인터넷상의 날짜 및 시간에 대한 RFC 3339 명세에서 오늘날 대부분의 구조화된 로깅 라이브러리 (structured logging libraries)가 기본값으로 사용하는 명시적 오프셋 (explicit-offset) 타임스탬프 형식을 정의하고 있으며, Wikipedia의 ISO 8601 표준 개요를 통해 전체적인 그림을 보고 싶을 경우 이 모든 것의 기반이 되는 더 넓은 타임스탬프 형식 제품군을 확인할 수 있습니다.

137Foundry에서 UTC 우선 로깅 (UTC-first logging)은 우리가 첫날부터 모든 클라이언트 시스템에 구축하는 작고 덜 화려한 관례 중 하나입니다. 이는 처음에 올바르게 설정하는 비용은 저렴하지만, 이미 몇 년간 일관성 없는 로그가 축적된 후에 이를 사후 적용 (retrofit)하는 것은 진정으로 고통스럽기 때문입니다.