postmortem

postmortem skill 개요

postmortem skill이 하는 일

postmortem skill은 실패한 출시, 미달한 목표, 잘못된 채용, 놓친 딜, 운영 장애를 비난 없는 근본 원인 분석으로 전환하도록 돕는 경영진 멘토형 워크플로입니다. 에이전트가 사건을 정확히 정의하고, 체계적인 5-Whys 질문을 거치며, 변경 등록부를 만들도록 안내합니다. 그 결과물은 단순한 “교훈 정리”가 아니라 실행 가능한 시스템 개선 목록이 됩니다.

리더십과 Quality Management에 가장 잘 맞는 경우

이 postmortem skill은 계획과 실제 결과가 왜 달라졌는지 이해해야 하는 창업자, 임원, 운영 리더, 제품 리더, 엔지니어링 매니저, Quality Management 팀에 특히 유용합니다. 처벌이 아니라 재발 방지와 프로세스 개선이 목표인 상황에 적합합니다. Quality Management 용도의 postmortem에서는 실패를 통제 항목, 담당자, 측정 가능한 후속 조치로 바꾸는 데 가장 큰 가치가 있습니다.

일반 프롬프트와 다른 점

일반적인 “무엇이 잘못됐는지 분석해줘” 프롬프트는 대개 폭넓은 논평에 그치기 쉽습니다. 이 skill은 더 좁고 운영 중심적입니다. 사건을 명확히 정의하게 하고, 증상과 원인을 구분하며, 희생양 찾기를 피하게 하고, 어떤 조건이 실패 가능성을 높였는지 묻습니다. 핵심 차별점은 change register로, 인사이트를 담당자, 기한, 시스템 수준의 수정으로 전환하도록 돕습니다.

도입 전에 알아둘 점

저장소 경로에는 단일 SKILL.md만 있으며, 보조 스크립트, 참조 자료, 메타데이터 파일은 없습니다. 그래서 postmortem 설치는 가볍지만, 동시에 사용자가 제공하는 맥락의 품질에 크게 의존합니다. 진지한 회고를 뒷받침할 만큼 충분한 사실 관계를 공유할 수 있을 때 사용하세요. 사건이 아직 조직 내 정치적으로 안전하지 않거나, 법적으로 민감하거나, 소문에만 기반한 경우에는 피하는 편이 좋습니다.

postmortem skill 사용 방법

postmortem 설치와 확인할 파일

GitHub skill 소스에서 다음 명령으로 설치합니다.

npx skills add alirezarezvani/claude-skills --skill postmortem

소스 위치는 다음과 같습니다.

c-level-advisor/executive-mentor/skills/postmortem/SKILL.md

먼저 SKILL.md를 읽어보세요. 이 파일에 전체 운영 모델이 들어 있습니다. 맞춰 봐야 할 별도의 rules/, resources/, references/, scripts/ 폴더는 없으므로, 설치 여부를 판단할 때 핵심은 이 단일 파일 워크플로가 여러분의 회고 방식과 맞는지입니다.

실제로 skill을 호출하는 방법

이 skill은 다음과 같은 명령 패턴을 기준으로 설계되어 있습니다.

/em:postmortem <event>

약한 호출 예시는 다음과 같습니다.

/em:postmortem Q3 release slipped

더 좋은 호출은 에이전트가 사실, 가정, 원인을 구분할 수 있을 만큼 충분한 자료를 제공합니다.

/em:postmortem The Q3 enterprise release shipped six weeks late. Expected: public launch by Sep 15 with SOC2-ready audit logging. Actual: launch moved to Oct 27, two pilot customers delayed contracts, and support handled 43 escalation tickets. Timeline: scope expanded Aug 8, QA found permission bugs Sep 3, final security review failed Sep 12. Please run a blameless 5-Whys analysis and produce a change register with owners, preventive controls, and follow-up metrics.

postmortem 활용도를 높이는 입력 정보

postmortem을 잘 활용하려면 기대 결과, 실제 결과, 타임라인, 최초 경고 신호, 영향, 주요 의사결정, 제약 조건, 당시 알고 있던 정보를 제공하세요. 정량적 근거와 사람·조직 맥락을 함께 포함하는 것이 좋습니다. 예를 들어 매출 차이, 결함 수, 채용 일정, 놓친 마일스톤, 고객 영향, 의사결정 책임자, 승인 병목, 상충하는 우선순위 등을 넣을 수 있습니다.

skill에 “누가 이 일을 일으켰는지 찾아줘”라고 요청하지 마세요. 대신 불명확한 오너십, 약한 에스컬레이션 경로, 비현실적인 계획 가정, 빠진 품질 게이트, 인센티브 충돌, 늦은 리스크 가시화 같은 시스템 조건을 식별해 달라고 요청하는 편이 좋습니다.

유용한 결과물을 얻기 위한 권장 워크플로

먼저 사실 기반의 사건 요약으로 시작한 뒤, 첫 postmortem 초안을 요청하세요. 5-Whys 흐름이 너무 일찍 멈추거나, 설명하기 쉬운 원인으로 성급히 건너뛰지는 않았는지 검토합니다. 그런 다음 근거를 더해 반복하세요. 예를 들면 “Pressure-test the root cause against the timeline,” “Separate controllable causes from external shocks,” 또는 “Convert these lessons into a change register suitable for the next exec review.”처럼 요청할 수 있습니다.

가장 좋은 최종 산출물에는 보통 사건 정의, 영향 요약, 기여 요인, 근본 원인, 원인이 아닌 것들, 당시에는 합리적으로 보였던 의사결정, 권장 시스템 변경 사항, 담당자, 기한, 검증 지표가 포함됩니다.

postmortem skill FAQ

postmortem은 초보자에게도 적합한가요?

네, 사용자가 명확한 사건 설명을 제공할 수 있다면 적합합니다. 이 skill의 구조 덕분에 정식 회고 방법론을 미리 잘 알고 있지 않아도 됩니다. 초보자는 호출 전에 짧은 타임라인과 기대 대비 실제 결과의 차이를 준비하는 것이 좋습니다. 그렇지 않으면 모델이 부족한 맥락을 그럴듯하지만 검증되지 않은 가정으로 채울 수 있습니다.

언제 이 skill을 사용하지 말아야 하나요?

성과 평가, 징계 도구, 법적 조사, 공개 사고 성명서로는 인간 검토 없이 사용하지 마세요. 리더십이 불편한 인과 분석이 아니라 보기 좋게 정리된 이야기만 원하는 경우에도 잘 맞지 않습니다. 조직이 발견 사항을 실행에 옮길 수 없다면 postmortem은 개선보다 좌절을 만들 수 있습니다.

incident review와는 어떻게 다른가요?

incident review는 보통 기술 서비스 장애와 운영 복구에 초점을 맞춥니다. 이 postmortem skill은 범위가 더 넓습니다. 놓친 분기 목표, 실패한 출시, 잘못된 채용, 놓친 딜, 제품 실패, 리더십 의사결정까지 모두 다룰 수 있습니다. Quality Management를 지원할 수는 있지만, 자격 있는 검토자가 조정하지 않는 한 규제 대상 CAPA, 감사, 컴플라이언스 문서를 대체하지는 않습니다.

특정 생태계가 필요한가요?

아니요. 이 skill은 일반 markdown으로 되어 있으며, 위 명령을 사용해 호환되는 skills 워크플로에 설치할 수 있습니다. 스크립트나 외부 자산이 없기 때문에 비즈니스, 제품, 엔지니어링, 운영 맥락 전반에서 이식성이 좋습니다. 다만 그 대가로 대시보드, 티켓 시스템, incident log를 자동으로 가져오지는 않습니다. 관련 근거는 직접 요약하거나 붙여 넣어야 합니다.

postmortem skill 개선 방법

postmortem에 더 좋은 원자료 제공하기

postmortem 결과를 가장 빠르게 개선하는 방법은 압축된 근거 패키지를 제공하는 것입니다. 목표, 실제 결과, 타임라인, 의사결정 지점, 놓친 신호, 제약 조건, 이해관계자, 영향, 기존 가설을 포함하세요. 불확실한 주장은 명확히 표시해야 합니다. 예를 들면 다음과 같습니다. “Confirmed: QA blocked release on Sep 12. Hypothesis: sales pressure caused scope expansion. Unknown: whether engineering estimated the new scope.”

흔한 실패 패턴 점검하기

가장 흔한 실패는 “커뮤니케이션 부족”이나 “오너십 부재”처럼 얕은 근본 원인에 머무는 것입니다. 에이전트에게 한 단계 더 깊이 들어가 달라고 요청하세요. 어떤 구조 때문에 커뮤니케이션이 실패했는가? 왜 오너십이 불명확했는가? 왜 계획 프로세스가 그런 모호성을 허용했는가? 또 다른 실패 패턴은 너무 많은 액션 아이템으로 과잉 교정하는 것입니다. 담당자가 명확하고, 관찰 가능하며, 재발 방지 가능성이 높은 소수의 변경 사항에 집중하도록 유도하세요.

발견 사항을 change register로 전환하기

강력한 change register에는 변경 사항, 해당 변경이 다루는 근본 원인, 담당자, 기한, 성공 지표, 검토 주기가 들어가야 합니다. Quality Management 용도로는 통제 유형, 검증 방법, 필요한 증거를 추가하세요. 이렇게 하면 리더십 리뷰, 분기 계획, 릴리스 거버넌스, 채용 프로세스 변경, 지속적 개선 프로그램에서 skill의 결과물을 더 쉽게 운영에 반영할 수 있습니다.

첫 답변 이후 반복 개선하기

첫 초안이 나온 뒤에는 구체적인 후속 질문을 던지세요. “Which conclusions are evidence-backed versus inferred?”, “What would have prevented this without slowing the team unnecessarily?”, “What early warning metric should we add?”, 또는 “Rewrite the change register for executive accountability.”처럼 물어볼 수 있습니다. postmortem skill은 한 번에 보고서를 뽑아내는 도구가 아니라, 구조화된 조사 파트너로 다룰 때 가장 잘 작동합니다.