Rain Lag

종이만으로 하는 장애 캠프파이어: 사고를 팀의 folklore로 바꾸기

저기술, 종이 기반 스토리 서클을 통해 장애를 기억에 남는 팀의 이야기로 바꾸고, 인시던트 대응 역량을 강화하며, 더 탄탄한 엔지니어링 문화를 만드는 방법.

종이만으로 하는 장애 캠프파이어: 사고를 팀의 이야기(folklore)로 바꾸기

현대 인시던트 대응은 디지털 도구가 장악하고 있습니다. 대시보드, 타임라인, 화상 회의, 티켓 시스템, 런북, 그리고 슬랙 워룸까지. 모두 없어서는 안 될 도구입니다.

하지만 사태가 일단락된 뒤, 가장 강력한 도구는 놀랍도록 단순할지도 모릅니다. 사람들이 앉은 동그라미, 몇 자루의 펜, 그리고 한 꾸러미의 종이.

이게 바로 **종이만으로 하는 장애 캠프파이어(paper-only outage campfire)**라는 아이디어입니다. 포멀한 사후 인시던트 리뷰를 보완하는, 저기술·스토리 중심 세션이죠. 인시던트 리포트, 근본 원인 분석(RCA), 사이버 인시던트 대응 계획을 대체하려는 게 아닙니다. 대신, 쉽게 휘발되는 인시던트 지식을 기억에 남는 팀의 folklore로 바꿔 실제로 남게 만드는 방법입니다.


왜 RCA 이후에 “캠프파이어”가 필요한가

정식 사후 인시던트 리뷰(post-incident review)는 보통 이런 질문에 답하기 위해 설계됩니다.

  • 무엇이 일어났는가?
  • 왜 일어났는가?
  • 다시 일어나지 않게 하려면 무엇을 해야 하는가?

필수적인 절차이지만, 동시에 한계도 분명합니다.

  • 사람의 경험보다는 기술적 정확성이 우선되기 쉽습니다.
  • 끝까지 정독하는 사람이 거의 없는 문서를 양산합니다.
  • 감정적 맥락, 판단의 순간, 암묵지(tacit knowledge)를 놓치기 쉽습니다.

종이 기반 캠프파이어 세션은 같은 인시던트를, 그 상황을 실제로 겪은 사람들이 들려주는 "이야기"로 다시 구성합니다. 이 이야기는 다음과 같은 효과를 냅니다.

  • 인시던트를 훨씬 기억하기 쉽게 만들고,
  • 결정과 트레이드오프에 인간적인 얼굴을 붙이고,
  • 프로세스·교육·커뮤니케이션의 빈틈을 드러내고,
  • “우리는 이렇게 위기를 다룬다”라는 팀의 공통 언어와 folklore를 만듭니다.

이런 이야기들이 시간이 지나며 팀 정체성의 일부가 됩니다. 그리고 신입 온보딩, 좋은 관행의 강화, 여러 인시던트에 걸친 패턴 발견에 강력한 도구가 됩니다.


종이만으로 하는 장애 캠프파이어란 무엇인가?

종이만으로 하는 장애 캠프파이어는 포멀한 인시던트 리뷰가 끝난 이후(또는 최소한 급한 불이 꺼진 뒤)에 진행하는, 구조화된 저기술 스토리텔링 서클입니다.

핵심 특징은 다음과 같습니다.

  • 노트북·프로젝터·대시보드 없음. 펜, 포스트잇, 인덱스 카드, 그리고 필요하다면 화이트보드만 사용합니다.
  • 본질적으로 블레이멧(blameless). 초점은 배움이지, 책임 추궁이 아닙니다. 인사고과도, “꼬투리 잡기” 질문도 없습니다.
  • 내러티브 중심. 참가자들이 인시던트를 하나의 이야기로 재구성합니다. 등장인물, 타임라인, 갈등, 전환점, 결말, 교훈까지.
  • 프로세스 인식. 사이버 인시던트 대응 계획(cyber incident response plan) 같은 기존 절차를 실제로 어떻게 따랐는지도 명시적으로 짚어봅니다.
  • 멀티디서플리너리. 엔지니어, 인시던트 리스폰더, 리더십, 그리고 필요하다면 고객 대응 역할까지 함께 합니다.

인시던트 포스트모템, 작가들의 방(writers’ room), 팀 상담(therapy session)을 섞어 놓은 것 같은 자리인데, 모든 것이 종이로만 진행된다고 보면 됩니다.


종이만으로 하는 장애 캠프파이어 진행 방법

1. 프레임 세팅: 블레이멧 스토리텔링

먼저 그라운드 룰을 명확히 선언합니다.

  • 비난·망신 금지. 인시던트는 개인의 실패가 아니라 시스템 전체의 결과로 다룹니다.
  • 목표는 공동 학습. 무엇이 일어났는지, 시스템을 어떻게 개선할지 이해하기 위한 자리입니다.
  • 모든 관점이 중요하다. 사람마다 본 것이 다릅니다. 바로 그 다양성이 핵심입니다.

이걸 소리 내어 말합니다. 필요하다면 플립차트에 써 두세요. 심리적 안전감이 있어야 솔직한 스토리텔링이 가능합니다.

2. 등장인물(Cast of Characters) 정리

종이나 화이트보드에 이 이야기의 “등장인물”을 적습니다.

  • 사람들: 온콜 엔지니어, 인시던트 커맨더(IC), SRE, 보안 분석가, 고객 지원 리드, 임원 이해관계자 등
  • 시스템: 결제 API, 로깅 파이프라인, 네트워크 엣지, SSO 프로바이더 등
  • 외부 요인: 벤더 장애, DDoS 공격, 규제 마감 기한, 대형 고객 론칭 등

간단한 레이블이나 재미있는 별명을 붙여도 좋습니다. 캐릭터가 있어야 이야기가 머리에 남습니다. “Database Guardian이 리플리케이션 지연을 발견했을 때…”는 “DBA #3가 메트릭을 확인했다”보다 훨씬 기억에 남습니다.

3. 손으로 타임라인 그리기

이제 단순한 타임라인을 종이에 그립니다.

  • 시작: 처음 이상 징후를 감지한 시점은 언제인가?
  • 중간: 주요 의사 결정, 에스컬레이션, 중요한 발견은 무엇이었나?
  • 끝: 언제, 어떻게 인시던트 종료를 선언했나?

사람들에게 포스트잇으로 이벤트를 추가하게 합니다.

  • “02:13에 페이저 울림; 로그는 비어 있었음”
  • “지름길 선택: 의존성 X 확인 대신 서비스 재시작”
  • “리더십이 브리지 콜에 합류; 커뮤니케이션 속도 느려짐”
  • “마지막에야 방화벽 룰을 확인함”

직접 쓰고, 붙이고, 옮기는 행위 자체가 참여자들이 그때의 혼란을 외부화하고, 이야기의 흐름을 눈으로 보게 만듭니다.

4. 절차와 플레이북을 이야기 속에 녹여 넣기

이제 스토리와 프로세스를 연결할 차례입니다.

명시적으로 물어보세요.

  • “어디에서 사이버 인시던트 대응 계획을 그대로 따랐나요?”
  • “어디에서 벗어났나요? 그리고 왜였나요?”
  • “다음 단계가 무엇인지 몰랐던 순간이 있었나요?”

타임라인 위에 기호나 색을 써서 표시합니다.

  • 초록 점: 문서화된 절차를 따른 지점
  • 노란 삼각형: 즉흥적이었지만 합리적인 이탈
  • 빨간 느낌표: 혼란, 상충되는 지시, 가이드 부재

사람을 평가하는 게 아니라, 문서와 교육을 스트레스 테스트하는 시간입니다. 스토리 속에서 혼란이 드러나는 곳에는 대개 이런 문제가 있습니다.

  • 런북이 오래되거나 불완전함
  • 소유권과 역할이 애매함
  • 경험이 적은 리스폰더를 위한 교육 부족

5. 갈등과 해소를 분명히 드러내기

좋은 이야기에는 항상 갈등이 있습니다.

  • 상충하는 우선순위 (서비스 복구 vs. 근본 원인 파악)
  • 팀 간 긴장 (보안 vs. 가용성, 프로덕트 vs. 인프라)
  • 정보 공백 (로그 부재, 메트릭 지연, 잘못된 대시보드)

참가자들에게 종이에 힘들었던 순간을 적어보게 합니다.

  • “롤백 vs 롤포드로 격하게 논쟁함”
  • “보안 팀은 시스템을 계속 내리고 싶어 했고, 세일즈는 패닉 상태였음”
  • “누가 인시던트 종료를 선언할 권한이 있는지 몰랐음”

그다음, 이 갈등이 어떻게 해소되었는지도 함께 정리합니다.

  • 누가 최종 결정을 내렸는가?
  • 어떤 정보가 방향을 바꾸게 만들었는가?
  • 어떤 우회책이나 ‘해킹’이 상황을 살려냈는가?

이 전환점을 쉬운 언어로 남겨두면, 이야기 자체도, 그 속의 교훈도 훨씬 오래 기억됩니다.

6. 다양한 관점을 의도적으로 끌어내기

여러 이해관계자의 목소리가 꼭 들리도록 합니다.

  • 엔지니어링 / SRE: 어떤 부분이 명확해 보였고, 어떤 부분이 헷갈렸는가?
  • 인시던트 대응 / 보안: 플레이북은 실제 압박 상황에서 어떻게 작동했는가?
  • 리더십: 언제 상황 인식(situational awareness)이 충분하다고 느꼈고, 언제 부족했다고 느꼈는가?
  • 고객 대응 팀: 외부에 리스크와 영향을 어떻게 설명했는가?

각 그룹에 종이에 3~5개의 관찰을 적게 한 뒤, 함께 벽에 붙이고 클러스터링합니다.

금방 이런 패턴이 드러날 것입니다.

  • 엔지니어링은 커뮤니케이션이 괜찮았다고 느끼지만, 지원 팀은 완전히 깜깜이라고 느낄 수 있습니다.
  • 보안 팀은 대응 계획이 잘 지켜졌다고 생각하지만, 엔지니어는 그런 계획이 있는지도 몰랐을 수 있습니다.
  • 리더십은 “덜 자세한 내용을, 더 자주” 원하지만, 리스폰더는 “너무 자세한 내용을, 너무 가끔” 보냈을 수 있습니다.

이런 패턴은 다음 인시던트에서 팀 간 공조를 개선하는 데 매우 귀중한 데이터입니다.

7. 인사이트를 즉석에서 액션으로 바꾸기

다 같이 추억만 하고 끝나는 캠프파이어는 의미가 없습니다.

세션 마지막 부분은 인사이트를 구체적인 변화로 번역하는 데 씁니다.

종이에 세 개의 칼럼을 만듭니다.

  1. 문서 개선(Fix Documentation)

    • 오래되거나 맞지 않는 런북
    • 빠져 있는 에스컬레이션 경로
    • 혼란스럽거나 상충되는 플레이북
  2. 프로세스 / 프로토콜 개선(Improve Process / Protocols)

    • 인시던트 역할(IC, 커뮤니케이션 리드, 운영 리드 등) 명확화
    • 승인 플로우 간소화
    • 인시던트 선언/종료 기준 정의
  3. 교육 & 훈련(Training & Drills)

    • 신규 온콜 엔지니어 대상 시뮬레이션
    • 시나리오 기반 보안/대응 교육
    • 팀 간 친숙도를 높이기 위한 섀도잉(shadowing)

각 항목을 구체적으로 적고, 오너를 배정한 다음, 그 이후에야 디지털 티켓 시스템이나 추적 도구에 옮깁니다.

저기술이라는 제약 덕분에 대화는 사람과 경험에 더 집중되고, 이후의 체계적인 후속 조치가 진짜 가치를 만들어 줍니다.


공유된 이야기와 회복탄력성(Resilience) 만들기

이 종이 기반 캠프파이어를 정기적으로 운영하세요. 큰 인시던트 이후에는 반드시, 중간 규모 인시던트에도 가끔씩.

시간이 지나면 중요한 변화가 생깁니다.

  • “DNS 벤더가 다운됐던 그때” 같은 이야기가, 특정 세이프가드가 왜 존재하는지 설명하는 약속된 표현이 됩니다.
  • 신입 구성원은 팀의 불문율과 문화—위기 때 어떻게 말하고, 어떻게 결정하며, 무엇을 ‘좋은 대응’으로 보는지—를 훨씬 빨리 익힙니다.
  • 반복되는 스토리들을 통해 구조적인 문제가 드러납니다. 예: 야간 상시 인력 부족, 깨지기 쉬운 의존성, 모호한 소유권.

이렇게 팀의 folklore가 만들어집니다.

  • 함께 겪은 어려움에 대한 공유된 이야기
  • 리스크와 트레이드오프를 설명하는 공통 언어
  • “우리는 더 심한 것도 겪어 봤고, 그걸 이겨낸 팀이다”라는 감각

이 folklore는 단순히 “문화가 좋아지는” 수준을 넘어, 직접적으로 **운영 회복탄력성(operational resilience)**을 높입니다. 다음 장애가 닥쳤을 때 사람들은 읽히지 않은 PDF가 아니라, 기억 속에 살아 있는 이야기에서 행동 방침을 꺼내기 때문입니다.


조직에서 실제로 적용하는 방법

몇 가지 실용적인 팁입니다.

  • 짧고 집중되게. 대부분의 인시던트는 60–90분이면 충분합니다.
  • 세션당 인시던트는 하나만. 한 번 캠프파이어에 여러 사건을 섞으면 이야기의 힘이 희석됩니다.
  • 퍼실리테이터를 로테이션. 한 사람에게만 맡기지 말고, 여러 사람이 이 서클을 진행할 수 있게 훈련하세요.
  • 이야기를 나중에 간단히 문서화. “팬텀 레이턴시의 밤(The Night of the Phantom Latency)” 같은 짧은 내러티브와 핵심 인사이트를 정리해, 정식 RCA 문서 옆에 두세요.
  • 파일럿으로 시작. 다음 대형 인시던트 이후 한 번 시도해 보고, 참여자들에게 솔직하게 물어보세요. “이게 유용했나요? 다음에는 무엇을 바꾸면 좋을까요?”

결론: 전기가 나가도, 종이는 여전히 작동한다

자동화와 대시보드가 당연한 시대에, 종이만으로 하는 장애 캠프파이어는 약간 시대착오적이거나 심지어 반항적으로 느껴질 수 있습니다. 하지만 바로 그 단순함이 핵심입니다.

다음과 같은 방식으로

  • 인시던트를 구조화된, 블레이멧 스토리로 바꾸고,
  • 절차와 대응 계획이 실제로 어떻게(또는 어떻게 하지 못했는지) 작동했는지 명시적으로 들여다보고,
  • 엔지니어링, 인시던트 대응, 리더십 등 다양한 관점을 한자리에 모으고,
  • 그 인사이트를 활용해 문서를 고치고, 프로토콜을 다듬고, 교육과 훈련을 설계하면,

단발성 재난처럼 보이는 장애가 팀을 강화하는 **공유된 이야기(folklore)**로 변합니다.

다음 번 시스템이 복구되고, 줌 콜이 끝났다고 해서 티켓만 닫고 넘어가지 마세요. 사람들을 화이트보드 근처에 모으고, 펜을 나눠주고 이렇게 시작해 보세요.

“자, 그날 진짜로 어떤 기분이었는지, 뭐부터 어떻게 무너졌는지부터 얘기해 볼까요….”

회복탄력성은 바로 거기서 시작됩니다.

종이만으로 하는 장애 캠프파이어: 사고를 팀의 folklore로 바꾸기 | Rain Lag