당신이 기억하는 장애 vs. 문서에 적힌 장애

마지막으로 팀에 큰 인시던트가 있었던 순간을 떠올려 보세요.

당신이 기억하는 건 아마 이런 것에 그치지 않을 겁니다:

• 타임라인
• 영향받은 서비스 목록
• 루트 원인에 대한 한 줄 설명

당신이 기억하는 건 이런 것에 더 가깝습니다:

• 누군가 “저… 더 망가뜨린 것 같아요”라고 말한 직후, 콜을 지배하던 침묵
• “이 부분은 항상 잘 아는 사람”에게 쏟아지던 다급한 DM과 멘션들
• 롤백 여부를 두고 시니어 엔지니어 둘이 어색하게 설전을 벌이던 순간
• 누군가 슬랙 채널에 조용히 남긴 “5분만 휴식이 필요해요”라는 메시지

이런 것들은 보통 인시던트 리포트에는 거의 등장하지 않습니다.

여기서 등장하는 개념이 바로 **아날로그 인시던트 스토리 캐비닛 오브 에코스(Analog Incident Story Cabinet of Echoes)**입니다.

이는 인시던트를 단순한 기술적 실패가 아니라, 보존할 가치가 있는 이야기로 다루는 방식입니다. 목소리, 감정, 오해, 그리고 복잡한 시스템을 압박 속에서 살려 보려고 애쓰는 매우 인간적인 경험까지 포함해서요.

"아날로그 인시던트 스토리 캐비닛 오브 에코스"란 무엇인가?

이름은 다소 몽환적으로 들리지만, 아이디어 자체는 꽤 구체적입니다.

**캐비닛 오브 에코스(Cabinet of Echoes)**란, 장애가 팀 내부에서 실제로 어떻게 들리고, 어떻게 느껴졌는지를 풍부한 내러티브 형태로 보존한, 큐레이션된 인시던트 스토리 모음입니다.

기존처럼 다음만 아카이브하는 대신:

• 타임라인,
• 메트릭,
• 루트 원인 bullet point

…여기에 더해 다음도 함께 보존합니다:

• Slack, Zoom, Teams 등의 채팅 일부 발췌본 (필요하다면 가볍게 익명 처리)
• 참여자들의 핵심 발언 ("그 순간엔 진짜로 데이터베이스가 완전히 날아갔다고 생각했어요")
• 인시던트 콜의 오디오 일부나 트랜스크립트
• 각 참여자의 짧은 내러티브 회고 ("제 관점에서는 이렇게 느껴졌어요…")
• 감정적 맥락 (언제 스트레스가 최고조였는지, 언제 안도가 찾아왔는지)

여기서 "아날로그"라는 말은, 깨끗하게 정제된 디지털 추상화가 아니라, 주관적이고 lived experience 중심의 현실—즉 지저분하고 서사적인 면을 중시한다는 의미입니다.

당신이 저장하는 것은 단순한 데이터가 아니라, 그때의 **메아리(echoes)**입니다. 사람들이 실제로 어떻게 그 순간을 살았는지의 흔적이죠.

왜 전통적인 인시던트 리포트는 이렇게까지 건조할까

대부분의 인시던트 리뷰는 두 가지 질문에 답하기 위해 설계되어 있습니다:

1. 무슨 일이 있었나?
2. 다시는 이런 일이 일어나지 않게 하려면 어떻게 해야 하나?

둘 다 중요한 질문이지만, 이 질문들은 우리를 너무 좁은 프레임으로 밀어 넣습니다:

• 인시던트를 정렬된 사건들의 나열로 평탄화합니다 ("10:03에 알람 발생…")
• 복잡한 상호작용을 단일 원인으로 축약합니다 ("서비스 X의 플래그 설정 오류…")
• 감정과 불확실성을 걷어냅니다 ("DB인지 캐시인지 확신이 없어서 20분을 날렸다" 같은 맥락)

그 결과, 읽기에는 깔끔하지만, 실제로 배우기에는 별로 도움이 안 되는 결과물이 나옵니다.

대부분의 포스트 인시던트 문서는 다음을 말해주지 않습니다:

• 압박 속에서 대시보드가 얼마나 혼란스러웠는지
• 에스컬레이션 경로가 실제로는 얼마나 불분명하게 느껴졌는지
• 주니어 엔지니어들이 얼마나 말하기를 주저했는지
• 도구, 알람, 사회적 역학이 어떻게 서로를 강화하거나 방해했는지

이런 것들은 사회기술적(sociotechnical) 요인입니다. 사람, 도구, 문화, 프로세스, 권력 관계가 서로 얽혀 있는 지점이죠. 인시던트는 로그와 코드 안에만 존재하지 않고, 이 사회기술적 공간 전체 안에서 일어납니다.

캐비닛 오브 에코스는 바로 이 현실을 그대로 보존하기 위해 고안되었습니다.

장애의 사회기술적 현실을 포착하기

인시던트를 기술 퍼즐이 아니라 서사적인 사건으로 다루기 시작하면, 전혀 다른 디테일들이 눈에 들어오기 시작합니다:

• 스트레스: 누가 압도되고 있었는가? 누가 너무 많은 짐을 떠안았는가? 인지적 과부하는 언제 나타났는가?
• 가정(assumptions): 사람들이 무엇을 당연한 전제로 두었는가 ("배포는 이미 끝났다") 그리고 그것이 어떻게 틀렸는가?
• 커뮤니케이션 붕괴: 어떤 지점에서 메시지가 적절한 사람이나 채널에 도달하지 못했는가?
• 권력 역학: 누가 안전하게 말할 수 있다고 느꼈는가? 누가 그렇지 못했는가? 누가 자동으로 의사결정자 역할을 떠맡았고, 그게 결과에 어떤 영향을 미쳤는가?
• 툴 마찰(tool friction): 어떤 대시보드, 런북, 알람은 실제로 도움이 되었고, 어떤 것들은 사람들을 혼란스럽게 만들었는가?

이건 곁가지가 아닙니다. 실제 인시던트 압박 속에서는, 이런 인간적·조직적 역학이 실패한 코드 경로만큼이나 결정적입니다.

"무슨 일이 있었는지"뿐 아니라 "어떻게 들렸는지"까지 함께 보존하면, 캐비닛은 미래의 팀에게 다음을 제공합니다:

• 인시던트의 구조만이 아니라 질감(texture)
• 의사결정을 형성한 감정의 풍경
• 다이어그램과 런북이 상상하는 work-as-imagined가 아니라, 실제 현장에서 수행된 work-as-done

이렇게 쌓인 기록은 엔지니어링 조직의 세대를 잇는 공유 기억이 됩니다.

캐비닛 오브 에코스에는 무엇이 들어가는가?

대단한 플랫폼이 필요한 건 아닙니다. 필요한 것은 의도성입니다.

캐비닛 오브 에코스는, 예를 들어 다음과 같은 일관된 구조를 가진, 지식 베이스 안의 하나의 폴더일 수도 있습니다.

1. 스토리 개요(Story Overview)

• 3–5단락 정도의 짧은 내러티브 요약 (일상적인 언어로)
• 누가 참여했는지
• 무엇이 걸려 있었는지 (사용자 영향, 비즈니스 영향, 감정적 영향)

2. 목소리 & 순간들(Voices & Moments)

• 맥락이 붙은 선택된 채팅 발췌 및 인용
• 채팅 스레드의 스크린샷과 주석 (“이 순간이 우리가 롤백 실패를 깨달은 때였습니다”)
• 통화 내용 일부의 트랜스크립트 (타임스탬프 포함)

3. 감정 타임라인(Emotional Timeline)

• 인시던트의 대략적인 단계 (예: 혼란 → 공황 → 집중 → 안도 → 포스트모템 피로감)
• 각 단계에서 사람들이 남긴 짧은 회고

4. 사회기술적 메모(Sociotechnical Notes)

• 어떤 도구, 알람, 대시보드가 도움이 되었는지 혹은 방해가 되었는지
• 역할 혼선, 책임 불명확, 의사결정 병목의 징후
• 문화, 규범, 권력이 무엇을 쉽게 혹은 어렵게 만들었는지

5. 액션 아이템만이 아닌, 깊은 성찰(Reflections, Not Just Action Items)

• 사람들을 놀라게 했던 것들
• 다음에 똑같은 상황이 온다면, 기술적으로가 아니라 감정·사회적으로 무엇을 다르게 하고 싶은지
• 인시던트를 설명하는 데 자연스럽게 튀어나온 비유들 ("열쇠구멍으로 디버깅하는 느낌이었다" 등)

이런 아티팩트들은 기존의 기술적 포스트 인시던트 리뷰를 대체하는 것이 아닙니다. 그 옆에 나란히 놓이며, 빠져 있던 인간적 채널을 더해 줍니다.

학습, 공감, 문화가 달라지는 방식

시간이 지나면, 캐비닛 오브 에코스는 다음과 같은 역할을 합니다:

• 신규 온콜 엔지니어들을 위한 트레이닝 라이브러리: 단순히 무엇이 깨졌는지만 읽는 것이 아니라, 진짜 인시던트가 어떻게 느껴지는지를 경험하게 해줍니다.
• 리더십을 위한 공감 엔진: 단순한 인시던트 건수뿐 아니라, 그 이면에 있는 인지적·감정적 부하를 들려줍니다.
• 조직 문화를 비춰 보는 거울: 사람들이 압박 속에서 어떻게 말하고, 머뭇거리고, 에스컬레이트하고, 서로를 비난하거나 지지하는지의 패턴을 보여줍니다.

"이번 분기에 sev‑1이 12건 있었다"라는 문장 대신, 다음과 같은 것들이 보이기 시작합니다:

• 스트레스가 반복적으로 치솟는 지점과 그 이유
• 어떤 팀들이 상시적으로 노출되어 있는지
• 의사결정이 어디서 취약하거나 과도하게 중앙집중화되어 있는지
• 우리의 도구들이 어디에서 사람들을 모르게 위험한 습관으로 길들이는지

이는 인시던트 매니지먼트를 넘어, 더 넓은 의사결정에까지 영향을 줄 수 있습니다:

• 팀과 온콜 로테이션을 어떻게 구성할지
• 심리적 안전(psychological safety)을 어떻게 지원할지
• "휴먼 에러"를 어떻게 다루고, 어떤 시스템 조건들을 바꿔야 할지

왜 이게 AI와 자동화에도 중요한가

많은 팀이 인시던트 대응에 AI를 빠르게 도입하고 있습니다:

• 온콜을 위한 AI 코파일럿
• 자동화된 런북 실행
• 인시던트 종료 후 LLM 기반 요약

이 도구들은 학습할 데이터가 필요합니다. 만약 당신의 아티팩트가 전부:

• 지나치게 정제된 타임라인,
• 깨끗하게 정돈된 bullet point

뿐이라면, AI는 인시던트가 실제로 작동하는 방식과는 다른 세계를 학습하게 됩니다.

내러티브 인시던트 스토리는 AI 시스템에 다음을 제공합니다:

• 언어 속 모호성의 실제 예시 ("db가 죽었다"는 말이 실제로는 여러 가지를 의미할 수 있음)
• 서로 충돌하는 해석의 증거 ("난 네가 스테이징 클러스터 얘기하는 줄 알았는데")
• 오퍼레이터들이 도구를 설계 의도와 다르게 실제로 어떻게 사용하는지에 대한 창

이는 더 나은 AI 설계로 이어집니다:

• 실제 의사결정 포인트를 반영한 더 똑똑한 제안
• 인간의 주의력과 처리 용량에 대한 더 현실적인 기대
• 인간의 판단을 대체하기보다 보완하는 자동화

캐비닛 오브 에코스는 사회기술적 현실에 대한 그라운드 트루스가 됩니다. 특히 더 많은 책임을 자동화 시스템에 넘기려 할수록, 이런 현실 기반이 필수적입니다.

아날로그 캐비닛을 실무 습관으로 만드는 법

전체 인시던트 프로세스를 갈아엎을 필요는 없습니다. 작게 시작하면 됩니다:

1. 인시던트 체크리스트에 "스토리 캡처" 단계를 추가하세요

   • 인시던트가 해결된 뒤(또는 디브리핑 중), 한 사람을 스토리 큐레이터로 지정합니다.

2. 원자료(raw material)를 빠르게 모읍니다

   • 관련 Slack 채널이나 채팅 로그를 export 합니다.
   • 콜 녹음에서 주요 시간 구간에 마크를 남깁니다.
   • 각 참여자에게 3–5문장 정도를 부탁합니다: “제 관점에서 이 인시던트는 이렇게 느껴졌어요…”

3. 전부 받아쓰지 말고, 큐레이션하세요

   • 대표성이 있는 인용과 순간 몇 개를 고릅니다.
   • 짧은 설명과 타임스탬프를 덧붙여 주석을 답니다.

4. 기술적 포스트 인시던트 문서 옆에 보관하세요

   • 같은 폴더나 인덱스에, "Story Version" 또는 "Echoes" 같은 레이블로 명확히 구분합니다.

5. 교육과 리뷰에 실제로 사용하세요

   • 온보딩 시, 신규 입사자와 함께 인시던트 스토리를 읽거나 오디오 클립을 재생해 보세요.
   • 리더십 리뷰에서는 숫자와 그래프만이 아니라, 구체적인 인용문으로 현장의 경험을 함께 보여주세요.

몇 번 반복하다 보면, 이것은 인시던트 위생(hygiene)의 자연스러운 일부가 됩니다: 시스템을 고치고, 시스템을 이해하고, 시스템을 운영했던 그 감각까지 함께 기억하는 것.

결론: 메트릭만이 아니라, 기억을 설계하기

인시던트는 코드에서의 실패만이 아니라, 살아 있는 사회기술 시스템 안에서 발생하는 사건입니다.

아날로그 인시던트 스토리 캐비닛 오브 에코스라는 아이디어는 단순하지만 강력합니다:

• 장애가 작업자들에게 어떻게 들리고, 느껴지고, 전개되는지를 보존합니다.
• 내러티브, 감정, 혼란을 1급 데이터로 취급하고, 노이즈로 치부하지 않습니다.
• 루트 원인을 넘어서, 실제 인간 경험까지 포괄하는 조직적 기억을 만들어, 미래의 팀이 거기서 배울 수 있게 합니다.

메트릭과 로그는 시스템이 어디서 깨졌는지 알려줍니다.
캐비닛 오브 에코스는 사람들이 시스템을 어떻게 부서짐 속에서 지탱해 냈는지를 들려줍니다.

효과적인 동시에 더 인간적인 인시던트 매니지먼트를 원한다면, 그리고 당신의 도구·자동화·AI가 실제 업무 현실과 제대로 맞닿기를 바란다면, 이 둘 모두가 필요합니다.