아날로그 장애 스토리 컴퍼스 퀼트: 실패를 함께 쓰는 신뢰성 지도

디지털 시스템의 장애는 놀라울 만큼 아날로그한 방식으로 사람들을 덮칩니다.

의료 기록 시스템이 멈추면 환자는 약을 제때 받지 못하고, 검사 결과는 지연되며, 지친 간호사들은 어두운 복도에서 클립보드로 임기응변을 합니다. 사회보장·복지 포털이 다운되면 가족들은 몇 시간씩 줄을 서거나, 결국 식비 지원을 못 받은 채 집으로 돌아갑니다. 전력회사의 디스패치 애플리케이션이 실패하면, 폭풍 속에서 현장 팀은 거의 눈을 가린 채로 복구 작업을 진행해야 합니다.

하지만 대부분의 조직에서 이런 사건은 그저 **“개별 인시던트”**로만 기억됩니다. 티켓 번호 하나, 에러 그래프의 스파이크 하나, 공동 드라이브 어딘가에 묻힌 포스트모텀 문서 하나로요.

**아날로그 장애 스토리 컴퍼스 퀼트(Analog Outage Story Compass Quilt)**는 이런 실패를 바라보는 전혀 다른 방식입니다. 여러 곳에 흩어져 있는 장애 스토리를 모아, 말 그대로 종이 위에 **바느질하듯 엮어 하나의 ‘공유되는 시각적 신뢰성 지도’**로 만드는 실천입니다. 은유이자 방법론으로서, 인시던트 스토리들로 만든 물리적인 퀼트가 곧 어디에 탄탄함과 회복탄력성을 투자해야 하는지 알려주는 나침반이 됩니다.

이 접근법의 중심에는 대시보드가 아니라 사람이 있습니다. 각 장애를 실제 결과를 낳는 하나의 이야기로 대하고, 그 이야기를 다시 정교한 신뢰성 분석을 위한 데이터로 활용합니다. 그 결과는 팀이 둘러서서 함께 가리키고, 논쟁하고, 배우고, 수정해 나갈 수 있는, 살아 있는 아날로그 아티팩트가 됩니다.

왜 ‘아날로그 신뢰성 지도’가 필요한가

특히 의료, 사회복지, 공공요금·에너지, 공공 인프라와 같은 중요한 영역에서, 일선 실무자와 시민은 기술에 반대하는 사람들이 아닙니다. 오히려 많은 경우 디지털 전환의 열렬한 지지자입니다.

간호사는 반복 클릭을 줄이고, 환자와 더 많은 시간을 보내고 싶어 합니다.
사례관리자는 복잡한 케이스 파일을 열 때마다 시스템이 멈추지 않기를 바랍니다.
환자들은 검사 결과와 예약을 온라인으로 확인할 수 있는 걸 좋아합니다.

그런데 소프트웨어가 실패하는 순간, 그 피해를 직접 떠안는 사람들도 바로 이들입니다.

전자의무기록(EHR)이 다운되어, 의사가 약물 알레르기 정보를 확인하지 못합니다.
사례관리 시스템이 멈춰, 사회복지사가 약속을 취소해야만 합니다.
온라인 포털이 타임아웃 후 신청서를 날려버려, 한 부모가 콜센터 대기만 몇 시간을 합니다.

상태 대시보드에서 이런 일은 다음과 같이 보입니다.

43분 장애 발생
2.3% 에러율
HTTP 500 에러 스파이크

하지만 실제 삶에서는 이것이 곧

놓친 진단
한 주치의 소득 상실
안전하지 않은 주거 환경에서 보내는 밤이 하루 더 늘어남

이 됩니다.

기술적 지표만으로는 이 현실이 납작해집니다. 대시보드는 돌려막기, 창의적인 우회, 시스템이 무너지는 동안에도 서비스를 이어가려 애쓰는 이들의 감정적 노동과 도덕적 상처를 보이지 않게 만듭니다.

아날로그 장애 스토리 컴퍼스 퀼트는 이 숨겨진 차원을 억지로라도 보게 만듭니다.

흩어진 인시던트에서 하나의 퀼트로

대부분의 조직은 이미 장애 데이터를 수집하고 있습니다.

인시던트 티켓
온콜 페이저 알림
포스트모텀 문서
신뢰성 대시보드

하지만 이 정보는 대개

여러 툴에 흩어져 있고
작성 양식과 스타일이 제각각이며
기술 중심이고, 실제 영향은 제대로 담지 못하고
시간이 지나도 비교·학습하기 어렵습니다.

“퀼트” 접근법은 이런 인시던트를 공통된 아날로그 형식으로 바꾸어, 모두가 볼 수 있는 공간에 함께 걸어두는 것에서 출발합니다. 각 장애는 일정한 템플릿을 가진 종이 패치 한 장이 됩니다.

이름 & 날짜
사람이 알아보기 쉬운 제목과 발생 기간.
맥락(Context)
그때 어떤 상황이었는지 (예: “지역 병원 야간 근무”, “매월 1일 복지 신청 폭주”).
타임라인
중요한 사건들을 시간 순으로 기록: 감지, 진단, 우회 조치, 복구, 후속 조치.
근본 원인 분석(Root Cause Analysis)
단순히 “뭐가 고장 났는지” (예: DB 인덱스 문제)를 넘어서, 왜 그런 방식으로 고장 날 수 있었는지를 다룹니다.
- 테스트의 공백
- 위험한 배포 패턴
- 부족한 관측성(observability)
- 인력 부족한 온콜 로테이션
인간적 영향(Human Impact)
구체적인 결과를 적습니다.
- 누가 영향을 받았는지 (환자, 직원, 클라이언트, 현장 요원 등)
- 그들이 무엇을 다르게 해야 했는지
- 무엇이 지연되거나, 더 어려워졌거나, 아예 불가능해졌는지
액션 아이템(Action Items)
명확한 책임자와 기한이 있는 변화들:
- 기술적 수정
- 프로세스 개선
- 교육·문서 보완
- 정책·인력 관련 조정

각 패치는 하나의 이야기일 뿐입니다. 하지만 이런 패치가 수십 장씩, 색깔 코드를 붙이고, 묶어서, 주석을 더해 벽에 걸리기 시작하면, 그 순간부터 이것은 하나의 지도로 변합니다.

패턴이 눈에 띄기 시작합니다.

특정 서비스나 벤더에 집중되는 장애
반복되는 실패 양상 (예: 금요일 오후 배포 후 장애)
특정 신뢰성 통제에 대한 만성적 투자 부족
늘 같은 집단에 반복되는 피해 (야간 근무자, 농어촌 지점, 비(非)모국어 사용자 등)

이렇게 만들어진 것이 바로 **컴퍼스 퀼트(Compass Quilt)**입니다. 수많은 실패를 한 땀 한 땀 이어 만든 시각적 신뢰성 지도로, 다음 투자를 어디에 해야 하는지 방향을 알려줍니다.

사람 이야기 + 엄격한 신뢰성 분석

서사에만 집중하면, 이야기가 단편적인 에피소드 수준에 머무르거나, 특정인에게 책임을 떠넘기는 장으로 변질될 위험이 있습니다.

아날로그 장애 스토리 컴퍼스 퀼트의 힘은, 이 작업이 다음을 함께 결합한다는 데 있습니다.

정성적 장애 스토리
실제 이름, 현장 인용, 일선 실무자의 시선을 담은 이야기.
구조화된 신뢰성 분석
반복 가능한 포스트모텀 템플릿과 근본 원인 분석 기법을 활용한 분석.

이 두 가지가 결합되면 팀은 다음과 같은 일을 할 수 있게 됩니다.

그냥 지나쳤을 패턴을 발견
- 서로 무관해 보였던 네 개 인시던트에 모두 같은 서드파티 API가 얽혀 있는 것.
- 3년 전의 인력·조직 결정이, 지금 반복적으로 장애의 선행 요인이 되고 있는 것.
- 특정 환경 설정 하나가 지속적으로 연쇄 장애(cascading failure)에 기여하고 있는 것.
인시던트 리뷰를 팀마다 재발명하지 않기
팀마다 제각각 포스트모텀 양식을 쓰면, 학습이 흩어집니다. 퀼트는 스토리 수집 방식을 표준화하여, 서로 비교하기 쉽게 만듭니다.
- 공통 필드
- 비슷한 수준의 상세도
- 원인과 영향에 대한 공유 언어
시스템 수준의 개선에 우선순위 부여
가장 시끄럽거나, 가장 최근의 인시던트에만 반응하는 대신, 다음과 같은 방식으로 결정할 수 있습니다.
- 동일 근본 원인을 공유하는 장애 수를 세어 보고,
- 각 사용자 그룹에 가해진 피해를 합산해 보고,
- 어떤 신뢰성 통제가 여러 패치에서 계속 빠져 있는지 확인해 보는 것.

이때 퀼트는 동시에 감정적 진실을 드러내는 도구이자, 데이터 아티팩트가 됩니다.

비난 없이 배우기: 포스트모텀 템플릿

장애 스토리를 벽에 그냥 걸기만 하면, 특히 압박 속에서 임기응변을 해야 했던 일선 직원들은 노출감과 불안을 느낄 수 있습니다.

그래서 퀼트는 반드시 블레이멀리스(blameless), 구조화된 포스트모텀 템플릿에 의존해야 합니다. 각 패치는 개인의 잘못이 아니라 시스템의 행동을 다룬다는 점을 명확히 해야 합니다.

효과적인 템플릿에는 보통 다음이 포함됩니다.

명확한 타임라인
무엇이, 언제, 어떻게 발견·대응되었는지.
복수의 기여 요인
진짜로 단일 ‘루트 원인’만 존재하는 경우는 거의 없습니다. 좋은 패치는 다음을 함께 나열합니다.
- 기술적 조건 (예: 서킷 브레이커 없음, 레이트 리밋 미구현)
- 조직적 조건 (예: 인력 부족 팀, 촉박한 마감)
- 설계 결정 (예: 중요한 벤더와의 취약한 연동 구조)
카운터팩추얼(Counterfactuals)
무엇이 있었다면 이 장애를 예방하거나 피해를 줄일 수 있었을지.
구체적인 액션 아이템
각각에 대해
- 책임자
- 마감일
- 진행 상태
후속 점검 루프
액션 아이템이 완료될 때마다 퀼트도 함께 업데이트합니다.
- “이 패치는 5개 중 3개의 완화 조치가 완료되었습니다.”
- “여기에 모니터링을 추가했습니다. 새 그래프는 여기에서 볼 수 있습니다.”

이 템플릿을 표준화하면, 조직은 모든 장애를 처벌이 아닌 학습의 구조화된 기회로 바꿀 수 있습니다.

예방 가능한 피해, 예방 가능한 장애

퀼트가 가장 명확하게 보여주는 진실 중 하나는, 생각보다 많은 것이 충분히 예방 가능했다는 점입니다. 상당수 장애와 그로부터 파생된 피해는 ‘불가항력’이 아니라, 여러 선택의 결과입니다.

약하거나 부재한 신뢰성 기준·표준
충분한 테스트 없이 서둘러 진행한 배포
미비한 **관측성(observability)**과 알림 체계
들쭉날쭉한 운영 규율(operational discipline)
예산 부족·과부하로 인한 유지보수 소홀

“사전 부하 테스트(pre-production load testing) 없음” 또는 “벤더 X 단일 장애점(SPoF)”이 적힌 패치가 열 장쯤 벽에 걸려 있으면, 더 이상 이것을 개별 사고로 치부하기 어렵습니다.

대신 퀼트는 이런 대화를 가능하게 합니다.

“같은 DB 제약 조건 때문에 연쇄 장애가 난 스토리가 다섯 건입니다.”
“지난 1년간 야간 근무자가 가장 큰 피해를 본 인시던트가 세 건입니다.”
“농어촌 클리닉 백업 회선에 대해, 우리가 반복적으로 투자를 미루어 왔습니다.”

이런 대화는 자연스럽게 로드맵과 예산으로 이어집니다. 퀼트는 곧 나침반이 됩니다.

지금 우리가 취약한 곳은 어디인가?
피해가 집중된 곳은 어디인가?
돈과 시간을 어디에 쓸 때 신뢰성 향상 효과가 가장 큰가?

우리 조직의 컴퍼스 퀼트, 이렇게 시작하기

이 작업을 시작하는 데 거창한 혁신 프로그램은 필요 없습니다. 작고 손에 잡히는 것부터 시작하면 됩니다.

벽을 하나 정합니다
사람들이 실제로 자주 지나는 복도, 팀룸, 공유 오피스 한쪽이면 충분합니다.
한 페이지짜리 장애 템플릿을 만듭니다
간결하게 유지합니다: 제목, 날짜, 맥락, 타임라인, 근본 원인, 인간적 영향, 액션 아이템.
과거 인시던트 5–10개를 모읍니다
기존 포스트모텀이나 티켓을 패치로 재구성합니다. 인쇄해서 종이로 만듭니다. 그리고 벽에 붙입니다.
일선 목소리를 초대합니다
간호사, 사례관리자, 디스패처, 콜센터 직원에게 다음과 같은 메모를 추가해 달라고 부탁합니다.
- “당시 우리가 느낀 건 이랬습니다.”
- “그래서 이렇게 대응할 수밖에 없었습니다.”
최소한의 구조를 더합니다
색깔이나 태그를 사용해 다음을 표시합니다.
- 애플리케이션/서비스명
- 실패 유형 (성능, 가용성, 데이터, UX 등)
- 가장 큰 영향을 받은 사용자 그룹
정기적으로 퀼트를 리뷰합니다
회고, 아키텍처 리뷰, 계획 수립 회의 때 실제로 그 벽 앞으로 가서 이야기합니다.
- “요즘 어떤 테마가 눈에 띄나요?”
- “아직 처리되지 않은 액션 아이템은 무엇인가요?”
- “이번 달에 새로 추가할 패치는 무엇인가요?”

시간이 지나면 벽은 점점 채워집니다. 그럴수록 패턴을 외면하기는 어려워지고, 그것을 바꾸기 위한 투자를 정당화하기는 쉬워집니다.

결론: 퀼트를 한 땀씩 이어, 회복탄력성으로

아날로그 장애 스토리 컴퍼스 퀼트는 로그, SLO(Service Level Objective), 인시던트 관리 툴을 대체하는 도구가 아닙니다. 이 모든 것을 보완하면서, 장애의 인간적 결과를 신뢰성 작업의 중심으로 끌어오는 역할을 합니다.

실패의 종이 패치를 한 땀씩 이어 붙이고, 각 패치를 비난이 아닌 학습을 위한 구조화된 이야기로 다루면, 다음과 같은 것을 얻게 됩니다.

기술·비기술 팀이 함께 쓸 수 있는 공유 인시던트 언어
시스템이 어디에서 취약하며, 그 취약성이 누구를 다치게 하는지 보여주는 시각적 지도
신뢰성 기준, 운영 규율, 장기 투자 방향을 잡아주는 나침반

무엇보다도, 퀼트는 우리에게 신뢰성은 소프트웨어의 추상적인 속성이 아니라, 그 소프트웨어에 기대어 가장 취약한 순간을 버텨내는 사람들에게 한 약속임을 상기시킵니다.

우리는 장애를 티켓과 로그 속으로 사라지게 두지 않을 때, 그리고 그 이야기를 함께 마주 보고, 충분히 오래 앉아서 배울 때, 비로소 그 약속을 지켜 나갈 수 있습니다.