아날로그 인시던트 스토리 도면 서랍: 다음 온콜 리모델링 전에 종이 위에 그려보는 실패의 평면도

인시던트는 시스템이 스스로에게 보내는 아키텍처 피드백이다.

그 피드백을 무시하고 갈라진 틈만 메우면서 버틸 수도 있고, 매 장애를 시스템(과 팀)이 실제로 어떻게 돌아가는지 도면을 다시 그려볼 기회로 삼을 수도 있다.

이 글은 다소 옛날스럽지만 단순한 아이디어 하나에 대한 이야기다: 인시던트를 그림으로 그려라.

펜과 종이를 꺼내서 실제로 무슨 일이 있었는지 스케치해 보라. 마치 구조적 붕괴가 난 건물의 평면도를 새로 그리듯이. 그런 다음, 그 아날로그 도면을 사용해 온콜 문화를 조용히, 한 번의 인시던트씩 리모델링해 나가라.

포스트모템은 체크리스트가 아니라 문화 변화다

포스트모템을 새로 도입하거나(혹은 망가진 포스트모템 문화를 고치려 할 때), 이걸 단순히 또 하나의 기술적 실천(practice) 정도로 취급하기 쉽다.

• “콘플루언스 템플릿 하나 추가하죠.”
• “루트 코즈(root cause)랑 액션 아이템만 적도록 하죠.”
• “지라(Jira) 이슈로 추적하면 되겠네요.”

이건 변화가 아니라 서류 작업이다.

실제로 당신이 조직에 요구하는 건, 실패를 바라보는 관점 자체를 바꾸자는 것이다.

• 창피한 사고 → 예상 가능하고 들여다볼 수 있는 신호
• 개인의 잘못 → 시스템의 제약과 구조적 한계
• 다시는 안 일어나기만을 바람 → 다음에는 더 탄탄해지기 위한 재료

이건 문화의 문제다.

그리고 문화는 새 템플릿을 배포했다고 바뀌지 않는다. 사람들이 인시던트를 둘러싼 행동 양식이 실제로 달라지는 경험을 반복해서, 일관되게, 안전하게 했을 때 바뀐다.

그 지점에서 작고, 아날로그이고, 시각적인 인시던트 리뷰가 힘을 발휘한다.

“시스템이 알아서 나아지겠지”라는 희망은 버려라

인시던트가 끝난 뒤, 슬며시 스며드는 안일한 거짓말이 있다.

“버그 패치했고 대시보드도 하나 만들었으니까, 이제 괜찮겠지.”

실제로 일어난 일은 이렇다.

• 구조가 아니라 증상만 다뤘다.
• 코드 경로 하나는 바꿨지만, 사회·기술(socio-technical) 시스템 전체는 그대로 두었다.
• 시스템이 그 패치로부터 “학습하길” 희망했을 뿐이다.

시스템은 희망으로부터 배우지 않는다.

사람들이 의도적으로 실패가 어떻게 전파되었는지 분석하고, 그에 맞게 가드레일, 피드백 루프, 역할과 책임을 다시 설계할 때 비로소 배운다.

의도적인 분석 없이 한다면, 그저 랜덤 시드만 조금 바꿔서 주사위를 다시 던지는 것과 다를 바 없다.

작게 시작하라: 가벼운 인시던트 리뷰

처음부터 거대한 “포스트모템 프로그램”을 출범시키기보다는, 팀이 실제로 지속할 수 있는 작은 인시던트 리뷰부터 시작하라.

다음과 같은 형태를 목표로 삼을 수 있다.

• 자격을 갖춘(= 일정 기준을 넘는) 인시던트마다 30–45분
• 인시던트 발생 후 영업일 기준 1–3일 내 진행
• 인원은 최대 6–8명: 대응자들 + 퍼실리테이터 1명
• 결과물: 1페이지 분량의 요약 문서 + 1장의 아날로그 스케치

끝이다. 복잡한 분류 체계도, 여섯 개의 위원회도, 즉석 자동화도 필요 없다.

왜 이렇게 작게 가야 할까?

• 저항을 줄인다. 거대한 심문 절차처럼 느껴지지 않는 뭔가는 사람들이 훨씬 쉽게 시도한다.
• 반복을 늘린다. 작게 설계하면 더 자주, 더 많이 리뷰를 돌릴 수 있고, 이는 곧 습관이 되고 문화가 된다.
• 개선이 눈에 보인다. 포맷이 작고 단순하면, 프로세스를 조금씩 바꿔보며 실험하기가 훨씬 쉽다.

지금 만드는 건 “최종 완성형 포스트모템 프로세스™”가 아니다. 처음으로 안전하게, 반복 가능하게 밟을 수 있는 한 걸음이다.

엔지니어링이 주도하는 인시던트 대응 프레임워크를 쓰라

일관성은 중요하다. 인시던트마다 대응 방식이 제각각이면, 배움은 쌓이지 않는다.

인시던트 대응과 리뷰 모두에 쓸 수 있는 단순하고 엔지니어 주도적인 프레임워크를 하나 정하라. 예를 들면 다음과 같다.

1. 인시던트 선언(Declare)

   • 명확한 심각도 티어(SEV-1, SEV-2 등)를 사용한다.
   • 인시던트 커맨더(Incident Commander, IC)를 한 명 지정한다.

2. 시스템 안정화(Stabilize)

   • 먼저 피를 멈춘다(롤백, 피처 플래그, 페일오버 등).
   • 실시간으로 가벼운 이벤트 로그를 남긴다. (예: “10:32에 X 롤백 실행”)

3. 커뮤니케이션(Communicate)

   • 단일 상태 공유 채널(또는 룸)을 쓴다.
   • SEV-1 같은 중대 장애라면 15–30분 간격으로 정기 업데이트를 올린다.

4. 즉시 문서화(Document)

   • 인시던트 직후, IC가 이벤트 로그를 토대로 타임라인을 정리한다.
   • 무얼로 보이는지에 대한 짧은 가설을 적어 둔다. (틀려도 상관없다.)

5. 리뷰(Review)

   • 대응자들과 작은 리뷰 미팅을 잡는다.
   • 함께 아날로그 “실패 평면도”를 그려본다.

핵심은 “완벽한 프레임워크”를 갖추는 게 아니다. 누구나 이해하고 가르칠 수 있는 공통 패턴이 있어서, 모두가 방향을 잃지 않고 움직이게 하고, 그 결과가 리뷰에 좋은 입력으로 이어지게 만드는 것이 중요하다.

아날로그 도면: 인시던트의 평면도 그리기

디지털 도구는 훌륭하지만, 학습 단계에서는 종종 복잡성을 줌 레벨과 탭 뒤에 숨겨 버린다.

종이는 그렇지 않다.

리뷰 시간에는 잠시 대시보드를 치우고 다음을 준비하라.

• 종이 한 장(또는 화이트보드)
• 굵은 마커
• 있다면 포스트잇

그리고, 부분 붕괴가 일어난 건물의 평면도를 그리듯 인시던트를 스케치한다.

무엇을 그릴까

1. 방(Room) = 주요 컴포넌트 또는 도메인

   • 서비스, 외부 의존성, 데이터베이스, 큐, 사용자 진입 지점 등.
   • 각각을 사각형/방으로 그리고, 쉬운 한국어 이름으로 라벨링한다. (예: “체크아웃 API”, “검색 인덱스”, “결제 프로바이더”)

2. 문과 복도 = 상호작용

   • 요청, 이벤트, 데이터 플로를 화살표나 복도로 표현한다.
   • 방향을 표시한다. (누가 누구를 호출하는지, 누가 누구에게 의존하는지)

3. 사람 = 액터와 역할

   • 온콜 엔지니어, SRE, 고객 지원, 고객 등.
   • 문제가 터졌을 때 이 “건물”의 어디에 있었는지, 누가 언제 무엇을 처음 알아챘는지 표시한다.

4. 피해 구역 = 실패 지점

   • 첫 번째로 관측 가능한 실패가 어디에서 나타났는가?
   • 실제로는 어디에서 기원했는가?
   • 연쇄적인 영향이 일어난 구역을 강조해서 표시한다.

5. 안전 장치 = 있었던(혹은 있었어야 하는) 보호 장치들

   • 서킷 브레이커, 레이트 리밋, 폴백, 플레이북, 런북 등.
   • 무엇은 잘 작동했고, 무엇은 없었고, 무엇은 있는 줄도 몰랐는지 적어둔다.

스케치를 어떻게 활용할까

그리면서 이런 질문을 던져보라.

• 현실은 우리의 멘탈 모델과 어디에서 달랐는가?
• 정보는 어디에서 너무 느리게, 혹은 아예 전달되지 않았는가?
• 무엇이 이 인시던트를 불필요하게 더 크게 키웠는가?

아날로그 스케치는 공유된 스토리 아티팩트가 된다. 사람들은 실제로 손가락으로 가리키며 오해를 짚어낼 수 있다.

“저는 여기서 웹 앱이 바로 DB랑 통신하는 줄 알았어요.”
“잠깐, 저 큐가 세 개 컨슈머로 팬아웃된다고요?”

이런 놀라움이야말로 금광이다. 바로 그 지점에 리질리언스 작업이 숨어 있기 때문이다.

스케치를 사진으로 찍어 인시던트 리뷰 문서에 첨부하라. 예쁘게 잘 그릴 필요는 없다. 중요한 건 정직하게 그렸느냐다.

비난 금지, 리질리언스 중심으로

리뷰 자리가 재판처럼 느껴지기 시작하면, 그 문화는 곧 사라진다.

다음 원칙을 명시적으로 합의하라.

• 비난 금지, 망신 주기 금지. 사람들의 행동은 그들이 알고 있던 것과 그때의 제약 조건 아래에서라면 충분히 합리적이었다고 간주한다.
• 개인의 잘못이 아니라 시스템의 기여를 찾는다.
• 처벌이 아니라 학습을 최대화하는 방향으로 최적화한다.

구체적으로는 다음을 의미한다.

• “휴먼 에러(human error)”를 루트 코즈로 금지한다. 대신 묻는다: 왜 그런 실수를 하기가 그렇게 쉬웠는가?
• “누가 망쳤나?” 대신 “무엇이 이런 결과를 일어나기 쉽게 만들었나?”를 묻는다.
• 개인에게 나사 조이기를 하는 대신, 스트레스 상황에서도 성공적으로 대응할 수 있는 행동의 범위를 넓히는 방법에 집중한다.

리질리언스를 키우는 데 도움이 되는 질문들:

• 이걸 더 일찍 탐지할 수 있으려면 어떻게 했어야 할까?
• **블라스트 레이디우스(영향 범위)**를 더 작게 만들려면 무엇이 필요할까?
• 다음에 비슷한 인시던트가 나더라도, 처리 과정이 훨씬 지루할 정도로 평범해지려면 무엇을 바꿔야 할까?

이런 질문들에서 나올 수 있는 결과물 예시:

• 더 나은 가드레일(피처 플래그, 더 안전한 배포 패턴 등)
• 더 명확한 소유 범위와 경계
• 방금 겪은 인시던트를 활용한 온콜 트레이닝 시나리오

사람들이 리뷰가 반복해서 더 좋은 도구, 더 인간적인 프로세스, 더 넓은 공유 이해로 이어지는 걸 직접 경험하게 되면, 실수를 숨기기보다 더 빨리 드러내기 시작한다.

그게 바로 문화 변화다.

문화가 성숙해질수록, 그에 맞춰 점진적으로 자동화하라

첫날부터 완전히 자동화된 포스트모템 파이프라인이 필요하지는 않다.

대신, 실천(practice)이 문화와 함께 진화하도록 두라.

1. 1단계 – 수동, 아날로그 중심

   • 단순한 엔지니어링 주도 프레임워크 사용.
   • 종이 또는 화이트보드로 인시던트 도면을 그린다.
   • 짧은 요약 문서를 남긴다.

2. 2단계 – 반복 가능한 패턴 정착

   • 실제로 써 본 포맷을 바탕으로 표준 템플릿을 만든다.
   • 공통 질문 세트와 기본 지표들을 정한다.
   • 인시던트 유형에 대한 가벼운 분류 체계를 도입한다.

3. 3단계 – 타겟을 정한 자동화

   • 타임라인, 로그, 메트릭을 자동으로 일부 채워 주는 도구들을 도입한다.
   • 이전 인시던트에서 얻은 학습 내용을 반영한 대시보드를 만든다.
   • 알림 시스템에서 바로 열 수 있는 런북을 연결한다.

4. 4단계 – 지속적인 개선 루프

   • “인시던트 리뷰 자체”에 대한 정기적인 회고: 무엇이 잘 작동하고, 무엇이 소음(noise)인가?
   • 팀 간에 패턴을 공유하는 리뷰(예: 반복되는 특정 의존성 장애 패턴).
   • 과거 인시던트에서 도출된 리질리언스 테마를 제품/플랫폼 로드맵에 명시적으로 반영한다.

이쯤 되면, 실제로 대부분의 일을 하는 건 템플릿이 아니라 **조직의 규범(norms)**이다.

자동화는 건강한 문화를 증폭시키는 역할을 해야지, 망가진 문화를 콘크리트처럼 굳혀 버리면 안 된다.

정리: 다음 페이지를 넘기기 전에, 먼저 리모델링부터

온콜 시스템—사람, 프로세스, 소프트웨어 전체—을, 살고 있는 동안 방 하나씩 리모델링해 나가는 건물이라고 생각해 보자.

각 인시던트는 구조 점검이다.

그 점검이 진짜 의미를 가지게 만들려면:

• 포스트모템을 단순 문서 작업이 아니라 문화 리모델링으로 바라보라.
• 사람들이 실제로 참여할 수 있도록 작고 가볍게 시작하라.
• 대응과 리뷰 모두에 사용할 단순하고 엔지니어링 주도적인 프레임워크를 가져라.
• 인시던트가 시스템 안을 어떻게 흘러갔는지 모두가 볼 수 있게 아날로그 실패 평면도를 함께 그려 보라.
• 초점을 비난이 아니라 리질리언스와 학습에 두어라.
• 프로세스를 반복해서 다듬고, 문화가 준비되었을 때에만 자동화를 더하라.

다음 온콜 로테이션이 시작되기 전에, “아날로그 인시던트 스토리 도면 서랍”을 열어 보라.
펜 하나, 종이 한 장, 그리고 가장 최근의 큰 장애를 꺼내라.

실제로 무슨 일이 있었는지, 다시 그려보라.

당신이 그리는 건 과거의 실패 도면만이 아니다. 앞으로 더 탄탄한 미래를 위한 평면도를 함께 그려 나가는 것이다.