아날로그 장애 대응 필드 가이드: 신뢰성 스택이 배신할 때를 위한 로우테크 전략

인터넷이 멈춰 서는 순간, 대부분의 조직은 불편한 진실을 마주합니다.

우리 조직의 신뢰성 전략은, 신뢰성 도구들이 항상 신뢰할 수 있을 거라고 가정한다.

서비스 상태 대시보드, 인시던트 채널, 티켓 시스템, 런북, SSO 같은 것들은 정작 가장 필요할 때 통째로 사라질 수 있습니다. 클라우드 장애, 사이버 공격, ISP(통신사) 장애, 내부 설정 오류 등으로 벌어지는 대형 인시던트에서, 팀이 결국 하는 일은 의외로 원시적입니다. 바로 펜과 종이를 집어 드는 거죠.

이건 현대 도구의 실패가 아닙니다. 아날로그 대비(Analog Readiness) 의 실패입니다.

이 가이드는 디지털 도구가 없어도 조직이 계속 운영될 수 있도록, 의도적으로 설계된 로우테크 대체 수단, 장기 인시던트를 버틸 수 있는 온콜 패턴, 실시간 장애 감지 방식을 정리합니다. 즉, 신뢰성 스택이 우리를 배신하더라도 버틸 수 있는 운영 방식을 만드는 이야기입니다.

1. “아날로그 대비(Analog Readiness)”란 무엇이고, 왜 중요한가

아날로그 대비(analog readiness) 란, 디지털 시스템이 느려지거나 완전히 중단됐을 때도, 저기술/로우테크 도구만으로 핵심 업무를 유지할 수 있는 조직의 능력을 말합니다.

클라우드나 자동화를 버리자는 이야기가 아닙니다. 대신 이런 어려운 질문에 답하는 것입니다.

주요 도구를 24–72시간 동안 사용할 수 없다면, 우리는 구체적으로 무엇을, 누가, 어떻게 할 것인가?

흔히 놓치는 전제들

대부분의 인시던트 대응 계획은 말 없이 이렇게 가정합니다.

사내 메신저(슬랙/팀즈 등)는 항상 된다
SSO와 패스워드 매니저에 항상 접속할 수 있다
티켓·인시던트 도구(Jira, ServiceNow, PagerDuty 등)는 계속 동작한다
문서와 런북은 온라인으로 접근 가능하다
EDR/엔드포인트 보안과 VPN이 정상이다

하지만 큰 규모의 사이버 사고나 인프라 장애에선, 위의 것들 중 일부는 — 때로는 사고 확산 방지 목적으로 의도적으로 — 내려가기도 합니다. 그때 살아남는 조직은 이미 저기술 운영 모드(low‑tech operating mode) 를 설계하고, 연습까지 해 둔 곳입니다.

2. 펜과 종이가 주요 신뢰성 도구가 되는 순간

심각한 장애 상황에서는 여러분이 쓸 수 있는 가장 "고급" 백업 수단이 다음과 같을 수 있습니다.

펜과 종이로 조치와 의사결정을 기록하기
인쇄된 런북과 체크리스트
워룸(war room)에서 상황 공유를 위한 화이트보드

이건 "있으면 좋은 것" 정도가 아닙니다. 실제 인시던트에선 오히려 주요 운영 도구가 됩니다.

사전에 준비해 둬야 할 것들

빠르게 꺼내 쓸 수 있는 아날로그 인시던트 키트(Analog Incident Kit) 를 만듭니다.

출력된 연락망(연락 트리)
- 핵심 역할: 인시던트 커맨더, 보안팀, 법무, 커뮤니케이션, 경영진, 시설팀 등
- 엔지니어링, SRE, IT, 벤더 에스컬레이션용 온콜 리스트
- 대표전화가 아니라 직통 번호 (사내 메신저나 이메일에 의존하지 말 것)
종이 런북과 체크리스트
- 인시던트 선언 및 역할 배정 절차
- 네트워크 격리 및 컨테인먼트 단계별 절차
- 데이터센터 접근 및Fallback(우회) 네트워크 절차
- 고객 공지용 커뮤니케이션 템플릿
로우테크 로그 도구
- 페이지 번호가 매겨진 제본 노트(인시던트 저널용)
- "누가/무엇을/언제"를 기록하는 서식지가 인쇄된 양식지
필기·시각화 도구
- 볼펜·마커·포스트잇·인덱스 카드·테이프
- 이동식 화이트보드 또는 플립차트

이 키트는 물리적으로 여러 장소에 비치해야 합니다. 특히 위기 시 사람들이 모일 공간(본사, 주요 오피스, 데이터센터, 상황실 등)에 두어야 합니다.

3. 길고 지저분한 장애를 위한 온콜 설계

일반적인 온콜 체계는 보통 짧고 강도가 높은 이벤트에 최적화되어 있습니다. 알람이 울리고, 누군가 한두 시간 안에 고치고, 다시 평상 업무로 돌아가는 식입니다.

하지만 사이버 인시던트와 수일에 걸친 장애는 다릅니다. 이건 스프린트가 아니라, 마라톤입니다.

"장기 인시던트" 전용 로테이션 만들기

장기화될 수 있는 이벤트에 대해 별도의 플레이북을 정의합니다.

짧은 근무, 엄격한 인수인계
- 12–24시간짜리 "영웅 모드"가 아니라, 4–6시간 단위의 교대 근무
- 도구가 아날로그뿐이어도, 반드시 서면 또는 구두 인수인계 시행
역할 분리
- 인시던트 커맨더(Incident Commander)
- 운영/인프라 리드
- 보안 리드
- 커뮤니케이션/PR 리드
- 서기/인시던트 히스토리언 (도구가 죽었을 때 특히 필수)
피로 관리
- 연속 근무 시간·일수에 대한 명확한 상한선
- 백업 IC와 백업 리드 지정
- 중요도가 낮은 업무를 중단 또는 연기할 수 있는 명시적 권한 부여

그리고 디지털 스케줄링 도구가 없을 수도 있다는 점을 전제로 합니다.

주요 장소에 인쇄된 온콜 스케줄을 비치
중요 노트북에는 오프라인 사본을 보관 (예: 암호화된 로컬 파일)
단순히 전화번호 목록과 달력만 가지고도 로테이션을 재구성할 수 있게 여러 명을 훈련

4. 글로벌 커버리지: 디지털·아날로그를 섞어 24시간 대응하기

여러 지역에서 운영하는 조직이라면, 장애 대응도 마찬가지로 Follow‑the‑sun(태양을 따라 도는) 모델이어야 합니다. 심지어 디지털 협업 도구가 끊긴 상황에서도 말이죠.

인시던트 전 사전 합의

아무 일도 일어나지 않았을 때, 미리 다음을 정의합니다.

지역별 책임 범위
- 각 지역 업무 시간 동안 누가 리드를 맡는지
- 타임존이 바뀔 때 권한과 책임이 어떻게 이양되는지
지역별 1·2차 통신 채널
- 예: A지역: 1순위 공용 전화 브리지 → 2순위 SMS → 3순위 사전 승인된 범위 내의 범용 메신저 앱
- B지역: 다른 회선의 전화 서비스 → 라디오/위성 전화(중요 거점용)
언어 및 번역 책임
- 공유 도구가 죽었을 때, 중요한 업데이트를 번역·중계할 수 있는 사람은 누구인지

타임존을 넘나드는 아날로그 협업

협업 도구를 쓸 수 없어도, 지역 간 협업은 다음 방법으로 가능합니다.

정해진 시각의 정기 음성 체크인 (예: 매 정시 5분 회의)
표준화된 구두 브리핑 포맷 사용 (3분 이내 요약)
- Situation(상황): 지난 한 시간 동안 무엇이 바뀌었는가
- Actions(조치): 무엇을 했고, 이어서 무엇을 할 것인가
- Risks(위험): 새로 생기거나 커진 리스크는 무엇인가
- Needs(요청): 필요한 의사결정, 승인, 리소스는 무엇인가
이메일·메신저는 안 되지만 전화·팩스·일부 레거시 회선이 된다면, 화이트보드 사진을 찍어 보내거나 팩스로 공유

목표는 단순합니다. 서로 다른 지역이 서로의 상황을 몰라서 상충되는 결정을 내리지 않도록 하는 것입니다.

5. 실시간 장애 가시성: Downdetector를 써야 할 때, 안 써야 할 때

장애가 의심되는 순간, 사실보다 먼저 퍼지는 건 보통 인식과 소문입니다. 이때 가장 널리 쓰이는 외부 신호 중 하나가 바로 Downdetector 같은 크라우드소싱 기반 플랫폼입니다.

팀은 이 도구를 어떻게 읽어야 할지 알아야 합니다. 그렇지 않으면, 작은 잡음에도 과잉 대응하거나, 반대로 진짜 장애의 초기를 놓칠 수 있습니다.

Downdetector 상태 이해하기

Downdetector는 보통 다음과 같은 상태를 보여 줍니다.

“No problems detected(문제 없음)”
- 신고량이 평소 백그라운드 노이즈 수준 이하다
- 이게 "문제가 전혀 없다"를 뜻하는 건 아니다 — 보이는 스파이크가 없다는 의미일 뿐
신고량이 평소보다 높은데, 아직 대규모 장애로 표시되진 않은 상태
- 특정 지역 ISP 문제, 소규모 지역 프로바이더 이슈, 혹은 단순 노이즈일 수 있다
- 이를 힌트로 삼고, 내부 지표나 사용자 신고와 교차 확인해야 한다
대규모 장애로 확인 / 신고량이 급증하는 상태
- 여러 지역 사용자들이 동시에 문제를 보고하고 있음을 의미
- 주요 클라우드·SNS·결제·통신사 장애 등과 종종 맞물려 나타난다

Downdetector를 프로세스에 넣는 방법

"정상"이 어떤 모양인지 기준선을 잡아라
- 평시에도 가끔 주요 프로바이더의 Downdetector 페이지를 들여다본다
- 평소 일별 패턴과 작은 출렁임을 익혀 두면, 정말 이상한 패턴이 눈에 들어온다
외부 신호와 내부 신호를 결합하라
- Downdetector 스파이크를 다음과 비교한다.
  - 내부 모니터링/텔레메트리
  - 고객지원 티켓 증가량
  - 고객의 직접 신고(전화, 이메일 등)
- 내부·외부 지표가 동시에 튀기 시작하면, 실제 이슈일 가능성이 훨씬 커진다
의사결정 기준을 문서화하라
- 미리 정의해야 할 것들:
  - Downdetector 스파이크가 언제 주의 단계(Heightened monitoring) 를 트리거 하는가?
  - 언제 내부 인시던트 선언을 하는가?
  - 언제 외부 커뮤니케이션(상태 페이지, SNS, 고객 메일)을 시작하는가?
매 작은 변동에 쫓기지 않도록 교육하라
- 테이블탑 연습에서 과거 예시를 활용한다
- 일상적인 작은 출렁임과, 진짜 대규모 이벤트의 패턴을 비교해 보여 준다

실시간 장애 가시성은 대시보드가 많다는 뜻이 아닙니다. 신호를 보고 무엇을 의미하는지 공통의 판단 기준을 갖고 있는지가 핵심입니다.

6. 아날로그 플레이북을 만들고, 시험하는 방법

위키에만 존재하는 아날로그 계획은, 계획이 아니라 소원(wish) 에 가깝습니다.

1단계: 반드시 유지해야 하는 것부터 정리

디지털 장애나 사이버 인시던트 동안, 최소 24–72시간 이상 반드시 유지해야 하는 핵심 역량을 나열합니다.

핵심 고객 요청을 받고 처리하기
고객에게 대금 청구·결제·환불을 (제한적이어도) 수행하기
필수 재무·법무 결정을 승인하기
안전, 보안, 규제 준수 의무를 지키기

각 항목에 대해 질문합니다.

주요 시스템 없이 — 전화, 종이, 사람 간 조율만으로 — 이걸 어떻게 최소한으로라도 수행할 수 있을까?

2단계: 단순화된 아날로그 워크플로 설계

각 핵심 역량마다 축소된 세이프 모드(Safe Mode) 를 정의합니다.

선택지를 최소화하고, 엣지 케이스는 과감히 줄인다
접근 권한과 승인을 더 엄격하게 제한한다
나중에 시스템 복구 후 대사(Reconciliation)를 할 수 있도록 수동 로그를 남긴다

예시: 온라인 주문 시스템이 죽었을 때, 다음과 같이 운영할 수 있습니다.

높은 우선순위의 주문만 전화로 접수
종이 양식에 고유 ID를 부여해 기록
사전에 정해 둔 대체 인증·결제 방식을 이용해 고객 신원과 결제를 확인

3단계: 테이블탑·실전 드릴 수행

최소 연 1회 이상, 다음과 같은 가정으로 연습을 진행합니다.

SSO와 VPN이 모두 불가
기본 사내 메신저와 티켓 시스템이 먹통
특정 SaaS 프로바이더가 몇 시간 동안 전혀 접속 불가

연습 중에는 다음을 실제로 해 봅니다.

디지털 로깅에서 종이 로그로 전환하기
인쇄된 연락망을 사용해 콜 트리 돌리기
음성만으로 지역 간 인수인계 하기

그 과정에서 배운 점을 정리해, 디지털·아날로그 런북을 모두 업데이트합니다.

7. 아날로그 대비를 경쟁력으로 만드는 법

아날로그 대비는 향수나 복고 감성이 아니라, 레질리언스(Resilience) 입니다.

디지털과 로우테크 운영을 유연하게 오갈 수 있는 조직은 다음을 더 잘 해냅니다.

시스템을 격리해야 하는 상황에서도, 협업을 이어가며 사이버 인시던트를 더 빨리 통제한다
장기 장애 동안 혼란과 직원 번아웃을 줄인다
비록 축소 운영일지라도, 안전하고 통제된 방식으로 서비스를 이어가 고객 신뢰를 지킨다

회사를 종이 기반으로 다시 만들 필요는 없습니다. 대신 이렇게 하면 됩니다.

인정하라. 언젠가 큰 장애나 사이버 사고는, 지금 당연하게 쓰는 도구들을 우회하거나 무력화할 것이다.
설계하라. 의도적인 아날로그 워크플로, 역할, 커뮤니케이션 경로를 만들어 둔다.
연습하라. 실제 강제당하기 전에, 아날로그 모드로 전환하는 훈련을 해 둔다.

신뢰성 스택이 우리를 배신하는 순간, 비즈니스를 지켜 주는 것은 화려한 도구가 아니라 단순한 로우테크 전술로 되돌아갈 수 있는 능력입니다. 그 필드 가이드를 만들어야 할 때는 바로 지금입니다. 대시보드가 아직 초록불일 때, 불이 모두 꺼지기 전에 말입니다.