종이 인시던트 컴퍼스 룸: 온콜 의사결정을 위한 아날로그 노스 스타 손그리기

모든 게 불타고 있을 때, 우리의 뇌는 최상의 상태가 아니다.

스트레스가 높아지면 시야는 좁아지고, 기억은 흐릿해지고, 숙련된 엔지니어조차 기본적인 단계조차 잊어버릴 수 있다. 그래서 가장 미션 크리티컬한 분야들—소방, 항공, 응급의학—은 로우테크지만 매우 구조화된 도구에 의존한다. 화이트보드, 클립보드, 코팅된 체크리스트, 시각적인 지휘 시스템 같은 것들이다.

소프트웨어 팀도 똑같은 패턴을 가져올 수 있다.

이 글에서는 “종이 인시던트 컴퍼스 룸(Paper Incident Compass Room)” 아이디어를 다룬다. 팀이 물리적·아날로그 환경에서 직접 노스 스타(north star) 를 그려 넣는 공간—시스템이 실패했을 때 온콜 의사결정의 기준이 되는, 명확하고 단순한 안내선들이다.

디지털 시대에도 아날로그 도구가 여전히 중요한 이유

모든 것이 대시보드, 채팅 도구, 복잡한 오브저버빌리티 플랫폼을 통해 흘러가다 보면, 인시던트의 혼란을 해결할 답이 더 많은 소프트웨어라고 착각하기 쉽다.

하지만 고스트레스 상황에서는:

• 사람들은 링크가 어디 있는지 기억하지 못한다.
• 대시보드는 타임아웃되거나 노이즈로 가득 찬다.
• 컨텍스트는 수십 개의 브라우저 탭에 흩어져 버린다.

아날로그 도구는 이를 다음과 같은 방식으로 잘라낸다:

• 시각적 – 모두가 손가락으로 가리킬 수 있는 단일한 공유 현실.
• 단순함 – 로그인도, 로딩도, “그 페이지 어디 있었지?”도 필요 없다.
• 복원력 – VPN이나 SSO 제공자가 죽어도 같이 죽지 않는다.

긴급 대응 조직은 이런 원칙 위에 구축된 구조화된 지휘 시스템(ICS/NIMS 같은 것들)을 사용한다. 명확하게 정의된 역할, 시각적 보드, 표준화된 플레이북들이다. 소프트웨어 팀도 비슷한 개념을 가볍고 로우테크하게 도입할 수 있다.

그게 바로 종이 인시던트 컴퍼스 룸이 등장하는 지점이다.

“종이 인시던트 컴퍼스 룸”이란 무엇인가?

이걸 라이트웨이트 인시던트 커맨드 센터라고 생각하면 된다. 다만 종이 기반이라는 점이 다르다.

• 현재 인시던트를 시각적으로 맵핑하는 물리적인 공간(회의실 한 칸이나 화이트보드 벽면이면 충분하다).
• 타임라인, 임팩트 맵, 에스컬레이션 트리 같은 단순한 손그림 아티팩트.
• 출력하거나 손으로 적어둔 런북(runbook) 과 체크리스트—당신의 “노스 스타” 역할을 하는 것들.

특별한 워룸이 필요하지 않다. 작은 회의실, 클립보드 몇 개, 혹은 노트북 앞에 펼쳐놓을 노트 한 권이면 충분하다. 중요한 것은 가구가 아니다. 마인드셋이다.

위기 상황에서는 단순하고, 공유되고, 눈에 잘 보이는 가이드를 기본값으로 삼는다.

런북: 아날로그 노스 스타의 중심

컴퍼스 룸의 핵심에는 런북(runbook) 이 있다. 흔히 발생하는 장애 양상에 대해 미리 정의된 단계별 안내서다.

런북은 온콜 엔지니어를 다음과 같이 돕는다:

• 피곤하거나 스트레스를 받을 때 인지 부하를 줄여준다.
• 중요한 점검 항목을 빼먹지 않게 해준다.
• 인시던트가 새롭고 낯선 상황일 때도 최소한의 기본 접근 방식을 제공한다.

좋은 런북의 조건

탄탄한 인시던트 런북은 다음과 같다.

• 짧다 – 시나리오 하나당 최대 1–2페이지.
• 액션 지향적이다 – 이론 설명이 아니라 "X를 확인", "Y를 실행"처럼 행동 단위로 써야 한다.
• 무자비하게 명확하다 – 독자가 피곤하고, 급하고, 산만하다는 전제를 깔고 쓴다.

전형적인 구조는 다음과 비슷하다.

1. 트리거(Trigger) – 이 런북을 언제 사용할지 (예: "API p95 latency > 2초가 5분 이상 지속될 때").
2. 즉각 조치(처음 5분) – 안정화 단계:
   • 1차 온콜을 페이징한다.
   • 알림을 확인(ack)한다.
   • 인시던트 채널에 짧은 상태 업데이트를 남긴다.
3. 진단(Diagnostics) – 무엇을 어떤 순서로 확인할지.
4. 알려진 해결책 / 우회책 – 서비스를 복구하기 위한 전술적 접근들.
5. 에스컬레이션(Escalation) – 복구가 진전되지 않을 때 누구에게, 언제 escalation 할지.

이걸 출력해서 바인더에 꽂자. 바인더 옆면을 보기 쉽게 적는다: “API 인시던트”, “데이터베이스 인시던트”, **“결제 인시던트”**처럼. 이렇게 하면 위기 상황에서 실제 손에 쥘 수 있는 아날로그 노스 스타가 된다.

에스컬레이션 트리: 누구에게 언제 연락할지 한눈에 보기

인시던트 중에 시간을 가장 많이 허비하는 것 중 하나가 무엇을 누가 책임지는지 모르는 것이다.

간단한 에스컬레이션 트리(escalation tree) 는 다음 질문에 답한다.

• 현재 온콜은 누구인가?
• 백업 온콜은 누구인가?
• 이 서브시스템 또는 벤더는 누가 커버하는가?
• 위험이 있는 결정을 최종 승인할 권한은 누구에게 있는가? (예: 기능 플래그 끄기, 페일오버, 트래픽 셰딩 등)

유용한 에스컬레이션 트리를 그리는 방법

화이트보드나 종이에 다음처럼 그린다.

• 맨 위에 Incident Commander(IC, 인시던트 커맨더) 를 적는다.
• 아래로 가지를 뻗어 다음을 연결한다.
  • Tech Lead / 도메인 전문가 (예: 데이터베이스, 네트워킹, 결제 등)
  • 커뮤니케이션 / 이해관계자 연락 담당 (예: 프로덕트, 고객지원)
  • 온콜 로테이션 (SRE, 애플리케이션 팀, 인프라 팀 등)

각 노드 옆에는 다음을 적는다.

• 이름
• 연락 수단 (Slack 핸들, 전화번호, 백업 채널)
• 시간 기준 (예: "10분간 개선이 없으면 페이징")

그리고 이 에스컬레이션 트리를 런북과 온콜 문서에도 반영한다. 동시에 인시던트 동안에는 수기로 그린 버전을 컴퍼스 룸에 항상 보이게 두어 애매한 부분이 없도록 한다.

알림 피로(Alert Fatigue)를 줄여 진짜 신호가 눈에 띄게 만들기

모든 게 긴급이라면, 사실상 어떤 것도 긴급하지 않다.

알림 피로는 대응 효율을 무너뜨린다. 온콜 엔지니어가 매일 밤 수십 개의 알림을 보게 되면, 시스템을 더 이상 신뢰하지 않게 된다. 실제 인시던트가 발생했을 때 정말 중요한 신호를 놓칠 수도 있다.

컴퍼스 룸을 활용해 시각적으로 트리아지(우선순위 분류) 하고 단순화하자.

• 우선 보드에 현재 활성화된 알림들을 나열한다.
• 시끄러운 알림들을 묶어 하나의 문제에 대한 여러 증상으로 통합한다. (예: 서로 다른 DB 알림 15개 대신 “DB saturation” 하나로 표시)
• P0/P1 알림은 굵게 쓰거나 다른 색으로 표시한다.

그리고 장기적으로는 알림 설계를 개선한다.

• 실제 액션으로 이어지지 않는 알림은 제거한다.
• 신호(signal) (사용자에게 실제 영향을 주는 것)와 노이즈(noise) (정보 제공용) 를 분리한다.
• SLO와 에러 버짓을 최상위 신호로 두고, 세부 메트릭들은 그 아래에 매단다.

목표는 인시던트 상황에서 대응자가 눈앞에 소수의, 의미 있는 고우선 알림만 보도록 만드는 것이다.

신뢰성 문화 만들기: 인시던트를 ‘일상적인 것’처럼 느끼게 하기

도구만으로는 부족하다. 다음과 같은 문화를 만들어야 한다.

• 인시던트는 드물고 무서운 일이 아니라, 예상되고 연습되는 것이다.
• Dev와 Ops는 티켓이 아니라 결과(outcome)에 대한 책임을 공유한다.
• 블레임 없는(Postmortem) 사후 회고가 학습의 수단이지, 처벌의 도구가 아니다.

건강한 신뢰성 문화에서는 컴퍼스 룸이 일상 리듬의 일부가 된다.

• Game Day – 런북, 에스컬레이션 트리, 출력된 대시보드 같은 아날로그 자료만 가지고 드릴을 돌려본다. 무엇이 부족한지 찾아낸다.
• 사후 인시던트 워크스루 – 화이트보드에 인시던트 타임라인을 재구성하고, 그 결과를 바탕으로 런북과 알림을 개선한다.
• 공유된 소유권 – 각 서비스의 런북을 해당 서비스를 소유한 개발자가 직접 작성하고 유지보수하게 한다.

시간이 지나면, 이렇게 해서 인시던트 대응은 구조화되고 루틴한 작업처럼 느껴진다. 비록 장애 자체는 매우 복잡하더라도 말이다.

워크플로의 확장성과 복원력을 설계하기

시스템 복잡성은 분기마다 커져 간다. 그에 맞춰 인시던트 워크플로도 확장돼야 한다.

좋은 테스트가 있다. “현재 인시던트 프로세스가, 단 두 명의 영웅적인 사람이 깨어 있고 온라인일 때만 겨우 돌아가는가?” 그렇다면, 시스템과 팀이 성장할수록 결국 붕괴한다.

컴퍼스 룸 모델을 이용해 다음을 만족하는 워크플로를 설계하자.

• 복잡성을 분해한다 – 거대한 인시던트를 명확한 리드가 있는 작은 워크스트림들로 나눈다.
• 혼란이 아니라 역할을 확장한다 – IC, 커뮤니케이션, 도메인 리드 같은 역할 구조는 그대로 두고, 시스템이 늘어날 때 도메인 리드 수만 늘린다.
• 부분 장애에도 작동한다 – 채팅 도구나 모니터링 도구가 죽어도, 전화 트리와 출력된 런북만으로 여전히 조율이 가능해야 한다.

인프라의 복원력뿐 아니라 프로세스 자체의 복원력도 생각하자. 목표는 이거다. 새로 온 온콜 엔지니어도, 여러분이 준비해 둔 아날로그 도구만으로 대규모 장애를 끝까지 끌고 갈 수 있어야 한다.

인시던트 커맨드에서 빌려오기: 공짜로 공개된 표준 관행

공공 재난대응 조직들은 수십 년간 인시던트 커맨드 시스템(Incident Command System) 을 다듬어 왔고, 그 많은 내용이 문서화되어 무료로 공개되어 있다.

이를 그대로 베끼지는 않아도, 핵심 아이디어 몇 가지는 충분히 도입할 수 있다.

• 명확한 역할: Incident Commander, Operations, Planning, Communications 등.
• 표준 단계: 감지(Detection), 트리아지(Triage), 안정화(Stabilization), 복구(Recovery), 리뷰(Review).
• 단순한 양식: 누가 책임자인지, 현재 목표는 무엇인지, 관련 자원은 무엇인지.

다음과 같은 식으로 활용할 수 있다.

• 한 페이지짜리 인시던트 커맨드 템플릿을 스케치해서 여러 장 출력해둔다.
• 인시던트 크기에 상관없이 항상 동일한 구조를 사용한다.
• 모두가 기본 구조를 익혀 두어, 필요시 어떤 역할이든 들어갈 수 있게 훈련한다.

이렇게 하면 좋은 관행이 민주화된다. 비싼 도구 없이도 전문가처럼 대응할 수 있다. 필요한 것은 일관된 패턴과, 그것을 실제로 사용하겠다는 약속뿐이다.

시작하기: 실전형 체크리스트

종이 인시던트 컴퍼스 룸은 일주일 안에 부트스트랩할 수 있다.

1. 공간을 정한다 – 모두가 접근할 수 있는 작은 회의실이나 화이트보드 구역.
2. 핵심 아티팩트를 만든다:
   • 가장 중요한 장애 유형 3–5개에 대한 핵심 런북.
   • 이름과 연락처가 들어간 단순한 에스컬레이션 트리.
   • 역할, 목표, 상태, 다음 리뷰 시각이 들어간 인시던트 커맨드 템플릿.
3. 출력하고 게시한다 – 런북, 에스컬레이션 트리, 템플릿을 모두가 쉽게 보고 집어 갈 수 있는 곳에 비치한다.
4. 드릴을 돌린다 – 하나의 인시던트를 시뮬레이션하고, 이 아날로그 도구들만 써서 대응해본 뒤, 빠진 것을 기록한다.
5. 반복 개선한다 – 문서를 업데이트하고, 마찰을 줄이며, 정기적으로 리프레시 일정을 잡는다.

결론: 폭풍이 오기 전에 노스 스타를 그려 두라

프로덕션이 불타고 있을 때는, “그 문서 어디 있지?”나 “이건 누가 책임이지?”라고 물을 시간이 없다.

종이 인시던트 컴퍼스 룸은 팀에게 저기술(low-tech)이지만 고명료도(high-clarity)의 방법을 제공한다. 혼란을 헤쳐 나갈 수 있는 방식이다.

• 아날로그 노스 스타로서의 런북.
• 추측을 제거하는 에스컬레이션 트리.
• 알림 피로를 줄이는 시각적 트리아지.
• 누구나 배울 수 있는 표준화된 인시던트 커맨드 스타일 구조.

인시던트 대응을 개선하는 데 더 큰 툴 예산이 꼭 필요한 건 아니다. 펜, 종이, 그리고 폭풍이 닥치기 전에 컴퍼스를 설계하겠다는 의지만 있으면 된다.