[CS300 #236] 장애 대응과 포스트모템 — 불을 끄는 법과 다시 안 나게 하는 법

컴퓨터공학 300 주제 시리즈의 236번째 글이다. 전체 지도는 여기.

한 줄 요약

장애 대응은 역할을 나누고 한 사람이 지휘하며 “원인 규명보다 영향 완화가 먼저”인 절차이고, 포스트모템은 사건이 끝난 뒤 사람을 탓하지 않고 시스템의 약점을 찾아 재발 방지 조치를 추적하는 문서다.

왜 필요한가

장애는 반드시 난다. 차이는 어떻게 대응하느냐다. 절차가 없는 팀의 장애 현장은 대개 이렇다. 다섯 명이 동시에 서로 다른 것을 재시작하고, 누가 무엇을 바꿨는지 아무도 모르고, 고객 문의에는 아무도 답하지 않고, 상황이 끝난 뒤에는 “누가 그 명령을 쳤냐”로 끝난다. 그리고 석 달 뒤 같은 장애가 다시 난다.

절차는 이 혼란을 줄이고, 포스트모템은 같은 장애가 반복되지 않게 한다.

핵심 개념

대응의 우선순위

완화(mitigate): 사용자 영향을 멈춘다. 롤백, 트래픽 우회, 기능 끄기(feature flag), 용량 증설.
복구(recover): 정상 상태로 되돌린다. 밀린 작업 처리, 데이터 정합성 확인.
원인 분석: 왜 일어났는지는 그다음이다.

가장 흔한 실수는 순서를 뒤집는 것이다. 원인을 정확히 알아내려고 사용자가 30분 더 장애를 겪게 두는 것은 대개 잘못된 선택이다. 직전에 배포가 있었다면 원인이 확실하지 않아도 먼저 롤백한다. 단, 완화 조치 전에 진단에 필요한 증거(로그, 힙 덤프, 상태 스냅샷)를 짧게 확보할 수 있다면 확보한다.

역할

Google SRE 책은 장애 대응에서 역할을 명확히 나눌 것을 권한다. 이 구조는 화재·재난 현장의 사고 지휘 체계(Incident Command System)에서 왔다.

역할	하는 일
Incident Commander (IC)	전체 지휘. 직접 고치지 않고 판단하고 위임한다
Operations / Ops lead	실제로 시스템을 조작한다. 조작은 이 사람(들)만 한다
Communications	상태 페이지, 고객·경영진 공지, 정기 업데이트
Planning / Scribe	타임라인 기록, 후속 작업 정리, 교대 준비

작은 팀이면 한 사람이 여러 역할을 맡는다. 그래도 “지금 IC 가 누구인가”는 항상 명확해야 한다. IC 가 바뀌면 명시적으로 넘긴다.

심각도 등급

사전에 등급 기준을 정해 둔다. 예를 들면 이렇다.

등급	기준(예시)	대응
SEV1	핵심 기능 전면 불가, 데이터 손실	즉시 호출, IC 지정, 30분마다 공지
SEV2	일부 사용자 또는 주요 기능 저하	근무 시간 외 호출, 공지
SEV3	우회 가능한 경미한 저하	다음 근무일 처리

기준은 조직마다 다르다. 중요한 것은 “이게 장애인가” 논쟁에 시간을 쓰지 않도록 미리 정해 두는 것이다. 애매하면 높은 등급으로 선언하고 나중에 낮추는 편이 낫다.

핵심 시간 지표

발생 ──── 탐지 ──── 응답 ──────── 완화 ──────── 복구
  |<-TTD->|<-TTA->|
  |<---------- TTM ---------->|
  |<------------------- TTR ------------------->|

TTD (time to detect): 발생부터 탐지까지. 모니터링 품질을 보여 준다.
TTA (time to acknowledge): 경보부터 사람이 응답하기까지.
TTM (time to mitigate): 발생부터 사용자 영향이 멈추기까지.
TTR (time to resolve/recover): 발생부터 완전 복구까지.

이 지표들의 시작점·끝점 정의는 조직마다 조금씩 다르다. 비교하려면 정의를 먼저 맞춘다. 이 글에서는 모두 실제 발생 시각에서 잰다.

여러 사건의 평균을 내면 MTTD, MTTR 이 된다. 다만 사건 수가 적고 분포가 치우쳐 있어 평균은 쉽게 왜곡된다. 추세를 볼 때는 중앙값이나 개별 사건 검토를 함께 쓴다.

포스트모템

포스트모템은 사건이 끝난 뒤 쓰는 기록이다. 일반적인 구성은 다음과 같다.

요약: 무엇이, 언제, 얼마나 영향을 줬나
영향: 사용자 수, 실패 요청 수, 매출, 소모한 에러 버짓
타임라인: 분 단위의 사실 기록
근본 원인과 기여 요인
잘된 점, 잘못된 점, 운이 좋았던 점
후속 조치(action item): 담당자와 기한, 추적 가능한 티켓

비난하지 않는(blameless) 문화

포스트모템의 핵심 원칙은 사람이 아니라 시스템을 본다는 것이다. “엔지니어 A 가 잘못된 명령을 실행했다”에서 멈추면 아무것도 고쳐지지 않는다. 묻는 질문은 이렇다. 왜 그 명령이 운영 환경에서 확인 없이 실행될 수 있었나? 왜 결과를 바로 알 수 없었나? 왜 되돌리는 데 40분이 걸렸나?

사람을 탓하면 사람들은 실수를 숨긴다. 숨겨진 실수는 다음 장애의 씨앗이 된다. SRE 책이 강조하듯, 포스트모템은 처벌이 아니라 학습의 도구여야 한다.

“근본 원인” 하나에 집착하지 않기

복잡한 시스템의 장애는 대개 여러 요인이 겹쳐서 난다. 설정 실수 + 검증 부재 + 경보 미흡 + 롤백 절차 미숙. 하나만 고치면 다음에는 다른 조합으로 터진다. 그래서 “기여 요인”을 여럿 적고, 각 계층에서 방어선을 하나씩 추가한다.

직접 해 보기

장애 타임라인에서 시간 지표를 계산하고, 후속 조치가 실제로 완료되는지 추적해 보자.

from datetime import datetime as dt
from statistics import mean, median

def minutes(a, b):
    return (dt.fromisoformat(b) - dt.fromisoformat(a)).total_seconds() / 60

incidents = [
    # start(실제 발생), detect, ack, mitigate, resolve
    ("INC-1", "2026-09-01T02:10", "2026-09-01T02:14", "2026-09-01T02:19", "2026-09-01T02:40", "2026-09-01T03:30"),
    ("INC-2", "2026-09-09T14:00", "2026-09-09T14:45", "2026-09-09T14:47", "2026-09-09T15:05", "2026-09-09T15:20"),
    ("INC-3", "2026-09-20T09:30", "2026-09-20T09:31", "2026-09-20T09:33", "2026-09-20T09:38", "2026-09-20T13:00"),
]
rows = []
for iid, start, det, ack, mit, res in incidents:
    r = dict(id=iid, ttd=minutes(start, det), tta=minutes(det, ack),
             ttm=minutes(start, mit), ttr=minutes(start, res))
    rows.append(r)
    print(f"{iid}: TTD={r['ttd']:4.0f} TTA={r['tta']:3.0f} TTM={r['ttm']:4.0f} TTR={r['ttr']:4.0f} (min)")

for k in ("ttd", "ttm", "ttr"):
    vals = [r[k] for r in rows]
    print(f"{k.upper()}: mean={mean(vals):6.1f} median={median(vals):6.1f}")

actions = [
    ("INC-1", "디스크 사용률 85% 경보 추가", "done"),
    ("INC-2", "에러율 번 레이트 경보 추가", "done"),
    ("INC-2", "배포 후 자동 카나리 분석", "open"),
    ("INC-3", "DB 마이그레이션 롤백 절차 문서화", "open"),
    ("INC-3", "마이그레이션 스테이징 리허설 의무화", "open"),
]
done = sum(1 for a in actions if a[2] == "done")
print(f"action items: {done}/{len(actions)} done")
for a in actions:
    if a[2] == "open":
        print("  OPEN", a[0], a[1])

결과는 다음과 같다.

INC-1: TTD=   4 TTA=  5 TTM=  30 TTR=  80 (min)
INC-2: TTD=  45 TTA=  2 TTM=  65 TTR=  80 (min)
INC-3: TTD=   1 TTA=  2 TTM=   8 TTR= 210 (min)
TTD: mean=  16.7 median=   4.0
TTM: mean=  34.3 median=  30.0
TTR: mean= 123.3 median=  80.0
action items: 2/5 done
  OPEN INC-2 배포 후 자동 카나리 분석
  OPEN INC-3 DB 마이그레이션 롤백 절차 문서화
  OPEN INC-3 마이그레이션 스테이징 리허설 의무화

INC-2 는 탐지에 45분이 걸렸다. 모니터링의 구멍이다. INC-3 는 8분 만에 완화했지만 완전 복구에 3시간 반이 걸렸다. 데이터 복구 절차의 문제다. 평균만 보면 이 차이가 보이지 않는다. 그리고 후속 조치의 절반 이상이 열려 있다. 포스트모템의 가치는 문서가 아니라 닫힌 조치에서 나온다.

현업에서는

장애 채널과 타임라인. 장애마다 전용 채팅 채널을 열고, 무엇을 봤고 무엇을 바꿨는지 그 채널에 적는다. 포스트모템의 타임라인은 여기서 거의 그대로 나온다.
“마지막 변경”을 먼저 본다. 많은 장애가 배포·설정 변경 직후에 일어난다. 변경 이력(GitOps 라면 Git 로그)과 장애 시작 시각을 나란히 놓는다.
런북. 자주 울리는 경보마다 “이 경보가 울리면 무엇을 확인하고 무엇을 하라”는 런북을 연결한다. 새벽 3시의 사람은 똑똑하지 않다.
무응답도 장애다. 자동화된 알림 봇이나 당번 체계가 조용히 멈추면 장애가 탐지되지 않는다. 감시 체계 자체를 감시하는 하트비트 경보(일정 시간 신호가 없으면 경보)를 둔다.
보안 사고는 별도 절차. 침해 사고는 증거 보존, 법적 통지 의무 등 추가 요구가 있다. NIST SP 800-61 같은 사고 대응 지침을 참고해 별도 절차를 둔다.

확인 문제

장애 대응에서 원인 분석보다 완화를 먼저 하는 이유는?
Incident Commander 가 직접 시스템을 고치지 않는 이유는?
TTD 가 긴 사건과 TTR 만 긴 사건은 각각 무엇을 개선해야 하는가?
“비난하지 않는” 포스트모템이 재발 방지에 더 효과적인 이유는?
포스트모템을 썼는데 같은 장애가 반복됐다. 가장 먼저 확인할 것은?

풀이

사용자 영향 시간을 줄이는 것이 최우선이기 때문이다. 원인 분석은 영향이 멈춘 뒤에도 할 수 있다.
손이 시스템에 묶이면 전체 상황 판단, 위임, 소통을 할 수 없다. 지휘와 조작을 분리해야 혼란이 줄어든다.
TTD 가 길면 탐지(모니터링·경보)를, TTR 만 길면 복구 절차(데이터 복구, 롤백, 자동화)를 개선한다.
사람을 탓하면 실수와 정보가 숨겨진다. 시스템의 약점이 드러나야 방어선을 추가할 수 있다.
후속 조치가 실제로 완료되었는지, 그리고 그 조치가 기여 요인을 제대로 겨냥했는지.

더 읽을거리 (References)

Google SRE Book, Managing Incidents
Google SRE Book, Postmortem Culture: Learning from Failure
Google SRE Workbook, Incident Response
NIST, SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management