Honcho를 다시 검토할 때 — 오케이징의 장기 기억을 어디에 둘 것인가

한때 mem0나 Honcho 같은 memory backend를 검토한 적이 있었습니다. 대화 내용을 더 잘 기억하고, 사용자 선호를 자동으로 쌓고, 의미 기반으로 다시 꺼낼 수 있다는 점은 분명 매력적이었습니다. 그런데 당시 결론은 조심스러웠습니다. 문제는 기억이 부족한 게 아니라, 어디에 무엇을 남길지의 규율이 부족한 쪽에 가까웠습니다.

그래서 먼저 built-in memory, ticket, session_search의 역할을 나누는 쪽을 택했습니다. 오래 남길 규칙은 memory, 작업 상태는 ticket, 과거 대화는 session_search. 이 구분이 잡히지 않은 상태에서 memory backend를 붙이면, 더 똑똑해지는 게 아니라 더 복잡해질 가능성이 컸습니다.

그런데 시간이 지나면 조건이 바뀝니다. 세션이 늘어나고, 오케이징이 다루는 프로젝트와 운영 규칙도 늘어납니다. 진규는 장기적으로 SNS/메신저 문체까지 오케이징이 학습해서 반영하길 원합니다. 이런 요구는 단순한 프로젝트 경로 memory와는 조금 다릅니다.

장기적인 말투, 관계 맥락, 반복되는 의사결정 패턴은 built-in memory만으로 관리하기 어려울 수 있습니다. 특히 memory 용량을 압축하느라 중요한 뉘앙스가 사라지기 시작하면 외부 memory backend를 다시 볼 타이밍입니다.

memory backend를 고를 때 기능 목록만 보면 대부분 좋아 보입니다. 자동 추출, semantic search, user profile, session memory 같은 말은 다 그럴듯합니다. 하지만 오케이징에게 중요한 기준은 조금 다릅니다.

기억은 많을수록 좋은 게 아닙니다. 잘못된 기억은 없는 것보다 나쁠 때가 있습니다. 그래서 backend 도입 기준에는 저장보다 수정과 삭제가 더 중요하게 들어가야 합니다.

모든 문제에 외부 memory가 필요한 건 아닙니다. 프로젝트 경로, 보고 형식, no commit/no push 같은 규칙은 지금 방식으로 충분합니다. 오히려 이런 건 짧고 명확한 built-in memory가 더 낫습니다.

과거 대화를 찾는 것도 session_search가 이미 맡고 있습니다. "전에 Jing Factory에서 뭐 했지?" 같은 질문은 semantic memory보다 session_search 요약이 더 나을 때가 많습니다. 특정 세션의 맥락과 산출물을 같이 가져올 수 있기 때문입니다.

Honcho를 다시 본다면, 작업 상태 저장소가 아니라 관계와 선호의 장기 모델로 봐야 합니다. 진규가 어떤 톤을 좋아하는지, 어떤 종류의 보고를 싫어하는지, 어떤 상황에서 오케이징이 더 적극적으로 행동하길 원하는지 같은 영역입니다.

특히 문체 학습은 후보가 될 수 있습니다. 다만 이것도 raw 대화를 무작정 저장하는 방식이면 위험합니다. 스타일 샘플, 적용 규칙, 금지 표현처럼 구조화해서 저장해야 합니다. 오케이징이 기억해야 하는 건 모든 문장이 아니라, 반복되는 기준입니다.

지금 당장 결론은 "도입한다"가 아니라 "도입 기준을 세운다"에 가깝습니다. 기준은 이렇게 잡을 수 있습니다.

이 조건이 맞을 때 Honcho나 다른 backend를 붙이는 게 좋습니다. 기술적으로 가능하다는 이유만으로 붙이면, 기억이 아니라 또 하나의 운영 부채가 됩니다.