virtual-insanity
매크로 가격 공시 펀더 테크 섹터 뉴스 볼트 채권
← 리포트 목록

반복 LLM 인프라 실패의 주간 크레딧 리포트 파이프라인 영향 정리 및 대응 제안

2026-09-08 cowork [크레딧, 주간리포트, orchestrator, agent-infra-cb, FRED, 정책제안]

반복 LLM 인프라 실패 — 주간 크레딧 리포트 영향 및 대응 제안 (CMD#38534)

0. 전제 재검증 — 사용자 전제와 실측이 다르다 (먼저 명시)

요청 전제는 "#38533(analyst-macro)과 #38532(analyst-technical) 둘 다 모델 응답 타임아웃"이었다. 실측(sqlite3 /Users/ron/.hermes/data/ops_multiagent.db "SELECT result_note FROM bus_commands WHERE id IN (38532,38533)", 조회 2026-09-08 06:10 KST)은 다르다:

  • #38532(analyst-technical): 결론: needs_evidence: llm_infra_failure_retry_deferred — 이것만 진짜 모델 응답 타임아웃(상류 LLM 게이트웨이 용량 문제).
  • #38533(analyst-macro): 결론: needs_evidence: 결과 확인 보류 + verification_command_path_not_found:..., execution_artifact_path_not_found:/Users/ron/.hermes/workspace/scripts/pipeline/market_indicator.py... — 이것은 evidence-gate 반려다. find /Users/ron/.hermes/workspace/scripts -iname "market_indicator.py" → 0건, sector_macro_bridge.py → 0건. 즉 analyst-macro가 워크스페이스에 존재하지 않는 파일 경로를 검증 근거로 스스로 인용해서 반려됐다 — 인프라 용량 문제가 아니라 analyst-macro의 응답 자체가 존재하지 않는 스크립트를 지어낸 것이다. 선행건 #38529, #38531도 동일 패턴(전부 market_indicator.py/sector_macro_bridge.py 인용, 3연속 동일 hallucination).

이 구분이 대응 방식을 가른다. technical은 "기다리거나 우회"가 맞지만, macro는 재시도 간격을 아무리 조정해도 같은 hallucination이 반복될 구조적 문제다.

[권고]

1순위: LQD/HYG(technical)·IG/HY OAS(macro) 둘 다 결정적 파이프라인

스크립트로 즉시 우회 실행 — 코드 변경 없이 지금 있는 스크립트를 그대로 실행

방금 두 스크립트를 직접 실행해 재현 가능함을 확인했다(LLM 미사용, 순수 API/라이브러리 호출):

  • python3 /Users/ron/.hermes/workspace/scripts/pipeline/fi_credit_refresh.py --weekly-only → {"status": "ok", "as_of": "2026-09-03", "series_count": 12, "error_count": 0, "output": ".../memory/fi-session/us-ig-weekly-latest.json"}. 저장된 JSON에 BAMLC0A0CM(IG, 81.0bp, weekly +2bp)·BAMLH0A0HYM2(HY, 265.0bp, weekly +5bp)가 그대로 들어있다 — #38533이 재확인하려던 바로 그 두 시리즈다.
  • python3 /Users/ron/.hermes/workspace/scripts/pipeline/credit_etf_technical_check.py → LQD/HYG의 RSI(50.7)·MACD(hist -0.0347, 데드크로스)·이평선· HYG/LQD 상대강도(0.7505)까지 실제 수치로 출력 — #38532가 재확인하려던 바로 그 산출물이다.

기대효과: 두 산출물 모두 상류 LLM 게이트웨이와 무관하게 즉시(수 초 내) 생성된다. 주간 크레딧 리포트(weekly_credit_digest_email.py, 월요일 아침 발송)까지는 아직 며칠 여유가 있지만, "지연 중"인 지금 즉시 신선한 숫자를 확보해두는 것이 재시도 대기보다 안전하다. 단, 이 스크립트들의 출력은 현재 bus_commands의 4블록 증거 형식으로 자동 변환되지 않으므로, analyst-macro/technical 명의의 status=done 완료 제출로 만들려면 누군가(ron/codex)가 이 실행 결과를 인용해 새 completion 텍스트를 작성해야 한다 — 이 변환 작업 자체는 코드 변경이 아니라 단순 실행+인용이라 codex 위임 없이도 가능하다.

2순위: technical과 macro를 다른 재시도 정책으로 분리

  • technical(진짜 infra): AGENT_INFRA_CB_COOLDOWN_MIN=45(분)을 그대로 존중해 45분 전 재시도를 지시하지 않는다. 단, _is_agent_infra_cb_tripped() 실측(scripts/orchestrator.py 3062행): if target_agent not in ("codex", "cowork", "ron"): return False, "" — analyst-technical/macro는 이 서킷브레이커의 보호 대상이 아니다. 즉 45분 쿨다운은 코드가 강제하는 게 아니라 운영자가 수동으로 지켜야 하는 관행일 뿐이다.
  • macro(evidence-gate, hallucination): 재시도 간격을 아무리 늘려도 같은 잘못된 파일 경로를 또 인용할 위험이 있다(3연속 재현됨). 재시도 전에 analyst-macro 역할 정의/프롬프트에 실제 존재하는 파이프라인 파일 목록(fi_credit_refresh.py, market_indicator_tracker.py, macro_series_collector.py)을 명시적으로 배선해야 근본 해결된다 — 이는 프롬프트 수정(scripts/analyst_macro_prompt.md)이라 codex 위임 대상이며, 이번 우회 실행과는 별개 작업이다.

우선순위 재배치(priority=high)는 이미 #38531/#38533에 적용됐으나 효과가 없었다(#38533도 여전히 evidence-gate 반려) — 근거: 두 건 다 priority column = 'high'(실측: SELECT priority FROM bus_commands WHERE id IN (38531,38533) → 둘 다 high). 즉 macro의 실패 원인은 대기열 우선순위 문제가 아니라 응답 내용 자체의 문제이므로, 우선순위 재배치는 이 갈래에서 효과가 없는 조치로 이미 실측 확인됐다.

[현황]

  • 2026-09-08 하루 bus_commands 실패 8건(SELECT id, claimed_by FROM bus_commands WHERE date(created_at)='2026-09-08' AND status='failed'): analyst-macro 3건(#38529, #38531, #38533 — 전부 evidence-gate/파일경로 hallucination), analyst-technical 2건(#38530, #38532 — 전부 llm_infra_failure_retry_deferred), cowork 3건(#38527·#38528 infra, #38534 evidence-gate).
  • analyst-technical의 llm_infra_failure는 최근 7일간 2건뿐(SELECT claimed_by, COUNT(*) FROM bus_commands WHERE claimed_by IN ('analyst-macro','analyst-technical') AND result_note LIKE '%llm_infra_failure%' AND datetime(created_at)>=datetime('now','-7 day') GROUP BY claimed_by → analyst-technical|2, analyst-macro는 0건) — "반복 인프라 실패"라는 프레이밍은 technical에만 맞고 macro에는 안 맞는다.

  • 38532 이후(05:24:18) 06:10 현재까지 42분간 analyst-technical에 신규

    bus_commands가 재생성되지 않음(SELECT id FROM bus_commands WHERE target_agent='analyst-technical' AND datetime(created_at) > '2026-09-08 05:24:18' → 0행) — orchestrator의 agent-infra CB가 analyst-technical에 적용 안 되므로 이건 CB 차단이 아니라 단순 대기 중.
  • 우회 스크립트 실행 결과(방금 재현): fi_credit_refresh.py --weekly-only exit 0, series_count=12, error_count=0; credit_etf_technical_check.py exit 0, LQD/HYG 실제 수치 출력.

[리스크]

  • 구조적 공백: AGENT_INFRA_CB_FALLBACK_MAP(orchestrator.py 2939행)과 _is_agent_infra_cb_tripped()(3062행)는 codex/cowork/ron 3개 에이전트만 대상이다. analyst-macro/technical/fundamental/pm은 서킷브레이커 보호도 폴백 라우팅도 없다 — 이는 스킬 hermes-orchestrator-circuit-breakers의 기존 레퍼런스 (2026-09-07-agent-infra-cb-fallback-map-missing-analyst-agents.md)가 이미 21건/20일, 7건/7일 빈도로 문서화한 미해결 공백과 동일 문제이며, 이번 조사로 macro 쪽에서 "인프라 실패가 아닌 hallucination"이라는 별도 실패 유형까지 추가로 확인됐다 — 즉 analyst-macro는 CB 미적용 문제 위에 hallucination 문제까지 이중으로 노출돼 있다.
  • 단일 장애점: 주간 크레딧 리포트(weekly_credit_digest_email.py)는 analyst-macro/technical의 bus_commands 산출물을 직접 참조하지 않는다 (grep -n "analyst-macro\|analyst-technical" /Users/ron/.hermes/scripts/weekly_credit_digest_email.py → 0건). 즉 이 리포트의 실제 데이터 경로는 볼트에 이미 수집된 "01 시장·크레딧" 항목이며, analyst-macro/technical 실패가 리포트 발송 자체를 막지는 않는다 — 다만 analyst 판단(스프레드 방향 해석, RSI/MACD 신호)이 리포트 서술 품질에 반영되는 경로라면 그 갱신이 지연된다.
  • macro의 3연속 동일 hallucination(#38529→#38531→#38533)은 "재시도하면 스스로 해소"되는 유형이 아니다 — 같은 프롬프트 상태로 재시도하면 같은 존재하지 않는 파일을 또 인용할 위험이 실측상 이미 3회 재현됐다.

[검증방법]

  • KPI 1: 우회 실행 산출물의 as_of 신선도. 측정: python3 -c "import json; d=json.load(open('/Users/ron/.hermes/workspace/memory/fi-session/us-ig-weekly-latest.json')); print(d['as_of'])" → 실측 2026-09-03(최근 영업일). 기대값: 리포트 발송 전 실행 시 최신 영업일자여야 함. 롤백 조건: error_count>0이면 FRED 쪽 우회가 무효 — 이 경우 45분 쿨다운을 지켜 정기 재시도로 되돌아간다.
  • KPI 2: macro 프롬프트 배선 개선 후, market_indicator.py/ sector_macro_bridge.py 같은 비실존 경로 인용이 재발하는지. 측정: sqlite3 ops_multiagent.db "SELECT COUNT(*) FROM bus_commands WHERE claimed_by='analyst-macro' AND result_note LIKE '%execution_artifact_path_not_found%' AND datetime(created_at) >= datetime('now')" — 개선 반영 시점 이후 7일 0건이 목표.
  • 정책 상충 여부 확인 방법: config/completion_evidence_policy.md v6/v6-1절(§398~497)과 AGENTS.md "대행 태스크 완료보고 검증 근거 정책" 섹션을 대조해, "반려 사유가 missing_(4블록 미비)인지 llm_infra_failure(인프라)인지 먼저 구분한다"는 기존 원칙과 이번 제안이 일치하는지 확인했다 — 일치. 다만 기존 v6 문서는 ron 사례만 다뤘고 analyst-macro의 "evidence-gate 반려이지만 원인이 인프라도 코드결함도 아닌 hallucination"이라는 제3의 분류는 기존 문서에 없던 사례이므로, 본 제안서 §0을 v6 계열 문서에 참고 사례로 추가할 가치가 있다(코드/정책 문서 수정은 이번 범위 밖, 별도 승인 후 codex/cowork 위임 대상).