아날로그 인시던트 아틀라스: 최악의 온콜 주를 버티게 해 줄 종이 지도 만들기

최악의 온콜 주가 찾아오면, 노트북 팬은 미친 듯이 돌고, Slack에는 빨간 점이 빼곡하고, Jira에서는 인시던트 티켓이 쏟아지고, 모두가 Slack으로 메시지를 보내고, 페이지를 날리고, 심지어 전화까지 걸어온다.

바로 이럴 때, 당신의 뇌는 스택에서 가장 믿기 어려운 도구가 된다.

책상이나 가방 속에 항상 넣어둘 수 있는 아날로그 인시던트 아틀라스—즉, 접어서 펼칠 수 있는 종이 지도—는 혼돈 속에서 길을 잃지 않게 해 주는, 손으로 만질 수 있는 저기술(highly low-tech)·고명료(high-clarity) 가이드다. 모니터링이나 런북을 대체하지는 않지만, 압박 속에서 어떻게 생각하고, 행동하고, 소통할지 구조를 잡아 준다.

이 글에서는 현대적인 온콜 프레임워크의 핵심 요소—인시던트 단계, 도구, 다이어그램, 문서화 표준—를 바탕으로 이 아틀라스를 어떻게 설계할지 단계별로 살펴본다.

왜 인시던트에 ‘종이 아틀라스’인가?

디지털 도구는 놀랍도록 강력하다. 잘 동작할 때까지는. 하지만 고스트레스 인시던트 상황에서는 사람들은 대개 이런 식으로 행동한다.

• 계획을 따라가기보다 각종 도구를 클릭하며 뱅글뱅글 돈다
• 에스컬레이션 경로와 커뮤니케이션 규칙을 잊어버린다
• 전체 그림을 파악하는 데 어려움을 겪는다

접이식 종이 지도는 몇 가지 핵심 문제를 해결해 준다.

• 인지 부하 감소: 프로세스가 머릿속이 아니라 종이 위에 있다.
• 낮은 마찰: 문서와 대시보드를 왔다 갔다(alt-tab) 할 필요가 없다.
• 항상 사용 가능: Wi‑Fi 장애, SSO 장애, 탭 지옥(tab chaos)에서도 살아남는다.
• 공유된 시야: 워룸(war room)에서 테이블 위에 펼쳐 두고 모두가 함께 볼 수 있다.

아날로그 인시던트 아틀라스는 전체 문서의 대체물이 아니다. 모니터링, 알림, 문서화, 커뮤니케이션을 하나로 묶어 주는 비상용 체크리스트 + 지도라고 생각하면 된다.

뼈대: 명확한 인시던트 대응 플로우차트

아틀라스의 한가운데에는 단순한 인시던트 대응 플로우차트가 있어야 한다. 나머지 모든 요소는 이 “척추”에 매달리는 구조가 된다. 이 플로우차트에는 다음 단계들이 명확하게 매핑되어야 한다.

1. 탐지(Detection)
2. 트리아지(Triage)
3. 커뮤니케이션(Communication)
4. 완화(Mitigation)
5. 사후 리뷰(Post-incident review)

가급적 한 페이지에, 가능하면 첫 번째 펼침면(spread)에 넣는 것이 좋다.

1. 탐지(Detection)

이 단계의 질문은 다음과 같다. "문제가 있다는 걸 우리는 어떻게 알게 되는가?"

지도에는 다음 내용을 포함한다.

• 주요 모니터링 도구 (예: Prometheus, Datadog, CloudWatch)
• 연동된 알림 시스템 (예: Jira Service Management, PagerDuty, Opsgenie)
• 전형적인 탐지 벡터: 사용자 제보, 자동화 알림, 내부 QA, 보안 시스템 등

시각적으로는 아주 단순하게 구성해도 된다.

• “Alert / Report Received(알림 / 제보 수신)” 라벨이 붙은 박스 하나
• Monitoring(모니터링) 과 User Reports(사용자 제보) 에서 화살표가 들어오는 형태

2. 트리아지(Triage)

이 단계의 질문은 다음과 같다. "이게 얼마나 심각한 문제이며, 누가 책임을 지는가?"

플로우차트는 다음을 안내해야 한다.

• 심각도 분류: Sev1/Sev2/Sev3 정의가 들어간 간단한 표
• 오너십: 누가 Incident Commander(IC, 인시던트 커맨더)가 되는지, 언제 전문 인력을 페이지할지
• 초기 확인 사항: 예를 들어 이런 질문들
  • 고객에게 영향을 주는가, 아니면 내부 시스템에만 영향을 주는가?
  • 이미 진행 중인 인시던트가 있는가?
  • 즉시 가능한 간단한 롤백이나 페일오버가 있는가?

3. 커뮤니케이션(Communication)

이 단계에서는 누구에게, 언제, 어떤 방식으로 알릴 것인지를 정의한다.

지도에는 다음과 같은 내용을 매핑한다.

• 내부 채널 (예: #incidents-sev1, #on-call, 영상 회의 링크)
• 외부 공지 (Status Page, Customer Success, Support)
• 심각도별 업데이트 주기 (예: Sev1: 15–30분마다 업데이트)

“Sev1인가?”와 같은 간단한 결정 박스를 두고, “인시던트 채널 생성 + IC 배정 + 서기(scribe) 지정”으로 분기될지, 아니면 “기존 티켓 업데이트 후 진행”으로 갈지 분기할 수 있다.

4. 완화(Mitigation)

완화 단계의 질문은 "지금 당장 피해를 어떻게 줄일 것인가?" 이다.

종이 위에 모든 런북을 다 적을 수는 없으니, 대신 이런 것들을 넣는다.

• 핵심 런북에 대한 링크나 ID
• 어디서 찾아야 하는지 위치 (Confluence 스페이스, 서비스별 런북 인덱스 등)
• 안전한 디폴트 액션 강조 (예: “마지막으로 정상 동작하던 버전으로 롤백”, “특정 엔드포인트 rate limit”, “가능하다면 X 리전에 페일오버” 등)

5. 사후 리뷰(Post-Incident Review)

이 단계의 질문은 다음과 같다. "무엇을 배웠고, 다시는 반복하지 않으려면 어떻게 해야 하는가?"

플로우는 항상 다음으로 귀결돼야 한다.

• 무엇이 일어났는지 문서화 (예: Confluence와 같은 전용 문서 도구에 기록)
• 사후 리뷰 일정 잡기 (예: 48–72시간 안에 진행하도록 규정)
• 런북, 다이어그램, 표준을 최신화 (이번 인시던트에서 얻은 교훈을 반영)

이 플로우차트의 핵심은, 혼돈 속에서도 지금 우리가 어디에 있는지 손가락으로 짚을 수 있다는 것이다.

“우리는 아직 트리아지 단계고, 심각도랑 IC를 안 정했어. 그거 먼저 하자.”

지도의 기반이 되는 온콜 프레임워크

아틀라스는 그것이 표현하는 시스템만큼만 유용하다. 잘 설계된 온콜 체계는 인시던트 대응의 모든 측면을 조율하는 종합적인 프레임워크—프로세스, 도구, 프로토콜—이다.

아틀라스에는 적어도 한 개의 펼침면 전체에, 이 요소들이 시각적으로 연결되어 나타나야 한다.

• 프로세스: 인시던트 라이프사이클 (탐지 → 트리아지 → 커뮤니케이션 → 완화 → 리뷰)
• 도구:
  • 모니터링 스택
  • 알림 및 티켓 시스템 (예: Jira Service Management)
  • 문서화 도구 (예: Confluence)
  • 커뮤니케이션 도구 (Slack/Teams, Zoom, 이메일)
• 프로토콜:
  • Incident Commander를 누가 맡는지
  • 에스컬레이션 규칙
  • 언제 리더십, 법무, PR을 개입시켜야 하는지

이 펼침면은 예쁘게 디자인하는 것이 목적이 아니다. **인시던트 대응 시스템의 배선도(wiring diagram)**를 그리는 데 초점을 맞춘다.

알림과 모니터링 통합: 지도는 현실을 반영해야 한다

아틀라스에 그려진 프로세스가 실제 도구 환경과 다르면, 사람들은 그 지도를 무시하게 된다.

지도가 실제 모니터링과 알림 통합 상태를 그대로 반영하도록 해야 한다.

• 모니터링 도구는 알림을 Jira Service Management(또는 사용하는 시스템)로 보낸다.
• 온콜 로테이션과 스케줄은 그 시스템에 정의되어 있다.
• 페이지와 에스컬레이션 정책은 가능한 한 자동화되어 있다.

아틀라스에는 다음이 포함되어야 한다.

• 작은 다이어그램 하나:
  • Monitoring → Alert → Jira Incident → On-call Pager → IC
• 작은 치트시트:
  • 누가 온콜인지 확인하는 위치
  • 에스컬레이션 정책이 설정된 곳
  • 자동화가 실패했을 때 수동으로 에스컬레이션하는 방법

인시던트가 한창일 때, 한눈에 확인하고 싶은 질문은 다음과 같다.

“이 페이지에 아무도 응답하지 않으면, 다음 에스컬레이션 경로는 뭐지?”

그 경로를 아틀라스에 넣어 두어야 한다.

전투 기록: 문서화 도구를 제대로 활용하기

Confluence 같은 전용 문서화 도구는 인시던트 진행 중과 종료 후, 두 시점 모두에서 필수적이다.

아틀라스에서는 문서화를 다음 두 가지 모드로 강조해야 한다.

1. 실시간 인시던트 상태 기록
2. 사후(Postmortem) 분석

인시던트 진행 중

지도에는 다음 내용이 포함되어야 한다.

• 실시간 인시던트 노트에 사용할 템플릿이나 스페이스 위치
• IC나 서기가 반드시 기록해야 할 항목:
  • 이벤트 타임라인
  • 주요 의사결정 (누가, 왜, 무엇을 결정했는지)
  • 시도한 가설과 그 결과

간단한 체크리스트 박스만 있어도 큰 도움이 된다.

• 인시던트 문서를 템플릿에서 생성
• 관련 티켓 모두 링크
• 주요 결정 + 타임스탬프 기록

인시던트 종료 후

사후 리뷰 단계에서, 아틀라스는 다음 사항을 안내해야 한다.

• Postmortem 문서를 어디에 생성할지
• 필수 섹션 (요약, 영향, 근본 원인, 타임라인, 기여 요인, 액션 아이템)
• 누가 리뷰에 참석해야 하고, 누가 승인해야 하는지

또한 **“Jira에 추적할 후속 액션”**이라고 라벨을 붙인 빈 영역이나 포스트잇 공간을 만들어 두는 것도 좋다.

불길 속의 다이어그램: 지금은 단순하게, 예쁘게는 나중에

다이어그램은 인시던트 중에 매우 강력한 도구지만, 빠르게 만들 수 있고, 즉시 이해 가능할 때만 진짜 힘을 발휘한다.

아틀라스에는 압박 속에서 다이어그램을 그리는 가이드라인을 포함해야 한다.

• 인시던트 진행 중:

  • 기본 도형과 텍스트만 사용 (서비스는 박스, 호출은 화살표, 장애는 번개 아이콘 등)
  • 화이트보드, 종이, 간단한 드로잉 툴이면 충분하다
  • 목표는 *“어디가 고장 났고, 트래픽이 어떻게 흐르는지”*를 보여주는 것이지, 완벽한 시스템 다이어그램을 만드는 것이 아니다

• 인시던트 종료 후:

  • 런북, 발표 자료, 교육용으로 다이어그램을 다듬는다
  • 필요하다면 “기존 상태(as was)”, “인시던트 중 상태”, “수정 후(as fixed)” 뷰를 모두 캡처한다

아틀라스 안에는 다음과 같은 작은 예시 스케치를 넣어두면 좋다.

• 최소한의 서비스 의존성 맵
• 완화 조치 전/후의 변화 (예: 서킷 브레이커 추가, 라우팅 변경 등)

핵심 메시지는 명확해야 한다. 인시던트 라이브 상황에서는 빠르고 못생긴(diagram) 다이어그램이 ‘허용’ 정도가 아니라, ‘기대되는 기본값’이라는 점이다.

즉흥으로 하지 말 것: 인시던트 계획 표준

아날로그 인시던트 아틀라스의 마지막 섹션은 조직의 인시던트 계획 표준을 가리켜야 한다.

서비스 중심 비즈니스라면 누구나 다음과 같은 내용이 문서화된 표준을 가지고 있어야 한다.

• 인시던트 심각도 및 분류 체계
• 역할과 책임 (IC, 서기, 커뮤니케이션 리드, 도메인 전문가 등)
• 도구 요구사항 (모니터링, 알림, 문서화)
• 응답 및 커뮤니케이션에 대한 SLA/OLA
• 리뷰 주기와 기대 사항

아틀라스에서는 이 내용을 다음처럼 핵심만 압축해서 담아야 한다.

• 역할 치트시트: Sev1 상황에서 누가 무엇을 하는지
• 심각도 매트릭스: 각 Sev에 해당하는 예시 상황
• 조직의 인시던트 철학을 한 줄로 요약한 문구, 예를 들면:

  “먼저 안정화, 설명은 그다음. 커뮤니케이션은 빠르고 자주.”

상세 표준 문서는 Confluence 같은 곳에 두더라도, 그 핵심만큼은 아틀라스에 들어 있어야 한다.

아날로그 인시던트 아틀라스를 실제로 만드는 방법

디자인 팀이 꼭 필요한 것은 아니다. 필요한 것은 프린터용 종이와 약간의 구조뿐이다.

추천 레이아웃:

1. 표지: 제목, 버전, 담당자, 마지막 업데이트 날짜
2. 1번 펼침면: 인시던트 대응 플로우차트 (탐지 → 트리아지 → 커뮤니케이션 → 완화 → 리뷰)
3. 2번 펼침면: 온콜 프레임워크 개요 (프로세스, 도구, 프로토콜)
4. 3번 펼침면: 모니터링 + 알림 통합, 에스컬레이션 치트시트
5. 4번 펼침면: 문서화 워크플로우 (실시간 노트 + 사후 리뷰 프로세스)
6. 5번 펼침면: 다이어그램 가이드라인 + 최소 예시
7. 6번 펼침면: 인시던트 표준 (역할, 심각도, 원칙)

인쇄하고, 접어서, 다음 장소에 비치하라.

• 노트북 옆
• 사무실 / 팀 공용 공간
• 인시던트 룸이나 워룸

디지털 런북을 업데이트하듯, 이 아틀라스도 주기적으로 업데이트해야 한다.

결론: 가장 필요할 때 손에 잡히는 지도

최악의 온콜 주에는 인시던트 프로세스를 머릿속에서 다시 조립할 시간도, 정신적인 여유도 없다. 대시보드, 알림, 온갖 도구는 넘쳐나겠지만, 진짜 필요한 것은 “지금 다음에 무엇을 해야 하는지”를 모두가 공유할 수 있는 명확한 지도다.

아날로그 인시던트 아틀라스는 모든 것을 담으려 하지 않는다. 대신 **골격(skeleton)**을 담는다.

• 탐지, 트리아지, 커뮤니케이션, 완화, 리뷰로 이어지는 명확한 플로우
• 온콜 프레임워크와 각종 도구가 어떻게 연결되는지에 대한 전체 그림
• 압박 속에서도 다이어그램과 문서화를 어떻게 할지에 대한 간단한 규칙
• 일관되고 프로페셔널한 대응을 가능하게 해 주는 표준

필요해지기 전에 미리 만들어 두어라. 지옥 같은 한 주가 찾아왔을 때, 그 접이식 종이 지도는 방 안에서 가장 침착한 존재가 되어 줄 것이다.