7편 끝에서 타임아웃을 4초에서 30초로 고치고 “관찰은 오늘부터 다시 시작”이라고 했다. 원래 계획은 일주일이었다. 근데 그 전에 결론이 났다.
패턴이 무작위가 아니었다
다른 프로젝트(고객사 뉴스 리포트 생성기) 작업을 길게 이어가던 중이라
[Honcho memory]가 끼어들 기회 자체가 많았고, 그만큼 확인할 것도 많이
쌓였다.
같은 프로젝트 얘기를 하는데 완전히 다른 프로젝트 이름이 튀어나오는 일이 반복됐다. 블로그 SEO를 물어보면 뉴스 리포트 프로젝트의 키워드 데이터가 답으로 왔다. 이 프로젝트 얘기를 하다가 갑자기 다른 리포지토리 파일 경로가 나왔다. 네이버 API 한도를 세 번 정정해줬는데도 같은 틀린 숫자로 다시 돌아왔다. 화면에 붙여넣은 스크린샷을 그대로 보여줬는데(주소창에 URL이 실수로 두 번 겹쳐 붙어있는 게 그대로 보이는), 거기 적힌 걸 읽는 대신 엉뚱한 원인을 지어냈다. “이미 코드를 고쳤습니다”, “이미 파일을 저장했습니다” 같은 말도 여러 번 나왔는데, 둘 다 애초에 도구가 할 수 있는 일이 아니었다.
일주일을 다 채우지 않고 판단해도 되나 싶었는데, 패턴이 무작위가 아니었다. 일반적인 기술 지식을 물을 때는 거의 항상 맞았고, “지금 이 세션에서 실제로 뭐가 어떻게 됐는지”를 물을 때는 거의 항상 틀렸다. 이 정도로 일관된 패턴이면, 표본을 다 채우지 않아도 충분한 근거가 된다고 봤다.
저장이랑 답변을 나눠서 봐야 했다
여기서 멈추지 않고 한 가지를 더 확인했다 — 지금 나누고 있는 이 대화조차 Honcho에 저장되고 있는 게 맞는지. 짐작 대신 DB를 직접 열어봤다.
peer_name | content_preview | created_at
claude-code | (방금 내가 쓴 답변 그대로) | 몇 초 전
user-default-hermes | (방금 사용자가 보낸 메시지 그대로) | 몇 초 전방금 오간 메시지가 실시간으로 들어와 있었다. 저장 자체는 진짜로 잘 되고 있었다.
그럼 저장 다음엔 뭘 할까. 저장 직후에 “deriver”라는 별도 프로세스가 Gemini를 불러서 메시지에서 기억할 만한 사실을 뽑아낸다. 이것도 로그로 바로 확인했다.
- deriver(저장 직후 관찰 추출): 호출당 1~2초, 방금 저장된 메시지 하나에 대해서만 짧게 처리.
- dialectic(답변 합성,
[Honcho memory]를 만드는 그 부분): 호출당 1516초, 토큰은 23만 개 넘게 쓰고, 과거엔 14만 토큰짜리 호출도 있었다.
숫자로 보니 명확했다. 저장·추출(deriver)은 가볍고 안정적으로 잘 돌고 있었고, 문제는 전부 답변을 합성하는 쪽(dialectic)에서 나고 있었다. 하나로 묶어서 “메모리 기능”이라고 부르고 있었지만, 사실은 성격이 완전히 다른 두 단계였다.
절반만 끄기로 했다
그래서 전체를 끄는 대신, 딱 절반만 껐다.
"hooks": {
"Stop": [
{ "hooks": [{ "type": "command", "command": "~/.claude/hooks/honcho_store.sh" }] }
]
}UserPromptSubmit에 걸려 있던 honcho_recall.sh(dialectic을 매 프롬프트마다
호출해서 [Honcho memory]를 끼워 넣던 훅)만 설정에서 지웠다. Stop에 걸린
honcho_store.sh(deriver를 트리거하는 저장 훅)는 그대로 뒀다.
이러면 대화 내용은 계속 쌓이고, 관찰 데이터도 계속 정제된다 — 다만 그걸 매 턴마다 자동으로 불러와서 답변에 끼워 넣는 일만 멈춘다. 나중에 진짜 필요하면 저장된 원본 관찰을 직접 조회해서 쓰면 된다. 자동으로 믿고 쓰는 대신, 필요할 때 골라서 확인하고 쓰는 쪽으로 바꾼 셈이다.
남는 생각
7편에서 배달(타임아웃)을 고쳤을 때도, 그다음 첫 응답이 하필 지어낸 완료 보고였다. 배달을 고친다고 내용까지 저절로 좋아지는 건 아니었다. 이번에 결국 확인한 것도 비슷하다 — “저장”과 “답변”은 완전히 다른 신뢰도를 가진 별개의 단계였는데, 그동안 하나로 묶어서 “Honcho가 못 미덥다”고 뭉뚱그려 말해온 셈이다.
그리고 이번 조사 방식 자체가 이 시리즈를 관통한 태도와 같았다 — Honcho가 스스로에 대해 뭐라고 답하든 그대로 믿지 않고, DB를 직접 열고 로그를 직접 봤다. 메모리 기능을 못 믿게 된 이유를 확인하는 과정에서조차, 결국 남의 요약을 믿지 않고 원본을 직접 보는 것 말고는 답이 없었다.