질문
같은 recall이 60초 안에 다시 온 쌍이 44쌍 나왔다.
recall은 에이전트가 Hindsight 메모리 뱅크에서 기억을 꺼내는 조회다.
이 숫자만 보면, 방금 낸 결과를 잠깐 보관해 두었다가
그대로 돌려주는 결과 캐시가 효과를 볼 것처럼 보였다.
그런데 44쌍 중 33쌍은 한 세션이 이어서 부른 순차 loop였고
앞 요청이 끝나기 전에 같은 요청이 겹친 동시 중복은 2쌍이었다.
그래서 결과 캐시도, 겹친 요청을 조회 한 번으로 합치는 장치도 만들지 않았다.
중복 호출이 많아 보여서 캐시부터 붙이려는 상황이라면 같은 갈림길에 선 셈이다.
판정을 가른 것은 중복의 크기보다 중복이 어디서 왔느냐였다.
판정
결과 캐시와 요청 합치기는 만들지 않는다.
Hindsight-Crew 분석 보고서(81번 이슈)가 이렇게 추천했고
캐시를 보류해 둔 76번 이슈도 이 결론에 따라 만들지 않는다고 적고 닫았다.
클라이언트 쪽 조치도 코드를 고치는 데까지 가지 않는다.
어느 클라이언트가 같은 조회를 반복했는지 출처를 확인하는 데서 멈춘다.
60초 안의 중복 44쌍은 상시 부하가 아니라 대부분 하루 동안 한 세션이 남긴 흔적이었다.
loop 33쌍을 빼면 11쌍(reusable의 3.4%)이 남고
이 11쌍도 같은 날에 몰려 있다.
캐시가 11쌍을 전부 맞혀도 아끼는 시간은 보고서 어림으로 약 1분이다.
그 1분을 위해 모든 쓰기 경로에 무효화를 거는 장치를 만들 이유는 없었다.
근거
같은 요청을 무엇으로 셀지 먼저 정하고, 그다음 중복을 출처별로 갈랐다.
같은 요청의 키는 쿼리, 태그 집합, 태그 일치 방식(tags_match) 셋이다.
| 주장 | 실측 | 측정 조건 |
|---|---|---|
| 반복은 하루에만 있었다 | 1시간 이내 반복 58쌍 전부 2026-09-22, 나머지 10일 0쌍 | 원장 UTC 날짜 기준, 그날 reusable 103행·나머지 218행, 쌍 사이 retain 없음 |
| 60초 이내 중복의 대부분은 loop | 44쌍 중 33쌍 | 같은 키가 60초 이내로 이어진 연쇄 중 5쌍 이상을 loop로 봄 |
| loop 밖 중복은 작다 | 11쌍, reusable의 3.4% | 같은 세션 2·다른 세션 5·세션 불명 4(세션 필드 없는 옛 MCP 행 3, REST 1) |
| 합치기가 줄일 호출은 거의 없다 | 확정 동시 2쌍(0.6%), 같은 초 3쌍을 더해 5쌍(1.6%) | 뒤 요청 도착이 앞 요청 응답 완료보다 이른 쌍, 나머지 39쌍은 순차 |
| 재시도에서 온 중복은 없었다 | 뒤 요청 직전 30초 안에 짝 없는 감사 로그 줄 0건 | 허용된 recall 줄 331개 중 원장 행이 없는 줄 2개 |
| 캐시 이득 상한이 작다 | 적중 44건(13.7%), 자연 발생 11건 합계 약 1분 | TTL 60초 가정, 건당 recall 지연 4~7초 |
| 키가 느슨하면 수가 부푼다 | 쿼리만 키로: 95·81·71쌍 | 같은 원장, 1시간 이내·60초 이내·같은 세션 순 |
| 훅 recall과 겹친 중복의 상한 | 45건 중 2건 | 훅 recall이 끝난 뒤 60초 안에 원장 recall, 쿼리 비교 못 함 |
같은 요청 키가 60초 이내로 이어진 연쇄의 길이(쌍 수)
11, 11, 11, 3, 3, 2, 1, 1, 1
5쌍 이상 = loop: 11 + 11 + 11 = 33쌍
33쌍 모두 한 세션, MCP, 앞뒤 간격 11~30초, 앞 응답이 끝난 뒤 도착키를 쿼리만으로 잡으면 같은 데이터에서 반복 쌍이 95, 60초 이내가 81,
같은 세션이 71로 커진다. 쿼리가 같아도 태그가 다르면 결과가 다른데,
그런 요청까지 한 요청으로 세기 때문이다. 세 요소로 된 키로 세자
76번 이슈가 적은 321·58·44·35가 그대로 재현됐다.
같은 세션 35쌍은 두 가지로 읽힐 수 있었다.
에이전트가 같은 호출을 되풀이하는 버릇일 수도 있고 한 번 실행된 스크립트일 수도 있다.
답은 연쇄 길이에서 나왔다. 11쌍짜리 연쇄 셋이 한 세션에서 고정 간격으로 이어졌고
전부 순차였다. 측정·점검 스크립트와 같은 모양이고, 날짜도 하루뿐이다.
물론 클라이언트가 실패한 요청을 다시 보낸 것이라면 합치기가 맞는 처방이다.
그러나 같은 기간의 감사 로그에서 허용된 recall 줄 331개 중
원장 행이 없는 줄은 2개뿐이었다. 원장은 성공한 응답만 적으므로
이 2개가 실패·거부·미기록 요청이다. 중복 44쌍의 뒤 요청 직전 30초 안에
이런 줄이 있던 경우는 0건이었다.
반대편에 놓인 비용은 구체적이다. 결과 캐시를 만들면 retain뿐 아니라
수정·무효화·삭제·비우기까지 모든 쓰기 경로에서 결과를 지워야 하고
태그와 budget·max_tokens 인자도 키에 넣어야 한다.
보고서는 분석이 retain 두 도구와 REST 저장만 쌍을 끊는 쓰기로 셌다고 적는다.
다른 쓰기가 끼었다면 결과가 달랐을 쌍까지 중복으로 셌으니
적중 44건은 부푼 쪽의 상한이고 이 오차는 기각 판단을 약하게 하지 않는다.
길목에서 기억을 자동으로 꺼내 붙이는 훅 recall은 원장에 남지 않는데,
그 장치는 기억한 실수를 길목에 놓았다에 적었다.
한계·재검토 트리거
이 판정의 약한 고리는 시각과 출처다.
원장의 시각은 응답이 끝난 때, 감사 로그의 시각은 요청이 도착한 때이고
둘 다 1초 단위로 내림한 UTC다. 같은 초의 도착과 완료는 선후를 가릴 수 없어서
확정 동시 2쌍과 별도로 선후 불명 3쌍을 따로 셌다.
오래 걸린 요청이 뒤 요청에 추월당했다면 동시 판정이 틀릴 수 있다.
loop 기준 5쌍은 이 데이터의 연쇄 길이에 맞춘 값이다.
기준을 4쌍에서 11쌍 사이 어디에 둬도 loop는 33쌍이지만
3쌍으로 내리면 3쌍 연쇄 2개가 더해져 39쌍이 된다.
다른 데이터에서도 이 기준이 맞는다는 보장은 없다.
출처를 가릴 필드는 생겼지만 재분석은 아직 남아 있다.
보고서 시점의 감사 로그 recall 줄에는 MCP 클라이언트 이름도 세션 id도 없었다.
원장에 budget·max_tokens를 남기는 작업(80번 이슈)과
클라이언트 이름 client, 요청 도착 시각 arrived_ts를 남기는 작업(89번 이슈)은
10월 2일에 닫혔다. 2026-10-20 확인 기준으로 원장 1140행(전 신원 합계) 중
네 필드를 모두 가진 행은 275개이고
첫 행은 2026-10-15T17:35:58Z(UTC)에 찍혔다.
클라이언트별 재분석(154번 이슈)은 아직 결과가 없다.
배포 뒤 만 7일 이상 쌓인 데이터로 2026-10-23 19:35 KST 이후에 판정한다.
다시 볼 조건은 둘이다. loop를 뺀 60초 이내 중복이 reusable의 10% 이상으로
상시 나타나는 것, 그리고 확정 동시 중복이 3% 이상 나오는 것이다.
지금 값은 3.4%와 0.6%이고
가장 먼저 확인할 것은 하루에 몰렸던 중복이 여러 날에 걸쳐 나타나는지다.
2026-10 기준 / 재검토 트리거: client 필드가 쌓인 7일 이상 원장에서 loop를
뺀 60초 이내 중복이 reusable의 10% 이상으로
상시 나타나거나 확정 동시 중복이 3% 이상 나온다