그림자의 캐비닛: 당신의 지표가 결코 보여주지 않는 장애의 지도 그리기

모든 신뢰성(리라이어빌리티) 팀에는 하나쯤 있다.

대시보드도 아니고, 포스트모템 문서도 아니다. 훨씬 더 조용한 무엇이다.

“거의” 사고가 날 뻔했던 일에 대한 공유된 기억.

• 배포 직후 90초 동안 에러율이 치솟았다가, 이유도 모르게 저절로 회복된 배포.
• 실제 장애로 이어지지는 않았지만 모두를 식겁하게 만들 만큼 길게 걸린 데이터베이스 페일오버.
• 트래픽 패턴의 우연한 특징 덕분에, 원래라면 프로덕션을 박살 냈어야 했지만 결과적으로는 멀쩡했던 기능 플래그(Feature Flag) 실수.

고객 문의도 없다. 온콜 재난도 없다. 공식적인 사고 리뷰도 없다.

그리고 거의 언제나: 이 상황을 제대로 설명해주는 지표도 없다.

이게 바로 당신의 근접 사고(near miss) 다. 그래프에는 거의 표시도 안 되지만, 시스템은 필사적으로 알아달라고 신호를 보내고 있는 거의-장애의 아카이브, 일종의 그림자의 캐비닛(Cabinet of Shadows) 속에 숨어 있다.

이 글은 왜 그 그림자들이 중요한지, 왜 기존 옵저버빌리티 도구들이 이를 놓치는지, 그리고 생성형 AI가 어떻게 메트릭의 빈틈 사이에 숨어 있는 이야기들을 드러내고 해석하는 데 도움을 줄 수 있는지에 관해 이야기한다.

근접 사고: 시스템이 속삭이고 있는 사건들

항공, 산업 안전처럼 안전이 최우선인 분야에는 강력한 개념이 하나 있다. 바로 근접 사고(near miss, close call) 다.

근접 사고는 실제로 피해나 중단을 일으키지는 않았지만, 그럴 수도 있었던 비계획 이벤트다.

OSHA 같은 안전 분야에서는 이런 사건을 금쪽 같은 데이터로 취급한다.

• 다친 사람은 없다.
• 폭발도 없다.
• 운영은 다시 정상화된다.

그런데도 이 이벤트는 반드시 로그로 남기고, 분석하며, 종종 시정 조치를 촉발한다.

왜일까? 근접 사고가 알려주는 사실은 단순하면서도 소름 끼친다.

당신의 시스템은 아직 당신을 다치게 하지는 않았지만, 이미 충분히 취약하다.

소프트웨어 인프라에서도 똑같은 패턴이 반복된다.

• 트래픽이 우연히 적었기 때문에, 중요한 서비스를 완전히 막아버리지 않고 넘어간 잘못된 시큐리티 그룹 설정.
• 자동 리프레시 직전에, 거의 최대 메모리에 닿을 뻔했다가 간신히 피해 간 캐시 노드.
• 몇 초만 더 지나면 회복 불가능한 수준으로 밀릴 뻔했던 Kafka 파티션.

공식 장애는 없다. 상태 페이지도 초록불 그대로다. 하지만 시스템은 분명 손을 들었다.

왜 대시보드는 근접 사고를 보지 못하는가

전통적인 신뢰성 지표는 본질적으로 한 가지 목적에 최적화되어 있다. 이미 발생한 피해를 감지하고 계량하는 것이다.

우리는 SLO와 대시보드를 다음에 맞춰 설계한다.

• 에러율
• 지연 시간(percentile 기반 레이턴시)
• 포화도(saturation) 지표
• 가용성/업타임

필요한 것들이긴 하지만, 이것만으로는 부족하다.

그 결과는 이렇다.

• 에러율 스파이크가 스스로 회복되면, “잠깐 튀었네” 정도로 치부한다.
• 레이턴시가 SLO 기준 안에 있으면, “괜찮다”고 여긴다.
• 고객 불만이 없으면, “아무 일도 없었다”고 생각한다.

다시 말해, 우리는 **“피해 없음, 장애 없음”**을 그대로 비사건(non-event) 으로 취급한다.

하지만 안전·신뢰성 분야에서는 이런 사고방식이 정확히 정반대다.

오늘 당신을 부수지 못한 것들이, 내일 당신을 부술 가장 명확한 데이터일 때가 많다.

대시보드는 임계값(threshold) 과 정상 상태(steady state)에 맞춰 튜닝되어 있지, 미세한 이상 징후나 경계 조건의 취약성을 찾도록 설계되지 않는다. 그래서 근접 사고는 지표에서 과소 표현되거나 아예 사라진다.

그렇게 해서 당신은 그림자의 캐비닛을 떠안게 된다.

• Slack 스레드, 즉석 Zoom 통화, 복도에서의 잡담에만 남아 있는 이야기들.
• “아, 그때 큐 진짜 터질 뻔했던 거 기억나?”
• “진짜 운 좋았지. 언젠간 그거 고쳐야 하는데…”

메트릭, 티켓, 포스트모템 어디에도 남지 않으면, 이야기는 그림자 속으로 사라진다.

대시보드에서 오실로스코프로: 미세 신호를 보는 법

전자 공학에서 신호가 어딘가 이상한데 딱 부러지게 고장 난 건 아닐 때, 사람들은 단일 전압 수치만 보고 있지 않는다. 대신 이런 도구를 꺼낸다.

• 오실로스코프(oscilloscope) – 시간에 따라 변하는 신호를 고해상도로 시각화.
• 벡터스코프(vectorscope) – SMPTE 컬러 바 같은 복잡한 컬러 신호를 시각화.

왜 그럴까? 복잡한 시스템은 단일 숫자로 표현할 수 없는, 미묘하고 패턴화된 이상 현상을 보여주기 때문이다.

예를 들어, 벡터스코프에서 보는 SMPTE 컬러 바를 생각해 보자.

• 일반 모니터에서는 그저 색깔 막대 몇 개로 보인다.
• 벡터스코프에서는 각 색상이 특정 포인트나 영역으로 매핑된다.
• 어느 한 포인트가 살짝만 어긋나도, 신호의 어떤 구성 요소가 드리프트하고 있는지 바로 알 수 있다.

인프라 영역에서는 이런 시각을 갖추지 못한 경우가 많다.

• 우리는 “레이턴시 200ms 이하면 OK”만 보고 넘어간다.
• 특정 경로, 특정 테넌트, 특정 리전이 항상 살짝씩 치우쳐 있다는 사실은 보지 못한다.
• 우리의 시스템에는 이런 벡터스코프에 해당하는 것이 없어서, 근접 사고의 패턴을 놓친다.

필요한 건 단순히 더 많은 메트릭이 아니다. 미세한 동작을 들여다볼 더 나은 방법이다.

• 리소스가 “거의” 고갈될 뻔했던 상황을 보여주는 상관 분석된 트레이스.
• 배포, 페일오버, 트래픽 전환 시점의 고해상도 시간 창.
• 작지만 지속적인 편차를 강조해 보여주는 이상 징후 시각화.

근접 사고는 종종 복잡한 신호 속에 박힌 작은 이상 패턴으로 나타난다. 우리의 목표는 작은 블립마다 알람을 울리는 게 아니다. 시스템이 반복해서 실패의 경계를 스치고 지나가는 지점을 지도처럼 그려내는 것이다.

그림자의 캐비닛을 지도화하기: 근접 사고를 1급 시민으로 다루기

이 그림자 속 사건들을 빛 아래로 끌어내기 위해서는 프로세스와 툴링 모두를 바꿔야 한다.

1. 근접 사고를 진짜 인시던트로 선언하라

명시적인 카테고리를 하나 만든다.

• Severity N (Near Miss) – 이번에는 고객이나 비즈니스에 실제 영향을 주지 않았지만, 충분히 그럴 수 있었던 이벤트.

다음과 같은 상황을 보면 가볍게라도 인시던트를 여는 식으로 정한다.

• 이상하지만 스스로 회복해 버린 에러/레이턴시 스파이크.
• 자동 스케일링이 “정말 아슬아슬하게” 리소스를 늘려서 넘긴 포화도 상황.
• 수동 개입 덕분에 연쇄적인 장애로 번지지 않고 막을 수 있었던 순간들.

목표는 사소한 블립까지 전부 관료적으로 관리하겠다는 게 아니다. 사람들이 이렇게 말할 수 있는 문화를 만드는 것이다.

“이번엔 운이 좋았다. 왜 그런지 이해해 보자.”

2. 숫자만 아니라, 이야기를 기록하라

근접 사고는 메트릭만 남겨서는 설득력이 떨어지는 경우가 많다. 서사(narrative) 가 필요하다.

• 그때 시스템 전체적으로 어떤 일이 벌어지고 있었는가?
• 사람들이 가장 먼저 눈치챈 것은 무엇이었고, 무엇은 무시했는가?
• 어떤 행동이 결과를 바꾼 것처럼 보였는가?
• 부하, 지연, 추가 장애가 조금만 더 있었으면 어떻게 달라졌을 것인가?

이런 이야기들은 다음을 드러낸다.

• 다이어그램에 나타나지 않는 숨겨진 의존성.
• “9시에는 절대 저 서비스를 재시작하지 않는다” 같은 암묵지(tacit knowledge).
• 특정 개인의 영웅적인 대응이나 애매한 런북 때문에 생기는 조직적 취약성.

다시 말해, 이야기 자체가 데이터다.

인시던트 스토리의 신호 해석자로서의 생성형 AI

생성형 AI가 엔지니어링 워크플로우에 점점 스며들면서, 이제는 코드 샘플을 물어보는 챗봇 이상의 역할을 한다. 바로 서사를 해석하는 패턴 인식기다.

당신의 조직은 이미 다음과 같은 것들을 매일 만들어 내고 있다.

• “매운맛” 배포 때의 Slack·Teams 스레드
• 임시로 적어둔 인시던트 문서
• PagerDuty·온콜 노트
• PR 코멘트와 커밋 메시지

이 안에는 근접 사고에 대한 이야기가 가득하지만, 대부분 비정형 데이터로 남아 분석되지 않는다.

생성형 AI는 여기서 다음을 도와줄 수 있다.

1. 숨은 근접 사고를 끌어올리기

대화 로그와 문서를 (적절한 프라이버시·접근 제어 하에) 활용하면, AI는 다음을 할 수 있다.

• 유사 이벤트를 클러스터링: “Service X를 포함하고, 수동 롤백이 필요했던 배포들”
• 반복되는 표현 감지: “거의(almost)”, “다행히(luckily)”, “그래도 ○○ 덕분에”, “큰일 날 뻔했다” 같은 표현.
• 정식으로 인시던트로 기록되지 않았던 후보 근접 사고를 제안.

2. 인시던트 서사를 해석하고 재구성하기

AI는 인시던트 리포트를 읽고 다음을 수행할 수 있다.

• 반복적으로 등장하는 공통 기여 요인 추출
  • 예: “주인이 없는 의존성”, “수동 페일오버”, “누락된 알람” 등
• 이를 복잡계·안전 이론의 이머징 모델 위에 매핑
  • 예: 실패로의 드리프트(drift into failure), 로컬 합리성(local rationality), 샤프 엔드/블런트 엔드(sharp-end/blunt-end) 다이내믹
• 다른 관점의 프레이밍 제안
  • “우리가 멍청한 실수를 했다” → “시스템이 잘못된 행동을 하기 쉽게 설계돼 있었다.”
  • “운 좋게 살았다” → “아주 비슷한 패턴의 근접 사고가 반복되고 있다.”

이는 인간의 판단을 대체하자는 게 아니다. 다음과 같은 공동 분석가(co-analyst) 를 곁에 두는 것이다.

• Slack 메시지 200개를 읽어도 지치지 않고,
• 여러 달에 걸친 운영 이력 속 먼 지점을 서로 연결해 주는 분석가.

3. 미묘한 이상 징후를 위한 새로운 뷰 설계

오실로스코프와 벡터스코프가 엔지니어에게 신호를 이해하기 위한 새로운 시각적 문법을 제공했듯, AI는 근접 사고 패턴을 위한 새로운 시각화 설계를 도와줄 수 있다.

• 배포, 설정 변경, 리소스 포화 타임라인을 한눈에 겹쳐 보여주기.
• 여러 약한 신호가 동시에 나타나는 위험 구간(danger zone) 하이라이트.
• KPI 헬스가 아니라, 취약성(fragility) 인디케이터에 초점을 맞춘 대시보드 프로토타이핑.

실용적인 단계: 그림자에 빛을 비추는 방법

이를 위해 거창한 AI 플랫폼이 꼭 필요한 것은 아니다. 작은 단계부터도 그림자의 캐비닛을 지도화할 수 있다.

1. 근접 사고에 이름을 붙이고 추적하라.

   • “Near Miss” 라벨이나 별도의 Severity를 추가한다.
   • “실제 영향은 없었다” 하더라도, 엔지니어들이 짧게라도 정리해 남기도록 독려한다.

2. 이야기를 수집하라.

   • 인시던트 관련 Slack 채널과 회의 노트를 검색 가능한 저장소에 모은다.
   • 모든 ‘매운’ 이벤트 뒤에 한 가지만 물어본다:
     “이게 10%만 더 나빠졌다면, 무슨 일이 벌어졌을까?”

3. AI 보조 분석을 실험해 보라.

   • 생성형 AI를 사용해 몇 주치 운영 대화를 요약하고 반복 패턴을 추출한다.
   • 이렇게 물어본다:
     “이 인시던트들에서 어떤 근접 사고 패턴이 보이나?”

4. ‘벡터스코프’에 해당하는 뷰를 만들어라.

   • 근접 사고와 상관성이 높은 신호 몇 가지를 고른다: 배포 빈도, 부분 장애(partial failure), 수동 오버라이드 등.
   • 대형 론치, 백필(backfill), 마이그레이션 같은 까다로운 시기에 이 신호들을 함께 시각화한다.

5. 루프를 닫아라(피드백 루프 완성).

   • 의미 있는 근접 사고마다, 문제를 설계·프로세스·문화로 거슬러 올라가 본다.
     • 기본값을 바꿔서 “잘못된 행동”을 더 하기 어렵게 만들 수는 없는가?
     • 위험 신호를 더 일찍, 더 잘 보이게 만들 수는 없는가?
     • “이번엔 운이 좋았다”는 보고가 비난 없이 자연스럽게 올라오게 만들 수는 없는가?

결론: 일어나지 않은 일에 귀 기울이기

장애는 요란하다. 근접 사고는 조용하다.

대시보드는 이미 게임에서 진 뒤에 그 사실을 알려주는 데는 탁월하다. 하지만 얼마나 아슬아슬했는지, 그리고 그 일이 얼마나 자주 벌어지는지 알려주는 데는 훨씬 서툴다.

근접 사고를 1급 데이터로 취급하고, 오실로스코프·벡터스코프에 가까운 도구와 뷰를 도입하고, “거의 났던” 사건들의 풍부한 서사를 생성형 AI로 끌어올려 해석하기 시작하면, 비로소 당신의 그림자의 캐비닛에 지도를 그릴 수 있게 된다.

신뢰성은 업타임 차트를 더 뚫어져라 본다고 개선되지는 않는다. 결국 발생하지는 않았지만, 일어날 뻔했던 사건들에 귀 기울이고, 마치 실제로 일어난 것처럼 대응할 때 비로소 취약성이 줄어든다.

그림자 속에는 이미 수많은 이야기가 쌓여 있다. 질문은 단 하나다. 다음 그림자가 빛 속으로 걸어나오기 전에, 그 이야기들을 읽을 준비가 되어 있는가?