아날로그 인시던트 스토리, 그림자의 캐비닛: 메트릭으로는 절대 보이지 않는 장애를 지도에 그리기

현대 시스템에는 유령이 산다.

대시보드에 보이는 그래프는 깨끗하다. 업타임은 높고, 에러율은 낮고, SLA는 온통 초록이다. 하지만 인시던트 채널 구석, 개인 DM, 복도에서 오가는 대화 속 이야기는 전혀 다르다. 아슬아슬하게 막힌 장애, 잘못 설정된 보호 장치, 어찌어찌 “저절로” 복구된 실패한 페일오버, 아무도 제대로 파헤칠 시간이 없어 반복해서 지나가는 이상 징후들.

이것이 바로 당신의 그림자의 캐비닛(Cabinet of Shadows) — 메트릭에는 절대 잡히지 않는 장애와 실패의 아날로그하고, 지저분하고, 인간적인 기록이다.

이 글에서는 전통적인 신뢰성 메트릭이 왜 이 그림자 영역을 놓치는지, 숨겨진 보호 장치 실패가 어떻게 리스크 인식을 왜곡하는지, 그리고 이 보이지 않는 장애들을 어떻게 체계적으로 시각화 가능한 시스템 리스크 모델로 맵핑할 수 있는지 살펴본다.

이진 상태(Up/Down) 장애 모델의 문제

대부분의 신뢰성 프레임워크는 아주 단순한 전제 위에 서 있다. 시스템은 켜져 있거나(up) 꺼져 있다(down). 이 이진적 관점이 업타임 퍼센트, MTTF(Mean Time To Failure), SLA 같은 일반적인 지표의 기반이다.

그런데 실제 시스템은 이진적이지 않다. 계층적이고 조건부다. “완전 건강”과 “완전 다운” 사이에는 이런 스펙트럼이 존재한다.

겉으로는 건강해 보이지만 조용히 보호 장치가 고장 난 컴포넌트
더 이상 제대로 페일오버되지 않는冗長 경로
울려야 할 때 울리지 않는 잘못 튜닝된 알림(alert)
특정 부하 조건에서만 동작하는 자동화

전통적인 이진 모델은 대개 이렇게 가정한다.

시스템은 동작 중이거나, 완전히 실패했거나 둘 중 하나다.
보호 장치는 동작하거나, 아예 동작하지 않거나 둘 중 하나다(중간은 없다).
**부분 실패(partial failure)**나 **숨겨진 보호 성능 저하(hidden protection degradation)**는 거의 모델링하지 않는다.

결과적으로, 문서 상에서의 신뢰성은 실제보다 항상 좋아 보인다. 모델은 보호 장치가 제자리에서, 의도대로 잘 작동하고 있다고 가정한다. 하지만 실제로 운영 중인 시스템은 그 가정을 매번 만족하지 않는다.

숨겨진 계층: 눈에 보이지 않는 보호 장치 실패

시스템을 설계할 때 우리는 여러 겹의 보호 장치를 쌓는다.

로드 밸런서
레이트 리미터(rate limiter)
서킷 브레이커(circuit breaker)
재시도 로직(retry logic)
백업 라우트나 리전
피처 플래그와 킬 스위치

모델링할 때는 종종 이렇게 생각한다. “X가 실패하면, Y가 대신 맡는다.”

그런데 이미 Y가 망가져 있고, 우리가 모르는 상태라면 어떻게 될까?

이게 바로 **숨겨진 보호 장치 실패(hidden protection failure)**다.

마지막 마이그레이션 이후로 한 번도 갱신되지 않은 페일오버 경로
“성공”으로 표시되지만 실제로는 핵심 데이터를 조용히 건너뛰는 백업 작업
“잠깐만 비활성화”했다가 다시 켜지지 않은 알림 규칙
설정 오류로 실제로는 한 번도 트립하지 않는 서킷 브레이커

시스템의 진짜 신뢰성을 이해하려면, 우리가 시스템을 관찰하는 바로 그 순간에 보호 장치가 이미 고장 나 있을 확률을 추정해야 한다.

이건 결코 단순하지 않다.

“지금 이 안전망은 고장 난 상태입니다”라고 말해 주는 직접적인 메트릭은 거의 없다.
실패는 드러나기 전까지 **잠복(latent)**해 있다가 몇 주, 몇 달이 지나서야 발견되기도 한다.
숨겨진 실패의 확률은 시간이 지남에 따라 변한다. 특히 배포, 설정 변경, 부분 인시던트 이후에 큰 폭으로 달라진다.

대부분의 조직은 이걸 아예 모델링하지 않는다. 그래서 대시보드는 암묵적으로 이렇게 가정한다. “최근에 실패한 적이 없으니, 지금은 괜찮다.” 이 가정은 자주 틀린다.

시간에 따라 변하는 상태 확률: 신뢰성은 움직이는 목표다

시스템은 몇 개의 이산 상태 중 하나에만 있는 것이 아니다. 시간이 흐르면서 상태를 옮겨 다닌다. 더 중요한 건, 각 상태에 있을 확률 자체가 시간에 따라 변한다는 점이다.

그 확률은 다음과 함께 계속 바뀐다.

코드와 인프라 변경
트래픽 패턴 변화
운영자가 배우고, 자동화하고, 가끔은 시스템을 망가뜨리는 일

개념적으로 시스템 상태를 이렇게 정의해 볼 수 있다.

건강하고, 보호 장치도 모두 정상 작동 중
겉보기에는 건강하지만, 하나 이상의 보호 장치가 조용히 성능 저하 또는 실패 상태
부분 실패 상태 (예: 성능 저하, 일부 리전/기능 제한 등)
완전 실패 상태 (실제 장애)

각 상태는 시간에 따라 변하는 확률을 가진다.

대규모 배포 직후에는 숨겨진 설정 오류의 확률이 급격히 올라갈 수 있다.
큰 인시던트 후에는 일시적으로 보호 장치가 좋아져서 일부 리스크가 낮아질 수 있다.
시간이 지나면 엔트로피가 쌓인다. 설정은 드리프트하고, 의존성은 업데이트되고, 가정은 낡으면서 확률이 다시 올라간다.

하지만 대부분의 표준 메트릭은 다음과 같다.

시점별 값만 보고한다(예: 오늘의 업타임)
잠복된 리스크나 숨겨진 실패는 보지 못한다.
역사를 연속적인 과정이 아니라, 서로 독립적인 스냅샷의 나열로 취급한다.

시간에 따라 변하는 이 상태 확률을 모델링하지 않으면, 이런 패턴을 놓친다.

“대규모 배포 후 2주 이내에 보호 장치 실패 리스크가 통계적으로 의미 있게 올라간다.”
“대형 인프라 변경 후 90일 이내에 백업 설정 오류가 발생할 가능성이 유의미하게 증가한다.”

복잡한 확률 과정 이론을 배우지 않아도 된다. 핵심은, 신뢰성을 정적인 값으로 보지 말고 리스크는 항상 움직이고 있다는 사실을 인정하는 것이다.

그림자 영역: 대시보드에 잡히지 않는 근접 사고와 오퍼레이션 실수

어느 정도 탄탄한 시스템이라면, 실제 장애로 발전하지는 않았지만 분명히 존재했던 사건의 보이지 않는 층이 있다.

막판에 롤백되어 간신히 막은 배포
누군가 우연히 눈치채서 겨우 넘긴 데이터베이스 95% 용량 초과
시니어 엔지니어 코드 리뷰에서 걸러진 잘못된 방화벽 규칙
실제 고객 영향은 없었지만 심각한 구멍을 드러낸 페일오버 테스트

이것들이 바로 **근접 사고(near-miss)**와 **보호 장치 오작동(misoperation)**이다.

이들은 대개 다음과 같은 특징을 가진다.

고객이 체감하는 가시적인 장애를 만들지는 않는다.
에러율이나 레이턴시 같은 메트릭에는 거의 나타나지 않는다.
티켓이나 공식 인시던트로 남지 않고, 비공식적으로 처리되는 경우가 많다.

하지만 이들은 곧바로 다음의 직접적인 증거다.

숨겨진 취약점
망가지거나 성능이 저하된 보호 장치
리뷰, 테스트, 변경 관리 프로세스의 조직적 블라인드 스팟

이 전체 그림자 영역은 보통 신뢰성 리포트와 대시보드에서 완전히 빠져 있다. 우리가 얻는 건 다음뿐이다.

아주 깔끔한 업타임 숫자
그럭저럭 관리할 수 있어 보이는 인시던트 개수
얼마나 자주 파국 직전까지 갔는지에 대한 명확한 신호는 없음

당신의 그림자의 캐비닛은 이미 존재하지만, 다음과 같은 형태로 흩어져 있다.

사람들의 기억 속
DM과 비공식 채널
공유되지 않은 런북, 개인 노트

이 공간을 지도에 옮겨 그리는 것, 그게 실제 신뢰성을 이해하는 첫 단계다.

심리적 안전감: 유령 이야기에서 데이터로

사람들이 입 밖으로 꺼내기 두려워하는 것은 측정할 수 없다.

이 그림자 인시던트를 끌어올리려면, 사람들에게 다음을 보고해도 안전하다고 느끼게 해 주는 **심리적 안전감(psychological safety)**이 필요하다.

거의 장애를 낼 뻔한 실수
고객에게는 닿지 않았지만 분명히 존재했던 근접 사고
“막판에” 발견한 설정 오류
실패한 실험과 보기 흉한 의외의 결과들

심리적 안전감을 적극적으로 키운 팀에서는 보통 이런 변화가 보인다.

근접 사고 보고량이 급증한다. 예를 들어 6개월 만에 40% 증가 같은 숫자가 실제로 관찰된다.
리스크가 실제로 어떻게 나타나는지에 대한 더 구체적이고 질 높은 서사가 쌓인다.
보호 장치 실패 패턴을 훨씬 더 일찍 포착한다.

이를 뒷받침하는 리더십 관행은 대략 다음과 같다.

책임 추궁이 아닌 학습에 초점을 둔 블레임리스(blameless) 인시던트 리뷰
장애보다 “급이 낮은” 일이 아니라, **동급(first-class)**으로 다루는 정기적인 근접 사고 리뷰 세션
리더 스스로 자신의 실수와 근접 사고를 공개적으로 공유
약한 신호를 일찍 보고한 사람에게 명시적으로 인정과 감사를 표현

목표는 이야기를 그림자에서 끌어내어, 리스크 모델의 핵심 입력으로 다루는 것이다.

스토리 캐비닛에서 시각적 리스크 대시보드로

장애, 근접 사고, 숨겨진 실패의 신호들을 눈에 보이게 모으기 시작했다면, 이제 이를 바탕으로 시각적인 리스크 분석 대시보드를 만들 수 있다. 이 대시보드는 다음을 목표로 한다.

서로 다른 유형의 이벤트를 통합하기
- 고객에게 직접 영향을 준 전체 장애(full outage)
- 일부 기능/리전/성능만 떨어진 부분 장애(partial degradation)
- 근접 사고(near-miss)
- 보호 장치 오작동, 테스트 실패
시간에 따라 변하는 리스크를 시각화하기
- 대형 릴리스 전후로 리스크가 어떻게 변하는지 보여주기
- 실제 장애에 앞서 몰려 나오는 근접 사고 클러스터를 강조 표시
- “마지막 검증 이후 180일 이상 경과” 같은 노후 보호 장치(ageing protection)를 하이라이트
숨겨진 실패의 지표를 드러내기
- 실패한 페일오버 드릴
- 일부만 성공한 백업 복구(restore) 테스트
- 기대대로 울리지 않은 알림 테스트

이 대시보드는 기존의 Observability 스택을 대체하는 것이 아니다. 오히려 그림자 영역을 지도 위에 올려놓는 보완재에 가깝다.

메트릭은 말해 준다: “지금 바로 무슨 일이 벌어지고 있는가”
인시던트와 근접 사고 스토리는 말해 준다: “무엇이 일어날 뻔했으며, 왜 그런 일이 거의 일어날 뻔했는가”
이 둘이 합쳐져 시스템 리스크의 동적인 지도가 된다.

소방수 모드에서 선제적 리스크 관리로

가시적인 장애만 추적할 때 조직은 반응적인 소방수 모드에 갇힌다.

인시던트가 터진다.
모두가 불 끄느라 뛰어다닌다.
회고를 쓴다.
그때의 직접적인 원인만 패치한다.

반대로, 그림자의 캐비닛을 체계적으로 맵핑하기 시작하면 태도가 이렇게 바뀐다.

보호 장치 실패 패턴을 실제 장애 이전에 미리 본다.
특정 유형의 변경 이후 리스크 수준이 어떻게 상승하는지 감지한다.
최근에 겪은 고통(pain)만이 아니라, 리스크가 집중되는 구역을 기준으로 우선순위를 세운다.

구체적으로는 이런 변화가 나타날 수 있다.

보호 장치를 의도적으로 스트레스 테스트하는 정기적인 게임데이(game day) 운영
백업, 페일오버, 알림 체계에 대해 “마지막 검증 이후 경과 시간”을 추적
근접 사고 밀도(density)를 선행 지표로 삼아 예방 작업을 트리거
특정 종류의 릴리스 이후 근접 사고가 치솟는다면, 그에 맞춰 변경 관리 정책을 조정

변화의 문장은 간단하지만, 실행은 어렵다. *“우리는 장애를 몇 번 겪었는가?”*에서 *“시스템이 ‘거의 위험했다’고 말해 준 순간이 몇 번 있었고, 거기서 무엇을 배웠는가?”*로 질문을 바꾸는 것이다.

결론: 캐비닛을 열고, 그림자를 지도에 올려라

당신의 시스템은 대시보드가 말해 주는 것보다 더 취약하고, 동시에 더 많은 것을 알려준다.

다음과 같은 접근을 통해:

단순한 Up/Down 장애 모델을 의심하고
숨겨진 보호 장치 실패와 그 시간 가변적 확률을 고려하고
근접 사고와 오퍼레이션 실수를 1급 데이터로 다루고
사람들이 실제로 이를 보고할 수 있도록 심리적 안전감을 만들고
이 모든 신호를 시간 축을 가진 시각적 리스크 대시보드로 통합하면

…“모든 그래프가 초록이라서 안전해 보이는” 가짜 신뢰성에서 벗어나, 실제 리스크 지형을 보고, 그 지형을 설계하는 쪽으로 나아갈 수 있다.

그림자의 캐비닛은, 당신이 인정하든 말든 이미 존재한다. 선택지는 둘뿐이다. 이곳이 계속해서 속삭임과 뒷이야기의 집합으로 남게 할 것인가, 아니면 당신이 방향을 잡을 수 있는 지도로 바꿀 것인가.