아날로그 인시던트 우체국: 장애 ‘편지’를 위기 되기 전에 라우팅하는 법

아날로그 인시던트 스토리 우체국: 장애 ‘편지’를 위기 되기 전에 라우팅하기

대부분의 팀은 인시던트 접수 프로세스가 얼마나 허술한지, 정말로 무언가가 “불타고” 나서야 깨닫습니다.

어느 날 누군가 Slack 채널에 애매한 메시지를 하나 남깁니다.

“결제 좀 느린 것 같은데요? 다른 사람들도 그러세요?”

그러면 바로 추리 게임이 시작됩니다.

어떤 시스템?
언제부터?
얼마나 심각한데?
누가 책임자야?

이 질문들에 답을 얻었을 즈음이면, 이미 차분한 인시던트 관리가 아니라 불끄기 비상 대응을 하고 있게 됩니다.

이보다 나은 방법이 있습니다. 핵심은 인시던트를 우체국을 통과하는 종이 편지처럼 바라보는 데서 시작합니다.

왜 느슨한 인시던트 접수 방식은 위기 상황에서 무너질까

인시던트가 아무렇게나 들어오면—랜덤한 이메일, 여기저기 흩어진 채팅, 복도에서 주고받은 말들—팀은 실질적인 기술 대응에 들어가기 전에, 우선 수사부터 해야 하는 상황에 놓입니다.

이런 비구조화된 접수의 공통점은:

보고 형식이 제각각이다
필요한 정보가 들어 있을지 보장할 수 없다
보고가 들어와도 명확한 최초 담당자가 없다
긴급도에 대한 공통 인식이 없다

그래서 인시던트 하나 들어올 때마다 똑같은 마찰이 반복됩니다.

“뭐가 고장났어요?” → “어디서요?” → “언제부터요?” → “사용자는 얼마나 영향 받아요?” → “이거 급한 건가요?”

이 과정이 초반 트리아지를 느리게 만들고, “이게 뭔가요?”, “누가 맡아야 하죠?”, “얼마나 심각하죠?” 같은 가장 기본적인 질문조차 노가다성 추측 작업으로 변합니다.

대신, 크고 작든 모든 인시던트 보고를 우체국에 들어오는 종이 편지 한 통처럼 다뤄보세요.

인시던트 우체국 비유

당신의 팀이 하나의 **인시던트 스토리 우체국(Incident Story Post Office)**이라고 상상해 봅시다.

누군가 문제가 있다고 보고하는 순간, 그 사람은 당신에게 ‘장애 편지(failure letter)’ 한 통을 쓰는 것입니다. 우체국인 당신의 할 일은:

그 편지를 접수하고
목적지와 우선순위에 따라 분류하고
올바른 “우편함”(팀, 담당자, 큐)으로 라우팅하고
추적 가능한 방식으로 전달하는 것입니다.

이 비유를 바탕으로 디지털 워크플로를 설계하면, 이런 시스템을 갖게 됩니다.

예측 가능: 편지가 어떻게 움직이는지 모두가 안다
탄탄함: 상황이 혼란스러워도 프로세스는 그대로 동작한다
가시성: 인시던트가 지금 흐름의 어디쯤 있는지 보인다

이걸 단계별로 쪼개 보겠습니다.

1단계: 명확한 인시던트 커뮤니케이션 프로토콜 설계하기

잘 작동하는 우체국에서는 사람들이 편지를 어떻게 보내야 하는지 알고 있습니다. 어디에 넣어야 하는지, 어떻게 주소를 써야 하는지, 우표는 어떻게 붙여야 하는지요.

인시던트도 마찬가지로, 팀에 명확한 규칙이 필요합니다.

먼저, 다음 질문에 답할 수 있는 인시던트 커뮤니케이션 프로토콜을 정의하고 문서화하세요.

인시던트는 어디에 보고하나요? (예: 특정 폼, 전용 채널, 티켓 시스템)
인시던트는 어떻게 작성하나요? (필수 필드, 형식)
누가 최초 트리아지를 맡나요?
어떤 기준과 시점에 따라 에스컬레이션되나요?
진행 상황과 해결 결과는 어떻게, 언제, 누구에게 공유되나요?

그리고 이 내용을 모두가 찾기 쉬운 곳에 올려두세요. 예를 들면:

사내 위키
온보딩 문서
메인 채팅 채널의 고정 메시지

목표는 단순합니다. 누구도 더 이상 이렇게 묻지 않게 만드는 것:

“이거 어디에 보고해야 하죠?”
“보내고 나면 어떻게 되는 건가요?”

2단계: ‘편지’ 표준화하기 — 인시던트 리포트 템플릿

우체국은 주소를 반만 쓰고 우표도 없는 봉투를 받아주지 않습니다. 그런데 많은 팀은 실제로 내용이 거의 없는 인시던트 보고도 그대로 받습니다. 대충 이런 식이죠.

“고장 난 것 같아요.”

빠르게 움직이려면, 모든 인시던트 보고에 반드시 포함돼야 하는 정보를 표준화해야 합니다. 이렇게 하면 불필요한 되물음이 줄어들고, 진단 속도가 빨라집니다.

예를 들어 이런 심플한 템플릿이 꽤 강력합니다.

Reporter (보고자): 누가 올렸나요? (이름, 팀, 연락처)
System / Service (시스템 / 서비스): 어떤 제품, 컴포넌트, 환경인가요?
Timeframe (시간 범위): 언제부터 시작됐나요? 지금도 계속되나요? 이전에도 있었나요?
Symptoms (증상): 정확히 어떤 일이 벌어지나요? (에러 메시지, 동작, 관련 메트릭)
Impact (영향 범위): 누가 영향 받고 있나요? (사내 사용자, 외부 고객, 특정 리전 등)
Severity (심각도 추정): Critical / High / Medium / Low
Reproduction steps (재현 방법, 알고 있다면): 어떻게 하면 재현되나요?
Attachments / Evidence (첨부 / 증거): 스크린샷, 로그, URL 등

이 구조는 다음과 같은 도구를 통해 강제할 수 있습니다.

전용 인시던트 신고 폼
정해진 형식의 Slack 명령어나 봇
이슈 트래커(Jira 등)의 티켓 템플릿

핵심은 일관성입니다. 모든 ‘편지’가 같은 기본 필드를 담고 들어오게 만들어야, 트리아지가 더 이상 이렇게 시작되지 않습니다.

“조금 더 자세히 써서 다시 보내주실 수 있을까요?”

3단계: 명시적인 우선순위 레벨을 만들고, 행동과 연결하기

우편물 중에서도 모든 편지가 같은 취급을 받지는 않습니다. **익일 특급(overnight)**은 일반 우편과 전혀 다르게 처리되죠.

인시던트도 마찬가지로, 명확한 우선순위 프레임워크가 필요합니다. 흔히 쓰는 예시는 다음과 같습니다.

Critical (P0): 전체 서비스 장애, 심각한 데이터 손실, 중대한 보안 이슈나 법적 리스크. 24/7 즉각 대응.
High (P1): 많은 사용자에게 주요 기능이 망가졌지만, 우회 방법이 있거나 영향 범위가 제한적인 경우.
Medium (P2): 성능 저하, 비핵심 기능의 문제, 일부 고객에게만 영향을 주는 버그.
Low (P3/P4): UI 깨짐, 사소한 불편, 나중에 처리해도 되는 요청.

그리고 각 레벨마다 반드시 구체적인 대응 기대치를 연결해야 합니다.

누가 호출(paging) 대상인지 (있는 경우)
**응답(acknowledge)**까지 목표 시간
완화/조치 시작까지 목표 시간
이해관계자에게 커뮤니케이션하는 주기

이 기준은 모두가 볼 수 있게 공유해야 합니다. 중요한 건 단지 라벨을 붙이는 게 아니라, 그 라벨이 구체적인 행동과 타임라인에서 무엇을 의미하는지 모두가 이해하는 것입니다.

4단계: 라우팅을 ‘보이게’ 만들고 추적 가능하게 하기

잘 운영되는 우체국에서는 우편물이 어디에 있는지 알 수 있습니다. 수거됨 → 분류 중 → 이동 중 → 배송 중.

인시던트도 이와 비슷한 수준의 가시성이 필요합니다.

인시던트 보고가 들어오면, 즉시 최초 책임자가 지정됩니다. (예: “On-call Incident Commander” 같은 온콜 역할)
인시던트의 상태가 보입니다. 예: New → Triage → In Progress → Monitoring → Resolved → Postmortem
누가 지금 이 인시던트를 소유하고 있는지, 다음에 무슨 일이 일어나는지 누구나 볼 수 있어야 합니다.

이를 구현하는 방법은 여러 가지가 있습니다.

중앙 인시던트 대시보드 운영
티켓과 연동된 전용 인시던트 채널 운영
인시던트 상태 변경 시 자동으로 상태를 업데이트하고 담당자에게 알리는 자동화

결과적으로 이런 상태가 됩니다.

“유실된 편지”라는 개념이 없다.

어떤 인시던트든, 시스템 안에서 자기가 있어야 할 위치와 상태가 항상 보입니다.

5단계: 디지털 워크플로를 우편물 처리 단계에 매핑하기

이제까지의 요소를 모두 합쳐 물리적인 우편 처리 과정과 1:1로 대응되는 워크플로를 만들 차례입니다.

1. Intake (우편 투입함)

보고자는 표준 인시던트 폼이나 명령어를 사용합니다.
필수 필드가 모두 채워졌는지 기본 검증을 합니다.
고유 ID를 가진 티켓/레코드가 자동 생성됩니다.

2. Sorting (초기 트리아지)

온콜 트리아지 담당자가 새 인시던트를 검토합니다.
보고된 심각도(severity)를 확인하거나 조정합니다.
적절한 시스템, 팀, 카테고리 태그를 붙입니다.

3. Routing (올바른 우편함으로 라우팅)

태그와 우선순위를 기준으로 인시던트를 다음과 같이 처리합니다.
- 특정 담당자나 팀에 직접 할당
- 긴급하지 않은 이슈라면 적절한 백로그/스프린트 큐에 추가
- Critical/High는 전용 인시던트 대응 프로세스로 에스컬레이션

4. Delivery and Tracking (전달 및 추적)

**소유권(ownership)**이 명확하게 기록됩니다.
정해진 위치(티켓, 채널, 상태 페이지 등)에 상태 업데이트가 올라갑니다.
해결되면 보고자와 이해관계자 모두에게 알립니다.
심각한 인시던트의 경우, 후속 사후 분석(Post-incident review/postmortem) 일정을 잡습니다.

이렇게 디지털 단계 하나하나를 접수 → 분류 → 라우팅 → 전달이라는 아날로그 우편 과정에 대응시키면, 워크플로는 설명하기도, 디버깅하기도, 개선하기도 쉬워집니다.

6단계: 화재 진압이 아니라 우체국처럼 조금씩 개선하기

현실의 우편 시스템은 끊임없이 개선됩니다. 더 빠른 분류 기계, 더 직관적인 주소 표기 방식, 더 효율적인 배송 루트 등.

인시던트 프로세스도 똑같이 다뤄야 합니다.

최근 인시던트를 정기적으로 리뷰하세요. 어디에서 라우팅이 느려졌는지, 어떤 정보가 자주 빠졌는지를 보세요.
실제 겪은 불편을 바탕으로 템플릿과 프로토콜을 조금씩 손봅니다.
신규 팀원 온보딩에 “인시던트 우편실(메일룸)” 교육을 포함시키세요.
다음과 같은 메트릭을 가시화하세요.
- Time to Triage (초기 트리아지까지 걸린 시간)
- Time to Assign (책임자 지정까지 걸린 시간)
- 우선순위 레벨별 Time to Resolve (해결까지 걸린 시간)

처음부터 완벽한 시스템을 만드는 게 목적이 아닙니다. 사용할수록 점점 나아지는 시스템을 만드는 것이 목적입니다.

결론: 비상사태가 나기 전에 우편실부터 설계하라

인시던트는 언제나 발생합니다. 그것을 대형 비상사태로 바꾸는 건, 종종 장애 그 자체가 아니라, 장애가 조직 안으로 어떻게 들어오고, 어떻게 흘러가는지에 대한 혼란입니다.

인시던트 보고를 **‘장애 편지(failure letter)’**로, 팀을 인시던트 스토리 우체국으로 바라보면 다음과 같은 효과를 얻습니다.

접수 단계에서의 추측과 재질문을 없앤다
빠르게 대응하는 데 필요한 정보를 표준화한다
심각도 레벨을 구체적인 대응 행동과 연결한다
라우팅 과정을 보이고, 추적 가능하고, 감사 가능하게 만든다
예측 가능하고 탄탄한 디지털 워크플로를 구축한다

이를 위해 거창한 툴이 반드시 필요한 것은 아닙니다. 더 중요한 것은:

명확한 프로토콜
표준화된 “봉투” 역할을 하는 인시던트 리포트 양식
모든 인시던트는 신뢰할 수 있는 우편 시스템을 통해 처리되어야 하는 한 통의 편지라는 공감대

다음 비상사태가 터지기 전에, 지금 당신만의 인시던트 우체국을 설계하세요. 그러면 앞으로는 문제의 원인을 해결하는 데 더 많은 시간을 쓰고, “편지가 도대체 어디로 사라졌지?”를 찾는 데 쓰는 시간은 훨씬 줄어들 겁니다.