서비스 장애 학습회 — 형식이 바뀌는 이유

장애가 나면 두 가지를 해야 한다. 당장 복구하는 것, 그리고 같은 일이 반복되지 않도록 배우는 것. 첫 번째는 긴급하니까 한다. 두 번째는 하기로 마음먹어야 한다.

우리 팀은 두 번째를 “장애 학습회”라고 부른다. 이 자리의 형식을 여러 번 바꿨다. 왜 바뀌었는지를 정리하는 게 이 글의 목적이다.

처음 형식: 타임라인 중심

첫 번째 형식은 “언제 무슨 일이 있었는가”를 시간 순으로 정리하는 방식이었다. 어느 시각에 알람이 왔고, 어느 시각에 원인을 찾았고, 어느 시각에 복구됐는지를 문서화했다.

유용했다. 특히 여러 명이 동시에 대응한 경우, 각자 본 것을 맞춰보는 데 도움이 됐다. 그러나 타임라인 정리가 끝나면 대화가 멈추는 경우가 많았다. “그래서 앞으로 어떻게?”로 자연스럽게 넘어가지 않았다.

두 번째 형식: 5-Why 추가

원인 분석을 구조화하기 위해 5-Why를 추가했다. “왜 장애가 났는가?”를 다섯 번 반복해서 근본 원인에 가까워지는 방법이다.

이론적으로는 좋았다. 그런데 실제로 해보니 “왜”를 다섯 번 파고들다가 결론이 “더 꼼꼼하게 확인해야 한다”나 “프로세스를 강화해야 한다” 같은 막연한 곳으로 흘러가는 경우가 잦았다. 특정 사람의 실수가 근본 원인처럼 보이는 방향으로 흘러가는 분위기도 불편했다.

세 번째 형식: 시스템 관점 전환

가장 크게 바꾼 건 관점이었다. 장애의 원인을 사람에게서 찾지 않고 시스템에서 찾는 원칙을 명시적으로 세웠다.

“누가 잘못했나”가 아니라 “어떤 환경이 이 실수를 가능하게 했는가”를 묻는 방식으로 바뀌었다. 같은 사람이 같은 상황에 처하면 같은 실수를 할 수 있다. 시스템이 바뀌어야 반복이 막힌다.

이 관점 전환이 가장 효과적이었다. 책임 추궁이 없어지니 공유가 편해졌고, 개선 항목이 구체적인 코드나 설정 변경으로 이어지는 경우가 늘었다.

지금 형식

지금은 세 가지 질문으로 구성한다. 무슨 일이 있었는가(타임라인), 이것을 가능하게 한 시스템의 조건은 무엇이었는가(시스템 분석), 다음 번에 같은 일이 생기기 어렵게 하려면 무엇을 바꿔야 하는가(개선 항목).

개선 항목은 반드시 담당자와 기한을 붙인다. 붙이지 않으면 흐지부지된다.

형식이 바뀐 이유는 단순하다. 팀이 실제로 배우는 방식이 달라졌기 때문이다. 형식은 목적을 위한 도구다. 목적에 맞지 않으면 바꾸면 된다.

— by mings