タイムラインが報告書の半分だ

한 줄 요약

타임라인은 사건의 나열이 아니라 각 구간이 무엇을 뜻하는지를 드러내는 도구이고, 그 구간들이 곧 다음번에 줄여야 할 시간이다.

왜 이게 필요했나

장애 보고서에서 고객이 가장 먼저 읽는 것은 원인 분석이 아니라 타임라인입니다. 이유가 있습니다. 타임라인은 "우리가 얼마나 오래 몰랐는가" 와 "알고 나서 얼마나 빨리 움직였는가" 를 동시에 보여 주기 때문입니다.

그리고 이 두 숫자가 다음 분기의 개선 과제를 결정합니다.

어떻게 동작하나

쓸 만한 타임라인에는 다섯 개의 시각이 있습니다.

변경 시각 — 무언가 바뀐 때. 배포, 설정 변경, 트래픽 급증. 영향 시작 시각 — 사용자가 실제로 실패를 겪기 시작한 때. 인지 시각 — 우리가 알게 된 때. 알람이 울렸거나 고객이 신고한 때. 조치 시각 — 완화 조치가 들어간 때. 복구 확인 시각 — 같은 잣대로 다시 재서 정상을 확인한 때.

그리고 이 다섯 개 사이의 네 구간이 각각 이름을 가집니다.

변경 → 영향: 잠복 구간. 짧으면 즉시 드러난 것이고, 길면 특정 조건이 쌓여야 터지는 유형입니다. 후자가 훨씬 무섭습니다.

영향 → 인지: 탐지 지연. 이 값이 크면 문제는 시스템이 아니라 관측입니다. 고객이 먼저 알려 주는 상황이 반복되면, 원인을 아무리 잘 고쳐도 신뢰는 회복되지 않습니다.

인지 → 조치: 대응 지연. 런북이 있으면 짧고 없으면 깁니다.

조치 → 복구 확인: 검증 구간. 이 구간이 없는 보고서는 "고쳤다고 생각한다" 까지만 말한 것입니다.

현장에서 만나는 모습

여기서 자주 나오는 판단 하나를 짚어 둡니다. 영향 지속 시간을 어디부터 어디까지로 세느냐입니다.

변경 시각부터 세면 실제보다 길어지고, 조치 시각까지만 세면 실제보다 짧아집니다. 사용자 관점에서 정직한 계산은 영향 시작부터 복구 확인까지 입니다. 사용자는 배포가 언제였는지 모르고, 롤백 명령이 들어간 순간이 아니라 실제로 정상이 된 순간에 영향에서 벗어납니다.

그리고 타임라인을 쓸 때 지켜야 할 규칙이 하나 더 있습니다. 사람 이름을 쓰지 않습니다. "김 아무개가 03:19 에 배포" 가 아니라 "03:19 payment 2.7.0 배포" 입니다.

이것은 도덕이 아니라 계산입니다. 고객사 보고서에 특정 담당자가 지목되면 다음 장애에서 그 사람은 정보를 숨깁니다. 그러면 다음번 탐지 지연이 늘어납니다. 비난 없는 보고서는 다음 진단의 속도를 사는 투자입니다.

시각을 맞추는 것이 절반이다

여러 출처의 로그를 한 줄에 세울 때 가장 먼저 걸리는 것이 시간대와 정밀도입니다.

출처	흔한 형식	함정
애플리케이션 로그	2026-09-06 12:04:31	시간대가 없다 — 서버 로컬인지 UTC 인지 모른다
쿠버네티스 이벤트	2026-09-06T12:04:31Z	UTC 고정. 앱 로그와 9시간 차이
클라우드 콘솔	브라우저 로컬 시간	보는 사람마다 다르게 보인다
알람	발생 시각이 아니라 평가 시각	실제보다 1~5분 늦다

전부 UTC 로 바꿔 적고, 문서 맨 위에 그렇게 썼다고 밝힙니다. 그리고 알람은 "탐지 시각" 이지 "발생 시각" 이 아니라는 점을 표시합니다. 이 구분을 안 하면 "경보가 늦었다" 와 "장애가 늦게 시작했다" 를 섞어 버립니다.

정밀도도 맞춥니다. 초 단위 로그와 밀리초 단위 로그를 같은 줄에 세울 때는 초로 내림합니다. 없는 정밀도를 있는 것처럼 쓰면 인과가 뒤집혀 보입니다.

무엇을 인과로 볼 것인가

시간순으로 세우면 선후 관계 는 보이지만 인과 는 보이지 않습니다. 세 가지를 확인해야 인과라고 말할 수 있습니다.

1. 시간 정합 — 원인이 결과보다 먼저인가. 전파 지연을 감안해도 순서가 맞는가.
2. 범위 정합 — 원인의 영향 범위와 증상의 범위가 같은가. 파드 하나만 바뀌었는데 전체가 죽었다면 다른 원인이 있습니다.
3. 되돌림 검증 — 원인을 되돌렸을 때 증상이 사라졌는가. 이것이 가장 강한 증거입니다.

셋 중 하나라도 안 맞으면 "관련 있어 보이는 것" 으로 적고, 확정하지 않습니다. 타임라인 문서에 추정과 확인을 구분해 표시 하는 것이 신뢰를 만듭니다.

| 시각(UTC) | 사건 | 출처 | 확인 |
|---|---|---|---|
| 03:19:02 | payment 2.7.0 배포 시작 | Argo CD | 확인 |
| 03:19:40 | payment 파드 5xx 시작 | 앱 로그 | 확인 |
| 03:23:11 | 결제 실패율 경보 | Alertmanager | 확인(평가 시각) |
| 03:24 경 | 고객 문의 유입 | 지원 티켓 | 추정(티켓 시각은 접수 시각) |
| 03:31:05 | 2.6.4 로 롤백 | Argo CD | 확인 |
| 03:31:52 | 5xx 소멸 | 앱 로그 | 확인 — 되돌림으로 인과 성립 |

다음 실습에서 할 것

배포 이력, 애플리케이션 로그, 알람 이력에서 다섯 개의 시각을 각각 뽑아내고, 시간순으로 세운 타임라인 문서를 만들고, 사용자 관점의 영향 지속 시간을 계산합니다.