소개

프로덕션에서 실제 장애가 발생했을 때, 팀이 실패하는 이유는 도구가 부족해서가 아닙니다. 인지 부담이 급격히 치솟고, 커뮤니케이션이 흐트러지며, 사람들이 **서로 다른 머릿속 그림(멘탈 모델)**을 갖게 되는 순간부터 실패가 시작됩니다.

아날로그 인시던트 라이트하우스 계단(Analog Incident Lighthouse Staircase) 은 이 문제에 대한 의도적인 로우테크 해법입니다. 즉, 장애 진행 상황을 종이 위에 단계별로 시각화한 것으로, 대시보드, 알람, Slack 채널이 소음으로 넘쳐날 때에도, 늘 보이고 안정적으로 남아 있으며 비즈니스 맥락과 연결된 기준점을 제공합니다.

이 글에서는 다음 내용을 다룹니다.

• 라이트하우스 계단이 무엇이며, 왜 중요한지
• PagerDuty 및 CrateDB 중심의 인시던트 워크플로우에 어떻게 녹아드는지
• 어떻게 데이터 일관성을 유지하고 수집/적재 오류를 줄이는지
• 간단한 재료로 직접 라이트하우스 계단을 만드는 방법
• 사람(휴먼 팩터)과 실시간 의존성을 고려해 효과적으로 사용하는 방법

아날로그 인시던트 라이트하우스 계단이란?

라이트하우스 계단은 인시던트가 진행되는 동안 실시간으로 종이에 쌓아 올리는 단계별 물리적 타임라인입니다.

다음과 같이 생각할 수 있습니다.

• 장애 라이프사이클을, 탐지부터 해결·사후 회고까지 수직 방향의 계단 형태로 표현한 것
• 방 안의 모두가 한눈에 볼 수 있는 단 하나의 공유 기준점(single shared reference point)
• 이후 CrateDB 같은 시스템에 데이터를 적재할 때, 그 구조를 그대로 반영할 수 있는 데이터 수집 골조(data collection scaffold)

계단의 각 "단(step)"은 인시던트의 명확한 단계 또는 사건 하나를 의미합니다.

1. 탐지(Detection)
2. 트리아지 시작
3. 영향도 평가
4. 가설 수립
5. 완화/조치 적용
6. 검증
7. 커뮤니케이션 업데이트
8. 해결 선언
9. 후속 / 포스트모템 작업

이 계단은 미리 준비한 카드나 포스트잇을 이용해, 벽이나 큰 보드 위에 실시간으로 쌓아 올립니다. 각 단계(카드)에는 다음 항목을 적습니다.

• 시간
• 담당자(Owner)
• 관련 시스템 / 의존 서비스
• 수행한 결정 또는 조치
• 비즈니스 영향도

인시던트가 끝날 때쯤이면, 정돈된 순서의, 사람이 읽기 쉬운 로그가 완성되어 있습니다. 이 기록은 그대로 CrateDB의 구조화된 레코드, PagerDuty 인시던트 노트, 그리고 사후 회고 템플릿으로 손쉽게 옮길 수 있습니다.

왜 아날로그인가? 그리고 왜 라이브 장애 중에 해야 할까?

심각한 장애가 터지면, 가장 먼저 무너지는 것은 두 가지입니다.

1. 공유된 컨텍스트(Shared context): 각자 다른 데이터 조각만 보고, 서로 다른 스토리를 상상하며, 대화는 서로 엇갈립니다.
2. 신뢰할 수 있는 데이터 캡처: 메모가 Slack, Zoom, 터미널 로그, 사람 머릿속에 흩어집니다. 나중에 CrateDB나 인시던트 관리 시스템과 동기화하려 하면, 타임스탬프가 빠졌거나 용어가 제각각이고, 중간 단계가 통째로 사라져 있곤 합니다.

종이 기반의 아날로그 산출물은 이 중 여러 문제를 한 번에 줄여 줍니다.

• 인지 부담이 낮다: 위기 상황에서 새 UI를 배울 필요가 없습니다. 카드에 몇 줄 쓰고 벽에 붙이는 일은 누구나 바로 할 수 있습니다.
• 가시성이 높다: 방에 있는 모든 사람(또는 벽을 비추는 카메라를 통해 화상 회의에 있는 사람들)에게 같은 현실이 보입니다.
• 구조가 안정적이다: 계단이라는 레이아웃이 시간 순서를 강제하고, 항상 같은 형식을 유지하게 만듭니다.
• 데이터 규율(Data discipline): 어떤 단계가 카드로 기록되지 않았다면, 다른 어디에도 남지 않았을 가능성이 크므로, 빈 구간이 눈에 바로 띕니다.

무엇보다도, 라이트하우스 계단은 이후 작업에서 사용하는 권위 있는 아날로그 기준(ground truth) 이 됩니다.

• 실제 타임라인을 재구성할 때
• CrateDB에 레코드를 보강하고 정제할 때
• PagerDuty 이벤트를 대조·검증할 때
• 인시던트 이후 리뷰/포스트모템 문서를 작성할 때

라이트하우스 계단과 PagerDuty, CrateDB의 연결

요즘 인시던트 대응 워크플로우에서는 보통 이렇게 일합니다.

• PagerDuty에서 인시던트를 트리거하고 관리합니다.
• 인시던트 데이터를 스트리밍 또는 배치로 CrateDB에 적재해 분석, 대시보드, 히스토리 조회에 활용합니다.

라이트하우스 계단은 이 도구들을 대체하는 것이 아니라, 옆에서 함께 동작하는 보조 축입니다.

인시던트 진행 중

• PagerDuty는 알람, 에스컬레이션, 역할(Incident Commander, Scribe 등)을 관리합니다.
• 라이트하우스 계단은 팀이 무엇을, 왜 하는지를 비즈니스 관점에서 한눈에 볼 수 있는 사람 친화적 타임라인을 제공합니다.
• Scribe(또는 타임라인 전담자)가 인시던트 동안 계단을 실시간으로 업데이트합니다.

인시던트 이후

라이트하우스 계단은 사실상 원본 대본(ground truth transcript) 으로 활용됩니다.

• PagerDuty 이벤트 로그와 타임스탬프를 대조합니다.
• CrateDB 적재 전에 용어를 정규화합니다. (서비스 이름, 런북 ID, 비즈니스 영향도 표현 등)
• 자동화로는 잡히지 않은 맥락, 예를 들어 롤백 시도에 담긴 의도와 배경 같은 부분을 빈 구간에 채워 넣습니다.

이 워크플로우는 다음을 크게 줄여 줍니다.

• 적재/수집 오류 (필드 매핑 불일치, 누락된 단계, 순서 꼬임 등)
• 분류 불일치 (예: Severity와 실제 비즈니스 영향도 사이의 괴리)

이후 CrateDB는 다음을 수행하는 분석 및 조회의 허브가 됩니다.

• 여러 인시던트에 걸친 패턴 분석
• MTTR, 영향 범위(blast radius) 등 지표 리포트 생성
• 의존성 및 반복되는 장애 유형 쿼리

라이트하우스 계단은 이 CrateDB 레코드들이 일관되고, 빠짐없고, 서로 비교 가능하도록 만들어 주는 장치입니다.

전제 조건: 무엇이 중요한지, 시스템이 어떻게 동작하는지부터 알기

라이트하우스 계단은 여러분 조직의 비즈니스와 시스템 현실을 반영할 때만 진짜 효용이 있습니다.

계단을 만들기 전에, 다음을 먼저 정리해야 합니다.

1. 비즈니스 우선순위 명확화

   • 무엇이 진짜로 중요합니까? (결제 처리, 주문 접수, 환자 데이터, 물류 출고 등)
   • Severity는 무엇을 기준으로 정의합니까? (매출, 차단된 고객 수, 안전, 규제 리스크 등)

2. 핵심 시스템과 의존성 매핑

   • 어떤 서비스가 고객에게 직접 노출되는지?
   • 그 서비스가 의존하는 내부 시스템(데이터베이스, 메시지 큐, 서드파티 API 등)은 무엇인지?
   • 모니터링과 알람은 어디에서 발생하는지?

3. 복구 목표 정의

   • 주요 시스템에 대한 RTO, RPO는 무엇인지.
   • Severity 별 응답/해결 SLA는 어떻게 되는지.

이 입력값들은 곧바로 다음을 결정합니다.

• 계단 카드에 어떤 필드를 인쇄할지
• 계단에 어떤 단계를 포함할지
• 어떤 행동은 반드시 기록해야 할 필수 항목인지

이 정렬이 없다면, 데이터는 모으더라도 정작 필요한 데이터는 빠진 상태가 됩니다.

라이트하우스 계단 만들기 (단계별 가이드)

별다른 고급 장비가 필요하지 않습니다. 필요한 것은 명확성과 일관성입니다.

준비물

• 모두가 볼 수 있는 큰 벽, 화이트보드 또는 폼보드
• 계단 형태를 그릴 수 있는 마스킹 테이프(페인터스 테이프) 또는 두꺼운 마커
• 미리 인쇄한 카드 또는 다양한 색상의 포스트잇
• 두꺼운 마커(어두운 색, 카메라로도 잘 보이는 대비가 좋은 색)
• 선택 사항: 벽을 비추기 위한 웹캠 또는 휴대폰 거치대 (원격 참가자를 위해)

1단계: 계단 레이아웃 설계

보드나 벽 위에, 왼쪽에서 오른쪽 위로 올라가는 큰 계단을 그립니다.

• 각 계단의 한 칸(step) = 하나의 주요 단계 또는 의미 있는 사건
• 위로 올라가는 방향 = 시간이 흐르고, 영향도가 커지는 방향

계단 아래쪽 또는 옆에 각 단계를 라벨링합니다. 처음에는 다음과 같은 템플릿으로 시작해 볼 수 있습니다.

1. 탐지 & 선언(Detection & Declaration)
2. 트리아지 & 담당 지정(Triage & Assignment)
3. 영향도 & 범위 평가(Impact & Scope Assessment)
4. 가설 수립 & 계획(Hypothesis & Plan)
5. 완화 / 변경 적용(Mitigation / Change Applied)
6. 검증 & 모니터링(Verification & Monitoring)
7. 커뮤니케이션 & 이해관계자(Communication & Stakeholders)
8. 해결 선언(Resolution Declared)
9. 후속 작업 & 포스트모템(Follow‑Up & Postmortem Tasks)

조직의 프로세스 성숙도에 따라 단계를 합치거나 세분화해도 됩니다.

2단계: 카드 템플릿 정의

가장 자주 등장하는 이벤트 유형별로, 미리 인쇄된 카드나 포스트잇 템플릿을 만듭니다. 예를 들어:

• 탐지 카드 (예: 파란색):

  • 시간(Time):
  • 소스(Source, PagerDuty 서비스명 또는 모니터 이름):
  • 탐지 주체(도구 또는 사람):
  • 증상(Symptom, 짧게):

• 액션 / 변경 카드 (예: 노란색):

  • 시간(Time):
  • 담당자(Owner):
  • 시스템 / 의존 서비스(System / Dependency):
  • 수행한 조치(Action taken):
  • 기대 효과(Expected effect):

• 영향도 카드 (예: 빨간색):

  • 시간(Time):
  • 영향받은 비즈니스 기능(Affected business capability):
  • 영향받은 고객 수(추정)(Customers affected, estimate):
  • 심각도(Severity):

• 커뮤니케이션 카드 (예: 초록색):

  • 시간(Time):
  • 대상(Audience, 내부 / 외부):
  • 채널(Channel, 이메일, 상태 페이지, Slack 등):
  • 요약(Summary):

각 카드는 이후 CrateDB에 저장하고자 하는 필드, 그리고 필요하다면 PagerDuty의 노트/커스텀 필드에 대응하도록 설계합니다. 이 필드 매핑이 데이터 드리프트를 막는 핵심입니다.

3단계: 역할 정의

• Incident Commander (IC): 대응을 지휘하고, 어떤 순간에 새로운 카드가 필요한지 호출합니다.
• Scribe / 타임라인 오너: 라이트하우스 계단의 주인입니다. 카드를 작성하고, 계단에 부착합니다.
• 기술 리드들: 자신이 수행한 액션이 계단에 정확히 반영되도록 확인합니다.

조직 규칙으로 분명히 선언합니다. “계단에 올라가지 않은 일은, 공식 스토리의 일부가 아니다.”

4단계: 실시간으로 계단 사용하기

인시던트 진행 중에는 다음과 같이 사용합니다.

1. 인시던트가 선언되면, Scribe가 곧바로 첫 번째 탐지 카드를 작성해 첫 번째 계단에 붙입니다.
2. 담당자가 정해지고 트리아지가 시작되면, 트리아지 & 담당 지정 단계에 카드 하나를 추가합니다. (누가 리드인지, 무엇에 초점을 맞추는지)
3. 가설이 세워지고, 완화 조치가 적용되고, 영향도 추정이 바뀔 때마다 해당 단계에 새 카드를 붙입니다.
4. 커뮤니케이션이 나갈 때마다(예: 외부 상태 페이지 업데이트), 커뮤니케이션 카드를 추가합니다.
5. IC가 해결을 선언하면 마지막 카드를 붙이고, 빠르게 한 번 더 훑어보며 눈에 띄는 빈 구간이 없는지 확인합니다.

IC는 주기적으로 "계단을 읽어 내려가며" 다음을 수행합니다.

• 모두가 같은 상황 인식을 갖도록 정렬
• 순서와 내용의 정확성을 검증
• 다음에 무엇을 할지 결정

5단계: 인시던트 이후 – CrateDB 및 PagerDuty와 동기화

인시던트가 종료되면, 다음 순서로 진행합니다.

1. 계단 전체를 사진으로 찍어 PagerDuty 인시던트나 티켓에 첨부합니다.
2. 각 카드를 인시던트 데이터 파이프라인에 전사합니다.
   • CrateDB 스키마에 필드를 매핑합니다. (예: time, actor, system, action, business_impact 등)
   • 계단 단계 이름을 내부에서 정의한 표준 라이프사이클 스테이지와 매칭합니다.
3. 라이트하우스 계단을 활용해 다음을 수행합니다.
   • 자동 로그 및 이벤트와 교차 검증
   • 의사결정의 "이유(why)"를 채워 넣기
   • 카드에는 있지만 로그에는 없는 부분을 통해 모니터링/알람의 누락 지점을 식별

이 단계에서 최소한의 재작업으로, 깨끗하고 구조화되고 맥락이 풍부한 데이터를 얻게 됩니다.

휴먼 팩터를 고려한 설계

라이트하우스 계단이 제대로 작동하려면, 사람들에게 마찰을 더하는 것이 아니라 부담을 줄여야 합니다. 실제 스트레스 상황에서 인간이 어떻게 행동하는지를 전제로 설계해야 합니다.

인지 부담 최소화

• 큰 글씨, 높은 색 대비, 단순한 형식을 사용합니다.
• 카드당 필드는 꼭 필요한 몇 개로 제한하고, 빽빽한 텍스트 블록은 피합니다.
• 계단 단계 수는 관리 가능한 수준으로 유지합니다. 계단이 너무 많으면 아무도 제대로 구분해서 쓰지 않습니다.

명확한 커뮤니케이션 지원

• 계단 업데이트를 하나의 의식(ritual) 으로 만듭니다. “이전 단계가 계단에 올라가기 전에는 다음 단계로 넘어가지 않는다.”
• 엔지니어들이 계단의 언어로 말하도록 유도합니다.
  예: “우리는 아직 영향도 평가 단계에 있어요.”, “이건 완화(Mitigation) 단계의 액션입니다.”

그룹 다이내믹 보완

• Scribe에게 정확성을 위해 대화를 잠시 멈출 수 있는 명시적인 권한을 줍니다.
  예: “잠깐만요, 방금 내용부터 먼저 적고 갈게요.”
• 조용한 참여자에게 계단의 뷰를 검증해 달라고 요청합니다.
  예: “이 단계에서 빠진 내용이 있는지 봐줄 수 있나요?”

스트레스 반응 관리

• 직접 자리에서 일어나 카드를 쓰고 벽에 붙이는 행위 자체가 짧은 인지 리셋을 제공합니다.
• 계단이 위로 차곡차곡 채워지는 시각적 진행 상황은, 팀이 실제로 앞으로 나아가고 있다는 안도감을 줘 과도한 불안을 줄입니다.

마무리

아날로그 인시던트 라이트하우스 계단은 의도적으로 단순합니다. 종이, 펜, 벽이면 충분합니다. 그러나 그 단순함 뒤에는 다음과 같은 강력한 아이디어가 있습니다.

• 비즈니스와 연결된 진짜 진척 상황을 눈에 보이게 만든다.
• 사후가 아니라 실시간으로 구조화된 데이터를 캡처한다.
• 그 구조를 활용해 데이터 적재 오류를 줄이고, CrateDB와 PagerDuty의 데이터 일관성과 해석 가능성을 높인다.

툴이 넘쳐나는 시대에, 라이트하우스 계단은 로우테크 앵커(low‑tech anchor) 입니다. 지금 무슨 일이 일어나는지, 무엇이 중요한지, 다음에 무엇을 해야 하는지를 한 화면(한 벽) 위에 공유하는 단 하나의 시각화입니다.

처음에는 작게 시작하십시오. 단계를 정의하고, 카드 템플릿 몇 개만 인쇄해서, 다음 중간 수준(severity 중간) 인시던트에서 시범 적용해 보십시오. 거기서부터 계속 개선하면 됩니다.

시간이 지나면, 장애를 더 침착하게 다룰 뿐만 아니라, 조직이 학습하는 데 쓸 수 있는 훨씬 더 풍부하고, 깔끔하며, 유용한 인시던트 히스토리를 쌓게 될 것입니다.