Rain Lag

아날로그 인시던트 스토리 카이트워크 아틀라스: 멈추기 전에 종이 비행 경로를 손으로 잇기

아날로그 회로 사고, 휴먼 팩터, 손으로 그린 ‘비행 경로’로, 위기 상황에서 무너지는 취약한 플로우차트형 인시던트 에스컬레이션을 실제로 사람들이 사용하는 살아 있는 아틀라스로 바꾸는 방법.

아날로그 인시던트 스토리 카이트워크 아틀라스

멈추기 전에 에스컬레이션을 위한 종이 비행 경로를 손으로 잇기

장애, 안전 이슈, 보안 위협 같은 인시던트가 터지면 대부분의 조직은 슬라이드 덱에서는 그럴듯해 보이지만 실제 상황에서는 쉽게 무너지는 에스컬레이션 프로세스에 의존합니다. 사람들은 멈칫하고, 스스로를 의심하고, 아예 단계를 건너뛰기도 합니다. 문제는 보통 문서가 부족해서가 아닙니다. 우리의 에스컬레이션 시스템이 현실의 인간 두뇌를 위한 도구가 아니라 취약한 자동화 시스템처럼 설계되어 있기 때문입니다.

이 글에서는 다른 접근법을 제안합니다. 인시던트 에스컬레이션을 아날로그 회로 설계 문제로 보고, 인시던트가 조직 안에서 실제로 어떻게 움직이는지 보여주는 “카이트워크 아틀라스(Kitework Atlas)”—손으로 꿰맨 회로도 스타일의 지도—를 만드는 것입니다. 인시던트가 멈추기 전에 **종이 비행 경로(paper flight paths)**를 그려두면, 상황이 꼬였을 때도 명확성, 자신감, 속도를 되찾을 수 있습니다.


넷리스트에서 스토리 맵으로: 구조가 중요한 이유

아날로그 회로 설계에서는 중요한 구분이 있습니다.

  • 넷리스트(netlist): 부품과 연결을 텍스트로 나열한 목록입니다. 기계가 좋아합니다.
  • 회로도(schematic): 회로가 실제로 어떻게 동작하는지 보여주는 시각적·구조적 다이어그램입니다. 사람이 좋아합니다.

많은 자동 회로 사이징 도구는 회로도를 거의 무시하고 넷리스트만 가지고 동작합니다. 성능을 최적화할 수는 있지만, 시각적·구조적 표현을 제거함으로써 설계자의 인지적 이해를 약화시킵니다. “여기를 이렇게 바꾸면, 저기가 이렇게 달라진다”는 직관적인 감각을 잃어버리는 것이죠.

당신의 인시던트 에스컬레이션 프로세스도 비슷한 문제를 갖고 있을 가능성이 큽니다.

아마 이런 것들은 있을 겁니다.

  • 위키에 있는 플레이북(인시던트 버전의 넷리스트)
  • 한 번 만들어두고 아무도 업데이트하지 않는 플로우차트
  • 사람들이 순차적으로 따를 거라고 가정하는 런북 스크립트

하지만 대부분 조직에 없는 것은, 인시던트가 실제로 팀·시스템·의사결정 포인트를 어떻게 가로지르는지 보여주는 **공유되는 회로도 스타일의 “스토리 맵”**입니다.

이게 없으면 사람들은 이런 것들을 제대로 판단하기 어려워합니다.

  • 누가 언제 무엇을 해야 하는지
  • 실제로 어디에서 의사결정이 이뤄지는지
  • 정보가 어떻게—혹은 제대로 전달되지 않는지

이걸 고치려면 단순히 문서를 더 잘 쓰는 것으로는 부족합니다. 인시던트와 그 에스컬레이션 경로 사이의 시각적·구조적 연결을 복원해야 합니다.


휴먼 팩터: 이상적인 사용자가 아니라 진짜 뇌를 위한 설계

휴먼 팩터와 인간공학(Human Factors & Ergonomics)은 현실의 인간의 몸과 마음에 맞게 도구·프로세스·환경을 설계하는 분야입니다. 피곤하지도, 헷갈리지도 않고, 항상 합리적으로 행동하는 ‘이상적인 사용자’를 위한 설계가 아닙니다.

이 렌즈를 인시던트 에스컬레이션에 적용해 보면 몇 가지 사실이 드러납니다.

  1. 사람은 불완전하게 이상 신호를 감지합니다. 지표가 빨갛게 변하기 훨씬 전부터 “뭔가 이상하다”는 기분을 느낍니다.
  2. 사람은 망설입니다. 과잉 대응, 선배를 괜히 귀찮게 하는 것, 틀릴지도 모른다는 걱정을 합니다.
  3. 사람은 단순화합니다. 스트레스가 커질수록, 가장 눈에 잘 띄고 기억하기 쉬운 행동만 하려 합니다.
  4. 사람은 단서를 필요로 합니다. 시각 자료, 체크리스트, 명확한 권한 구조는 인지적 부담을 줄여 줍니다.

대부분의 에스컬레이션 시스템은 이런 현실을 무시합니다. 대신 이렇게 가정합니다.

  • 모두가 런북을 꼼꼼히 읽고 있다
  • 모두가 플로우차트를 외우고 있다
  • 모두가 누가 어떤 결정을 맡고 있는지 합의하고 있다

휴먼 팩터 관점에서 설계된 에스컬레이션은 정반대를 묻습니다.

  • 이 조직에서 사람들은 실제로 어떻게 문제를 눈치채고, 해석하고, 행동하는가?
  • 어디에서 멈칫하고, 스스로를 의심하고, 시간을 끄는가?
  • 어떤 시각적·구조적·사회적 단서가 있으면 더 빠르고 자신 있게 움직일 수 있을까?

여기서 카이트워크 아틀라스가 등장합니다.


인시던트를 위한 “카이트워크 아틀라스”란 무엇인가?

카이트워크 아틀라스는 당신 조직의 인시던트 에스컬레이션 세계를 손으로 만든 회로도 스타일의 지도라고 생각하면 됩니다. 서로 다른 유형의 문제가 어떻게 떠오르고, 갈라지고, 어디에 가닿아야 하는지를 보여주는 종이 비행 경로의 집합입니다.

이 아틀라스는 다음과 같습니다.

  • 디지털 자동화가 아니라 아날로그 – 어떤 툴을 설정하기 전에 화이트보드, 포스트잇, 마커로 만듭니다.
  • 절차서가 아니라 구조 – 실제로 정보, 권한, 책임이 어떻게 연결되는지에 초점을 둡니다.
  • 단순 상태도가 아니라 스토리 중심 – “이런 일이 생기면, 여기에 도달하고, 이 사람들이 이런 결정을 내린다”처럼 이야기로 표현합니다.

전통적인 플로우차트가 이렇게 말할 수 있습니다.

IF Severity = SEV1 THEN Notify On‑Call Manager

카이트워크 비행 경로는 이렇게 표현할 수 있습니다.

리전 A에서 고객이 체감하는 장애가 발생하면 “Red Tail(레드 테일)” 비행이 시작된다. 온콜 SRE가 인시던트 커맨더를 페이징하고, 커맨더는 곧바로 범위, 커뮤니케이션, 리소스 할당에 대한 권한을 가져간다.

차이는 이야기성, 가시성, 소유권입니다. 기계가 읽는 상태 다이어그램이 아니라, 사람이 읽는 스토리 맵에 가깝습니다.


에스컬레이션이 멈추는 이유 (그리고 명확한 비행 경로가 돕는 방법)

인시던트가 멈추는 이유는 대부분, 기술 역량이 부족해서가 아니라 모호함과 망설임 때문입니다.

  • “이걸 정말 메이저 인시던트라고 불러도 되나?”
  • “부사장을 진짜 깨워야 하나?”
  • “지금 이 시스템의 오너가 누구지?”
  • “이건 보안 문제인가, 운영 문제인가, 제품 문제인가?”

두 가지 설계 개입만 잘 해도 이런 정체를 크게 줄일 수 있습니다.

1. 명확한 의사결정 권한 정의

각 에스컬레이션 경로마다 다음이 분명해야 합니다.

  • 누가 **심각도(severity)**를 결정하는가
  • 누가 대응 범위(롤백, 페일오버, 피처 플래그 등)를 결정하는가
  • 누가 대외 커뮤니케이션을 책임지는가
  • 누가 라인 중단(stop-the-line) 권한을 갖고 있는가

카이트워크 아틀라스 안에서 이런 것들은 애매한 박스가 아니라, 구체적인 역할(role) 이름과 명시적인 권한으로 표현됩니다. 스트레스 상황에서 권한 구조가 명확하면, 허락을 구느라 생기는 지연이 사라집니다.

2. 에스컬레이션 경로를 손에 잡히고 기억에 남게 만들기

전화번호 목록은 경로가 아니라 단순한 디렉터리입니다. 진짜 비행 경로는 다음과 같습니다.

  • 시각적으로 구별 가능 – 인시던트 유형별로 색, 선, 마커를 다르게 사용합니다.
  • 물리적으로 존재 – 워룸이나 팀 공간 벽에 인쇄해 붙여 둡니다.
  • 반복 연습됨 – 온보딩 때 한 번 읽고 끝나는 게 아니라, 워크숍에서 실제로 따라가 봅니다.

사람들 머릿속에 에스컬레이션 비행 경로가 그림으로 떠오를 수 있을 때, 훨씬 더 빠르게 그 경로를 따릅니다.


아날로그 비행 경로 만들기: 실전 워크숍 패턴

더 나은 에스컬레이션을 설계하는 데 정교한 소프트웨어는 필요 없습니다. 필요한 것은 의도적인 크로스 펑셔널 대화와 조금의 종이뿐입니다.

다음은 카이트워크 아틀라스를 만들기 위한 가벼운 워크숍 포맷입니다.

1단계: 크로스 펑셔널 그룹 구성

다음 사람들을 포함하세요.

  • 엔지니어 (백엔드, 프론트엔드, SRE/인프라)
  • 고객 지원 / 커스터머 석세스
  • 보안 팀(해당될 경우)
  • 프로덕트 / 오퍼레이션
  • 인시던트 대응을 이해하는 퍼실리테이터

구성이 중요합니다. 숨겨진 의존성과 실패 모드는 보통 조직 간 경계에 숨어 있습니다.

2단계: 인시던트 “스토리” 2–3개 선택

각 스토리마다 구체적인 상황을 고릅니다. 예를 들어:

  • 트래픽의 20%에 영향을 주는 특정 리전 장애
  • 크리덴셜 유출이 의심되는 상황
  • 하드웨어 제품에서 안전과 직결된 버그 발생

그룹에 이렇게 물어보세요. “처음 이상을 감지한 순간부터 해결될 때까지, 실제로 무슨 일이 일어나는지 차근차근 이야기해 주세요.”

3단계: 현재의 비행 경로 그리기 (미화 금지)

화이트보드나 큰 종이에 다음을 도식화합니다.

  • 신호(Signals): 어떻게 처음 문제가 감지되는가? (모니터링 알람, 고객 문의, 직감 등)
  • 첫 번째 행위자: 누가 처음 보며, 그때 어떤 선택지가 있다고 생각하는가?
  • 분기점: 사람들이 어디에서 망설이고, 슬랙에 물어보고, 임기응변을 하는가?
  • 에스컬레이션 홉(hop): 그다음에는 누가, 어떤 방식으로 끌려 들어오는가?

깔끔하게 정리하려는 욕구를 참으세요. 지금은 현재 프로세스의 지저분한 넷리스트를 있는 그대로 그리는 단계입니다.

4단계: 정체 지점과 실패 모드 찾기

다음을 찾아 표시합니다.

  • 허락을 기다리거나, 과도한 에스컬레이션을 두려워하는 지점
  • 어떤 시스템·결정을 누가 책임지는지 헷갈리는 지점
  • 도구 마찰 (명확한 채널 부재, 오래된 연락처 등)
  • 중복되거나 서로 충돌하는 알림 경로

이 지점들을 빨간색으로 표시하세요. 인시던트가 여기서 고도(altitude)를 잃는 구간입니다.

5단계: 회로도 스타일 스토리 맵으로 재설계

이제 아날로그 회로도를 새로 그리듯 다시 그립니다.

  • 컴포넌트 묶기: 예를 들어 감지(Detection), 트리아지(Triage), 지휘(Command), 커뮤니케이션(Communications) 같은 모듈로 묶습니다.
  • 각 모듈마다 권한을 명확히: 누가 무엇을 결정하는지 적습니다.
  • 경로 단순화: 스트레스 상황에서는 분기를 줄이고, 기본값을 늘립니다. (예: “애매하면 X에게 에스컬레이션”)
  • 인시던트 클래스별로 고유한 시각적 아이덴티티(색, 도형, 이름)를 부여합니다.

단계를 고치는 것에 그치지 않고, 사람들이 머릿속에 갖고 있는 인시던트 비행 모델을 다시 배선하는 작업입니다.

6단계: 비행 경로에 이름 붙이기

각 경로에 짧고 기억하기 쉬운 이름을 붙입니다. 예를 들면:

  • Red Tail(레드 테일) – 고객 체감 장애
  • Grey Wing(그레이 윙) – 의심스러운 보안 이벤트
  • Blue Vector(블루 벡터) – 데이터 무결성 위험

이 이름들은 인지적 손잡이가 됩니다. “이건 레드 테일 냄새가 나는데—그 경로를 시작하자.”

7단계: 공유·인쇄·리허설

재설계한 맵을 다음과 같이 활용합니다.

  • 인시던트 룸과 팀 공간에 붙이는 인쇄 포스터
  • 채팅 툴과 런북에 고정해 두는 1페이지 PDF
  • 팀이 시나리오를 읽고 비행 경로를 따라가 보는 짧은 테이블탑(Tabletop) 연습

반복 연습을 통해 이 회로도 스타일의 맵이 팀의 공유된 정신 모델로 자리 잡습니다.


왜 “아날로그 먼저, 디지털은 나중”인가

바로 인시던트 관리 플랫폼이나 티켓 워크플로 설정으로 뛰어들고 싶을 수 있습니다. 하지만 아날로그 구조를 이해하고 재설계하기 전에 그렇게 해 버리면, 오늘의 혼란을 내일의 도구 속에 그대로 굳혀 버리게 됩니다.

아날로그를 먼저 하면 다음이 생깁니다.

  • 공유된 이해: 모두가 같은 지도를 보고 비판하고 개선할 수 있습니다.
  • 저비용 반복: 선 하나 지우는 게, 자동화를 리팩터링하는 것보다 훨씬 쌉니다.
  • 인지적 정렬: 이후 디지털 워크플로가 사람들 머릿속의 스토리와 일치합니다.

카이트워크 아틀라스가 종이 위에서 충분히 자연스럽게 느껴지면, 그다음에야 다음을 수행합니다.

  • 비행 경로를 그대로 반영하는 알림 규칙 구현
  • 도구 안의 역할 정의를 권한 회로도와 맞추기
  • 인시던트가 시작되는 모든 곳에 시각적 맵 링크 심기

이제 도구는 아틀라스의 대체제가 아니라, **확장(extension)**이 됩니다.


결론: 필요하기 전에 먼저 경로를 날려 보라

인시던트는 시스템의 취약성뿐 아니라 조직 설계의 취약성도 드러냅니다. 에스컬레이션이 멈춰 버릴 때는, 문서 속에는 프로세스의 “넷리스트”가 있지만, 회로도는 누구 머릿속에도 없는 경우가 많습니다.

아날로그 회로 설계와 휴먼 팩터에서 아이디어를 빌려오면 다음을 할 수 있습니다.

  • 인시던트와 에스컬레이션 경로 사이의 시각적·구조적 연결을 되살리고
  • 사람들이 실제로 문제를 감지·해석·행동하는 방식에 워크플로를 맞추고
  • 명시적인 권한과 손에 잡히는·기억에 남는 경로로 망설임을 줄이며
  • 크로스 펑셔널 워크숍으로 숨겨진 의존성과 실패 모드를 드러낼 수 있습니다.

카이트워크 아틀라스는 그저 보기 좋은 플로우차트가 아닙니다. 실제 압박 속에서 일하는 진짜 사람들을 위해 에스컬레이션 시스템을 설계하겠다는 약속이며, 언젠가 인시던트가 밟게 될 종이 비행 경로를 지금 미리 손으로 꿰매 두는 일입니다.

그 꿰매는 작업을 지금 하십시오. 그래야 다음 인시던트가 낮은 고도에서 멈춰 버리기 전에, 이미 날아갈 경로가 준비되어 있습니다.

아날로그 인시던트 스토리 카이트워크 아틀라스: 멈추기 전에 종이 비행 경로를 손으로 잇기 | Rain Lag