incident

Agent Incident Response

에이전트 장애 대응 프로토콜 — 발견, 분류, 대응, 복구, 학습

Core Goal

• 에이전트 장애를 신속하게 감지하고 대응 — 침묵의 실패(Silent Failure)를 조기에 찾아내고 격리
• 블래스트 반경을 제한하고 영향 최소화 — 영향받은 사용자/비용 범위를 정확히 파악 후 신속 복구
• 장애 경험을 암묵지로 추출 — TK로 기록해서 비슷한 실패의 재발 방지

---

Trigger Gate

Use This Skill When

• 에이전트 정확도가 급락(> 10% 한 번에)했을 때
• 비용이 갑자기 폭증(2배 이상)했을 때
• PII 또는 민감 정보 유출 신호가 있을 때
• 사용자 신고 또는 SNS 부정적 언급이 들어왔을 때
• 내부 QA/모니터링에서 에러율 급증을 탐지했을 때

Route to Other Skills When

• reliability (Pre-mortem 섹션) → 장애 원인 분석 후 유사 실패 예방 메커니즘 설계
• ops-review --mode cost → 비용 폭증이 토큰 사용량 이상이라면 (비용 최적화 필요)
• reliability → 장애 복구 후 신뢰성 개선 계획 수립
• metrics-design (코호트 분석 섹션) → 특정 버전/세그먼트만 장애를 겪었다면 (코호트 분석)

Boundary Checks

• 실제 장애 vs 정상 변동 — Accuracy 1-2% 변화는 정상 범위, > 5% 이상이면 조사
• 원인 판단 과정 — 5 Whys를 최소 3단계 이상 실행해야 근본 원인 파악 가능
• 영향도 산정 정확성 — 추정이 아닌 실제 영향받은 사용자/트래잭션 로그 기반 확인

---

개념

에이전트 장애는 일반 소프트웨어 장애와 다르다. "서버가 죽었다"는 명확하지만, "에이전트가 환각으로 잘못된 답을 줬다"는 발견 자체가 어렵다. 침묵의 실패(Silent Failure)가 에이전트 장애의 가장 위험한 유형이다.

Instructions

You are running incident response for: $ARGUMENTS

Step 1 — Incident Detection & Classification

발견 시각: [timestamp]
발견 방법:
  □ 자동 모니터링 알림
  □ 사용자 신고
  □ 내부 QA 발견
  □ 비용 이상 감지
  □ 외부 보고 (SNS, 언론)

Severity Classification:

SEV	정의	예시	대응 시간
SEV-1	전체 서비스 중단 또는 데이터 유출	에이전트가 PII를 외부에 노출	15분 이내
SEV-2	핵심 기능 장애, 다수 유저 영향	정확도 50% 이하로 급락, 비용 10배 폭등	1시간 이내
SEV-3	일부 기능 저하, 소수 유저 영향	특정 입력에서 환각 반복	4시간 이내
SEV-4	경미한 품질 저하, 우회 가능	응답 속도 저하, 포맷 깨짐	24시간 이내

Step 2 — Immediate Response

에이전트 장애 유형별 긴급 대응:

🔴 환각/오정보 장애:
  1. 해당 에이전트 기능 즉시 비활성화
  2. 영향 범위 확인 (몇 명이 잘못된 정보를 받았는가?)
  3. 영향받은 유저에게 정정 통보
  4. 원인 분석 (프롬프트 문제? 모델 변경? 입력 데이터 오염?)

🔴 비용 폭등 장애:
  1. API 호출 rate limit 즉시 설정
  2. 비용 발생 원인 추적 (무한 루프? 토큰 폭발? 잘못된 모델 라우팅?)
  3. 비용 캡 설정
  4. 영향받은 기간의 비용 산출

🔴 데이터 유출 장애:
  1. 에이전트 즉시 중단
  2. 유출 범위 파악 (어떤 데이터, 누구에게, 어디로)
  3. 법무팀 즉시 통보
  4. 규제 보고 필요 여부 판단 (GDPR, 개인정보보호법)

🔴 연쇄 실패 장애 (멀티에이전트):
  1. 오케스트레이터 에이전트 중단
  2. 하위 에이전트 상태 확인
  3. 실패 전파 경로 추적
  4. 격리 후 개별 에이전트 순차 재시작