reliabilitylisted

# Reliability Review > 에이전트 신뢰성 체계적 점검 및 개선 ## Core Goal - **에이전트의 "최악의 경우" 신뢰성을 정량화** — 평균이 아니라 백분위수(P95, P99)로 신뢰도 평가 - **실패 패턴을 분류하고 각각에 대한 safeguard 설계** — 입력 오류, 모델 오류, 통합 오류 등 유��별 방어책 구축 - **신뢰성 수준(Basic/Standard/High/Critical)을 비즈니스 요구에 맞추기** — 내부 도구는 95%, 고객 대면은 99.9% 같이 차등 목표 설정 --- ## Trigger Gate ### Use This Skill When - 에이전트를 프로덕션에 배포하기 전에 신뢰성 평가가 필요할 때 - incident 이후 비슷한 실패를 방지하기 위해 safeguard를 강화할 때 - 에이전트 성능이 불안정하거나 예측 불가능한 패턴을 보일 때 - SLA 보장(예: 99.5% uptime)이 필요한 고객 계약을 체결할 때 ### Route to Other Skills When - **incident** → 실제 장애가 발생한 후 근본 원인 분석과 신뢰성 개선 연결 - **이 스킬의 Pre-mortem 섹션** → 신뢰성 개선 계획의 리스크를 사전 분석할 때 (아래 "사전 위험 분석" 섹션) - **metrics-design --step kpi** → 신뢰성을 KPI 대시보드(Success Rate, Error Rate)에 포함 - **metrics-design** (코호트 분석 섹션) → 신뢰성이 코호트(버전)별로 다르게 나타날 때 (버전 비교) ### Boundary Checks - **기준선 데이터 부족** — 최소 1주일 이상 데이터 필요 (일일 변동성 흡수) - **실패 분류의 표준화** — 팀마다 "에러"를 다르게 정의하면 신뢰성 측정 불가 → formula 명시 - **Safeguard 과도화** — 모든 가능한 실패에 방어책을 세우면 성능 저하 → 영향도 × 발생 확률로 우선순위화 --- ## 개념 에이전트 신뢰성은 "평균적으로 잘 되는가"가 아니라 "최악의 경우에도 허용 가능한가"로 측정한다. 99%의 성공률은 100번 중 1번 실패를 의미하고, 실패 1번의 비용이 99번의 가치를 초과할 수 있다. ## Instructions You are conducting a **reliability review** for: **$ARGUMENTS** ### Step 1 — Reliability Baseline Collect current data: ``` Total executions (last 30 days): ___ Successful: ___ (___%) Failed: ___ (___%) Partially correct: ___ (___%) ``` ### Step 2 — Failure Taxonomy Classify all failures: | Category | Count | Severity | Example | |----------|-