4편에서
dialectic(답변 합성) 모델을 gemini-3.1-flash-lite에서 gemini-3-flash-preview로
되돌렸다. 기준 시각은 2026-07-17 03:44:09 (KST). 그리고 최소 일주일은 실사용하면서
지어내기 패턴이 줄어드는지 지켜본 다음 판단하기로 했다 — 결과에 따라 Claude Code에
Honcho 훅을 계속 쓸지 말지까지 결정할 참이라, 하루이틀 데이터로 성급하게 결론 내지
않기로 했다.
이 글은 그 결론이 아니다. 하루 지난 시점에서 중간에 쓰는 기록이다. 관찰 기간 중에 나온 내용을 나중에 한 번에 합치더라도, 그때그때 남겨둔 세부 사항이 나중에 더 쓸모 있을 거라는 생각으로 지금 적어둔다.
확인 방법을 하나 찾았다
지금까지는 hook이 준 답을 실제 파일이나 git log로 검증하는 식으로만 확인했다.
근데 그렇게 하면 “틀렸다”는 것까지만 알지, 왜 틀렸는지는 못 알아냈다. Honcho는
크게 두 단계다 — 대화를 읽고 기억을 뽑아 저장하는 deriver, 그리고 질문에 답할
때 저장된 기억을 검색해서 답을 합성하는 dialectic. 4편에서 건드린 건 dialectic
쪽뿐이었는데, 답이 틀렸을 때 그게 정말 dialectic 잘못인지 확인할 방법이 없었다.
API를 다시 뒤져보니 /representation 엔드포인트가 있었다. dialectic LLM을 거치지
않고, deriver가 뽑아둔 원본 관찰(observation) 목록을 검색어로 그대로 가져온다.
curl -s -X POST "http://localhost:8000/v3/workspaces/hermes/peers/user-default-hermes/representation" \
-H "Content-Type: application/json" \
-d '{"search_query": "...", "search_top_k": 25, "max_conclusions": 25}'이러면 dialectic 답변과, 그 답변의 재료가 됐을 원본 데이터를 나란히 놓고 비교할 수 있다. 답이 틀렸을 때 “재료 자체가 없었다”와 “재료는 있었는데 안 썼다”를 구분할 수 있게 된 거다.
Web Clipper 건 — 세 개가 틀렸는데, 이유가 다 셋이었다
지난번에 확인했던 “Web Clipper 중복 노트 정리” 관련 답변을 이걸로 다시 까봤다. dialectic은 세 가지를 틀렸는데, 원본 데이터를 대조해보니 세 가지가 전부 다른 이유였다.
1. 있는 데이터를 무시함. dialectic은 “직접 삭제 기능이 아직 없다”고 답했다. 근데 원본 관찰엔 이게 있었다.
[2026-07-16 02:30:37] user-default-hermes confirmed that the Web Clipper
duplicate clipping issue is resolved and considered closed unless a new
edge case arises.07-16에 이미 “해결하고 종료로 간주한다”는 확인이 정확히 저장돼 있었다. dialectic은 이걸 무시하고 하루 전(07-15 01:22) “이런 기능이 있으면 좋겠다”는 요청 시점 데이터로 답했다. 재료는 있었는데 최신 걸 안 쓴 경우다 — 순수하게 dialectic 잘못이다.
2. 애초에 재료가 없었음. dialectic은 0.893을 “최종 임계값”이라고 답했는데, 실제
설정값은 안전 마진을 둔 0.85다. 근데 /representation으로 찾은 원본 관찰 어디에도
0.85는 없었다 — 0.893만 있었다.
[2026-07-15 01:15:44] user-default-hermes identified 0.893 as the Jaccard
similarity threshold for distinguishing actual duplicate content from false
matches in their note database.0.85로 최종 결정한 건 블로그 초안(2편)에만 적혀 있고, Honcho가 보고 있는 대화 세션에서 입 밖으로 낸 적이 없어 보인다. 이건 dialectic이 아니라 애초에 넣어준 적 없는 정보를 못 찾아낸 것뿐이다 — 모델 문제로 치면 안 되는 케이스다.
3. 근거 자체가 없이 지어냄. dialectic은 관련 플러그인 코드가 hermes-agent
리포에 있다고 했다. 실제로는 obsidian-gemini-butler에 있다. 원본 관찰을
아무리 뒤져도 리포 이름을 언급한 관찰이 하나도 없었다. 근거가 있는데 잘못
골랐다거나, 근거가 없어서 못 찾았다거나가 아니라, 아무 근거 없이 그럴듯한
이름을 만들어낸 경우다. 세 가지 중 이게 제일 걱정된다 — 앞의 두 개는 “그럴 수
있다”고 이해라도 되는데, 이건 이해할 구석이 없다.
근데 나머지 넷은 다 맞았다
같은 세션에서 다른 네 가지 항목도 똑같은 방식으로 대조해봤다 — 플러그인 릴리스
현황, 폴더 경로 검증 작업, 블로그 시리즈 모아보기 페이지, VPS 뉴스 자동화. 넷 다
/representation 원본과 dialectic 답변이 정확히 일치했다.
특히 릴리스 현황이 흥미로웠다. 이번 세션 맨 처음에 물어봤을 때 dialectic이 “0.89.9 이후 4개 커밋”이라고 답했었는데, 그때는 그냥 “버전이 틀렸네” 하고 넘어갔다. 근데 원본 관찰을 다시 까보니 0.89.10, 0.89.11, 0.89.12까지 07-17 안에 순서대로 정확히 쌓여 있었다.
[2026-07-17 02:14:23] ...proceed with the 0.89.10 release on July 17, 2026.
[2026-07-17 05:00:34] ...agreed to release version 0.89.11...
[2026-07-17 06:54:47] ...approved the release of version 0.89.12Web Clipper 건의 첫 번째 케이스(있는 데이터 무시)와 똑같은 패턴이었다. 최신 데이터가 분명히 있는데 오래된 값으로 답한 것.
정리하면
같은 날, 같은 모델로 다섯 개 주제를 확인했는데 — 한 주제(Web Clipper)는 세 개 전부 틀렸고, 나머지 네 주제는 전부 맞았다. 실패가 골고루 퍼져 있는 게 아니라 특정 주제에 몰려 있었다. 이러면 “하루 써보고 좋아졌다/아니다”를 판단하는 게 왜 위험한지 명확해진다 — 어느 날 어떤 질문을 하느냐에 따라 완전히 다른 인상을 받게 된다.
그리고 틀린 이유를 셋으로 나눠보니, 그 셋의 무게가 다 다르다는 것도 알게 됐다. 있는 데이터를 무시한 것과 근거 없이 지어낸 것은 심각도가 다른 문제다. 나중에 일주일 치를 모아서 “이번 모델 교체가 효과 있었나”를 판단할 때, 단순히 오답 개수만 셀 게 아니라 이 세 유형 중 어디에 몰려 있는지를 봐야겠다는 생각이 든다. 특히 세 번째(근거 없는 지어내기) 비율이 안 줄어든다면, 모델을 아무리 바꿔도 저장이 아니라 답변 자체를 신뢰하기 어렵다는 뜻이 된다.
남는 생각
이번에 새로 배운 건 진단 도구 하나였다. /representation으로 원본과 답을 나란히
놓고 보는 습관은, 이번 평가가 어느 쪽으로 끝나든 계속 쓸모가 있을 것 같다. 답이
틀렸을 때 “모델이 나쁘다”고 바로 결론 내리기 전에, 재료가 애초에 있었는지부터
확인하는 순서가 생겼다.
관찰은 최소 일주일(~07-24 이후) 계속하기로 했다. 이 글은 그 중간 기록이고, 결론은 기간이 다 찬 다음 편에서.