장애 회고와 Runbook 운영법: 알림 피로를 줄이고 같은 장애를 반복하지 않는 팀 만들기
장애는 끝난 뒤부터 팀의 실력이 드러난다
서비스 장애가 발생하면 팀은 복구에 집중합니다. 알림이 울리고, 대시보드를 열고, 로그를 뒤지고, 임시 조치를 적용합니다. 하지만 진짜 중요한 일은 장애가 끝난 뒤 시작됩니다. 왜 같은 종류의 장애가 다시 발생하는지, 왜 알림은 많았는데 원인 파악은 늦었는지, 왜 대응자가 매번 같은 명령을 검색해야 했는지 돌아봐야 합니다.
장애 회고는 누군가를 비난하는 문서가 아닙니다. 시스템이 어떤 조건에서 실패했고, 팀의 관측성과 절차가 어디서 부족했는지 확인하는 과정입니다. 좋은 회고는 "사람이 조심한다"로 끝나지 않습니다. 다음번에는 같은 실수를 하기 어렵도록 알림, runbook, 배포 절차, 테스트, 소유권을 바꿉니다.
알림 피로도 중요한 문제입니다. 매일 중요하지 않은 알림이 수십 개 울리면 온콜 담당자는 결국 알림을 믿지 않습니다. 심각한 장애 알림도 배경 소음처럼 느껴집니다. 알림은 많을수록 안전한 것이 아니라, 행동 가능한 알림만 남을수록 안전합니다.
1. 좋은 알림은 행동을 요구한다
알림을 만들 때 가장 먼저 물어야 할 질문은 "이 알림을 받은 사람이 지금 무엇을 해야 하는가"입니다. CPU가 80%를 넘었다는 알림은 상황에 따라 의미가 없습니다. CPU가 높아도 사용자 영향이 없고 자동으로 회복된다면 알림이 아니라 대시보드 지표로 충분할 수 있습니다.
반대로 에러율, 지연 시간, 큐 적체 시간, 결제 실패율처럼 사용자 경험이나 비즈니스 동작에 직접 연결되는 지표는 알림 가치가 높습니다. 특히 SLO 기반 burn rate 알림은 단순 임계값보다 실용적입니다. 짧은 시간에 빠르게 예산을 태우는 장애와, 천천히 악화되는 장애를 다른 우선순위로 다룰 수 있습니다.
알림 메시지에는 서비스 이름, 영향 범위, 현재 값, 기준 값, 대시보드 링크, runbook 링크가 포함되어야 합니다. "High latency"만 보내는 알림은 대응자를 다시 검색하게 만듭니다. 알림은 문제를 알려주는 것에서 끝나지 않고 첫 대응 화면으로 이어져야 합니다.
2. Runbook은 장애 중에 읽는 문서다
Runbook은 평소에 멋지게 보이기 위한 문서가 아닙니다. 새벽에 잠이 덜 깬 담당자가 보고도 따라 할 수 있어야 합니다. 그래서 짧고 구체적이어야 합니다. 증상 확인, 영향 범위 판단, 즉시 완화 조치, 롤백 방법, 에스컬레이션 기준, 사후 확인 항목이 순서대로 있어야 합니다.
나쁜 runbook은 배경 설명이 길고 명령이 모호합니다. "필요하면 서버를 재시작한다"는 문장은 충분하지 않습니다. 어떤 서버를 어떤 순서로 재시작하는지, 재시작하면 어떤 사용자 영향이 있는지, 성공 여부를 어떤 지표로 확인하는지 적어야 합니다. 위험한 명령에는 예상 부작용과 승인 기준도 있어야 합니다.
Runbook은 실제 장애에서 계속 수정되어야 합니다. 회고 때 "문서가 없어서 늦었다"가 나오면 새 runbook을 만들고, "문서가 틀려서 헤맸다"가 나오면 기존 문서를 고칩니다. 문서 소유자를 정하지 않으면 runbook은 빠르게 낡습니다. 서비스 소유권과 문서 소유권은 함께 움직여야 합니다.
3. 회고는 타임라인과 개선 과제로 남긴다
좋은 회고 문서는 타임라인에서 시작합니다. 언제 알림이 울렸고, 누가 확인했고, 어떤 가설을 세웠고, 어떤 조치를 했고, 언제 회복됐는지 기록합니다. 감정이 섞인 기억보다 시간 순서의 사실이 원인 분석에 도움이 됩니다. 채팅 로그와 배포 이력, 대시보드 스냅샷을 함께 남기면 나중에 다시 볼 수 있습니다.
원인 분석은 단일 원인 찾기로 끝나면 안 됩니다. 장애는 보통 여러 방어선이 동시에 실패했을 때 발생합니다. 잘못된 설정이 배포됐고, 테스트가 잡지 못했고, 알림이 늦었고, 롤백 절차가 불명확했을 수 있습니다. 각 방어선을 어떻게 보강할지 과제로 나눠야 합니다.
개선 과제는 담당자와 기한이 있어야 합니다. "모니터링 강화" 같은 문장은 실행되지 않습니다. "결제 API p95 latency burn rate 알림 추가, 담당자 A, 5월 10일까지"처럼 구체적이어야 합니다. 다음 회고나 운영 회의에서 닫히지 않은 과제를 확인하는 절차도 필요합니다.
4. 운영 체크리스트
- 모든 page 알림에 runbook 링크가 있는가
- 알림을 받은 사람이 즉시 할 행동이 명확한가
- 사용자 영향 없는 지표 알림이 온콜을 깨우고 있지 않은가
- 장애 회고에 타임라인, 영향 범위, 원인, 개선 과제가 포함되는가
- 개선 과제마다 담당자와 기한이 있는가
- Runbook이 최근 장애 경험을 반영해 갱신되었는가
- 반복 장애를 별도 태그로 묶어 추세를 보고 있는가
4. 알림 피로는 정리하지 않으면 계속 쌓인다
알림은 처음 만들 때는 모두 중요해 보입니다. 하지만 서비스가 커지면 임시 알림, 실험용 알림, 더 이상 의미 없는 임계값이 계속 남습니다. 온콜 담당자가 매일 같은 warn 알림을 무시하기 시작하면 심각한 장애 알림도 같이 무시될 위험이 커집니다. 알림 피로는 사람의 집중력 문제가 아니라 운영 시스템의 부채입니다.
알림 정리는 정기 작업이어야 합니다. 최근 30일 동안 울린 알림을 기준으로 actioned, ignored, noisy, duplicate로 분류합니다. 실제로 사람이 조치를 취한 알림은 유지하거나 개선합니다. 항상 자동 회복되고 조치가 없었던 알림은 대시보드 지표로 내립니다. 같은 원인을 여러 알림이 동시에 알려준다면 대표 알림 하나로 줄이고 나머지는 context로 연결합니다.
임계값도 고정값으로 방치하면 안 됩니다. 트래픽이 두 배가 되면 정상 지표 범위도 달라질 수 있습니다. 배치 시간대와 피크 시간대가 다른 서비스라면 시간대별 기준이 필요할 수 있습니다. SLO 기반 알림은 이런 문제를 줄여줍니다. 사용자 영향과 오류 예산 소모를 기준으로 알림을 만들면 단순 인프라 지표보다 행동 가능성이 높아집니다.
알림 설명도 함께 관리해야 합니다. 알림 이름만 보고 담당자가 무엇을 해야 하는지 알 수 없다면 좋은 알림이 아닙니다. 알림에는 영향, 가능한 원인, 첫 확인 대시보드, 완화 조치, 에스컬레이션 기준이 있어야 합니다. 이 정보가 runbook으로 연결되어 있으면 신규 온콜도 덜 흔들립니다.
5. 회고 과제는 닫히지 않으면 의미가 없다
장애 회고에서 좋은 이야기가 많이 나와도 개선 과제가 닫히지 않으면 다음 장애는 비슷하게 반복됩니다. 회고 문서의 마지막에는 반드시 action item 목록이 있어야 하고, 각 항목에는 담당자, 기한, 완료 조건이 있어야 합니다. "모니터링 개선"은 완료 조건이 아닙니다. "checkout-api 5xx burn rate 알림 추가 후 staging 장애 훈련으로 검증"처럼 확인 가능한 문장이어야 합니다.
과제 우선순위도 정해야 합니다. 모든 개선을 즉시 할 수는 없습니다. 사용자 영향이 컸던 원인, 탐지 지연을 만든 원인, 복구를 늦춘 원인을 우선합니다. 근본 원인을 완전히 제거하기 어려운 경우에도 탐지와 완화 시간을 줄이는 과제는 가치가 있습니다. 예를 들어 외부 결제사의 장애를 막을 수는 없지만, circuit breaker와 fallback 안내로 사용자 영향을 줄일 수 있습니다.
회고 과제는 일반 제품 백로그와 섞이면 밀리기 쉽습니다. 운영 개선 lane을 따로 두거나, 다음 스프린트 용량의 일정 비율을 회고 과제에 예약하는 방식이 필요합니다. 같은 장애 유형이 반복되면 단일 팀의 문제가 아니라 조직의 우선순위 문제일 수 있습니다. 장애 회고는 문서가 아니라 실행 체계와 연결되어야 합니다.
완료 후에는 효과를 검증해야 합니다. 알림을 추가했다면 실제로 테스트 알림이 울리는지, runbook을 수정했다면 다른 팀원이 따라 할 수 있는지, 자동 복구를 넣었다면 chaos test나 staging 훈련에서 동작하는지 확인합니다. 닫힌 과제가 실제 방어선으로 작동하는지 확인하지 않으면 회고 문서만 좋아집니다.
6. 장애 훈련은 runbook의 품질을 드러낸다
Runbook은 실제 장애 전에는 완성도를 알기 어렵습니다. 그래서 정기적인 장애 훈련이 필요합니다. staging 환경에서 의도적으로 dependency timeout을 만들거나, queue consumer를 멈추거나, 잘못된 feature flag를 켜고 담당자가 runbook만 보고 복구할 수 있는지 확인합니다. 훈련은 팀을 시험하는 자리가 아니라 절차의 빈틈을 찾는 작업입니다.
훈련에서는 시간도 측정합니다. 탐지까지 걸린 시간, 원인 후보를 좁히는 시간, 완화 조치까지 걸린 시간, 정상화 확인까지 걸린 시간을 기록합니다. 이 숫자가 있어야 다음 개선이 실제로 효과가 있었는지 비교할 수 있습니다. 회고 문서가 좋아졌다는 느낌보다 MTTA와 MTTR이 줄었는지가 더 객관적입니다.
신규 온콜 담당자가 훈련에 참여하는 것도 중요합니다. 시스템을 오래 본 사람만 복구할 수 있다면 runbook이 아니라 개인 기억에 의존하고 있는 것입니다. 문서만 보고 따라 한 사람이 어디서 막혔는지 관찰하면 설명이 부족한 지점이 드러납니다. 이런 피드백은 실제 장애 전에 반영해야 합니다.
훈련 후에는 알림과 대시보드도 수정합니다. 알림은 울렸지만 대시보드가 원인 파악에 도움이 되지 않았을 수 있고, runbook 첫 단계가 실제 시스템 이름과 맞지 않을 수 있습니다. 작은 불일치를 평소에 고쳐두면 실제 장애에서 큰 지연을 줄일 수 있습니다.
7. 회고 문화는 비난 금지에서 끝나지 않는다
Blameless 회고는 책임을 없애자는 뜻이 아닙니다. 개인을 탓하는 대신 시스템의 약한 지점을 찾자는 뜻입니다. 누가 실수했는지보다 왜 그 실수가 배포까지 갔는지, 왜 자동 검증이 막지 못했는지, 왜 알림이 늦었는지를 봐야 합니다. 그래야 개선 과제가 개인 주의가 아니라 시스템 보강으로 이어집니다.
동시에 소유권은 분명해야 합니다. "우리 모두 조심하자"는 결론은 실행되지 않습니다. 특정 서비스의 알림 정리, runbook 갱신, 배포 가드 추가처럼 명확한 담당자가 있어야 합니다. 건강한 회고는 사람을 비난하지 않지만, 개선 책임은 흐리지 않습니다.
8. 반복 장애는 별도 문제로 승격한다
같은 유형의 장애가 두 번 이상 반복되면 개별 회고만으로는 부족합니다. 반복 장애는 별도 운영 과제로 승격해야 합니다. 같은 서비스에서 timeout이 반복되는지, 같은 배포 단계에서 rollback이 자주 발생하는지, 같은 외부 의존성이 계속 문제를 만드는지 묶어서 봐야 합니다. 단건 회고에서는 보이지 않던 패턴이 반복 분석에서 드러납니다.
반복 장애에는 더 강한 조치가 필요합니다. 단순 문서 보강이 아니라 자동화된 배포 차단, circuit breaker, capacity 증설, 소유 팀 조정, SLA 재협상 같은 구조적 개선이 필요할 수 있습니다. 팀이 바쁘다는 이유로 반복 장애를 방치하면 온콜 피로와 사용자 불신이 누적됩니다.
반복 장애 지표를 운영 회의에서 정기적으로 보는 것도 효과적입니다. 장애 수보다 같은 원인의 반복 횟수, 재발까지 걸린 시간, 이전 회고 과제 완료 여부를 보는 편이 실질적입니다. 회고의 목적은 문서를 남기는 것이 아니라 재발률을 낮추는 것입니다.
9. 회고 문서는 검색 가능한 지식이어야 한다
장애 회고가 쌓이면 그것 자체가 운영 지식베이스가 됩니다. 제목에는 서비스명과 증상을 넣고, 태그에는 원인 유형과 영향 범위를 남기는 것이 좋습니다. 예를 들어 payment, timeout, dependency, rollback 같은 태그가 있으면 나중에 비슷한 장애가 났을 때 이전 사례를 빠르게 찾을 수 있습니다. 회고 문서가 채팅 로그 어딘가에 묻히면 같은 분석을 반복하게 됩니다.
문서에는 최종 원인뿐 아니라 틀렸던 가설도 남길 가치가 있습니다. 장애 중에 왜 특정 가설을 의심했고, 어떤 증거로 배제했는지 기록하면 다음 대응자가 시간을 아낄 수 있습니다. 운영 지식은 성공한 조치만이 아니라 시행착오까지 포함할 때 더 유용합니다.
결론: 장애 대응은 기억력이 아니라 시스템이다
좋은 팀은 장애가 없는 팀이 아닙니다. 장애를 빨리 발견하고, 덜 흔들리며 복구하고, 같은 종류의 실패를 줄이는 팀입니다. 이를 위해서는 행동 가능한 알림, 실제로 따라 할 수 있는 runbook, 비난 없는 회고, 닫히는 개선 과제가 필요합니다.
장애는 언제든 다시 옵니다. 하지만 같은 장애가 같은 방식으로 반복된다면 그것은 운이 아니라 운영 시스템의 문제입니다. 회고와 runbook은 그 반복을 끊기 위한 가장 현실적인 도구입니다.