아날로그식 장애 스토리 시계 캐비닛: 장애가 실제로 어떻게 전개되는지 보여주는 ‘시간의 벽’ 만들기

아날로그 장애 스토리 시계 캐비닛

장애가 실제로 어떻게 전개되는지 보기 위한 ‘시간의 벽’ 만들기

MTTR 대시보드만 보고 있다면, 사실상 눈을 가린 채 비행하는 것이다.

MTTR(Mean Time To Resolution, 평균 복구 시간)은 거의 모든 장애 리포트와 SRE 슬라이드에 등장한다. 하지만 이 수치는 그 자체로 드러내는 것보다 숨기는 게 더 많다. 복잡하고 풍부한 이야기를 단 하나의 숫자로 납작하게 만들어 버린다. 장애는 스프레드시트 속이 아니라, 시간 속에서 존재한다.

이제 시계로 가득 찬 벽을 떠올려 보자.

각 시계는 하나의 장애를 나타내고, 그 바늘은 탐지(detection), 할당(assignment), 참여(engagement), 확인(acknowledgment), 수정(fix), 해결(resolution)의 단계를 따라 움직인다. 이 시계들이 나란히 놓이면, 팀·시스템·툴 전반에서 장애가 실제로 어떻게 전개되는지를 보여주는 ‘시간의 벽’이라는 아날로그식 시각화가 된다.

이것이 바로 **Incident Story Cabinet of Clocks(장애 스토리 시계 캐비닛)**의 아이디어다. 타임라인 기반의 아날로그 같은 뷰를 활용해, 장애 시간이 실제로 어디에서 소비되는지, 그리고 운영 프로세스가 어디서 조용히 실패하고 있는지 드러내는 것이다.

왜 하나의 MTTR 숫자보다 ‘시간의 벽’이 더 강력한가

MTTR 같은 지표는 우리에게 통제감을 준다. 깔끔하다. OKR이나 분기 리뷰에 넣기에도 좋다. 하지만 이런 지표는 요약일 뿐, 설명이 아니다.

생각해 보자.

두 장애 모두 MTTR이 45분일 수 있다.
첫 번째 장애에서는 엔지니어가 즉시 대응했지만, 수정 자체가 복잡했다.
두 번째 장애에서는 수정은 5분이면 끝났지만, 누군가가 이 장애를 잡아들기까지 40분이 걸렸다.

대시보드 위에선 이 두 장애가 똑같아 보인다. 하지만 ‘시간의 벽’에서는 완전히 다른 모습이다.

시각적인 타임라인은 이런 차이를 단번에 드러낸다.

아무 일도 벌어지지 않는 긴 평평한 구간
짧은 시간에 액션이 몰려 있는 조밀한 활동 구간
관련된 다른 장애나 알람과 겹쳐지는 시간대

이처럼 장애를 공유된 시간 축 위에 놓아 보면, 장애를 숫자로만 다루는 것이 아니라 시간 속에서 전개되는 스토리로 다루게 된다.

테이블별 타임라인: 장애가 실제로 어떻게 진행되는지 확대해서 보기

대부분의 조직에는 이미 구조화된 데이터가 많다. Incident 테이블, Alert 테이블, Change 테이블, 티켓 큐 등등. 문제는 데이터가 없어서가 아니라, 일관된 서사가 없다는 것이다.

이 서사를 되살리는 강력한 방법이 바로 데이터 테이블별 전용 타임라인 뷰다. 예를 들어:

Incident 타임라인: 최초 탐지 → 할당 → 참여 → 확인 → 완화(mitigation) → 해결(resolution)
Alert 타임라인: 최초 알람 → 중복 제거(deduplication) → 억제(suppression) → 상관관계 분석(correlation) → 에스컬레이션(escalation)
Change 타임라인: 변경 요청 → 승인 → 배포 시작 → 배포 종료 → 롤백(있다면)

각 테이블마다 시간 순으로 쌓인 이벤트 시퀀스를 부여하면, 다음이 가능해진다.

특정 장애 유형(예: SEV-1 vs SEV-3)에만 집중해 라이프사이클 차이를 비교
특정 서비스나 팀이 유사한 장애에서 어떻게 다르게 동작하는지 비교
반복적으로 나타나는 프로세스 지연(예: 핸드오프, 승인 대기)을 식별

정적인 레코드 목록이 아니라, 운영 현장이 살아 움직이는 스토리보드를 얻게 되는 셈이다.

왜 MTTR만으로는 부족한가

MTTR(Mean Time to Resolution, 평균 복구 시간)은 보통 다음과 같이 정의된다.

장애가 시작된 시점부터 서비스가 복구될 때까지 걸린 평균 시간

유용한 지표임은 분명하지만, 이 안에는 서로 다른 여러 활동이 하나의 불투명한 시간 덩어리로 묶여 있다.

장애를 탐지하고 라우팅하는 데 걸린 시간
누군가 실제로 작업을 시작할 때까지의 시간
문제를 이해하고 확인(acknowledge) 하는 데 필요한 시간
실제로 수정·배포를 완료하는 데 걸린 시간

MTTR만 보면, 프로세스의 어느 부분이 느린지 알 수 없다. 탐지가 느린 것인지, 사람 참여(engagement)가 느린 것인지, 수정이 느린 것인지, 핸드오프가 꼬이는 것인지 전혀 분간할 수 없다.

그래서 더 세분화된 지표와 타임라인 뷰가 필요하다.

MTTE: 사람이 실제로 일을 시작하기까지 걸리는 시간 측정

**MTTE(Mean Time to Engage)**는 장애가 어떤 팀이나 사람에게 할당된 시점부터, 그들이 실제로 의미 있는 대응을 시작하는 시점까지의 지연을 측정하는 지표다.

한마디로 이런 질문에 답하는 값이다.

“이 장애가 누군가의 업무 범위 안에 들어온 뒤, 실제로 일을 시작할 때까지 얼마나 걸리는가?”

이게 중요한 이유:

인력·리소스 문제를 드러낸다: 사람이 과부하 상태이거나, 멀티태스킹·잦은 컨텍스트 스위칭을 하고 있을 수 있다.
온콜(온콜 체계) 문제를 노출한다: 정말로 연락이 닿지 않거나, 알람 우선순위가 제대로 서 있지 않을 수 있다.
조직적 마찰을 드러낸다: 오너십이 불분명하거나, 에스컬레이션 경로와 승인 절차가 불명확할 수 있다.

아날로그식 장애 시계에서 MTTE는 다음 두 시점 사이의 구간이다.

"Incident assigned"(장애가 팀/담당자에게 할당됨)
"First meaningful action taken"(처음으로 의미 있는 액션이 수행됨)

‘시간의 벽’ 위에서 보면, 많은 지연이 시스템이 아니라 사람이 시작하기까지의 시간에 쌓여 있다는 것을 한눈에 확인할 수 있다.

MTTR 분해: Engage, Acknowledge, Fix

MTTR을 진짜 유용하게 만들려면, 이를 눈에 보이는 단계별 구성 요소로 분해해 각 단계를 장애 시계 위의 구간으로 매핑해야 한다.

Time to engage – 누군가 장애 작업을 시작할 때까지의 시간(MTTE에 해당)
Time to acknowledge – 담당자/팀이 문제 범위를 이해하고, 책임지고 처리 중임을 명확히 하는 시점까지의 시간
Time to fix – 근본 원인이 완화되거나 해결되기까지의 시간

개념적으로는 전체 복구 시간을 다음과 같은 합으로 볼 수 있다.

MTTR ≈ MTTE (engage) + MTTA (acknowledge) + MTTF (fix)

이렇게 MTTR을 쪼개면 다음이 가능해진다.

병목 구간을 분리 – 우리가 느린 부분이 참여(engage)인지, 이해/확인(acknowledge)인지, 실제 수정(fix)인지 구체적으로 파악
정밀한 개선 액션 – 교육·런북·알람 튜닝·자동화·인력 조정 등 무엇을 손봐야 할지 명확해짐
명확한 커뮤니케이션 – “MTTR이 나쁘다”가 아니라, “참여 시간은 괜찮은데, 문제를 이해·확인하는 데 시간이 너무 오래 걸린다”와 같이 설명 가능

장애 스토리 시계 캐비닛에서는 이 각 단계가 하나의 숫자가 아니라, 서로 다른 색이나 구간으로 표시된 시각적으로 구분되는 세그먼트가 된다.

MTTF 계산: Acknowledge와 Fix 사이에서 무슨 일이 벌어지는가

많은 운영 문맥에서 MTTF는 "Mean Time to Failure"(평균 고장 시간)을 의미한다. 여기서는 장애 라이프사이클 안에서의 Mean Time to Fix(평균 수정 소요 시간) 으로 보는 편이 더 유용하다.

다음 값이 있다고 하자.

MTTR – Mean Time to Resolution (평균 복구 시간)
MTTE – Mean Time to Engage (평균 참여 시작 시간)
MTTA – Mean Time to Acknowledge (평균 확인 시간)

그렇다면 수정 시간은 대략 다음과 같이 표현할 수 있다.

MTTF ≈ MTTR – MTTE – MTTA

이 관점은 중요한 역할을 한다.

참여(engage), 확인(acknowledge), 수정(fix) 사이의 단계를 의식적으로 분리해 볼 수 있게 해 준다.
지연이 코드 수정이나 배포뿐 아니라 프로세스 어디에나 숨어 있을 수 있음을 강조한다.

‘시간의 벽’에서 MTTF는 실제 엔지니어링이 이루어지는 구간이다. 진단하고, 가설을 세우고, 테스트하고, 변경을 롤아웃하는 시간이다. MTTE와 MTTA는 짧은데 MTTF가 길다면, 다음과 같은 개선이 필요할 가능성이 크다.

더 나은 런북·플레이북
향상된 관측성(observability)과 로깅
더 탄탄한 아키텍처와 안전한 배포 패턴

반대로, MTTF는 짧은데 MTTE나 MTTA가 시계 대부분을 차지한다면, 문제는 기술이라기보다 프로세스·커뮤니케이션의 문제일 수 있다.

아날로그 타임라인 + Uptime 도구: 장애를 더 풍부하게 이해하기

대부분의 팀은 이미 Uptime 모니터링, 알람 도구, 대시보드를 사용하고 있다. 이들은 필수적이지만, 보통은 진실의 일부만 보여준다.

Uptime 그래프: "서비스가 언제 살아 있었고, 언제 죽어 있었는가?"
알람 대시보드: "분당 알람 수는 얼마인가? 어떤 알람이 터졌는가?"
티켓 시스템: "장애 티켓이 몇 건이고, 누가 담당인가?"

여기서 빠져 있는 건, 이 조각들이 시간 축에서 서로 어떻게 맞물리는지다.

기존 도구에 **아날로그식 장애 ‘시간의 벽’**을 더하면:

모니터링 데이터, 알람, 티켓을 하나의 공유된 타임라인 위에 겹쳐서(overlay) 볼 수 있다.
Uptime 그래프의 스파이크가 장애 시계상의 늦은 참여(engage) 구간과 정확히 언제 맞물리는지 확인할 수 있다.
하나의 배포가 연쇄적인 알람과 후속 장애를 어떻게 촉발하는지 연결된 흐름으로 추적할 수 있다.

이로 인해 다음과 같은, 보다 직관적인 이해가 가능해진다.

장애가 대부분의 시간을 어디에서 보내는지 (대기 큐, 사람 지연, 복잡한 수정 작업 등)
여러 시스템과 장애가 하나의 outage 시나리오에서 어떻게 서로 얽히는지
진짜로 고통을 줄이는 데 도움이 되는 개선 지점이 어디인지 (툴링, 자동화, 인력, 아키텍처 등)

나만의 장애 스토리 시계 캐비닛 만들기

이걸 위해 새로운 제품 카테고리가 꼭 필요한 건 아니다. 이미 가진 도구들로도 어느 정도는 구현할 수 있다.

단계를 정의한다
- 탐지(detection), 할당(assignment), 참여(engagement), 확인(acknowledgment), 완화(mitigation), 해결(resolution) 등
- 신뢰할 수 있게 수집 가능한 타임스탬프가 무엇인지 먼저 정한다.
워크플로우를 계측(instrument)한다
- 티켓/Incident 시스템이 이러한 상태 전이를 명시적으로 기록하도록 설정한다.
- 대응자가 Incident 상태를 업데이트하는 것을 표준 업무로 정착시킨다.
테이블별 타임라인을 만든다
- Incidents, Alerts, Changes에 대해 단순 테이블 뷰 대신 시간 기반 시각화를 생성한다.
- 이들을 공통 시간 축에 맞춰 놓아, 서로 겹치는 구간을 볼 수 있게 한다.
MTTE, MTTA, MTTF, 분해된 MTTR을 계산한다
- 수집한 타임스탬프를 이용해 MTTR뿐 아니라 각 구성 요소 지표를 계산한다.
장애를 숫자가 아니라 ‘스토리’로 리뷰한다
- Post-incident 리뷰에서, 시계식 타임라인을 따라가며 되짚어 본다.
- “시간이 어디에 고였는가? 무엇이 예방 가능했는가? 단순한 혼선이었나, 본질적인 복잡성이었나?”를 질문한다.

시간이 지나면 이 시계 캐비닛은 조직의 신뢰성·운영 문화를 위한 공유된 시각 언어가 된다.

결론: 숫자에서 내러티브로

장애는 단지 시스템의 실패가 아니다. 조직이 스트레스 상황에서 어떻게 생각하고, 행동하고, 소통하는지를 그대로 드러내는 거울이다.

하나의 MTTR 숫자로는 그 이야기를 들을 수 없다.

아날로그 장애 스토리 캐비닛, 즉 개별 Incident 시계와 테이블별 타임라인으로 구성된 ‘시간의 벽’은 그 이야기를 보여준다. 이 벽은 다음을 가능하게 한다.

지연과 병목을 눈에 보이게 드러낸다.
MTTR 같은 추상적인 지표를 분해 가능한, 실행 가능한 인사이트로 바꾼다.
사람의 행동, 프로세스 설계, 시스템 동작을 하나의 공유된 캔버스 위에 연결한다.

장애가 실제로 어떻게 전개되는지, 그리고 그 시간을 어떻게 줄일 수 있는지 진심으로 알고 싶다면, 시작은 의외로 단순하다.

숫자만 보지 말고, 시간을 보라.