아날로그 인시던트 스토리 트램 맵 워크숍

장애로 가득한 종이 도시 위에 신뢰성 노선도를 손으로 그리기

다음 인시던트를 당신의 시스템을 달리는 트램(노면전차) 노선처럼 따라가 볼 수 있다면 어떨까요? 모든 알림은 하나의 역이 되고, 팀 간 핸드오프는 환승이고, 애매한 의존성은 모두가 리스크를 떠안는 환승역이 됩니다.

이것이 바로 아날로그 인시던트 스토리 트램 맵 워크숍의 핵심 아이디어입니다. 팀이 함께 종이를 펼쳐 놓고, 장애가 인프라·툴·팀·프로세스를 어떻게 흐르는지 직접 그려 보는 협업형 아날로그 연습입니다.

대시보드·트레이스·실시간 메트릭으로 가득한 세상에서, 이런 방식은 다소 수상할 만큼 ‘로우테크’처럼 보일 수 있습니다. 하지만 바로 그게 포인트입니다. 화면에서 눈을 떼고 펜과 종이로 속도를 늦추면, 신뢰성을 전혀 다른 관점에서 보기 시작합니다.

왜 인시던트를 트램 노선도로 그릴까?

대중교통 노선도는 복잡한 지리 정보를 깔끔하고 이해하기 쉬운 구조로 압축합니다. 모든 거리와 건물을 보여주지 않고, 이동에 필요한 것만 남기죠.

• 분명한 노선 (route)
• 구분되는 역 (stop)
• 직관적인 환승역 (interchange)

이제 인시던트를 트램 노선도로 상상해 봅시다.

• 각 인시던트는 시간에 따라 시스템·팀·의사결정을 관통하는 하나의 노선입니다.
• 각 이벤트(알림, Slack 메시지, 실패한 배포, 수동 조치)는 하나의 역입니다.
• 각 의존성이나 핸드오프는 환승역입니다.

이렇게 인시던트를 시각적으로 매핑하면:

• 숨겨진 의존성과 “이게 아직도 있었어?” 싶은 컴포넌트를 드러내고
• 사소해 보이던 문제가 어떻게 대형 장애로 연쇄 확대되는지 보이고
• 인시던트가 서버뿐 아니라 팀과 툴을 어떻게 가로질러 이동하는지 이해하게 되며
• 로그나 포스트모템에 파묻혀 있던 리스크와 병목을 한눈에 보이게 만들 수 있습니다.

트램 노선도는 그저 예쁜 산출물이 아니라, 모두가 가리키며 이야기할 수 있는 공유된 멘탈 모델입니다.

픽셀보다 종이: 왜 아날로그가 중요한가

이미 대시보드, 런북, 인시던트 타임라인, 트레이스, 티켓 시스템을 가지고 있는데, 왜 종이를 더해야 할까요?

그 이유는 아날로그 방식이 다른 행동을 강제하기 때문입니다.

1. 천천히 그릴수록 숨은 가정이 드러난다
   인시던트를 손으로 그리면 빨리감기나 필터링이 안 됩니다. 다음을 스스로 물어야 합니다. “그다음에 정확히 뭐가 일어났지? 누가 관여했지? 어떤 시스템이 영향을 받았지?” 이런 대화를 하다 보면:

   • 서로 모순되는 기억이 드러나고
   • 보이지 않던 숨은 의존성이 튀어나오고
   • “누가 이 잡(Job)을 실제로 운영하지?” 같은 모호한 오너십이 노출됩니다.

2. 누구나 참여할 수 있다
   특별한 툴 스킬이 필요 없습니다. 펜과 포스트잇만 있으면 됩니다. Ops, 개발, PM, 심지어 리더십까지 한 장의 종이 지도 앞에 함께 설 수 있습니다. 이는 역할 간 격차를 줄이고, 공유 학습을 촉진합니다.

3. 대시보드 터널에서 빠져나온다
   디지털 뷰는 강력하지만 철저히 큐레이션된 시야입니다. 누군가 계측하기로 결정한 것만, 그 툴이 좋아하는 형태로 보여주죠. 빈 종이는 제품이나 스키마에 신경 쓰지 않습니다. 한 화면에 아래를 마음대로 섞어 넣을 수 있습니다.

   • 인프라
   • 팀
   • 프로세스
   • 툴

4. 산출물이 호기심을 부른다
   벽에 붙은 손그림 지도는 이런 복도 대화를 유도합니다. “왜 단순 롤백 하나에 노선이 세 팀을 지나가야 하지?” 시간이 지나면 이 벽은 살아 있는 신뢰성 갤러리가 됩니다.

인시던트 트램 맵 워크숍 준비하기

필요한 것은 많지 않습니다.

자료:

• 큰 도화지 또는 갈색 롤지
• 색깔 있는 마커나 펜
• 포스트잇 (선택이지만 있으면 편리함)
• 테이프 또는 넓은 테이블/벽

사람:

• 이야기를 이끌 1–2명의 숙련된 SRE 또는 인시던트 커맨더
• 인시던트에 관여한 핵심 시스템의 엔지니어들
• 고객 영향이 있었다면, 지원/제품/고객 성공팀 중 1명
• 시간 관리와 논의 촉진을 맡을 퍼실리테이터(위 SRE 중 1명이 겸해도 좋음)

인시던트 선택 기준: 다음 중 하나를 고릅니다.

• 모두가 기억하고 있는 최근의 높은 임팩트 인시던트
• 작아 보이지만 자주 반복되어 배경 소음처럼 계속 나타나는 인시던트

가장 트라우마가 큰 최악의 장애부터 시작하지는 마세요. 충분히 현실적이지만, 안전하게 해부할 수 있는 사례가 좋습니다.

단계별 진행: 종이로 그리는 장애 도시

1. 지도의 ‘지리’를 정의하기

먼저, 지도의 역(station)이 무엇을 의미할지 정합니다. 흔한 선택지는:

• 시스템 / 컴포넌트 (API, DB, 큐, 배치 잡 등)
• 팀 (Backend, SRE, Data, Support 등)
• 툴 (PagerDuty, Slack, CI, 대시보드 등)
• 프로세스 단계 (탐지 Detect → 진단 Diagnose → 완화 Mitigate → 복구 Recover → 학습 Learn)

그다음 단순한 레이아웃을 그립니다.

• 가로축: 시간 (왼쪽 = 인시던트 시작, 오른쪽 = 종료)
• 세로 방향으로는 주요 도메인을 클러스터링합니다. 예:
  • 상단 밴드: 고객 및 비즈니스 영향
  • 중간 밴드: 애플리케이션 & 서비스
  • 하단 밴드: 인프라 & 외부 의존성
  • 한쪽 사이드 패널: 팀 & 커뮤니케이션

정교할 필요는 없습니다. 역을 배치할 수 있는 논리적인 영역만 있으면 됩니다.

2. 인시던트 타임라인을 하나의 노선으로 그리기

이 인시던트 **노선(line)**에 사용할 색깔 마커를 정합니다.

그리고 인시던트 스토리를 처음부터 끝까지 따라가며 그립니다.

1. 트리거: 처음 관측 가능한 신호는 무엇이었나요? 사용자 제보? 알림? 대시보드 이상 징후?

   • 하나의 역을 그려 이름을 붙입니다: “사용자 500 에러 제보”, “서비스 X CPU 알림 발생” 등.

2. 전파(Propagation): 그 다음엔 무엇이 일어났나요? 어떤 시스템으로 장애가 옮겨갔나요?

   • 의미 있는 전환점마다 역을 그리고 선으로 연결합니다.

3. 탐지 & 대응: 팀은 어떻게 문제를 인지하고 반응했나요?

   • “온콜에게 PagerDuty 알림”, “Slack 워룸 채널 생성” 같은 역을 포함합니다.

4. 에스컬레이션 & 핸드오프: 언제 다른 팀이나 툴이 스토리에 합류했나요?

   • 이 지점들이 바로 환승역입니다.

5. 완화 & 복구: 성공이든 실패든, 주요한 모든 시도와 조치를 따라가며 기록합니다.

과감히 압축하려는 유혹을 참으세요. 롤백 하나를 위해 핸드오프가 여섯 번 일어났다면, 실제로 그 여섯 번 모두를 그려야 합니다.

3. 숨은 의존성과 잊힌 컴포넌트 드러내기

그리는 동안 계속 이렇게 물어보세요.

• “이 장애가 ‘보이게’ 되기 위해 무엇에 의존했지?”
• “더 악화되기 위해 무엇을 발판으로 삼았지?”
• “여기서 우리가 ‘당연히 잘 돌아간다’고 가정한 컴포넌트는 뭐지?”

그리고 다음 같은 것들도 역으로 추가합니다.

• 조용히 실패하고 있던 스케줄링 잡
• 아무도 책임지고 싶어하진 않지만 모두가 쓰고 있는 레거시 서비스
• 인시던트 흐름에 영향을 준 외부 서비스(결제, DNS, 인증 등)

이러한 “잊힌” 요소들은 **연쇄 장애(cascading failure)**의 출발점인 경우가 많습니다. 다른 색깔이나 모양으로 표시해 두는 것이 좋습니다.

4. SRE 관행을 노선과 환승으로 지도에 녹여 넣기

이제 지도에 SRE 인시던트 관리 구조를 입혀 봅니다.

• 누가 누구와, 어디에서, 언제 얘기했는지 보여주는 별도의 **“커뮤니케이션 노선”**을 그립니다. (Slack 채널, 브리지 콜, 상태 페이지 등)
• 인시던트 커맨더 역할, 주요 의사결정 지점, 에스컬레이션 흐름을 나타내는 **“커맨드 노선”**도 추가합니다.
• 기술적인 경로와 커뮤니케이션 경로가 교차하는 환승역을 표시합니다. 예:
  • 롤백을 하기로 한 결정
  • 다른 팀을 호출하기로 한 결정
  • 고객 공지를 업데이트하기로 한 결정

이렇게 하면 커뮤니케이션 지연이나 역할 혼선 때문에 복구가 늦어진 지점이 훨씬 선명하게 보입니다.

5. 병목, 취약 지점, 설계 결함 강조하기

이제 한 걸음 물러나 전체 지도를 봅니다. 그리고 그룹에게 물어보세요.

• 여러 노선이 한 개의 취약한 역을 공통으로 지나는 곳은 어디인가요? (싱글 포인트 오브 페일러)
• 탐지와 실제 조치 사이의 간격이 긴 구간은 어디인가요? (느린 대응)
• 노선이 불필요하게 여러 팀을 우회하는 곳은 어디인가요? (오너십 또는 권한 문제)
• 장애가 예상 밖의 도메인으로 갑자기 튀어 넘어간 지점은 어디인가요? (의외의 의존성)

이 구간들을 동그라미로 크게 표시하거나 (⚠, ●●●) 같은 아이콘을 써서 강조합니다. 여기가 바로 신뢰성 핫스팟입니다.

트램 맵이 미래 인시던트를 개선하는 방식

몇 개의 인시던트 트램 맵을 그리고 나면, 패턴이 보이기 시작합니다.

더 빠르고 명확한 의사결정

자신들의 인시던트 노선을 눈으로 본 팀은 보통 다음을 조정합니다.

• 우회 경로를 줄이도록 온콜 로테이션과 에스컬레이션 경로를 재설계하고
• 지도에서 드러난 블라인드 스팟 근처에 대시보드와 알림을 추가하며
• 적절한 사람이 기다림 없이 조치할 수 있도록 권한과 절차를 간소화합니다.

다음 인시던트에서 익숙한 환승역이 등장하면, 대응자들은 이미 그 컨텍스트와 리스크를 이해한 상태에서 움직일 수 있습니다.

역할을 넘나드는 공감과 이해

비(非)엔지니어도 이제 다음을 직접 눈으로 볼 수 있습니다.

• 왜 “작은 설정 변경”이 전혀 작지 않았는지
• 외부 벤더나 “그 오래된 서비스”가 장애 양상에 어떤 영향을 미치는지
• 매번 큰 인시던트마다 어떤 팀이 과부하를 겪는지

이런 이해는 서로에 대한 공감을 키우고, 신뢰성 투자 논의를 훨씬 구체적으로 만들어 줍니다.

더 솔직한 사후 리뷰(Post‑Incident Review)

시각적인 트램 맵은 포스트모템을 책임 공방이 섞인 이야기에서 공동 탐구의 장으로 바꿉니다.

• 모두가 복잡하게 얽힌 선을 가리키며 “이걸 어떻게 더 단순하게 만들 수 있을까?” 하고 질문할 수 있습니다.
• “당시에 우리는 큐가 밀리고 있는 줄 사실 몰랐어요” 같은 정정과 맥락이 자연스럽게 추가되어, 기록의 정확도도 올라갑니다.

좋은 워크숍을 위한 팁

• 시간을 강하게 제한하세요. 한 인시던트에 60–90분이면 충분합니다. 완벽함이 아니라 인사이트가 목표입니다.
• 처음에는 거칠게. 역은 포스트잇으로 만들면, 스토리가 선명해질수록 쉽게 위치를 옮길 수 있습니다.
• 스토리텔러를 순환시키세요. 시니어 엔지니어만 설명하게 두지 말고, 각 구간을 다른 참여자가 설명하게 해 보세요.
• 사진을 남기고 가볍게 디지털화하세요. 나중에 다이어그램 툴로 다시 그릴 수 있지만, 원래 손그림의 느낌은 남겨두는 게 좋습니다.
• 정기적으로 반복하세요. 트램 맵 워크숍을 인시던트 리뷰 문화의 일부로 만들고, 월 1회 혹은 큰 이벤트 이후에 진행해 보세요.

맺으며: 신뢰성 스토리로 채워진 한 도시를 만드는 일

아날로그 인시던트 스토리 트램 맵 워크숍의 목적은 더 멋진 그림이 아닙니다. **더 나은 공동 사고(Shared Thinking)**입니다.

인시던트를 종이 위의 장애 도시를 가르는 노선으로 손수 그리면서, 우리는 다음을 할 수 있습니다.

• 평소엔 잘 안 보이는 모호한 의존성과 잊힌 컴포넌트를 끌어올리고
• 사소한 이슈가 어떻게 대형 장애로 증폭되는지 눈앞에서 확인하고
• 지하철 노선도 같은 공간적 직관과 추상적인 신뢰성 데이터를 결합하고
• SRE 역할, 커뮤니케이션 경로, 에스컬레이션 흐름을 지도 위에 직접 표현하며
• 팀이 가정을 의심하고 시스템을 재설계할 수 있는 느리고 아날로그적인 협업 공간을 만듭니다.

시간이 지나면, 벽 가득한 트램 맵은 조직이 어떻게 실패를 경험하고, 어떻게 학습하는지를 보여 주는 살아 있는 아틀라스가 됩니다. 새로 생기는 각 인시던트 노선은, 다음번에는 더 잘 이동하게 될 또 하나의 경로입니다.

이미 로그, 트레이스, 메트릭은 충분히 가지고 있습니다. 이제 다른 것을 하나 더해 보세요. 굵은 마커, 큰 종이 한 장, 그리고 팀과 함께하는 한 시간. 다음 인시던트의 이야기를 직접 그려 보세요. 선들이 실제로 어디를 지나가는지, 눈으로 확인해 보십시오.