Rain Lag

아날로그 장애 계주: 여러 팀이 얽힌 장애를 종이 바통처럼 깔끔하게 넘기는 법

여러 팀이 관여하는 장애를 잘 짜인 계주처럼 운영하는 방법—명시적인 소유권 전환, 예측 알림, 시간 기반 에스컬레이션 규칙, 재사용 가능한 플레이북으로 복잡한 인시던트를 통제하는 법을 다룹니다.

아날로그 장애 계주: 여러 팀이 얽힌 장애를 종이 바통처럼 깔끔하게 넘기는 법

대형 장애를 처리하는 엔지니어링 조직을 본 적이 있다면, 하이테크 대시보드와 로우테크 혼돈이 섞인 묘한 풍경을 봤을 겁니다. 누군가는 노트에 뭔가를 급히 적고, 다른 사람은 타임라인을 채팅창에 복붙하고, 여기저기서 “지금 이거 누가 맡고 있어요?”라는 말이 튀어나옵니다.

마치 누가 바통을 들고 있는지 아무도 모르는 계주 경기를 보는 것 같습니다.

이 글에서는 인시던트(장애) 대응을 아날로그 계주 경기로 보고, 그 종이 바통을 구조화된 신뢰 가능한 인수인계 시스템으로 바꾸는 방법을 이야기합니다. 다룰 내용은 다음과 같습니다.

  • 장애의 각 단계마다 명시적인 소유권 전환을 설계하는 방법
  • **예측 알림(predictive alerting)**과 시간 기반 에스컬레이션 규칙으로 MTTR을 줄이는 방법
  • 여러 도구와 팀 간에 발생하는 **알림 폭주(notification storm)**를 방지하는 방법
  • 실제로 변화를 이끌어내는 **집중형 회고(retrospective)**를 운영하는 방법
  • 재사용 가능한 인시던트 대응 플레이북을 만들고 공유하는 방법

왜 인시던트는 엉망인 계주처럼 느껴질까

실제 계주 경기에서 팀이 지는 이유는 주자가 느려서가 아니라, **바통 인수인계(handoff)**를 제대로 못해서입니다.

복잡한 장애도 대부분 비슷한 이유로 실패합니다.

  • 데이터베이스 팀이 당장의 문제는 해결했지만, 며칠 뒤에 터질 데이터 복구 백로그를 책임질 사람이 없다.
  • 지원(서포트) 매니저가 고객 후속 대응을 약속했지만, 인시던트 채널이 조용해진 뒤에는 명확한 오너가 없다.
  • SRE가 교대 시간에 “이제 누군가가 보고 있겠지”라는 생각으로 노트북을 덮는다.

기술적인 복구는 빨리 끝났을지 몰라도, 조직 차원의 대응은 그렇지 않습니다.

해법은 인시던트 라이프사이클의 각 단계를 **계주의 한 구간(leg)**으로 보고, 명확한 소유자와 공식적인 인수인계를 설계하는 것입니다.

인시던트 라이프사이클을 계주 구간으로 그려보기

먼저 여러분 조직의 인시던트가 어떤 “구간”으로 나뉘는지 정의해 보세요. 흔히 볼 수 있는 패턴은 다음과 같습니다.

  1. 탐지 & 트리아지(Detection & Triage) – 문제가 발생했는지 확인하고, 영향 범위를 파악한 뒤 인시던트를 선언.
  2. 격리 & 안정화(Containment & Stabilization) – 더 큰 피해를 막고 서비스를 복구.
  3. 데이터 복구 & 근본 조치(Data Repair & Remediation) – 손상된 데이터를 복구하고, 큐를 정리하고, 부수 효과를 정리.
  4. 고객 커뮤니케이션 & 후속 조치(Customer Communication & Follow-up) – 고객에게 알리고, 업데이트하고, 후속 조치를 마무리.
  5. 회고 & 개선(Retrospective & Improvement) – 배운 점을 정리하고, 액션 아이템을 우선순위화하고, 플레이북을 업데이트.

각 구간에는 반드시 다음이 필요합니다.

  • 명시적인 역할(owner role): 단순히 팀이 아니라 인시던트 커맨더(Incident Commander), 데이터 복구 리드(Data Repair Lead), 고객 커뮤니케이션 리드(Customer Comms Lead) 같은 롤.
  • 명확한 시작 조건(entry condition): 이 구간이 시작되었다고 보는 기준.
  • 명확한 종료 조건(exit condition): 이 구간이 “완료”되었다고 보는 기준.
  • 문서화된 인수인계(handoff): 바통을 누가, 어떻게 받는지.

바통은 **단일 진실 공급원(single source of truth)**이라고 생각하세요. 주인이 바뀔 때마다 함께 이동하는 문서, 티켓, 인시던트 레코드 같은 것입니다.

예시: 각 구간별 소유권 설계

  • 탐지 & 트리아지

    • 소유자: 온콜 SRE (초기) → 인시던트가 선언된 후 인시던트 커맨더
    • 종료 조건: 인시던트가 선언되었고, 심각도(severity)가 정해졌으며, 초기 영향 범위가 이해된 상태.

  • 격리 & 안정화

    • 소유자: 인시던트 커맨더
    • 종료 조건: 영향이 줄었거나 제거되었고, 합의된 시간 동안 서비스가 안정적으로 유지됨.

  • 데이터 복구 & 근본 조치

    • 소유자: 데이터 복구 리드 (대개 해당 서비스 오너 팀에서 지정)
    • 종료 조건: 데이터가 복구되었거나, 남은 작업이 추적 가능한 백로그로 정리되었고, 리스크가 문서화됨.

  • 고객 커뮤니케이션 & 후속 조치

    • 소유자: 고객 커뮤니케이션 리드 (Support, PM, Customer Success 등)
    • 종료 조건: 필요한 공지와 후속 대응이 모두 끝났고, 상태 페이지(Status Page)가 닫힘.

  • 회고 & 개선

    • 소유자: 사후 인시던트 회고 퍼실리테이터(Post-incident Facilitator) (대개 SRE 또는 엔지니어링 매니저)
    • 종료 조건: 사실 관계가 정리되었고, 기여 요인(contributing factors)이 정리되었으며, 액션 아이템이 생성되고 오너가 지정됨.

인수인계를 암묵적으로 하지 말고, 명시적으로 만들기

많은 장애 대응은 즉흥적인 전환에 의존합니다.

“이제 괜찮은 것 같아요. 아마 데이터 팀이 여기서부터 맡을 걸요?”

이렇게 해서 바통이 바닥에 떨어집니다.

이 대신 명시적이고 구조화된 인수인계를 사용하세요.

간단한 인수인계 템플릿

각 구간이 바뀔 때마다 다음을 기록합니다.

  • From: 인수인계를 하는 역할/사람
  • To: 소유권을 넘겨받는 역할/사람
  • Scope: 이제 무엇을 책임지는지 정확한 범위
  • State: 현재 상태, 리스크, 열린 이슈/질문들
  • Artifacts: 관련 대시보드, 로그, 문서, 티켓 링크
  • Next checkpoints: 다음 확인 시점이나 데드라인

실제 운영에서는 인시던트 채널에 붙여넣고, 인시던트 레코드에 함께 저장하는 정도의 단순한 텍스트 블록이면 충분합니다.

[HANDOFF]
From: Incident Commander (Alice)
To: Data Repair Lead (Ravi)
Scope: Kafka 토픽 `orders`에서 DB `orders_v2`로 12:10–12:27 UTC 사이 생성된 주문을 정합성 있게 재처리.
State: 1,842건 주문 영향; 600건 검증 완료; 현재까지 고객 영향 사례 0건.
Artifacts: Runbook #42, 복구 대시보드, Jira EPIC-321.
Next: 첫 상태 업데이트 15:00 UTC; 완료 예상 시각 18:00 UTC.

이렇게 계속 아날로그 텍스트 템플릿을 쓰면서도, 동시에 모던 인시던트 관리 도구와 연동할 수 있습니다.

예측 알림으로 MTTR 줄이기

인시던트를 빨리 감지할수록 각 계주 구간에 쓸 수 있는 시간이 늘어납니다. 여기에서 **예측 알림(predictive alerting)**과 **ML 기반 신뢰도 점수(confidence score)**가 중요해집니다.

단순히 “5xx 비율이 X%를 넘으면 알림” 같은 하드 임계치 기반 알림만 쓰지 말고, 다음과 같은 모델을 사용해 보세요.

  • 서비스별, 시간대별로 정상 패턴을 학습.
  • 패턴이 벗어날 때 신뢰도 점수(예: 장애일 가능성 0.92)를 함께 올려주는 알림 생성.
  • 지연(latency), 에러율, 자원 포화도, 고객 문의량 같은 여러 신호를 결합해 하나의 조기 경보로 통합.

운영 관점에서는 다음과 같이 쓸 수 있습니다.

  • 낮은~중간 신뢰도 신호는 경고 레벨 인시던트나 모니터링 대시보드로, 사람이 검토할 수 있게.
  • 높은 신뢰도 신호는 온콜을 자동 호출(page)하고, 인시던트 티켓을 자동 생성.

목표는 팀을 오탐(false positive)으로 지치게 만드는 게 아니라, 첫 번째 주자가 조금이라도 더 앞에서 출발할 수 있게 하는 것입니다.

시간 기반 에스컬레이션으로 조용한 실패 막기

인시던트가 시작되면, 시간 기반 에스컬레이션 규칙이 중간에 멈추지 않도록 안전장치 역할을 합니다.

예시:

  • P1 알림을 5분 안에 아무도 **ACK(인지)**하지 않으면 → 더 높은 에스컬레이션 정책으로 자동 승격 (PagerDuty, SMS, 혹은 매니저 직접 호출 등).
  • 인시던트가 높은 심각도로 30분 이상 유지되는데 상태 업데이트가 없다면 → 인시던트 커맨더와 리더십 채널을 자동으로 멘션.
  • 인시던트에서 파생된 백로그(예: 데이터 복구 작업)가 48시간이 지나도 미완료라면 → 해당 오너 팀 매니저에게 자동 에스컬레이션.

PagerDuty, Opsgenie, 혹은 사내 시스템에서도 이 규칙들을 인시던트 대응 자체에 대한 SLO처럼 다루세요.

여러분의 계주는 누군가가 “바통 넘겨야지”를 기억하는 것에 의존하면 안 됩니다. 시간 기반 규칙이 바통이 계속 앞으로 나가게 만들어 줍니다.

장기 인시던트에서 알림 폭주 막기

여러 팀이 얽힌 장기 장애는 종종 **알림 폭주(notification storm)**로 이어집니다.

  • 각 팀의 모니터링 도구가 비슷한 알림을 서로 다른 채널로 계속 보냄.
  • 상태 업데이트가 이메일, Slack, SMS, 티켓 시스템 등으로 중복 발송되는데, 내용이 조금씩 다름.
  • 사람들은 정신을 지키려고 채널을 mute 했다가, 정말 필요한 메시지를 놓침.

이 문제는 알림을 조율하고(throttle) 중앙에서 관리해서 풀 수 있습니다.

  1. 인시던트마다 **주요 방송 채널(primary broadcast channel)**을 하나 정합니다. (예: 특정 Slack 채널, MS Teams 룸 등)
  2. 모든 도구의 알림을 **집계기(aggregator)**를 통해 흘려보냅니다. (PagerDuty, 인시던트 관리 플랫폼, 혹은 내부 서비스)
    • 여러 소스에서 들어오는 알림을 중복 제거(deduplication).
    • 전송 빈도 제한(rate limit) 적용 (예: 영향이 바뀌지 않는 한 30분에 한 번만 고객 공지).
    • 역할 기반 구독(role-based subscription) 지원 (IC, 온콜, 리더십, 서포트 등 각각 필요한 수준만 수신).
  3. 단일, 정본(status canonical) 아티팩트를 강하게 밀어줍니다.
    • 외부용: 상태 페이지(status page), 고객용 업데이트 문서.
    • 내부용: 인시던트 타임라인 + 소유자 필드.

목표는 특히 여러 팀과 여러 도구가 섞였을 때 소음은 줄이고, 신호는 더 또렷하게 만드는 것입니다.

사실 기반, 포커스 있는 회고 운영하기

경기가 끝난 후 좋은 팀은 경기 영상을 보며 분석합니다. 장애도 마찬가지입니다.

**집중형 회고(focused retrospective)**는 다음을 갖춰야 합니다.

  1. 의견이 아니라 사실 수집

    • 타임라인: 누가, 언제, 무엇을 했는지, 링크 포함.
    • 지표: MTTD(탐지까지 시간), MTTA(인지까지 시간), MTTR(복구까지 시간), 영향 지속 시간, 고객 영향 규모 등.

  2. 기여 요인(contributing factors) 정의

    • 기술: 아키텍처 한계, 용량(capacity) 부족, 보호 장치 미비.
    • 프로세스: 런북 부재, 인수인계 불명확, 승인 절차 지연.
    • 사람: 피로, 교육 부족, 역할 혼선.

  3. 후속 액션 우선순위화

    • 각 액션에는 반드시:
      • 명확한 오너(owner)
      • 마감일(due date)
      • 비즈니스 임팩트 근거
    • 리더십이 맡아야 할 일도 명시적으로: 예산/인력/도구 투자, 정책 변경 등.

회고는 블레이멀리스(blameless) 하되, 동시에 **책임감(accountability)**을 가져야 합니다. 목적은 사람을 탓하는 게 아니라 시스템을 개선하는 것이고, 그러면서도 액션 아이템이 공중으로 사라지지 않도록 하는 것입니다.

재사용 가능한 인시던트 대응 플레이북으로 표준화하기

매번 장애가 날 때마다 처음부터 계획을 짜고 싶지는 않을 것입니다. 그래서 **인시던트 대응 플레이북(incident response playbook)**이 필요합니다.

오픈소스인 AWS Incident Response Playbooks (aws-samples/aws-incident-response-playbooks 리포지토리)를 좋은 출발점으로 삼을 수 있습니다.

플레이북을 사용하거나 커스터마이징해서 다음을 표준화하세요.

  • 역할과 책임(roles & responsibilities) 정리 (IC, Ops Lead, Comms Lead 등).
  • 자주 발생하는 시나리오에 대한 체크리스트 문서화 (DB 과부하, 리전 장애, 인증/로그인 장애 등).
  • 팀 및 타임존 간 인수인계 패턴 정의.
  • 에스컬레이션 로직과 알림 규칙을 명시.

그리고 다시 커뮤니티에 기여하세요.

  • 여러 팀이 얽힌 장애에 대해 개선된 런북.
  • SRE, 플랫폼, 프로덕트 팀, 서포트 간 바통을 어떻게 넘기는지 담은 신규 플레이북 등.

시간이 지날수록 여러분의 “아날로그” 프로세스는 스크립트로 자동화할 만큼 믿을 수 있게 되고, “종이 바통”은 모두가 익숙하게 쓰는 템플릿으로 자리 잡게 됩니다.

모두 엮어서 정리해 보기

잘 운영되는 인시던트 대응은 누군가의 영웅적인 활약이 아니라, **잘 짜인 안무(choreography)**에 가깝습니다.

여러 팀이 얽힌 장애를 잘 돌아가는 계주로 만들려면 다음을 실천하세요.

  • 인시던트 라이프사이클을 **계주 구간(legs)**으로 나누고, 각 구간에 명확한 오너를 붙인다.
  • 구조화된 명시적 인수인계를 사용해 바통이 바닥에 떨어지지 않게 한다.
  • 예측 알림과 시간 기반 에스컬레이션으로 더 빠르게 감지하고 대응한다.
  • 알림을 조율하고(throttle) 중앙에서 관리해 알림 폭주와 피로도를 줄인다.
  • 집중형 회고를 통해 고통스러운 경험을 우선순위가 명확한 액션으로 전환한다.
  • aws-samples/aws-incident-response-playbooks를 포함한 재사용 가능한 플레이북을 구축·공유해 팀 간 협업 방식을 표준화한다.

장애 상황에서 여전히 종이에 메모를 휘갈겨 쓰게 될 수도 있습니다. 괜찮습니다. 중요한 건, 그 모든 낙서가 결국에는 명확한 바통 하나로 모여서, 한 오너에서 다음 오너로 깔끔하게 전달되고, 인시던트가 “복구 완료”를 넘어 진짜로 끝났다고 말할 수 있는 지점까지 이어지는 것입니다.

아날로그 장애 계주: 여러 팀이 얽힌 장애를 종이 바통처럼 깔끔하게 넘기는 법 | Rain Lag