포스트모템이 문화가 되면 장애가 준다: blame-free 리뷰와 재발 방지 액션아이템 작성법

장애는 끝났는데, 팀은 더 지치는 이유가 있다

장애가 복구된 뒤에 더 큰 문제가 시작되는 경우가 있다.

원인 찾기가 "사람 찾기"로 바뀌고, 회의는 길어지며, 다음 장애 때는 모두가 방어적으로 변한다.

이런 분위기에서는 같은 유형의 장애가 반복되고, 복구 시간은 오히려 늘어난다.

현장에서 자주 보이는 장면은 다음과 같다.

11:08 알림: API 5xx 비율 6.2% (지속 4분)
11:12 문의: "결제 완료 후 주문 화면이 비어 있다"
11:19 완화: 일부 트래픽 우회(임시)
11:37 복구: 설정 롤백 후 정상화
11:50 회고: "누가 배포했지?"로 시작 → 결론 없음
다음 주: 유사한 장애 재발(원인 후보 동일)

오해가 하나 있다.

장애가 줄어드는 것은 "포스트모템 문서가 존재함"이 아니라 "포스트모템이 반복 가능한 습관으로 굳어짐"에서 나온다.

blame-free 포스트모템이 재발을 줄이는 순환 구조

핵심 개념 2개: blame-free와 액션아이템을 분리해 읽는다

개념 1) blame-free 리뷰

정의: 사람의 탓을 묻는 대신, 관측된 사실과 시스템의 조건을 기준으로 장애 흐름을 재구성하는 리뷰 방식이다.

핵심 특징: "누가 했나"보다 "어떤 조건에서 이런 선택이 자연스러웠나"를 먼저 다룬다.

핵심 특징: 개인의 실수를 지우는 것이 아니라, 실수가 발생해도 피해가 커지지 않게 만드는 장치를 찾는다.

주의점: 책임이 사라지는 방식으로 오해되면 실행력이 떨어진다.

책임을 "비난"이 아니라 "소유권(누가 개선을 끝낼 것인가)"로 다시 정의해야 한다.

개념 2) 재발 방지 액션아이템

정의: 다음에는 같은 장애가 발생하지 않도록 시스템에 변화를 만드는 구체적 작업 항목이다.

핵심 특징: 측정 가능한 완료 조건이 있고, 담당자와 기한이 고정되어 있다.

핵심 특징: 작업이 끝났는지 아닌지가 도구(이슈 트래커, PR, 대시보드)에서 확인 가능하다.

주의점: "주의한다", "공유한다" 같은 문장은 실행이 끝났는지 판별하기 어렵다.

근본 원인을 "원인 1개"로 단정하면, 다른 경로로 재발하는 장애를 놓치기 쉽다.

문화가 되지 못한 포스트모템의 흔한 패턴과 교정 포인트

포스트모템이 매번 작성되는데도 장애가 줄지 않는 경우가 있다.

대부분 문서의 분량 문제가 아니라, 문서가 "결정과 실행"을 만들지 못하는 구조에 있다.

비교 항목	형식만 남은 포스트모템	문화로 굳는 포스트모템
대화의 출발점	배포자/담당자 추궁	타임라인과 관측 사실
원인 서술	"실수했다"로 끝난다	조건·가정·가시성 부족을 포함한다
액션아이템	추상적(주의, 공유)	측정 가능(알림/테스트/가드레일)
완료 판정	회의 후 잊힌다	이슈 상태/대시보드로 확인한다

blame-free는 "따뜻한 말"이 아니라 "사실 기반 구조"로 유지된다.

사실 기반 구조가 없으면 리뷰는 감정과 기억력 싸움으로 흐르기 쉽다.

실전 확인 절차: "확인→완화→복구→검증"을 포스트모템 문서로 고정한다

포스트모템을 처음 만들 때 가장 효과적인 방법은 장애 대응 흐름을 문서의 뼈대로 고정하는 것이다.

특정 툴을 쓰더라도, 경로와 체크 포인트를 문장으로 남기면 다음 장애에서 그대로 복사해 쓸 수 있다.

1. 경로: 인시던트 채널(메신저/협업툴) → 타임스탬프가 남는 대화/결정 로그 수집
2. 체크 포인트: "누가 무엇을 말했나"가 아니라 "언제 어떤 결정이 내려졌나"만 추출한다.
3. 경로: 모니터링 대시보드 → 서비스 선택 → 에러율/지연시간/트래픽 패널 확인
4. 체크 포인트: 장애 시작 시각과 지표 변화의 선후관계를 캡처로 고정한다.
5. 경로: 로그/에러 트래킹 → 오류 코드/에러 메시지 상위 N개 확인
6. 체크 포인트: "가장 많이 터진 에러 1개"와 "가장 비용이 큰 에러 1개(지연/타임아웃)"를 분리해 적는다.
7. 경로: 배포 기록 → 릴리즈/PR 목록 확인 → 장애 시작 시각 전후 변경점 비교
8. 체크 포인트: 변경점이 직접 원인인지, 단지 촉발 조건인지 구분해 기록한다.
9. 경로: 조치 목록 정리 → 완화(피해 축소)와 복구(정상 회복)로 구분
10. 체크 포인트: 완화가 언제 적용되었고, 지표가 언제 꺾였는지를 같이 남긴다.
11. 경로: 검증 단계 정의 → 성공 조건(수치/사용자 흐름) 2종 작성
12. 체크 포인트: "지표 정상 + 사용자 경로 1회 성공"으로 종료 조건을 고정한다.

이 절차를 따르다 보면, 포스트모템의 뼈대가 자연스럽게 "확인→완화→복구→검증"으로 정리된다.

포스트모템 작성 흐름도(사실 수집→원인 후보→액션아이템→추적)

액션아이템이 살아남는 작성법: ‘측정 가능’과 ‘가드레일’로 끝낸다

재발 방지 항목이 실제로 실행되려면, 문장이 "완료 판정"을 품고 있어야 한다.

다음은 자주 실패하는 문장과, 실행까지 이어지는 문장의 차이다.

# 실패하기 쉬운 문장
- 배포 시 더 주의한다
- 로그를 더 잘 남긴다
- 리뷰를 강화한다

# 실행까지 이어지는 문장(완료 판정 포함)
- 배포 전 체크리스트에 "DB 마이그레이션 플래그" 항목을 추가하고, 미통과 시 배포를 막는다
- 5xx가 2%를 넘으면 자동으로 인시던트 채널을 생성하고 담당자에게 알림을 보낸다
- 결제 API의 타임아웃 로그를 request_id로 추적 가능하도록 필드를 추가하고 대시보드에 패널을 만든다

액션아이템의 형태는 크게 두 종류가 있다.

• 가시성 개선: 관측 지표/로그/알림을 보강해 "늦게 알아차리는 문제"를 줄인다
• 가드레일 추가: 배포/설정/권한/리소스에 안전장치를 넣어 "실수해도 크게 번지지 않게" 만든다

YES/NO로 빠르게 점검하면 액션아이템의 품질이 갈린다.

• YES: 완료 조건이 한 줄로 판정 가능하다(대시보드 패널 생성, 테스트 추가, 알림 룰 적용)
• YES: 담당자 1명과 마감일 1개가 고정되어 있다
• YES: 실제 변경점이 남는다(PR, 설정 변경, 런북 업데이트)
• NO: "주의/공유/신경" 같은 표현으로 끝난다
• NO: 원인만 적고, 시스템 변화가 없다
• NO: 완료 여부를 확인할 경로가 없다

실전 예시 1개: blame-free 리뷰가 액션아이템으로 이어지는 흐름

문제: 결제 요청의 타임아웃이 증가하면서 5xx 비율이 6%까지 상승했고, 고객 문의가 급증했다.

왜 발생: 외부 결제 연동 지연이 늘었지만, 내부 재시도 로직이 동시에 작동하며 큐 적체가 확대되었다.

어떤 선택이 적합: 단기에는 재시도 횟수 제한과 임시 우회로 완화하고, 장기에는 타임아웃/서킷브레이커/관측 필드를 추가하는 조합이 맞다.

잘못 쓰면 어떤 문제: 사람의 실수로 결론을 내리면, 외부 지연이 다시 오면 같은 방식으로 다시 터진다.

확인/해결: 대시보드에서 타임아웃과 지연시간 변화를 고정하고, 로그에서 타임아웃 문구와 요청량 급증을 확인한 뒤, 가드레일 중심 액션아이템으로 전환한다.

관측 조각 예:
- timeout 로그: 1분당 150건 (평시 5건)
- 큐 적체: backlog 0 → 9,200
- 대응: 재시도 3회 → 1회로 제한(완화), 서킷브레이커 도입(복구/재발 방지)

배포/운영 체크리스트: 액션아이템이 ‘완료’로 끝나게 만드는 장치

포스트모템이 문화가 되려면, 액션아이템을 운영 루틴에 끼워 넣어야 한다.

• 이슈 트래커에 액션아이템을 "작업 티켓"으로 분리해 등록했는가
• 티켓마다 담당자 1명과 마감일 1개가 고정되어 있는가
• 완료 조건이 도구에서 확인 가능한가(PR 링크, 대시보드 링크, 알림 룰 링크)
• 배포 체크리스트/런북/온콜 핸드오버 문서에 반영되었는가
• 2주 또는 4주 단위로 "미완료 액션아이템"을 재검토하는 회의가 있는가

결론

blame-free 리뷰는 책임을 없애는 방식이 아니라, 사실 기반으로 시스템의 약점을 드러내는 방식이다.

재발 방지 액션아이템은 "측정 가능한 완료 조건"이 있을 때 실행으로 이어진다.

포스트모템이 문서가 아니라 습관이 되면, 같은 유형의 장애가 줄어들고 복구 속도가 빨라진다.

연계 주제 제안: 런북(runbook) 작성 요령과 온콜 핸드오버 체크리스트 설계가 함께 묶이면 실행력이 더 좋아진다.

FAQ

blame-free를 하면 책임 소재가 흐려지지 않나?

비난을 없애는 것과 소유권을 없애는 것은 다르다.

리뷰에서는 사실과 조건을 먼저 정리하고, 액션아이템에서는 담당자와 완료 조건으로 책임을 고정하는 방식이 맞다.

액션아이템을 몇 개까지 만드는 것이 적당한가?

처음에는 3~7개 정도가 실행 가능성이 높다.

너무 많으면 추적이 무너지고, 너무 적으면 재발 방지의 범위가 부족해지기 쉽다.

포스트모템은 언제 작성하는 것이 좋나?

복구 직후 바로 시작하되, 감정이 가라앉을 시간을 짧게 확보하는 편이 좋다.

타임라인과 관측 데이터가 남아 있을 때 작성하면 사실 기반으로 정리하기 쉬워진다.