멘탈 모델 수요 신호를 reflect에서 읽기 호출로 옮겼다

멘탈 모델이 쓰이는지 재려고 reflect 호출마다 감사 줄을 남겼다.
그 줄은 모두 10개였고 마지막은 9월 28일이었다.
같은 기간에 멘탈 모델을 그대로 읽는 get_mental_model은 계속 불렸다.
수요는 읽기 쪽에 있었는데 신호는 reflect에서 재고 있었다.
그래서 계측을 고친 일은 오지 않는 호출을 더 정밀하게 잰 일이 됐고
신호가 돌아온 것은 수요가 왜 적은지 묻고 세는 호출을 바꾼 뒤였다.

문제

Hindsight는 에이전트의 기억을 쌓는 오픈소스 메모리이고
멘탈 모델은 그 기억을 태그별로 미리 요약해 둔 문서다.
get_mental_model은 이 문서를 LLM(언어 모델)을 거치지 않고 그대로 읽는다.
reflect는 기억을 검색해 LLM이 추론한 답을 돌려주고
응답에 담긴 근거 목록(based_on)에는 멘탈 모델을 썼는지가 기록된다.

9월 21일, 멘탈 모델의 역할을 "세션 부팅 팩"에서
"reflect 1차 캐시"로 넓히면서 수요도 reflect에서 재기로 했다.
게이트웨이가 reflect마다 감사 줄을 남기고
주간 감사는 7일 동안의 호출 수와 태그 분포, 히트율을 산출한다.
모델이 없는 태그로 들어온 reflect는 새 모델을 만들 후보 1순위가 된다.
근거 목록이 빠진 응답은 미스로 세지 않고 unknown으로 따로 셌다.

그런데 사흘 전인 9월 18일, 나는 에이전트 지침 파일에 두 줄을 더해 두었다.
작업이 프로젝트에 속하면 시작할 때 그 멘탈 모델을 get_mental_model로 읽고
reflect는 판단·충돌 판정·패턴 질문에만 쓴다는 줄이다.

사실 조회·최신 기록은 recall, 요약 적재는 get_mental_model이 정답 -
reflect는 가장 비싼 경로다.

소비는 읽기 쪽으로 돌려 놓고 수요는 reflect에서 재기로 한 셈이다.
신호를 재기로 정한 경로와 실제로 쓰이는 경로가 갈라져 있다면, 이 글에서 다루는 상황과 같다.

설계가 가정한 호출이 오지 않았다

reflect 감사 줄은 첫날 넷, 9월 25일에 다섯, 9월 28일에 하나가 찍히고 끝났다.

unknown 7건 중 REST 1건은 upstream이 근거 목록을 돌려주지 않는 경로였고
MCP 6건은 호출하는 쪽이 근거 목록을 요청하지 않은 탓으로 봤다.
9월 25일에 찍힌 다섯 줄은 해당 태그의 모델이 이미 있었는데도 서빙 목록이 비어 있었다.
주간 감사가 낸 히트율 0.667은 판정할 수 있는 3건에서 나온 값이다.

호출이 적다는 사실은 첫날 이미 나와 있었다.
9월 21일 세션에서 에이전트는 6월 말부터 9월 13일까지
reflect가 3회뿐이라는 실측을 근거로, 멘탈 모델을 실제로 쓰는 쪽은
세션 시작 때의 적재라고 제안했다. 나는 2분 뒤 이렇게 답했다.

리플렉트 호출횟수가 적은이유는 붙인지 몇일안돼서그래.
그 실측내용은 제외하고 다시 제안해.
리플렉트를 안쓰고있었고, 이제는 좀더 하인드사이트답게 리플렉트를 써보려해.

그 제안으로 돌아오기까지 3주 남짓 걸렸다.

계측을 고쳤지만 관찰 창에는 호출이 없었다

10월 1일, unknown을 줄이는 일은 게이트웨이가 맡기로 했다.
"형식은 게이트웨이가 강제하고 프롬프트에 중복하지 않는다"는
원칙을 따른 결정이다. MCP reflect에 include_based_on이 없으면
게이트웨이가 true로 채워 보내고, 감사 줄에는 upstream 원본 응답의
hit/miss를 남긴다. 게이트웨이가 값을 채운 호출이면 응답에서 근거 목록을 다시 지운다.

배포 시각부터 7일을 관찰 창으로 잡았고
그 안에 MCP reflect 줄이 10건 미만이면 표본 부족으로 판정하기로 했다.
창이 닫혔을 때 그 줄은 0건이었다.
판정 결과는 "표본 부족"이었고, 완료 기준 두 가지는 판정하지 못했다.

다시 세어 보면 감사 줄 바깥도 비어 있다.
9월 28일 이후로는 허용된 줄로도 거부된 줄로도 reflect 도구 호출이 남아 있지 않다.
반면 같은 창이 열린 뒤 10월 19일까지 허용된 get_mental_model은 56건이다.
근거 목록을 빠짐없이 받도록 고친 계측은 오지 않는 호출을 기다리고 있었다.

같은 시기의 다른 0

같은 시기에 0이 두 번 더 나왔고, 셋은 뜻이 달랐다.

cached_tokens 0은 upstream이 응답을 변환하면서 입력·출력·합계 토큰만 넘겨서 생긴
집계 버그였다. Hindsight 이슈 5487로 제보했고
10월 16일 Hindsight PR 5675가 머지되며 닫혔다.
운영 환경에 고정해 둔 v1.0.0에는 이 수정이 아직 들어 있지 않다.

센 호출을 바꿨다

10월 14일 새벽, 열린 이슈를 점검하다가 이 측정 이슈에 이르러 이렇게 물었다.

54의 경우는 좀더 생각해보자. 리플렉트 수요가 왜 별로없을까?

에이전트는 게이트웨이를
거친 reflect가 전부 10건이라는 실측과 원인에 대한 판단 세 가지를 내놓고
이슈를 "관찰 대상 소멸"로 닫은 뒤 신호를 get_mental_model로 옮기는 안을 권했다.
나는 "ㅇㅇ 그렇게하자."라고 답했다.

종결 댓글에 적힌 원인은 세 가지다. 9월 18일 지침이 reflect의 용도를 좁혔고
호출하는 쪽이 Opus급 에이전트라 reflect 1회에 입력 약 3만 토큰을 쓰느니
recall 결과로 직접 추론하는 편이 빠르며 세션 시작 때의 적재가
요약 수요를 흡수했다는 것이다(셋 다 에이전트의 판단이고 따로 재지 않았다).
댓글은 9월 30일 이후 retain 약 400, recall 275, get_mental_model 32,
reflect 0을 적고 "계측 결함이 아니라 의도한 설계의 결과다."라고 정리했다.

바꾼 범위는 작다. 허용된 get_mental_model 감사 줄에 요청한 모델 id를 싣고
주간 감사에 호출 수, 모델별 분포, id 없는 옛 줄 수, 없는 id 요청 수를 더했다.
reflect 쪽 집계는 그대로 두었다. 측정하려고 일부러 부르는 호출은
만들지 않는다고 못 박았고 이유는 "수요 신호를 오염시킨다"였다.

id는 10월 15일 19:39 UTC 줄부터 실렸고 그 뒤의 24건은 모두 id를 달고 있었다.
10월 19일 감사에 잡힌 31회는 bk-rules-bkan-blog 9,
bk-rules-hindsight-crew 8, 다른 프로젝트 모델 4, 지금은 없는 bk-rules-vault 1이고
나머지 9회는 id가 없는 옛 줄이라 모델별로 나뉘지 않았다.

결론

계측을 정밀하게 고친 일보다 수요가 왜 적은지 물은 일이 신호를 되살렸다.
신호를 정한 뒤에 다른 결정이 소비 경로를 옮기면, 그 신호는 고장 난 곳 없이도 점점 비어 간다.
신호가 0으로 떨어지면 계측을 손보기 전에,
그 신호를 정한 시점 앞뒤로 소비 경로를 바꾼 결정이 있었는지부터 본다.
이번에는 그 결정이 신호보다 사흘 먼저 있었다.

한계·재검토 트리거

옮긴 신호도 이미 있는 모델이 읽히는지만 보여 준다.
주간 감사는 수요 후보를 reflect 호출의 태그에서만 만들고
읽기 호출은 수와 분포로만 센다. 그래서 같은 실행에서 31회를 세고도 결과는 이렇게 나왔다.

MODEL_AUDIT_OK candidates=20 demand=0 size_warn=0 reflect_calls=0

모델이 없는 태그에 대한 필요는, 없는 id를 요청한 수와
기억 태그에 쌓인 규칙·결정 수로 따로 만드는 공급 후보로만 잡힌다.
읽힌 수와 쓰인 수도 다르다. 스크립트·검증 호출이 섞였을 수 있고
10월 18일에는 갱신이 시간 제한에 걸려 모델 둘이 비었는데
그 모델을 읽어도 오류 없이 빈 문자열만 돌아왔다.
근거 목록을 채우는 게이트웨이 수정이 실제 호출에서 어떻게 동작하는지도 아직 재지 못했다.

2026-10 기준 / 재검토 트리거: 게이트웨이 감사 로그에 MCP reflect 감사 줄이 다시 찍힐 때

참고

• Hindsight 이슈 5487 - reflect 응답의 cached_tokens 0 제보
• Hindsight PR 5675 - 토큰 사용량 누락 수정
• Hindsight-Crew 소개 글 - 게이트웨이 소개