애널리스트 실패 재시도 운영 기준 초안

작성시각: 2026-09-19 18:31 KST 대상: analyst-macro 요청과다 보류, analyst-technical 결과물·검증근거 없음 실패, 최근 failed 9건 분류 결과 수신 시 적용 범위: 코드 변경 없음. 재발행·보류·프롬프트 보정 기준만 정리.

1. [권고]

→ 1순위: failed 9건을 “즉시 재발행 금지 / 수정 후 재발행 / 상류 모델 타임아웃 보류” 3분류로 먼저 나눈다. 같은 데이터 태스크를 그대로 다시 넣으면 요청과다와 근거 없음 실패가 반복되므로, 재발행 전 차단 기준을 고정한다. 기대효과: 동일 원인 재실패 9건 중 최소 6건 이상 차단, 재시도 낭비 60% 이상 축소.

→ 2순위: analyst-technical은 결과물 경로와 검증 4블록이 없으면 프롬프트·증거게이트 문구를 먼저 보정한 뒤 재발행한다. analyst-macro는 요청과다·모델 지연이면 새 데이터 수집을 즉시 반복하지 말고 쿨다운 후 1회만 재시도한다. 기대효과: 근거 없음 반려율을 0건 목표로 낮추고, 요청과다 연쇄 실패를 1회 보류로 제한.

2. [현황]

• 적용 대상: 최근 failed 9건.
• 핵심 실패군 3개: 요청과다 보류 1군, 결과물·검증근거 없음 1군, 상류 모델 타임아웃 1군.
• 기준 문서: /Users/ron/.hermes/workspace/config/agent_completion_submission_standard.md 는 완료보고에 결론/근거/검증/근거파일 4블록을 요구한다.
• 이전 기준 대비 변화: “실패하면 재발행”에서 “원인별로 재발행 가능 여부를 먼저 판정”으로 변경.

3. [운영 기준]

가. 같은 데이터 태스크를 즉시 재발행하지 말아야 하는 조건

1. 같은 원천·같은 날짜·같은 지표를 다시 조회하는 태스크인데 실패 사유가 analyst-macro 요청과다, 429, rate limit, quota, cool down, too many requests 중 하나일 때.
2. 이전 실행이 원천 API 호출 직후 실패했고, 로컬 캐시나 기존 산출물 확인 없이 동일 요청을 반복하려 할 때.
3. failed 9건 중 같은 제목·같은 대상·같은 데이터 날짜가 2건 이상 겹칠 때.
4. 실패 결과에 “결과 없음”만 있고, 실제로 원천 데이터가 비었는지 또는 프롬프트가 잘못됐는지 구분되지 않았을 때.

적용 예시: analyst-macro가 같은 거시지표 묶음을 5분 안에 다시 호출해 요청과다로 실패했다면 즉시 재발행하지 않는다. 기존 저장 파일과 로그를 먼저 확인하고, 30분 이상 보류 뒤 1회만 재시도한다.

나. 프롬프트·증거게이트 수정 후 재발행해야 하는 조건

1. analyst-technical 결과에 차트·표·파일·요약 산출물 경로가 없을 때.
2. 완료보고에 결론/근거/검증/근거파일 중 하나라도 없거나, “정상 확인”, “처리됨” 같은 말만 있을 때.
3. 검증 명령은 적었지만 실제 결과값, 건수, 통과 토큰, 파일 줄번호 인용이 없을 때.
4. 지표 계산형 태스크인데 입력 데이터 기간, 계산식, 출력 파일 중 하나가 빠졌을 때.

적용 예시: analyst-technical이 RSI/MACD 판단을 냈지만 저장 파일과 검증값이 없으면 같은 태스크를 바로 재발행하지 않는다. 먼저 프롬프트에 “산출물 경로, 계산 입력기간, 검증 결과값, 근거파일 인용”을 필수로 넣고 재발행한다.

다. 상류 모델 타임아웃으로 보류해야 하는 조건

1. 실패 원인이 모델 응답 지연, upstream timeout, gateway timeout, llm_infra_failure, 모델 큐 지연으로 표시될 때.
2. 에이전트가 실행을 시작했지만 결과 텍스트 생성 전에 끊긴 흔적만 있을 때.
3. 데이터 원천과 프롬프트에는 결함이 없고, 같은 시각 다른 모델 호출도 지연됐을 때.
4. 재시도해도 같은 상류 모델을 즉시 다시 쓰는 구조일 때.

적용 예시: analyst-macro가 데이터 조회 전후가 아니라 모델 응답 단계에서 끊겼다면 failed 9건 분류표에는 “상류 모델 타임아웃 보류”로 둔다. 30~60분 뒤 모델 상태를 확인하고, 필요하면 더 가벼운 요약 프롬프트로 1회 재발행한다.

4. [리스크]

• 단일 장애점: analyst-macro가 같은 상류 모델과 같은 원천 API에 동시에 의존하면 요청과다와 타임아웃이 함께 난다.
• 구조적 위험: analyst-technical은 산출물 경로 없이 판단문만 내도 사람이 보기엔 답처럼 보이지만, 증거게이트 기준으로는 실패다.
• 의존관계: failed 9건 분류가 들어오기 전에는 개별 건을 추측 재발행하지 않는다. 분류표의 실패 라벨, 원천, 데이터 날짜, 산출물 존재 여부를 먼저 본다.

5. [검증방법]

• 측정 지표: 재발행 전 9건 전부가 3분류 중 하나로 라벨링됐는지 확인한다. 기대값 9/9건.
• 재발행 허용 기준: “수정 후 재발행” 라벨에는 수정된 프롬프트 또는 4블록 증거 보강 문구가 붙어 있어야 한다. 기대값 100%.
• 보류 기준: 요청과다와 상류 모델 타임아웃은 즉시 재발행 0건이어야 한다.
• 롤백 조건: 수정 후 재발행한 태스크가 다시 “근거 없음”으로 2건 이상 실패하면 재발행을 멈추고 프롬프트·증거게이트 기준을 다시 고친다.

통과 토큰: RETRY_STANDARD_OK