도입부: 장애 대응을 몇 번 겪고 나니, 지표와 시스템은 정상화되는데 운영자는 계속 소모된 채로 남는다는 감각이 강해졌습니다. 이 글에서는 “장애 후 사람 회복 프로세스의 부재”가 왜 반복 학습을 막는지, 그리고 조직 차원에서 어떤 장치부터 바꿔야 하는지 정리해봅니다.
장애는 끝났는데, 왜 나는 계속 무너질까
많은 조직에서 장애의 “종료 조건”은 명확합니다. 서비스가 복구되고(availability), 고객 영향이 줄고, MTTR이 수렴하면 장애는 끝납니다. 그리고 곧바로 재발 방지 대책을 정리하며 마무리합니다.
문제는 그 다음입니다. 실제 현장에서는 종종 이런 감정이 남습니다.
- “결국 사람을 갈아먹는 것 같다”
- “내가 부족해서, 내가 좋은 시스템을 못 만들어서 이렇게 됐다”
- “서비스만 살아나면 끝이고, 나는 그냥 다음 장애를 기다리는 상태다”
즉, 장애 대응 체계는 서비스 복구 중심으로는 정교하지만, 장애로 손상된 사람의 회복은 개인 책임(멘탈, 책임감, 자기관리)으로 방치되기 쉽습니다.
DevOps 기여가 ‘덜 실패하기’로 왜곡되는 평가 구조
DevOps/플랫폼/운영 역할의 기여는 평시에는 “당연한 것”이 되기 쉽고, 장애가 나면 질문이 한 문장으로 수렴합니다.
- “왜 막지 못했나요?”
이 프레임이 고착되면 운영의 가치는 “더 나은 전달/학습/자동화”가 아니라 **“실패를 더 숨기거나, 더 덜 발생시키는 것”**으로 축소됩니다. 그리고 장애 이후의 회고가 “학습”이 아니라 “평가/심판”처럼 느껴지기 시작합니다. 결국 남는 결론은 개인화된 죄책감입니다.
- “내가 더 잘했어야 했다”
- “내가 미리 알았어야 했다”
특히 Kubernetes처럼 복잡도가 높은 환경에서는, 원래 불확실성과 변수가 많아 “사전 예측”이 구조적으로 어려운데도 결과만 놓고 책임론이 강화되기 쉽습니다.
기존 장애 지표는 ‘사람의 상태’를 정의하지 않습니다
우리가 익숙한 장애 정의는 대개 아래에 집중합니다.
- 고객 영향(Customer impact)
- Severity
- MTTR(Mean Time To Recovery)
- 재발률, 장애 건수
여기엔 공통점이 있습니다. 사람의 상태가 빠져 있습니다.
그래서 조직의 의사결정 테이블에 이런 질문은 올라오지 않습니다.
- 이번 장애로 온콜이 얼마나 소진됐는가?
- 대응자가 다음 주에도 온콜을 유지할 수 있는가?
- 재발방지 액션이 “추가 과제”로 누적돼 회복을 방해하지는 않는가?
결국 “회복이 없다”는 건 단순히 복지의 문제가 아니라, 운영 리스크를 측정하는 모델이 사람을 누락하고 있다는 신호입니다.
관측성(Observability)은 있는데, ‘해석의 공통 모델’이 없다
현대 시스템에는 지표/로그/트레이스가 넘쳐납니다. 그런데도 장애 대응이 특정 개인의 경험에 의존하는 순간이 많습니다.
- 신호는 많은데 무엇이 중요한지 합의가 없다
- 알람은 울리는데 “이게 어떤 상태를 의미하는지” 공통 언어가 없다
- 결국 “아는 사람이 해결”하고, 다음엔 다시 반복된다
여기서 “미리 알았어야”라는 말이 나오면 학습은 사라집니다. 시스템이 복잡해질수록 필요한 건 개인의 초능력이 아니라, 조직이 공유하는 해석 프레임과 런북, 의사결정 기준입니다.
‘장애 종료’ 정의를 바꾸면 프로세스가 바뀝니다
제가 가장 크게 공감했던 포인트는 이것입니다.
장애가 회복되어 서비스만 잘 돌아가면 재발방지 대책과 마무리로 끝난다.
즉, 장애는 “서비스 복구”로 끝나고, 사람은 그 다음부터 알아서 회복해야 합니다.
이 전제를 뒤집으려면 **장애 종료의 게이트(Exit criteria)**를 바꾸는 것이 출발점이 됩니다.
예를 들어 종료 조건을 아래처럼 확장하는 겁니다.
- 서비스 복구 완료
- 1차 원인/영향 정리 완료(사실 기반)
- 대응자 컨디션 체크 및 역할 재배치 완료
- 후속 액션(재발방지) 소유권/일정이 ‘회복 가능한 범위’로 분산됨
핵심은 “회복”을 마음가짐이 아니라 운영 프로세스의 산출물로 만드는 것입니다.
최소한의 ‘사람 회복 프로세스’ 템플릿
조직이 당장 거창한 제도를 만들기 어렵다면, 최소 단위로 시작할 수 있습니다. 아래는 제가 생각하는 “최소 구성요소 3가지”입니다.
1) 강제 휴식(또는 온콜 제외) 규칙
장애의 크기(Severity)와 관계없이 “가장 힘든 장애”는 사람마다 다릅니다. 그래서 저는 단순 규칙이 필요하다고 봅니다.
- P1/P0 대응자는 다음 영업일 반나절~하루 온콜/배포 승인에서 제외
- 야간 대응(예: 02:00~06:00)이 발생하면 다음날 회의/업무량을 강제로 깎기
이건 배려가 아니라, 다음 장애의 MTTR을 지키는 장치입니다.
2) 블레임리스 디브리핑(사실-느낌-학습 분리)
회고가 “왜 막지 못했나”로 흐르면, 사람은 방어적으로 변하고 정보가 사라집니다. 디브리핑을 아래처럼 분리하면 도움이 됩니다.
- Facts: 타임라인, 영향, 의사결정, 관측된 신호
- Feelings: 가장 압박이 컸던 순간, 혼자 떠안았던 감정/부담
- Learnings: 다음에 바꿀 시스템/프로세스/런북
중요한 건 Feelings를 “감상”으로 취급하지 않고, 인지 부하와 의사결정 품질의 입력값으로 다루는 겁니다.
3) 재발방지 액션의 ‘부채화’ 방지(소유권 분산)
재발방지가 대응자에게 “추가 과제”로 몰리면 회복은 더 늦어집니다. 그래서 액션 아이템을 정할 때부터 룰이 필요합니다.
- 장애 대응자에게 후속 액션을 몰아주지 않는다
- 액션은 “더 조심/더 공부”가 아니라 시스템/프로세스 변경으로 표현한다
- 일정/우선순위 조정 권한이 없는 팀에게 “개선하라”고만 하지 않는다
재발방지는 학습의 결과여야지, 소진의 연장이 되면 안 됩니다.
지표를 바꾸면 의사결정이 바뀝니다
“사람 회복이 없다”는 문제는 대개 “측정되지 않는다”로 귀결됩니다. 지표가 없으면 우선순위 테이블에 못 올라갑니다.
바로 도입 가능한 신호는 이런 것들입니다.
- 온콜 이탈률 / 온콜 기피 증가
- 장애 후 2주 내 재발률(학습 부재의 신호)
- 장애 대응자 1인당 후속 액션 누적량(개선 과제의 쏠림)
- 장애 이후 병가/휴가 급증, 인력 교체 빈도(조직 비용)
이런 지표는 “개인을 감시”하려는 목적이 아니라, 회복 비용을 운영 비용으로 가시화하기 위한 장치여야 합니다.
마무리
장애 대응은 서비스 복구로 끝나는 일이 많지만, 운영을 지속 가능하게 만들려면 “사람의 회복”도 종료 조건으로 포함해야 합니다. 저는 회복을 개인의 탄력성이 아니라 조직이 설계해야 하는 프로세스로 다루는 순간, 같은 장애가 반복되는 방식도 달라진다고 믿습니다.