소개

요즘 신뢰성 스택은 화려합니다. 통합 플랫폼, 실시간 관측(Observability), 인시던트 봇, 자동화 런북, AI 기반 복구 지원까지. 하지만 여기에 위험한 전제가 하나 숨어 있습니다. 정작 가장 필요할 때, 이 도구들이 “접근 가능하고, 믿을 만할 것”이라는 가정입니다.

그렇지 않을 때는 어떻게 될까요?

생각해볼 만한 상황들:

• 채팅 플랫폼과 상태 페이지가 동시에 내려가는 장애
• SSO나 인증 장애로, 대응자가 도움을 받아야 할 도구에 접속하지 못하는 상황
• 스택 일부만 나머지와 통신 가능한 네트워크 분할(Network Segmentation) 사건
• 데이터 손상이나 잘못 구성된 대시보드가, 그럴듯하게 “완전히 틀린 이야기”를 들려주는 경우

이런 순간에야 팀은 비로소 알게 됩니다. 자신들에게 **진짜 백업 컨트롤 센터(backup nerve center)**가 있는지, 아니면 인시던트 프로세스가 1차 도구만큼이나 취약한지.

이 글에서는 의도적으로 로우테크이고, 의존성이 적은 백업 워룸 디자인인 **“아날로그 인시던트 정원 창고(Analog Incident Garden Shed)”**를 소개합니다. 자동화에 반대하는 개념이 아니라, 신뢰성 도구가 반란을 일으켰을 때를 위한 안전 그물(safety net)에 가깝습니다.

다음 내용을 다룹니다.

• 통합 플랫폼이 왜 도움이 되지만, 여전히 실패할 수 있는지
• Before–During–After(전–중–후) 관점을 아키텍처에 매핑하는 방법
• 실제로 로우테크 컨트롤 센터가 어떻게 생겼는지
• 구성요소 불신뢰성과 인간 피로에서 역사적으로 배운 교훈
• 직접 “정원 창고” 백업 센터를 프로토타입하는 구체적인 단계

1. 도구 난립, 통합 플랫폼, 그리고 숨은 단일 장애점(SPOF)

많은 조직은 신뢰성 문제에 대응할 때 도구를 더 추가하는 방식으로 움직입니다.

• 하나는 메트릭, 하나는 로그, 또 하나는 트레이스용
• 여러 개의 알림·페이징 시스템
• 복수의 런북 저장소(위키, 문서, 내부 도구 등)
• 애드혹 스프레드시트와 집에서 만든 대시보드

이런 **툴 스프로울(tool sprawl, 도구 난립)**은 오히려 자동화와 신뢰성 도구의 효과를 떨어뜨리는 경향이 있습니다.

• 사람들이 “단일 소스 오브 트루스”가 어디 있는지 모릅니다.
• 온보딩에 시간이 더 들고, 인시던트 대응 근육 기억이 약합니다.
• 위기 상황에서는 컨텍스트가 탭과 팀 사이에 흩어져 버립니다.

통합 플랫폼은 다음과 같은 식으로 도움을 줍니다.

• 여러 신호를 일관된 검색 가능한 공간으로 모으고,
• 알림이 도착하는 지점에서 바로 인시던트 워크플로(선언, 트리아지, 업데이트)를 수행하게 하고,
• 런북, 포스트모템, 커뮤니케이션 패턴을 표준화합니다.

하지만 통합 플랫폼은 곧 집중된 의존성 포인트, 즉 숨겨진 단일 장애점(SPOF)이 되기도 합니다.

• SSO나 IAM 레이어가 깨지면, 플랫폼 전체에 접근이 불가능해질 수 있습니다.
• 기본 데이터베이스나 네트워크 세그먼트가 영향을 받으면, 인시던트 도구도 함께 다운될 수 있습니다.
• 설정이나 데이터가 손상되면, 주요 대시보드가 매우 자신 있게 “틀린 방향”을 가리킬 수 있습니다.

해답은 “도구를 더 추가하라”가 아니라 **계층화된 설계(Intentional Layering)**입니다. 강력하고 통합된 1차 스택 위에, 의도적으로 훨씬 단순한 2차 스택을 얹는 것입니다.

여기에서 정원 창고(garden shed)가 등장합니다.

2. Before–During–After: 회복력을 설계하는 프레임워크

신뢰성 작업은 Before–During–After(사전–사고 중–사후) 렌즈를 적용하고, 이를 아키텍처에 직접 매핑하면 훨씬 이해하기 쉬워집니다.

Before: 준비와 예방

질문:

• 인시던트를 피하거나, 영향도를 줄이도록 시스템을 설계·테스트·문서화하는 방법은?
• 런북, 다이어그램, 연락망, 에스컬레이션 정책은 어디에 저장할까?

아키텍처 상 시사점:

• 고가용 문서 저장소(버전 관리, 복제)
• 도구 일부가 없는 상황을 가정한 교육과 모의훈련
• 중요한 서비스와 연락처를 위해 실물 출력(!!) 치트 시트 준비

During: 탐지, 조정, 대응

질문:

• 문제를 얼마나 빨리 탐지하고, 노이즈에서 신호를 분리할 수 있는가?
• 전사적 인시던트가 발생했을 때, 팀은 어디서 조정·협업을 하는가?
• 평소 사용하는 채팅/인시던트 도구를 사용할 수 없거나, 신뢰할 수 없다면?

아키텍처 상 시사점:

• 1차: 통합된 알림 + 인시던트 관리 + 채팅
• 2차: 디지털 도구가 실패해도 동작하는 로우테크 “컨트롤 센터(nerve center)”
• “도구 장애” 시나리오를 위한 명시적 플레이북 (예: “SSO 오프라인” 인시던트 타입)

After: 복구, 학습, 강화

질문:

• 1차 시스템이나 도구가 손상되거나 데이터가 망가졌을 때, 어떻게 서비스를 복원할까?
• 무슨 일이 있었는지를 어떻게 기록하고, 시스템·프로세스를 개선할까?

아키텍처 상 시사점:

• 지속적인 백업·복구 능력을 사후 단계의 안전망으로 확보
• 관측·인시던트 도구 자체를 복구하는 모의 복구 훈련 정기 실시
• 인시던트 후 회고에서, 도구 가용성과 의사결정 품질을 명시적으로 추적

이 프레임워크를 아키텍처 설계에 직접 보이게 반영하면, 다음이 선명해집니다.

• 각 단계를 누가 책임지는지
• 각 단계에서 데이터가 어디로 흐르는지
• 어떤 결정이 어디서 내려지는지, 그리고 그 지점이 사라지면 어떻게 되는지

3. 왜 로우테크 컨트롤 센터가 필요한가 (역사가 말해 주는 것들)

역사 속 많은 신뢰성 실패 사례는 크게 두 가지 축으로 귀결됩니다.

1. 구성요소 자체의 불신뢰성
2. 인간의 피로와 인지 과부하

예를 들어 2차 세계대전 당시, 초기 전자 장비(진공관, 원시적인 배선, 수작업 납땜 부품)는 자주 고장이 났습니다. 이런 부품을 길게 이어 붙인 시스템일수록 연쇄적인 장애에 취약했습니다. 당시 엔지니어들은 중복 설계, 디레이팅(derating, 한계 이하로 쓰기), 더 단순한 폴백 메커니즘으로 대응했지, 단순히 복잡성을 더 쌓지 않았습니다.

인간 측면에서는, 고강도 스트레스가 지속되는 상황에서 다음과 같은 문제가 생겼습니다.

• 피로로 인한 판단력 저하
• 반응 속도 지연
• 복잡한 절차를 수행할 때의 오류율 증가

현대 인시던트 대응에 주는 교훈은 분명합니다.

• 복잡하고 상호의존적인 도구일수록, 미묘한 실패나 잘못된 설정이 당신을 눈멀게 만들 가능성이 커집니다.
• 스트레스가 심한 상황에서 다단계 디지털 워크플로에 과도하게 의존할수록, 인간 피로의 영향이 커집니다.

의도적으로 설계된 **로우테크 “컨트롤 센터(nerve center)”**는, 이런 의미에서 2차 대전 시기 폴백 설계의 현대적 버전입니다.

• 움직이는 부품이 적고,
• 네트워크, 인증 레이어, 통합 UI 같은 깨지기 쉬운 구성요소에 대한 의존도가 낮으며,
• 스트레스 상황에서도 사람이 따라갈 수 있는 절차를 제공합니다.

4. 워룸과 정원 창고를 가동해야 할 때

워룸은 모든 PagerDuty 알림마다 여는 공간이 아닙니다. 보통은 다음과 같은 전면적, 고객 영향 대규모 장애 때 활성화합니다.

• 코어 데이터베이스 불가용성이나 데이터 손상
• 여러 리전에 걸친 결제 처리 실패
• 인증/SSO 시스템 장애
• 전체 트래픽에 영향을 미치는 주요 네트워크 분할이나 DNS 장애

이런 고임팩트 이벤트에서는 다음이 필요합니다.

• 강도 높은 크로스팀 협업
• 명확한 커맨드 구조(인시던트 커맨더, 커뮤니케이션 리드, 오퍼레이션 리드 등)
• 엔지니어링, 리더십, 고객 대응 팀 전체에 대한 빠르고 신뢰할 수 있는 공지

당신의 **주요 워룸(Primary War Room)**은 보통 다음에 존재합니다.

• 협업 플랫폼(Slack, Teams 등)
• 인시던트 관리 제품(브리지, 상태 페이지, 타임라인 기능 등)

반면 **정원 창고 컨트롤 센터(Garden Shed Nerve Center)**는, 다음과 같은 상황에서 가동되는 백업 워룸 설계입니다.

• 1차 협업 도구가 다운되거나 접근 불가할 때
• IAM/인증 문제로 팀 상당수가 도구에 접근하지 못할 때
• 주요 Observability 스택에서 나오는 데이터를 신뢰하기 어려울 때

트리거 조건은 명시적이어야 합니다. 예를 들어:

“Sev-1 인시던트 동안 인시던트 도구가 10분 이상 사용 불가이거나 신뢰할 수 없는 경우, Garden Shed 프로토콜을 가동한다.”

5. 아날로그 인시던트 정원 창고 설계하기

이를 최소한의 소프트웨어 지원만으로 운영 가능한 로우테크 백업 관제실을 설계하는 작업이라고 생각하면 됩니다.

5.1 위치와 인프라

물리적일 수도, 가상일 수도 있지만 다음 제약을 염두에 둡니다.

• 물리적 회의실: 화이트보드, 대형 출력물, 전용 전화선 구비
• 아웃오브밴드(Out-of-band) 연결성: 주 네트워크와 분리된 보조 ISP, LTE 핫스팟 등
• 접근 정책이 메인 SSO에만 전적으로 의존하지 않도록 설계할 것

완전히 물리적인 공간이 어렵다면, 가상으로라도 이를 에뮬레이션하되 다음을 가정해야 합니다.

• 일부 대응자는 전화만 사용할 수 있을 수 있고,
• VPN과 SSO는 불안정하거나 아예 불가능할 수 있습니다.

5.2 최소 도구 스택

정원 창고는 매우 단순하고, 독립적으로 복구 가능한 스택이어야 합니다.

• 음성 브리지(Voice Bridge): 메인 스택과 분리된 공급자에게서 제공받는 전화 회의 라인
• 아웃오브밴드 메세징: SMS, 전화 트리, 혹은 기본 인증 체계와 분리된 소규모 백업 채팅 채널
• 정적 문서(Static Docs): 인쇄물 또는 로컬 캐시된 PDF
  • 조직도 및 에스컬레이션 연락망
  • 중요 시스템의 상위 레벨 다이어그램
  • Sev-1 시나리오 및 “도구 장애” 인시던트용 런북
• 인시던트 로그 템플릿: 다음을 기록하기 위한 종이 또는 오프라인 템플릿
  • 시각, 결정, 액션, 오너
  • 외부 커뮤니케이션 이력

5.3 프로세스와 역할

정원 창고로 폴백했을 때 누가 무엇을 하는지를 명확히 정의합니다.

• 인시던트 커맨더(IC): 브리지를 운영하고, 작업을 할당하며, 우선순위를 명확히 유지
• 스크라이브(Scribe): 아날로그 인시던트 로그 기록 담당
• 커뮤니케이션 리드(Comms Lead): 사전 정의된 채널을 통해 이해관계자·고객 공지 담당

소수의 Garden Shed 플레이북을 공식화합니다.

• “SSO/인증 장애”: 팀을 소집하는 방법, 사용할 백업 계정
• “주요 Observability 다운”: 호스트 로컬 로그·메트릭 수집 방법과 전송 위치
• “네트워크 분할/VPN 장애”: 접근 가능한 사람 vs 불가능한 사람을 어떻게 조직할지

5.4 백업 및 복구 체계와의 정렬

정원 창고는 사후(After) 단계의 백업·복구 능력을 강하게 전제합니다.

• 지속적인 백업 대상
  • 코어 데이터베이스 및 설정 저장소
  • Observability 데이터(전체가 아니더라도, 핵심 서브셋)
  • 인시던트 도구 메타데이터(타임라인, 런북, 연락처 목록)
• 모의 복구 절차
  • 최소 기능의 Observability 복구
  • 인시던트 관리 도구의 축소/저하 모드 복구

다음과 같은 복합 시나리오 연습이 필요합니다.

1. 주요 장애 도중, 1차 인시던트 도구가 실패한다.
2. 팀이 Garden Shed 프로토콜을 가동한다.
3. 백업 문서를 사용해:
   • 올바른 백업을 식별하고,
   • 복구 단계를 실행하며,
   • 신뢰할 수 있는 상태의 백업에서 1차 도구(또는 축소된 서브셋)를 복원한다.

6. 30일 안에 나만의 정원 창고 프로토타입 만들기

거대한 프로그램이 필요하지 않습니다. **최소 기능 컨트롤 센터(Minimal Viable Nerve Center)**를 목표로 시작하세요.

1–2주차: 인벤토리 및 설계

• 현재 Sev-1 인시던트에서 사용하는 모든 도구를 나열합니다.
• SSO, VPN, 채팅, 인시던트 플랫폼, 대시보드 등 어떤 전제를 깔고 있는지 식별합니다.
• 백업 구조를 결정합니다.
  • 하나의 전화 브리지 공급자
  • 하나의 백업 메시징 채널
  • 하나의 정적 문서 저장 위치(그리고 인쇄된 바인더 한 권)

2–3주차: 구축 및 문서화

• 간결한 Garden Shed 플레이북(5–10페이지)을 작성합니다.
  • 가동 기준과 체크리스트
  • 역할과 책임
  • 연락처와 전화번호 목록
• 플레이북을 인쇄해, 1차 워룸과 백업 위치에 비치합니다.
• 가능하다면 물리적 공간을 세팅합니다(화이트보드, 인쇄된 다이어그램 등).

3–4주차: 모의훈련 및 개선

• 테이블탑(Tabletop) 연습을 진행합니다.
  • 시나리오: “결제 장애와 SSO 장애가 동시에 발생”
  • 팀이 정원 창고 리소스만 사용해 운영하도록 강제합니다.
• 마찰 지점을 수집하고 다음을 업데이트합니다.
  • 연락처 정보
  • 다이어그램
  • 런북과 체크리스트

이 연습을 연 2회 정도 반복하고, 실제 인시던트에서 얻은 교훈을 계속 반영합니다.

결론

하이테크 신뢰성 도구는 필수적이지만, 무오류는 아닙니다. 도구 난립은 효과를 희석시키고, 지나치게 중앙집중된 플랫폼은 보이지 않는 단일 장애점이 될 수 있습니다.

Before–During–After 인시던트 프레임워크를 아키텍처에 직접 매핑하면, 예방, 조정된 대응, 견고한 복구에 어디에 투자해야 할지 선명해집니다. 특히, 위기 관리에 사용하는 도구 자체를 복구하기 위해서라도, 지속적인 백업과 복구 능력은 사후 단계의 안전망이 됩니다.

그리고 대시보드가 꺼지고, 인증이 당신을 밖으로 밀어내며, 데이터가 서로 다른 이야기를 들려주는 그 순간에, 의도적으로 설계된 로우테크 컨트롤 센터—아날로그 인시던트 정원 창고—는 단순하고 탄탄한 폴백 수단을 제공합니다.

이것이 1차 워룸을 대체하지는 않습니다. 다만, 신뢰성 도구들이 반란을 일으키는 드문 날에도 고객을 지킬 수 있게 해 주는 마지막 방어선입니다.

질문은 “그런 날이 올까?”가 아닙니다. **“그날이 왔을 때, 당신에게 남은 것이 부서진 대시보드와 간절한 바람뿐이 아닐 것인가?”**입니다.