소개

대부분의 팀은 실패를 이미 너무 늦은 시점에서야 마주합니다.

워룸에 모이고, 인시던트 브리지를 열고, 실시간 고위험 환경에서 무엇이 잘못됐는지 진단하느라 허둥댑니다. 그 후에야 “다음엔 더 잘하자”고 다짐하고 몇 개의 알림을 더 추가하곤 하죠. 하지만 문제가 터지기 훨씬 전부터, 조용하고, 저렴하고, 안전하게 연습할 수 있다면 어떨까요?

여기서 등장하는 것이 바로 아날로그 실패 관측 데스크(Analog Failure Observatory Desk) 입니다. 프로덕션을 전혀 건드리지 않고 장애를 실험해 볼 수 있는 아주 작은 종이 기반 실험실입니다.

사회기술적 실패(sociotechnical failure)를 위한 테이블탑 시뮬레이터라고 생각하면 됩니다. 포스트잇, 출력한 다이어그램, 인덱스 카드, 체크리스트를 사용해 시스템이 어떻게 망가지는지, 그리고 사람들은 어떻게 대응하는지를, 누구의 페이저도 울리기 전에 미리 탐색해 보는 것입니다.

이 글에서는 이 데스크가 왜 중요한지, 어떻게 만들고 활용하는지, 그리고 이를 회복탄력성 공학(Resilience Engineering), 카오스 엔지니어링(chaos engineering), 컴플라이언스, 전력망 의존성 같은 현실적인 리스크와 어떻게 연결할 수 있는지 살펴봅니다.

왜 ‘아날로그 실패 데스크’인가?

대부분의 실패 관련 작업은 비트와 바이트에 집중합니다.

• 깨진 코드
• 잘못 설정된 서비스
• 장애가 발생한 의존성

하지만 실제 장애는 **사회기술적 현상(sociotechnical phenomena)**입니다. 다음 요소들이 얽혀서 나타납니다.

• 인간: 역량, 멘탈 모델, 스트레스, 피로
• 프로세스: 런북, 에스컬레이션 경로, 승인 절차
• 기술: API, 큐, 데이터베이스, 네트워크
• 맥락: 규제, 리스크 허용도, 고객 기대

종이 기반의 ‘실패 데스크’는 이런 상호작용을 탐색할 수 있는 저위험 샌드박스를 제공합니다.

왜 아날로그일까요?

• 저위험: 프로덕션 접근 없음, 실제 고객 영향 없음.
• 저마찰: 펜, 종이, 인덱스 카드는 풀 디지털 시뮬레이터를 만드는 것보다 훨씬 싸고 빠릅니다.
• 인간 중심: 자동화가 없을수록 사람들이 실제로 어떻게 생각하고, 결정하고, 적응하는지가 더 잘 드러납니다.
• 접근성: 엔지니어뿐 아니라 프로덕트, 법무, 컴플라이언스, 보안, 고객지원까지 누구나 참여할 수 있습니다.

목표는 전체 아키텍처를 완벽하게 시뮬레이션하는 것이 아닙니다. 놀라운 상호작용이 드러날 만큼만 현실적인, 작지만 불완전한 모델을 만드는 것입니다.

작은 종이 실험실 설계하기

전용 방이나 화려한 설치물을 준비할 필요는 없습니다. 구석의 테이블 하나나 이동식 카트 정도면 충분합니다. 중요한 것은 의도적인 구조화입니다.

핵심 구성 요소

아날로그 실패 관측 데스크에 다음과 같은 것들을 갖춰 두세요.

• 시스템 맵(System Maps)

  • 현재 또는 단순화된 아키텍처 다이어그램 출력본
  • 데이터 플로우 차트와 의존성 맵
  • 외부 의존성 (결제 프로세서, 클라우드 제공자, 전력망 등)

• 역할 카드(Role Cards)

  • 온콜 엔지니어, SRE, 프로덕트 매니저, 인시던트 커맨더
  • 보안 담당자, 컴플라이언스 담당자, 고객지원
  • 외부 이해관계자(규제기관, 대형 엔터프라이즈 고객 등)

• 시나리오 카드(Scenario Cards)

  • “프라이머리 DB 리드 레플리카가 30분 지연되기 시작한다.”
  • “클라우드 리전에서 부분적인 네트워크 파티션이 발생한다.”
  • “인시던트 도중 규제기관이 긴급 데이터 처리 지침을 발행한다.”
  • “한 주요 오피스에 정전이 발생하지만 원격 근무자는 영향을 받지 않는다.”

• 제약 & 리스크 카드(Constraint & Risk Cards)

  • 규제 제약 (예: “고객 데이터는 X 리전을 벗어나면 안 된다.”)
  • 보안 제약 (예: “모든 긴급 접근은 로깅 및 검토 대상이다.”)
  • 비즈니스 제약 (SLA, 비용 상한, 계약상 벌금 등)

• 프로세스 보조 도구(Process Aids)

  • 인시던트 타임라인 시트
  • 커뮤니케이션 템플릿 (상태 공지, 내부 Slack/메신저 메시지, 임원 보고 요약)
  • 포스트 인시던트 리뷰 템플릿

• 기본 사무용품

  • 여러 색상의 포스트잇
  • 인덱스 카드
  • 두꺼운 마커펜
  • 테이프, 끈(벽/화이트보드에 의존성을 표시할 때 사용)

당신의 목표는 사람들이 다음을 할 수 있는 물리적 환경을 만드는 것입니다.

1. 시스템을 빠르게 모델링하고
2. 현실적인 실패 상황을 상상하며
3. 협조된 대응을 연습하고
4. 무엇이 도움이 되었고 무엇이 방해가 되었는지 되돌아보는 것

실패는 사회기술적이다: 단순한 ‘버그 찾기’를 넘어서

전통적인 인시던트 실습은 종종 실패를 주로 기술적인 문제로 가정합니다. 버그, 잘못된 설정, 고장 난 서버 같은 것들 말이죠.

하지만 실제 장애는 다음과 같은 것들에서 비롯되곤 합니다.

• 모호한 문서화: 두 팀이 같은 정책을 서로 다르게 해석
• 불일치하는 인센티브: 프로덕트는 속도를, 인프라는 안정성을 우선
• 숨겨진 결합(Hidden couplings): 거의 사용되지 않는 API가 취약한 레거시 서비스에 의존
• 인지적 과부하(Cognitive overload): 온콜 담당자가 스트레스 상황에서 모든 움직이는 부분을 따라가지 못함

데스크를 중심으로 모이면 이 요소들을 눈에 보이는 형태로 드러낼 수 있습니다.

예시 연습:

1. 큰 종이에 단순화된 아키텍처를 그립니다.
2. 참가자들에게 다음 내용을 포스트잇으로 붙이게 합니다.
   • “우리가 의존하지만 실제로는 검증하지 않는 가정”
   • “이건 ‘충분히 안전하다’고 생각하는 이유…”
   • “이게 조용히 실패한다면, 누가 가장 먼저 눈치챌까?”
3. 이제 시나리오 카드를 하나 꺼냅니다. 예: “외부 결제 게이트웨이가 간헐적으로 5xx 에러를 반환하기 시작한다.”
4. 다음을 토론합니다.
   • 누가 가장 먼저 페이저를 받나?
   • 누가 가장 먼저 받아야 하는가?
   • 어떤 가정이 제일 먼저 무너지는가?
   • 어떤 팀이 나중에야 끌려 들어와서 놀라게 되는가?

이제 단순히 코드를 디버깅하는 것이 아니라, 조정(coordination), 커뮤니케이션, 멘탈 모델을 디버깅하는 셈입니다.

세이프티-I와 세이프티-II: 실패뿐 아니라 성공도 연구하기

회복탄력성 공학(Resilience Engineering)은 중요한 관점 전환을 제안합니다.

• Safety-I: 무엇이 잘못되는지에 초점. 실패를 방지하고, 오류를 최소화한다.
• Safety-II: 무엇이 잘 되는지에 초점. 사람들이 다양한 상황에서 어떻게 적응하고 성공하는지 연구한다.

데스크에서는 두 가지를 모두 다룹니다.

데스크에서의 Safety-I

이 작은 실험실을 활용해 다음을 할 수 있습니다.

• 과거 인시던트를 종이 위에서 재구성
• 의사결정 지점과 정보 격차를 맵으로 정리
• 절차나 도구가 상황을 더 어렵게 만든 지점을 찾기
• 다른 대응 방식을 시도해 결과가 어떻게 달라지는지 살펴보기

데스크에서의 Safety-II

세션을 하나 정해서 **“평소에는 어떻게 해서 잘 굴러가는가?”**만 다뤄 보세요.

• 온콜 엔지니어에게 일상적인 우회(workaround)를 맵으로 그려달라고 합니다.
  • “알람이 시끄럽지만 실제 장애일 수도 있을 때, 어떻게 하세요?”
  • “동시에 여러 페이저가 울릴 때, 무엇을 우선순위에 두나요?”
• 이런 **적응(adaptation)**을 포스트잇으로 기록합니다.
  • 비공식 대시보드
  • 사이드 채널 커뮤니케이션(비공식 채팅방 등)
  • 런북에 조용히 추가해 둔 작은 꼼수들

이런 일상적인 적응은 회복탄력성의 원천이지, “절차 위반”으로만 봐서는 안 됩니다. 이를 문서화하고, 이해하며, 필요하다면 공식적으로 지원하거나 제도화해야 합니다.

종이 위에서 하는 카오스와 인시던트 드릴

카오스 엔지니어링과 인시던트 대응 연습을 아날로그 환경으로 가져올 수 있습니다.

아날로그 카오스 연습(Analog Chaos Exercises)

1. 시스템의 한 조각 선택하기
   로그인, 결제(Checkout), 데이터 내보내기, 배치 처리 등 중요한 플로우 하나를 고릅니다.

2. 카드로 실패를 주입하기
   예시:

   • “서비스 A와 B 사이의 레이턴시가 2초로 급증한다.”
   • “DNS 오구성으로 인해 전체 사용자 중 10%의 트래픽 라우팅이 깨진다.”

3. “실제로는 무엇이 일어날까?”를 묻기

   • 어떤 모니터링 알람이 뜨는가?
   • 어느 팀이 첫 번째 증상을 가장 먼저 보게 되는가?
   • 사용자는 어떤 경험을 하게 되는가?

4. 종이 위에서 시스템을 수정해 보기

   • 캐시를 하나 더 추가하면 무엇이 달라지는가?
   • 레이트 리밋(rate limit)을 추가하면 누가 보호되고, 누가 보호받지 못하는가?

목표는 정밀한 시뮬레이션이 아니라, 실제 환경에서 카오스 실험을 하기 전에 가정과 취약 지점을 드러내는 것입니다.

인시던트 대응 롤플레이(Incident Response Roleplay)

테이블탑 인시던트 드릴을 진행해 보세요.

• 역할 카드를 사용해 역할을 배정합니다. (인시던트 커맨더, 커뮤니케이션 담당, 테크 리드, 보안, 컴플라이언스 등)
• 시나리오를 한 번에 다 주지 말고, 5–10분 간격으로 새로운 징후나 제약을 조금씩 추가하며 전개합니다.
• 다음을 추적합니다.
  • 의사결정이 어떻게 이뤄지는가
  • 누구에게 언제 자문을 구하는가
  • 정보가 어떻게 흐르고, 어디에서 막히는가

마무리로 구조화된 디브리핑을 진행합니다.

• 협업에 도움이 된 것은 무엇인가?
• 어디에서 논쟁하거나 멈칫했는가?
• 어떤 런북이나 도구가 없어서, 혹은 모호해서 힘들었는가?

이 과정은 협조와 조정의 근육을, 아무 리스크 없는 환경에서 단련하는 것입니다.

지식 공유와 크로스 펑셔널 학습을 위한 데스크 활용법

이 데스크는 **지식 공유 공간(knowledge commons)**으로도 기능할 수 있습니다.

포스트 인시던트 리뷰(Post‑Incident Reviews)

슬라이드 덱 대신, 인시던트를 물리적으로 재구성해 보세요.

• 테이블 위에 긴 타임라인 스트립을 깔고
• 이벤트, 결정, 신호, 불확실성을 각각 포스트잇으로 붙입니다.
• 색상을 달리해 기술적 이벤트, 인간의 결정, 외부 압력 등을 구분합니다.

그 위를 함께 걸어가듯 보면서, 고객지원, 프로덕트, 영업, 보안, 컴플라이언스 등 다양한 역할의 사람들을 초대합니다.

질문 예시:

• “어떤 부분이 가장 놀라웠나요?”
• “그 순간에 어떤 맥락이 더 있었다면 도움이 되었을까요?”
• “평소 인시던트 리포트에서는 보이지 않는 부분이 어디인가요?”

이 통찰을 다음과 같이 전환합니다.

• 업데이트된 런북
• 새로운 교육/훈련 시나리오
• 관찰 가능성(observability)이나 안전성을 개선하는 설계 변경

크로스 펑셔널 드릴(Cross‑Functional Drills)

엔지니어링 외의 역할도 현실적인 방식으로 연습에 참여시킬 수 있습니다.

• 법무/컴플라이언스: “규제기관이 이런 질문을 한다면, 어떻게 답변하시겠어요?”
• 보안: “이 완화 조치가 우리 위협 모델 상 허용 가능한가요?”
• 프로덕트: “리더십에 어떤 트레이드오프를 제안하시겠어요?”

이런 연습은 **공유된 멘탈 모델(shared mental model)**을 만들고, 실제 인시던트 시에 서로를 비난하기보다 협업하는 문화를 만듭니다.

컴플라이언스, 보안, 현실 세계 제약을 잊지 말 것

장애 시나리오는 실제 프로덕션에서 매우 중요한 다음 제약들을 종종 간과합니다.

• 데이터 레지던시 및 개인정보 보호 규제
• 산업별 요구사항 (HIPAA, PCI DSS, SOC 2 등)
• 내부 리스크 한도와 감사 가능성(auditability)

데스크에서는 이들을 주요 요소로 다뤄야 합니다.

• 시나리오 중간에 꺼낼 수 있는 컴플라이언스/보안 제약 카드를 만듭니다.
  • “해당 데이터는 리전 X를 절대 벗어나면 안 됩니다.”
  • “긴급 접근은 반드시 사유를 남기고 로깅해야 합니다.”
  • “암호화 키는 어떠한 경우에도 반출할 수 없습니다.”
• 팀이 서비스 복구와 제약 준수를 동시에 만족하는 대응 전략을 찾도록 도전합니다.

이렇게 하면, 대응자들이 “어떤 빠른 해결책이든”이 아니라, **안전하고 컴플라이언스를 준수하는 적응(safe, compliant adaptation)**을 자연스럽게 떠올리는 습관을 기르게 됩니다.

사용자의 두려움, 의존성, 그리고 전력망

인시던트는 단순한 업타임 문제가 아니라, 시스템 뒤에 있는 것들에 대한 사람들의 두려움과 의존성의 문제이기도 합니다.

특히 **전력망(power grid)**에 대한 의존성은 시스템 설계와 인시던트 대응을 크게 좌우합니다.

• 사용자들은 전기가 “당연히 항상 들어온다”고 가정하지만, 정전은 다음과 같은 연쇄 문제로 이어질 수 있습니다.
  • 데이터센터 장애
  • 네트워크/연결성 상실
  • 결제 단말기 다운타임
• 팀은 종종 클라우드 제공자의 장애만 설계에 반영하고, 그 이전 단계 인프라의 취약성은 고려하지 않곤 합니다.

데스크에서 다음을 탐색해 보세요.

• 클라우드 리전 하나와 대도시 한 곳에 동시에 정전이 나는 시나리오
• 백업 발전기가 실패했을 때 핵심 서비스는 어떻게 동작하는지
• 기업 네트워크가 완전히 끊긴 상황에서 어떤 커뮤니케이션 채널이 남는지

그리고 이런 질문을 던져 보세요.

• “위기 상황에서 우리 서비스는 사용자에게 어떤 의미를 가지나요?”
• “기술적 해결책이 아니더라도, 더 나은 안내, 오프라인 대안, 수동 프로세스 같은 방식으로 피해를 줄일 수 있는 방법은 없을까?”

이런 질문은 사고방식을 순수한 비용 최적화에서 **인간 중심 회복탄력성(human‑centric resilience)**으로 전환하게 해 줍니다.

결론: 작게 시작해, 계속 배우기

아날로그 실패 관측 데스크가 모든 장애를 예측하거나 실제 테스트를 대체해 주지는 않습니다. 애초에 그럴 의도로 만든 도구가 아닙니다.

이 도구의 가치는 다음에 있습니다.

• 시스템, 사람, 프로세스가 스트레스 상황에서 어떻게 상호작용하는지 저위험 환경에서 탐색할 수 있다.
• **회복탄력성 공학(Resilience Engineering)**과 Safety‑II 관점을 일상적인 업무에 스며들게 한다.
• 카오스 실험과 인시던트 드릴을 예외적인 이벤트가 아닌, 루틴 활동으로 정착시킨다.
• 컴플라이언스, 보안, 사용자 현실을 장애 대비의 중심에 놓는다.

이번 주 안에 바로 시작할 수 있습니다.

1. 책상이나 테이블 하나를 확보합니다.
2. 단순한 아키텍처 다이어그램을 한 장 출력합니다.
3. 장애 시나리오 카드 3장과 제약 카드 3장을 작성합니다.
4. 동료 몇 명을 불러 60분짜리 테이블탑 세션을 해 봅니다.

그 다음에는 실험실을 진화시키면 됩니다. 시나리오를 더하고, 역할 카드를 다듬고, 실제 인시던트에서 얻은 인사이트를 계속 반영하세요.

이 작은 종이 실험실에서 실패를 많이 연습할수록, 실제 장애가 닥쳤을 때 조직은 더 잘 준비된 상태가 되어 있을 것입니다.