아날로그 인시던트 나침반 다락방: 모니터링이 무너질 때를 위한 올드스쿨 전술 다시 꺼내기

현대적인 옵저버빌리티는 놀라울 정도로 강력합니다. 그게 더 이상 동작하지 않는 날이 오기 전까지는요.

APM 대시보드는 멈춰 버리고, 메트릭 파이프라인은 밀려 쌓입니다. Synthetic 체크는 애매한 부분 장애 상태에서 멈춰 있습니다. 알림은 소음 수준으로 폭주하거나, 이상하리만큼 조용해집니다. 그런데 고객들은 실제로 문제를 겪고 있습니다.

모니터링 스택이 녹아내렸을 때, 당신에게 남은 건 무엇일까요?

여기서 등장하는 것이 바로 아날로그 인시던트 나침반 다락방입니다. 화면이 전부 꺼졌을 때도 조직이 움직일 수 있게 해 주는, 잘 정렬된 ITSM 프로세스, 임베디드 SRE 관행, 그리고 관리 잘 된 지식이 결합된 상태를 말합니다. 이건 향수가 아니라, **회복탄력성(resilience)**입니다.

이 글에서는 다음 내용을 다룹니다.

서비스 품질이 대시보드에 의존하지 않도록 ITSM 프로세스를 조율하는 방법
인시던트·문제·구성 관리(Incident / Problem / Configuration Management)를 영향도와 의존성을 파악하는 새로운 "프론트엔드"로 사용하는 방법
지식 관리를 실행 가능한 런북과 암묵지를 담은 "아날로그 다락방"으로 다루는 방법
임베디드·컨설팅 SRE를 활용해 아날로그 플레이북을 설계·리허설·실행하는 방법
멀티 클라우드·멀티 프로바이더 장애 플레이북을 만들고 반복 숙달하는 방법
"모니터링 다운" 게임데이를 통해 이런 전술을 몸에 배게 만드는 방법

나침반이 부러질 때: 모니터링 퍼스트 운영의 리스크

요즘 대부분의 팀은 모니터링 퍼스트(monitoring-first) 관점으로 운영합니다.

알림과 대시보드를 통한 인시던트 감지
APM 트레이스와 집계 로그를 단일 화면(single pane of glass)에서 보고 트리아지
서비스 맵과 자동 발견 토폴로지를 통한 의존성 이해

평소에는 훌륭한 접근이지만, 관측 도구 자체가 다음과 같은 상태가 되면 이야기가 달라집니다.

부분 장애 (네트워크 이슈, 모니터링 SaaS 제공업체 장애 등)
성능 저하 (메트릭 지연, 트레이스 드롭)
설정 오류 (잘못된 룰, 깨진 대시보드)

운영의 근육 기억이 **“그래프 뜰 때까지 기다리자”**에 맞춰져 있다면, 그건 취약점입니다. 여기에 더해, 기본 도구·탄탄한 프로세스·잘 관리된 지식에 기대는 아날로그 인시던트 전술이라는 두 번째, 독립적인 근육이 필요합니다.

도구가 실패할 때의 프레임워크: 조율된 ITSM

옵저버빌리티가 무너질 때, IT Service Management(ITSM) 역량은 통제력을 유지하는 등뼈가 됩니다. 핵심은 주요 프로세스들이 서로를 강화하도록 조율하는 것입니다.

인시던트 관리(Incident Management) – 대응, 커뮤니케이션, 의사결정을 총괄
문제 관리(Problem Management) – 화재 진압을 넘어선 근본 원인과 패턴을 포착
구성 관리(CMDB / Configuration Management) – 도구가 보여주지 못하는 의존성과 소유 정보를 저장
서비스 요청 관리(Service Request Management) – 인시던트가 아닌 업무를 워룸 밖으로 분리
서비스 수준 관리(Service Level Management) – 데이터가 부족할 때 기대치와 에스컬레이션 기준을 제공
지식 관리(Knowledge Management) – "대시보드 클릭"을 대신할 아날로그 가이드를 보관

모던 모니터링이 고장났을 때, 이 프로세스들은 **수동 제어 시스템(manual control system)**처럼 동작해야 합니다.

인시던트 관리: 혼돈의 정문

인시던트 관리는 모니터링 장애 상황에서의 **정문(front door)**입니다. 모든 것이 이 문을 통해 들어옵니다.

신호가 흐릿하더라도, 의심되는 이슈는 전부 인시던트로 등록
지정된 인시던트 커맨더(IC)가 제보를 트리아지하고 대응자들을 조율
이해관계자 커뮤니케이션은 상태 페이지, 슬랙, 이메일 등 일관된 채널로 송출

대시보드가 없는 상황에서 IC는 다음에 의존해야 합니다.

검출은 사람과 간단한 수동 체크에 의존
- 고객 제보, 지원 티켓, 온콜 엔지니어, 카나리아 배포
- curl, ping, traceroute 같은 간단한 네트워크 명령, 수동 synthetic 테스트
구조화된 트리아지 질문 사용
- 무엇이 영향을 받는가? (어떤 제품, 어떤 리전?)
- 언제부터 시작되었는가? (누가, 어디에서 처음 관측했는가?)
- 재현성은 어떤가? (어떤 요청 경로는 실패하고, 어떤 경로는 통과하는가?)
스택 레이어가 아닌 서비스 단위로 에스컬레이션
텔레메트리가 부족할수록, 막연히 "네트워크 탓", "DB 탓"을 하기보다 비즈니스 서비스 소유자에게 에스컬레이션하는 편이 훨씬 효과적입니다.

인시던트 관리는, 옵저버빌리티 도구가 제공하던 **조정 계층(coordination layer)**을 수동으로 다시 세워 줍니다.

문제·구성 관리: 대시보드가 꺼졌을 때의 컨텍스트

인시던트 관리가 정문이라면, 문제 관리와 구성 관리는 각각 **기록 보관소(아카이브)**와 **지도(map)**입니다.

문제 관리: 역사책

라이브 트레이스를 기대할 수 없을 때, 문제(Problem) 레코드는 엄청난 자산이 됩니다.

과거에 텔레메트리가 거의 없거나 부분적이었던 유사 인시던트 이력
특정 컴포넌트·프로바이더에서 반복되던 플레이키(flaky) 이슈
이전 장애 때 효과적이었던 우회책(workaround)

모니터링 실패 중에는 대응자들이 다음을 수행해야 합니다.

시스템 이름뿐 아니라 증상(symptom) 기준으로 문제 레코드를 검색
특정 벤더 조합(예: Cloudflare + AWS)이나 패턴(특정 리전에서의 지연 증가)으로 묶인 클러스터 찾기
계측이 어두운 상태에서도 검증된 완화책(mitigation)을 재사용

구성 관리: 의존성 지도

CMDB 혹은 서비스 카탈로그는 아날로그 버전의 서비스 맵입니다.

무엇이 무엇에 의존하는가? (예: API Gateway → 인증 서비스 → 사용자 DB → 캐시 → 외부 DNS)
어떤 서비스는 멀티 리전이고, 어떤 서비스는 단일 리전인가?
각 컴포넌트의 오너는 누구이며, 어떻게 빠르게 연락할 수 있는가?

토폴로지 그래프를 클릭해 볼 수 없을 때, 잘 관리된 구성 DB와 시스템 다이어그램은 다음을 가능하게 합니다.

영향받은 컴포넌트 목록만으로도 대략적인 블라스트 레이디우스(blast radius)를 추정
수동 체크를 효율적으로 수행 (예: 앱 문제로 몰아가기 전에 DB 직접 연결을 먼저 테스트)
서킷 브레이커, 페일오버, 피처 플래그에 대한 의사결정을 비교적 안전하게 수행

문제 관리 + 구성 관리는 라이브 옵저버빌리티가 불안정할 때 조직의 기억과 구조를 제공합니다.

지식 관리: 생존 스킬을 담은 "아날로그 다락방"

**지식 관리(Knowledge Management)**가 바로 아날로그 나침반 다락방이 실제로 존재하는 곳입니다.

단순한 위키를 넘어, 다음을 체계적으로 모아둔 공간이어야 합니다.

흔하지만 리스크가 큰 장애 유형에 대한 런북(runbook) – 특히 "모니터링 다운" 시나리오
**사후 분석(Postmortem)**에 담긴, "X를 다시 보게 되면 Y를 먼저 시도하라"는 형태의 명확한 가이드
인시던트 커맨드, 커뮤니케이션, 인계·인수 절차를 담은 체크리스트
옵저버빌리티 이전 시대를 경험한 시니어 엔지니어들의 암묵지(tribal knowledge)

모니터링 장애 상황을 위해서는 특히 다음이 필요합니다.

"모니터링 성능 저하 / 다운" 런북
- 이 문제가 단순히 내 VPN 문제인지, 실제 모니터링 장애인지 검증하는 방법
- 어떤 백업 도구를 쓸 것인지 (직접 로그 확인, 시스템 명령, 기본적인 프로브 등)
- 언제, 어떻게 수동 상태 업데이트 모드로 전환할지
서비스별 아날로그 플레이북
- 중앙 집중형 옵저버빌리티에 의존하지 않는 수동 헬스 체크 방법
- 안전하게 조정 가능한 레버: 피처 플래그, 서킷 브레이커, 트래픽 셰이딩/셰딩
- 과도한 완화를 막기 위한 명확한 "중단(stop) 조건"

이 지식 베이스를 실제로 자주 올라가는 다락방처럼 다루어야 합니다. 정기적으로 정리·레이블링·점검해서, 위기 상황에서도 사람들이 필요한 내용을 빠르게 찾을 수 있어야 합니다.

임베디드 & 컨설팅 SRE: 아날로그 플레이북의 설계와 실행

아날로그 전술을 실제로 작동하게 만들려면, **SRE(Site Reliability Engineer)**는 단순히 페이저를 받는 사람 그 이상이어야 합니다.

임베디드 SRE: 현장의 실무자

제품·엔지니어링 팀에 SRE를 임베드하면 다음이 가능합니다.

아날로그 인시던트 전술이 이론이 아닌 실무가 됨
수동 체크와 페일백 절차가 일상적인 워크플로우에 녹아듦
대시보드와 중앙 알림이 전혀 없는 상태를 가정한 장애 모드 리허설

임베디드 SRE의 책임은 다음을 포함합니다.

서비스별 런북과 아날로그 체크리스트 유지·관리
서킷 브레이커, 피처 플래그, 페일오버 메커니즘이 실제로 테스트 가능한 상태인지 확인
자신의 제품 영역 안에서 인시던트 드릴을 주도

컨설팅 SRE: 시스템 설계자

컨설팅 혹은 중앙 SRE 팀은 한 단계 상위 레벨에서 다음을 수행합니다.

조직 전반에 공통으로 사용할 수 있는 아날로그 플레이북 템플릿 설계·표준화
실제 인시던트와 게임데이 결과를 기반으로 런북을 리뷰·지속 개선
멀티 프로바이더 장애, DNS 장애 등 횡단적인 장애 패턴을 발견하고, 이에 대한 글로벌 플레이북 작성

정리하면:

임베디드 SRE는 아날로그 플레이북을 실행하고, 현실에 맞게 유지합니다.
컨설팅 SRE는 그 플레이북을 큐레이션하고 진화시켜 조직 전체의 수준을 끌어올립니다.

두 역할이 함께할 때, 아날로그 나침반은 잘 설계되고, 잘 연습된 도구가 됩니다.

멀티 프로바이더 장애 플레이북 만들기

현대 시스템 중 단일 프로바이더에만 의존하는 경우는 거의 없습니다. 현실적인 아날로그 도구 상자는 **멀티 프로바이더 장애(예: Cloudflare와 AWS가 동시에 문제를 겪는 상황)**에 대한 단계별 플레이북을 반드시 포함해야 합니다.

실용적이면서도 간결한 구조 예시는 다음과 같습니다.

트리아지 및 검증
- 고객 제보, 지원 티켓, 서로 다른 네트워크에서의 synthetic 체크 등 여러 관점에서 증상을 확인
- 프로바이더 상태 페이지와 외부 모니터링(공개 업타임 트래커 등) 교차 확인
Synthetic & 프로빙
- 의심받는 프로바이더와 독립된 synthetic 모니터링 사용
- 다음을 테스트:
  - 여러 DNS 리졸버에서의 DNS 해석
  - TLS 핸드셰이크
  - 단순 HTTP(S) 엔드포인트(헬스 체크, 랜딩 페이지)
APM 없는 트레이싱
- 간단한 수동 트레이싱 활용:
  - 서비스 간 로그에 상관관계 ID(correlation ID) 남기기
  - curl, HTTPie로 실제 유저 여정(user journey)을 단계적으로 따라가며 요청 보내기
  - ping, traceroute, mtr 같은 기본 네트워크 도구 사용
의도적인 페일오버 테스트
아키텍처가 허용한다면:
- 적은 비율의 트래픽을 대체 프로바이더나 다른 리전으로 안전하게 우회
- 이때 평소 대시보드 대신 로컬 로그, 수동 프로브, 고객 피드백으로 영향을 관찰
커뮤니케이션 & 기대치 설정
- 내부·외부 이해관계자에게 이번 인시던트가 멀티 프로바이더 장애라는 점을 명확히 설명
- 관측 수단이 제한되어 있어, 진단과 완화 속도가 느려질 수 있음을 미리 알림

이 플레이북은 문서화·버전 관리·정기 리허설이 필요하며, 그때그때 즉흥적으로 만들어서는 안 됩니다.

"모니터링 다운" 게임데이: 연습이 현실을 만든다

아날로그 전술을 처음 써보는 순간이 실제 위기 상황이어서는 곤란합니다.

정기적으로 "모니터링 다운" 게임데이를 운영해 보세요.

옵저버빌리티 실패 상황 시뮬레이션
- 연습 동안 대시보드 접근을 막거나 제한
- 특정 모니터링 도구의 알림을 의도적으로 음소거
아날로그 도구만 사용
- 시스템 명령: top, netstat, ss, journalctl, kubectl logs / kubectl describe 등
- 수동 HTTP 체크, DNS 쿼리, 단순 로그 스크래핑
미리 작성된 체크리스트를 따르기
- 인시던트 커맨드 체크리스트
- 서비스별 트러블슈팅 런북
- 커뮤니케이션 템플릿
리뷰 & 개선
- 지식 베이스에 어떤 정보가 더 있었으면 좋았는가?
- 소유권이나 의존 관계가 어디에서 모호하게 느껴졌는가?
- 어떤 런북이 오래되었거나 빠진 단계가 있었는가?

이 피드백을 지식·문제·구성 관리에 다시 반영합니다. 게임데이를 할 때마다, 아날로그 다락방은 더 깨끗해지고, 더 완전해져야 합니다.

결론: 불이 꺼지기 전에 준비하라

정교한 모니터링은 필수입니다. 하지만 그게 유일한 나침반이어서는 안 됩니다.

ITSM 프로세스를 조율하고, 인시던트 관리를 정문으로 삼으며, 문제·구성 관리로 과거 이력과 의존성 컨텍스트를 공급하면, 현대적인 툴이 사라진 상황에서도 충분히 항해를 계속할 수 있습니다.

당신의 지식 베이스는 아날로그 다락방이 됩니다. 대시보드가 꺼지는 날을 대비해 준비된 런북, 포스트모템, 암묵지가 그 안에 쌓입니다. 임베디드와 컨설팅 SRE는 아날로그 플레이북을 설계하고, 리허설하고, 다듬으면서 수동 체크·서킷 브레이커·페일오버를 익숙한 루틴으로 만들어 줍니다.

그리고 "모니터링 다운" 시나리오와 멀티 프로바이더 장애를 반복해서 연습함으로써, 올드스쿨 전술을 전설이나 구전(口傳)이 아닌, **훈련된 실무(practice)**로 바꿀 수 있습니다.

옵저버빌리티가 실패했을 때 비로소, "우리는 아날로그로 운영할 줄 모른다"는 사실을 깨닫게 되어서는 안 됩니다. 지금 당장, 당신의 아날로그 인시던트 나침반 다락방을 털어내고 정리하세요. 그리고 팀 모두가 그 다락방이 어디에 있고, 어떻게 사용하는지 정확히 알고 있도록 만드십시오.