아날로그 장애 대응 역무도 서랍: 대시보드마다 다르게 거짓말할 때, 한 장짜리 종이 세이프가드 설계하기

대형 장애 동안 화상 회의를 해본 적 있다면 이런 장면을 봤을 것이다. 10명, 12개의 대시보드, 15개의 서로 다른 ‘진실’. Grafana는 한 가지를 말하고, 벤더 상태 페이지는 다른 얘기를 하고, 내부 메트릭은 둘 다와 다르며, 고객은 이 모든 것과 모순되는 스크린샷을 보내온다.

이 순간에 여러분에게 있는 문제는 모니터링 문제가 아니다. 조정(coordination) 문제다.

여기서 등장하는 개념이 바로 **“아날로그 장애 대응 역무도(incident train station map) 서랍”**이다. 모든 디지털 시스템이 제각각 소리를 질러대도, 모두가 이해하고 따라갈 수 있는 단 하나의 저기술(로우테크) 공유 “지도”를 갖자는 아이디어다.

옛날 기차역 대형 벽걸이 노선도를 떠올려보자. 모든 선로, 포인트(스위치), 노선이 한눈에 나오는 단 하나의 권위 있는 레이아웃. 계기판을 신뢰할 수 없을 때 관제사는 그 지도와 규칙을 본다. 장애 대응에서도 그 지도는 툴 안이 아니라 정책, 플레이북, 거버넌스 안에 존재한다.

이 글에서는 그 은유적인 종이 세이프가드(페일세이프)를 어떻게 설계할지 살펴본다. 그렇게 해서 모든 대시보드가 서로 다르게 거짓말을 하더라도, 조직이 여전히 효과적으로 대응할 수 있도록 말이다.

툴이 아니라 ‘정책’부터 시작하라

많은 팀이 툴부터 산다. 인시던트 관리 플랫폼, 알림 봇, 상태 페이지 같은 것들이다. 논리는 그럴듯하다. “모든 걸 연동만 하면, 장애 대응은 쉬워질 거야.” 하지만 실제로는 더 빠른 혼돈을 얻게 되는 경우가 많다.

순서는 이렇게 가야 한다.

1. 비즈니스 목표와 리스크 허용도(risk appetite)
2. 인시던트 대응 정책과 거버넌스
3. 플레이북과 런북
4. 마지막에야 툴

명확한 인시던트 대응 정책이 없으면, 툴은 단지 불일치를 자동화할 뿐이다. 무언가를 사거나 만들기 전에, 종이 위에서 먼저 답을 내야 한다.

• 무엇을 인시던트(incident) 로 보고, 무엇을 단순 이슈로 볼 것인가?
• 심각도(severity, SEV) 레벨은 어떻게 분류하고, 그것이 고객과 비즈니스에 각각 무엇을 의미하는가?
• 누가 인시던트를 선언할 수 있고, 누가 심각도를 상향(escalate) 할 수 있으며, 누가 인시던트를 종료(close) 할 수 있는가?
• 심각도 레벨별 알림 규칙(내부/외부)은 어떻게 되는가?
• 정보 공개(disclosure) 에 대한 우리의 입장은 무엇인가? 무엇을, 언제, 누구에게까지 공유할 것인가?

이 정책들이 문서로 정리되고 합의가 되면, 툴은 좋은 거버넌스를 구현하는 실행 수단이 된다. 거버넌스를 대체하는 것이 아니라. 아날로그 지도(정책)가 먼저 존재하고, 디지털 오버레이(툴)는 그 위에 얹힌다.

똑똑한 사람들이 서로 다르게 말할 때를 위한 거버넌스

장애 대응 중의 의견 충돌은 프로세스 실패가 아니다. 복잡한 문제를 다루고 있다는 증거다.

고조된 상황에서 자주 벌어지는 논쟁은 이렇다.

• 알림(Notification): C-레벨을 깨워야 할까? 법무팀을 불러야 할까? PR(홍보) 팀을 지금부터 개입시켜야 할까?
• 공개 범위(Disclosure scope): 지금 고객에게 알려야 할까, 나중에? 아니면 영향받은 일부에게만? 얼마나 상세하게 말해야 할까?
• 해결 기준(Resolution criteria): 인시던트가 실제로 끝난 시점은 언제인가? 에러율이 떨어졌을 때? 고객 확인까지 끝났을 때? 일정 쿨다운 기간 이후에?

이 질문들이 갈등을 전혀 일으키지 않는 세상을 설계할 수는 없다. 대신, 갈등이 빠르고 예측 가능하게 정리되는 세상을 설계할 수는 있다. 그것이 거버넌스다.

좋은 인시던트 거버넌스는 미리 다음을 정의한다.

• 의사결정 역할(Roles): 누가 Incident Commander(인시던트 커맨더) 인가? 누가 고객 커뮤니케이션을 책임지는가? 누가 리스크를 수용(accept risk) 하고 “배포해도 된다”, “이 정도면 닫아도 된다”라고 최종 판단할 수 있는가?
• 의사결정 프레임워크: 어떤 입력값이 중요하게 취급되는가? 예: “고객 영향이 15분 이상 지속되고 결제에 영향을 미치면 SEV‑1. 이 경우 커뮤니케이션 리드는 30분 이내에 외부 공지를 반드시 게시해야 한다.”
• 타이브레이커(Tie-breakers): 엔지니어링과 고객 성공(Customer Success) 팀이 의견이 다를 때, 최종 결정은 누구 몫인가? 어떤 조건에서 그 결정을 다시 뒤집을 수 있는가?

이를 역무도의 범례(legend)에 비유할 수 있다. 범례가 실제 지형의 애매함을 제거해 주지는 못하지만, 어떻게 해석하고 어떻게 움직여야 하는지를 알려준다.

과잉 설계된 인시던트 시스템: 스타트업의 고전 패턴

스타트업에서 종종 벌어지는 이야기가 있다.

• 3개월 차: 첫 번째 제대로 된 장애 발생. 대혼란.
• 4개월 차: 창업자들이 말한다. “제대로 된 인시던트 시스템이 필요해.”
• 5–8개월 차: 엔지니어 두 명이 커스텀 인시던트 대시보드/CLI/챗봇/자동화 스위트를 만든다.
• 9개월 차: 프로덕트 로드맵이 밀리고, 인시던트 시스템에는 아무도 쓰지 않는 기능이 가득하다. 다음 큰 장애 때도 사람들은 여전히 Slack에서 즉흥적으로 대응한다.

근본적인 문제는 툴이 부족해서가 아니라, 공유된 기대치와 연습된 절차가 없었다는 점이다.

커스텀 인시던트 관리 시스템에 과도하게 투자하는 이유는 흔히 다음과 같다.

• 툴을 만드는 일은 생산적이고 눈앞에 보이는 일처럼 느껴진다.
• 권한, 커뮤니케이션, 책임에 대한 불편한 대화를 피할 수 있다.
• “무엇을 인시던트로 볼 것인가?”, “SEV‑2는 실제로 어떤 상태를 의미하는가?” 같은 정의에 합의하는 일을 미룰 수 있다.

아날로그 지도 접근법은 이렇게 말한다. 먼저 종이부터 제대로 만들라.

• 공용 문서에 있는 한 페이지짜리 심각도 매트릭스(severity matrix)
• 누가 인시던트를 선언하고, 누가 닫을 수 있는지에 대한 짧은 정책 문서
• 텍스트 기반의 간단한 플레이북 몇 개를 담은 레포지토리나 위키

이것들을 실제 장애에서 몇 번 써본 뒤에야, 무엇(있다면)이 커스텀 툴링이 필요한지, 그리고 무엇은 이미 존재하는 평범하고 검증된 소프트웨어로 처리하는 것이 나은지 판단할 수 있다.

모니터링 vs. 감시(Surveillance): 메트릭 때문에 신뢰를 태우지 마라

신뢰성을 높인다는 명분으로, 조직은 종종 감시(surveillance)의 영역까지 미끄러져 들어간다.

• 개별 개발자 터미널 화면 캡처를 수집하는 것
• 사람별 “에러 대시보드”를 품질 관리 명목으로 운영하는 것
• 인시던트 대비를 핑계로 세세한 활동 로그를 남겨 두었다가 성과 관리에 활용하는 것

여기서 반드시 구분해야 할 것이 있다.

• 신뢰성을 지원하는 모니터링(Monitoring)

  • 집계된 메트릭과 로그
  • 서비스 수준 지표(SLI)와 에러 버짓(error budget)
  • 요청이 시스템을 어떻게 통과하는지 추적하는 트레이스(Trace) — 사람의 하루를 추적하는 것이 아니라, 요청의 흐름을 추적한다.

• 신뢰와 프라이버시를 갉아먹는 감시(Surveillance)

  • 인시던트의 “가해자”를 색출해 처벌하는 데 초점을 맞춘 추적
  • 나중에 검토할 목적으로 모든 키보드를 기록해 두는 것
  • 인시던트 데이터를 주로 HR(인사) 용도로 활용하는 것

건강한 모니터링은 시스템과 결과에 집중한다. 개인을 겨냥하지 않는다. 더 빠른 탐지와 대응을 가능하게 하지만, 동료를 잠재적 범죄자처럼 취급하지는 않는다.

이것은 인시던트 대응에서 매우 중요하다. 두려운 팀은 정보를 숨기기 때문이다. 엔지니어가 “이 로그 페이지가 나중에 나를 겨냥하는 증거로 쓰일 수 있다”고 믿으면, 장애 한가운데에서 정보를 덜 공유하게 되고, 이는 해결 속도를 늦추고 학습의 질을 떨어뜨린다.

따라서 아날로그 지도에는 다음이 명시되어야 한다.

• 무엇을 모니터링하는지 / 하지 않는지
• 인시던트 데이터가 어떻게 활용되는지 (비난이 아니라 학습과 개선을 위해)
• 프라이버시와 심리적 안전(psychological safety) 을 어떻게 보호하는지

이런 명료함은 장애 시 빠르고 솔직한 대응에 필요한 신뢰를 쌓는다.

플레이북 vs. 런북: 지도 위의 전략과 전술

탄탄한 인시던트 프로세스는 플레이북(playbook) 과 런북(runbook) 의 차이를 분명히 인식한다.

플레이북: 전략적 가이드와 의사결정 경로

인시던트 플레이북은 특정 유형의 문제에 대한 상위 수준의 전략이다. 한 노선 전체를 아우르는 역무도에 가깝다.

• 이 카테고리의 인시던트는 보통 어떻게 나타나는가?
• 누가 언제쯤 관여해야 하는가?
• 어떤 의사결정을 마주하게 될 가능성이 높은가?
• 핵심 트레이드오프(예: 데이터 일관성 vs. 가용성)는 무엇인가?

예를 들면:

• “플레이북: 대규모 고객 영향 장애”
• “플레이북: 보안 침해 의심 상황”
• “플레이북: 서드파티(3rd-party) 프로바이더 성능 저하”

플레이북은 이런 식으로 적을 수 있다.

10분 이상 5%가 넘는 요청이 실패하는 경우, Incident Commander는 SEV‑2에서 SEV‑1로 상향 조정을 고려해야 한다. 이 경우 경영진과 고객 커뮤니케이션 팀이 바로 개입된다.

플레이북은 정확히 어떤 버튼을 누를지까지 말해주는 것이 아니라, 가능한 경로와 선택지를 보여준다.

런북: 단계별 실행 지침

런북은 전술적(tactical) 인, 단계별 실행 지침이다. 노선 전체가 아니라, 특정 스위치나 분기점 하나에 대한 상세 패널에 가깝다.

예를 들면:

• 특정 서비스를 안전하게 재시작하는 절차
• 데이터베이스 페일오버 수행 방법
• 노출된 키를 교체(rotate)하는 방법

런북에는 다음과 같은 내용이 담길 수 있다.

1. 관리자 콘솔에 로그인한다.
2. X 명령을 실행한다.
3. 메트릭 Y가 5분 이내에 안정되는지 확인한다.
4. 그렇지 않으면 5–7단계의 롤백 절차를 따른다.

런북은 플레이북 안에서 동작한다. 장애 상황에서 플레이북은 Incident Commander가 어떤 런북을 어떤 순서로 쓸지, 언제 중단하고 에스컬레이션할지를 결정하는 데 도움을 준다.

플레이북과 런북을 명시적으로 나누고 둘 다 꾸준히 관리하는 조직은:

• 런북 덕분에 예상 가능한 조치를 더 빨리 수행하고,
• 플레이북 덕분에 언제 방향을 틀지, 언제 커뮤니케이션을 늘릴지, 언제 부분적인 해결을 받아들일지 더 나은 결정을 내린다.

나만의 아날로그 인시던트 지도 만들기

거창한 프로그램으로 시작할 필요는 없다. 서랍 안에 몇 장의 좋은 지도만 있으면 된다.

실무적인 시작점은 이렇다.

1. 한 페이지짜리 인시던트 정책

   • 인시던트와 심각도 레벨 정의
   • 누가 선언·에스컬레이션·종료할 수 있는지
   • 내부/외부 커뮤니케이션에 대한 기대치

2. 핵심 플레이북 3~5개

   • 고객 영향이 큰 서비스 장애
   • 보안 이슈 의심 상황
   • 데이터 손실 또는 손상
   • 서드파티 의존성 장애
   • 심각한 성능 저하

3. 주요 장애 유형에 대한 작은 런북 라이브러리

   • 재시작 절차
   • 폴백(fallback) 경로
   • 수동 오버라이드

4. 모니터링 및 프라이버시 선언문

   • 무엇을 모니터링하는지
   • 그 데이터가 어떻게 사용되는지
   • 인시던트 이후 리뷰가 비난이 아닌 비처벌적(non-punitive) 학습이라는 약속

5. 거버넌스 노트

   • 역할과 책임
   • 에스컬레이션 규칙
   • 실시간으로 의견 충돌이 날 때 어떻게 정리하는지

이 문서들을 모두가 아는 장소에 둬라. 공유 폴더, 레포지토리, 위키 등. 정말 중요한 것들은 인쇄해서 운영·관제 공간 벽에 실제로 붙여 두는 것도 좋다.

그리고 인시던트가 있을 때마다, 이 지도들을 업데이트하라. 어디가 헷갈렸는지, 어디서 머뭇거렸는지, 어떤 지점에서 툴들이 서로 싸웠는지 기록하라. 그 교훈을 먼저 아날로그 레이어에 반영하라.

결론: 모두를 정렬시키는 하나의 지도

대시보드끼리 상충하고, 알림이 오작동하며, 벤더 상태 페이지가 현실보다 늦게 따라올 때, 승리하는 조직은 공유된 멘탈 모델—장애를 어떻게 통과해 나갈지에 대한 명확하고 합의된 지도를 가진 조직이다.

그 지도는 다음과 같다.

• 대시보드가 아니라, 문서화된 정책과 거버넌스
• 결정을 프레이밍하는 플레이북과, 그 결정을 실행하는 런북
• 신뢰를 갉아먹는 감시가 아니라, 신뢰성과 학습을 지원하는 모니터링
• 목적이 분명한 프로세스를 뒷받침하는 소박한 툴 셋, 그리고 목적을 찾지 못한 채 비대해진 커스텀 인시던트 머신이 아닌 것

먼저 여러분만의 아날로그 장애 대응 역무도 서랍을 만들어라. 화면이 혼란스러워지거나—아예 꺼져버리는 순간—팀이 여전히 믿을 수 있는 유일한 것이 될지도 모른다.