소개: 왜 우리 인시던트들은 서로 따로 노는 것처럼 보일까

대부분의 조직은 인시던트를 비슷한 방식으로 겪습니다.

• 어떤 서비스가 장애가 난다.
• 워룸이 열린다.
• 포스트모템을 작성한다.
• 티켓을 생성한다.
• 그리고 모두 다음 일로 넘어간다.

각 인시던트 포스트모템만 놓고 보면 꽤 괜찮을 수 있습니다. 하지만 전체적으로는 거의 보이지 않습니다. 날짜나 심각도로 정렬된 채 위키, Confluence, Google Drive 폴더 어딘가에 쌓여 있을 뿐, 서로 어떻게 연결되는지는 전혀 보이지 않습니다.

여기서 등장하는 것이 바로 **아날로그 인시던트 스토리 트레인야드(Analog Incident Story Trainyard)**입니다. 벽 전체를 쓰는 종이 머럴로, 흩어진 포스트모템 더미를 팀, 서비스, 시간 축을 가로질러 서로 연결된 하나의 시각적 스토리로 바꿔 줍니다.

이건 화이트보드나 포스트잇에 대한 향수가 아니라, 물리적인 공유 캔버스를 사고 도구로 활용해서, 대시보드나 스프레드시트로는 보기 어려운 패턴, 시스템적 원인, 조직의 취약 지점을 드러내는 방법입니다.

아날로그 인시던트 스토리 트레인야드는 무엇인가?

사무실 한쪽 전체 벽이 인시던트 지도로 변한다고 상상해 보세요.

• 제품, 서비스, 팀별로 철도 선로 같은 가로 레인이 있고,
• 인시던트는 열차로 표현되며, 각 객차는 기여 요인, 타임라인, 영향 범위를 나타냅니다.
• **선로 전환(switch track)**은 인시던트가 팀이나 시스템을 어떻게 가로질러 확산되었는지 보여 줍니다.
• 그 위에 딜리버리 지표, 의존성, 핸드오프, 반복되는 실패 테마 같은 주석 레이어를 쌓습니다.

목표는 단순합니다.

각각의 인시던트를 고립된 이벤트가 아니라, 실제 운영 환경에서 시스템과 조직이 어떻게 행동하는지를 보여 주는 하나의 크고 변화하는 이야기의 일부로 만드는 것.

이 아날로그 머럴은 여러분의 트레인야드 파노라마가 됩니다. 멀리서 한 발 물러서서 병목, 위험한 교차점, 과부하된 선로를 한눈에 볼 수 있는 장면인 셈입니다.

1단계: 인시던트를 위한 단순한 시각 프레임워크 만들기

종이와 마커를 집어 들기 전에, 먼저 일관된 시각 언어를 정의해야 합니다. 누구나 설명을 많이 듣지 않고도 쓸 수 있는 프레임워크가 필요합니다.

실용적인 출발점은 다음과 같습니다.

기본 레이아웃

• X축(시간): 인시던트 빈도에 따라 주 단위 또는 월 단위.
• Y축(트랙): 핵심 서비스, 도메인, 혹은 오너십을 가진 팀.
• 인시던트 카드: 인시던트당 카드 한 장, 발생 시점과 해당 서비스가 만나는 지점에 배치.

각 인시던트 카드에 공통으로 들어갈 요소

멀리서도 한눈에 읽을 수 있도록 색상이나 아이콘을 통일합니다.

• 심각도별 색상 (예: 빨강 = SEV-1, 주황 = SEV-2, 노랑 = SEV-3)
• 트리거 타입 아이콘 (배포, 설정 변경, 인프라 장애, 외부 의존성, 용량 문제 등)
• 짧은 제목 (예: “피크 트래픽 시 Search API 500 오류”)
• 지속시간 또는 영향 지표 (예: 37분 장애, 영향 받은 고객 수 등)
• 주요 오너 팀

그 다음, 연결선을 추가합니다.

• 동일한 루트 원인이나 의존성을 공유하는 인시던트들 사이에 화살표.
• 의심되지만 확실하지 않은 관계는 점선으로.
• 관련 인시던트들을 감싸는 “구름”이나 테두리 그룹 (예: “Auth 관련 장애” 클러스터).

이 기본 프레임워크만으로도 시작하기에 충분합니다. 시간이 지날수록 이 뼈대 위에 더 풍부한 인사이트를 걸어 둘 수 있습니다.

2단계: 포스트모템을 시각적 스토리로 바꾸기

포스트모템은 원재료이고, 머럴은 그걸 가공한 구조화된 스토리입니다.

새로운 인시던트가 생길 때마다, 다음과 같은 최소한의 반복 가능한 데이터를 추출합니다.

• 언제 시작되고 끝났는지
• 어디에서 탐지되었는지 (어떤 모니터링/알림/사용자 제보 등)
• 어떤 서비스들이 관여했는지
• 어떤 팀들이 참여했는지
• 핵심 기여 요인들 (기술적 + 조직적 요인 모두)
• 완화 조치와 후속 작업

그리고 이 정보를 앞서 정의한 시각 프레임워크에 담아냅니다.

반복 가능한 매핑 의식(Ritual)

인시던트마다 10–15분 정도 투자해 미니 세션을 진행합니다.

1. 메인 인시던트 카드를 올바른 시간과 트랙 위치에 붙입니다.
2. 의존성 카드를 추가합니다. 직접적이든 간접적이든, 인시던트에 기여한 다른 서비스를 모두 포함합니다.
3. 관계 화살표를 그립니다. 루트 원인이 비슷한 인시던트끼리 (같은 컴포넌트, 유사한 실패 모드, 반복되는 운영 갭 등).
4. 시스템적 요인을 작은 스티커나 심볼로 표시합니다.
   • 🟦 프로세스 / 온콜 이슈
   • 🟥 테스트 / 품질 격차
   • 🟩 관측성(Observability) / 탐지 격차
   • 🟨 용량 / 스케일링 격차
5. 핵심 학습 포인트를 카드 아래에 짧고 쉬운 문장으로 적습니다.
   예: “안전한 롤백 경로가 없었고, 배포가 all-or-nothing 구조였다.”

시간이 지나면 트레인야드는 겹치는 인시던트가 많은 트랙, 루트 원인이 비슷한 클러스터, 반복적으로 등장하는 조직적 고통 지점을 자연스럽게 드러내게 됩니다.

3단계: 관계, 의존성, 핸드오프를 시각화하기

인시던트는 거의 항상 단일 팀 안에만 머물지 않습니다. 이 머럴이 특히 가치 있는 순간은 팀 간 연결을 보여 줄 때입니다.

다음과 같은 레이어를 더해 보세요.

1. 서비스 의존성 라인

머럴 상단이나 측면에 간단한 **서비스 의존성 키(key)**를 유지합니다.

• 서비스마다 박스를 하나씩 (Auth, Billing, Notifications, Search 등)
• 런타임 의존성을 화살표로 표시 (A가 B를 호출, B가 C를 호출 등)

그리고 메인 머럴에서는:

• **색 테이프나 실(실제 끈)**을 사용해, 각 인시던트에 어떤 의존성이 관여했는지 표시합니다.
• 여러 인시던트 경로가 한 곳으로 몰리는 병목/초크 포인트를 강조합니다.

2. 팀 핸드오프 경로

각 인시던트에 대해, 어떤 팀들이 어떤 순서로 참여했는지도 표시합니다.

• 번호 스티커나 작은 화살표에 팀 이름을 적어서 사용 (예: “SRE → Data Platform → Payments”).
• 책임이 모호하거나 핸드오프가 느린 긴 체인이 반복되는 패턴을 찾아봅니다.

3. 핵심 개입 지점(Key Intervention Points)

패턴이 보이기 시작하면, 특히 중요한 “핫 트랙”이나 교차점을 식별합니다.

• 주요 인시던트의 높은 비율에 등장하는 서비스
• 장애 완화 후반부에 자주 소환되는 팀
• 공통적인 근본 원인으로 자주 등장하는 의존성

이 지점들을 시각적으로 강조합니다(예: 빨간 테두리, 별 아이콘 등). 이런 곳이야말로 시스템적 개선(리팩터링, 더 나은 런북, 명확한 오너십, 강한 SLO 등)의 최우선 타깃이 됩니다.

4단계: 인시던트를 딜리버리와 속도 데이터와 연결하기

인시던트는 진공 상태에서 발생하지 않습니다. 항상 딜리버리 압박, 변경량, 팀 업무량이라는 맥락 속에서 발생합니다.

Jira, Azure Boards, Linear 같은 스크럼/칸반 도구에서 데이터를 가져와 인시던트에 컨텍스트를 더합니다.

무엇을 오버레이할까

시간 단위(주 또는 스프린트)별로, 인시던트 위나 아래에 작은 주석을 붙입니다.

• 핵심 서비스별 배포 횟수
• 변경 실패율(Change Failure Rate)
  (예: 인시던트로 이어진 변경 비율)
• 팀 처리량(Throughput)
  (완료한 티켓 수, 스토리 포인트, WIP 등)
• 사이클 타임(Cycle Time)
  (작업이 In Progress에서 Done까지 걸리는 시간)

어떻게 도움이 되는가

이제 시각적으로 다음을 연관 지어 볼 수 있습니다.

• 인시던트 스파이크와 변경량 급증의 상관관계
• 반복되는 “서둘러 진행된” 배포와 낮은 품질 결과의 연관성
• 장기간 WIP 과다 / 처리량 저하 상태인 팀에서 더 많은 운영 실수가 발생하는 패턴

머럴은 단순한 실패 지도에 그치지 않고, 그 실패들이 발생했을 당시 우리가 어떻게 일하고 있었는지까지 보여 주는 컨텍스트 뷰가 됩니다.

5단계: 데이터는 자동화하되, 머럴은 아날로그로 유지하기

머럴은 아날로그여야 하지만, 데이터 수집은 가능한 한 자동화되어야 합니다.

유용한 자동화 아이디어

• 포스트모템 템플릿 + 스크립트: Confluence나 Google Docs에 포스트모템을 구조화된 템플릿으로 저장하고, 시간, 서비스, 심각도, 루트 원인 태그 등 주요 필드를 추출하는 스크립트를 운영합니다.
• 이슈 트래커 연동: 인시던트 관련 Jira 티켓에 태그를 달고, API를 통해 팀, 컴포넌트, 사이클 타임 등의 메타데이터를 가져옵니다.
• CI/CD 및 배포 로그: 서비스 및 주(week) 단위로 배포 빈도와 변경 실패율을 자동 계산합니다.
• 텔레메트리 / Observability 도구: SLA/SLO 위반 통계와 탐지 방식(알람 vs 사용자 신고 등)을 CSV나 대시보드 형태로 내보냅니다.

이렇게 모은 데이터를 바탕으로 단순한 주간 리포트를 생성합니다.

• 신규 인시던트와 그 메타데이터
• 팀/서비스별 딜리버리 지표
• 가장 자주 등장한 태그나 카테고리

그리고 짧은 정례 의식을 만듭니다.

매주 한 번, 각 팀 대표 몇 명이 모여 30분 동안, 자동 수집된 최신 데이터를 바탕으로 머럴을 업데이트한다.

이렇게 하면 사람들을 수작업 보고로 지치게 만들지 않으면서도 벽을 최신 상태로 유지할 수 있습니다.

6단계: 가볍게 시작하고, 지도를 진화시키기

처음부터 완벽한 머럴을 설계하려고 하지 마세요. 이걸 하나의 살아 있는 실험으로 취급하는 편이 좋습니다.

가볍게 시작하기

• 마스킹 테이프, 포스트잇, 마커만으로 시작합니다.
• 처음에는 1–2개의 축에만 집중합니다: 예를 들어 시간 + 서비스, 혹은 시간 + 팀.
• 인시던트를 제자리에 붙이고 간단한 연결선만 그리는 것에 초점을 맞춥니다.

학습에 따라 진화시키기

패턴이 보이고 사람들이 벽에 익숙해질수록, 점차 복잡도를 올립니다.

• 각 시간 컬럼 위에 딜리버리 지표 스트립을 추가합니다.
• 프로세스, 테스트, Observability 등 시스템적 요인에 대한 심볼을 도입합니다.
• 특히 복잡한 인시던트는 **확대 뷰(인셋 맵)**를 만들어 더 자세히 표현합니다.
• 새로운 조직적 인사이트를 요약해 두는 “Top Learnings” 전용 레인을 추가합니다.

어떤 머럴은 끝까지 러프한 스케치에 가까울 것이고, 어떤 머럴은 매우 dense하고 정보량 많은 파노라마로 진화할 것입니다. 둘 다 가치가 있습니다. 중요한 것은, 인시던트와 시스템에 대한 이해가 깊어질수록 머럴도 함께 변화한다는 점입니다.

7단계: 이 벽을 공유 학습 공간으로 만들기

트레인야드 파노라마의 진짜 힘은 기술이 아니라 사회적 효과에서 나옵니다.

이 벽을 진짜 공유 학습 공간으로 만들려면:

• 중앙 위치에 설치합니다. 팀 룸 근처, 휴게 공간, 메인 복도처럼 사람들이 자연스럽게 오가는 곳.
• 조직의 의식(ritual)에 활용합니다. 인시던트 리뷰, 전체 엔지니어링 올핸즈, 분기별 플래닝 등.
• 자유로운 참여를 초대합니다. 엔지니어, PM, SRE 누구든 주석을 달고, 질문을 적고, 패턴을 표시할 수 있게 합니다.
• 개선 사항을 축하합니다. “Q2 리팩터링으로 이 위험한 의존성을 제거했다” 같은 완화된 시스템 리스크를 눈에 띄게 표시합니다.

시간이 지나면서 다음과 같은 변화가 나타납니다.

• 팀들이 자기 인시던트가 다른 것들과 어떻게 연결되는지를 보기 때문에 포스트모템의 품질이 좋아지고,
• 벽이 팀 간 의존성을 적나라하게 보여 주기 때문에 크로스팀 협업이 늘어나며,
• 대화가 “누가 망쳤냐?”에서 “우리 시스템과 프로세스가 왜 이런 실패를 낳기 쉬운 구조였나?”로 이동하는 더 깊은 시스템적 논의가 이루어집니다.

결론: 증상이 아닌 시스템을 보라

대시보드와 도구는 필수적이지만, 우리의 시야를 잘게 쪼개기도 합니다. 인시던트는 개별 알람, 티켓, 그래프로 흩어져 나타납니다. 아날로그 인시던트 스토리 트레인야드는 이 파편들을 하나의 공유된, 사람이 읽을 수 있는 파노라마로 엮어 줍니다.

포스트모템을 구조화된 시각 프레임워크에 담고, 의존성과 팀 관계를 매핑하고, 딜리버리 지표와 연결하고, 가벼운 자동화로 계속 데이터를 공급하면, 이 머럴은 다음과 같은 역할을 합니다.

• 개별 리포트로는 보이지 않던 패턴과 시스템적 원인을 드러내고,
• 기술적·조직적 변화를 위한 핵심 개입 지점을 부각시키며,
• 시간이 지날수록 팀들이 연결성을 보게 되어 포스트모템의 품질을 향상시키고,
• 신뢰성과 운영 품질을 둘러싼 공유 오너십과 학습 문화를 키워 줍니다.

결국 이건 벽에 붙인 종이일 뿐입니다. 하지만 잘 활용하면, 조직이 실제로 어떻게 소프트웨어를 배포하고 운영하는지를 보여 주는 강력한 렌즈가 됩니다. 작게 시작하고, 끝까지 아날로그로 유지하고, 매 인시던트에서 배운 것을 더할수록 트레인야드 파노라마가 함께 자라나게 하세요.