아날로그 장애 스토리 캐비닛의 다리들: 사고가 팀을 단절시키기 전에 종이로 교차점을 손수 구축하기

현대의 장애 관리 환경은 대시보드, 자동화, AI 기반 알림으로 가득 차 있습니다. 하지만 진짜 회복탄력성을 키워 주는 가장 강력한 도구들 중 상당수는 놀라울 만큼 저(低)기술입니다. 종이, 펜, 그리고 의도적인 대화 같은 것들 말입니다.

조직을 여러 팀이 흩어져 있는 하나의 지형으로 떠올려 보세요. 인프라 팀은 여기, 프로덕트 팀은 저기, 보안 팀은 저쪽, 고객 지원 팀은 멀리 언덕 너머에 있습니다. 장애가 터졌다고 해서 갑자기 새로운 다리가 생기지는 않습니다. 그 순간에 쓸 수 있는 건 이미 존재하는 다리들뿐입니다.

여기서 등장하는 개념이 바로 **“아날로그 장애 스토리 캐비닛의 다리들”**입니다. 이는 장애가 모두를 압박 속에서 다리를 건너게 만들기 전에, 팀들 사이에 다리를 손수 지어 두도록 돕는, 의도적으로 저기술이며 스토리 중심적인 방법입니다.

왜 장애 대응에는 대시보드 이상의 것이 필요한가

현대 DevOps와 SRE 실천에서 장애 관리는 비교적 명확한 목표를 가집니다.

다운타임을 줄여 고객에게 가는 영향을 최소화한다.
문제를 빨리 고치는 것뿐 아니라, 정직한 설명을 통해 고객 신뢰를 지킨다.
분명하고 반복 가능한 워크플로우를 따르며, 역할과 에스컬레이션 경로를 정의해 “누가 책임자지?”라는 질문이 나오지 않게 한다.

요즘 대부분의 팀에는 장애 대응 플레이북이 있습니다. 누가 장애를 선언하는지, 누가 인시던트 커맨더(Incident Commander)를 맡는지, 누가 커뮤니케이션을 담당하는지, 언제 어떻게 에스컬레이션하는지 등이 정리되어 있습니다. Slack 채널, 인시던트 봇, 런북, 온콜 로테이션 같은 도구들이 이런 과정을 조율해 줍니다.

하지만 워크플로우가 잘 갖춰져 있어도 다음과 같은 상황에서는 쉽게 무너질 수 있습니다.

팀들이 서로의 시스템이나 제약 조건을 제대로 이해하지 못한다.
커뮤니케이션 경로가 불명확하거나 쉽게 끊어진다.
과거의 교훈이 공유된 살아 있는 지식으로 남지 못한다.

이건 도구의 실패가 아니라 사회기술적(sociotechnical) 실패입니다.

장애는 “기술적 오류”가 아니라 사회기술적 사건이다

장애는 순수하게 기술의 영역에서만 발생하지 않습니다. 사람과 기술이 끊임없이 상호작용하는 사회기술적 시스템 안에서 일어납니다.

코드는 조직의 인센티브와 마감 기한 속에서 작성됩니다.
런북은 과거 장애 경험 뿐 아니라 내부 정치와 의사결정 구조를 반영합니다.
에스컬레이션 경로는 실제 현실이라기보다 조직도(Org chart)를 따라 그려지는 경우가 많습니다.

회복탄력성을 키우려면 두 가지 면을 모두 이해해야 합니다.

기술적 측면: 아키텍처, 의존성, 한계, 장애 양상
사회적 측면: 소유권(ownership), 기대치, 커뮤니케이션 규범, 인지 부하, 신뢰 관계

그래서 장애 이후에 “리트라이 추가”, “큐 크기 확장”, “쿼리 튜닝” 같은 순수 기술적 조치만으로는 충분하지 않은 경우가 대부분입니다. 다음 장애는 종종 조금 다른 방향에서, 사람의 가정과 시스템의 동작 사이의 틈에서 나타납니다.

필요한 것은 **다리(bridge)**입니다. 장애가 터지기 전에 팀, 관점, 책임을 서로 이어 주는 프로세스 말입니다.

구조화된 포스트모템: Google SRE에서 업계 표준으로

현대 신뢰성 실천에서 가장 중요한 다리 중 하나가 바로 **구조화된 포스트모템(postmortem)**입니다. Google SRE 문화에서 시작된 이 방식은 이제 업계 전반으로 널리 퍼졌습니다.

잘 운영되는 포스트모템은 다음과 같습니다.

블레이멀리스(blameless): 잘잘못을 가리지 않고, 당시의 조건과 의사결정을 이해하는 데 초점을 둡니다.
구조적(structured): 일관된 템플릿과 프로세스를 사용합니다.
실행 가능(actionable): 기술, 프로세스, 조직 차원에서의 구체적인 개선 조치를 도출합니다.
공유 가능(shared): 관련된 모든 팀이 접근할 수 있으며, 특정 팀의 드라이브에만 갇혀 있지 않습니다.

시간이 지나면서 일관된 포스트모템 실천은 미묘하지만 강력한 변화를 만듭니다. 장애 리뷰 미팅을 **단순한 상태 보고나 책임 추궁 자리가 아니라 학습의 의식(ritual)**으로 바꿔 버립니다.

그러면 여러 패턴이 눈에 띄기 시작합니다.

서로 다른 장애에서 똑같은 에스컬레이션 공백이 반복된다.
특정 팀과의 조율은 항상 늦고, 그때그때 즉흥적으로 이뤄진다.
프로덕트와 운영(Ops) 사이에 동일한 유형의 오해가 계속 나타난다.

이런 패턴은 현재의 다리가 약하거나, 아예 없다는 신호입니다.

포스트모템에서 다리로: 메타포를 바꾸기

대부분의 조직은 장애 프로세스를 일련의 양식과 단계로 취급합니다. 선언, 트리아지, 완화, 해결, 리뷰 같은 흐름 말입니다.

좀 더 강력한 접근은 이 프로세스들을 팀 간 다리로 바라보는 것입니다.

인시던트 런북은 온콜 대응자와 시스템 오너 간의 다리입니다.
에스컬레이션 경로는 현장 대응자와 전문가·리더십 사이의 다리입니다.
포스트모템은 장애를 직접 겪은 팀과, 다음 장애를 겪게 될지도 모르는 팀 사이의 다리입니다.

이 다리 메타포를 채택하면 몇 가지 변화가 일어납니다.

공유 소유권이 커진다. 다리는 사용하는 모두의 것입니다. “운영 팀의 프로세스”, “SRE의 템플릿”이 아니라 조직 전체의 자산이 됩니다.
커뮤니케이션이 설계 대상이 된다. 스트레스 상황에서 사람들이 이 다리를 찾을 수 있는지, 필요한 사람이 모두 건널 수 있을 만큼 넓은지 질문하게 됩니다.
조정이 즉흥이 아니라 사전 설계가 된다. “그때 가서 누구를 부를지 정하자”가 아니라, 미리 어떻게 건널지 설계해 둡니다.

하지만 이런 다리를, 도구에만 갇히지 않고 사람이 이해할 수 있는 방식으로 어떻게 설계하고 유지할 수 있을까요?

여기서 아날로그, 스토리 기반 실천이 빛을 발합니다.

아날로그 장애 스토리 캐비닛이란 무엇인가

조직 어딘가 눈에 잘 띄는 곳에 놓인, 물리적이고 공유되며 저기술인 아티팩트를 상상해 보세요.

진짜 철제 서랍 캐비닛일 수도 있고,
클립보드로 가득한 벽일 수도 있고,
책장 한 칸을 채운 공책 묶음일 수도 있습니다.

각 파일, 카드, 혹은 페이지에는 하나의 장애 스토리가 담겨 있습니다.

무슨 일이 있었는지 (쉬운 문장, 최소한의 전문 용어)
누가 관여했는지 (팀, 역할, 타임존)
어떤 느낌이었는지 (헷갈린 지점, 놀람, 마찰)
팀 사이에 어떤 다리가 없었는지(혹은 불안정했는지)
우리가 무엇을 바꿨는지 — 시스템 자체 그리고 함께 일하는 방식 모두

이것이 바로 아날로그 장애 스토리 캐비닛의 다리들입니다. 로그인, 권한, “맞는 키워드” 검색이 없어도, 장애의 인간적인 경험이 기록·공유·재방문될 수 있는 공간입니다.

디지털 포스트모템 시스템을 대체하려는 것이 아닙니다. 대신 의도적으로 제한된, 병렬적인 뷰를 제공하는 장치입니다.

**지표보다 서사(narrative)**를 우선시하고,
스택 트레이스보다 팀 간 상호작용을 강조하며,
비기술 이해관계자도 배울 수 있게 만들어 줍니다.

종이로 다리를 손수 짓기: 실천 방법

이제 이 아이디어를 실제로 구현해, 장애 관리와 SRE 실천을 강화하는 방법을 단계별로 살펴보겠습니다.

1. 단순하고 반복 가능한 스토리 템플릿으로 시작하기

모든 장애 스토리가 반드시 한 장짜리(물리적으로도 종이 한 장) 안에 들어가도록 템플릿을 만드세요. 예를 들면 다음과 같습니다.

장애 이름 & 날짜
고객 영향 (간단한 문장 2–3개, 쉬운 언어)
관여한 시스템 & 팀
무엇이 우리를 놀라게 했는가? (깨진 가정들)
커뮤니케이션/조정이 어디서 막혔는가?
어떤 다리가 존재했고 잘 작동했는가? (프로세스, 관계, 공유 도구)
어떤 다리가 없었거나 너무 좁았는가?
두 가지 구체적 변화 (하나는 기술적, 다른 하나는 사회·프로세스적)

짧게 유지하세요. 이 제약이 서술을 더 명료하게 만듭니다.

2. 기존 포스트모템 실천과 연결하기

장애 프로세스를 처음부터 다시 만들 필요는 없습니다. 대신 아날로그 스토리를 기존 포스트모템의 얇은 슬라이스(thin slice) 로 만드세요.

디지털 포스트모템을 모두 끝낸 뒤, 팀이 함께 10분 정도 시간을 내어 한 장짜리 스토리를 작성합니다.
각 장애 리뷰마다 돌아가면서 맡는 “스토리 서기(story scribe)” 역할을 두세요.
작성한 페이지는 모두가 볼 수 있는 물리적 공간에 꽂거나 게시합니다.

몇 달, 몇 년이 지나면 이것이 장애와 학습의 손에 잡히는 타임라인이 됩니다.

3. 기술 팀만이 아니라, 팀 간을 위한 것으로 만들기

이 캐비닛을 다리 생성기로 활용하세요.

때때로 고객 지원, 프로덕트, 마케팅, 리더십을 포스트모템에 초대해 아날로그 스토리 작성에 함께 참여하게 합니다.
그들에게 묻습니다. “당신들 관점에서, 다리가 어디서 흔들렸나요?” 메시지였는지, 의사결정 지연이었는지, 고객 영향에 대한 불명확함이었는지 등.
그런 관점을 종이 한 장 안에 함께 기록합니다.

이렇게 하면 장애 대응과 예방이 단지 기술적 수정이 아니라, 전체 사회기술 시스템이 어떻게 작동하는가의 문제임을 강화해 줍니다.

4. 캐비닛을 정기적으로 다시 열어보기

캐비닛의 힘은 다시 여는 데서 나옵니다.

분기마다 한 번씩 “다리 리뷰(bridge review)” 미팅을 진행합니다. 그래프부터 보지 말고, 종이 스토리부터 시작하세요.
여러 장애 페이지를 책상이나 벽에 시간 순서대로 펼칩니다.
다음과 같은 팀 간 질문을 던집니다.
- 어떤 팀이 가장 많은 스토리에 등장하는가? 왜 그런가?
- 반복해서 빠져 있는 다리는 무엇인가? (예: 릴리스 커뮤니케이션, 특정 도메인의 관측 가능성 등)
- 어떤 변화 실험은 실제로 정착되었는가?

이 과정에서 더 큰, 시스템적 개선을 정의할 수 있습니다. 조직 차원의 런북, 더 명확한 에스컬레이션 경로, Ownership 정리, 공통 도구 개선 등이 그 예입니다.

5. 다음 장애 이전에 다리를 눈에 보이게 만들기

마지막 단계는 인사이트를, 다음 장애가 오기 전에 분명한 다리로 옮기는 것입니다.

캐비닛에서 발견한 패턴을 바탕으로 장애 대응 워크플로우를 업데이트합니다. 새로운 역할, 더 이른 시점의 타팀 개입, 더 명확한 핸드오프 등을 포함할 수 있습니다.
실제 협업 양상을 반영하도록 에스컬레이션 경로를 조정합니다. 단순한 조직도 기반이 아니라, 실제로 필요한 연결을 기준으로 설계합니다.
**팀 간 의식(ritual)**을 만들거나 다듬습니다. 사전 릴리스 리뷰, 합동 게임데이(game day), 공유 온콜 오피스 아워 같은 것들이 있습니다.

목표는 다음 장애가 터졌을 때, 대응자들이 “이 다리는 우리가 이미 한 번 걸어봤다”고 느끼게 하는 것입니다. “불길 속에서 관계를 처음 쌓는” 상태가 아니라요.

결론: 필요하기 전에 다리를 지어라

신뢰성은 장애 한가운데에서 만들어지지 않습니다. 그 순간에 드러날 뿐입니다.

DevOps와 SRE가 형성한 현대의 장애 관리는 다운타임을 줄이고 고객 신뢰를 지키기 위해 구조화된 포스트모템, 에스컬레이션 경로, 명확한 워크플로우 같은 강력한 실천을 제공합니다. 그러나 이런 실천이 진정한 힘을 발휘하는 순간은, 그것들이 사회기술 시스템 전반에 걸쳐 팀과 맥락, 관점을 이어 주는 다리로 작동할 때입니다.

아날로그 장애 스토리 캐비닛은 다음과 같은 일을 가능하게 해 주는 단순하지만 강력한 도구입니다.

포스트모템을 지속적인 학습의 의식으로 바꾼다.
장애의 인간적인 측면을 눈에 띄게 만들고, 이야기할 수 있게 한다.
장애가 시험하기 전에, 팀 간 다리를 설계하고 유지하도록 돕는다.

복잡하고 자동화된 분산 시스템이 일상이 된 지금, 종이와 펜을 꺼내는 일은 다소 구식처럼 느껴질 수 있습니다. 하지만 그렇게 손으로 만드는 아날로그 다리야말로 가장 중요한 것을 드러내는 경우가 많습니다. 시스템이 어떻게 실패하는지만이 아니라, 사람들이 그 실패 속에서 어떻게 함께 성공해 나가는지를 말입니다.

지금 그 다리들을 지으세요. 앞으로의 장애는 이미 오고 있습니다. 그리고 그 장애가 얼마나 감당할 만한 사건이 될지는, 지금 미리 준비해 둔 다리들에 의해 결정될 것입니다.