SRE 실무 #5 포스트모템: 비난 없는 회고와 액션 아이템의 사후 관리

장애는 반드시 다시 납니다. 조직이 선택할 수 있는 것은 장애의 유무가 아니라, 같은 장애를 반복할 것인가 매번 새로운 장애를 만날 것인가입니다. 이 갈림길을 결정하는 제도가 포스트모템(postmortem, 사후 분석)입니다. 이번 편은 포스트모템을 형식적 보고서가 아니라 실제 학습 장치로 작동시키는 방법을 다룹니다.

비난 없음은 온정주의가 아니라 정보 전략입니다 #

포스트모템의 제1원칙은 비난 없음(blameless)입니다. 장애에 관여한 개인을 지목하고 문책하지 않는다는 원칙인데, 이것을 “착하게 굴자"로 이해하면 본질을 놓칩니다. 이유는 냉정하게 실용적입니다.

비난이 있는 조직에서는 정보가 사라집니다. 명령어를 잘못 입력한 사람이 문책당하는 문화라면, 다음 장애에서 그 사람은 자신이 아는 것을 말하지 않습니다. 타임라인은 부정확해지고, 원인 분석은 겉돌고, 같은 장애가 다시 납니다. 비난 없음은 정확한 정보를 얻기 위해 지불하는 값입니다.

그리고 논리적인 근거가 하나 더 있습니다. 사람의 실수가 가능했다는 것 자체가 시스템의 결함입니다. “A가 프로덕션에서 잘못된 명령을 실행했다"에서 멈추면 액션 아이템은 “A가 조심한다"가 됩니다. 이것은 재발 방지가 아닙니다. 올바른 질문은 다음으로 이어집니다. 왜 프로덕션에서 그 명령이 실행 가능했는가? 왜 확인 절차가 없었는가? 왜 되돌리기가 어려웠는가? 답이 시스템 개선(권한 분리, 확인 프롬프트, 롤백 자동화)에 도달할 때까지 “왜"를 반복하는 것이 원인 분석의 방법론입니다.

언제 쓰는가: 트리거를 미리 정합니다 #

모든 이슈에 포스트모템을 쓰면 제도가 형식화되고, 기준이 없으면 큰 장애도 슬쩍 넘어갑니다. 트리거를 명문화합니다. 일반적인 기준은 이렇습니다.

• 사용자 영향이 SLO 버짓의 일정 비율(예: 28일 버짓의 10%)을 넘게 소모한 장애
• 데이터 유실 또는 오염이 발생한 모든 사건
• 온콜 에스컬레이션이 상위 체계까지 올라간 장애
• 영향과 무관하게, 대응 과정에서 도구·절차의 결함이 드러난 경우 (아차 사고 포함)

마지막 항목이 중요합니다. 실제 피해가 없었던 아차 사고(near miss)는 가장 싼 수업료로 같은 교훈을 주는 기회입니다.

템플릿: 타임라인이 뼈대입니다 #

포스트모템 문서의 표준 구성은 다음과 같습니다.

타임라인을 쓸 때의 요령은 당시에 알던 것과 지금 아는 것을 구분하는 것입니다. “22:14, 대시보드에서 에러율 상승 확인. 이 시점에는 배포와의 연관을 몰랐음"처럼 쓰면, 나중에 읽는 사람이 “왜 바로 롤백을 안 했지?“라는 결과론적 비난 대신 “이 시점에 연관을 알 수 있게 하려면 무엇이 필요했나"라는 생산적 질문으로 갑니다.

또 하나, 영향 섹션에서 에러 버짓과 연결합니다. “이 장애로 버짓의 40%가 소모됐다"는 문장은 이 장애의 후속 작업이 왜 로드맵보다 우선인지를 숫자로 설명해 줍니다.

액션 아이템: 포스트모템의 성패가 갈리는 곳 #

포스트모템 제도가 죽는 경로는 정해져 있습니다. 회고는 잘 썼는데 액션 아이템이 백로그 밑바닥에 가라앉고, 반년 뒤 같은 장애가 나고, 지난 문서를 열어 보니 정확히 그 재발 방지책이 미완료로 남아 있는 경로입니다. 이를 막는 규칙은 단순하지만 강제력이 필요합니다.

• 모든 액션 아이템에 소유자 한 명과 기한을 붙입니다. “팀에서 검토"는 소유자가 아닙니다.
• 우선순위를 구분합니다. 재발을 직접 막는 항목(P0)과 개선이면 좋은 항목(P1 이하)을 나누고, P0는 스프린트에 즉시 편성합니다.
• 완료율을 주기적으로 점검합니다. 월간 운영 리뷰에서 “지난 분기 포스트모템 액션 아이템 완료율"을 보는 것만으로 방치가 크게 줄어듭니다.
• 액션 아이템을 무한정 쌓지 않습니다. 장애 하나에 30개의 액션 아이템은 아무것도 안 하겠다는 뜻과 같습니다. 재발 방지에 직접 기여하는 소수로 압축합니다.

공유: 문서는 읽힐 때만 자산입니다 #

다 쓴 포스트모템은 팀 폴더에 넣고 끝이 아닙니다. 조직 전체가 열람할 수 있는 저장소에 모으고, 큰 사건은 리뷰 회의에서 함께 읽습니다. 다른 팀의 장애에서 자기 시스템의 같은 약점을 발견하는 것이 포스트모템 공유의 실질 효용입니다. 신규 입사자에게 대표 포스트모템 몇 편을 온보딩 자료로 주는 조직도 있습니다. 시스템의 실제 약점과 대응 문화를 이보다 잘 보여 주는 문서는 없습니다.

정리 #

• 비난 없음은 정확한 정보를 얻기 위한 전략입니다. 비난이 있는 곳에서 타임라인은 거짓말을 시작합니다.
• 사람 실수에서 분석을 멈추지 않습니다. 그 실수가 가능했던 시스템 결함에 도달할 때까지 “왜"를 반복합니다.
• 포스트모템 트리거(버짓 소모율, 데이터 유실, 아차 사고)를 미리 명문화합니다.
• 타임라인은 당시 알던 정보를 기준으로 쓰고, 영향은 에러 버짓으로 정량화합니다.
• 성패는 액션 아이템 추적에서 갈립니다. 소유자·기한·우선순위를 강제하고 완료율을 리뷰합니다.
• 다음 편은 시리즈 마지막으로, 반복 수작업(토일)을 측정하고 자동화로 갚아 가는 법입니다.