[자문] Sonnet quota burst 재발 방지 — 페르소나 게이트웨이 안전장치

TL;DR

PR #94의 cascade fallback는 증상 차단. 재발 방지엔 4개 안전장치 추가 필요. 도구 위상 고려해 저비용·고효과 P0 2건 우선(Catch-all fallback + cascade 횟수 상한, Log self-loop 가드), 중비용 P1 2건은 시범 데이터 본 뒤 결정.

질문 / 결정 사항

2026-05-22 00:09 KST 발생한 sonnet quota 429 장애의 재발 방지 — 리포트 follow-up 3건(nit·drain 가드·메모리 명문화)이 재발 방지엔 부족. 어떤 안전장치를 어느 우선순위로 추가할 것인가?

옵션 비교

Option A: P0 2건만 즉시 + P1·P2는 데이터 후 결정 (권장)

장점

저비용·고효과 우선 — 코드 변경 분량 작음, 검증 부담 적음
개인 도구 위상에 부합 — SRE급 인프라화 비용 회피
시범 데이터(2~4주 운영 로그) 본 뒤 P1·P2 결정 → 과설계 위험 차단

단점

다음 quota reset 사이클(매일 14:00)에 또 burst 발생 가능성 남음 — 단, cascade가 이미 동작하므로 *재현되지 않음*
실패율 기반 circuit breaker 부재 → cascade 누적 지연 가능 (worst case 3×300s)

트레이드오프

과설계 회피 vs cascade worst case 지연 노출. 시범 데이터로 실제 worst case 분포 측정 후 P1 도입 결정

---

Option B: 4건 모두 일괄 도입

장점

한 번에 SRE급 가드 완비
다음 quota 변동·CLI 포맷 변경에 모두 면역

단점

개인 페르소나 도구에 *과설계* — 관측·튜닝 부담이 가치 대비 큼
Circuit breaker 임계값·global timeout 수치 모두 *실측 없는 추측*에 의존
한 번에 4건 도입 시 회귀 위험 증가 (PR #94 직후라 더더욱)

트레이드오프

완전한 가드 vs 과설계·실측 부재. 도구 위상엔 부적합.

---

Option C: Anthropic plan 다변화로 근본 해결 (트랙 분리)

장점

단일 plan 종속이 근본 원인 — API key 병행 또는 Bedrock 경유로 *quota 자체 분산*
코드 가드보다 *구조적* 해결

단점

비용 구조 변경 — Pay-as-you-go 추가 비용 발생
인증·라우팅 코드 분량 큼 (Bedrock SDK 통합 등)
단기 재발 방지엔 과한 카드

트레이드오프

장기 안정성 vs 단기 비용·구현 부담. *별도 트랙*에서 Q3 검토 권장.

권장안

선택: Option A (P0 2건 즉시 + P1·P2 데이터 후 결정)

근거:

도구 위상이 개인 페르소나 게이트웨이 — SRE급 가드 비용·관측 부담 부적합
Catch-all fallback과 self-loop 가드는 *코드 5~10줄* 수준, 회귀 위험 최소
Circuit breaker·global timeout 수치는 실측 없이 정할 수 없음 — 시범 데이터 선결
Anthropic quota API가 잔여량을 노출하지 않으므로 "조기 경고"는 *실패율 기반 reactive*만 가능 — "조기"라는 표현 자체가 오해 소지

우선순위 분류

우선순위	항목	비용	효과	비고
P0	Catch-all fallback (exit≠0 OR JSON parse 실패 = 무조건 fallback)	저	고	`_QUOTA_MARKERS` 대신 negative match. cascade 횟수 상한 짝지어야 함
P0	Log self-loop 가드 (metadata 기반 자기참조 필터)	저	고	914 vs 27 false-positive 차단. wrapper PID 라이프사이클 점검 동시
P1	실패율 기반 reactive circuit breaker	중	중	2~4주 운영 로그 분포 본 뒤 임계값 결정
P1	Global timeout + per-tier dynamic timeout	중	중	cascade worst case 실측 후 ceiling 설정
P2	Anthropic plan 다변화 (별도 트랙)	고	고	Q3 검토. 단기 재발 방지엔 과함
P3	리포트 follow-up 3건 (nit·drain 가드·메모리 명문화)	저	저	P0 머지 후 정리

반대 케이스·주의사항

**Catch-all fallback의 amplifier 위험**: prompt injection 또는 모든 모델 quota 소진 시 무한 cascade로 비용·지연 폭증 가능 → *cascade 횟수 상한 반드시 함께 도입* (max_retries=4 권장: sonnet→opus→haiku→gemini)
**"조기 경고" 표현 수정**: Anthropic quota 잔여량 API 부재 → 실패율 기반 reactive만 가능. 권고 문서·티켓에서 "조기" 어휘 제거
**HAN-179 graceful drain 상호작용**: 120s drain 윈도우 ↔ cascade 3-tier (각 300s) 충돌 가능. drain 중 cascade 시작된 호출은 *abort 또는 force-complete* 정책 명시 필요

참고 자료

HAN-248 PR #94 (78046fe) — stdout JSON api_error_status 분류 + cascade fallback 추가
HAN-179 — graceful drain 윈도우
feedback_persona_model_tiering 메모리 — Jarvis·Nano Sonnet 정책, 비상 시 cascade 허용 예외 명문화 필요
Anthropic Max plan 모델별 별도 한도 (sonnet·opus·haiku 독립 quota)
Gemini 자문 (2026-05-22) — Catch-all fallback, Circuit breaker, Self-loop 차단, Global timeout 4건 일치