postmortem-writing

postmortem-writing 스킬 개요

postmortem-writing가 하는 일

postmortem-writing 스킬은 에이전트가 구조화된 비난 없는(blameless) 인시던트 포스트모템을 작성하도록 돕습니다. 특히 압박이 큰 상황에서 팀이 자주 빠뜨리는 요소들, 즉 명확한 타임라인, 근본 원인 분석, 기여 요인, 영향 범위, 그리고 실제로 추적 가능한 후속 조치를 빠짐없이 담는 데 초점이 있습니다. 서비스 장애, 성능 저하, 아차 사고, 데이터 이슈 등 단순한 요약이 아니라 조직 차원의 학습이 필요한 사건 이후의 보고서 작성에 적합합니다.

postmortem-writing를 설치하면 좋은 사람

이 스킬은 특히 다음과 같은 경우에 잘 맞습니다:

• SRE, DevOps, 플랫폼, 인시던트 대응 팀
• 일관된 인시던트 보고서가 필요한 엔지니어링 매니저
• 장애 이후 내부 보고서 작성 업무를 맡는 실무자
• 비난 중심 회고에서 시스템 사고 중심 문화로 전환하려는 팀

지저분한 인시던트 메모를 실제로 쓸 수 있는 포스트모템 문서로 바꾸는 일이 핵심이라면, postmortem-writing은 범용 글쓰기 프롬프트보다 훨씬 목적에 맞게 설계된 선택지입니다.

실제로 해결해 주는 일

대부분의 사용자는 추상적으로 “문서를 잘 쓰는 법”이 필요한 것이 아닙니다. 필요한 것은 로그, 채팅 스레드, 알림, 불완전한 기억을 바탕으로 다음을 만족하는 보고서로 정리하는 일입니다:

• 무슨 일이 있었는지 평이한 언어로 설명하고
• 시간 순서를 보존하며
• 근본 원인과 기여 요인을 구분하고
• 개인 비난을 피하고
• 실제로 추적 가능한 액션 아이템으로 끝나는 문서

이 점이 바로 postmortem-writing 스킬의 실질적인 가치입니다.

일반 프롬프트와 다른 점

이 스킬의 차별점은 화려한 자동화가 아닙니다. 핵심은 편집 구조와 인시던트 리뷰 원칙입니다. 소스 자료에서 특히 강조하는 부분은 다음과 같습니다:

• 비난 없는 서술 방식
• 언제 포스트모템이 필요한지에 대한 명시적 기준
• 타임라인 우선 워크플로
• 표면 증상이 아닌 근본 원인 분석
• 나중에 덧붙이는 부록이 아니라 결과물의 핵심으로서의 액션 아이템

즉, postmortem-writing skill은 단순히 문장을 매끈하게 다듬고 싶을 때보다, 일관된 형식과 더 안전한 표현이 필요할 때 더 유용합니다.

도입 전에 알아둘 점

이 스킬은 문서 중심입니다. 저장소 기준으로 확인되는 파일은 SKILL.md뿐이며, 보조 스크립트, 스키마, 참고 파일은 보이지 않습니다. 즉 postmortem-writing install 자체는 간단하지만, 결과물의 품질은 사용자가 어떤 인시던트 입력을 주느냐에 크게 좌우됩니다. 증거를 자동 수집하거나 티켓을 자동 생성해 주는 기능을 기대한다면, 이 스킬만으로는 충족되지 않습니다.

postmortem-writing 스킬 사용 방법

postmortem-writing 설치 맥락

상위 스킬 저장소에서 설치하면 됩니다:

npx skills add https://github.com/wshobson/agents --skill postmortem-writing

이 스킬은 plugins/incident-response/skills/postmortem-writing에 들어 있으므로, 설치되는 것은 독립 실행형 인시던트 플랫폼이 아니라 포스트모템 작성 워크플로와 가이드 레이어라고 보는 것이 정확합니다.

먼저 읽어야 할 파일

가장 먼저 볼 파일은 다음입니다:

• SKILL.md

이 스킬에는 resources/, rules/, 스크립트 같은 보조 구성요소가 드러나 있지 않으므로, 저장소를 가장 빠르게 파악하는 방법은 SKILL.md를 처음부터 끝까지 읽는 것입니다. 여기서는 코드보다 프로세스 가이드와 서술 프레이밍이 가치의 핵심이기 때문에 이 점이 특히 중요합니다.

postmortem-writing를 꺼내 쓰기 좋은 시점

postmortem-writing usage는 이미 “이 사건은 공식 포스트모템이 필요하다”는 판단이 선 경우에 특히 유용합니다. 예를 들면:

• SEV1 또는 SEV2 인시던트
• 잠깐의 일시적 흔들림을 넘는 고객 영향 장애
• 데이터 손실 또는 보안 이슈
• 심각한 사고로 이어질 뻔한 아차 사고
• 새로운 유형의 장애나 이례적인 운영자 개입이 있었던 경우

반대로 사건이 경미하고 학습 포인트나 후속 조치가 필요하지 않다면, 짧은 인시던트 노트만으로도 충분할 수 있습니다.

이 스킬이 필요로 하는 입력

이 스킬은 “포스트모템 써줘” 같은 한 줄 요청보다, 원시 인시던트 자료를 함께 줄 때 가장 잘 작동합니다. 유용한 입력 예시는 다음과 같습니다:

• 인시던트 요약
• 시작 시각과 종료 시각
• 고객 또는 시스템 영향
• 주요 이벤트 타임라인
• 감지 방식
• 완화 조치
• 추정 근본 원인
• 확인된 기여 요인
• 아직 풀리지 않은 질문
• 이미 논의된 후속 액션

시간 순서가 정확할수록 최종 보고서의 품질도 좋아집니다.

거친 요청을 강한 프롬프트로 바꾸는 법

약한 프롬프트:

• “어제 장애 포스트모템 작성해줘.”

강한 프롬프트:

• “Use the postmortem-writing skill to draft a blameless postmortem for a 47-minute API outage on 2025-02-10. Include a minute-by-minute timeline, impact summary, root cause, contributing factors, what detection missed, and action items grouped by prevention, detection, and response. Mark uncertainties clearly instead of inventing details.”

이 프롬프트가 더 나은 이유:

• 인시던트 범위를 분명히 정하고
• 비난 없는 서술을 명시하며
• 빠지기 쉬우나 중요한 섹션을 요구하고
• 근거 없는 확정 서술 대신 불확실성을 허용하기 때문입니다

실무에서 바로 쓰기 좋은 프롬프트 템플릿

다음과 같은 형태로 요청하면 좋습니다:

• Incident type: outage, degradation, security event, data incident, near-miss
• Severity: SEV level or equivalent
• Time window: start, detection, mitigation, resolution
• Impact: users, revenue, requests, data, internal operations
• Evidence: logs, alerts, chat notes, ticket excerpts
• Suspected cause: what failed and why
• Contributing factors: tooling, process, load, config, staffing, dependencies
• Desired output: executive summary, timeline, RCA, lessons learned, action items
• Tone constraint: blameless, factual, no named-person blame
• Unknowns: list them explicitly

이 방식이 postmortem-writing for Report Writing 결과를 가장 빠르게 끌어올리는 방법입니다.

실제 인시던트에서 권장하는 워크플로

현실적으로 잘 작동하는 흐름은 다음과 같습니다:

1. 인시던트 노트와 시스템 증거에서 원시 사실을 모읍니다.
2. 스킬에 1차 구조화 초안을 요청합니다.
3. 타임라인의 순서 오류를 검토합니다.
4. 근본 원인과 기여 요인의 구분을 더 명확히 다듬습니다.
5. 비난처럼 읽히는 표현을 걷어냅니다.
6. 필요하다면 초안 바깥에서 담당자와 기한이 있는 액션 아이템을 추가합니다.
7. 최종 보고서를 포스트모템 회의에 활용합니다.

이 순서는 실제 팀이 인시던트 이후 문서를 작성하는 방식과도 맞습니다. 먼저 사실을 정리하고, 그다음 해석을 붙이고, 마지막에 개선 조치를 확정하는 흐름입니다.

더 나은 타임라인을 얻는 방법

포스트모템 문서가 신뢰할 만해 보이는지는 대개 타임라인 품질에서 갈립니다. 아래처럼 시각이 포함된 bullet을 제공하세요:

• 09:14 UTC: latency alert fired
• 09:16 UTC: on-call acknowledged
• 09:21 UTC: deploy rollback started
• 09:37 UTC: error rate returned to baseline

이런 정보가 없으면 아무리 좋은 postmortem-writing guide라도 인과관계를 안정적으로 재구성하기 어렵습니다.

더 나은 근본 원인 분석을 요청하는 법

그냥 “근본 원인”만 물어보지 마세요. 대신 다음을 함께 요청하세요:

• 직접적인 원인
• 더 깊은 시스템적 요인
• 보호장치가 왜 실패했는지
• 감지나 에스컬레이션이 왜 늦었는지
• 무엇이 이 실패를 가능하게 했는지

그래야 결과가 “잘못된 배포가 있었다” 수준의 얕은 설명으로 무너지는 것을 막을 수 있습니다. 그런 서술은 대개 실무적으로 충분히 유용하지 않습니다.

문서를 비난 없는 방식으로 유지하는 법

이 스킬은 명시적으로 blameless 문화를 중심에 둡니다. 프롬프트에서도 이 점을 다시 강화하는 것이 좋습니다:

• 개인의 잘못이 아니라 시스템 조건에 초점을 맞추라고 요청하고
• 중립적인 표현을 요구하며
• 사람의 행동과 조직적·기술적 맥락을 분리해 달라고 요청하세요

예를 들어 다음 표현이 더 적절합니다:

• “The deployment process allowed an unsafe config change to reach production”
  다음보다:
• “An engineer pushed the wrong setting”

이 스킬이 제공하지 않는 것

postmortem-writing skill에는 다음 기능이 포함된 것으로 보이지 않습니다:

• 자동 데이터 수집
• 도구에서 인시던트 타임라인 자동 추출
• 티켓 동기화
• 일반적인 가이드를 넘는 수준의 심각도 분류 로직
• 조직별 전용 템플릿의 즉시 제공

따라서 자체 맥락은 직접 넣어야 하고, 결과물도 팀의 인시던트 운영 방식에 맞게 조정할 계획을 세우는 편이 좋습니다.

postmortem-writing 스킬 FAQ

postmortem-writing는 일반 LLM 프롬프트보다 낫나요?

대체로 그렇습니다. 특히 문제의 핵심이 구조와 원칙이라면 더 그렇습니다. 일반 프롬프트로도 포스트모템은 만들 수 있지만, 인시던트 발생 기준, 비난 없는 서술, 근본 원인과 기여 요인의 구분을 자주 놓칩니다. postmortem-writing은 에이전트에게 더 분명한 작업 패턴을 제공합니다.

초보자도 쓰기 적합한가요?

네. 가이드 중심이고 별도 커스텀 툴링이 필요하지 않아서 초보자도 접근하기 쉽습니다. 다만 초보자라도 인시던트에 대한 사실 기록은 직접 가져와야 합니다. 이 스킬은 글의 품질과 리뷰 구조를 개선해 주지만, 인시던트 조사 자체를 대신해 주지는 않습니다.

언제 postmortem-writing를 쓰지 않는 편이 좋나요?

다음 경우에는 굳이 쓰지 않는 편이 낫습니다:

• 사건이 전체 포스트모템까지 필요할 정도는 아닐 때
• 글 작성 도우미가 아니라 실시간 incident commander가 필요할 때
• 기본 사실조차 아직 부족하고 여전히 디버깅 중일 때
• 조직에서 매우 엄격한 사내 전용 템플릿을 요구하고, 이 스킬로는 큰 수정 없이 맞추기 어려울 때

postmortem-writing는 엔지니어링 장애에만 쓸 수 있나요?

아니요. 기술 인시던트에 가장 잘 맞긴 하지만, 타임라인, 영향, 시정 조치를 제공할 수만 있다면 보안 사고, 데이터 사고, 운영 실패, 심각한 아차 사고에도 같은 프레임워크를 적용할 수 있습니다.

경영진용 요약에도 postmortem-writing를 쓸 수 있나요?

네, 가능합니다. 다만 거기서 멈추면 안 됩니다. 경영진은 짧은 요약을 원하지만, 대응자와 실무자는 전체 타임라인과 액션 플랜이 필요합니다. 간결한 요약과 전체 보고서를 둘 다 생성해 달라고 요청하는 편이 좋습니다.

이 스킬이 액션 아이템 작성에도 도움이 되나요?

네, 간접적으로 도움이 됩니다. 소스 가이드는 실행 가능한 후속 조치를 강조합니다. 예방, 감지, 대응, 프로세스 개선처럼 카테고리별로 액션을 묶어 달라고 요청하면 결과가 더 좋아집니다.

postmortem-writing 스킬을 더 잘 활용하는 방법

postmortem-writing에는 지시문보다 증거를 더 잘 넣어라

가장 큰 품질 레버는 입력의 충실도입니다. 다음을 그대로 붙여 넣으세요:

• timestamps
• customer impact metrics
• alert names
• mitigation steps
• known unknowns

복잡한 메타 지시문보다 풍부한 증거가 더 큰 차이를 만듭니다.

사실과 해석을 분리하라

흔한 실패 패턴 중 하나는 가정을 타임라인 안에 섞어 넣는 것입니다. 입력을 두 블록으로 나누세요:

• confirmed facts
• hypotheses or open questions

이렇게 하면 postmortem-writing usage가 정확성을 유지하면서도 불확실성을 드러내기 쉬워집니다.

빠진 섹션은 이름을 찍어서 요청하라

첫 초안이 너무 뭉뚱그려져 있다면, 빠진 섹션을 이름으로 직접 요청하세요:

• “Add a ‘What went well’ section”
• “Separate contributing factors from root cause”
• “Rewrite action items so each is specific and testable”

“더 좋게 만들어줘”보다 이런 구체적인 수정 요청이 훨씬 빠르게 결과를 개선합니다.

피상적인 액션 아이템을 막는 법

약한 포스트모템은 “모니터링 개선”처럼 모호한 액션으로 끝나는 경우가 많습니다. 각 액션이 다음 기준을 만족하도록 요청하세요:

• 구체적일 것
• 담당자 지정이 가능할 것
• 특정 실패 모드와 연결될 것
• 측정 가능하거나 테스트 가능할 것

예를 들어:

• “Add an alert for queue lag over 5 minutes in region us-east-1”
  는 다음보다 낫습니다:
• “Improve alerting”

비난이 다시 스며드는지 점검하라

비난 없는 스킬을 써도, 채팅 로그나 메모 같은 원본 자료에 비난이 강한 표현이 섞여 있을 수 있습니다. 특정 개인에게 과도하게 초점을 맞추고, 시스템 조건·인센티브·도구·리뷰 공백·운영 맥락을 놓치는 표현이 없는지 검토하세요.

더 높은 품질을 원하면 두 번에 나눠 다듬어라

안정적으로 잘 먹히는 패턴은 다음과 같습니다:

1. 1차 패스에서는 사실 구조를 잡고
2. 2차 패스에서는 분석과 액션을 다듬기

타임라인이 아직 불안정한 상태에서 모델에게 매끈한 해석까지 한 번에 요구하면, 없는 논리를 지어낼 가능성이 커집니다.

팀의 포스트모템 성숙도에 맞춰 출력 깊이를 조절하라

팀이 아직 초기 단계라면 postmortem-writing에 타임라인, 영향, 원인, 액션 정도의 단순한 형식을 요청하세요. 팀이 성숙한 편이라면 감지 공백, 에스컬레이션 효과, 복구 과정의 트레이드오프, 시스템 차원의 교훈 같은 더 깊은 섹션을 요구할 수 있습니다. 같은 스킬로 둘 다 지원할 수 있지만, 기대하는 깊이는 사용자가 직접 설정해야 합니다.

초안 이후 report-writing 결과를 더 좋게 만드는 법

더 강한 postmortem-writing for Report Writing 결과를 원한다면, 최종 검토에서 다음 네 가지를 확인하세요:

• 새로 합류한 팀원도 무슨 일이 있었는지 이해할 수 있는가?
• 타임라인이 감사·검증 가능한 수준으로 충분히 정확한가?
• 분석이 방어선이 왜 실패했는지를 설명하는가?
• 액션이 재발 가능성을 낮출 만큼 충분히 구체적인가?

이 질문 중 하나라도 “아니오”라면, 막연히 다시 실행하지 말고 그 빈틈을 반영해 프롬프트를 수정하는 것이 낫습니다.