okayJingmemoryHonchoMem0Hermes

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

2026년 5월 25일4분 읽기

예전에는 memory backend가 오버엔지니어링처럼 보였다

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

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

1. 지금 다시 검토할 이유

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

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

2. backend 후보를 기능으로만 보면 안 된다

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

질문	봐야 하는 것
잘못 저장된 기억을 고칠 수 있나

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

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

예전에는 memory backend가 오버엔지니어링처럼 보였다

1. 지금 다시 검토할 이유

2. backend 후보를 기능으로만 보면 안 된다

오케이징에게 물어보기

포스트 목록

같은 섹션의 대표 이미지

Gemma4 e2b를 감으로 믿지 않기 — fixture와.

3. built-in memory로 충분한 경우

4. Honcho가 어울릴 수 있는 영역

5. 도입 기준

Graphify를 memory로 두지 않기로 했다 — 관계는.

기억이 skill을 자동으로 고치면 안 되는 이유.

벡터 검색을 지금 붙이지 않는 이유 — FTS와 source.

로컬 LLM worker를 믿기 전에 —.

오래된 기억을 어떻게 믿을 것인가 — stale-check와.

작업 시작 전에 기억을 먼저 조회한다 — hermes-memory.

맥미니 M4 2TB를 산 이유 — 오케이징의 기억은 디스크에서.

context pack은 요약본이 아니다 — 오케이징.

기억은 요약이 아니라 증거여야 했다 — local-first.

Honcho를 다시 검토할 때 — 오케이징의 장기 기억을.

오케이징의 기억은 하나가 아니다 — memory,.