종이 인시던트: 스트리트 맵 카페가 매일의 신뢰성을 스케치하는 방법

종이 인시던트: 배포 사이를 잇는 일상적 신뢰성 스케치

대부분의 팀은 인시던트를 폭풍처럼 대합니다. 방해되고, 지치고, 다시는 안 오길 바라는 일. **스트리트 맵 카페(Street Map Cafe)**라는 가상의(하지만 매우 익숙한) 도시 탐색 SaaS 제품 팀은 인시던트를 폭풍이 아니라 이야기로 대하는 법을 배웠습니다. 그리고 그 이야기를 종이에 스케치하고, 지도처럼 펼쳐 보고, 배포와 배포 사이에 계속해서 다시 꺼내 봅니다.

이 글에서는 작은 엔지니어링 팀이 다음을 어떻게 해낼 수 있는지 살펴봅니다.

FRACAS(Failure Reporting, Analysis, and Corrective Action System: 고장 보고·분석·시정조치 시스템)를 과도한 관료주의 없이 가볍게 쓰는 법
인시던트 리포트를 먼지 쌓이는 포스트모템이 아니라, 신뢰성·안전·운영을 위한 구조화된 데이터 자산으로 바꾸는 법
아주 작은 핵심 인시던트 팀과 명확한 역할로 인시던트를 운영하는 법
종이 우선 스케치(타임라인, 의존성 맵, 스토리 맵)를 통해 배운 것을 체화하고, 매일의 신뢰성 의식으로 만드는 법

이걸 하나의 종이 인시던트 스토리 맵이라고 생각해도 좋습니다. 장애 중에 일어나는 일과, 배포 사이에 여러분이 어떻게 일하는지를 이어 주는 연결 고리입니다.

한 번짜리 포스트모템에서 ‘살아 있는’ 신뢰성 시스템으로

스트리트 맵 카페의 인시던트는 예전에는 늘 비슷한 패턴이었습니다.

뭔가 고장이 난다.
Slack이 난리가 난다.
사람들이 우르르 모여 어떻게든 복구하고, 포스트모템을 쓴다.
…그리고 일상이 돌아오면, 실제 일하는 방식은 거의 변하지 않는다.

변곡점은 어느 날 결제 시스템 장애 이후였습니다. 여섯 달 전에도 비슷한 일이 있었죠. 근본 원인은 달랐지만, 패턴은 완전히 같았습니다.

느린 탐지
모호한 오너십
팀보다 고객이 먼저 장애를 알아차리는 상황

문제는 기술적인 것만이 아니었습니다. 시스템적인 문제였죠. 인시던트를 고립된 사건으로만 보고, 더 큰 신뢰성 스토리 안의 데이터 포인트로 보지 못하고 있었던 겁니다.

그래서 팀은 가벼운 FRACAS 마인드셋을 도입했습니다.

관료주의 없이 쓰는 FRACAS

FRACAS는 이렇게 구성됩니다.

Failure Reporting(고장 보고) – 인시던트를 구조화된 방식으로 기록한다.
Failure Analysis(고장 분석) – 실제로 무슨 일이 왜 일어났는지 이해한다.
Corrective Action(시정조치) – 재발을 막거나 영향을 줄일 변경을 적용한다.
System(시스템) – 이 과정을 인시던트 전체에 일관되게 적용·추적 가능하게 만든다.

많은 팀이 FRACAS라는 말을 들으면, 항공 산업급의 빡센 관료제를 떠올리며 일단 피하고 봅니다. 스트리트 맵 카페는 다른 길을 택했습니다.

모든 인시던트에 공통으로 쓰는 간단한 단일 인시던트 폼(문서나 티켓 시스템 기반)
매번 반드시 채우는 소수의 공통 필드만 유지
배포와 배포 사이에 패턴을 리뷰하는 습관

거대한 스프레드시트도, 10단계 승인 체인도 없습니다. 다만, 시간이 지나도 트렌드를 볼 수 있을 만큼의 최소한의 구조만 남겼습니다.

인시던트 리포트를 ‘무덤’이 아니라 데이터 자산으로

가장 큰 변화는 폼 자체가 아니라, 데이터를 바라보는 시각이었습니다.

단발성 포스트모템으로 끝내는 대신, 팀은 이렇게 물었습니다.

“이걸 1년치 구조화된 데이터로 본다면, 우리 신뢰성·안전·운영에 대해 무엇을 배울 수 있을까?”

그래서 핵심 인시던트 스키마를 표준화했습니다.

무엇이 실패했는가? (서비스, 기능, 의존성 등)
Failure Class(고장 유형): 데이터, 인증(auth), 성능, 설정, 외부 의존성 등
탐지 소스: 모니터링, 고객 문의, 내부 제보
영향 범위(Impact Surface): 영향받은 고객 규모, 지역, 내부/외부 영향 구분
시간 지표(Time Metrics): 탐지까지 걸린 시간, 완화까지 시간, 완전 해결까지 시간
기여 요인(Contributing Factors): 프로세스, 툴링, 환경, 휴먼 팩터 등
시정조치(Corrective Actions): 기술·프로세스 변경 사항

이렇게 구조화하니 다음과 같은 질문에 답할 수 있게 됩니다.

어떤 서비스가 인시던트 대부분을 만들어 내는가?
외부 의존성 때문에 문제가 생기는 빈도는 어느 정도인가?
인시던트는 주로 고객이 먼저 발견하는가, 아니면 모니터링이 먼저 잡는가?
특정 릴리스 윈도우와 장애 발생이 상관 관계를 보이는가?

인시던트를 구조화된 신뢰성 데이터로 다루면서, 이 데이터는 곧바로 계획 수립을 위한 피드백 루프가 됩니다.

로드맵에 신뢰성 작업을 넣을 때, **아네크도트(누군가의 기억)**가 아니라 증거 기반으로 결정할 수 있습니다.
플랫폼·툴링 투자도 패턴을 근거로 정당화할 수 있습니다(“느낌상 필요해서”가 아니라).
온콜(온콜러) 교육도 실제로 자주 반복되는 실전 고장 유형 위주로 조정됩니다.

작은 팀일수록 가벼운 인시던트 워크플로가 필요하다

스트리트 맵 카페는 작은 엔지니어링 팀으로 운영됩니다. 거대한 인시던트 프로세스를 운용할 여력은 없지만, 그렇다고 완전한 혼돈도 감당할 수 없습니다.

그래서 워크플로 설계에 다음 두 가지 제약을 걸었습니다.

3–5명이면 언제든지 전 과정을 돌릴 수 있어야 한다.
혼란을 줄이거나 재발을 줄이는 데 기여하지 않는 프로세스 단계는 모두 없앤다.

결과물은 작고, 역할이 또렷이 정의된 핵심 인시던트 대응 팀이었습니다.

3–5명으로 구성하는 코어 팀

중요도가 있는 인시던트에는 항상 세 가지 핵심 역할을 지정합니다.

Incident Commander (IC, 인시던트 커맨더)
- 전체 의사결정과 조율을 책임집니다.
- 롤백 vs 패치, 부분 셧다운 vs 전체 셧다운 등 우선순위를 결정합니다.
- 팀이 한 방향으로 집중하도록 하고, 불필요한 왈가왈부를 막습니다.
Tech Lead (TL, 테크 리드)
- 근본 원인 분석과 기술적 완화를 주도합니다.
- 엔지니어들에게 어디를 볼지, 무엇을 바꿀지, 어떻게 검증할지 지시합니다.
- 가설과 증거를 추적하며 기술적 스토리를 정리합니다.
Communications Lead (CL, 커뮤니케이션 리드)
- 고객, 리더십, 지원/영업 팀 등 이해관계자 커뮤니케이션을 담당합니다.
- 상태 페이지 업데이트, 내부 브로드캐스트를 책임집니다.
- 기술적 상황을 이해하기 쉬운 일반 언어로 번역합니다.

필요하면 여기에 1–2명의 지원 엔지니어를 더할 수 있지만, 핵심 역할 셋은 항상 동일하게 유지됩니다. 이 일관성 덕분에:

조율 오버헤드가 줄고,
교육이 쉬워지며,
상황이 혼란스러울 때도 누가 무엇을 결정하는지가 명확해집니다.

25명이 몰려 있는 워룸도, 흐릿한 의사결정 구조도 없습니다. 소수 정예가 각자 무엇을 책임지는지 아는 팀만 있습니다.

왜 ‘종이’인가? 스트리트 맵 카페의 스케치 의식

이 팀의 가장 특이한 신뢰성 습관은 사실 거의 우연처럼 시작됐습니다.

한 번은 특히 소란스러운 인시던트가 있었습니다. 한 엔지니어가 노트북을 덮고, 노트를 꺼내더니 스케치를 시작했습니다.

세로로 내려가는 타임라인에 주요 이벤트를 표시하고,
서비스와 외부 API를 간단히 그린 의존성 다이어그램을 그리고,
사용자, 그들의 경로, 어디에서 에러를 마주치는지 정리한 스토리 맵을 그렸습니다.

이때 팀은 변화를 느꼈습니다.

대화가 훨씬 집중되었고,
모두가 랜덤한 Slack 메시지를 따라다니기보다, 같은 그림을 기준으로 정렬되었고,
며칠이 지나도 인시던트의 디테일을 더 잘 기억하고 있었습니다.

그래서 이걸 하나의 **의식(ritual)**으로 만들었습니다.

인시던트 중 ‘손으로 그리는’ 스케치

인시던트가 일정 심각도(severity) 이상이면, 누군가(보통 TL이나 IC)가 종이 스케치를 시작합니다.

타임라인 컬럼: 탐지 시점, 주요 변경, 완화 시도, 상태 전환 등을 시간 순으로 적습니다.
시스템 맵: 서비스 박스, 데이터 스토어, 서드파티 API, 큐 등을 박스와 화살표로 단순하게 표현합니다.
영향 메모: 어떤 사용자 플로우가 어디서 깨지는지, 어떤 증상이 나타나는지를 적습니다.

왜 멋진 툴 대신 굳이 종이일까요?

인지 부하가 낮습니다. UI를 만지작거릴 필요 없이, 생각나는 대로 빠르게 그릴 수 있습니다.
집중력이 좋아집니다. 펜과 종이는 탭 과부하에서 벗어나게 해 줍니다.
기억력이 좋아집니다. 손으로 쓰고 그리는 것은 인지·기억에 더 오래 남습니다.
의도적인 제약을 줍니다. 정말 중요한 것만 적게 되기 때문입니다.

스케치는 나중에 사진으로 찍어 인시던트 기록에 첨부하지만, 그 순간만큼은 툴링의 편리함보다 생각의 속도를 우선합니다.

배포 사이를 잇는 ‘종이 우선’ 매핑

진짜 마법은 인시던트 중이 아니라, 배포와 배포 사이에서 일어납니다.

스트리트 맵 카페는 **종이 인시던트 스토리 맵 세션(Paper Incident Story Map Session)**이라는 정기 의식을 만들었습니다.

매주(혹은 큰 인시던트 이후) 45–60분 정도 소규모로 모여서:

최근 기간 인시던트 리포트,
출력하거나 화면에 띄운 지표(SLI/SLO, MTTR, 인시던트 건수 등),
빈 종이와 펜, 마커를 준비합니다.

그리고 세 가지 종류의 맵을 그립니다.

1. 한눈에 보는 인시던트 타임라인

한 장의 종이에:

최근 인시던트 각각에 대한 미니 타임라인을 스케치합니다.
탐지, 에스컬레이션, 완화, 해결 시점을 표시합니다.
어떤 시그널(알람, 고객 티켓, 대시보드 지표 등)이 실제 행동을 트리거했는지 적습니다.

이 과정을 반복하다 보면 다음과 같은 것들이 드러납니다.

지나치게 시끄럽거나, 반대로 너무 조용한 알람 규칙
오너십이 애매해서 에스컬레이션이 느려지는 패턴
특정 유형의 인시던트에서 반복해서 나타나는 지연 요인

2. 의존성 스토리 맵

다른 한 장에는 이렇게 그립니다.

핵심 사용자 여정(예: “지도 둘러보기 → 카페 선택 → 결제”)을 먼저 그리고,
각 단계에서 호출되는 서비스와 의존성을 층위별로 얹습니다.
그 위에 최근 인시던트가 어느 경로와 겹치는지 표시합니다.

그러면 다음과 같은 패턴이 눈에 보입니다.

특정 백엔드 서비스가 전체 인시던트의 절반 가까이에 관여한다.
하나의 서드파티 제공자가 연쇄적인 문제를 만들어 낸다.
어떤 흐름은 우아한 강등(Graceful Degradation) 경로가 전혀 없다.

이 맵은 그대로 아키텍처 우선순위와 신뢰성 에픽으로 이어집니다.

3. 매일 하는 신뢰성 의식 맵

마지막으로, 인시던트를 덜 일어나게 하거나 덜 고통스럽게 만들 일상의 습관 루프를 스케치합니다.

배포 전 체크리스트
알람 튜닝
런북(runbook) 업데이트
카오스 테스트나 드릴
온콜 섀도잉(신규 인원이 함께 따라다니며 배우는 것)

각 습관마다 다음을 적습니다.

어떤 인시던트가 이 습관의 동기가 되었는지
누가 책임자인지
얼마나 자주 할 것인지

이렇게 하면 신뢰성 작업이 손에 잡히고 눈에 보이는 것이 됩니다. “언젠가 해야지”라고만 말하는 추상적인 일이 아닙니다.

인시던트 스토리에서 매일의 실천으로

시간이 흐르면서 스트리트 맵 카페의 종이 우선 의식은 팀의 기본 행동양식을 바꾸었습니다.

엔지니어들은 새로운 기능을 설계할 때부터 **고장 모드(Failure Mode)**를 자연스럽게 떠올립니다.
프로덕트 매니저는 로드맵에서 신뢰성 트레이드오프를 더 잘 이해하게 됩니다.
온콜 담당자는 가상의 시나리오가 아니라 실제 인시던트에서 나온 스토리 맵과 런북을 활용합니다.

가장 큰 변화는 이것입니다. 인시던트는 더 이상 드문 재앙이 아니라, 팀이 매일의 일을 개선해 가는 데 쓰는 주요 원자재가 되었습니다.

여러분 팀에서 ‘종이 인시던트 스토리 맵’을 시작하는 법

새로운 툴은 필요 없습니다. 몇 가지 제약과 펜 하나면 충분합니다.

최소한의 FRACAS 스키마를 정의하세요.
모든 인시던트에 대해 반드시 남길 6–10개 필드를 정하고, 꾸준히 지키세요.
3–5명으로 구성된 핵심 인시던트 팀을 정하세요.
Incident Commander, Tech Lead, Communications Lead 역할을 명시적으로 정의하고, 담당자를 지정하세요.
다음 인시던트에서 종이 스케치를 도입하세요.
한 명을 지정해, 다른 사람들이 일하는 동안 거친 타임라인과 시스템 맵을 그리게 하세요.
배포 사이에 짧은 매핑 세션을 예약하세요.
주 1회나 큰 인시던트 이후, 타임라인·의존성 맵·일상 습관 루프를 함께 스케치해 보세요.
맵을 구체적인 액션에 연결하세요.
매 세션이 끝날 때마다 알람, 문서, 코드, 프로세스 등과 관련된 1–3개의 구체적인 변경 사항을 결정하세요.

결론: 신뢰성은 그저 ‘숫자’가 아니라, 여러분이 그려 가는 ‘이야기’다

신뢰성은 업타임 퍼센트나 MTTR 그래프만으로 정의되지 않습니다. 더 중요한 것은 팀이 실패를 어떻게 이해하고, 위기 순간 사이의 평상시를 어떻게 보내는가입니다.

가벼운 FRACAS 접근법, 작고 명확한 인시던트 대응 팀, 그리고 종이 우선 스케치 의식을 결합하면서, 스트리트 맵 카페는 인시던트를 다음과 같이 바꾸었습니다.

구조화된 신뢰성 인사이트의 원천으로,
복잡한 시스템을 공유해 이해하는 시각적 언어로,
포스트모템이 끝난 뒤에도 살아남는 일상적 신뢰성 습관의 토대로.

여러분의 인시던트 프로세스가 혼란스럽거나, 반대로 지나치게 복잡하게 느껴진다면, 겉보기엔 단순한 다음 세 가지를 시도해 보세요.

팀을 줄이고,
데이터를 표준화하고,
펜을 집어 드세요.

그러면 인시던트가 여러분에게 들려주고 있던 이야기가, 마침내 배포와 배포 사이의 매일을 바꾸기에 충분히 선명해질지 모릅니다.