/debrief#

Post-incident blameless analysis — 인시던트 발생 후 근본 원인 분석, 영향 범위 파악, 게이트 개선안 도출

Triggers#

• Production 인시던트 발생 후
• 심각한 버그가 게이트를 통과하여 배포된 경우
• 팀 회고 또는 post-mortem이 필요한 경우

Usage#

# 인시던트 설명으로 시작
/debrief  " 로그인 서비스 장애 — 소셜 로그인 토큰 만료 미처리 " 

 # 이슈 번호 기반
/debrief --issue 456

# 특정 커밋/PR 기반
/debrief --pr 789

Parameters#

*하나 이상 필수

Options#

Execution Flow#

Phase 1: Information Gathering#

1. 인시던트 컨텍스트 수집

   • 이슈/PR에서 정보 추출 (ZenHub MCP 활용)
   • 관련 코드 변경 이력 조회 (git log, git diff)
   • 영향받은 파일/모듈 식별

2. 타임라인 구성

   • 문제 발생 시점
   • 감지 시점 및 방법
   • 대응 시작 시점
   • 해결 시점
   • 전체 MTTR (Mean Time To Resolve) 산정

Phase 2: Root Cause Analysis#

3. 5 Whys 분석

   • Why 1: 직접적 원인
   • Why 2: 왜 그 원인이 발생했는가
   • Why 3-5: 근본 원인까지 재귀적 추적
   • 각 단계에서 증거(코드, 커밋, 설정) 첨부

4. Blast Radius 분석

   • 영향받은 사용자/서비스 범위
   • 영향받은 코드 모듈 (Grep 기반 의존성 추적)
   • 데이터 영향 (손실, 불일치 여부)

Phase 3: Gate Gap Analysis#

5. 게이트에서 놓친 것 분석

   • Specification Gate: 이 시나리오가 스펙에 포함되어 있었는가?
   • Analysis Gate: Acceptance Criteria에 이 케이스가 있었는가?
   • Implementation Gate: 테스트가 이 케이스를 커버했는가?
   • Code Review: 리뷰어가 이 패턴을 감지할 수 있었는가?

6. 기여 요인 식별

   • 시스템적 요인 (아키텍처, 인프라)
   • 프로세스적 요인 (리뷰, 테스트)
   • 도구적 요인 (모니터링, 알림)

Phase 4: Action Items#

7. 개선 조치 도출 (각 항목에 우선순위 부여)

   Prevent (재발 방지):

   • 코드 변경 제안 (구체적 파일/라인)
   • 테스트 추가 제안 (구체적 시나리오)
   • 게이트 기준 강화 제안

   Detect (조기 탐지):

   • 모니터링/알림 추가
   • 테스트 커버리지 확대
   • 린트 규칙 추가

   Respond (대응 개선):

   • 런북 업데이트
   • 에스컬레이션 경로 개선
   • 롤백 절차 확인

Phase 5: Document & Learn#

8. Debrief 문서 작성

   • docs/debriefs/YYYY-MM-DD-{topic}-debrief.md 저장

9. 학습 연동

   • /session:wrap 호출하여 학습 사항 자동 추출
   • 게이트 개선안이 있으면 관련 게이트 파일에 TODO 코멘트 추가

Artifact Structure#

# Debrief: {incident_title}

**Date**: YYYY-MM-DD
**Severity**: Critical | Major | Minor
**MTTR**: Xh Ym

## Summary
{1-2 paragraph incident summary}

## Timeline
| Time | Event |
|------|-------|
| HH:MM | {event} |

## Impact
- **Users affected**: {scope}
- **Services affected**: {list}
- **Data impact**: {description}

## Root Cause (5 Whys)
1. **Why**: {direct cause}
2. **Why**: {underlying cause}
3. **Why**: {systemic cause}
...

## Gate Gap Analysis
| Gate | Should Have Caught? | Why Missed |
|------|---------------------|------------|
| Specification | Yes/No | {reason} |
| Analysis | Yes/No | {reason} |
| Implementation | Yes/No | {reason} |
| Code Review | Yes/No | {reason} |

## Contributing Factors
- {factor 1}
- {factor 2}

## Action Items

### Prevent (재발 방지)
- [ ] {action} — Owner: {who} — Due: {when}

### Detect (조기 탐지)
- [ ] {action} — Owner: {who} — Due: {when}

### Respond (대응 개선)
- [ ] {action} — Owner: {who} — Due: {when}

## Lessons Learned
{blameless insights}

## References
- Issue: #{number}
- PR: #{number}
- Related commits: {hashes}

Key Rules#

1. Blameless: 개인이 아닌 시스템/프로세스에 초점. "누가"가 아니라 "왜"를 추적
2. Evidence-based: 모든 분석에 코드/커밋/로그 증거 첨부
3. Actionable: Action Items는 구체적이고 담당자/기한이 명확해야 함
4. Gate-aware: 파이프라인 게이트 관점에서 분석하여 시스템 개선으로 연결
5. Time-sensitive: 인시던트 후 48시간 이내 수행 권장 (BMAD 정책)

Related Commands#

• /dev:bugfix — 버그 수정 사이클
• /session:wrap — 세션 학습 추출
• /project — 파이프라인 게이트 참조