AI 하네스(harness) 브리지가 매 턴 대화를 통째로 재전송한다 — 캐시 적중률 급락 근본원인 추적기

오후 3시 13분, 도움을 청하는 메시지로 시작됐다

오후 3시 13분, 한 참여자가 페이블(Fable, 클로드 계열 모델) 라우팅 설정을 고정해뒀는데도 서브에이전트가 자꾸 다른 모델을 호출하면서 세션 대화가 계속 다시 로드된다고 토로했다. 그는 이 문제를 고쳐달라고 요청했지만, 곧바로 스스로 원인 추적에 나섰다.

"페이블5 라우팅 설계 검토만 고정했는데 서브에이전트가 실수하면서 fable 호출 자주하고 세션 대화 계속 리로드 하는거 고쳐줘 ! 했는데 고정이 잘 안되는데 설정 하는 방법이 있을까욥..?"

1분 만에 처음 진단이 나왔다

같은 시각, 이 참여자는 스스로 분석한 결과를 곧바로 공유했다. 검증되지 않은 설정 수정이 페이블을 기본 모델로 지정했고, 새로 생긴 세션 브리지가 매 턴 전체 대화를 다시 전송하면서 실제 실행의 85.89%가 오푸스 5로 대체돼 앤트로픽 쪽 사용 한도를 소진시켰다는 진단이었다.

"Sol 설정 세션이 검증되지 않은 resident 수정에 근거해 Fable을 기본 모델로 만들었고, 새 세션 브리지가 매 턴 전체 대화를 다시 전송했으며, 그 Fable 선택 세션의 실제 실행 85.89%가 Opus 5로 대체되어 Anthropic 한도를 태웠다."

근본 원인은 '기억력'이 아니라 '재전송 구조'였다

8분 뒤 진단은 한 단계 더 정밀해졌다. 그는 문제의 핵심이 페이블이 대화를 잘 기억하지 못하는 게 아니라, 브리지가 매 턴마다 전체 대화 기록을 새 입력으로 재조립해 클로드 쪽으로 다시 보내는 구조 자체에 있다고 짚었다. 관련 구현 경로까지 특정하며, 이전 진단에서는 세션 처리 방식 탓에 매번 새로 시작되는 문제로 정리했었다고 덧붙였다.

"Senpi→Claude 브리지가 매 턴 전체 대화를 새 입력으로 재조립해 보낸 것이 핵심 원인이었다."

이 설명을 들은 다른 참여자는 숫자의 의미를 짚었다. 실행의 85%가 오푸스로 넘어갔다면 나머지 15%만 페이블이 처리한 셈이고, 이는 사실상 보조 모델이 주력 모델의 부담을 떠안는 '폴백' 상태와 다르지 않겠느냐는 추측을 보탠 것이었다.

"85프로를 오푸스로 수행했다면, 15프로는 페이블이 했다는 뜻인가요? 그럼 검사기 폴백같은데.. 이건 해결법이 없는"

진단은 끝났지만 해결은 남았다

실측까지 곁들여 코드 경로를 짚어낸 진단은 상당히 정밀했지만, 정작 본인은 자신의 지식수준으로는 고칠 수 없다며 아쉬움을 표했다. 라우팅 설정을 원래대로 되돌려도 증상이 이어졌다는 언급도 있어, 문제가 단순 설정값이 아니라 브리지 코드 쪽에 있을 가능성을 뒷받침한다. 대화가 길어질수록 캐시 재사용률이 떨어지는 구조라면, 이는 한 번의 사고가 아니라 이 브리지를 쓰는 모든 장시간 세션에서 반복될 수 있는 구조적 결함으로 보인다.