아날로그 장애 스토리 기차표 매표소: 최악의 장애 속에서도 작동하는 작은 종이 티켓 시스템

새벽 3시에 시스템이 녹아내리는 상황에서, 누구도 또 하나의 복잡한 툴, 또 하나의 대시보드, 또 하나의 “단일 창(single pane of glass)” 같은 걸 배우고 싶어 하지 않는다. 다들 이미 뭐가 어디에 있는지 기억도 잘 안 난다.

대신, 굉장히 단순한 것을 떠올려 보자. 장애를 위한 아날로그 기차표 매표소다.

무언가 망가질 때마다, 누군가 이 매표소로 걸어와 작은 종이 티켓 하나를 받는다. 이건 작은 표준 양식의 “장애 스토리 패스”로, 핵심 정보만 담는다. 무슨 일이 일어났는지, 누가 관련되어 있는지, 다음 단계는 무엇인지, 그리고 이 이벤트가 이번 장애라는 더 큰 그림 속에서 어디쯤에 위치하는지를 적는다.

물론 이건 은유다. 하지만 매우 강력한 설계 제약이기도 하다.

당신의 장애 대응 도구와 프로세스가 물리적인 매표소만큼 제약적이고, 눈에 잘 보이고, 단순하다면 — 최악의 장애 상황에서도 여전히 잘 작동할까?

이 글에서는 이 “아날로그 티켓 매표소”라는 아이디어를 가지고 다음을 살펴본다.

왜 장애는 작은 오류가 아니라 **음속 폭음(sonic boom)**처럼 느껴지는지
시각적 워크플로우가 스트레스 상황에서 대응을 더 일관되게 만드는 이유
자동화가 정말로 도움이 되는 지점과, 오히려 해가 될 수 있는 지점
더 잘하고 싶다면 피드백 루프가 선택이 아닌 필수인 이유
휴먼 팩터와 다학제적 디자인이 어떻게 툴을 ‘진짜 도움 되는 시스템’으로 바꾸는지

음속 폭음과 충격파: 장애는 한 자리에 머물지 않는다

대부분의 장애 대응 도구는 실패가 작고, 국지적이고, 선형적이라고 가정하고 설계된다. 입력 오류 → 실패 → 알림 → 수정 — 이런 식이다.

현실은 **음속 폭음(sonic boom)**에 더 가깝다.

제트기가 어느 시점, 어느 지점에서 음속 장벽을 돌파한다.
우리가 땅에서 듣는 폭음은 나중에, 한 점이 아니라 선을 따라 들려온다.
충격은 시작 지점이 아니라, **이동하는 전면(front)**에서 경험된다.

장애도 비슷하게 동작한다.

트리거(Trigger): 10:02에 미묘한 버그가 포함된 배포가 나간다.
충격파(Shockwave): 캐시가 무효화되고, 큐가 밀리기 시작하고, 재시도가 쌓인다.
폭음(Boom): 10:20이 되면 고객이 로그인할 수 없고, 대시보드는 새빨개지고, 온콜이 호출된다.

실제 고통은 종종 실패의 발단이 아니라, 충격파의 전면에서 발생한다. SRE는 불완전한 정보들을 juggling 하고, 고객 지원팀은 문의 폭주에 시달리고, 세일즈는 “무슨 일이냐”고 묻는다.

당신의 “장애 티켓 매표소”는 이 전면을 위해 설계되어야 한다.

단순한 원인 분석이 아니라, 충격파 전체의 스토리를 캡처해야 한다.
지금 우리가 충격파의 어디쯤에 있는지 — 시작, 중간, 복구 단계 — 를 볼 수 있게 해야 한다.
영향 범위가 넓어질수록 크로스팀 코디네이션을 지원해야 한다.

장애는 단일 이벤트가 아니다. 움직이고 확장되는 이야기다. 당신의 프로세스와 도구는 그것을 그렇게 취급해야 한다.

시각적 워크플로우: 매표소 뒤 지도를 모두가 보게 만들기

당신의 아날로그 매표소 뒤에 큰 지도가 하나 걸려 있다고 상상해 보자.

단계가 명확하고
역할이 분명하고
인계 지점이 정의되어 있다.

누구든 창구로 와서 똑같은 지도를 본다. 혼란의 한가운데에서 “우리가 보통 하던 방식이 뭐였더라” 하고 추측할 필요가 없다.

이게 바로 시각적 장애 워크플로우 다이어그램이 주는 효과다.

좋은 장애 워크플로우 다이어그램이 보여줘야 할 것들

최소한, 다이어그램은 다음을 분명히 보여줘야 한다.

진입점(Entry points)
- 누가 장애를 선언할 수 있는가?
- P0, P1 등급은 무엇을 기준으로 구분하는가?
역할과 책임(Roles & Responsibilities)
- Incident Commander(IC, 장애 지휘자): 전체를 조율하고 의사 결정을 내린다.
- Communications Lead(커뮤니케이션 리드): 이해관계자와 고객에게 상황을 공유한다.
- Operations Leads(오퍼레이션 리드): 원인 분석과 복구 작업을 수행한다.
- Scribe/Recorder(기록 담당): 이벤트, 결정, 타임스탬프를 기록한다.
핵심 단계(Core phases)
- 탐지 & 트리아지(Detection & Triage)
- 안정화(Stabilization)
- 완화 & 우회(Mitigation & Workaround)
- 검증(Verification)
- 종료 & 리뷰 일정 수립(Closure & Review Scheduling)
핸드오프(Handoffs)
- 누가, 언제, 무엇을 누구에게 넘기는가?
- “실시간 대응”에서 “사후 학습(Post-incident learning)”으로 어떻게 넘겨 가는가?

이 다이어그램은 눈에 띄지만 심심할 정도로 평범한 곳에 붙어 있어야 한다.

온콜 런북 옆
장애 대응 툴 UI 안
(정말로) 출력해서 팀 공간에 붙여두기

스트레스 상황에서 뇌는 시각적 앵커를 좋아한다. 문서 링크는 까먹기 쉽지만, 사람들은 이런 건 기억한다. “지도 다음 박스가 뭐였지? → Slack 채널 업데이트 → 그다음 IC 선언.”

당신의 “매표소 직원”이 매번 지도를 새로 즉흥적으로 만들어낼 필요는 없어야 한다.

자동화: 창구 뒤에서 조용히 일하는 작은 로봇들

우리의 은유 속 매표소를 떠올려보면, 그 뒤에는 작지만 믿을 수 있는 기계들이 있다.

시간과 날짜를 도장 찍어주고
올바른 티켓 포맷으로 인쇄해주고
사본을 적절한 사무실로 보내준다.

사람이 모든 걸 손으로 베껴 쓸 필요는 없다. 사람은 상호작용, 판단, 이례적인 상황에 집중한다.

마찬가지로 장애 대응에서도, 선택적인 자동화는 다음을 줄여줄 때 강력하다.

수동 반복 업무(Manual toil): 반복적이고 판단이 거의 필요 없는 작업
조율 오버헤드(Coordination overhead): 누구를 불러야 하지? 어디에 기록하지?

판단이 아니라 ‘레일’을 자동화하라

좋은 자동화 후보는 다음과 같다.

Incident 채널 생성: 표준 템플릿이 포함된 이름 있는 채팅 채널을 자동으로 만든다.
역할 프롬프트(Role prompts): 첫 응답자에게 IC, 커뮤니케이션 리드 등의 역할을 선택·배정하도록 유도한다.
데이터 수집(Data gathering): 핵심 대시보드, 로그, 최근 배포 정보 등을 자동으로 첨부한다.
Status Page 스캐폴딩: 고객 공지용 템플릿을 미리 채워두고 승인만 받도록 한다.
타임라인 캡처(Timeline capture): 알림, 변경 이력, 주요 이벤트를 자동으로 로그에 쌓는다.

반대로, 다음은 자동화로 대체해서는 안 된다.

사람의 검토 없이 이루어지는 심각도(Severity) 결정
리뷰 없이 나가는 고객 커뮤니케이션
부분 롤백 vs 기능 플래그로 완화와 같은 복잡한 트레이드오프 판단

목표는 “셀프 드라이빙 장애 대응(Self-driving incident)”이 아니다. 목표는 이렇게 생각하는 것이다. 전원이 들어간 장애 매표소:

기계는 구조와 반복을 처리한다.
인간은 모호함과 결과(Consequence)를 책임진다.

피드백 루프: 모든 티켓은 결국 하나의 이야기로 돌아온다

작은 종이 티켓이 어디론가 서랍 속으로 사라지기만 한다면, 이 매표소는 영원히 나아지지 않는다. 같은 실수를 반복할 뿐이다.

장애 관리에서 **사후 리뷰(Post-incident review)**는, 티켓이 이야기로 돌아오는 과정이다.

최초 티켓에는 무엇이 적혀 있었는가? (증상, 담당자, 심각도 등)
충격파가 시스템 곳곳을 지나갈 때, 스토리는 어떻게 전개되었는가?
프로세스는 사람들을 어디에서 도와주었고, 어디에서 발목을 잡았는가?

진짜 도움이 되는 구조화된 리뷰 설계하기

탄탄한 리뷰 프로세스는 다음을 만족해야 한다.

항상, 예외 없이 진행된다
- “시간 나면 하자”가 아니라, 장애 종료 시점에 바로 일정을 잡는다.
블레임리스(Blameless)이지만 구체적이다
- 개인의 잘못이 아니라 시스템/프로세스 설계에 초점을 맞춘다.
여러 관점을 담는다
- 온콜 엔지니어, 프로덕트, 고객 지원, 필요하다면 고객의 관점까지.
구체적인 변경 사항을 남긴다
- 런북 업데이트
- 도구 개선
- 교육/훈련 혹은 역할 정의 명확화
다시 설계로 피드백된다
- 시각적 워크플로우를 조정할 필요가 있는가?
- 자동화는 도움이 되었는가, 방해가 되었는가?
- 사람들의 업무 부하는 적절했는가?

마지막 항목이 핵심이다. 당신의 매표소는 고정된 것이 아니다. 각 장애 스토리를 바탕으로 점진적으로 재설계된다.

휴먼 팩터: 창구 뒤에 있는 사람들

대부분의 장애 대응 툴은 무한한 집중력, 0의 스트레스, 완벽한 기억력을 전제로 한다. 실제 장애 상황에서는 그 어느 것도 존재하지 않는다.

효과적인 장애 관리는 다음을 고려해야 한다.

인지 부하(Cognitive load): 여러 대시보드, 메시지, 가설을 동시에 처리해야 하는 상황
인체공학(Ergonomics): 작은 노트북 화면, 불안정한 VPN, 피로, 시차 문제
사회기술 시스템(Sociotechnical dynamics): 위계, 커뮤니케이션 패턴, 말하지 않는 규범들

아날로그 매표소라는 은유는 이런 질문들을 던지게 도와준다.

대기열이 보이는가? 지금 무슨 일이 어디까지 진행되었는지, 누가 어떻게 도울 수 있는지 보이는가?
인터페이스가 단순한가? P0 상황에서 지친 엔지니어가 두세 번의 클릭만으로 필요한 것을 찾을 수 있는가?
역할이 명시적인가? 아니면 모두가 속으로 “누군가는 알아서 하겠지”라고 생각하는가?
혼란 없이 추가 지원을 요청할 수 있는 **명확한 비상 레버(escape hatch)**가 있는가?

장애 상황의 사람들은 이상적인 상태가 아니다. 스트레스 받고, 시간에 쫓기고, 완벽하지 않다. 그런 현실의 인간을 전제로 설계해야 한다.

다학제적 디자인: SRE와 개발만으로는 부족하다

훌륭한 장애 시스템은 SRE만으로는 나오지 않는다. 다음 분야에서 빌려온다.

HCI(Human–Computer Interaction): 사람들은 당신의 툴에서 상태(state), affordance, 피드백을 어떻게 인지하는가?
UX 디자인: 장애 플로우는 일관되고, 흐름이 자연스럽고, 발견 가능(discoverable)한가?
산업 디자인(Industrial design): 런북, 대시보드, UI 같은 장애 아티팩트는, 높은 부하 상황에서도 명확한 정보 계층과 단순성을 제공하는가?
시스템 엔지니어링(Systems engineering): 장애 동안 사회·기술·조직 요소가 전체 시스템으로서 어떻게 상호작용하는가?

당신의 장애 프로세스를 의도적으로 디자인된 제품으로 대하라. 우연히 모여든 스크립트와 Slack 채널 묶음으로 취급하지 말고.

다음과 같은 다학제적 질문을 던져보라.

신규 멤버가 매표소 UI를 5분 안에 이해할 수 있는가?
장애 중에, 매 단계마다 다음에 무엇을 해야 하는지가 명확한가?
게임데이(Game Day)처럼 장애를 시뮬레이션하여 이 프로세스의 사용성을 테스트할 수 있는가?
사람들이 가장 많이 버벅이는 지점은 어디인가? 거기를 도와줄 수 있도록 환경을 재설계할 수 있는가?

아날로그 매표소 은유는 강한 제약을 건다. 작은 창구, 짧은 대화, 작은 티켓 한 장. 그 안에서 이기는 것은 결국 명료함이다.

정리: 나만의 장애 티켓 매표소를 설계하는 법

이 은유를 실제로 적용해 보려면, 작게 시작해도 된다.

지도를 그려라
- 시각적 장애 워크플로우를 만든다. 출력하고, 공유하고, 팀과 함께 한 번 걸어가 본다.
티켓을 정의하라
- 모든 장애 기록에 반드시 들어가야 하는 정보를 표준화한다: 누가, 무엇을, 언제, 영향, 현재 상태, 다음 단계.
지루한 부분을 자동화하라
- 채널 생성, 템플릿, 타임라인 캡처를 자동화한다. 사람들은 어려운 문제에 집중하게 하라.
피드백 루프를 설치하라
- 사후 리뷰를 정례화하고, 구조화하며, 여러 직군이 함께 참여하도록 한다.
사람에게 맞춰 튜닝하라
- 클릭 수, 인지적 오버헤드, 애매함을 줄일 수 있는 곳이면 어디든 줄인다.

당신의 장애 대응 프로세스를 아날로그 기차표 매표소처럼 떠올릴 수 있다면 — 단순하고, 눈에 잘 보이고, 최악의 장애 중에도 쓸 수 있다면 — 올바른 방향으로 가고 있는 것이다.

결국 그 작은 종이 티켓들은 이런 의미일 뿐이다.

조직이 무슨 일이 있었는지 이해하고, 함께 대응하며, 다음 음속 폭음을 맞을 때 더 잘 준비되게 해 주는 공유된 이야기.