Rain Lag

종이 인시던트 스토리 등대 주방: 가장 조용한 근접 사고로 손수 러న్북 만들기

가장 작고 조용하게 지나가는 인시던트를 MTTA/MTTR을 줄이고, 회복탄력성을 높이며, 지능형 자동화 대응으로 이어지는 강력한 러브북 라이브러리로 만드는 방법.

종이 인시던트 스토리 등대 주방: 가장 조용한 근접 사고로 손수 러ン북 만들기

커다란 인시던트 스토리는 쉽게 떠오를 것입니다. 한밤중에 울려대는 페이저, 수시간 동안 이어진 장애 회고, 전사 워룸(All‑hands war room) 말이죠.

하지만 회복탄력성(resilience)을 진짜로 강화해 주는 보물은, 대개 거의 눈치채지 못했던 인시던트 속에 숨어 있습니다.

자동으로 해제된 경고 알림, “거의” 롤백까지 갈 뻔한 배포, 5분 만에 잦아든 CPU 스파이크. 이런 조용한 근접 사고(quiet near‑miss) 들이, 앞으로의 화재를 작고 다루기 쉬운 수준으로 유지하게 해 줄 러ン북을 만드는 최고의 원재료입니다.

이것이 바로 **“종이 인시던트 스토리 등대 주방(Paper Incident Story Lighthouse Kitchen)”**이라는 아이디어입니다. 눈에 잘 띄지 않는 잔소(紙傷) 같은 인시던트를 차곡차곡 수집하고, 잘게 썰어, 차분하게 조리해서 명확하고 신뢰할 수 있는 러ン북 — 그리고 궁극적으로는 지능형 자동화 — 로 만들어 내는 곳이죠.

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

  • 인시던트 대응 러ン북이 핵심 도구인 이유
  • 인시던트의 대표적인 원인(그리고 무엇을 문서화해야 하는지)
  • 구조화된 IcM 프로세스로 혼란을 일관성으로 바꾸는 방법
  • 바로 가져다 쓸 수 있는 실용 예시와 러ン북 템플릿
  • 러ン북 자동화가 발전하는 단계
  • 조용한 근접 사고를 대형 사고로 번지기 전에 포착하는 방법

왜 러ン북은 주방의 주력 칼인가

인시던트 대응 러ン북(Incident Response Runbook) 은 운영 세계의 레시피와 같습니다. 장애를 탐지하고(detect), 진단하고(diagnose), 복구(resolve) 하는 절차를 단계별로 정리한 안내서입니다.

잘 만들어진 러ン북은 다음을 크게 개선합니다.

  • MTTA(Mean Time To Acknowledge, 인지까지 평균 시간) – 명확한 지침과 라우팅 규칙 덕분에 알림 발생부터 사람의 확인까지 걸리는 시간이 줄어듭니다.
  • MTTR(Mean Time To Resolve, 복구까지 평균 시간) – 반복 가능한 절차 덕분에 추측과 망설임이 줄어듭니다.
  • 전반적인 시스템 회복탄력성 – 한 번 문서화된 대응 방식은 재사용 가능한 플레이가 되어, 압박 속에서 그때그때 즉흥적으로 해결책을 발명하지 않아도 됩니다.

좋은 러ン북은 다음 세 가지를 즉시 답해 줍니다.

  1. 누가 움직여야 하는가?
  2. 무엇을 어떤 순서로 해야 하는가?
  3. 어떻게 우리가 끝났는지(또는 상향 에스컬레이션해야 하는지) 알 수 있는가?

핵심은 가장 큰 인시던트에만 러ン북을 쓰는 것이 아니라, 가장 작은 인시던트를 학습 데이터로 삼는 데 있습니다.

흔한 용의자들: 인시던트의 일반적인 원인

러ン북을 요리하기 전에, 먼저 재료를 알아야 합니다. 대부분의 인시던트는 다음과 같은 몇 가지 범주로 모일 것입니다.

  1. 하드웨어 / 인프라 장애

    • 디스크 장애, 네트워크 파티션, 노드 장애
    • 클라우드 제공자의 리전 이슈 또는 AZ(가용 영역) 글리치

  2. 리소스 한계 및 용량 문제

    • CPU, 메모리, 디스크, I/O 임계치 초과
    • API, 데이터베이스, 큐 등의 레이트 리밋(rate limit) 초과

  3. 휴먼 에러(Human Error)

    • 실패하거나 일부만 성공한 배포
    • 인프라‑as‑코드, 피처 플래그, 시크릿 설정 오류
    • 수동 운영 작업 실수(잘못된 명령, 잘못된 호스트 등)

  4. 외부 위협 및 보안 공격

    • DDoS 공격
    • 크리덴셜 스터핑, 의심스러운 로그인 시도
    • 데이터 유출 시도, 멀웨어/랜섬웨어 공격 징후

각 범주마다 최소 한 개 이상의 베이스라인 러ン북이 필요합니다. 어떻게 이를 인지하는가? 첫 행동은 무엇인가? 언제 더 많은 도움을 호출해야 하는가?

그리고 특히 중요한 점은, 이 범주들에서 발생하는 조용한 근접 사고들이 어디에 더 나은 문서화나 자동화가 필요한지 알려 주는 초기 신호라는 것입니다.

IcM은 주방 라인: 구조화되고, 반복 가능하며, 빠르게

인시던트 관리(Incident Management, IcM) 프로세스 는 날것의 인시던트를 일관되고 신뢰할 수 있는 결과로 바꿔 주는 주방 라인(kitchen line)입니다.

탄탄한 IcM 프로세스는 보통 다음 단계를 포함합니다.

  1. 탐지 & 트리아지(Detection & Triage)

    • 알림, 메트릭, 로그, 사용자 신고
    • 심각도(severity)와 영향도(impact)에 따른 분류

  2. 할당 & 인지(Assignment & Acknowledgment)

    • 적절한 온콜(on‑call) 또는 팀으로 자동 라우팅
    • 명확한 오너십과 MTTA 중심의 응답 SLA

  3. 차단 & 완화(Containment & Mitigation)

    • 피해 확산을 막기 위한 단기 조치
    • 트래픽 셰이핑, 피처 플래그 강제 OFF, 서킷 브레이커

  4. 진단 & 해결(Diagnosis & Resolution)

    • 근본 원인 분석(RCA)
    • 패치, 롤백, 설정 변경 등 해결 조치

  5. 사후 리뷰 & 학습(Post‑Incident Review & Learning)

    • 블레이멧(blameless) 회고
    • 기존 러ン북 업데이트 또는 신규 러ン북 작성
    • 이후 자동화 대상 선정

러ン북은 이 프로세스 안에서 움직이는 작업 단위(unit of work) 입니다. IcM의 주요 단계마다 기존 러ン북을 참조하거나, 새로운/개선된 러ン북을 생성해야 합니다.

등대 주방: 근접 사고를 러ン북으로 바꾸기

“등대 주방(lighthouse kitchen)”이라는 메타포는 두 부분으로 나뉩니다.

  • 등대(Lighthouse): 재난이 터지기 전에, 조용하지만 꾸준히 방향을 알려 주는 신호
  • 주방(Kitchen): 의도적인 준비, 반복, 다듬기가 이뤄지는 공간

이걸 실제로 구축하려면, 모든 근접 사고를 기록할 만한 이야기로 다루어야 합니다.

1단계: 종이 인시던트부터 포착하기

뭔가 이상한 일이 생겼다면 — 5분짜리 지연(latency) 스파이크, 금방 롤백으로 수습한 실패 배포, 플랩(flapping)만 하다가 사라진 알림 등 — 그냥 흘려보내지 마십시오.

다음 네 가지를 최소한으로 남깁니다.

  • 무엇을 보았는지: 알림, 로그, 대시보드, 사용자 증상
  • 무엇을 했는지: 실행한 명령, 확인한 대시보드, 호출된 사람들
  • 무엇이 효과 있었는지: 시스템을 안정시킨 실제 액션
  • 무엇이 아쉬웠는지: 더 있었으면 좋았던 알림, 빠져 있던 대시보드, 애매했던 문서 등

이 정도는 인시던트 관리 도구, 위키, 티켓 시스템에서 쓸 수 있는 아주 가벼운 템플릿이면 충분합니다.

2단계: 이야기를 러ン북으로 증류하기

이렇게 모은 이야기를 바탕으로 1차 버전 러ン북을 작성합니다. 처음부터 완벽할 필요는 없습니다.

예시: “Region X 웹 지연(latency) 스파이크” 러ン북(골격)

  1. 트리거(Triggers)

    • Alert: web.latency.p95 > 1.5s for 5m in region=us‑east

  2. 즉시 점검(5–10분)

    • 대시보드 확인: Web / Latency & Error Rates / Region Split
    • 확인: 문제가 특정 리전에만 국한되는지, 전역(global)인지
    • 에러율 확인: 지연과 함께 5xx 에러도 같이 올랐는지

  3. 차단/완화 옵션(Containment options)

    • 한 개 AZ만 영향 받는다면, 정상 AZ로 트래픽 20% 전환
    • 모든 AZ가 영향을 받고, 읽기 트래픽이 크다면: 비핵심 플로우에 대해 읽기 전용(read‑only) 모드 활성화

  4. 진단(Diagnosis)

    • 데이터베이스 CPU 및 락 경합(lock contention) 확인
    • 최근 3개 리전에 영향을 줄 수 있는 배포 기록 확인
    • 상위 의존성(결제, 인증 등) 서비스 지연 여부 확인

  5. 해결 & 후속 조치(Resolution & Follow‑up)

    • 스파이크와 상관 있어 보이는 최근 배포가 있다면 롤백
    • 근본 원인을 찾았다면 버그 티켓 생성
    • 인시던트 요약을 기록하고, 이 러ン북 업데이트

다음에 같은 패턴이 나타나면, 온콜은 백지에서 시작하는 대신 이 레시피를 따라가면 됩니다.

3단계: 쓸 때마다 계속 손질하기

러ン북을 한 번 사용할 때마다 다음을 점검하며 개선합니다.

  • 더 이상 맞지 않는(구식이 된) 단계 제거
  • 빠져 있던 점검 항목 추가
  • 모호한 표현을 더 명확한 문장으로 수정
  • 나중에 자동화해도 안전한 단계 표시

시간이 지나면, 여러분의 등대 주방은 잘 관리된 요리책(쿠크북)이 됩니다. 가장 흔하면서도 위험도가 높은 장애 패턴을 커버하는 신뢰할 수 있는 플레이 모음집이죠.

바로 가져다 쓸 수 있는 러ン북 템플릿 예시

지금 바로 가져다 쓸 수 있도록, 간단한 패턴 세 가지를 예시로 정리했습니다.

1. 하드웨어 / 인프라 장애

제목: 프로덕션 클러스터 노드 장애

  1. 트리거: 노드가 NotReady 상태로 5분 초과 유지
  2. 담당자(Who): 플랫폼 온콜
  3. 점검(Checks):
    • 클러스터 대시보드에서 노드 상태 확인
    • 워크로드가 정상적으로 재스케줄(reschedule)되었는지 확인
  4. 조치(Actions):
    • 워크로드가 건강하다면: 노드를 cordon & drain 후 재생성
    • 서비스가 저하되었다면: 재스케줄을 우선 처리하고 스케일 아웃
  5. 종료 조건(Done when):
    • 모든 워크로드가 Healthy 상태이며 SLO가 회복됨

2. 리소스 한계 / 용량 이슈

제목: 데이터베이스 CPU 포화(Database CPU Saturation)

  1. 트리거: DB CPU > 85% 상태가 10분 이상 지속
  2. 점검(Checks):
    • CPU 사용량 기준 상위 쿼리
    • 커넥션 풀(pool) 포화 여부
  3. 조치(Actions):
    • 비핵심 클라이언트에 대한 긴급 커넥션 제한 적용
    • 리소스를 많이 쓰는 백그라운드 작업 일시 중지
  4. 후속 조치(Follow‑up):
    • 상위 문제 쿼리에 대해 인덱스 추가 또는 튜닝/최적화 티켓 생성

3. 휴먼 에러 / 배포 실패

제목: 프로덕션 배포 실패 롤백

  1. 트리거: 배포 후 5분 이내에 에러율이 3배 이상 증가
  2. 조치(Actions):
    • 추가 배포를 즉시 중단(Pause)
    • 마지막으로 안정적이었던 버전으로 롤백
  3. 검증(Verification):
    • 주요 메트릭이 기준선(baseline)으로 돌아왔는지 확인
    • 인시던트 문서화

이러한 템플릿은 대응자에게는 출발선을, 여러분에게는 실제 근접 사고 사례를 반영해 점점 더 다듬어 갈 수 있는 구조를 제공합니다.

러ン북에서 실시간 이벤트 기반 자동화까지

예전의 “자동화”는 대개 크론(cron) 작업과 스크립트를 의미했습니다. 정해진 시간에 돌아가는 작업이나, 사람이 수동으로 실행하는 스크립트 정도였죠.

현대적인 러ン북 자동화(runbook automation) 는 그보다 훨씬 더 나아갑니다.

  1. 이벤트 기반 실행(Event‑driven execution)

    • 시스템 신호(알림, 로그 패턴, 상태 변화 등)가 자동으로 액션을 트리거합니다.
    • 예: 노드 장애를 감지하면 자동으로 해당 노드를 cordon & drain.

  2. 가드레일과 승인(Guardrails & Approvals)

    • 위험도가 높은 액션은 사람의 승인을 요구합니다.
    • 위험이 낮고 쉽게 롤백 가능한 액션은 완전 자동화합니다.

  3. 지능형 자동화(Intelligent Automation)

    • 과거 인시던트 데이터를 활용해, 가장 가능성 높은 해결책을 제안
    • 인시던트 패턴에 따라 적합한 러ン북을 자동 선택
    • 실시간 신호를 보며, 실행 중 단계들을 동적으로 조정

일반적인 여정은 다음과 같이 발전합니다.

  1. 수동 러ン북(Manual Runbooks) – 사람이 문서에 적힌 절차를 하나씩 수행
  2. 스크립트 기반 러ン북(Scripted Runbooks) – 사람이 스크립트를 호출하면 스크립트가 일부/전부 수행
  3. 이벤트 기반 자동화(Event‑driven Automation) – 시스템 신호에 따라 스크립트가 자동 실행
  4. 지능형 오케스트레이션(Intelligent Orchestration) – 시스템이 상황에 맞는 러ン북을 선택·조합해 실시간으로 실행

여기서 가장 중요한 점: 레시피 단계는 건너뛸 수 없습니다. 지능형 자동화의 품질은, 그 기반이 되는 러ン북의 품질에 달려 있습니다. 그리고 그 러ン북은 실제 인시던트와 근접 사고를 재료로 삼아 만들어져야 합니다.

조용한 근접 사고가 최고의 스승인 이유

대형 장애는 어쩔 수 없이 학습을 강제합니다. 회고를 하고, 논의하고, 문서화하게 되죠.

반면 조용한 근접 사고는, 여러분이 의도적으로 주목하지 않는 이상 그냥 사라집니다.

이러한 작은 신호를 러ン북으로 포착해 두면 다음과 같은 이점이 있습니다.

  • 위태로운 가정을 일찍 발견 (예: 아직 터지진 않았지만 임계치 가까이 간 의존성)
  • 자동화를 점진적으로 단단하게 (예: 리스크가 낮은 배포에 대한 자동 롤백을 안전하게 도입)
  • 수동 반복 작업을 줄임 (예: 매번 반복하던 완화 조치를 원클릭 혹은 완전 자동으로 전환)
  • 대형 장애를 사전에 차단 (종이 상처일 때 패턴을 고쳐, 헤드라인급 사고가 되기 전에 해결)

각각의 조용한 인시던트를 등대의 한 번 깜박임이라고 생각해 보십시오. 시스템이나 프로세스, 도구 어딘가에 더 좋은 레시피가 필요하다는 은근한 경고입니다.

결론: 이미 가지고 있는 재료로 요리를 시작하라

MTTA, MTTR, 회복탄력성을 개선하기 위해 거대한 신규 플랫폼이 필요한 것은 아닙니다. 이미 여러분에게는 충분한 재료가 있습니다.

  • 시스템에서 쏟아지는 알림과 로그
  • 온콜 엔지니어들의 전쟁터 경험담
  • 조용히 지나가 버린, 거의 잊힌 근접 사고들의 흐름

이것들을 종이 인시던트 스토리 등대 주방 으로 바꾸십시오.

  1. 작고, 자동으로 치유됐거나, 근접 사고에 그친 인시던트까지도 포착합니다.
  2. 이를 간단하고 실용적인 러ン북으로 증류합니다.
  3. 러ン북을 사용할 때마다 조금씩 개선합니다.
  4. 가장 안전하고 반복적인 단계를 점차 자동화합니다.
  5. 이벤트 기반, 지능형 러ン북 자동화로 진화해 나갑니다.

이 과정을 꾸준히 이어 가면, 팀은 위기 속에서 즉흥적으로 대응하는 데 쓰는 시간을 줄이고, 애초에 큰불로 번지지 않게 설계하는 일 에 더 많은 시간을 쓸 수 있습니다.

미래의 장애는 이미 속삭이고 있습니다. 러ン북은 그 속삭임을 듣는 법을 배우는 도구이며, 그 속삭임이 언젠가 고함으로 바뀌었을 때 여러분이 준비되어 있도록 해 주는 방법입니다.

종이 인시던트 스토리 등대 주방: 가장 조용한 근접 사고로 손수 러న్북 만들기 | Rain Lag