Claude Code한테도 메모리를 붙여주려다가 — 답을 짐작하는 대신 실험부터 해봤다

지난 글에서 Honcho를 self-host로 Hermes에 붙이는 데 성공했다. 그러고 나서 자연스럽게 든 질문이 있었다 — 그럼 이걸 Claude Code한테도 붙일 수 있나?

답은 “가능은 한데, 자동은 아니다”

Honcho가 Hermes에 자동으로 붙는 이유는, Hermes 코드 자체에 메모리 프로바이더를 호출하는 통합 로직이 미리 만들어져 있기 때문이었다. Claude Code한텐 그런 게 없다. Honcho가 REST API로 열려 있으니 curl로 직접 부르는 것 자체는 가능하지만, 그걸 매 턴 자동으로 하려면 별도로 훅이나 스킬을 직접 만들어야 한다. 그리고 Claude Code는 이미 파일 기반의 자체 메모리 시스템이 있어서, Honcho가 그것보다 나은지도 불확실했다.

그래서 짐작만 하고 넘어가는 대신, 작게 실험해보기로 했다.

실험 설계

Hermes가 쓰는 workspace는 안 건드리고, claude-code-test라는 별도 workspace를 하나 팠다. 여기에 이번 세션에서 실제로 있었던 사실 몇 개를 수동으로 넣고, 나중에 자연어로 물어봐서 정확하게 다시 꺼내오는지 확인하는 방식이다.

첫 질문에서 바로 오류가 나왔다

아무렇게나 적은 회사 이름 몇 개를 넣어봤다 — 그중 하나는 정식 명칭으로 교체한 내용이었다. “기존에 있던 ‘물류센터협회’라는 이름은 빼고, 정식 명칭인 ‘전국물류센터협회’를 새로 추가했다”는 내용도 있었다. 이름 하나가 다른 이름을 통째로 포함하는 관계였다.

나중에 “최근에 뭘 바꿨었지?”라고 물어보니, 이런 답이 돌아왔다.

삭제 항목: ‘전국물류센터협회’와… 삭제하셨습니다.

틀렸다. 실제로 삭제된 건 ‘물류센터협회’(전국 없는 쪽)고, ‘전국물류센터협회’는 오히려 새로 추가된 쪽이었다. 저장된 원본 데이터(observation)를 확인해보니 거기엔 정확하게 “물류센터협회를 제거했다”고 “전국” 없이 제대로 저장돼 있었다. 즉 저장 단계는 정확했는데, 질문에 답하려고 자연어로 합성하는 단계에서 비슷한 이름 두 개를 헷갈린 것이었다.

다른 질문 몇 개(모델 프로바이더를 왜 바꿨는지, lint 문제가 몇 건이었는지, tmux 문제 원인이 뭐였는지, 임베딩 차원을 왜 줄였는지)도 같이 물어봤는데, 이 중 세 개는 정확했고 하나(tmux)는 “prefix 키 설정 문제였습니다”라고 정확하지만 꽤 얕게만 답했다. 원래 있었던 핵심 — “설정 파일에는 없는데 살아있는 서버에만 남아있던 값”이라는 뉘앙스가 빠진 답변이었다.

가설: 모델이 약해서 그런 거 아닐까

Honcho는 질문에 답할 때 얼마나 깊게 추론할지 단계(reasoning level)를 고를 수 있는데, 내가 기본으로 설정해둔 값이 제일 가벼운 모델을 쓰는 low 단계였다. 그래서 제일 강한 max 단계로 같은 질문을 다시 던져봤다.

이번엔 정확했다.

제외: 물류센터협회 / 추가: 전국물류센터협회

가설이 맞았다 — 저장 품질 문제가 아니라, 답변을 합성할 때 쓰는 모델의 크기 문제였다.

그런데 그 과정에서 진짜 버그를 하나 더 찾았다

max 단계를 처음 테스트했을 때는 사실 이런 에러가 났었다.

{"detail":"An unexpected error occurred"}

로그를 열어보니 실제 원인은 따로 있었다. 설정 파일에 무거운 작업용 모델 이름을 gemini-3-flash라고 적어놨었는데, 이건 존재하지 않는 모델이었다. 진짜 이름은 gemini-3-flash-preview였다 — -preview를 빼먹은 단순 오타였다.

이게 왜 지금까지 안 걸렸냐면, 그동안 실제로 써본 건 전부 가벼운 작업(deriver, 기본 low 단계)뿐이었고, 이 잘못된 모델 이름을 쓰는 medium/high/max/dream 단계는 한 번도 실행된 적이 없었기 때문이다. 이번에 max 단계를 직접 테스트해보지 않았다면, 나중에 실제로 저 기능들을 쓸 때가 돼서야 (아마 한참 뒤에) 발견됐을 문제였다.

모델 이름을 고치고 다시 테스트하니 위에서 본 정확한 답이 나온 거다.

그럼 low는 항상 틀리나 — 아니었다

여기서 궁금해져서, 비슷한 이름이 헷갈리는 상황을 하나 더 만들어봤다. 이번엔 실제 업무 데이터가 아니라 순수하게 테스트용으로 지어낸 내용으로 — “새 배포 스크립트 이름을 ‘deploy-v2’로 정하고, 예전에 쓰던 ‘deploy-v2-beta’는 그만 썼다”는 식이었다. 역시 한 이름이 다른 이름을 포함하는 관계였다.

그런데 이번엔 low 단계로 물어봐도 틀리지 않았다. 정확하게 “deploy-v2-beta는 중단, deploy-v2를 새로 사용”이라고 답했다.

즉 “약한 모델은 비슷한 이름을 항상 헷갈린다”는 확정적인 법칙은 아니었다. 어떤 경우엔 맞고 어떤 경우엔 틀리는, 확률적인 문제에 가까웠다. 오히려 이게 더 다루기 까다로운 지점이다 — 매번 틀리면 바로 알아채고 대응하겠지만, 가끔씩만 틀리는 건 알아채기 훨씬 어렵다.

앞서 나온 질문들도 다시 비교해봤다

tmux 답변이 얕았던 게 마음에 걸려서, 아까 물어봤던 네 가지 질문을 low와 max로 나란히 다시 비교해봤다.

가장 뚜렷한 차이가 tmux였다.

low: “prefix 키 설정 문제였습니다.”
max: “실행 중인 tmux 서버에만 prefix C-a 설정이 적용되어 있었고, 정작 설정 파일(~/.tmux.conf)에는 반영되어 있지 않았기 때문입니다.”

lint 문제 관련 질문도 비슷했다. low는 “총 794건입니다”라고 숫자만 답했고, max는 원인부터 794건이 드러난 경위, 최종적으로 0건까지 해결한 결과까지 맥락을 갖춰서 답했다.

결론

정리하면 이렇다.

저장(추출) 단계는 low든 max든 꾸준히 정확했다. 문제는 항상 답변을 합성하는 단계에서 났다.
low는 틀리지 않을 때가 많지만, 얕게 답하거나 가끔 비슷한 이름을 헷갈릴 수 있다. 그리고 그 실수가 매번 나는 게 아니라서 예측하기 어렵다.
max는 이번 테스트 범위 안에서는 전부 정확했고, 놓친 뉘앙스도 잘 복원했다. 대신 더 무거운 모델을 쓰니 비용과 응답 속도는 더 든다.
그리고 이 실험을 하다가, 원래 알아내려던 것과 별개로 실제 설정 오류(잘못된 모델 이름) 하나를 더 찾아서 고쳤다.

정작 “Claude Code한테도 붙일까”라는 원래 질문에 대한 답은 아직 안 냈다. 자동으로 붙이려면 결국 훅이나 스킬을 새로 만들어야 하는데, 지금 갖고 있는 메모리 방식과 비교했을 때 그 수고를 들일 만큼 확실한 이득인지는 이번 실험만으로는 판단하기 이르다고 생각한다.

다만 이번 실험 결과를 바탕으로 바로 반영한 게 하나 있다 — Honcho의 기본 dialecticReasoningLevel을 low에서 max로 바꿨다. low가 틀리는 빈도 자체는 낮지만, 언제 틀릴지 예측할 수 없다는 게 더 큰 문제라고 판단했다. 어차피 답을 합성하는 단계에서만 나는 차이라 비용도 매 대화 턴마다 크게 부담되는 수준은 아니고, “가끔 틀릴 수 있는 답”보다는 “느리더라도 안정적인 답”이 메모리 시스템 본래 목적에 더 맞다고 봤다.