아날로그 인시던트 나침반 팬트리: 다음 대규모 장애 전에 종이 기반 의식을 비축하라

정말 일이 크게 꼬였을 때 우리를 구해주는 건 화려한 대시보드가 아니다. 우릴 살리는 건 지루해 보이는 체크리스트다.

대부분의 팀은 인시던트 대응을 설계할 때 기본 전제부터 이렇게 깔고 시작한다. “시스템은 그래도 대체로 돌아간다.” 슬랙은 살아 있고, VPN도 괜찮고, 위키도 접속 가능하고, SSO도 잘 동작한다고 가정하는 식이다. 하지만 진짜 아픈 대형 장애는 보통 마이크로서비스 하나만 고장 내고 끝나지 않는다.

그래서 아날로그 인시던트 나침반 팬트리(analog incident compass pantry) 라는 개념이 필요하다. 디지털 도구를 신뢰할 수 없거나 완전히 사라졌을 때 길잡이가 되어줄, 종이 기반 의식(rituals)—런북, 연락처 목록, 에스컬레이션 차트, 의사결정 트리—를 의도적으로 선별해서 꽂아 둔 선반 하나라고 생각하면 된다.

이 글에서는 인시던트 대응을 하나의 “제품”으로 다루는 관점에서, 다음 대규모 장애 때 당신을 구할지도 모를 아날로그 팬트리를 어떻게 채우고 유지해야 하는지 차근차근 살펴본다.

1. 인시던트 대응을 ‘1급 제품’으로 취급하라

고객이 쓰는 제품을 내보내면서 이런 것들을 안 챙기지는 않을 것이다.

• 책임 있는 오너
• 잘 정의된 프로세스
• 품질 기준과 지속적인 개선

하지만 인시던트 대응은 여전히 구전되는 관행과 여기저기 흩어진 문서의 느슨한 묶음으로 남아 있는 경우가 많다.

탄탄한 아날로그 인시던트 팬트리를 만들고 싶다면, 먼저 인시던트 운영을 하나의 제품(Product) 영역으로 격상시켜야 한다.

• 명확한 오너를 지정하라
  인시던트 프로세스, 문서, 훈련 전반의 라이프사이클을 책임지는 ‘인시던트 대응 프로덕트 오너(또는 오너 그룹)’를 명확히 정한다.
• 품질 기준을 정의하라
  예를 들어 이런 식으로 구체화할 수 있다.
  “어떤 온콜 엔지니어든 새벽 3시에 추가 설명 없이 이 플레이북만 보고도 안전하게 대응할 수 있어야 한다.”
  “종이 문서는 네트워크가 없고, 사용 가능한 도구가 최소한이라는 전제를 깐다.”
• 프로세스 로드맵을 만들어라
  새로운 인시던트 유형, 플레이북 개정, 교육·훈련 등을 모두 백로그 아이템으로 취급한다. 실제 발생한 인시던트와 리스크를 기준으로 우선순위를 정한다.

한 번 인시던트 대응을 ‘제품’이라고 생각하기 시작하면, 팬트리를 채우는 일은 ‘부가 작업’이 아니라 시스템 신뢰성을 위한 핵심 업무가 된다.

2. 종이로 접근 가능한 플레이북과 런북을 만들어라

위키에 6시간 동안 접속할 수 없다고 가정해보자. 지금 당신의 인시던트 프로세스 중 얼마나 남는가?

**플레이북(playbook)**과 **런북(runbook)**은 아날로그 팬트리의 뼈대다.

• 플레이북: 특정 인시던트 유형(클래스)에 대한 상위 수준 절차
  • 예: “대규모 고객 영향 장애”, “데이터 손상 의심”, “보안 인시던트”, “결제 서비스 성능 저하”
• 런북: 아주 구체적인 운영 작업을 수행하기 위한 단계별 기술 지침
  • 예: “데이터베이스 X를 리전 Y로 페일오버”, “서비스 Z의 API 키 롤테이션”, “메시지 버스를 안전하게 재시작”

이를 아날로그 친화적으로 만들려면:

1. 애초에 ‘출력물’ 기준으로 작성하라
   • 명확한 헤딩, 짧은 번호 매기기 단계, 여유 있는 여백을 사용한다.
   • 하이퍼링크나 내장 대시보드에 의존하지 않는다.
2. 의사결정 트리(Decision Tree)를 포함하라
   • 예/아니오로 갈라지는 단순한 플로우차트를 넣는다.
     • “DB가 베스천(bastion) 호스트에서 접근 가능한가? → 예 → 3단계로 이동 / 아니오 → DBA 온콜에게 전화하라.”
3. 에스컬레이션 경로를 문서 안에 직접 넣어라
   • 슬랙 채널이나 메일링 리스트뿐 아니라 이름, 역할, 전화번호를 적어둔다.
4. 전제 조건(Pre-condition)을 분명히 적어라
   • “당신은: 베스천에 대한 SSH 접근 권한 + 하드웨어 토큰에 저장된 크리덴셜을 가지고 있다.”
   • “당신은: 위키, 클라우드 대시보드, 사내 채팅은 없다고 가정한다.”

이 문서들을 출력해서 사람들이 실제로 대응하는 곳—온콜 룸, NOC, 운영 데스크, 사무실의 라벨 붙은 바인더—에 실물로 꽂아 둔다. 중요도가 높은 세트는 필요하다면 여러 벌로 복제해 둔다.

3. 인시던트 후 매번 종이 문서를 갱신하라

바로 써야 할 때 내용이 낡아 있다면, 그 문서는 오히려 위험하다.

이를 피하려면, 각 인시던트 회고 페이지(또는 트래킹 티켓)에 문서 유지보수를 직접 연결해 두어야 한다.

• 각 인시던트 직후 자문해보자.
  • 어떤 플레이북·런북을 실제로 사용했는가?
  • 문서가 없거나 틀려서 어디에서 ‘즉흥 대응’을 했는가?
  • 어떤 단계가 헷갈리거나 모호했거나, 이미 현실과 맞지 않았는가?
• 기억이 생생할 때 바로 수정하라
  • 잘못된 명령어나 빠진 컨텍스트, 틀린 호스트명을 고친다.
  • 새롭게 발견된 장애 양상과 대응책을 추가한다.
  • 주저하거나 실수하게 만들었던 표현을 명확히 다듬는다.
• 수정한 부분은 다시 출력해서 팬트리의 옛 장을 교체한다.

이를 아예 포스트 인시던트 체크리스트에 넣어라.

• 참조한 플레이북·런북을 리뷰했다.
• 필요한 변경 사항을 태스크로 정리했다.
• 우선순위가 높은 수정은 N일(가급적 1–3일) 안에 반영·재출력했다.

아날로그 팬트리는 살아 있는 시스템이다. 바뀌지 않는다면, 아마 썩어 가고 있다는 뜻이다.

4. 구조화된 인시던트 관리 기법을 활용하라

사람들 여럿이 한 방에서 서로 고함을 지르며 대형 장애를 ‘즉흥’으로 수습하는 데는 한계가 있다.

SRE와 재난 대응 분야에서 쓰는 구조화된 기법을 빌려와, 팀의 인시던트 의식을 설계하자.

명확한 역할 정의

먼저 다음과 같은 역할을 문서화하고 훈련하라.

• 인시던트 커맨더(Incident Commander, IC) – 기술 작업이 아니라 조율과 의사결정을 책임진다.
• 오퍼레이션 리드(Operations Lead) – 기술 대응자들을 지휘한다.
• 커뮤니케이션 리드(Communications Lead) – 이해관계자 및 고객 커뮤니케이션을 담당한다.
• 스크라이브(Scribe) – 이벤트와 의사결정의 타임라인을 기록한다.

종이 문서에는 다음이 포함되어야 한다.

• 각 역할의 책임을 A4 1페이지 이내로 설명
• IC를 위한 “스크립트”와 체크리스트
  • “심각도(Severity) 수준을 확정한다.”
  • “역할을 식별하고 할당한다.”
  • “다음 상태 업데이트 시점을 정한다.”

단계 구분: 완화(Mitigation)와 해결(Resolution)

대형 인시던트일수록 다음 두 단계를 명확히 나누는 것이 도움이 된다.

• Mitigation(완화): 더 큰 손실을 막는 단계. 피를 멎게 하는 단계라고 보면 된다.
• Resolution(해결): 근본 원인을 찾고 고치며, 후속 정리를 하는 단계.

아날로그 문서에는 다음을 포함하라.

• “Mitigation 모드” 체크리스트: 되돌릴 수 있는 변경 위주, 부분적인 서비스 복구에 초점.
• “Resolution 모드” 체크리스트: 심층 분석, 영구적 수정, 문서·프로세스 업데이트.

커뮤니케이션 채널과 주기

슬랙이나 사내 메신저를 잃을 수 있다는 전제로 움직여야 한다. 종이 플레이북에는 다음이 명시돼야 한다.

• 대체 채널: 전화 브리지(컨퍼런스 콜), SMS 트리, 외부 음성/채팅 도구, 혹은 실제 ‘워 룸’(한 곳에 모이는 회의실) 등
• 기본 상태 업데이트 주기
  예: “내부 이해관계자에게 15분마다, 고객에게 30–60분마다 업데이트한다.”

툴이 무너져도, “누구에게·무슨 내용을·얼마나 자주 알릴지”가 적힌 단순 체크리스트 한 장이 놀라울 만큼 큰 힘을 발휘한다.

5. 종이만 가지고 하는 ‘Wheel of Misfortune’ 훈련을 하라

문서를 읽는 것과 재난을 실제로 리허설하는 것은 전혀 다르다.

정기적인 훈련(월 1회나 분기 1회)을 운영하되, 다음 조건을 걸어보자.

1. 골치 아픈 장애를 시뮬레이션하라
   • 시나리오를 돌려 가며 사용한다.
     예: 전사 네트워크 마비, DB 손상, 보안 침해, 외부 서드파티 장애, 클라우드 리전 전체 장애 등.
2. 제약 조건을 강제로 부여하라
   • 사내 위키 금지.
   • 슬랙 금지.
   • 사용할 수 있는 건 아날로그 인시던트 팬트리, 전화, 최소한의 현실적인 도구뿐.
3. 실제 시간(real time)으로 역할을 배정해 진행하라
   • 종이 문서에 있는 IC 스크립트를 그대로 따른다.
   • 의사결정 트리를 그대로 밟아간다.
   • 헷갈리는 부분이 나오면 종이 출력물에 직접 메모를 남긴다.
4. 디브리핑과 문서 개선으로 마무리하라
   • 무엇이 잘 작동했는가?
   • 무엇이 아예 문서에 없었는가?
   • 사람들은 어디에서 막혔는가?
   • 이 인사이트를 새로운 체크리스트와 문서 개정에 반영한다.

이걸 “Wheel of Misfortune(불행의 바퀴)” 게임 데이라고 생각해도 좋다. 멋진 기술적 활약을 뽐내는 자리가 아니라, **종이 의식(paper rituals)**이 압박 속에서 팀을 얼마나 잘 안내하는지 검증하는 날이다.

6. 블레임리스 포스트모템과 버그 분류 체계를 운영하라

무언가 망가질 때마다 거기서 배운 것을 잘 모아두면, 아날로그 팬트리는 점점 더 좋아진다.

블레임리스(Blameless) 포스트모템

먼저, 포스트모템 프로세스에서 ‘블레임리스’를 명확히 선언하라.

• 목적은 누구를 혼낼지 찾는 게 아니라, 시스템이 어떻게 이런 오류를 허용했는지 이해하는 것이다.
• 초점은 다음에 둔다.
  • 탐지(Detection): 우리는 어떻게 이 문제를 알게 되었는가?
  • 진단(Diagnosis): 어떻게 원인을 좁혀 갔는가?
  • 의사결정(Decision-making): 왜 이 완화책들을 선택했는가?
  • 문서 갭(Document gap): 어느 지점에서 플레이북이 우리를 놓쳤는가?

버그 택소노미(Bug Taxonomy)

인시던트와 ‘히어로가 막은 아슬아슬한 상황’(near miss)에 대해, 단순한 분류 체계를 만든다.

• 예: 설정 오류(configuration error), 용량 이슈(capacity issue), 의존성 장애(dependency failure), 잘못된 배포(bad deploy), 보안 취약점, 문서 부족, 프로세스 갭 등.

각 카테고리에 대해 다음을 스스로에게 물어보라.

• 이 유형의 인시던트를 다루는 플레이북이 있는가?
• 가장 흔한 완화 시나리오를 다루는 런북이 있는가?
• 관련 가이드가 출력본 형태로도 존재하는가?

각 포스트모템은 결국 다음을 결과물로 내야 한다.

• 아날로그 팬트리에 추가·수정되어야 할 구체적인 문서 목록
• 각 변경의 오너와 마감일

시간이 지날수록, 책장 한 켠의 이 종이 문서 묶음은 조직이 축적해 온 학습의 물리적인 구현체가 된다.

7. 현실적인 접근성을 염두에 두고 팬트리를 설계하라

이제 팬트리 그 자체를 하나의 ‘오브젝트’로 생각해보자.

팬트리에 들어갈 것들

최소한 다음 정도는 비축해 두는 것이 좋다.

• 인시던트 프로세스 개요 (1–2페이지)
• 역할 설명과 IC 스크립트
• 심각도(Severity) 분류 가이드
• 상위 N개 인시던트 클래스용 플레이북
  (예: 발생 빈도나 리스크 기준 상위 10–20개)
• 크리티컬 런북 – 예:
  • 주요 데이터 스토어 페일오버 절차
  • 배포 중단/롤백 절차
  • 크리덴셜·API 키 롤테이션 절차
  • 리전/서비스 제공자 간 트래픽 전환 절차
• 연락처 및 에스컬레이션 차트
  • 온콜 로테이션(전화번호 포함)
  • 리더십, 보안팀, 법무, PR
  • 외부 벤더와 클라우드 제공자 연락처
• 커뮤니케이션 템플릿
  • 최초 인시던트 공지
  • 고객 대상 상태 업데이트
  • 내부 이해관계자 업데이트

물리 환경과 툴 가정

다음과 같은 상황을 기본 가정으로 두고 설계하라.

• 네트워크가 죽었거나, 매우 불안정할 수 있다.
• VPN과 SSO가 동작하지 않을 수 있다.
• 일부 사람은 원격, 일부는 오피스에 있을 수 있다.

실무적인 팁은 다음과 같다.

• 하드 카피 바인더를 최소 한 권 이상 만들고, 누구나 아는 위치에 라벨을 붙여 둔다.
• PDF 스냅샷 버전을 유지해, 몇 대의 노트북이나 태블릿에 미리 로드해 둔다.
  (네트워크는 되지만 내부 툴이 망가진 상황을 대비)
• 정기 리뷰 캘린더(예: 분기별)를 설정해 다음을 점검한다.
  • 전화번호와 연락처가 최신인지
  • 명백히 오래된 플레이북을 교체했는지
  • 새로 중요한 시스템이 생겼다면 그에 대한 런북이 추가됐는지

결론: 불이 깜빡일 때 손이 가야 할 것은 ‘그 선반’이다

대형 장애는 본질적으로 혼란스럽다. 모든 불확실성을 없앨 수는 없지만, 쓸데없는 혼란은 크게 줄일 수 있다.

인시던트 대응을 진짜 제품으로 다루고, 종이 우선 플레이북·런북을 유지하고, 툴 제약이 있는 훈련을 반복하고, 매 인시던트에서 배운 것을 아날로그 인시던트 팬트리에 충실히 되돌려 넣는다면, 한 가지 귀한 것을 얻게 된다. 바로, 암흑 속에서도 비교적 차분하고 환하게 밝혀진 하나의 경로다.

네트워크가 불안정하고, 툴이 말을 안 듣고, 사람들이 지치고 초조한 순간에, 단순한 종이 체크리스트 한 장이 당신의 나침반이 될 수 있다.

필요해지기 전에, 지금 그 선반을 채워 두어야 한다.