봇은 대화를 어떻게 기억하나 — OpenClaw는 격리로, Hermes는 통합검색으로

개인 AI 어시스턴트 OpenClaw를 다룰 때, 세션(대화 기록)은 에이전트별로 격리돼 있었다. 봇마다 자기 대화 저장소가 따로 있고, 세션 도구가 들여다볼 수 있는 범위는 tools.sessions.visibility(self / tree / agent / all) 설정으로 잠긴다. 한 서버에서 여러 봇을 굴려도 서로의 기억이 새지 않게 정책으로 벽을 세우는 방식이다.

또 다른 오픈소스 AI 에이전트 Hermes Agent는 같은 "대화를 어떻게 기억하느냐" 문제를 정반대로 푼다. 벽을 세우는 대신 벽을 허문다 — 터미널·텔레그램·디스코드·예약작업(cron)에서 들어온 모든 대화를 단일 데이터베이스 한 곳에 모으고, 그 위에 전문 검색 색인을 얹어 에이전트가 스스로 자기 과거 전체를 뒤지게 한다. 이 글은 그 한 가지 갈림길 — "기억을 격리해 지킬 것인가, 통합해 검색할 것인가" — 만 따라간다.

같은 문제, 갈라지는 결정 — 기억을 나눌 것인가 모을 것인가

두 봇 다 같은 벽에 부딪힌다. 대화가 휘발되면 봇은 매번 "처음 보는 사람"처럼 군다. 그래서 둘 다 대화를 저장한다. 문제는 그다음 — 저장한 대화를 어떻게 배치하느냐에서 갈린다. OpenClaw는 에이전트마다 저장소를 나눠 가시 범위를 정책으로 통제한다. Hermes는 입구를 가리지 않고 한 곳에 합쳐 통째로 검색 가능하게 만든다.

▲ OpenClaw — 봇마다 기억을 나누고 정책으로 잠근다

위 다이어그램은 앞서 다룬 OpenClaw의 세션 구조다. 봇마다 대화 저장소가 분리돼 있고, 세션 도구가 어느 저장소까지 들여다볼 수 있는지는 가시 범위 설정이 결정한다 — 자기 것만, 자기 계통만, 특정 에이전트만, 아니면 전부. 이 설계가 겨누는 상황은 명확하다 — 한 서버에 여러 봇·여러 사용자가 얹혀 돌 때, 한 봇이 실수로 다른 대화를 참조해 기억이 새는 사고를 정책으로 원천 차단한다.

▲ Hermes — 모든 입구를 한 DB로 합치고 통째로 검색한다

위 다이어그램은 Hermes의 정반대 선택이다. 네 입구(터미널·텔레그램·디스코드·예약 작업)에서 들어온 대화가 전부 단일 SQLite 파일(state.db) 하나로 흘러들고, 거기에 FTS5(SQLite 내장 전문 검색 엔진 — 책 뒤 색인처럼 단어가 어느 메시지에 나오는지 미리 정리해 즉시 찾는다) 색인이 얹힌다. OpenClaw와의 결정적 차이는 마지막 칸이다 — Hermes의 에이전트는 session_search라는 도구를 손에 쥐고 자기 과거 전체를 스스로 뒤진다. OpenClaw가 "어디까지 볼 수 있나"를 정책으로 좁혔다면, Hermes는 "전부 볼 수 있게" 열어 두고 검색 속도로 승부한다.

Hermes가 통합을 택한 대가 — 검색과 충돌을 스스로 풀어야 한다

기억을 한 곳에 모으면 검색은 쉬워지지만, 대신 두 가지 숙제가 새로 생긴다. 하나는 "수백 개 대화 속에서 그것을 어떻게 빨리 찾나", 다른 하나는 "여러 입구가 같은 파일에 동시에 쓸 때 충돌을 어떻게 막나"다. Hermes는 단일 DB 안을 세 표로 나눠 이를 푼다.

위 다이어그램은 통합 저장소 안이 어떻게 나뉘는지 보여준다. 대화 묶음의 요약 정보(출처가 텔레그램인지 예약 작업인지, 제목, 쓴 모델, 토큰 수)를 담는 표, 실제 주고받은 메시지 본문 표, 그리고 그 본문을 빠르게 뒤지기 위한 검색 색인이다. 점선이 핵심이다 — 메시지가 본문 표에 들어갈 때마다 트리거(특정 변경이 일어나면 자동 실행되는 DB 장치)가 색인을 자동 갱신하므로, 사람이 따로 "색인 다시 만들기"를 할 필요가 없다. 동시 쓰기 충돌은 WAL 모드(읽기와 쓰기가 서로를 막지 않는 SQLite 저널 방식)와 무작위 재시도로 직렬화해 막는다 — OpenClaw는 저장소가 격리돼 이 충돌을 이런 형태로 겪지 않지만, 통합을 택한 Hermes는 반드시 풀어야 하는 숙제다.

기억을 스스로 되살리는 봇 — session_search

통합 검색이 만드는 진짜 차이는 사람이 아니라 에이전트 쪽에서 드러난다. 사용자가 "우리 저번에 이거 했잖아"라고 운을 떼면, Hermes의 봇은 되묻는 대신 session_search 도구로 과거 세션을 FTS5로 뒤져 "목표 → 매치 → 결론"에 해당하는 메시지 묶음만 골라 읽고 맥락을 되살린다. LLM 호출도, 요약도 없이 DB에서 실제 메시지를 그대로 가져온다.

위 다이어그램은 Hermes의 봇이 자기 과거를 스스로 참조하는 흐름이다. 사용자가 흘린 한마디를 단서로 에이전트가 검색 도구를 직접 부르고, 색인으로 관련 세션을 찾아 그 실제 메시지를 통째로 맥락에 되살린다. 여기서 OpenClaw와의 철학 차이가 정점을 찍는다 — OpenClaw에서 "무엇을 참조할 수 있나"는 운영자가 정책으로 미리 정하지만, Hermes에서 "무엇을 참조할까"는 에이전트가 검색으로 그때그때 스스로 정한다. 통제의 주체가 사람이냐 봇이냐가 갈린다.

정리 — 여럿을 지킬 것인가, 하나를 깊게 쓸 것인가

두 봇은 "대화를 어떻게 기억하느냐"라는 같은 문제를, 기억의 배치라는 첫 결정 하나로 갈라 푼다.

	OpenClaw	Hermes
기억 배치	에이전트별 격리 저장소	모든 입구를 단일 DB로 통합
참조 통제의 주체	운영자 — visibility 정책으로 범위를 미리 잠금	에이전트 — session_search로 전체를 스스로 검색

어느 쪽이 낫다기보다, 겨누는 환경이 다르다. 봇 하나를 깊게 쓰는 개인 서버라면, 입구를 가리지 않고 전 대화를 통째로 검색하고 봇이 스스로 맥락을 회수하는 Hermes의 통합 방식이 강하다. 반대로 여러 봇·여러 사용자를 한 서버에 안전하게 얹어야 한다면, 기억 접근 범위를 운영자가 명시적으로 통제하는 OpenClaw의 격리 방식이 강하다. 매번 0에서 시작하는 봇은 도구일 뿐이고 지난주의 맥락을 기억하는 봇이라야 "조수"에 가까워진다는 목표는 같지만 — 그 기억을 열어 검색으로 풀지, 나눠 정책으로 지킬지가 이 두 봇을 가른다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.