세 호스트가 저마다 다른 시계로 로그를 찍고 있었다

목표

세 호스트가 서로 다른 시계로 찍은 로그에서, 오프셋이 없거나 뜻이 다른 표기를 가려내고, 기준 사건으로 호스트별 지역 오프셋과 시계 오차를 갈라 추정하고, 모든 줄을 믿을 수 있는 UTC 로 다시 써서 뒤집힌 인과 순서를 바로 세웁니다.

왜 중요한가

장애 조사에서 제일 먼저 정하는 것은 "무엇이 먼저 일어났는가" 입니다. 그 순서의 근거가 로그의 시각인데, 그 시각은 사실이 아니라 주장입니다. 오프셋이 없으면 어느 지역의 시계인지 밖에서 알 수 없고, -00:00 은 Z 와 뜻이 다르고, 오프셋이 정확해도 호스트의 시계가 몇 초 앞서 있으면 원인이 결과보다 뒤에 기록됩니다. 시각을 믿을 수 있게 만드는 일은 분석의 준비가 아니라 분석 자체입니다.

단계

1. /root/clock/gen_clock.py 를 만들어 실행해 /root/clock/raw/ 아래 app-seoul.log · db-frankfurt.log · edge-newyork.log 를 만드세요.
2. /root/clock/stamps.json — 파일마다 시각 표기가 어떻게 다른지, 지금 당장 UTC 로 바꿀 수 있는 줄이 몇 줄인지 적으세요.
3. /root/clock/dst_probe.json — 서머타임이 있는 지역의 지역시각이 사라지거나 두 번 오는 것을 zoneinfo 로 실측하세요.
4. /root/clock/anchors.json — 세 파일 모두에 자국을 남긴 점검 신호를 찾으세요.
5. /root/clock/skew.json — 기준 사건으로 호스트별 지역 오프셋과 시계 오차를 갈라 추정하세요.
6. /root/clock/fixed.ndjson — 모든 줄을 보정한 UTC 시각으로 다시 쓰고 시간순으로 세우세요.
7. /root/clock/causality.json — 보정 전에 원인이 결과보다 뒤에 찍혀 있던 요청을 세고, 보정 뒤와 견주세요.
8. /root/clock/clock_report.md — 무엇을 어떤 근거로 보정했는지 보고서로 남기세요.

참고

• 보정한 ts 는 모두 2026-03-08T06:05:00.200Z 모양으로 적습니다 — 날짜와 시각 사이에 대문자 T, 밀리초 세 자리, 끝에 대문자 Z.
• 줄의 시각을 읽는 규칙은 하나로 통일합니다. 오프셋이 붙어 있으면 그대로 읽고, 없으면 일단 UTC 로 읽습니다. 그 가정이 맞는지는 기준 사건이 판정합니다.
• 파이썬의 strptime 은 %z 로 -05:00 과 -00:00 을 모두 읽습니다. zoneinfo.ZoneInfo 와 datetime 의 fold 로 서머타임 구간을 다룹니다.
• 지역 오프셋은 15분의 배수입니다. 기준과의 차이를 가장 가까운 15분으로 접으면 지역 오프셋이 나오고, 남는 초가 그 호스트의 시계 오차입니다.
• 흔한 실수: -00:00 을 Z 와 같은 뜻으로 읽기, 오프셋 없는 줄을 UTC 로 둔 채 정렬하기, 남는 몇 초를 잡음으로 보고 버리기, 서머타임 전환일에 오프셋을 한 가지로 고정하기.
• 이 실습의 산출물은 전부 /root/clock/ 아래에 모읍니다. 세션이 끝나면 사라지므로 중요한 것은 화면에 남겨 두세요.

단계 8개

1. 세 호스트의 로그를 재현하기
2. 어느 줄이 지금 당장 UTC 로 바뀌는지 세기
3. 사라지는 시각과 두 번 오는 시각을 실측하기
4. 세 파일에 함께 찍힌 기준 사건 찾기
5. 지역 오프셋과 시계 오차를 갈라 추정하기
6. 모든 줄을 믿을 수 있는 시각으로 다시 쓰기
7. 원인이 결과보다 뒤에 찍힌 요청 세기
8. 무엇을 어떤 근거로 고쳤는지 남기기