지금까지 써 본 대부분의 AI 채팅 인터페이스에는 사실 기억이라는 게 없다. 그것들이 가진 건 컨텍스트 윈도우인데, 이건 전혀 다른 물건이다. 같은 대화 안에서 아까 네가 한 말은 여전히 모델 앞에 놓여 있다. 어제 대화에서 한 말은 사라지고 없다. 다음 날이 되면 다시 맨바닥에서 시작하고, 어시스턴트는 너를 처음 보는 사람처럼 자기소개부터 한다.
Hermes Agent는 다르다. 대화 컨텍스트와는 별개로, 진짜 기억 계층이 붙어 있다. 이 계층은 시간이 지나면서 너에 대한 것들을 하나씩 배워 나가고, 그걸 세션과 플랫폼을 건너뛰며 가지고 다닌다. 덕분에 봇은 네가 언제 말을 걸어도 같은 존재처럼 행동한다. 이 글은 그게 실제로 어떻게 돌아가는지, 어떤 설계 결정이 중요한지, 그리고 v0.7.0에 들어간 갈아 끼울 수 있는 메모리 인터페이스가 무엇을 바꿨는지에 대한 이야기다.
단기 기억 vs 장기 기억
먼저 중요한 구분을 짚자.
Hermes의 단기 기억은 세션 컨텍스트 윈도우다. 에이전트가 지금 진행하고 있는 대화의 한 토막이고, 여기에는 선제적 압축 전략이 따라붙는다. 컨텍스트가 모델 한계에 가까워지면 Hermes가 요약 패스를 한 번 돌려, 오래된 턴들을 구조화된 요약으로 접고 가장 최근의 몇 턴은 글자 그대로 남긴다. 이 압축은 몇 번의 릴리스를 거치며 다듬어져 왔다 — v0.4.0에서 구조화 요약과 반복 업데이트, 이후 토큰 예산 기반 꼬리 보호, 설정 가능한 요약 엔드포인트, 폴백 모델 지원까지. 긴 대화에서 이 친구는 중요한 맥락을 떨어뜨리지 않으면서도 에이전트를 조용히 빠르고 싸게 유지해 준다.
장기 기억은 재미있는 쪽이다. 이건 사실, 선호, 교정, 사용자 모델을 담아 두는 저장소인데, 대화 바깥에 산다. 오늘 네가 텔레그램에서 봇한테 "내 이름은 Alice"라고 말하면 그 사실이 장기 기억에 적힌다. 내일 슬랙에서 뭔가 물어보면, 그 사실이 뽑혀 나와서 에이전트가 네 메시지를 보기 전에 컨텍스트에 주입된다. 모델이 보는 건 여전히 자기 윈도우에 들어가는 만큼뿐이지만, 그 윈도우가 너에 대해 알아야 할 것들로 미리 덧칠돼 있다.
단기 기억은 버퍼다. 장기 기억은 한 사람이다.
Honcho — 이게 뭐고, 왜 중요한가
Hermes의 기본 장기 기억 프로바이더는 Honcho다. AI 네이티브 메모리를 위해 설계된 라이브러리다. Honcho의 역할은 에이전트 뒤에서 돌면서 구체적으로 세 가지 일을 하는 것이다.
- 1.관찰한다. 사용자 메시지와 에이전트 응답이 모두 이벤트 스트림으로 Honcho에 들어간다. Honcho는 그 스트림에서 내부 사용자 모델을 쌓는다 — 원시 채팅 이력이 아니라, 대화에서 추론해 낸 구조화된 사실과 선호다.
- 2.사용자를 추론한다. Honcho는 작은 "변증법" 계층을 돌려서 네가 누구인지, 뭘 원하는지, 뭘 정정했는지에 대한 일관된 그림을 세워 나간다. 단순한 키워드 추출이 아니다 — 사용자에 대해 계속 굴러가는 멘탈 모델이다.
- 3.주입한다. 새 턴이 시작될 때마다 Honcho는 "이 사용자에 대해 지금 중요한 게 뭔가"를 짧은 컨텍스트 조각으로 만들어 내고, Hermes는 그걸 시스템 프롬프트 앞쪽에 붙인다. 스니펫은 Honcho가 더 배워 나갈수록 바뀐다.
두 가지 디테일은 놓치기 쉬우니까 짚고 가자.
첫째, Honcho 쓰기는 비동기다. 에이전트는 메모리 쓰기를 기다리지 않는다. 응답을 먼저 내보내고, 메모리 계층은 그 교환을 뒤에서 처리한다. 그래서 긴 대화가 메모리 업데이트 때문에 레이턴시 세금을 내지 않는다. 메모리 백엔드가 잠깐 죽어도 봇은 멈추지 않는다 — 다운타임 동안의 업데이트는 잃지만, 어시스턴트는 계속 말을 한다.
둘째, Honcho 리콜은 캐시된 시스템 접두부 바깥쪽에 놓인다. Anthropic의 프롬프트 캐싱(Claude Sonnet 4.6 같은 모델에서 많이 쓰는 기능)은 시스템 프롬프트가 턴마다 안정적으로 유지되기를 원한다. 그래야 캐시가 맞는다. Honcho가 주입하는 스니펫은 턴마다 바뀌기 때문에, Hermes는 일부러 그걸 캐시된 시스템 섹션 뒤에 붙인다. 정적인 부분에는 캐시가 여전히 걸리고, 동적인 메모리 계층은 변하는 부분에서 여전히 작동한다. 이건 릴리스 노트에는 절대 실리지 않는 종류의 기계적 트레이드오프지만, 월 청구서가 50달러가 될지 500달러가 될지를 정한다.
게이트웨이 모드에서의 다중 사용자 격리
기본 Hermes 게이트웨이는 여러 사용자를 같은 에이전트 프로세스로 흘려 보낸다. 장기 기억은 사용자별로 분리돼야 한다. 아니면 Alice의 알레르기가 Bob의 요리 추천에 끼어든다. v0.3.0 릴리스는 게이트웨이 안에서 Honcho에 대한 제대로 된 다중 사용자 격리를 추가했고, 실전에서는 이런 뜻이다.
- •각 게이트웨이 사용자 ID가 별도의 Honcho 피어에 매핑되고, 메모리 쓰기는 피어 단위로 스코프가 잡힌다.
- •그룹 채팅 세션은 기본적으로 사용자별 세션을 상속받기 때문에, 공용 채널이라도 참여자 각각에 대해 별도의 메모리 스트림이 기록된다.
- •프로필 단위 메모리 격리(v0.5.0/v0.6.0) 덕분에 같은 머신에서 Hermes 프로필을 여러 개 돌려도 각 프로필의 기억은 서로 완전히 다른 우주에 산다. 프로필을 바꿔도 한 인격이 다른 인격으로 새 나가지 않는다.
이것들 중 어느 것도 사용자에게 보이지 않는다. 이것들 전부가, 봇이 실수로 엉뚱한 사람을 기억해 버리지 않는 이유다.
갈아 끼울 수 있는 메모리 인터페이스 (v0.7.0)
첫 다섯 번의 릴리스 동안 Honcho는 코드에 박혀 있었다. v0.7.0에서 메모리 계층은 제대로 된 프로바이더 인터페이스로 리팩터링됐다 — 어느 메모리 백엔드든 구현할 수 있는 작은 파이썬 추상 베이스 클래스 하나. 이 변경은 아키텍처적으로는 수수하고 실전에서는 엄청나다.
이 인터페이스 덕분에 Hermes 코어를 건드리지 않고도 메모리 백엔드를 바꿔 끼울 수 있다.
- •Honcho는 레퍼런스 프로바이더다(그리고 여전히 기본값이다). 기능이 풍부하고, 진짜 사용자 모델을 돌리고, 다중 사용자 격리를 제대로 처리한다.
- •Supermemory는 v0.8.0에서 두 번째 퍼스트 클래스 프로바이더로 들어왔다. 다중 컨테이너 지원, 설정 가능한 검색 모드, 아이덴티티 템플릿팅을 갖추고 있다.
- •mem0, OpenViking, RetainDB, Hindsight, ByteRover는 모두 Hermes 플러그인 시스템에 커뮤니티 메모리 플러그인이 올라와 있고, 통합 깊이는 제각기 다르다.
- •직접 써도 된다. ABC는 작다 —
write(),recall(), 라이프사이클 훅 몇 개를 구현하고 플러그인으로 등록하면 끝이다.
내장 메모리 프로바이더 — 따로 아무것도 세팅하지 않은 경우의 의존성 제로 기본값 — 는 SQLite 기반 사실 저장소다. 기본만 건사한다. 사실을 쓰고, 관련도로 리콜하고, 사용자 단위로 스코프를 잡는다. Honcho만큼 똑똑하진 않지만 외부 서비스가 전혀 필요 없다. 월 5달러 VPS 위에서 도는 개인 어시스턴트에는 대개 이거면 충분하다.
이게 조용히 풀어 준 것
갈아 끼울 수 있는 메모리는 릴리스 노트에서 보면 "메모리를 프로바이더 인터페이스로 리팩터링" 같은 청소부 작업처럼 보이는 종류의 아키텍처 변경이다. 헤드라인 감이 아니다. 하지만 이게 실제로 하는 일은 "AI 어시스턴트가 당신에 대해 뭘 기억해야 하는가"라는 질문을 "Hermes가 어떻게 돌아가는가"라는 질문에서 떼어 내 주는 것이다.
이제 Honcho를 자기 유즈 케이스에 맞는 메모리 백엔드로 갈아 끼울 수 있다 — 개인 지식 베이스에 시맨틱 검색을 돌리고 싶은 사람에겐 벡터 스토어, 명시적인 엔티티 관계를 원하는 사람에겐 그래프 DB, 기억 데이터가 자기 머신을 벗어나길 원하지 않는 사람에겐 로컬 SQLite 전용 구성, 팀에겐 사내 메모리 서비스. 에이전트는 바뀌지 않는다. memory 인터페이스 뒤에 있는 놈만 바뀐다.
몇 년 뒤까지 살아남고 싶은 프로젝트에 이건 딱 맞는 추상화의 높이다. 기억은 사적인 물건이고, 너에게 맞는 메모리 백엔드가 다른 누군가에게도 맞으란 법은 없다. Hermes의 할 일은 어떤 메모리 계층이 꽂혀 있든 그것과 좋은 이웃이 되는 것, 그리고 그 계층이 자기 일을 하도록 길을 비켜 주는 것이다.