아날로그 장애 스토리 역 시계

당신의 장애가 실제로 얼마나 오래 갔는지 보여주는 벽걸이 다이얼 만들기

유럽의 클래식한 역에 들어가면, 제일 먼저 눈에 들어오는 건 큼직한 시계입니다. 선명하고 단순해서 절대 지나칠 수 없죠. 이제 상상해 봅시다. 그 시계가 현재 시각 대신, 지난 장애가 실제로 얼마 동안 이어졌는지, 그리고 지금 진행 중인 장애가 얼마나 계속되고 있는지 보여준다고 하면 어떨까요?

이게 바로 **아날로그 장애 스토리 역 시계(analog incident story railway station clock)**의 개념입니다. **서비스 복구 시간(Time-To-Restore Service, TTR)**을 눈에 보이고, 손에 잡히고, 약간은 불편하게 만들어 주는 커다란 물리적 벽걸이 다이얼이죠. (물론 좋은 의미의 불편함입니다.)

대시보드, 알림 시스템, 수많은 메트릭이 넘쳐나는 시대에, 왜 굳이 아날로그를 써야 할까요? 이유는 간단합니다. 시간을 어떻게 보여주느냐에 따라 사람들이 그것을 어떻게 인식하는지가 완전히 달라지기 때문입니다. 그리고 이 인식의 문제는 많은 SRE 실무에서 빠져 있는 퍼즐 한 조각이기도 합니다.

왜 Time-To-Restore(TTR)만의 시계가 필요할까

Site Reliability Engineering(SRE)에서 대부분의 의사결정을 이끄는 핵심 지표는 몇 개 되지 않습니다. 그중에서도 Time-To-Restore Service(TTR)는 가장 중요한 축에 속합니다.

TTR = 장애가 시작된 시점부터 서비스가 복구될 때까지 걸리는 시간

우리는 장애 건수가 적고, 업타임이 좋으면 기뻐합니다. 하지만 현실은 모든 시스템은 언젠가 반드시 실패한다는 사실에서 출발합니다. 뛰어난 팀을 구분 짓는 건, 실패의 부재가 아니라 얼마나 빠르고 안정적으로 서비스를 복구하느냐입니다.

TTR이 짧을수록 다음과 같은 효과가 있습니다.

• 실질적인 신뢰성 향상 – 사용자는 장애의 원인보다 얼마나 오래 영향을 받았는지를 더 잘 기억합니다.
• 더 탄탄한 CI/CD – 빠르고 신뢰할 수 있는 롤백·복구 능력이 있어야, 잦은 배포도 안전해지고, 위험한 ‘감’에 의존하지 않게 됩니다.
• 배포에 대한 자신감 상승 – 팀이 자신의 복구 역량을 신뢰할수록, 새로운 변경을 내보내는 데도 훨씬 과감해집니다.

Prometheus, Opsgenie 같은 현대적인 관측·알림 도구는 보통 TTR을 40% 이상 줄여줍니다. 더 빠른 신호, 더 나은 트라이애지, 더 명확한 알림이 큰 도움이 되죠. 하지만 시간이 지나면, TTR도 대시보드 속 수많은 숫자 중 하나로 희미해지기 쉽습니다.

그래서 아날로그 시계가 필요합니다.

일부러 장애를 ‘몸으로 불편하게’ 느끼게 만들기

신뢰성 지표는 무언가 크게 터지기 전까지는 눈에 잘 띄지 않습니다. TTR 역시 보통은 이런 곳에만 나타납니다.

• 매일 들여다보는 사람이 거의 없는 대시보드
• 대충 훑어보기 쉬운 사후 사고 보고서
• 건수에 더 집중하는 분기별 리뷰 자료

여기서 **시각적·물리적 아티팩트(artifact)**가 판을 바꿉니다. 예를 들어, 이런 큰 벽걸이 시계를 생각해 봅시다.

• 장애가 선언되는 순간 바로 돌아가기 시작하고
• 서비스가 복구되는 순간 멈추며
• 다음 장애가 일어나기 전까지는 그 마지막 시간을 그대로 유지하는 시계

이런 아날로그 시계는 추상적인 숫자였던 TTR을, 그 앞을 지나는 누구에게나 직접 느껴지는 무언가로 바꿔 줍니다. 장애가 진행 중일 때 초침이 계속 움직이는 모습은, 아주 조용하지만 분명한 메시지를 줍니다. **“지금 이 순간에도 시간은 계속 흘러가고 있다”**는 사실 말이죠.

이건 ‘망신 주기용 벽면’ 같은 처벌 도구가 아닙니다. 오히려 **현실을 보여주는 기압계(barometer)**에 가깝습니다. 이 시계는 다음과 같은 역할을 합니다.

• 누구를 탓하지 않고도 인식을 끌어올리고
• 장애가 끝난 뒤에도 장애 지속 시간에 대한 감각을 계속 유지하게 하고
• 팀이 장애의 진짜 비용을 몸으로 익히도록 돕습니다.

보고서 속의 “4시간 22분”이라는 숫자와, 복도에 걸린 시침·분침이 “4시간 22분”에 멈춰 있는 모양새는 전혀 다른 심리적 효과를 줍니다. 하나는 **값(value)**에 불과하지만, 다른 하나는 **이야기(story)**가 됩니다.

인식이 장애의 현실을 어떻게 바꿀까

순수하게 기술적인 관점에서 보면, 장애는 단지 일련의 타임스탬프일 뿐입니다. 시작, 탐지, 에스컬레이션, 완화, 복구.

하지만 인간은 장애를 그렇게 경험하지 않습니다.

사람들은 장애를 **‘인식 프레임(perception framework)’**을 통해 해석합니다. 즉, 다음을 섞어서 받아들입니다.

• 원시 데이터: 타임스탬프, 로그, TTR, 알림 개수
• 맥락(Context): 어떤 사용자가 영향을 받았는지, 어느 팀 소유 서비스인지, 오후 3시에 터졌는지 새벽 3시에 터졌는지
• 사회적 범주(Social categories): 고심각도 vs 저심각도, “우리 팀의 잘못” vs “인프라 문제”, 내부 영향 vs 외부 고객 영향

이때 **‘시간이 어떻게 표현되느냐’**가 인식에 큰 영향을 줍니다.

• 스프레드시트 속 숫자: 그냥 데이터일 뿐
• 대시보드의 붉게 강조된 셀: 조금 불길한 숫자
• 복도에 걸린 큰 아날로그 시계가 6시간 지점 근처에 멈춰 있음: 감정적으로 와 닿는 현실

이 감정적 생생함이 중요합니다. 팀이 **“이번 장애는 정말 너무 오래 갔다”**는 걸 느끼게 되면, 보통 이런 행동으로 이어집니다.

• 플레이북, 자동화, 롤백 경로를 더 적극적으로 개선하고
• 또 하나의 기능 개발보다 장애 감소 작업을 더 우선순위에 두고
• 더 좋은 관측성과 알림 체계를 요구하게 됩니다. 왜냐하면, 그 ‘고통’이 눈앞에 보이기 때문입니다.

당신만의 ‘장애 역 시계’ 설계하기

거창한 산업용 커스텀 하드웨어가 필요하지는 않습니다. 필요한 건 딱 두 가지입니다.

1. 장애 라이프사이클과 시계 상태를 어떻게 매핑할지에 대한 명확한 정의
2. 벽에 걸어둘 수 있는 크고 눈에 잘 띄는 아날로그 디스플레이

1. 시계가 정확히 무엇을 표시할지 결정하기

단순하면서도 의견이 분명한 디자인을 예로 들어 보겠습니다.

• 장애 중일 때: 시계가 돌아가며, 현재까지의 장애 지속 시간을 보여줍니다.
• 복구 후에는: 최종 장애 시간이 멈춘 상태로 고정되고, 다음 장애가 발생할 때까지 그대로 유지됩니다.
• 장애와 장애 사이에는: 마지막 장애가 얼마나 길었는지를 보여주는 고정된 기억 장치 역할을 합니다.

여기에 약간의 요소를 더할 수 있습니다.

• 시계 옆에 **“ACTIVE INCIDENT(장애 진행 중)”**라고 쓰인 작은 LED나 표지판을 달고, 장애 중에는 불이 켜지게 하기
• 내부적으로 정의한 TTR 기준선을 넘을 때마다, 예를 들어 백라이트 색을 초록 → 노랑 → 빨강으로 바꾸기

가장 중요한 원칙은 **“복잡하게 만들지 말 것”**입니다. 이건 또 하나의 대시보드가 아니라, 신호가 매우 분명한 아티팩트여야 합니다.

2. 실제 장애 데이터를 시계로 연결하기

벽에 걸린 아날로그 시계는 최종 시각화일 뿐입니다. 진짜 ‘지능’은 여러분이 이미 쓰고 있는 장애 관리 도구들에서 나옵니다.

대부분의 팀은 이미 이런 도구를 사용하고 있을 것입니다.

• 알림·장애 관리 도구: Opsgenie, PagerDuty, VictorOps 등
• 모니터링·관측 도구: Prometheus, Grafana, OpenTelemetry 등

보통은 웹훅(Webhook)으로 쉽게 연동할 수 있습니다.

• 장애 시작 시: 예를 들어 티켓이 “investigating(조사 중)” 상태로 바뀌거나 특정 우선순위 이상 사고가 생성될 때, 시계를 시작하라는 신호를 보냅니다.
• 장애 해결 시: 장애가 “resolved(해결)” 상태로 바뀌면, 시계를 멈추고 최종 시간을 저장하라고 신호를 보냅니다.

이 사이를 중계하는 작은 서비스를 Raspberry Pi 같은 소형 장비 위에 올려, 벽 뒤에 숨겨 둘 수 있습니다. 이 서비스는 웹훅 이벤트를 받아서, 시계의 모터를 제어하는 명령으로 번역합니다.

3. 물리적으로 크고, 절대 안 보일 수 없게 만들기

‘역 시계’ 미학의 핵심은 크기와 가시성입니다.

• 모두가 지나다니는 복도나 공용 공간의 벽에 설치하세요.
• 단순하고 굵은 눈금을 사용하고 (한 바퀴에 12시간 또는 24시간 등), 멀리서도 한눈에 읽을 수 있게 만듭니다.
• 회의실 건너편에서도 바로 읽을 수 있을 정도의 크기가 좋습니다.

정밀 계측 장비를 만드는 게 목표가 아닙니다. **대화를 이끌어내는 물건(conversation starter)**을 만드는 게 목적입니다.

왜 ‘짧고 신호가 명확한 타임라인’이 장애 대응에 중요한가

실시간 장애 상황에서, 누구에게도 여유로운 분석 시간은 없습니다. 이미 화면은 다음으로 가득 차 있죠.

• 로그
• 메트릭 그래프
• 의존성 다이어그램
• Slack(혹은 유사 도구) 대화 스레드

이때 인시던트 커맨더와 대응자들이 진짜로 필요로 하는 건 짧고, 신호가 강한 정보 표현입니다.

• 이 장애는 지금까지 얼마나 지속되고 있는가?
• 우리의 평소 TTR과 비교하면 어느 정도 위치에 있는가?
• 특정 기준선을 넘어서, 더 높은 단계로 에스컬레이션하거나 커뮤니케이션 방식을 바꿔야 할 시점인가?

아날로그 장애 시계는 이런 정보를 한눈에 보여 줍니다. 새로운 브라우저 탭을 열 필요도 없죠.

장애가 끝난 뒤에는, 멈춰 있는 시계가 **사후 학습 환경(post-incident learning environment)**의 일부가 됩니다. 회고(레트로스펙티브)에서 정말로 시계를 가리키며 이렇게 물어볼 수 있습니다.

• 왜 이건 40분짜리가 아니라 4시간짜리가 됐을까?
• 탐지나 완화 과정에서 뭐가 달랐길래 이렇게 시간이 길어졌을까?
• 이런 시간을 다시는 보지 않도록, 어떤 부분을 자동화할 수 있을까?

시간의 패턴을 보기: 하나의 시계에서 ‘역사의 벽’으로

하나의 시계는 마지막 장애 하나만을 보여줍니다. 하지만 여러 개의 시계, 혹은 이를 순환·집계해서 보여주는 시각화는 패턴을 드러냅니다.

• 몇 달에 걸쳐 TTR이 짧아지는 추세를 보이고 있는가?
• 특정 서비스나 팀이 유독 긴 TTR과 상관관계를 보이는가?
• 짧은 장애와 아주 긴 장애의 분포는 어떤 모양인가?

실제로 시계를 열 개 달 필요는 없습니다. 대신 이런 방법을 쓸 수 있습니다.

• 하나의 실제 시계를 두고, 중요한 장애가 있을 때마다 시계의 모습을 사진으로 찍어 출력해서 벽에 붙여 두기
• 한 달 단위로 대표적인 TTR 패턴을 묶어, ‘월간 인시던트 다이얼’ 포스터 같은 걸 만들어 시각적으로 공유하기

이런 식의 집계된 시각 타임라인은, 팀이 우선순위를 정하는 데 큰 도움을 줍니다.

• 사고의 80%는 20분 이내에 해결되는데, 나머지 20%가 4시간 이상 질질 끈다면, 드문 장기 장애의 롱테일에 노력을 집중해야 한다는 신호입니다.
• 최근에 도입한 모니터링·관측성 개선이 정말로 TTR을 40% 정도 줄였는지, 시계 패턴이 그대로 보여 줄 것입니다. 이건 리더십에게 투자 효과를 설득하는 데도 좋은 근거가 됩니다.

CI/CD와 신뢰성에 다시 연결하기

CI/CD 파이프라인이 진짜 빛을 발하는 순간은 다음과 같습니다.

• 배포를 자주, 그리고 작게 나눠서 할 수 있고
• 문제가 생기면 빠르게 롤백하거나 완화 조치를 취할 수 있을 때

TTR은 CI/CD가 약속하는 가치를 운영 측면에서 구현한 지표입니다. 배포량(Throughput)만 늘리고, 복구 시간에 대한 최적화를 소홀히 하면, 위험한 시스템이 됩니다.

아날로그 장애 시계는 이 긴장을 항상 눈에 보이게 유지합니다.

• 배포 빈도를 높였는데, 시계가 멈춰 있는 시간이 점점 길어진다면, 어딘가 균형이 깨졌다는 신호입니다.
• 알림이나 플레이북을 개선한 뒤 TTR이 줄어들면, 시계는 조용히 그 변화를 ‘공개적으로 축하’해 줍니다.

결국 이 시계는 신뢰성 작업과 소프트웨어 딜리버리 실천 전반에 대한 **피드백 루프 아티팩트(feedback loop artifact)**가 됩니다.

결론: 시간을 ‘측정’만 말고, ‘보이게’ 만들자

이미 많은 팀이 Time-To-Restore를 측정하고 있을 겁니다. 아마 Prometheus, Opsgenie, 탄탄한 대시보드 같은 훌륭한 도구 덕분에, 실제로 TTR을 40% 이상 줄였을 수도 있습니다.

하지만 숫자만으로는 문화가 바뀌지 않습니다. 이야기와 인식이 문화를 바꿉니다.

단순하고 눈에 띄는 아날로그 ‘장애 역 시계’를 하나 만들어, 장애 라이프사이클에 연결해 보세요. 그러면 다음과 같은 효과를 기대할 수 있습니다.

• 장애 지속 시간을 손에 잡히고 감정적으로 와 닿는 대상으로 만들고
• 장애 대응자에게 시간 압박을 직관적으로 보여주는 고신호 도구를 제공하며
• 회고, 우선순위 결정, 학습의 장에서 모두가 공유할 수 있는 공동의 기준점을 만들어 줍니다.

신뢰성 작업에서는 보통 눈에 보이지 않는 것들—패킷, 레이턴시, 트레이스—에 집착합니다. 그런데 때로는, 가장 강력한 개선은 그중 하나를 도저히 무시할 수 없게 만드는 데서 나옵니다.

그 시작점으로 시간을 선택해 보세요. 그리고 그 시간을, 벽에 걸어 두세요.