아날로그 인시던트 퀼트: 1년 치 장애에서 종이 단서를 꿰매는 법

대부분의 조직은 자신도 모른 채, 엄청난 신뢰성 인사이트 위에 앉아 있습니다.

그 인사이트는 대시보드나 APM 툴, 티켓 시스템에만 있는 게 아닙니다. 오히려 다음과 같은 지저분한 아날로그 산출물에 숨어 있습니다.

화이트보드에 휘갈겨 쓴 타임라인
워룸에서 붙였다 뗀 스티키 노트
허겁지겁 남긴 채팅 로그
여기저기 폴더에 흩어진 PDF 형식의 사후 인시던트 리뷰

각각만 놓고 보면, 이건 그저 종이 단서일 뿐입니다. 스트레스 가득했던 어느 날, 새벽의 불 끄기 전투에서 떨어져 나온 파편들입니다. 하지만 이것들을 의도적으로 하나로 꿰매기 시작하면, 제가 **아날로그 인시던트 퀼트(Analog Incident Quilt)**라고 부르는 것을 얻게 됩니다. 인시던트 하나하나를 넘어, 시스템이 실제로 어떻게, 왜 실패하는지를 보여주는 통합 뷰입니다.

이 퀼트는 단일 장애만 보면 절대 보이지 않는 반복 패턴, 시스템적 취약점, 블라인드 스폿을 드러내 줍니다.

이 글에서는 다음 내용을 다룹니다.

1년 치 종이 단서를 신뢰성에 대한 구조화된 뷰로 바꾸는 법
명확하고 실용적인 템플릿으로 사후 인시던트 리뷰를 표준화하는 법
인시던트 유형과 심각도에 맞게 리뷰 프레임워크를 조정하는 법
인시던트 라이프사이클 전 단계에 걸쳐 베스트 프랙티스를 적용하는 법
비상 대응 계획(특히 Azure 장애 플레이북 포함)을 수립·훈련하는 법
장애를 더 드물고 덜 고통스럽게 만들기 위해 프로세스를 지속적으로 다듬는 법

1단계: 퀼트 조각 모으기 — 1년 치 “종이 단서” 수집

패턴을 보려면 먼저 원재료가 필요합니다.

지난 12개월 동안, 인시던트 흔적은 어디에 쌓였나요?

Confluence나 Notion 페이지
PDF·Word 형식의 사후 인시던트 리포트
인시던트용 Slack/Teams 채널의 채팅 로그
Jira/ServiceNow 티켓
즉석에서 만든 Google Docs
이메일 스레드
화이트보드나 노트 필기를 찍은 사진

첫 작업은 단순합니다. 전부 한곳에 모으는 것입니다.

각 인시던트마다 고유한 자리를 가진, 단일 검색 가능한 저장소를 만들어 **인시던트 라이브러리(Incident Library)**를 만드세요. 품질이나 형식은 당장 신경 쓰지 마세요. 일단 퀼트 조각부터 모으는 게 우선입니다.

자료가 한데 모이면, 연초 인시던트 몇 건과 최근 몇 주 인시던트 몇 건을 랜덤으로 골라 훑어보세요. 아마 이런 점이 눈에 들어올 것입니다.

형식·상세 수준이 제각각인 보고서
빠진 타임라인, 모호한 영향(임팩트) 설명
실제로는 증상에 불과한 “루트 원인”
담당자와 기한이 없는 액션 아이템

이 들쭉날쭉함이 바로 기회입니다. 반복 패턴을 보려면 데이터가 일정해야 합니다. 여기서 표준화된 리뷰 템플릿이 필요해집니다.

2단계: 패턴 표준화 — 명확한 사후 인시던트 리뷰 템플릿

좋은 사후 인시던트 리뷰 템플릿은 두 가지를 해냅니다.

개별 인시던트를 이해하기 쉽게 만든다
인시던트 간 교차 분석을 실제로 가능하게 만든다

최소한 다음 핵심 섹션은 포함해야 합니다.

1. 타임라인(Timeline)

무슨 일이 어떻게 진행됐는지 시간 순서대로 정리합니다.

문제가 언제 시작됐는가? (첫 알림이 아니라, 첫 증상 기준)
언제 감지됐는가?
인시던트가 언제 선언·에스컬레이션·완화·해결됐는가?

여기서는 사실과 타임스탬프만 기록하세요. 해석이나 의견은 나중에 합니다.

2. 임팩트(Impact)

영향 범위와 심각도를 설명합니다.

어떤 시스템과 서비스가 영향을 받았는가?
고객 또는 내부 사용자 수는 얼마나 되는가?
고객이 실제로 경험한 현상은 무엇이었는가?
영향이 지속된 시간
영향을 받은 비즈니스 지표(매출, SLA, SLO 등)

이 섹션은 이 인시던트가 왜 중요했는지를 설명합니다.

3. 루트 원인(Root Cause)

무엇이 실제로 실패했는지에 대한 간결하고 기술적으로 정확한 설명입니다.

표면적인 트리거가 아닌, 근본적인 메커니즘에 집중합니다.
특히 개인에게 책임을 돌리는 표현은 피합니다.
직접 원인(무엇이 고장 났는가)과 시스템적 원인(왜 이런 방식으로 고장 날 수 있었는가)을 구분합니다.

"5 Whys"나 인과 관계 다이어그램 같은 도구가 도움 될 수 있지만, 복잡함보다 명료함이 우선입니다.

4. 기여 요인(Contributing Factors)

패턴이 드러나기 시작하는 지점입니다.

인시던트를 더 쉽게 일어나게 만들었거나, 더 심각하게 만들었거나, 해결을 어렵게 만든 모든 요인을 나열합니다. 예를 들면:

빠졌거나 시끄러운(노이즈 많은) 알림
불완전한 런북
위험한 배포 패턴
단일 장애 지점(Single Point of Failure)
부족한 Observability
지식 사일로

1년 치 인시던트를 모아 보면, 이런 요인들이 반복해서 등장할 것입니다. 이 반복이 바로 신뢰성 투자를 가장 크게 해야 할 지점입니다.

5. 액션(단기·장기) Actions (Short-Term and Long-Term)

다음 두 가지를 분리해서 적습니다.

즉각적인 복구 조치: 서비스를 복원하기 위해 무엇을 했는가
후속 조치: 재발을 막거나 영향을 줄이기 위해 무엇을 할 것인가

각 액션마다 다음을 명확히 합니다.

담당자(Owner)
마감일(Due date)
기대 효과에 대한 명확한 설명

후속 조치가 실제로 완료되지 않는다면, 인시던트 프로세스는 그냥 이야기 나누기로 끝납니다. 액션 섹션이 인사이트를 실제 변화로 연결해 줍니다.

6. 교훈(Lessons Learned)

마지막으로, 사람 중심·실무 중심의 섹션입니다.

예상 밖이었던 점은 무엇인가?
탐지·대응·커뮤니케이션 측면에서 잘 작동한 점은?
우리를 느리게 하거나 혼란스럽게 만든 것들은?
앞으로도 꼭 계속해야 할 일, 다시는 하지 말아야 할 일은?

이 섹션은 솔직하지만 비난 없는 분위기여야 합니다. 목적은 사람을 벌주는 게 아니라, 시스템과 프로세스를 조정하는 것입니다.

3단계: 모든 인시던트가 똑같을 수는 없다 — 프레임워크 조정

모든 인시던트가 같은 수준의 의식을 요구하는 것은 아닙니다.

5분짜리 사소한 장애에도 매번 무거운 전체 리뷰를 강제하면, 사람들은 조용히 빠져나가거나 형식적으로만 작성하게 됩니다. 반대로, 대규모 장애에 가벼운 리뷰만 하면, 시스템적 실패 모드를 놓치게 됩니다.

따라서 인시던트 유형과 심각도에 맞게 사후 리뷰 프레임워크를 조정해야 합니다.

경미한 인시던트 (예: Sev 3/4)
- 짧은 템플릿 사용
- 타임라인·임팩트·간단한 루트 원인·1~2개의 액션에만 집중
- 15~30분 리뷰
중간 수준 인시던트
- 풀 템플릿 사용하되, 시간은 타임박싱
- 온콜 엔지니어와 서비스 오너 참여
- 45~60분 리뷰
중대 인시던트 (예: Sev 1/2, 클라우드 프로바이더 전체 장애 등)
- 심층 분석용 풀 템플릿 사용
- 엔지니어링, 프로덕트, 지원, 리더십 등 크로스팀 이해관계자 참여
- 퍼실리테이터가 진행하는 블레임리스 회고를 고려
- 60~90분 리뷰

강조점도 상황에 따라 달라질 수 있습니다. 예를 들어, 보안 인시던트라면 정보 공개와 포렌식 섹션을 추가할 수 있고, 용량 관련 인시던트라면 수요 예측·스케일링 의사결정에 더 많은 비중을 둘 수 있습니다.

핵심은 각 인시던트 클래스 내에서의 일관성입니다. 그래야 인시던트 간 비교가 의미를 갖습니다.

4단계: 라이프사이클 전체 강화 — 탐지부터 회고까지

장애 신뢰성은 사후 리포트만의 문제가 아닙니다. 뛰어난 팀은 인시던트 관리의 모든 단계를 개선 가능한 영역으로 봅니다.

탐지(Detection)
- 알림이 충분히 일찍 울리는가?
- 알림은 구체적이고 실행 가능하며, 노이즈가 적은가?
- 필요한 메트릭·로그·트레이스를 제대로 보고 있는가?
대응(Response)
- Incident Commander 역할이 명확한가?
- 온콜 로테이션이 건강하고 지속 가능하게 운영되는가?
- 대응자들이 런북과 체크리스트 위치를 알고 있는가?
커뮤니케이션(Communication)
- 상태 업데이트가 정기적이고 예측 가능한가?
- 이해관계자에게 제공되는 단일 소스 오브 트루스가 있는가?
- 고객 공지는 시기적절하고, 정확하며, 지나친 전문 용어를 쓰지 않는가?
회고(Retrospectives)
- 리뷰가 실제로 열리고, 제때 진행되는가?
- 정말로 블레임리스하게 진행되는가?
- 액션 아이템이 끝까지 추적·완료되는가?

1년 치 종이 단서를 활용해 각 단계에 대해 스스로를 평가해 보세요. 예를 들어, 각 인시던트에 poor-detection, great-communication, slow-response 같은 라벨을 붙이는 방식입니다. 시간이 지나면, 명확한 트렌드가 드러날 것입니다.

5단계: “큰 것”에 대비하기 — 비상 계획과 클라우드 프로바이더 장애

어떤 인시던트는 여러분 시스템의 범위를 넘어섭니다.

Azure 리전 장애 같은 클라우드 프로바이더 장애는 여러 서비스를 한 번에 쓰러뜨릴 수 있습니다. 이런 사건은 막을 수 없지만, 어떻게 대응할지는 미리 정해 둘 수 있습니다.

다음과 같은 **비상 대응 계획(Contingency Plan)**을 수립하고 정기적으로 테스트하세요.

Azure 장애 플레이북(Azure outage playbooks)
- 특정 리전이 성능 저하 상태라면 어떻게 할 것인가?
- Azure AD와 같은 아이덴티티 서비스가 불가능하다면?
- SQL Database, Storage, Service Bus 같은 핵심 Managed Service가 다운된다면?
Failover 및 Degradation 전략
- 멀티 리전 또는 멀티 존 배포
- 완전한 다운타임 대신 기능 축소(Graceful Degradation)
- 읽기 전용 모드 또는 제한 용량 모드
운영 연속성(Operational Continuity)
- 주요 도구(예: 메인 채팅 툴, CI/CD 플랫폼)가 영향을 받으면 팀은 어떻게 협업할 것인가?
- 중요한 런북에 오프라인 또는 대체 접근 경로가 있는가?

그다음, 대규모 프로바이더 장애도 다른 인시던트와 마찬가지로 다루세요.

풀 사후 인시던트 리뷰 진행
플레이북에서 잘 된 점·문제된 점을 모두 기록
그에 따라 비상 대응 계획 업데이트

목표는 완전 무적이 되는 것이 아니라, 스트레스 상황에서도 예측 가능하게 회복력 있는 상태를 유지하는 것입니다.

6단계: 살아있는 퀼트로 만들기 — 지속적인 개선 루프

아날로그 인시던트 퀼트의 진정한 힘은 1년 치를 한 번에 회고하는 데 있지 않습니다. 이 퀼트가 만들어내는 지속적인 피드백 루프에 있습니다.

표준화된 리뷰와 중앙 인시던트 라이브러리가 준비되면, 다음이 가능해집니다.

분기별 패턴 리뷰
- 어떤 기여 요인이 가장 자주 등장하는가?
- 어떤 시스템이나 팀에서 가장 심각한 인시던트가 많이 발생하는가?
- 여러 인시던트에 반복적으로 등장하는 액션은 무엇인가?
시스템적 개선에 우선순위 부여
- 다양한 실패에 공통으로 도움이 되는 알림·Observability·자동화에 투자
- 소유권 불명확, 핵심 서비스 인력 부족 같은 조직적 문제 해결
시간에 따른 개선 측정
- 탐지까지 걸리는 평균 시간(MTTD)
- 복구까지 걸리는 평균 시간(MTTR)
- 인시던트 발생 빈도와 심각도 분포
- 완료된 액션 아이템 비율

이 인사이트를 엔지니어링 로드맵에 반영하세요. 신뢰성 개선 작업은, 개별 사례가 아니라 1년 치 인시던트 데이터를 근거로 설명할 수 있을 때 훨씬 설득력이 커집니다.

결론: 흩어진 단서에서 신뢰성 스토리로

장애는 스트레스가 크지만, 동시에 시스템 생애 주기에서 가장 정보가 풍부한 순간이기도 합니다.

각 인시던트 리포트가 고립된 채 생성되고 잊힌다면, 그 값비싼 교훈을 버리는 셈입니다. 반대로, 흩어진 메모를 모으고, 분석 방식을 표준화하고, 정기적으로 전체를 되짚어 보면, 아날로그 인시던트 퀼트를 만들 수 있습니다. 압박 속에서 시스템이 실제로 어떻게 동작하는지 보여주는, 꿰매어진 하나의 이야기입니다.

이 이야기에서 우리는 다음을 해낼 수 있습니다.

반복 패턴과 시스템적 취약점을 찾아내기
탐지·대응·커뮤니케이션·회고를 개선하기
대규모 프로바이더 장애에 대비한 견고한 비상 계획을 세우기
프로세스와 아키텍처를 지속적으로 다듬기

완벽한 툴이나 비싼 플랫폼이 꼭 필요한 건 아닙니다. 필요한 것은 단 하나, 인시던트를 고통의 원인이 아니라 진실의 원천으로 대하는 태도입니다. 그리고, 새로운 종이 단서가 생길 때마다, 우리가 살아남은 모든 장애를 발판 삼아 더 단단해지는 퀼트에 한 조각씩 성실히 꿰매 넣는 일입니다.