아날로그 인시던트 스토리 만화경: 장애를 엔지니어링 인사이트로 바꾸기

인시던트는 비싸게 치입니다. 고객 신뢰를 소모하고, 새벽 3시에 사람을 깨우고, 소중한 엔지니어링 시간을 잡아먹습니다. 하지만 동시에, 인시던트는 매우 풍부한 이야기이기도 합니다. 모든 장애 안에는 수많은 결정, 가정, 아키텍처, 알림, 그리고 사람들의 반응이 뒤엉켜 있습니다.

대부분의 팀은 이 이야기를 한 번 읽고 끝내는 것으로 취급합니다. 타임라인 위주의 포스트모템 하나, 액션 아이템 몇 개, 그리고 다시 로드맵으로 복귀하죠. 이는 마치 만화경을 한 번 들여다보고는 바로 서랍 속에 넣어버리는 것과 같습니다.

이 글에서는 다른 접근법을 살펴봅니다. 바로 아날로그 인시던트 스토리 만화경(Analog Incident Story Kaleidoscope) 입니다. 장애를 한 번 쓰고 버리는 스토리가 아니라, 계속 돌리고, 재조합하고, 다시 들여다볼 수 있는 ‘종이 조각(shard)’ 들로 바라보는 사고 방식입니다.

이 글에서 다룰 내용은 다음과 같습니다.

• 왜 비유적 사고가 리더가 복잡한 시스템을 이해하는 데 도움이 되는지
• 어떻게 여러 개의 렌즈로 같은 인시던트를 볼 때 서로 다른 진실이 드러나는지
• 인시던트의 세부를 한 번 쓰고 끝나는 일화가 아니라 재사용 가능한 스토리 조각(shard) 으로 다루는 방법
• 어떻게 구조화된 포스트 인시던트 분석이 혼란을 학습으로 바꾸는지
• 테이블탑 연습과 비유 기반 회고가 전략을 실제 행동으로 연결하는 방법

왜 리더에게 ‘스토리 만화경’이 필요한가

현대 시스템은 하나의 서사로 완전히 설명하기에는 너무 복잡합니다. 마이크로서비스, 서드파티 의존성, 부분 롤아웃, 피처 플래그, 분산된 팀들이 서로 복잡하게 얽혀 있습니다.

비유는 리더가 디테일에 압도되지 않고 복잡성을 바라볼 수 있게 도와줍니다. 예를 들어, 시스템을 이렇게 생각해 볼 수 있습니다.

• 동네(서비스), 도로(API), 기반 시설(인프라)로 이뤄진 도시
• 생산자, 중간자, 소비자가 연결된 공급망(supply chain)
• 신호, 반사(reflex), 고차원 의사결정으로 구성된 신경계(nervous system)

각 비유는 서로 다른 측면을 강조합니다.

• 도시 비유는 지연(latency), 혼잡(congestion), 용량 계획(capacity planning) 을 떠올리게 합니다.
• 공급망 비유는 의존성과 장애 전파 에 초점을 맞추게 합니다.
• 신경계 비유는 가시성(observability), 피드백 루프, 알림 체계 에 집중하게 합니다.

‘스토리 만화경’은 인시던트를 살펴볼 때 이 비유들 사이를 회전하며 전환하는 사고 도구입니다. 한 번 “무슨 일이 있었나?”만 묻는 대신, 이렇게 묻습니다.

• 이게 압박받는 도시라면 무슨 일이 일어난 걸까?
• 이게 공급망 마비라면 어떻게 설명할 수 있을까?
• 이게 신경계 오작동이라면 무엇이 잘못된 걸까?

렌즈가 많을수록 인사이트는 더 풍부해집니다.

인시던트 스토리 돌려 보기: 같은 장애, 다른 각도

대부분의 인시던트 리뷰는 타임라인 형식으로 정리됩니다.

1. 09:02 – 서비스 A CPU 스파이크
2. 09:05 – 알림 발생
3. 09:12 – 온콜 합류
4. …

이런 정리는 필요하지만 충분하지는 않습니다. 선형 타임라인만으로는 비선형적인 인사이트를 놓치기 쉽습니다.

인시던트 스토리 만화경을 사용하면, 이야기를 여러 차원에서 돌려 볼 수 있습니다.

1. 아키텍처 렌즈

• 어떤 컴포넌트가 실패했고, 어떤 것들은 실패하지 않았나?
• 어디에 숨겨진 의존성(hidden dependency) 이 있었나?
• 설계 시 가정한 것들 중, 실제로 깨져버린 가정은 무엇인가?

이를 통해, ‘stateless’라고 생각했던 서비스가 사실은 캐시에 상태를 저장하고 있고, 그 캐시가 단일 장애 지점(SPOF) 이었다는 사실을 발견할 수 있습니다.

2. 인간/조직 렌즈

• 누가 핵심 정보를 갖고 있었지만 그 자리에 없었나?
• 어디에서 핸드오프가 혼란과 지연을 만들었나?
• 어떤 인센티브나 팀 경계가 대응 방식을 좌우했나?

이를 통해, 문서상으로는 인시던트 커맨더(Incident Commander) 역할이 존재하지만, 실제 사람들의 머릿속에는 그 역할이 제대로 자리 잡지 않았음을 알 수 있습니다.

3. 관측 가능성(Observability) 렌즈

• 어떤 신호(signal) 들이 있었지만 무시되거나 오해되었나?
• 로그, 메트릭, 트레이스가 전혀 없는 블라인드 스팟은 어디였나?
• 어떤 알림은 소음(noise) 이었고, 어떤 알림은 진짜 인사이트를 줬나?

이를 통해, 모두가 CPU 그래프만 들여다보느라, 실제 문제였던 큐 백업(queue backup)을 놓쳤다는 사실을 볼 수 있습니다.

4. 고객 영향 렌즈

• 장애가 서로 다른 유형의 사용자에게는 실제로 어떻게 느껴졌을까?
• 어떤 사용자 여정은 완전히 막혔고, 어떤 여정은 품질 저하만 있었으며, 어떤 여정은 거의 영향이 없었나?
• 어떤 커뮤니케이션 공백이 기술적인 문제보다 더 큰 문제를 만들어냈나?

예를 들어, 기술적으로는 작은 이슈였지만, 고객이 45분 동안 아무 소식도 듣지 못해 평판 리스크가 훨씬 커진 사례를 발견할 수 있습니다.

이렇게 스토리를 다양한 렌즈로 회전시키면, 하나의 인시던트가 여러 개의 학습 산출물(learning artifact) 로 바뀌고, 각각은 다른 개선 포인트를 가리키게 됩니다.

스토리 조각(Shard): 인시던트 조각을 재사용하기

각 인시던트를 산산이 부서진 스테인드글라스 창이라고 생각해 보겠습니다.

• 페이징 패턴과 알림 라우팅
• 특정 실패 모드 (예: thundering herd, stale cache, bad deploy)
• 그 상황에 참여한 사람들과 그들의 멘털 모델
• 사용된 도구들 (대시보드, 런북, 채팅, 티켓 시스템)
• 트래픽 급증, 의존 서비스 장애, 마이그레이션 등 환경적 맥락

각 인시던트를 하나의 완결된 이야기로 봉인해 버리는 대신, 이 조각들을 수집하고 이름을 붙여서 정리합니다.

재사용 가능한 샤드(조각)의 예는 다음과 같습니다.

• "롤아웃 과정에서 피처 플래그 오구성(misconfiguration)"
• "런북은 있으나 내용이 오래됨"
• "한 명의 SRE가 모든 컨텍스트를 독점"
• "회로 차단기(circuit breaker) 설정이 지나치게 보수적/공격적"
• "의존 서비스가 명확한 SLO 없이 우리를 rate limit 함"

한 번 샤드를 모으고 나면, 이런 일들을 할 수 있습니다.

• 인시던트들 간에 샤드를 재조합해 시스템적 패턴을 찾는다
  • 예: 서로 다른 4번의 장애에서 모두 “오래된 런북”이 등장 → 프로세스 수준의 문제
• 샤드를 섞어 복합 시나리오를 만들어 테이블탑 연습에 활용한다
  • 예: “의존 서비스 rate limit” + “온콜 교대 직후” + “UI 에러 핸들링 실패” 조합
• 반복되는 실패 모드를 추적하고, 이를 투자 항목과 연결한다
  • 예: “분기마다 캐시 설정 관련 이슈를 최소 한 번은 겪는다”

여기서 만화경 비유는 말 그대로입니다. 과거 인시던트에서 나온 조각들을 돌리고 재배열하면서, 각 인시던트를 따로 볼 때는 보이지 않던 새로운 패턴이 드러납니다.

구조화된 포스트 인시던트 분석: 만화경을 둘러싼 프레임

비유는 유용하지만, 구조 위에 얹혀 있을 때 비로소 힘을 발휘합니다. 좋은 포스트 인시던트 프로세스는 다음을 포함합니다.

1. 사실을 빠르게 수집한다

   • 타임라인, 로그, 스크린샷, Slack/Teams 스레드
   • 무엇이, 언제, 누구에 의해 변경되었는지

2. 표면적인 원인 너머를 탐구한다

   • 단순히 “나쁜 배포(bad deploy)”로 끝내지 않고, 왜 그런 식의 배포가 가능했는지 묻는다.
   • 왜 시스템이나 사람이 더 일찍 감지하지 못했는지 따져 본다.

3. 시스템적 기여 요인을 찾는다

   • 빠진 테스트, 약한 observability, 과도한 온콜 부담, 불명확한 오너십 등

4. 지속 가능한 개선을 만들어낸다

   • 코드 변경, 런북 업데이트, 새로운 알림, 더 나은 플레이북, 팀 교육 등

5. 명확한 오너와 후속 조치를 지정한다

   • 각 액션 아이템에 담당자, 기한, 추적 방식이 있어야 한다.

여기서 만화경이 들어갈 타이밍은, 기본적인 사실을 수집한 다음입니다. 이때 의식적으로 아래를 수행합니다.

• 최소 두세 개 이상의 렌즈(아키텍처, 인간/조직, 관측 가능성, 고객)를 통해 인시던트를 다시 본다.
• 이 인시던트에서 나온 재사용 가능한 샤드에 이름을 붙여 추출한다.
• 그 샤드를 과거 인시던트 및 향후 시뮬레이션과 연결한다.

이렇게 하면 리뷰가 “뭐가 잘못됐지?”에서 “무슨 재사용 가능한 이해를 얻었지?”로 전환됩니다.

테이블탑 연습: 저비용·고효율 시뮬레이션

테이블탑(tabletop) 연습은 토론 기반 인시던트 시뮬레이션입니다. 별도의 chaos engineering 도구도, 실제 프로덕션 영향도 필요 없습니다. 그저 사람들을 한 자리에(또는 화상 회의에) 모아 시나리오를 함께 따라가 보는 방식입니다.

테이블탑이 강력한 이유는 다음과 같습니다.

• 프로세스의 빈틈을 드러낸다 (누가 책임자지? 누가 고객과 소통하지?)
• “그건 SRE가 하는 줄 알았는데?” 같은 숨겨진 가정을 밝혀낸다.
• 사람들로 하여금 역할을 저스트 연습해 보게 한다. (실제 장애보다 훨씬 저스트한 환경에서)

간단한 테이블탑 진행 플로우는 다음과 같습니다.

1. 시나리오를 하나 고른다 (또는 여러 샤드를 조합해 만든 복합 시나리오)
2. 시작 상태를 정의한다 (시스템 정상, 트래픽 평시 수준)
3. 첫 번째 증상을 제시한다 (알림, 고객 문의, 대시보드 이상 징후 등)
4. 팀에 묻는다: 무엇을 하나요? 누가 하나요? 무엇을 먼저 보나요?
5. 시간을 조금 전진시키고, 새로운 정보나 복잡성을 드러낸다.
6. 인시던트가 해결되거나 최소한 봉합될 때까지 이어간다.
7. 디브리핑: 무엇이 잘 작동했나? 무엇이 헷갈렸나? 무엇을 바꿔야 하나?

비용: 캘린더 시간 + 퍼실리테이터 준비 시간. 효과: 실제 페이저가 울릴 때 놀랄 일이 줄어든다.

전략과 현실을 잇는 다리: 비유 + 테이블탑

아날로그 인시던트 스토리 만화경이 진가를 발휘하는 지점은, 비유 기반 회고와 테이블탑 리허설을 결합할 때입니다.

1단계: 스토리 샤드로 시나리오 만들기

여러 실제 인시던트에서 추출한 샤드를 조합해, 그럴듯한 새 이야기를 만듭니다.

• 샤드 A: “서드파티 API가 예고 없이 느려진다”
• 샤드 B: “알림은 에러율만 트리거하고, 지연 시간(latency)에 대해서는 없다”
• 샤드 C: “새 온콜 엔지니어가 의존성 그래프에 익숙하지 않다”
• 샤드 D: “고객 지원팀이 공식 인시던트 프로세스를 우회해 백채널로 에스컬레이션한다”

이제 아키텍처, observability, 커뮤니케이션을 동시에 시험해 볼 수 있는 현실적인 시나리오 하나가 손에 들어옵니다.

2단계: 다양한 비유로 테이블탑 디브리핑하기

디브리핑할 때, 의도적으로 비유 렌즈를 회전시킵니다.

• 도시 비유: 어디에서 교통 체증이 생겼나? 우회로와 비상 통로는 어디였나?
• 공급망 비유: 어떤 상류 공급자(의존 서비스)가 병목을 일으켰나? 대체 공급자가 있었나?
• 신경계 비유: 어떤 반사(reflex: 알림, 런북)가 동작했고, 무엇은 동작하지 않았나? 두뇌(리더십/개발자)는 과부하 상태였나?

이런 회전은 다음을 돕습니다.

• 리더가 전략(예: “우리는 탄탄한 공급망을 원한다”)을 운영 행동과 연결하게 해 준다 ("각 의존 서비스에 명확한 오너십과 계약이 필요하다").
• 엔지니어가 자신의 로컬 결정(알림 임계값, retry/timeout 설정 등)이 상위 레벨 시스템 행동에 어떤 영향을 주는지 보게 해 준다.

3단계: 비유를 구체적 변화로 번역하기

비유에서 멈추지 말고, 각 렌즈마다 스스로에게 질문합니다.

• 이 관점에서 봤을 때 떠오르는 설계 변경 한 가지는?
• 필요한 프로세스 변경 한 가지는?
• 필요한 학습 기회 한 가지(교육, 문서, 도구 개선)는?

이 답을 모아, 백로그와 인시던트 대비 프로그램에 반영합니다.

만화경을 조직의 습관으로 만들기

이 사고 방식을 조직에 뿌리내리게 하려면 다음을 시도해 볼 수 있습니다.

• 이 프랙티스에 이름을 붙인다: 문서와 회의에서 이것을 “인시던트 스토리 만화경”이라고 부르십시오.
• 표준 렌즈를 정한다: 주요 인시던트마다 최소한 아키텍처, 인간/조직, observability, 고객 렌즈는 꼭 검토합니다.
• 샤드를 모은다: 인시던트에서 반복해서 나타나는 패턴과 조각의 가벼운 카탈로그를 유지합니다.
• 정기적인 테이블탑 연습을 잡는다: 실제 샤드로 만든 시나리오를 가지고 분기별 또는 월별로 진행합니다.
• 크로스펑셔널 구성원을 초대한다: SRE, 기능 팀, 고객 지원, 제품, 커뮤니케이션 등, 실제 현실을 반영할 수 있는 사람들이 함께해야 합니다.

시간이 지나면 다음과 같은 변화가 보일 것입니다.

• “이거 예전에 한 번 본 장애인데…”라는 상황이 줄어든다.
• 인시던트 대응 속도가 빨라지고, 분위기가 더 차분해진다.
• 리더십이 말하는 이야기와 엔지니어가 현장에서 겪는 경험 사이의 정렬이 더 잘 맞는다.

결론: 혼란에서 패턴 있는 인사이트로

인시던트가 재미있을 일은 결코 없겠지만, 엄청나게 많은 것을 가르쳐 주는 사건인 것만은 분명합니다. 각 장애를 재사용 가능한 스토리 샤드의 원천으로 보고, 그 샤드를 여러 비유적 렌즈로 의도적으로 회전시켜 볼 때, 우리는 우연한 고통을 구조화된 학습으로 바꿀 수 있습니다.

아날로그 인시던트 스토리 만화경은 특정 도구나 벤더 제품이 아닙니다. 이것은 하나의 마인드셋입니다.

• 인시던트는 단순한 실패가 아니라, 다시 프레이밍해야 할 이야기다.
• 이야기는 정적이지 않고, 돌려 보아야 할 만화경이다.
• 샤드는 잔해가 아니라, 미래 회복탄력성을 위한 빌딩 블록이다.

이 마인드셋에 탄탄한 포스트 인시던트 분석과 정기적인 테이블탑 연습을 더한다면, 조직은 단지 장애를 ‘버티는’ 수준을 넘어, 시스템이 실패하는 속도보다 더 빠르게 학습하는 조직이 될 수 있습니다.