같은 장애가 왜 반복될까요? 많은 조직이 장애를 경험하고, 복구하고, 다시 같은 장애를 만납니다. 이것은 담당자의 실수가 아니라 구조의 문제입니다.
장애 후 무슨 일이 일어나는가
대부분의 조직에서 장애 대응은 이렇게 끝납니다.
- 장애 발생 → 긴급 대응 → 복구
- 원인 파악 → "이번엔 OO 때문이었다"
- 다음으로 넘어감
복구가 완료되는 순간, 장애는 과거가 됩니다. 무엇이 문제였는지 공식적으로 기록되지 않고, 같은 상황을 막기 위한 변경도 이루어지지 않습니다. 그리고 몇 달 후 유사한 장애가 다시 발생합니다.
반복을 만드는 구조
장애가 반복되는 데는 세 가지 구조적 이유가 있습니다.
원인이 아닌 증상을 고친다. 서비스가 느려진다 → 서버를 재시작한다. 재시작하면 일시적으로 해결되지만, 왜 느려졌는지는 알 수 없습니다. 증상 해결에 집중하면 원인은 그대로 남습니다.
지식이 개인에게 머문다. 장애를 해결한 담당자는 무엇이 문제였는지 압니다. 그러나 그 지식은 그의 머릿속에 있습니다. 기록되지 않으면 전달되지 않고, 다른 사람이 같은 상황을 만났을 때 처음부터 다시 시작해야 합니다.
재발 방지 조치가 없다. "앞으로 조심하자"는 재발 방지가 아닙니다. 같은 상황이 발생하지 않도록 시스템이나 프로세스를 바꾸는 것이 재발 방지입니다. 그 변경이 이루어지지 않으면 장애는 다시 옵니다.
Post-mortem 없는 조직
Post-mortem(사후 분석)은 장애 이후 체계적으로 원인을 분석하고 재발 방지 조치를 정하는 과정입니다. 많은 조직에서 이 과정이 없거나 형식적입니다.
Post-mortem이 작동하지 않는 이유는 대개 두 가지입니다.
첫째, 책임 추궁의 두려움. 장애 원인을 솔직하게 쓰면 누군가를 비난하는 것처럼 보입니다. 그래서 원인 분석이 모호해집니다. "시스템 오류" "예상치 못한 트래픽"으로 끝납니다.
둘째, 시간 없음. 장애를 복구하고 나면 밀린 업무가 기다리고 있습니다. Post-mortem은 나중으로 미뤄지고, 결국 하지 않게 됩니다.
반복을 끊는 방법
장애 반복을 구조적으로 끊으려면 세 가지가 필요합니다.
원인 추적 기록. 장애 발생 시 무엇이 변경됐는지, 어떤 순서로 대응했는지, 실제 원인이 무엇이었는지를 기록합니다. 이 기록이 쌓이면 패턴이 보입니다.
비난 없는 분석 문화. 장애는 개인의 잘못이 아니라 시스템의 취약점입니다. 분석의 목적은 책임자 찾기가 아니라 취약점 제거입니다. 이 문화가 없으면 Post-mortem은 형식에 그칩니다.
조치 항목의 추적. 재발 방지 조치는 누군가가 언제까지 무엇을 한다는 구체적 항목이어야 합니다. 그리고 실제로 완료됐는지 추적해야 합니다. 조치 항목이 완료되지 않으면 분석은 의미가 없습니다.
장애 반복은 담당자의 부주의가 아닙니다. 분석하지 않고, 기록하지 않고, 바꾸지 않는 구조가 반복을 만듭니다. 구조를 바꾸면 장애의 패턴이 달라집니다.