시스템 장애가 발생하는 원인은 여러 가지가 있습니다. 그 원인은 사람의 실수일 수도 있고, 예상치 못한 시스템의 오류일 수도 있고, 피할 수 없는 자연재해일 수도 있죠. 어떤 원인으로 발생한 일이든

시스템 장애가 발생하는 원인은 여러 가지가 있습니다. 그 원인은 사람의 실수일 수도 있고, 예상치 못한 시스템의 오류일 수도 있고, 피할 수 없는 자연재해일 수도 있죠. 어떤 원인으로 발생한 일이든 이러한 실패에는 배울 점이 있기 마련입니다. 포스트모템(Postmortem)은 장애 원인 분석을 통해 실패에서 배울 점을 찾는 회의입니다. Postmortem은 ‘부검’이라는 뜻인데, 회의에 이런 이름을 붙인 건 그만큼 장애의 원인을 샅샅이 파헤친다는 의미입니다. 성공적인 포스트모템을 위해서는 아래 6가지 조건이 필요합니다. 1️⃣ 모든 관계자 초대하기. 포스트모템에서는 핵심적인 정보와 중요한 인사이트가 많이 논의되기 때문에 모든 관계자가 참석하는 게 바람직합니다. 2️⃣ 타임라인 분석하기. 장애가 발생한 상황과 그 대응 과정을 상세하게 기록합니다. 누가, 언제, 어떤 정보를 가지고, 어떤 결정을 내렸는지 시간 순서대로 분석하다 보면 장애가 발생한 근본적 원인을 찾아내는데 도움이 됩니다. 3️⃣ 잘된 일과 잘못된 일 모두 파악하기. 잘된 일은 모범 사례로 참고하고, 잘못된 일은 보완해야 할 시스템의 약점을 찾아내기 위해 파악합니다. 4️⃣ 개선책 도출하기. 장애의 근본적 원인을 찾아내기 위해 “why?”라는 질문을 최소 5번 반복합니다. 이렇게 해서 근본적 원인에 다다르게 되면 이에 대한 개선책을 도출합니다. 5️⃣ 회의에서 찾아낸 정보 공개하기. 이렇게 해서 찾아낸 정보를 조직 전체에 공개합니다. 시스템에 어떤 약점이 있었는지, 어떤 상황에서 이게 문제가 되었는지, 이를 어떻게 해결할 것인지 공유해서 다른 팀에서도 인사이트를 얻을 수 있도록 합니다.  6️⃣ 책임자를 비난하지 않기. 가장 중요한 점은 사람의 실수로 발생한 장애더라도 문제의 책임자를 비난하지 않아야 한다는 것입니다. 비난의 화살이 책임자에게 돌아간다면, 그 조직은 점점 책임을 회피하기 위해 정보를 숨기게 됩니다. 조직 차원에서 시스템을 개선하기 위해서는 비난하는 태도를 지양하고 정보 공유를 독려해야 합니다. 사실 이런 회의를 한다는 행위보다 더 중요한 건 ‘실수해도 괜찮다’는 구성원들의 마인드입니다. 누구나 실수는 할 수 있잖아요. 그럴 때 실수한 사람을 비난하는 건 아무 도움이 되지 않습니다. 환경을 개선해서 다음에 같은 실수를 반복하지 않도록 방지하는 것이 더 효과적이죠. 실수를 부정적으로 생각하기보다는 이를 배움의 기회로 삼는 문화가 자리잡기를 바랍니다. 📔 함께 읽으면 좋은 글 - 포스트모템과 회고: https://brunch.co.kr/@jihyun-um/25 위 내용은 유호현 님의 브런치 글 의 일부를 정리한 내용입니다.