소개

인시던트(장애)는 거의 언제나 한 팀의 경계 안에만 깔끔하게 머물러 있지 않습니다. 망가진 의존 서비스, 갑자기 시끄러워진 알림(alert), 중요한 고객 영향 버그 하나만으로도 SRE, 애플리케이션 엔지니어, 데이터베이스 관리자(DBA), 보안, 고객 지원, 리더십까지 빠르게 일이 번져 나갑니다.

일이 정보 흐름보다 더 빠르게 움직이기 시작하는 순간, 전형적인 실패 패턴이 나타납니다. 바로 인수인계 갭(handoff gap) 입니다. 맥락은 사라지고, 책임은 모호해지며, 사람들이 이미 한 작업을 다시 반복하고, 중요한 단서는 채팅 로그나 누군가의 기억 속에만 남게 됩니다.

여기서 아날로그 인시던트 스토리 트롤리 맵(Analog Incident Story Trolley Map) 이라는 개념이 등장합니다. 인시던트가 팀 간을 어떻게 ‘이동’하는지를 일부러 종이(또는 물리적으로 눈에 보이는 방식)로 표현한 것입니다. 지하철·노면전차 노선도처럼 아래 내용을 보여줍니다.

• 인시던트가 각 팀의 “노선(line)”에 어디서 진입하는지
• 필수 정차 지점(문서화, 검증, 커뮤니케이션)
• 언제, 어떻게 노선을 갈아타는지(인수인계)

이 지도를 사전에 설계해 두면, 조직 전체에서 장애를 옮기고 처리하는 과정을 더 안전하고 예측 가능하게 만들 수 있습니다.

왜 인수인계는 위험하면서도 필수적인가

인수인계(handoff)는 역설적입니다.

• 필수적인 이유: 어떤 팀도 24/7로 모든 걸 책임질 수 없고, 복잡한 인시던트일수록 여러 전문성이 필요하기 때문입니다.
• 위험한 이유: 매번 넘길 때마다 맥락, 속도감, 명확한 오너십을 잃을 위험이 있기 때문입니다.

자주 반복되는 실패 패턴은 다음과 같습니다.

• “잠깐, 그건 당신 온콜이 맡는 거 아닌가요?”
• 새로 투입된 응답자가 이미 시도한 조치를 또 반복함
• 고객 대응 팀이 최신·정확한 상태를 알지 못함
• 안전하게 넘기지 못해 개인이 탈진할 때까지 붙잡고 있음

목표는 인수인계를 피하는 것이 아니라, 잘 설계하는 것입니다. 새벽 3시에도 예측 가능하고, 반복 가능하며, 실행하기 쉬운 인수인계를 만드는 것이 핵심입니다.

트롤리 맵 비유

인시던트를 노면전차(트롤리) 시스템의 승객이라고 생각해 봅시다.

• 각 팀은 하나의 노선(line) 입니다. (예: SRE 라인, DB 라인, 보안 라인 등)
• 각 노선의 특정 정류장(stop) 은 구체적인 작업 단계를 의미합니다. 트리아지, 조사, 완화(mitigation), 커뮤니케이션, 사후 리뷰 등입니다.
• 환승역(transfer station) 은 팀 간 인수인계나, 사람 간 교대(예: 교대 근무 시점)를 의미합니다.

아날로그 인시던트 스토리 트롤리 맵은 인시던트 처리 워크플로를 시각화한 것입니다. 출력물, 화이트보드, 포스트잇 등 눈에 보이는 형태로 다음을 분명히 드러냅니다.

• 인시던트가 각 팀 노선에 어디서 진입할 수 있는지
• 노선을 떠나기 전에 반드시 해야 할 일은 무엇인지
• 각 구간의 책임자는 누구인지
• 다음 팀이 실제로 인시던트를 “받아갔는지” 어떻게 확인하는지

이걸 아날로그로(최소한 물리적으로 가시적인 형태로) 만드는 힘은, 복잡함을 도구 뒤에 숨기지 않고, 오히려 명확하고 단순하게 만들도록 강제한다는 데 있습니다. 스트레스 상황에서도 사람이 따라갈 수 있는 워크플로를 설계하는 데 초점을 맞추게 됩니다.

구조화된 인수인계 설계: 무엇을 공유해야 하는가

효과적인 인수인계는 구조화된 문서화(structured documentation) 에서 시작합니다. 인시던트가 한 “노선”에서 다른 노선으로 옮겨가기 전에, 매번 반드시 기록·공유해야 할 내용을 정의해야 합니다.

간단한 인시던트 인수인계 템플릿은 다음 항목을 포함할 수 있습니다.

1. 인시던트 기본 정보

   • 고유 인시던트 ID
   • 심각도(severity)와 영향 요약
   • 시작 시각 및 현재까지의 지속 시간

2. 현재 상태

   • 무엇이 망가졌는지(확인된 장애 지점)
   • 영향 범위(사용자, 리전, 서비스 등)
   • 현재 상태 (예: 적극 대응 중, 모니터링 중, 관찰(watching) 중 등)

3. 지금까지 수행한 조치

   • 수행한 구체적인 단계와 타임스탬프
   • 관련 대시보드, 런북(runbook), 티켓, 로그 링크
   • 이미 제외된 가설/원인(재작업을 막기 위해)

4. 리스크와 미지 영역

   • 추정되는 근본 원인 또는 기여 요인
   • 아직 데이터가 부족하거나 조사가 더 필요한 영역

5. 명확한 오너십과 다음 단계

   • 다음 단계를 책임질 지정 온콜/프라이머리 담당자
   • 앞으로 수행해야 할 구체적인 작업
   • 에스컬레이션 조건(어떤 상황에서 더 escalte 해야 하는지)

이것이 한 노선에서 다른 노선으로 “점프”할 때 인시던트가 반드시 싣고 가야 하는 최소 화물(minimum cargo) 입니다.

트롤리를 언제 움직일 것인가: 타이밍 전략

아무리 훌륭한 문서화라도, 잘못된 타이밍에 인수인계를 하면 소용이 없습니다.

중요한 타이밍 전략은 다음과 같습니다.

1. 명시적인 인수인계 트리거 정의

인수인계를 언제 허용하거나 필수로 할지, 미리 명확히 정합니다. 예를 들어:

• 교대 시점(예: 8시간, 12시간 단위)
• 정의된 피로도 한계에 도달했을 때(예: 고강도 인시던트 대응 2–3시간 경과)
• 주요 전문 분야가 바뀌어야 할 때 (예: 네트워크 이슈에서 DB 이슈로 전환되는 시점)

2. 피로 상태에서의 “그림자 오너십” 금지

주요 응답자가 명백히 지쳐 있는 상황이라면, 트롤리 맵은 강제로 환승 정류장에 서게 해야 합니다.

• 인시던트는 체크인 없이 같은 노선에 계속 머물 수 없습니다.
• 두 번째 사람이 인시던트를 넘겨받거나, 공식적으로 공동 소유를 선언해야 합니다.

이렇게 하면 “내가 그냥 끝까지 버텨볼게요”라는 영웅 문화 대신, 설계된 안전 장치를 갖춘 시스템으로 바꿀 수 있습니다.

3. 부드러운 교대 경계

정각에 딱 끊어버리는 방식 대신, 짧은 오버랩 구간을 설계합니다.

• 15–30분 정도, 기존 담당자와 신규 담당자가 함께 있는 시간 확보
• 실시간 대화 + 작성된 요약을 함께 사용해 인수인계 진행

이 구간이 바로 환승역입니다. 나가는 팀이 인시던트가 다음 노선으로 “갈아타는” 과정을 도와, 그 사이에서 인시던트가 떨어져 나가지 않게 하는 것입니다.

표준화된 커뮤니케이션: 채널, 포맷, 역할

인시던트가 이리저리 움직이면서도 모두가 이해 가능한 상태를 유지하게 해주는 것은 표준화입니다.

1. 고정된 채널

인시던트가 터지기 전에 커뮤니케이션이 어디에서 이뤄질지 정해 둡니다.

• 인시던트별 전용 채팅 채널 (예: #inc-1234)
• 단일 상태 페이지(내부용/외부용)
• 모든 곳에서 링크되는 공용 인시던트 문서나 티켓

의미 있는 의사결정을 사이드 채널에서만 하지 않습니다. 중요한 내용은 반드시 공식 채널에 미러링합니다.

2. 공통 포맷

누구나 알아볼 수 있는 일관된 구조를 사용합니다.

• 상태 업데이트 템플릿 (Impact → Actions → Next steps → ETA 순서 등)
• 표준화된 타임스탬프 형식
• 가정(assumption)과 확인된 사실을 명확히 구분 표시

모든 팀이 같은 패턴을 사용하면, 인시던트 트롤리가 조직의 경계를 오갈 때 맥락 손실이 크게 줄어듭니다.

3. 명확한 역할 정의

일반적으로 정의해야 할 역할은 다음과 같습니다.

• 인시던트 커맨더(Incident Commander) – 전체 조율과 커뮤니케이션을 책임.
• 오퍼레이션 리드(Operations Lead) – 각 기술 워크스트림을 책임.
• 커뮤니케이션 리드(Communications Lead) – 고객 및 내부 이해관계자 대상 업데이트 담당.

트롤리 맵에는 어떤 정류장에서 어떤 역할이 필요하고, 팀이 바뀔 때 그 역할이 어떻게 이관되는지가 명시되어야 합니다.

검증: 다음 팀이 정말 트롤리를 받았는가?

인수인계는 정보를 보냈을 때가 아니라, 상대가 진짜로 받았을 때 성공한 것입니다.

이를 보장하기 위해, 맵 안에 명시적인 검증 단계를 포함해야 합니다.

1. 리드백(Read-back)

인수인계를 받는 사람/팀이 말로나 글로 다음을 요약합니다.

• 인시던트가 무엇에 관한 것인지
• 지금까지 무엇을 했는지
• 이제 본인이 무엇을 책임지는지

이 내용을 명확히 설명하지 못한다면, 인수인계는 아직 완료된 것이 아닙니다.

2. 체크리스트

양쪽 모두를 위한 간단한 체크리스트를 둡니다.

• 보내는 쪽: “템플릿을 다 채웠는가? 핵심 대시보드 링크를 넣었는가? 미지 영역을 명시했는가?”
• 받는 쪽: “현재 영향, 심각도, 다음 액션, 에스컬레이션 경로를 명확히 알고 있는가?”

3. 오너십 확인

명시적으로 선언합니다.

• 받는 사람이 말합니다. “지금부터 INC-1234의 프라이머리는 저입니다. 이제 내려가셔도 됩니다.”
• 보내는 사람이 이를 확인하고, 실제 작업에서 한 발 물러납니다.

이렇게 하면 서로 겹쳐서 맡고 있다고 생각하거나, 아무도 책임지고 있다고 믿지 않는 애매한 상태를 줄일 수 있습니다.

조정된 워크플로: 나만의 인시던트 트롤리 맵 만들기

자신의 조직에 맞는 트롤리 맵을 만들 때는, 작게 그리고 아날로그하게 시작하십시오.

1. 화이트보드나 종이에 각 팀을 노선으로 그립니다.
2. 대표적인 진입 지점을 표시합니다.
   • 모니터링 알림
   • 고객 문의/신고
   • 보안 탐지/취약점 리포트 등
3. 각 노선에 필요한 정류장을 추가합니다.
   • 초기 트리아지
   • 심층 조사
   • 완화(mitigation)
   • 커뮤니케이션 업데이트
4. 인시던트가 노선 간 이동하는 환승역을 식별합니다.
   • 교대/근무 교체
   • 전문 팀으로 에스컬레이션
   • 완화 후 디에스컬레이션(de-escalation)
5. 각 환승역마다 다음을 정의합니다.
   • 필수 문서화 항목
   • 사용할 커뮤니케이션 채널과 포맷
   • 검증 단계(리드백, 체크리스트 등)

아날로그 버전이 충분히 명확해지면, 이를 점진적으로 디지털 도구(인시던트 관리 시스템, 티켓 시스템, 챗봇 등)에 녹여 넣을 수 있습니다. 이때도 사람 눈으로 바로 이해 가능한 구조를 잃지 않는 것이 중요합니다.

연습이 신뢰성을 만든다: 테이블탑 시뮬레이션

트롤리 맵이 실제로 작동하는지 확인하려면, 직접 운행해 보는 수밖에 없습니다.

테이블탑 시뮬레이션(Tabletop Simulation)은 가상의 인시던트를 실제처럼 걸어가 보는, 저비용 고학습 연습입니다.

1. 현실적인 시나리오를 하나 고릅니다.
   • 예: 특정 리전 부분 장애, 데이터 손상, 자격 증명 유출 등
2. 맵에 등장하는 각 팀의 대표를 한자리에 모읍니다.
3. 다음 흐름을 실제처럼 밟아 봅니다.
   • 누가 가장 먼저 페이징을 받는가?
   • 첫 인수인계는 언제 일어나는가?
   • 어떤 정보가 어떤 포맷으로 옮겨 다니는가?
   • 역할은 어떻게 할당되고, 언제 어떻게 이관되는가?
4. 핵심 단계에 걸린 시간과, 혼란이 발생한 지점을 기록합니다.

이때 시험하는 것은 개인의 능력이 아니라, 시스템, 즉 트롤리 맵이 인시던트의 안전하고 예측 가능한 이동을 얼마나 잘 지원하는지입니다.

모든 테이블탑은 다음 결과를 남겨야 합니다.

• 템플릿과 체크리스트 수정
• 더 명확해진 역할 정의
• 갱신된 환승 규칙 (예: “X일 때는 더 일찍 DB 팀으로 넘긴다” 등)

시간이 지날수록 실제 인시던트에서의 인수인계는 더 차분해지고, 더 빠르며, 오류도 줄어드는 걸 체감하게 될 것입니다.

결론

인시던트는 피할 수 없습니다. 하지만, 혼란스럽고 깨지기 쉬운 인수인계는 그렇지 않습니다.

인시던트 프로세스를 노면전차 시스템처럼 — 노선, 정류장, 환승역이 있는 구조로 — 바라보면, 다음을 이룰 수 있습니다.

• 팀 간 맥락 손실 감소
• 오너십 전환을 명시적이고 안전하게 수행
• 응답자가 피로와 영웅주의 함정에 빠지지 않도록 보호
• 장애 시 팀 간 협업을 “즉흥 연주”가 아닌, 설계된 워크플로로 만들기

마커와 화이트보드 한 장으로 시작하십시오. 지금 조직에서 인시던트가 실제로 어떻게 움직이고 있는지 그려 보세요. 그다음, 그 여정을 다시 설계해 아날로그 인시던트 스토리 트롤리 맵으로 만드십시오. 그러면 장애가 조직 전체를 오가더라도, 도중에 길을 잃지 않고 안전하게 이동할 수 있는 시스템이 만들어질 것입니다.