서킷브레이커 analyst/guardian 커버리지 공백 개선 제안서

[현황]

scripts/orchestrator.py의 두 서킷브레이커(CB)는 코드상 target_agent를 하드코딩된 3종(codex, cowork, ron)으로만 제한한다.

• _is_agent_infra_cb_tripped() (3859~3956행), 게이트 조건 3870행: if target_agent not in ("codex", "cowork", "ron"): return False, ""
• _is_agent_evidence_gate_cb_tripped() (3962~행), 게이트 조건 3973행: if target_agent not in ("codex", "cowork", "ron"): return False, ""
• AGENT_INFRA_CB_FALLBACK_MAP (3743~3752행)도 키가 codex/cowork/ron 3개뿐이고, analyst-fundamental/analyst-macro/analyst-technical/ analyst-pm/guardian 5개 에이전트는 매핑 자체가 없다 — 즉 이 5개는 인프라 CB가 트립되어도 감지·재라우팅·드롭 어느 경로도 타지 않고 create_task()가 무한정 신규 태스크를 계속 큐에 넣는다.

bus_commands_archive 최근 14일 실측(조회 2026-09-23, sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db):

analyst-macro는 완료율이 1/319(0.3%)에 불과하고, 실패 사유 표본 10건 중 8건이 execution_artifact_path_not_found 또는 missing_verification_command/exit_code — codex/cowork/ron에 이미 적용된 "45분 내 2회 실패 시 15분 보류" 로직이 있었다면 즉시 트립됐을 연쇄 실패 구간이 실측으로 확인된다(2026-09-22 20:42:58→20:55:21, 13분 간격 연속 실패 2건). analyst-technical도 완료 0건에 실패 130건, 그 중 45건이 llm_infra_failure_retry_deferred(모델 응답 타임아웃) 계열로, 이는 codex/cowork에 붙어 있는 인프라 CB가 정확히 잡도록 설계된 패턴과 동일하다.

guardian은 표본이 4건뿐이라 통계적 반복성은 약하지만, 4건 전부가 evidence-gate 계열 반려라는 점에서 evidence-gate CB(동일 CMD 계열 30분/3회/15분 보류) 미적용 시 향후 같은 패턴이 재현될 구조적 공백이다.

[권고]

1순위: _is_agent_infra_cb_tripped()와 _is_agent_evidence_gate_cb_tripped() 두 함수의 화이트리스트를 ("codex", "cowork", "ron")에서 ("codex", "cowork", "ron", "analyst-fundamental", "analyst-macro", "analyst-technical", "analyst-pm", "guardian")로 확장한다. 근거: analyst-macro 14일 실패 299건 중 41건(13.7%), analyst-technical 130건 중 45건(34.6%)이 이미 codex/cowork에서 검증된 infra_markers 판정 문자열(llm_infra_failure, timeout, empty_response, cooldown 등)에 그대로 걸리는 패턴이다 — 화이트리스트만 넓히면 기존 판정 로직을 재사용해 즉시 커버 가능하고 별도 신규 로직 작성이 필요 없다. 기대 효과: analyst-macro/technical의 연쇄 실패 시 45분/2회 임계값 도달 뒤 15분간 신규 디스패치가 자동 보류되어, 현재처럼 완료율 0~0.3%인 채로 계속 큐에 태스크가 쌓이는 낭비를 억제한다.

2순위: AGENT_INFRA_CB_FALLBACK_MAP에 analyst 4종과 guardian의 대체 경로를 명시적으로 추가한다. 단, codex/cowork처럼 다른 agent로 완전히 떠넘기면 CMD#39748/#39749류(부적합 대행이 허구 근거파일로 완료 제출)가 재현될 위험이 있으므로, analyst-fundamental/macro/technical/ pm은 서로 대행 불가능한 전문 판단 영역이라 매핑값을 None(대체 없이 드롭, 기존 "대체agent 없음, 드롭" 로그 경로 재사용)으로 명시 등록하고, guardian만 "ron"으로 매핑한다(guardian의 시스템 점검 성격이 ron의 운영 범위와 겹치는 유일한 사례). 기대 효과: 현재 "화이트리스트에 없어 조용히 무한 재시도"되는 상태에서 "화이트리스트에는 있으나 대체agent 없음으로 드롭 로그 남김" 상태로 전환되어, 최소한 로그(AGENT_INFRA_CB_BLOCKED ... 대체agent 없음, 드롭)로 문제가 가시화된다.

[리스크]

• 구조적 위험: 현재 analyst 4종+guardian은 단일 장애점이 없는 게 아니라 오히려 "장애 감지 자체가 없는" 상태다 — CB가 없으므로 create_task()가 실패 이력과 무관하게 계속 신규 태스크를 생성하고, 이는 bus_commands_archive의 analyst-macro 299건/analyst-technical 130건이라는 실패 누적으로 이미 실증됐다. 화이트리스트 확장 없이 방치하면 이 누적은 계속 선형 증가한다.
• 의존관계: _is_agent_infra_cb_tripped()와 _is_agent_evidence_gate_cb_tripped()는 ops_db_query()로 bus_commands(활성 테이블, 실측 8행)만 조회하고 bus_commands_archive (3038행)는 보지 않는다 — 화이트리스트를 넓혀도 활성 테이블에 최근 데이터가 없으면(현재 activo 테이블에 analyst/guardian 관련 행 0건) CB가 트립 조건을 만날 기회 자체가 드물다. 확장 전에 아카이브 이관 주기와 활성 테이블 잔존 시간을 먼저 확인해야 한다(별도 조사 필요, 이번 조사 범위 밖).
• 리스크 완화 필요: analyst 4종을 AGENT_INFRA_CB_FALLBACK_MAP에 None으로 등록할 때 기존 fallback_target and fallback_target in ACTIVE_AGENTS 조건이 None을 False로 안전하게 처리하는지 코드(2383행 elif fallback_target and fallback_target in ACTIVE_AGENTS:)로는 처리되지만, .get(target)이 키 자체가 없을 때와 값이 None일 때를 로그 문구상 구분 못 하므로 codex 구현 시 로그에 "명시적 no-fallback" 문구를 추가해 향후 진단 시 "매핑 누락"과 "의도된 드롭"을 혼동하지 않게 해야 한다.

[검증방법]

• KPI: 화이트리스트 확장 배포 후 7일간 analyst-macro/analyst-technical의 bus_commands_archive 실패 건수가 배포 전 14일 평균(analyst-macro 299/14≈21.4건/일, analyst-technical 130/14≈9.3건/일) 대비 30% 이상 감소해야 한다(CB로 무의미한 재시도가 억제되는지 측정).
• 검증 명령: sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT target_agent, COUNT(*) FROM bus_commands_archive WHERE target_agent IN ('analyst-macro','analyst-technical') AND status='failed' AND completed_at > datetime('now','localtime','-7 days') GROUP BY target_agent;" — 기대값: 배포 전 대비 감소, 최소한 증가는 없어야 함.
• 로그 검증: grep -c "AGENT_INFRA_CB_BLOCKED.*analyst-" logs/orchestrator*.log 로 신규 CB 발동 로그가 실제로 찍히는지 확인(기대값: 0건이 아닌 양수 — CB가 전혀 발동하지 않으면 화이트리스트 확장이 코드에 반영은 됐으나 실제 트립 조건을 못 만난 것이므로 활성 테이블 리스크 항목을 먼저 재조사해야 함).
• 롤백 조건: 화이트리스트 확장 후 정상 완료 가능했을 analyst 태스크가 CB에 의해 오차단(false positive)되어 완료율이 오히려 하락하면(현재 analyst-macro 완료 1건/319건, analyst-technical 0건/130건 대비 더 낮아지면) 즉시 ("codex", "cowork", "ron") 원복.