【제14회】Hermes Agent가 과거 대화를 자동으로 복원하게 만들기

목차

• 이번 회차의 도달점
• 과거의 대화 내용을 찾을 수 없다는 고통
• 이번에는 서고에 검색 창구를 추가한다
• 개념 정리 (구성도)
• 사전 준비
• 과거 대화의 저장소를 들여다보기
• 자동 발화를 체감하기 (이번 회차의 핵심)
• sessions와 Memory의 구분 사용
• 요약 및 제15회 예고
• 자주 발생하는 에러와 대처법
• 조작 빠른 참조표
• 인용 출처 및 참고

제12회에서 Memory에 '매번 사용할 전제'를, 제13회에서 Obsidian Vault에 '오래 남겨두고 싶은 정보'를 넣었다. 포스트잇(Memory)과 서고(Vault)라는 이중 구조를 통해, 매 세션의 자기소개와 관심 있는 기사나 조사한 내용을 저장하는 데 더 이상 어려움이 없다.

하지만, 아직 부족한 서랍이 하나 더 있다. "지난주 Telegram에서 상담했던 그 AWS 비용 최적화 건, 어떤 순서로 줄여야 한다고 했었지?"와 같은 과거의 대화 내용 그 자체다. 이것은 Memory에 넣기에는 너무 크고, Vault에 직접 손으로 옮겨 적기에는 지속하기 어렵다. 하지만 Hermes는 나눈 대화를 전부 ~/.hermes/state.db (SQLite+FTS5)에 자동으로 기록하고 있다. 제14회에서는 이 쌓인 기록에 검색 창구를 추가하여, "기억해내 줘"라고 부탁하는 것만으로 Hermes가 스스로 과거 대화를 가져오는 상태까지 진행한다. 서고에 사서를 한 명 고용하는 이미지다.

시리즈의 전체 모습은 이쪽.

시리즈 목차 (탭하여 열기)

제I부 몸 만들기

• 제1회 Hermes Agent를 VPS에 배포하는 방법
• 제2회 Hermes Agent의 접속을 안전하게 만드는 방법
• 제3회 Hermes Agent의 인증 정보를 안전하게 관리하는 방법
• 제4회 Hermes Agent를 Docker로 격리하여 실행하는 방법
• 제5회 Hermes Agent에 Grok과 Discord를 연동시키기
• 제6회 Hermes Agent를 systemd로 상시 기동시키는 방법

제II부 얼굴과 조작석

제III부 생활 리듬

• 제9회 Hermes Agent가 매일 아침의 태스크를 자동 실행하게 하는 방법
• 제10회 Hermes Agent가 사용할수록 똑똑해지는 Skills 등록 방법
• 제11회 Hermes Agent가 최신 정보를 자동으로 취득하게 하는 방법

제IV부 기억을 나누어 키우기

• 제12회 Hermes Agent가 Memory로 취향과 전제를 기억하게 하는 방법
• 제13회 Hermes Agent와 Obsidian을 연동하여 지식을 공유하는 방법

제14회(본 기사) Hermes Agent가 과거의 대화를 자동으로 복원하게 만들기

전체 모습은 Hermes Agent 완전 구축 가이드에 있다.

직접 손을 움직이는 일은 거의 없는 회차다. Session Search는 새로 설정할 것이 없다. state.db에 저장된 대화 기록도, session_search 툴도 처음부터 활성화되어 있다. 따라서 이번 회차는 이미 작동하고 있는 것을 눈으로 확인하고, 자동 발화를 몸으로 이해하는 것이 주된 목적이다. SSH로 현황을 들여다보고, Telegram으로 "기억해내 줘"라고 한마디 부탁한다. 그것으로 끝난다.

이번 회차의 도달점

제13회 완료 시점과 제14회 완료 후의 차이점을 1분 만에 파악한다.

항목	제13회 완료 시	제14회 완료 후
기억하는 범위	"매번 사용할 전제" (Memory) + "오래 남겨두고 싶은 정보" (Obsidian Vault)	+ "대화했던 내용" (과거의 모든 대화 · state.db)
...	hermes sessions로 목록 · 대화 검색 · 통계 확인 가능

한마디로 요약하면 "Hermes에게 자신의 과거 대화까지 기억하게 만드는" 회차다.

이번 회차에서 등장하는 용어를 미리 익혀두자.

용어	의미
Session (세션)	Hermes와의 1회분 대화. CLI, Telegram, Discord, cron 등 진입점마다 기록됨
state.db	과거의 모든 대화가 들어있는 SQLite 데이터베이스. 위치는 ~/.hermes/state.db. 전문 검색용 인덱스(FTS5)가 붙어 있음
FTS5	SQLite의 전문 검색 엔진 (Full-Text Search Engine). 대량의 문장에서 해당 부분을 고속으로 찾는 메커니즘. Session Search의 토대
session_search	Hermes가 과거 대화를 검색하기 위해 스스로 호출하는 내장 도구. 사람이 직접 입력하는 명령어가 아님. v0.15 이후로는 LLM을 사용하지 않는 무료·고속(약 0.06초) 검색 방식이 됨
hermes sessions	사람이 직접 과거 대화를 들여다보거나 정리하는 관리 명령어. list (목록), browse (대화형 탐색), stats (통계) 등
/new (Telegram 명령어)	동일한 DM 내에서 새로운 세션으로 명시적으로 전환. 이를 입력하면 그때까지의 주고받은 내용은 '과거 세션'으로 취급되어 자동 발화(Trigger) 대상이 됨
세션 리셋	동일한 DM이라도 일정 시간(idle·기본 24시간)이 경과하거나, 매일 특정 시각(daily·기본 4시)에 대화 단위가 자동으로 끊기는 메커니즘

과거의 주고받은 내용을 찾을 수 없다는 고통

기능 설명에 앞서, 누구나 겪을 법한 '공감 상황'부터 시작하겠다.

"어라, 뭐라고 했었지?"를 찾을 수 없다

이전에 Hermes와 상담했던 이야기를 다시 꺼내고 싶을 때가 있다. "지난주 Telegram에서 이야기했던 그 AWS 비용 최적화 건, 어떤 순서로 줄이라고 했었지?"라고 말이다. 채팅 내역을 거슬러 올라가 보지만, 어느 날이었는지 알 수 없어 10분 동안 스크롤만 하다가 포기한다. AI와 상담한 본인이 정작 상담한 내용을 꺼내지 못하는 것이다.

제12회의 Memory는 "매번 사용하는 전제 조건" (이름, 가족, 취향)을 기억하지만, 지난주의 구체적인 대화 내용까지는 가지고 있지 않다. 제13회의 Obsidian Vault는 "길게 남겨두고 싶은 정보" (조사한 기사나 자신의 메모)를 담는 상자이지만, Hermes와의 대화 그 자체는 직접 손으로 옮겨 적지 않는 한 들어가지 않는다. 과거의 주고받은 내용은 그 어느 서랍에도 들어있지 않다.

이는 제13회까지 진행했더라도 구조적으로 남게 되는 빈틈이다. "관심 있는 기사", "나의 인물 카드"는 보관 장소가 정해졌지만, "내가 나누었던 대화"는 보관 장소가 공중에 떠 있는 상태다.

하지만, 기록은 전부 남아 있다

사실 Hermes는 주고받은 대화를 전부 ~/.hermes/state.db에 자동으로 기록하고 있다. CLI로 입력한 대화, Telegram으로 보낸 대화, Discord로 온 대화, cron이 자동으로 실행된 아침 뉴스 요약까지, 모두 동일한 데이터베이스에 들어 있다. 사라지지 않았다. 문제는 단지 "찾을 수 없다"는 것뿐이다.

Session Search는 이렇게 쌓인 기록에 검색 창구를 달아준다. 게다가 사람이 검색 버튼을 누르는 것이 아니라, Hermes가 "이것은 과거에 이야기했던 건이구나"라고 알아차리고 스스로 검색한다. "기억해내 줘"라고 부탁하기만 하면, 상대방이 대신 찾아준다. 제13회까지의 "서고"에 사서(Librarian)를 한 명 고용하는 이미지다.

이번에는 서고에 검색 창구를 추가한다

제13회에서 제시했던 4가지 비유를 다시 전부 나열할 필요는 없다. 이번에는 하나만 추가하겠다.

4가지 비유는 그대로, 서고에 "사서"를 배치한다

제13회에서 Memory=포스트잇, Obsidian Vault=서고, Skills=매뉴얼, Cron=재고 조사라는 4가지 비유를 들었다. 이번의 Session Search는 새로운 다섯 번째 비유가 아니다. 서고에 "사서"를 두는 이야기다.

비유	Hermes 기능	역할
📝 포스트잇	Memory (USER.md/MEMORY.md)	짧은 전제 조건·매번 사용하는 것·곁에 붙여두는 것
	서고의 내용을 자동으로 찾아 가져옴 (이번 회차에서 추가)
📋 매뉴얼	Skills	"이렇게 움직인다"는 레시피·상황에 따라 꺼내 쓰는 것
🧹 재고 조사	Cron	정기적으로 정리·오래된 것을 치우는 것

사서가 다루는 "서고"는 제13회의 Obsidian Vault(직접 남긴 메모)와 이번 회차의 state.db

(과거 대화의 자동 기록) 모두를 포함한다. 물리적으로는 별개의 파일이지만, Hermes의 관점에서는 동일한 「서고의 선반」으로 취급된다. 이번 회차의 사서(Session Search)가 주로 드나드는 곳은 state.db의 선반이다.

서고(과거의 기록)에는 책이 쌓여 있다. 하지만 선반에서 원하는 책 한 권을 스스로 찾는 것은 매우 힘들다. 그래서 사서를 고용한다. "지난주에 상담했던 그 AWS 비용 최적화 건에 대한 기록을 가져와줘"라고 말하면, 사서가 서고에서 해당 기록을 찾아온다. Session Search는 바로 이 사서에 해당한다.

개념 정리(구성도)

과거 대화에 접근하는 경로는 두 가지가 있다. 이 부분을 구분해서 이해해 두면 이번 회차의 목차를 납득하기 쉽다.

같은 state.db에 두 가지 경로가 있다

대화는 입구와 상관없이 한 곳(~/.hermes/state.db)으로 집약된다. 거기서부터 두 가지 경로가 뻗어 나간다.

경로	누가 움직이는가	무엇을 위해
(a) 자동 경로	Hermes가 스스로 session_search를 호출	"기억해내 줘"라는 요청으로 발화하며, 과거 대화를 찾아 답변함
(b) 수동 경로	사람이 hermes sessions 명령어로 들여다봄	내용을 자신의 눈으로 확인하거나 정리함

(a)가 이번 회차의 주인공인 자동 발화이다. (b)는 "내용을 직접 눈으로 보고 싶을 때" 사용하는 수단이며, (a)가 제대로 작동하지 않았을 때의 확실한 대안이 되기도 한다. 이번 회차는 (b)로 내용을 먼저 들여다본 뒤, (a)를 체감하는 순서로 진행한다.

session_search는 「무료·고속」이 되었다

과거 정보에는 "과거 대화 검색을 위해 요약용 AI 모델을 할당한다"라고 적혀 있는 경우가 있지만, v0.15 이후로는 다르다. session_search는 LLM(생성형 AI)을 사용하지 않는, 순수한 전문 검색(Full-text Search) 도구로 다시 만들어졌다. 실제 기기에서 측정하면 1회당 약 0.06초가 소요된다. API 비용도 들지 않는다. 따라서 "검색을 위해 모델을 설정할" 필요는 없다. 이미 활성화되어 있다.

사전 준비

VPS에 접속하여 구동을 확인하고, 과거 대화 기록 파일(state.db)이 실제로 존재하는지 눈으로 확인한다. 다음 두 가지가 갖춰지면 다음 장으로 넘어갈 수 있다.

VPS 실제 기기 버전 확인

ssh -i ~/.ssh/hermes_vps_ed25519 admin@hermes-vps
hermes version # v0.17.0(2026.6.19 The Reach Release) 이후인지 확인

v0.17.0보다 낮은 버전이 나올 경우, hermes update로 본체를 최신으로 올린 후 다시 시도한다. 이번 회차의 절차 자체는 v0.15 이후 버전에서 동작하지만, 제15회 이후와의 연결성을 고려하면 최신 버전으로 맞춰 두는 것이 안심된다.

과거 대화 기록 파일(state.db) 확인

Hermes가 대화를 쌓아두는 데이터베이스가 실제로 존재하는지 눈으로 확인한다. state.db 본체와 더불어, 쓰기 작업 중인 임시 파일(-wal / -shm)이 나란히 있는 것이 정상적인 상태다.

ls -la ~/.hermes/state.db*
# state.db / state.db-shm / state.db-wal 이 나열됨

이 파일이 「서고」의 실체다. 크기(수십 MB)를 보면 이미 상당한 양의 대화가 쌓여 있음을 알 수 있다. SQLite는 쓰기 중인 차이분을 -wal (Write-Ahead Log)에 저장했다가 본체에 합치는 구조이므로, 세 파일이 나란히 있는 것이 일반적인 모습이다. 참고로 ls는 바이트 수를 직접 나타내며, hermes sessions stats (다음 장에서 사용)는 동일한 값을 MiB(이진 기반) 단위로 "91.2 MB"라고 표시한다. 양자는 동일한 95,678,464 바이트를 서로 다른 단위로 표현하고 있을 뿐이다.

촬영용으로 딱 한 번의 대화만 준비해 두기 (§7의 사전 준비)

§7에서 "기억해내 줘"라고 부탁하는 핵심적인 경험을 하기 위해, 그전에 딱 한 번 평범한 주제로 Hermes와 대화를 나누어 둔다. 이렇게 하면 state.db에 해당 대화가 기록되어 나중에 확실하게 검색 대상이 된다. 실제로 나누지 않은 주제를 "기억해내 줘"라고 요청하면 찾아낼 수 없으므로, 반드시 한 번은 실제로 대화해야 한다.

얼마 전, 아내와 고등학생 딸로부터 "나고야, 맛집 말고는 뭐가 있는지 모르겠어"라는 말을 들어서 Hermes에게 명소(Spot)를 물어본 적이 있다. 이번 회차의 소재는 이를 그대로 재현한다. Telegram으로 다음과 같이 자연스러운 대화를 한 번 주고받는다.

(자신이 Hermes에게)
7월에 가족들과 나고야 여행을 가는데, 고등학생 딸이 좋아할 만한 인스타 감성 명소(映えスポット)를 알려줘.
(Hermes의 응답)
...

1회 왕복이면 충분하다. 이것으로 state.db에 「나고야」 「인스타 감성 명소」 「딸」을 포함하는 대화가 1개 기록된다. 평소 생활 속에서 실제로 상담하고 싶은 화제로 진행하면, 그것이 그대로 §7의 재료가 된다.

자동 발화(Automatic Trigger)를 체감하기 전에 세션을 구분하기 (중요)

Telegram의 동일한 DM은 표준 상태에서는 하나의 연속된 세션으로 이어진다. 전항에서 설정한 직후에 같은 DM으로 「기억해내 줘」라고 물어도, 그것은 현재 세션의 일부일 뿐이며, session_search는 발화하지 않는다 (Hermes는 눈앞의 주고받은 대화를 그대로 사용한다). 설정한 대화를 과거 세션으로 바꿀 필요가 있다.

방법은 세 가지다. 자신의 운용 방식에 맞는 것을 선택한다.

방법	절차	확실성·타이밍
방식 A · /new로 명시적 리셋	설정 직후 Telegram에서 /new를 전송. 즉시 새로운 세션이 끊김	가장 확실함 · 당일 내 체감 가능
방식 B · 24시간 이상 비우기 (idle reset)	밤에 설정 → 다음 날 밤에 체감. 1440분(24시간) 비활성 상태면 자동으로 새로운 세션이 됨	자연스러움 · 실제 운용 상황에 가까움
방식 C · 다음 날 새벽 4시를 넘기기 (daily reset)	밤에 설정 → 다음 날 새벽에 체감. 기본 설정으로 매일 새벽 4시에 새로운 세션으로 끊김	자연스러움 · 가장 빠르게 다음 날 새벽 체감 가능

이번 회차에서는 A를 채택한다. 설정 직후에 바로 체감 단계로 진행하기 위해, 즉시 세션을 끊을 수 있는 /new가 최적이다. B와 C는 「24시간 이상 비우고 다음 날 시도하는 운용」, 「다음 날 새벽에 구분을 두는 운용」의 선택지로서 머릿속에 넣어두면 된다.

과거 대화의 저장소를 들여다보기

자동 발화를 체감하기 전에, 사람의 입장에서 「얼마나 쌓여 있는지」, 「어떤 대화가 있는지」 미리 들여다본다. 이것이 구성도(b)의 수동 경로다.

얼마나 쌓여 있는가 (stats) + 최근 대화 (list)

먼저 통계를 본다. 몇 세션, 몇 메시지가 쌓여 있는지, 데이터베이스의 크기는 어느 정도인지 확인한다.

hermes sessions stats

실기에서는 다음과 같이 표시된다 (숫자는 환경에 따라 다름).

Total sessions: 188
Total messages: 3789
cli: 17 sessions
...

연재를 여기까지 진행해 온 실기(VPS 상주 3개월 상당)에서는 188 세션, 3,789 메시지, 91.2MB가 쌓여 있었다. stats 출력에는 cli/telegram/discord의 3가지 카테고리만 나오지만, 합계 188과의 차이인 129건은 다음에 볼 list의 ID 열을 보면 정체를 알 수 있다──cron_* 프리픽스(prefix)를 가진 세션(제9회에서 넣은 매일 아침 뉴스 요약이나 밤의 회고 등)이 대부분을 차지하고 있다. Telegram의 40이 「내가 능동적으로 나눈 대화」, CLI의 17이 「ssh로 접속해서 입력한 대화」가 된다.

이어서 최근 대화를 목록화한다. 제목은 자동으로 붙여져 있다.

hermes sessions list

「제목 / 프리뷰 / 최종 업데이트 / ID」가 나열된다. morning-news나 evening-reflection 같은 자동 대화(cron 유래)와 내가 나눈 대화가 섞여 보인다. 이것이 「서고의 선반」이다.

대화형으로 찾기 (browse)

목록에서 원하는 대화를 대화형으로 찾아 그 대화를 재개(resume)할 수 있는 것이 browse다.

hermes sessions browse

대화 피커(선택 화면)가 열리며, 키워드로 필터링하여 선택할 수 있다. 이것은 「사서에게 부탁하지 않고, 스스로 서고의 선반을 걷는」 경로다. 다음 장의 자동 발화가 제대로 작동하지 않을 때도, 이곳을 통해 확실하게 과거 대화에 도달할 수 있다. Enter를 누르면 해당 대화의 다음 내용을 CLI에서 재개할 수 있다.

자동 발화를 체감하기 (이번 회차의 핵심)

여기가 이번 회차의 하이라이트다. 아무것도 설정하지 않았는데, Hermes가 과거 대화를 스스로 가져온다. 그것을 Telegram에서 체감해 본다.

「기억해내 줘」라고 부탁하기만 하면

여기서 먼저 발화(trigger)의 핵심을 하나 짚고 넘어가자. 시험 삼아 "지난주 나고야 여행 건, 기억하고 있어?"라고 물으면, Memory에는 나고야라는 지명이 없기 때문에 Hermes는 "바로 떠올릴 수 없습니다"라고 대답해 버리는 경우가 있다 (Memory는 "나에 관한 것"만 가지고 있기 때문에, 잡담 토픽은 들어있지 않다). 똑같은 내용을 "어떤 이야기였는지 기억해서 알려줘"라고 다시 부탁하면, Hermes가 스스로 state.db를 검색하러 간다. 같은 의뢰라도, 의뢰 형태 하나에 따라 서랍을 여는 방식이 달라진다.

모선(Mother ship)에서 Telegram을 통해, 미리 설정해 둔 나고야 여행의 인스타 감성 스팟(映えスポット) 상담에 대해 "기억해내 줘"라고 부탁한다. 전장에서 /new를 입력하여 세션을 종료했다면, 이것이 "과거 세션에 대한 참조"가 된다.

전에 7월 나고야 여행에서 딸이 좋아할 만한 인스타 감성 스팟을 물어봤었지.
어디를 추천해 줬었는지, 기억해서 알려줘.

Hermes가 과거 대화를 찾아 답변하다

의뢰를 보내면, Hermes는 "이것은 과거에 이야기한 건이다"라고 판단하고, 스스로 session_search를 호출한다. 실기 v0.17.0(2026.6.19)에서는 Telegram 화면의 응답 텍스트 직전에 가는 글씨로 도구 호출(tool call) 진행 상황이 표시되는 것을 확인할 수 있었다. 그 이전 버전에서 동일한 진행 표시가 나오는지는 미확인이나, 본 회차 시점의 v0.17.0이라면 볼 수 있는 동작이다. 그리고 과거 대화의 내용을 가져와서, "지난주에는 이런 후보들을 말씀드렸습니다"라고 답변이 돌아온다.

사람은 검색 명령어를 전혀 입력하지 않았다. "기억해내 줘"라고 부탁했을 뿐인데, 상대방이 서고까지 가서 해당 기록을 찾아 답변했다. 이것이 Session Search의 "자동으로 복원하게 만들기"의 정체다.

뒤에서 어떤 일이 일어나고 있는가 (CLI로 자세히 보기)

Telegram에서도 진행 상황의 개요는 나오지만, 더 자세히 보고 싶을 때는 CLI에서 -v (verbose)를 붙여 실행하면 검색 쿼리(query)의 내용까지 드러난다. 2026-06-24에 수중의 모선에서 ssh로 접속하여, X 북마크 정리 이야기로 실기 검증을 했을 때의 로그를 가져와 둔다 (별개의 주제지만 session_search의 동작을 확인한 실기 로그).

[thinking] 과거의 관련 대화를 찾기 위해 session_search를 사용함
🛠️ Tool call: session_search
args: {"query":"X 북마크 정리 카테고리","limit":10,"sort":"newest"}
...

"기억해내 줘"라는 한마디로부터, Hermes가 스스로 검색 쿼리(X 북마크 정리 카테고리)를 구성하여, 0.06초 만에 과거 대화를 가져온다. 쿼리의 단어는 사용자가 지정한 것이 아니다. 의뢰문 내용으로부터 Hermes가 스스로 추출하여 구성한 것이다.

비포/애프터

상태	"지난주 나고야 여행 건, 뭐라고 했었지?"에 대한 반응
Memory만 있을 때 (제12회)	"나에 관한 것"은 대답할 수 있지만, 지난주의 구체적인 주고받음은 가지고 있지 않음
...

제12회→제13회→제14회를 거치며, 기억하는 범위가 "짧은 전제" "길게 남긴 지식" "과거의 주고받음 전부"로 3단계에 걸쳐 확장되었다. 세 개의 서랍이 갖춰져야 비로소 Hermes를 "잊지 않는 파트너"라고 부를 수 있는 상태가 된다.

sessions와 Memory의 구분 사용

독자가 혼동하기 쉬운 "sessions(주고받은 기록)"와 "Memory(나에 관한 것)"의 경계를 정리하고, 평소에는 건드리지 않는 편이 좋은 것에 대해 짚어둔다.

sessions와 Memory는 별개다

계층	내용	누가 읽는가
Memory (USER.md/MEMORY.md)	나에 관한 것 = 이름·가족·취향·전제	매 세션 시작 시 자동으로 읽힘
sessions (state.db)	과거의 대화 그 자체 = 주고받은 전문	필요할 때 session_search로 검색됨

Memory는 "매일 가방에 넣어 다니는 필수품", sessions는 "필요할 때 여는 대화 로그 서고"다. Memory에 대화를 전부 채워 넣을 필요는 없으며, 할 수도 없다 (제12회에서 보았듯이 USER.md는 1,375자, MEMORY.md는 2,200자의 상한이 있다). 대화의 기록은 sessions가 자동으로 담당한다. 역할이 다르다.

오래된 이력의 정리는 "재고 조사" 회차에 맡기기

대화가 계속 쌓이면 state.db는 커진다. 연재를 여기까지 진행해 온 시점에서 3개월 동안 91MB였다. 1년 동안 돌리면 더 늘어나겠지만, 실제 증가량은 cron의 실행 방식이나 Telegram 이용량에 따라 크게 달라진다. 한 달에 한 번 정도 hermes sessions stats로 증가 추이를 살펴본다면, 정리가 필요한 타이밍은 자연스럽게 판단할 수 있다. 오래된 이력을 한꺼번에 정리하는 작업은 있지만, 그것은 「재고 조사(棚卸し)」 = Cron/Curator의 영역이다(연재 후반부 예정 회차에서 다룬다). 이번 회차에서는 「다시 불러올 수 있는 것」에 집중하고, 정리는 재고 조사 회차로 미룬다.

평소에는 직접 건드리지 않는다

state.db는 Hermes가 관리하는 SQLite 데이터베이스다. 내용 정리나 삭제를 하고 싶을 때 필요한 명령어(delete / prune / rename)는 hermes sessions 서브 커맨드(subcommand)로 이미 갖춰져 있으므로, 애초에 직접 에디터로 열 필요가 없도록 설계되어 있다. 쓰기 작업 중(-wal 파일에 반영되지 않은 차분이 있는 상태)이라도 hermes sessions를 통한다면 안전하게 다룰 수 있으므로, 이것에 맡겨두면 된다.

요약 및 제15회 예고

제14회에서 한 일.

• VPS 실기 v0.17.0에서 ~/.hermes/state.db가 실제로 존재함을 확인했다
• hermes sessions stats로 누적 세션 수·메시지 수·DB 크기를 눈으로 확인했다
• hermes sessions list / browse로 과거 대화의 선반을 훑어보았다
• Telegram에서 「기억해내 줘」라고 부탁하는 것만으로, Hermes가 스스로 session_search를 호출하여 과거 대화를 가져오는 자동 발화(automatic trigger)를 체감했다
• 발화하기 쉬운 요청 형태(「기억해내서 알려줘」)와 발화하기 어려운 요청 형태(「기억하고 있어?」)의 차이를 파악했다
• 동일한 DM에서 세션을 구분하는 3가지 방법(/new / idle reset / daily reset)을 정리했다
• sessions와 Memory의 역할 차이(대화의 기록 / 나에 관한 것)를 경계로 설정했다

이로써 Hermes는 「매번 사용하는 전제(Memory)」, 「길게 남겨두고 싶은 정보(Obsidian Vault)」, 「대화했던 내용(Session Search)」의 3가지를 모두 갖춘 파트너로 성장했다. 「지난주 Telegram에서 이야기했던 그 AWS 비용 최적화 건」과 같이 머릿속 구석에만 남아 있는 파편도, 「기억해내 줘」라고 부탁하면 알아서 서고에서 찾아온다.

제15회(예정)는 그 범위를 다른 AI로 확장한다. 모선(mother ship)에서 구동 중인 Claude Code나 Codex의 대화 이력도 동일한 서고로 통합할 수 있도록 만든다. 자신의 대화를 불러올 수 있게 된 Hermes가, 다음 단계로는 다른 AI와의 대화까지 하나로 묶어가는 단계다.

← 이전 회차	다음 회차 →
제13회 Hermes Agent와 Obsidian을 연동하여 지식을 공유하는 방법	제15회 Hermes Agent에 다른 AI의 세션도 흡수시키는 방법 (곧 공개)

📑 시리즈 목차