Rain Lag

아날로그 장애 우편물 우체국: 팀 문앞에 장애 서류가 쌓이기 전에 정리하는 법

우체국 메타포를 활용해 명확하고 시각적이며 신뢰할 수 있는 장애 접수·대응 시스템을 설계하고, 장애가 팀 문앞에 쌓이기 전에 처리하는 방법을 다룹니다.

소개

프로덕션 시스템을 운영하는 팀이라면 장애는 피할 수 없습니다. 피할 수 있는 건 그와 함께 따라오는 혼란입니다. 예를 들면:

  • 모호한 티켓
  • 불분명한 담당자
  • 알 수 없는 우선순위
  • “작은 문제”가 조용히 쌓이다가 어느 순간 큰 문제로 터지는 상황

이 혼란에 질서를 부여하는 한 가지 방법은 장애 관리를 옛날식 우체국 운영에 비유해 보는 것입니다.

  • 모든 장애는 **편지(우편물)**입니다.
  • 여러분의 팀은 분류 센터입니다.
  • 이해관계자는 제때, 정확한 배달을 받아야 하는 수신인입니다.

이 우체국 메타포를 제대로 받아들이면, 장애가 팀 문앞에 쌓여 넘치기 전에 눈에 잘 보이고, 예측 가능하며, 무시하기 어려운 장애 접수·처리 시스템을 설계할 수 있습니다.


1단계: 모든 장애를 ‘들어오는 편지’처럼 취급하기

많은 조직에서 장애는 이런저런 채널로 뒤섞여 들어옵니다. 슬랙 멘션, DM, 이메일, 회의 중 툴툴거림, 에러 대시보드 알림 등등. 이는 사람들이 우편함을 쓰지 않고 우편물 직원에게 직접 편지를 집어던지는 상황과 비슷합니다.

목표: 모든 장애가 하나의 예측 가능한 **“우편 투입구”**로만 들어오게 만들기.

장애 접수 창구를 실제 우체국 창구라고 생각해 보세요.

  1. 우편함 / 접수 폼

    • 모든 장애가 반드시 기록되는 **단일 채널(또는 최대한 적은 수의 채널)**을 둡니다.
    • 예: 전용 /incident 슬랙 커맨드, 간단한 웹 폼, Jira/ServiceNow의 “New Incident” 템플릿 등.
  2. 봉투에 도장 찍기(초기 기록)
    새로 접수되는 모든 장애에는 반드시 다음이 필요합니다:

    • 발생 시각 기록 (처음 관측된 시점)
    • 고유 ID 부여 (장애 번호)
    • 간단한 설명 (겉으로 보기엔 무엇이 잘못됐는가?)
  3. 고아가 된 편지는 없다
    시스템에 등록되지 않은 이슈는 존재하지 않는 것으로 간주합니다. 모두가 이렇게 기억하도록 훈련시키세요: “로그에 안 남으면, 그건 장애가 아니다.”
    이 원칙은 큐에 올라오지 않는 조용한 비공식 작업을 막고, 나중에 “이게 왜 이제서야?” 하는 놀라움을 줄여 줍니다.


2단계: 등기·특급처럼 명확한 심각도(Severity) 등급 정의하기

우체국은 모든 봉투를 똑같이 다루지 않습니다. 일반 우편, 우편, 특급 등 우편 등급이 있습니다. 장애도 똑같은 구조가 필요합니다.

영향도와 긴급성을 기준으로 명확한 심각도 레벨을 정의해 보세요. 예를 들면:

  • SEV0 – 치명적(Critical, 익일 특급/Express Overnight)

    • 전사(全社)적 서비스 중단, 큰 매출 손실, 법적·컴플라이언스 리스크 발생.
    • 즉시, 전원 총동원(all-hands-on-deck) 대응.
  • SEV1 – 높음(High, 우선/Priority Mail)

    • 성능이 크게 저하되었고 많은 사용자가 영향받지만, 일부 기능은 동작하는 상태.
    • 정의된 SLA 내에 빠른 대응 필요.
  • SEV2 – 중간(Medium, 일반/Regular Mail)

    • 영향 범위가 제한적이거나, 우회 방법이 있거나, 일부 사용자에게만 영향을 주는 경우.
    • 계획된 시간 안에 스케줄링해서 해결.
  • SEV3 – 낮음(Low, 대량/ Bulk Mail)

    • UI 깨짐, 사소한 불편, 내부에서만 보이는 자잘한 문제 등.
    • 여유 리소스가 있을 때 처리.

새로운 “편지”가 들어오면, 접수 담당자(또는 자동화 시스템)가 해당 장애에 심각도 도장을 찍습니다. 이 등급이 결정해 주는 것은:

  • 누구에게 알릴 것인지
  • 얼마나 빨리 대응해야 하는지
  • 어떤 수준의 절차(워룸, Status Page 공지 등)가 필요한지

이렇게 미리 합의해 두면, 매번 “이거 진짜 급한 거 맞아요?” 같은 소모적인 논쟁을 피할 수 있습니다. “급하다”의 기준을 미리 정의해 두는 셈입니다.


3단계: 분류 센터 안의 역할을 명확히 나누기

우체국에서는 모든 사람이 모든 일을 다 하지는 않습니다. 접수, 분류, 라우팅, 동네 배달 직원까지 역할이 나뉘어 있죠. 장애 대응도 마찬가지로 구조가 있어야 합니다.

일반적으로 다음과 같은 역할이 있습니다:

  • Incident Commander(장애 지휘관) – 현장 매니저. 조율, 의사결정, 현황 공유를 책임집니다. 장애마다 한 명.
  • Triage Engineer(트리아지 엔지니어) – 분류 담당. 실제 영향도를 확인하고, 데이터를 모으고, 적절한 전문가에게 일을 라우팅합니다.
  • Functional Responders(기능별 대응자) – 배달 직원. 데이터베이스, 프론트엔드, 인프라, 보안 등 각 영역에서 직접 원인 분석과 수정을 수행합니다.
  • Communications Lead(커뮤니케이션 리드) – 창구 직원. 이해관계자에게 상황을 공유하고, 공지·알림을 관리합니다.

핵심 규칙은 하나입니다: 모든 장애에는 명시적인 소유자가 있어야 한다. 마치 모든 편지에 받는 사람 주소가 있어야 하듯이.
소유권이 불분명한 장애는 주소가 없는 우편물과 같습니다. 어딘가에 방치되어 결국 잊혀지기 쉽습니다.


4단계: 칸반 보드로 흐름을 시각화하기

만약 우체국에 바구니도, 선반도, 시각적인 단서도 없이 바닥에 편지만 잔뜩 쌓여 있다고 상상해 보세요.
사실 많은 팀의 장애 백로그는 딱 이런 모습입니다.

칸반(Kanban) 스타일 보드는 이 우편 분류 선반에 해당합니다:

  • 대기(Waiting / Inbox) – 새로 접수되었지만 아직 트리아지되지 않은 장애.
  • 진행 중(In Progress) – 현재 적극적으로 처리 중인 장애.
  • 완료(Completed) – 해결되고 정식으로 종료된 장애.

이렇게 단순한 보드만 있어도 보이지 않던 일이 눈에 보이게 됩니다:

  • 인박스가 넘치고 있는지 한눈에 알 수 있습니다.
  • 어떤 장애가 ‘진행 중’에서 너무 오래 멈춰 있는지 포착할 수 있습니다.
  • 장애가 슬며시 사라지는 일을 막을 수 있습니다.

Jira, Trello, Linear 같은 도구나 커스텀 incident 앱 등 어떤 것도 좋습니다. 중요한 건 이 보드가 팀에게 항상 보이도록 유지하는 것입니다.


5단계: ‘진행 중’을 더 세분화된 우편 처리 단계로 나누기

환경이 복잡해질수록 “In Progress(진행 중)”만으로는 너무 모호합니다.
이는 “어딘가 우편 시스템 어딘가에 있음”이라는 안내문 하나만 있는 것과 같습니다. 어디에서 막혀 있는지 알아야 합니다.

“진행 중”을 장애 라이프사이클에 맞춘 여러 단계로 나눠 보세요:

  • Detected(감지됨) – 이슈가 관측되어 장애로 기록된 상태.
  • Triage in Progress(트리아지 진행 중) – 장애 여부를 검증하고, 영향도를 확인하며, 심각도를 책정 중.
  • Escalated / Assigned(에스컬레이션/할당됨) – 적절한 팀 또는 전문가에게 라우팅 완료.
  • Mitigating(완화 조치 중) – 임시 조치나 영구적인 수정 작업을 실제로 수행 중.
  • Monitoring(모니터링 중) – 조치 이후 시스템 안정성을 확인하는 단계.
  • Ready for Closure(종료 준비 완료) – 수정 내용이 검증되었고, 문서화와 후속 작업만 남아 있는 상태.

이 정도의 세분화는 다음과 같은 인사이트를 제공합니다:

  • 병목 지점 가시화 – 트리아지가 느린가? 에스컬레이션 단계에 이슈가 쌓이고 있는가? 수정은 끝났는데 종료 처리가 안 되고 있는가?
  • 용량 시그널 – 감지 단계에 사람이 부족한지, 트리아지를 더 자동화해야 하는지 등 리소스·도구 투자 포인트가 드러납니다.

택배 추적 시스템이 “어느 물류센터를 거쳤는지” 세세히 보여주듯, 여러분의 장애 워크플로도 각 장애가 어떤 단계에 있는지 명확히 드러나야 합니다.


6단계: 커뮤니케이션을 ‘배달 라우팅’으로 다루기

장애는 기술적인 문제이기도 하지만 동시에 커뮤니케이션 문제입니다. 우체국 메타포에서 커뮤니케이션은 곧 **배달 경로(route)**입니다.

각 장애에는 반드시 다음이 있어야 합니다:

  • 명확한 주소 레이블:

    • Owner(담당자): 이 장애를 끝까지 해결로 이끌 책임자.
    • Stakeholders(이해관계자): 상황을 공유해야 하는 사람들 (프로덕트, 고객지원, 리더십, 고객 등).
  • 정의된 라우팅 규칙과 업데이트 주기:

    • SEV0: 15–30분마다 진행 상황 업데이트.
    • SEV1: 1시간마다, 또는 주요 마일스톤마다.
    • SEV2/3: 하루 1회 또는 중요 포인트에 맞춰.
  • 표준화된 메시지 템플릿:
    업데이트는 구조화된 형식을 유지하는 것이 좋습니다. 예를 들면:

    • 무엇이 발생했는지(What happened)
    • 누가/무엇이 영향받고 있는지(Who/What is impacted)
    • 지금 무엇을 하고 있는지(What’s being done now)
    • 다음 업데이트 예정 시각(Next update time)

이런 정의가 없다면, 우편으로 치면 잘못 배달되거나 분실된 우편물과 같은 상황이 벌어집니다.
루머가 돌고, 중복 작업이 생기고, 고객은 좌절하게 됩니다.


7단계: 장애용 ‘우체국 앱’을 구축하거나 도입하기

화이트보드와 스프레드시트만으로도 어느 정도 운영은 가능합니다. 하지만 시간이 지날수록 이 우체국 메타포를 전용 앱 안에 녹여 두는 것이 큰 도움이 됩니다.

장애 추적 및 포스트모템 도구는 다음을 지원해야 합니다:

  • 여러분이 중요하게 여기는 모든 메타데이터(심각도, 담당자, 영향도, 영향받은 시스템, 타임라인 등)를 캡처.
  • 정의한 워크플로 단계 구현
    (Detected → Triage → Escalated → Mitigating → Monitoring → Completed 등).
  • 커뮤니케이션 채널과의 연동 (Slack, 이메일, Status Page 등).
  • 장애와 바로 연결되는 Postmortem / 사후 리뷰 기능.

상용 툴을 커스터마이즈하든, 직접 내부 시스템을 구축하든 원리는 같습니다.
이 앱이 디지털 우체국처럼 동작하게 만드는 것입니다.

  • 편지가 들어오고(Letters in)
  • 도장이 찍히고(stamped)
  • 분류되고(sorted)
  • 라우팅되고(routed)
  • 추적되며(tracked)
  • 보관·아카이브(archived)되는 전체 흐름을 담아야 합니다.

8단계: 사후 리뷰를 ‘반송(Return to Sender)’ 피드백 루프로 활용하기

포스트-인시던트 리뷰(사후 장애 리뷰)는 여러분의 우편 시스템이 학습하는 단계입니다.

이를 “반송(Return to Sender)” 루프라고 생각해 보세요:

  • 어떤 장애는 잘못 분류되었나요? (심각도 도장이 틀렸던 경우)
  • 어디에서 라우팅이 실패했나요? (잘못된 팀에 보내졌거나, 여기저기 떠돌다가 시간이 지연된 경우)
  • 어떤 유형의 “우편물”이 계속 되돌아오나요? (같은 근본 원인으로 반복 발생하는 장애)
  • 어디에서 커뮤니케이션이 무너졌나요? (이해관계자가 뒤늦게 알게 되었거나, 고객에게 충분히 안내되지 않은 경우)

좋은 포스트모템은 단순히 “무엇이 고장났는가?”만 묻지 않습니다. 대신 다음을 묻습니다:

  • 더 빨리 감지할 수 있었던 방법은 무엇인가?
    (더 나은 우편 투입구와 센서를 두는 방법)
  • 더 잘 라우팅할 수 있는 방법은 무엇인가?
    (더 명확한 주소 체계와 분류 규칙)
  • 다음번에는 더 쉽게 처리하려면 무엇이 필요할까?
    (런북, 자동화, 교육 등)

각 리뷰는 곧 분류 규칙, 라우팅 경로, 처리 절차를 개선할 수 있는 기회입니다.
그 결과, 다음 번에는 더 적은 장애가 길을 잃거나 지연되겠죠.


결론

구조 없이 장애 대응을 운영하는 것은, 바구니도, 동선도, 도장도 없는 우체국을 운영하는 것과 같습니다.
우편물이 어딘가로 가긴 가겠지만, 신뢰할 수 없고, 예측 가능하지도 않습니다.

장애 시스템을 **“장애 우편물 우체국”**처럼 다루면 다음을 할 수 있습니다:

  • 장애가 우리 세계로 들어오는 방식을 표준화한다
    (혼란이 아닌, 하나의 우편 투입구).
  • 명확한 심각도 “등급”으로 분류·우선순위를 정한다.
  • 칸반 보드와 세분화된 단계로 흐름을 시각화한다.
  • 올바른 사람에게, 올바른 타이밍에 커뮤니케이션을 라우팅한다.
  • 포스트-인시던트 “반송(Return to Sender)” 루프로 지속적으로 개선한다.

완벽한 툴이 있어야만 시작할 수 있는 것은 아닙니다. 필요한 것은 **공유된 정신 모델(shared mental model)**입니다.

이 메타포로부터 시작해 보세요:
모든 장애는 한 통의 편지이고, 여러분의 일은 어떤 편지도 잃어버리지 않는 것이다.
도장을 찍고, 분류하고, 라우팅하고, 배달하고, 그로부터 학습해 다음 번 우편물이 팀 문앞에 도착하기 전에 더 잘 대비하는 것입니다.

아날로그 장애 우편물 우체국: 팀 문앞에 장애 서류가 쌓이기 전에 정리하는 법 | Rain Lag