아날로그 장애 스토리 카드 회전탑: 누구 탓이 아닌 ‘리스크’로 장애를 관리하기

디지털 장애 관리 도구는 강력하다. 대시보드, 포스트모템 문서, 알림 시스템은 모두 필수적이다. 하지만 한 가지를 대부분 잘 못한다. 바로 일상 속에서 계속 눈에 띄게 유지되는 것이다.

장애가 한 번 “종료”되면, 그 이야기는 위키나 티켓 시스템 속으로 사라진다. 팀은 다른 일로 넘어간다. 몇 주 후 비슷한 패턴이 다시 나타나고, 모두 또 한 번 놀란다.

만약 장애들이 절대 사라지지 않는다면? 진짜로 여러분 책상 위에 놓여서, 배울 때까지 계속 쳐다보고 있는 존재라면 어떨까?

여기서 등장하는 것이 바로 **아날로그 장애 스토리 카드 회전탑(Incident Story Card Carousel)**이다. 회전하는 책상 탑에 장애 카드를 꽂아두고, 그것들을 눈에 보이는 실물로 만들며, 무엇보다도 **‘누가’가 아니라 ‘어떤 리스크인가’**로 정렬하는 방식이다.

놀랄 만큼 단순한 이 로우테크 방식은 문화, 학습, 리스크 감소에 깊은 변화를 가져올 수 있다.

장애 스토리 카드 회전탑이란 무엇인가?

세로로 길게 세워진 회전식 카드홀더를 떠올려 보자. 명함이나 레시피 카드를 꽂는 데 쓰는 그런 탑 말이다. 이제 그 카드 하나하나가 작은 장애 스토리라고 상상해보자.

• 짧은 제목: “체크아웃 서비스 DB 커넥션 풀 고갈”
• 발생 일시와 지속 시간
• 고객 및 시스템에 미친 영향
• 무엇이 트리거였는지
• 어떻게 복구했는지
• 어떤 후속 조치가 나왔는지

이 카드들은 모두 팀 책상이나 공유 공간에 있는 회전식 카드 탑에 꽂혀 있다. 손으로 한 번 돌리면, 지난 수개월간의 실제 장애, 근접 사고(near miss), 계획된 점검 이벤트를 한눈에 훑어볼 수 있다.

이것은 기존 디지털 도구를 대체하는 것이 아니다. 항상 눈에 보이는 물리적 레이어를 하나 더 두어, 장애를 팀의 머릿속 전면에 계속 남겨두고, 즉흥적인 회고와 대화를 자연스럽게 유도하는 장치다.

“누가 망가뜨렸나”가 아닌, 리스크 기준으로 정렬하기

대부분의 장애 히스토리는 암묵적으로 ‘소유 팀’ 기준으로 분류된다.

• “이건 SRE 장애였어.”
• “이건 프론트엔드 쪽 장애야.”
• “그건 DB 팀이 문제였지.”

이런 프레임은 은근히 책임 전가와 사일로화된 사고를 부추긴다. 회전탑은 이 관점을 완전히 뒤집는다.

카드는 팀이나 개인이 아니라, 리스크 수준과 시스템적 영향도로 정렬한다.

• 레드 섹션 – 고위험 / 고영향
  • 고객 서비스 장기 다운
  • 데이터 손실 또는 손상
  • 규제 / 보안 관련 사고
• 앰버 섹션 – 중간 위험
  • 부분적 성능 저하
  • 핵심 업무 플로우에 영향이 있는 성능 문제
• 그린 섹션 – 저위험 / 저영향
  • 사소한 글리치(glitch)
  • 짧게 지나간 장애
  • 초기에 잡힌 근접 사고(near miss)

각 색 섹션 안에서는 다시 다음과 같은 시스템적 테마로 묶을 수 있다.

• 의존성(dependency) 장애
• 릴리스 / 배포 이슈
• 설정 오류(misconfiguration)
• 용량 / 스케일링 한계
• 커뮤니케이션·조율 실패

이 구조는 두 가지 효과를 낸다.

1. 정렬 기준에서 ‘개인 책임’을 제거한다. 카드는 누가 온콜이었는지 신경 쓰지 않는다. 어떤 리스크가 드러났는지만 본다.
2. 시스템 리스크 영역이 도드라져 보인다. 레드 카드의 절반이 ‘의존성 장애’ 태그를 달고 있다면, 아키텍처 자체를 손봐야 한다는 강력한 신호다.

각 카드는 미니 포스트모템이다

카드가 유용하려면, 짧지만 표준화된 구조를 가져야 한다. 극도로 압축된 포스트모템이라고 보면 된다.

일반적인 카드는 다음 정보를 담는다.

• 제목: 짧고 구체적인 라벨 (예: “로그인 API 인증 토큰 캐시 장애”)
• 일시 & 지속 시간: 언제 발생했고 얼마나 길었는지
• 컨텍스트: 당시 어떤 상황이었는지 (배포 중, 피크 트래픽, 마이그레이션, 등)
• 트리거: 장애를 촉발한 사건 (설정 변경, 의존 서비스 장애, 버그 등)
• 영향(Impact):
  • 어떤 사용자나 시스템이 영향을 받았는가?
  • 성능 저하나 불능의 정도는 어느 수준이었는가?
• 탐지 & 대응:
  • 어떻게 탐지되었는가? (알람, 고객 문의 등)
  • 팀은 얼마나 빨리 대응했는가?
• 복구 단계: 서비스를 복원하는 데 핵심이 된 조치들
• 후속 조치(Follow‑up):
  • 앞으로 무엇을 바꾸기로 했는가?
  • 상태: Planned / In progress / Done / Abandoned (and why)
• 리스크 레벨 & 태그: 색/리스크 카테고리 + 1–3개 태그 (예: deployment, dependency, communication)

카드 크기의 제약은 단점이 아니라 장점이다. 강제로 내용을 선명하게 만든다.

• 아무도 다시 읽지 않는 12페이지짜리 문서는 없다.
• “앞으로 더 조심하자” 같은 모호한 결론도 없다.
• 핵심 스토리만, 요약해서 남긴다.

QR 코드나 링크로 전체 포스트모템 문서로 연결할 수 있지만, 카드만으로도 사건의 스냅샷이 되도록 만드는 게 중요하다.

팀의 아티팩트이지, 컴플라이언스 체크박스가 아니다

회전탑이 “또 하나의 프로세스 요구사항”으로만 느껴지면 금방 망한다. 이게 제대로 작동하려면, 이것이 팀 스스로를 위한 학습 도구여야 한다. 관리·감사용 추적 장치처럼 느껴지면 안 된다.

진짜 협업 도구로 만드는 방법은 다음과 같다.

• 카드를 다 같이 만든다. 장애 리뷰 중이거나 직후에, 팀이 함께 카드를 채운다. 장애에 가장 가까이 있었던 사람들이 직접 스토리를 정리하도록 한다.
• 팀 가까이에 둔다. 공유 책상, 화이트보드 옆, 스탠드업 미팅 공간 근처 등. 누구든 쉽게 돌려보며 훑어볼 수 있어야 한다.
• 팀의 정기 행사에 녹여 넣는다.
  • 주간 장애 리뷰: 특히 레드 섹션에서 카드 1–2개를 골라 짧게 다시 돌아본다.
  • 스프린트 계획: 회전탑을 돌려보며 후속 조치 중 아직 열려 있는 것들을 확인한다.
  • 온보딩: 신규 입사자가 15–20분 동안 핵심 카드를 둘러보며 “이 팀에서 실제로 장애가 어떻게 일어나는지” 배우게 한다.
• 호기심을 장려한다. 누가 지나가다가 회전탑 앞에 멈춰 서서 “이건 무슨 일 있었어요?”라고 묻는다면, 그게 바로 성공이다. 이 아티팩트가 설계된 목적이 바로 그런 행동을 끌어내는 것이다.

이게 잘 작동하고 있다는 신호는 다음과 같다.

• 팀원들이 대화 중에 예전 장애 카드를 자연스럽게 언급한다.
• 누군가 “이거 예전에 그 사건이랑 비슷한데?”라고 말하며 카드를 꺼내 비교한다.
• 회전탑이 계획·설계 논의에 자연스럽게 참조되는 일부가 된다.

반복되는 패턴과 진짜 시스템 문제를 드러내기

수개월치 장애를 한 번에 눈앞에 두면, 반복 패턴을 무시하기가 어려워진다.

예를 들어 이런 질문을 해볼 수 있다.

• 레드 섹션에서 계속 반복되는 건 무엇인가?
  • 같은 외부 의존 서비스에 반복적으로 물리는가?
  • 특정 서비스 주변에서 배포 리스크가 유독 높은가?
• 어떤 태그가 가장 많이 보이는가?
  • communication 태그가 많다면, 책임 구분이 불명확하거나 인시던트 코디네이션이 약하다는 신호일 수 있다.
  • capacity나 scaling 태그가 많다면, 수요 예측이나 부하 테스트가 부족하다는 의미일 수 있다.
• 근접 사고(near miss)는 어디에 모여 있는가?
  • 학습 가치가 큰 그린 카드들을 보면, 어떤 실패 모드는 초기에 잘 잡히고 있고, 어떤 건 아직도 불시에 터질 준비를 하고 있는지 드러난다.

실물 카드라는 점을 활용해, 패턴을 더욱 눈에 띄게 만들 수 있다.

• 한 달 동안 dependency 태그를 단 카드들을 한 곳에 모아둔다.
• 같은 루트 코즈 패턴을 공유하는 사건에는 색깔 스티커를 붙인다.
• 회전탑에 “이달의 패턴” 섹션을 만들어, 지금 적극적으로 개선 중인 반복 테마를 따로 모아둔다.

이렇게 하면 대화의 초점이 “누가 실수했나”에서 “왜 이런 종류의 장애가 이렇게 쉽게 발생하는 시스템을 운영하고 있는가?”로 옮겨간다.

회전탑을 리스크 감소 엔진으로 만들기

멋진 카드 벽은 흥미롭다. 하지만 리스크 감소 작업의 우선순위 목록은 진짜 가치가 있다.

회전탑을 활용해 다음과 같은 결정을 내릴 수 있다.

• 어떤 후속 조치가 정말 중요한가?
  • 여러 사건에 반복해서 등장하는 액션을 찾는다.
  • 레드 카드 세 개가 모두 “X에 레이트 리미팅 추가”를 언급한다면, 그건 강력한 우선순위 후보다.
• 다음 분기에 엔지니어링 시간을 어디에 쓸 것인가?
  • 심각한 장애 절반이 특정 서브시스템과 관련 있다면, 그 부분에 집중 투자해야 한다.
• 무엇은 뒤로 미뤄도 안전한가?
  • 영향 범위가 좁고 저위험인 장애는, 더 시급한 시스템적 이슈에 비해 우선순위를 낮출 수 있다.

실무적으로는 이렇게 할 수 있다.

• 후속 조치가 아직 열려 있는 카드에 눈에 띄는 표시를 한다.
• 분기/스프린트 계획 회의에서, 고위험 카드 몇 개를 꺼내놓고 이렇게 직접 묻는다.
  “이 유형의 장애가 훨씬 덜 발생하거나, 발생하더라도 훨씬 덜 아프게 만들려면 무엇을 해야 할까?”
• 카드의 후속 조치가 모두 완료되었을 때 표시해두고, 그 후 동일한 패턴이 다시 나타났는지 추적한다.

시간이 지나면 회전탑은 이렇게 변해가야 한다.

• 최고 위험 섹션에 새로 추가되는 카드가 줄어든다.
• 초기에 포착된 근접 사고를 담은 그린 카드가 늘어난다.
• 오래된 레드 카드들은 “우리가 이미 길들인 실패 모드”의 예시가 된다.

계획된 장애와 비계획 장애, 하나의 시스템으로 다루기

대부분의 팀은 계획된 점검(maintenance)과 비계획 장애를 완전히 별개의 세계로 다룬다. 사용하는 도구도, 이야기하는 방식도 다르다.

회전탑은 의도적으로 이 둘을 섞는다.

• 비계획 장애: 갑작스런 장애, 회귀(regression), 인프라 이벤트
• 계획된 장애(작업): 마이그레이션, 점검 윈도우, 영향이 예상되는 대규모 배포

왜 통합할까?

• 다양한 유형의 실패에 대해, 우리가 얼마나 잘 예측·완화하고 있는지를 비교할 수 있다.
• 계획된 작업에서도 비계획 장애와 똑같은 약점이 드러난다. 커뮤니케이션 부족, 의존성 리스크, 미비한 런북 등.
• 계획된 작업이 매끄럽게 끝났다면, 그 카드는 명확한 커뮤니케이션, 탄탄한 롤백 플랜, 충분한 테스트가 갖춰진 **좋은 사례(positive example)**가 된다.

계획된 이벤트 카드는 다음을 포함할 수 있다.

• 예상 영향 vs 실제 영향
• 사전에 세웠던 완화 계획
• 실제로 무슨 일이 있었는지 (예상 밖의 일 포함)
• 다음에 같은 유형의 작업을 할 때, 무엇을 바꾸고 싶은지

시간이 지나면 이런 질문을 던질 수 있다.

• 우리는 계획된 리스크는 비계획 리스크보다 훨씬 잘 다루고 있는가?
• 성공적인 계획 작업에서 사용한 좋은 관행들을, 예고 없이 터지는 장애 상황에도 적용할 수 있는가?

나만의 회전탑 시작하기

이걸 도입하는 데 거창한 이니셔티브는 필요 없다. 간단한 셋업으로 시작할 수 있다.

1. 회전식 카드 탑을 구하거나 재활용한다. 인덱스 카드나 작은 종이를 꽂을 수 있고, 손으로 돌릴 수 있으면 된다.
2. 1페이지짜리 장애 카드 템플릿을 정의한다. 잔뜩 인쇄해 회전탑 옆에 둔다.
3. 리스크 색상 체계와 4–6개의 기본 태그를 정한다. 초반에는 단순하게 시작하라.
4. 앞으로 발생하는 몇 건의 장애(계획·비계획 모두)에 대해, 함께 카드를 작성한다. 리스크에 따라 회전탑에 꽂는다.
5. 주간 팀 의식 중 하나에 회전탑을 사용한다. 예를 들어, 팀 위클리에서 카드 한 장을 골라 짧게 리뷰한다.

필요하다면 점진적으로 개선한다.

• 전체 포스트모템으로 연결되는 QR 코드를 붙인다.
• 실제로 보이는 패턴에 따라 태그 체계를 확장한다.
• 누구나 빠르게 이해할 수 있도록, 회전탑 옆에 작은 범례(legend)나 키를 붙인다.

결론: 실패를 눈에 띄게, 유용하게, 그리고 인간적으로 만들기

아날로그 장애 스토리 카드 회전탑은 의도적으로 단순하다. 새로운 툴이나 플랫폼, 위원회가 필요 없다.

대신 이런 마인드셋 전환이 필요하다.

• **“누가 이걸 일으켰지?”**에서 **“이 사건이 드러낸 리스크는 무엇이지?”**로
• 체크리스트형 포스트모템에서 짧지만 재사용 가능한 스토리로
• 숨겨진 문서들에서 보이는 공유 기억으로

장애를 실물로 만들고, 리스크와 시스템 영향도 기준으로 조직함으로써 우리는 이렇게 상기하게 된다.

• 복잡한 시스템에서 장애는 정상적인 현상이다.
• 탓하기만 해서는 아키텍처나 프로세스가 개선되지 않는다.
• 진짜 리스크를 줄이는 것은 학습과 후속 실행이다.

책상 위 작은 회전 탑은 사소해 보일 수 있다. 하지만 팀이 가장 힘들게 얻은 교훈들을 눈앞에 계속 두고, 그것을 더 나은 의사결정으로 연결시켜줄 수 있다면, 이것은 여러분 엔지니어링 문화에서 가장 조용하지만 가장 강력한 도구 중 하나가 될 수 있다.