needs_evidence 75건·failed 4건 적체 원인 분류 (조회 2026-10-26 01:17~01:30 KST, sqlite3 -readonly, DB·코드 변경 없음)

조회 대상은 /Users/ron/.hermes/data/ops_multiagent.db 의 bus_commands 중 status='needs_evidence' 75건과 status='failed' 4건(#42683, #42685, #42687, #42688, 모두 guardian)이다. 합계 79건. 반려 사유의 1차 근거는 result_note의 "차단 사유" 칸과 게이트 로그(/Users/ron/.hermes/workspace/logs/completion_evidence_blocked.jsonl, 79건 전부 매칭)다. result_note는 900자 미만으로 잘려 저장돼서 에이전트 원문은 /Users/ron/.hermes/logs/agent-queue-*.log 에서 79건 전부 복원해 확인했다.

1. [권고]

→ 1순위: 서버 프로세스 재시작 + 게이트 코드 2곳 수정 (codex 위임, 해리 승인 후 재시작). 적체의 직접 원인은 guardian이 일을 못 하는 것이 아니라, 게이트가 "결과 확인 보류" 같은 금지문구를 에이전트 본인의 인용문에서도 찾아 반려하는 것이다. 79건 중 B유형(금지문구 매치) 34건과 A유형(exit code 판정) 30건, 합 64건(81%)이 이 때문이다. 근거: 실행 중인 서버 프로세스(PID 15335, 2026-09-28 09:17 기동)가 10-19 수정본이 아니라 옛 코드를 쓰고 있을 가능성이 있다(아래 3-3 참조). 기대효과: 신규 반려 일 평균 2.7건(75건/28일), 최근 7일은 23건(≈3.3건/일) → 0~1건. → 2순위: "needs_evidence N건 …집계" 계열 메타 태스크의 재발행 중단. 제목에 건수가 든 메타 태스크가 79건 중 53건(67%)이다. 이 태스크가 반려되면 건수가 +1 되고, 다음 라운드에 "N+1건 집계"가 다시 발행되는 폐회로다. 10-19에 넣은 재발행 루프 차단 게이트가 이 계열을 한 번도 막지 못했다(로그 ron_orchestrator.log 에 NEEDS_EVIDENCE_REISSUE_LOOP_BLOCKED 0건). 기대효과: 53건 계열 신규 발행 일 ~2건 → 0건.

2. [현황]

2-1. 에이전트별 × 반려 유형 (79건, 게이트 로그 최신 reasons 기준)

에이전트	건수	A exit code 누락/무효	B 금지문구 매치	C result_or_verification	D 경로 미존재	E 기타
guardian	59 (needs 55 + failed 4)	25	31	0	1	2
cowork	9	4	3	1	0	1
analyst-macro	6	0	0	6	0	0
analyst-pm	4	0	0	4	0	0
ron	1	1	0	0	0	0
합계	79	30	34	11	1	3

(A = missing/invalid_verification_exit_code, B = "결과 확인 보류"·"검증 근거 없음"·"결과물과 검증 근거가 없음" 등 문구, C = missing_result_or_verification/completion_result_note_forces_rework, D = execution_artifact_path_not_found, E = missing_execution_artifact·missing_verification_command·verification_command_unverifiable)

2-2. 요청서가 예시로 든 사유 라벨의 실제 건수

차단 사유 칸 기준: missing_source 0, missing_execution_value 0, missing_verification_value 0, missing_original_verification 0, llm_infra_failure 0, execution_artifact_path_not_found 5, missing_source_log_path 2(이 둘은 result_note 본문의 인용 포함 수치).
result_note 본문에 글자만 나오는 건: llm_infra_failure 19건, missing_source 3건, missing_execution_value 1건. 전부 "인프라 문제가 아니다"처럼 앞선 분석 보고를 인용한 문장이다. 즉 인프라 지연으로 반려된 건은 0건이다. 이전 집계(#42680)의 결론과 일치한다.
79건 모두 1회 반려(같은 CMD가 로그에 2번 이상 막힌 이력 0건). 재시도로 풀리지 않고 그대로 쌓이는 구조다.

2-3. guardian의 4블록 미사용 vs 실행 안 함 (질문 2)

guardian 59건의 에이전트 원문을 로그에서 복원해 확인: 4블록 라벨(결론/근거/검증/근거파일) 4개를 모두 쓴 건 56건(95%), 3개만 쓴 건 3건(#41323, #42685, #42687, 모두 '근거:' 줄 없음). "exit code 0"을 명시한 건 58건.
실행 흔적(sqlite3, SELECT, 조회, .py 경로 등)이 있는 건 59건 전부. 즉 실행을 안 한 것이 아니고, 4블록을 안 쓴 것도 아니다. 실제로 일을 하고 서식도 맞췄는데 게이트가 반려했다.
예시: #42640 원문은 4블록 전부 + "통과, exit code 0" 포함인데, 게이트 로그 reasons는 ['검증 근거 없음','결과물과 검증 근거가 없음','결과 확인 보류']였다. 이 문구들은 원문 속에서 "원본 요약/인용"으로 쓰인 것이다.
42688, #42683(failed)도 동일 패턴이다. 실제 4블록 모두 있는 3,136자 원문이 "결과 확인 보류, 근거 없음" 문구 매치로 failed 처리됐다.
진짜 서식 문제는 3건뿐(#41323, #42685, #42687). #42685·#42687은 근거 줄이 없고 인용 경로(scripts/research-sales-engine/..., /Users/ron/.hermes/workspace/jobs.json)가 실존하지 않아 path_not_found가 맞는 반려다.
42645는 요청서 예시였으나 guardian 건이 아니다. codex 완료보고가 반려된 건(status=failed, claimed_by=codex, bus_commands_archive)이며 이번 79건에 들어 있지 않다. 사유는 source_log_path_not_found + verification_command_unverifiable(인용 원본로그 경로를 <원본로그경로> 자리표시자로 남김).
42688은 지시문의 "최근 7일"과 75건이 맞지 않는다. 75건은 전체 기간(09-28~10-26)이고 최근 7일(10-19 이후 생성)은 23건이다. 지시문의 숫자 오류가 보고서 설명을 길게 만드는 보조 원인이다.

2-4. 시간 추이 (guardian)

09-28~10-12: 26건 (A 16, B 10)
10-13~10-26: 33건 (B 21, A 9, D 1, E 2) → A는 줄었으나 B가 2배로 늘었다. 10-19 이후 보강된 "근거 문구 인용 금지" 안내가 오히려 인용문 반려(B)를 늘렸다.

2-5. 중복 발행 (질문 3)

정확히 같은 제목 반복은 0건(79개 제목 모두 서로 다름). 그러나 숫자·괄호를 지운 계열로 묶으면 같은 질문이 반복된다.
"needs_evidence N건 반려 사유·에이전트별 분포 집계": #40902(10-05), #42165(10-20), #42680(10-25)
"needs_evidence N건 에이전트별·사유별 분류 집계": #41316(10-10), #42640(10-25)
"needs_evidence N건 반려 사유·담당 에이전트별 분류": #41494(10-12), #42062(10-19)
유연하게 보면 제목에 needs_evidence/반려/적체가 들어간 메타 태스크가 61건(+현재 이 작업 #42690)이고, 그중 58건이 needs_evidence 상태다. 건수 추이: 7건(10-04) → 22건(10-09) → 36건(10-12) → 52건(10-19) → 65건(10-22) → 75건(10-26). 적체의 약 77%(58/75)는 "적체를 분석하라"는 태스크 자신이 반려돼 쌓인 것이다. 사업 업무(주간 크레딧, US IG OAS, 지식사랑방 등) 반려는 17건이다.
재발행 제목 접두사("재발행", "재수행", "보강", "재점검")가 붙은 건은 7건(#40346, #40994, #41323, #41377, #41385, #41498, #41628).
시뮬레이션: orchestrator._reissue_family_key() 로 guardian 반려 59건을 계열화하면 55계열이고, 10-19 이후 발행분 25건은 각 계열의 직전 반려 이력이 0건이라(3회 임계 미달) 게이트가 한 번도 걸릴 수 없는 구조다.

3. [리스크]

3-1. 게이트가 인용문을 에이전트의 자백으로 오인 (구조적, 주원인)

scripts/server.py 의 _COMPLETION_STORAGE_HARD_BLOCK_PATTERNS(687행~709행, "결과 확인 보류" 706행, "검증 근거 없음" 704행)는 원문 전체를 정규식으로 훑는다. 공유 모듈 shared/public_result_formatter.py 의 strip_quoted_citations() 는 따옴표로 감싼 인용만 제외한다. 분석 보고는 지시문에 따라 "원문 1줄 인용"을 반드시 넣고, 그 인용이 반려 사례의 result_note 문구("결과 확인 보류", "근거: 결과물과 검증 근거가 없음…")다. 직접 재현: 로그에서 복원한 #42640 원문 → server._completion_storage_block_reasons() = ['검증 근거 없음','결과물과 검증 근거가 없음','결과 확인 보류'], 같은 원문을 canonical completion_required_evidence_gaps() 에 넣으면 gaps=[] 이고 completion_result_note_forces_rework()=False 다. 두 게이트가 서로 다른 결론을 낸다. #42680은 같은 호출에서 reasons=[]로 통과하는데도 실제로는 needs_evidence로 저장됐다. 이는 현재 디스크 코드와 실제 저장 결과가 다르다는 뜻이다(3-3).

3-2. 메타 조사 예외가 근거 2개를 앞 600자 안에서만 센다

shared/public_result_formatter.py _completion_has_meta_investigation_report() (756~783행)는 "결론:"~"근거:" 사이와 "근거:" 이후 각 600자만 읽는다. 집계 보고는 결론 길이가 길고 근거 줄이 뒤에 오는 경우가 많다(#42680 원문은 2,716자). 증거가 600자 밖에 있으면 예외가 적용되지 않는다.

3-3. 실행 중 프로세스가 디스크 코드보다 오래됨 (확인 필요 사항)

scripts/server.py 수정시각 10-19 15:06, 실행 중 server.py 프로세스(PID 15335)는 09-28 09:17 기동. 게이트 로그 surface 필드가 server.close_bus_command 인 건이 75건이고 worker 경로는 4건뿐이다. 즉 반려의 거의 전부가 server.py의 close_bus_command()(3038행)에서 일어난다.
scripts/orchestrator.py 수정 10-19 21:01, 실행 중 orchestrator.py --loop(PID 46446)는 09-27 07:55 기동. 10-19에 추가된 _is_needs_evidence_reissue_loop_tripped()(4330행)가 이 프로세스에 로드됐다면 로그에 BLOCKED가 있어야 하는데 /Users/ron/.hermes/logs/ron_orchestrator.log 에서 0건이다. 로드되지 않았거나 조건에 걸리지 않았다는 뜻이다. 어느 쪽인지는 이번 조회로 구분하지 못했다(미확인). 시뮬레이션상으로는 3-5절처럼 조건에 걸릴 수 없는 구조이므로, 로드 문제와 설계 문제가 둘 다일 수 있다.
에이전트 워커 3개(guardian PID 3974 09-29, cowork 9235 등)도 같은 이유로 10-25 14:47 수정분(agent_queue_worker.py, public_result_formatter.py)을 아직 안 읽었을 가능성이 있다. 이 부분도 미확인이다.
재시작은 사전 해리 승인이 필요하다(웹앱/큐 프로세스를 내리기 때문).

3-4. 반려가 새 태스크를 낳는 폐회로

반려된 메타 태스크가 건수를 올리고 오케스트레이터가 "N+1건 …" 태스크를 새로 발행한다. 재발행 차단 게이트는 (a) 같은 계열에서 3회 반려 + 지시문 유사도 0.9 이상일 때만 동작하는데 제목이 조금씩 달라(계열 키가 60자로 잘림) 임계에 도달하지 못하고, (b) requested_by == 'orchestrator' 일 때만 적용되며, (c) 다른 에이전트(cowork)로 우회된 건은 별도 계열로 센다.

3-5. 오탐 가능성 낮은 진짜 반려

D(경로 미존재 1건)와 E(3건), 그리고 analyst-macro 6건·analyst-pm 4건(C유형: 모두 "결론/근거" 라벨은 있으나 missing_result_or_verification)은 서식·검증 줄 부족이 실제 사유일 가능성이 있다. 이 10건은 원문에 exit code 명시가 있는 건(analyst 10건 전부 exit0 표기)이라 게이트 판정 기준(결과물 경로 + 검증 명령 + exit code 3요소)을 더 확인해야 하며, 이번에는 원인을 단정하지 않는다.

4. 코드 수정이 필요한 지점 (제안만, 이번에 수정하지 않음 — codex 위임용)

scripts/server.py _completion_storage_block_reasons() (854행~) 및 _COMPLETION_STORAGE_HARD_BLOCK_PATTERNS (687행~): 하드블록 정규식 스캔 전에 strip_quoted_citations()·"원본 요약:/인용" 구간 제거를 적용하고, canonical completion_result_note_forces_rework() 와 판정이 갈리면 canonical을 따르도록 통일. 검증: #42640, #42684, #42688 원문을 입력해 reasons가 []로 나오는 테스트 3개.
scripts/shared/public_result_formatter.py _completion_has_meta_investigation_report() (756행~): 근거 스캔 창을 600자 → 전체 본문(또는 2,500자)로 확대. 검증: 결론이 긴 집계 보고 샘플이 meta_hits>=2 로 통과.
scripts/orchestrator.py _reissue_family_key() (4301행)·_is_needs_evidence_reissue_loop_tripped() (4330행): 제목에 needs_evidence/반려/적체가 포함된 메타 계열은 임계 3 → 1, 동일 시각 claimed/needs_evidence 가 1건이라도 있으면 신규 발행 금지. 또 requested_by 조건을 완화해 대행·재라우팅 건도 계열에 포함.
scripts/server.py close_bus_command() (3038행~): 저장되는 result_note가 900자에서 잘려 "원본 요약" 220자만 남는다(79건 모두 확인). 반려 사유와 함께 에이전트 원문 앞 600자를 남기도록 길이 상한 조정(운영자가 사후 판정 가능).
오케스트레이터 프롬프트(메타 집계 태스크 본문 생성부): 건수가 들어간 "needs_evidence N건 분류" 태스크를 자동 발행하지 말고, 하루 1회 고정 크론(읽기 전용 집계 스크립트)으로 대체. 이 부분은 설계 변경이라 해리 확인 후.

5. 운영 조치 (코드 아님, 해리 확인 필요)

서버(server.py)·오케스트레이터(orchestrator.py --loop)·guardian/cowork 워커 재시작: 3-3의 미확인 사항을 확인하려면 재시작 전후 같은 원문(#42640)으로 close_bus_command 판정을 비교해야 한다. 재시작은 해리 승인 후에만.
75건 정리: 79건 중 메타 태스크 58건은 사업 산출물이 없고 내용 대부분이 서로 겹친다(각 집계가 이전 집계와 같은 질문). 해리가 승인하면 상태 정리(archive 이동)가 가능하나, DB 변경이라 이번에는 하지 않았다.

6. [검증방법]

지표 1: needs_evidence 총건수. 명령: sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT count(*) FROM bus_commands WHERE status='needs_evidence'". 현재 75 → 코드 수정·재시작 후 7일 동안 신규 증가 ≤ 5건이면 성공.
지표 2: 인용문 오탐. 명령: grep -c '"routed_status": "needs_evidence"' /Users/ron/.hermes/workspace/logs/completion_evidence_blocked.jsonl 의 일별 증가가 하루 1건 이하. 기대값: 증가 0~1.
지표 3: 메타 계열 재발행. 명령: grep -c NEEDS_EVIDENCE_REISSUE_LOOP_BLOCKED /Users/ron/.hermes/logs/ron_orchestrator.log 가 1 이상으로 오르고, 제목에 "needs_evidence N건"이 있는 신규 bus_commands가 하루 0~1건.
지표 4: 오탐 재현 테스트. #42640·#42684·#42688 원문을 close_bus_command 입력에 넣어 status=done 으로 저장되는지 확인(테스트 DB 사용).
롤백 조건: 수정 후 24시간 안에 '근거 없는 완료'가 done 으로 저장된 사례가 1건이라도 나오면(예: 4블록 라벨이 비어 있는 note가 done) 수정 취소. 이 때 completion_evidence_blocked.jsonl 의 reasons 로 판정.
이번 보고서의 한계: 에이전트 워커·서버 프로세스가 실제로 어떤 코드 버전을 메모리에 올렸는지는 확인하지 못했다. 재시작 영향은 미검증이다.

needs_evidence 75건·failed 4건 적체 원인 에이전트별 분류와 방지안