연필로 그린 장애 대응 주방: 모니터링이 뷔페 같을 때 종이 플레이북으로 요리하기

모니터링이 마치 무한리필 알림 뷔페처럼 느껴질 때가 있다면—페이지는 끝없이 쌓이고, 대시보드는 번쩍거리고, 누구도 “먼저 뭘 해야 할지” 확신이 없다면—당신만 그런 게 아니다.

많은 팀에서 장애는 지금도 이렇게 진행된다:

• 누군가 새벽 2시 17분에 호출을 받는다
• Slack 기록, 오래된 티켓, 구전 지식, 그리고 촉을 총동원해 이리저리 뒤져본다
• 결국은 해결되긴 하지만… 어떻게 거기까지 왔는지는 흐릿하고, 재현도 안 된다

이제 상상을 바꿔 보자. 장애 대응이 잘 돌아가는 주방처럼 느껴진다고 해보자: 정돈된 스테이션, 명확한 레시피, 각자 역할을 정확히 아는 사람들. 제대로 만든 장애 대응 런북(runbook)은 이런 일을 한다. 혼란스러운 ‘불 끄기’를, 누구나 따라 할 수 있는 차분하고 거의 지루할 정도로 반복 가능한 단계들의 연속으로 바꿔준다.

이 글은 다음 장애가 터지기 전에, 연필과 종이, 그리고 플레이북으로 그런 ‘주방’을 미리 만들어 두는 방법에 관한 이야기다.

혼돈에서 레시피로: 런북이 실제로 하는 일

**장애 대응 런북(incident response runbook)**은 특정 유형의 장애를 처리하기 위한, 단계별로 정리된 절차 문서다. 요리 레시피를 떠올리면 쉽다.

• 재료(Ingredients): 도구, 명령어, 대시보드, 권한
• 단계(Steps): 무엇을 어떤 순서로 확인하고, 그 결과에 따라 다음에 무엇을 할지
• 서빙 노트(Serving notes): 누구에게 알릴지, 어떻게 커뮤니케이션할지, 언제 에스컬레이션할지, 무엇을 기록할지

잘 설계된 런북은 다음을 바꿔준다:

• 영웅적인 임기응변 → 반복 가능한 프로세스
• “이건 Alice만 알아” → “그냥 런북 보면 돼”
• 스트레스 속의 찍어 보기(guesswork) → 인지 부담이 낮은, 명확한 의사결정

팀의 누구나 런북만 집어 들면 그럭저럭 제대로 대응할 수 있게 되면, 더 이상 소수의 전문가가 깨어 있고, 시간 나고, 온라인에 있어야만 한다는 전제에 매달리지 않아도 된다.

장애 대응의 미장플라스: 불 나기 전에 준비하기

프로 주방에는 **미장플라스(mise en place)**라는 개념이 있다. 직역하면 “모든 것이 제자리에.” 서비스 시작 전에 셰프들은 재료를 손질하고, 도구를 정리하고, 스테이션을 세팅해 두어야 바쁜 시간에도 매끄럽게 요리할 수 있다.

탄탄한 장애 대응도 똑같이 작동한다. 진짜 일은 장애 이전에 시작된다.

• 자주 발생하는 장애 유형 식별: 예) “API 레이턴시 급증”, “DB 커넥션 에러”, “디스크 풀(disk full)”, “큐 적체(queue backlog)”, “로그인 실패 급증”
• 유형을 테마별로 묶기: 네트워크, 스토리지, 퍼포먼스, 인증, 서드파티 의존성 등
• 오프라인에서 런북 작성: 화이트보드, 노트, 문서—정말로 연필과 종이도 좋다

장애 한가운데에 있을 때는, “우리가 원래 이렇게 정리해 두었으면 좋았을 텐데”를 고민하기에 최악의 타이밍이다. 당신의 ‘장애 주방’에는 미장플라스가 필요하다.

• 런북에 즐겨찾기된 대시보드 링크를 명시
• 진단용 명령어 리스트를 복붙 가능하게 정리
• 온콜 로테이션과 에스컬레이션 경로를 명확히 문서화
• 상태 공유용 커뮤니케이션 템플릿을 미리 준비

단순히 ‘해결 방법’을 적는 것이 아니다. 누구든 들어와서 바로 요리를 시작할 수 있게 테이블을 세팅하는 작업이다.

런북 설계하기: 빈 페이지에서 첫 번째 레시피까지

많은 팀이 “런북 좀 써야 하는데…”에서 멈춰버리는 이유는, 하얀 페이지가 너무 부담스럽기 때문이다. 템플릿과 구체적인 예시가 있으면 훨씬 빨리 움직일 수 있다.

실용적인 런북 구조는 대략 이렇게 생겼을 수 있다:

1. 제목 & 범위(Title & Scope)

   • 예: “High API Latency – Web Tier Only”
   • 이 런북이 다루는 것과 다루지 않는 것을 명확히 정의한다.

2. 트리거 / 언제 사용할지 (Trigger / When to Use)

   • 예: “프로덕션에서 api_p95_latency > 1s for 5 minutes일 때 이 런북을 시작한다.”
   • 알림 규칙이나 모니터링 패널로 직접 링크를 걸어 둔다.

3. 빠른 트리아지(Quick Triage, 최대 5분)

   • 알림이 실제 이슈인지(테스트/구데이터 아님)를 확인
   • 서비스 상태 페이지 / 메인 대시보드 확인
   • 영향 범위 파악: 사용자 수, 리전, 핵심 경로(critical path)

4. 안전 점검(Safety Checks)

   • “파괴적인 조치를 하기 전에, 현재 에러율, 최근 배포, 예정된 점검 여부를 확인한다.”
   • 위험도가 높은 행동은 굵게 강조해 표시한다.

5. 단계별 조사(Step-by-Step Investigation)

   • 순서가 있는 점검 목록: 로그, 메트릭, 의존성, 최근 변경사항
   • 실행할 구체적인 쿼리나 명령어
   • 연관 대시보드나 도구 링크

6. 의사결정 포인트 & 분기 로직(Decision Points & Branching Logic)

   • “에러율이 높은데 레이턴시는 정상이라면 → 7번 섹션으로 이동”
   • “특정 리전만 영향 받는 경우 → 리전별 완화(Regional Mitigation) 섹션으로 이동”

7. 완화(Mitigation) 액션

   • 롤백, 기능 플래그(feature flag), 트래픽 우회/분산
   • 각 액션의 선행 조건과 롤백 절차를 명확히 기술

8. 에스컬레이션 & 커뮤니케이션(Escalation & Communication)

   • 다음에 누구를 어떤 순서로 호출할지
   • 내부/외부 공지용 템플릿

9. 종료 기준(Exit Criteria)

   • “X, Y, Z 메트릭이 30분 동안 안정적으로 유지되면 장애가 완화된 것으로 간주한다.”

10. 사후 메모(Post-Incident Notes)

• 나중을 위해 어떤 내용을 남길지(타임라인, 기여 요인, 후속 작업 등)

준비된 템플릿과 실제 사례를 활용하면 속도가 훨씬 빨라진다. 자주 발생하는 몇 가지 장애 유형을 골라, 최소하지만 구체적인 런북을 먼저 만든 뒤, 각 장애 때마다 조금씩 개선해 나가면 된다.

분기 로직: 복잡한 상황에서 즉흥을 줄이는 법

모든 장애가 직선형 흐름을 갖는 건 아니다. 어떤 장애는 일종의 ‘내가 고르는 모험(choose your own adventure)’처럼 여러 갈래로 뻗어 나가기도 한다. 여기서 **분기 로직(branching logic)**이 필요하다.

주방의 의사결정 트리를 떠올리면 이해가 쉽다:

• 소스가 너무 되직하다 → 스톡(stock)을 추가한다
• 너무 짜다 → 희석하거나 산미로 밸런스를 맞춘다

런북으로 옮기면 이런 모습이다:

• 평이한 언어로 쓰인 의사결정 포인트
  • “데이터베이스 CPU가 10분 이상 90%를 초과하고 있는가?”
  • “에러율이 모든 리전에서 높아졌는가, 아니면 특정 리전만 그런가?”
• 명확한 분기
  • “예(Yes) → 경로 A로 진행 (스케일 업, 샤딩, 페일오버 고려)”
  • “아니오(No) → 경로 B로 진행 (애플리케이션 레이어, 최근 코드 변경 사항 조사)”

좋은 분기 로직은 다음을 가능하게 한다:

• 순간적으로 깊은 시스템 지식을 꺼내 쓸 필요를 줄인다
• 중요한 점검 단계를 건너뛰는 일을 방지한다
• 여러 응답자가 동시에 같은 플레이북을 따라가도 방향이 어긋나지 않게 한다

런북이 화려할 필요는 없다. 손으로 그린 플로우차트를 찍어서 문서 도구에 올려 두는 것만으로도 훌륭한 출발점이 될 수 있다.

효과 측정하기: MTTA, MTTR, 그리고 탄력성(Resilience)

런북은 “있으면 좋은 문서”가 아니다. 핵심 신뢰성 지표에 실제로 영향을 줘야 한다.

• MTTA(Mean Time to Acknowledge, 평균 인지 시간)

  • 트리거와 책임이 명확하면 알림 인지가 더 빨라진다.
  • 신규 온콜도 “이제 뭘 해야 하지?”를 고민할 필요가 없다. 답이 이미 적혀 있기 때문이다.

• MTTR(Mean Time to Resolve, 평균 해결 시간)

  • 막다른 길과 중복 작업이 줄어든다.
  • 진단이 표준화된다: 매번 동일한 ‘첫 10분’ 점검 절차를 수행하게 된다.
  • 자주 쓰는 완화 조치가 문서화되어 있고, 안전하며, 빠르게 실행 가능하다.

• 전반적인 시스템 탄력성(Resilience)

  • 런북을 쓰는 과정에서 취약한 지점과 지식 격차를 발견하게 된다.
  • 반복되는 장애 패턴이 또렷이 드러나, 구조적인 개선으로 이어질 수 있다.

만약 런북이 MTTA/MTTR 개선에 별 도움이 안 된다면, 그것도 피드백이다. 너무 모호하거나, 찾기 어렵거나, 실제 워크플로우 속에 녹아들지 못했을 가능성이 크다.

레시피를 신선하게 유지하기: 유지보수, 리뷰, 그리고 추적

장애 중에 만난 ‘묵은 런북’은, 없는 재료와 고장 난 장비를 당연하다는 듯 요구하는 레시피와 같다. 속도는 느려지고, 신뢰는 무너진다.

런북을 유용하게 유지하려면:

• 정기 리뷰

  • 분기별 혹은 큰 아키텍처 변경 이후에 검토
  • 문서 상단에 ‘리뷰 예정일’을 적어 둔다

• 관련 장애 이후마다 업데이트

  • 어떤 단계가 헷갈렸거나 빠져 있었는가?
  • 사람들이 런북 밖에서 임기응변한 부분은 어디인가?
  • 명령어나 대시보드가 바뀐 곳은 없는가?

• 실행 내역 추적

  • “1–7단계 수행, 8단계 스킵” 같은 간단한 체크리스트만 있어도 충분하다.
  • 런북을 첨부·임베드하고, 진행 상황을 표시할 수 있는 장애 관리 도구를 활용한다.

• 과감하게 가지치기

  • 쓰이지 않거나 오래된 런북은 병합하거나 제거한다.
  • 많기만 한 ‘문서 공동묘지’가 아니라, 잘 큐레이션된 작은 세트를 목표로 한다.

당신의 주방은 정리정돈이 잘 된 최신 공간이어야 한다. 오래된 배달 전단지로 가득 찬 서랍 같은 곳이 되어서는 안 된다.

전체 장애 워크플로우 안에 런북 녹여 넣기

런북은 위키 어딘가에 박혀 있는 정적인 문서일 때보다, 실제 워크플로우와 ‘배선’되어 있을 때 가장 강력하다.

• 알림에서 액션까지(From alerts to actions)

  • 각 알림이 특정 런북이나 의사결정 트리와 직접 연결되도록 한다.
  • 온콜 담당자는 페이지 → 런북 → 대시보드로 헌팅 없이 빠르게 이동할 수 있어야 한다.

• 장애 관리 도구 안에서(Within incident tools)

  • 장애 관리 시스템(incident management system)에 런북을 임베드한다.
  • 응답자가 도구 안에서 바로 단계 체크와 메모를 남길 수 있게 한다.

• 교육과 드릴 중에(During training and drills)

  • 게임데이(game day), 테이블탑(tabletop) 연습에 런북을 그대로 사용한다.
  • 신규 팀원이 런북을 처음부터 끝까지 실제로 ‘돌려보는’ 경험을 제공한다.

모니터링이 뷔페—즉, 신호는 너무 많고 노이즈도 가득—같이 느껴질 때, 런북은 각 상황에 맞는 ‘한 접시’를 정갈하게 차려내는 도구가 된다.

결론: 연필 하나, 플레이북 하나로 시작하기

완벽하고 완전히 자동화된 시스템이 있어야 시작할 수 있는 게 아니다. 필요한 건 단 세 가지다.

• 흔히 발생하는 장애 유형 한 가지
• 단순하지만 솔직한 런북 한 개
• 모두가 어디에 있는지 아는 단 하나의 저장 위치

필요하다면 진짜 연필로 첫 버전을 쓰면 된다. 이미 전문가들이 머릿속으로 하고 있는 일을 끌어내 문서로 옮기자. 이를 누구나 새벽 2시에라도 따라 할 수 있는, 명확하고 분기 로직이 있는 레시피로 바꾸면 된다.

그다음에는 장애가 올 때마다 다듬는다. 효과가 큰 곳부터 런북을 하나씩 더 추가한다. 알림과 연결하고, 사용 현황을 추적하고, 장애 주방을 항상 정리정돈되고 라벨링된 상태로 유지하라.

다음번 알림 뷔페가 쏟아질 때쯤이면, 당신의 플레이북은 이미 준비되어 있을 것이다. 잘 깎인 연필처럼 날카롭고, 조리대 위에 펼쳐져 있으며, 혼란 속에서도 차분하고 반복 가능한 단계들로 ‘요리하듯’ 장애를 해결할 준비가 되어 있을 것이다.