AI가 나를 오래 기억하는 두 방식 — OpenClaw는 검색으로 회상하고, Hermes는 늘 머릿속에 둔다

개인 AI 어시스턴트 OpenClaw를 다룰 때, 그 봇이 나를 세션 너머로 기억하는 방식은 마크다운 파일에 사실을 쌓아 두고, 대화 도중 필요해지면 그때그때 꺼내 오는 것이었다. 기본적인 LLM(Large Language Model, 대량 텍스트로 학습한 언어 모델 — ChatGPT·Claude 같은 것의 엔진) 대화는 한 세션이 끝나면 그 안의 기억이 통째로 증발한다 — 어제 "코드 설명은 짧게 해줘"라고 말해도 오늘 새 창을 열면 또 장황하게 답하는 식이다. 이 글이 다루는 "기억"은 바로 이 세션의 경계를 넘어 지속되는 장기 기억(long-term memory, 영속 기억)이다. 대화 도중에만 컨텍스트에 떠 있다가 세션과 함께 사라지는 단기 기억이나, 특정 사건 하나하나를 시점과 함께 기록하는 에피소드 기억이 아니라, "어제 한 말을 오늘도 아는" 지속성 그 자체를 말한다. OpenClaw는 그 사라진 기억을 파일에 남겨 두고, 회상할 때 임베딩 기반 시맨틱 검색(semantic search — 단어가 달라도 뜻이 비슷하면 찾아내는 의미 검색)으로 되살렸다.

또 다른 오픈소스 AI 에이전트 Hermes Agent를 같은 집 서버에 올려 memory 도구의 내부를 뜯어보니, 정확히 반대편에서 같은 문제를 풀고 있었다. Hermes는 기억을 검색으로 꺼내지 않는다. 대신 두 개의 아주 작은 파일(합계 약 3,600자 상한)에 욱여넣고, 매 세션 시작마다 그 전부를 시스템 프롬프트에 통째로 상주시킨다 — 찾을 필요 없이 늘 머릿속에 둬 버리는 것이다. 이 글은 그 갈림길 하나만 따라간다 — 장기 기억을 '항상 상주'시키느냐, '필요할 때 검색'해 회상하느냐. 나머지 차이는 전부 여기서 파생된다.

같은 문제, 갈라지는 결정 — 늘 상주시킬까, 검색으로 꺼낼까

두 봇이 푸는 문제는 똑같다. "세션이 바뀌어도 사용자를 기억하라." 그런데 그 목표에 도달하는 첫 결정에서 갈린다. OpenClaw는 기억을 넉넉히 쌓아 두고 필요한 순간 의미로 검색해 꺼내는 쪽을 택했고, Hermes는 소수의 핵심만 골라 매 세션 처음부터 머릿속에 상주시키는 쪽을 택했다. 두 스택을 나란히 보면 결정의 방향이 반대라는 게 한눈에 드러난다.

▲ OpenClaw — 파일에 쌓아 두고, 필요할 때 의미로 검색

위 다이어그램은 OpenClaw가 기억을 다루는 흐름을 한 줄기로 요약한 것이다. 사실을 마크다운 파일에 계속 쌓아 두되, 그것을 매 대화에 통째로 들고 있지는 않는다. 대신 의미 색인을 미리 만들어 두고, 대화 도중 과거 정보가 필요해지는 순간에만 검색으로 꺼내 온다. 여기서 "기억"은 곧 "필요할 때 잘 찾아내느냐"의 문제로 환원된다 — 평소에는 기억이 대화 밖 창고에 잠들어 있고, 호출당할 때만 깨어난다.

▲ Hermes — 두 작은 파일을 매 세션 통째로 머릿속에

위 다이어그램은 Hermes가 같은 문제를 반대편에서 푸는 방식이다. 기억을 딱 두 개의 작은 파일로 나눠 담는다 — 하나는 환경 사실·프로젝트 관례를 적는 에이전트의 개인 노트, 다른 하나는 이름·역할·말투 선호를 적는 사용자 프로필이다. 둘을 합쳐 약 3,600자라는 좁은 칸에 가두고, 세션이 시작될 때마다 그 전부를 시스템 프롬프트(system prompt — AI에게 주는 기본 지침문, 매 대화 맨 앞에 고정으로 붙는다)에 통째로 끼워 넣는다. 검색이라는 단계가 아예 없다 — 기억은 늘 대화 첫머리에 떠 있으므로 찾을 필요 없이 즉시 참조된다. 대신 그 대가로, 담을 수 있는 양이 이 좁은 칸으로 못 박힌다.

상주의 값 — 즉시 참조되지만, 칸이 작다

기억을 늘 머릿속에 두는 쪽의 이득은 분명하다. 검색이라는 왕복이 없으니 지연도 실패도 없고, AI는 매 순간 사용자 선호를 이미 알고 있다. 그런데 "매 세션 통째로 주입"에는 미묘한 트레이드오프가 하나 숨어 있다. 저장한 기억이 방금 세션에는 왜 안 보이는지를 보면 그 값이 드러난다.

위 다이어그램은 "늘 상주"를 값싸게 유지하는 장치를 보여준다. 세션 시작 시 기억 파일을 읽어 시스템 프롬프트에 한 번 박아 넣고(스냅샷), 세션 도중 AI가 기억을 추가·수정하면 디스크 파일은 즉시 바뀌지만 시스템 프롬프트 스냅샷은 끝까지 고정한다. 왜 이렇게 하냐면 prefix cache(접두 캐시 — 프롬프트 앞부분이 매 턴 똑같으면 모델이 그 부분의 계산을 재활용해 응답을 싸고 빠르게 내는 최적화) 때문이다. 상주 기억을 세션 중간에 바꾸면 이 캐시가 깨져 매 턴 처음부터 다시 계산해야 한다. 놓치기 쉬운 점은 "기억을 저장했는데 AI가 바로 모르네?"라는 의문인데, 디스크엔 분명히 적혔고 다음 세션부터 스냅샷에 반영된다.

대신 상주 기억은 크기를 키울 수 없다. 매 세션 통째로 시스템 프롬프트에 들어가는 만큼, 칸이 커지면 그대로 매 세션의 토큰(token — LLM이 텍스트를 처리하는 최소 단위, 비용·속도가 토큰 수에 비례) 비용이 된다. 그래서 Hermes는 칸을 일부러 3,600자로 좁혀 두고, 그 좁은 칸이 가득 차면 오래된 항목을 소리 없이 밀어내지 않고 저장을 거부해 AI에게 정리를 시킨다 — 겹치는 항목을 한 줄로 합치거나 낡은 항목을 지워 다시 담게 한다. 상주 방식의 값은 이렇게 "즉시 참조되지만, 무엇을 넣을지 매번 세밀하게 큐레이션해야 한다"로 요약된다.

검색의 값 — 무한정 쌓지만, 설정이 필요하다

반대편 OpenClaw는 기억을 대화에 상주시키지 않으므로, 칸 크기를 걱정할 이유가 없다. 파일에 얼마든 쌓아 두고 필요할 때만 꺼내면 된다. 대신 "필요할 때 잘 꺼내는" 능력 자체를 따로 갖춰야 한다.

위 다이어그램은 검색으로 회상하는 쪽의 이득과 대가를 함께 보여준다. 가장 큰 강점은 의미로 찾는다는 점이다 — 사용자가 저장할 때 쓴 단어와 물어볼 때 쓴 단어가 달라도, 뜻이 가까우면 끌어올린다. 비용 구조도 상주 방식과 정반대다. 기억이 대화에 늘 실려 있지 않으니 평소 토큰 비용은 0이고, 실제로 검색하는 그 순간에만 약간의 지연이 든다. 대가는 준비물이다 — 의미 검색은 텍스트를 벡터로 바꾸는 임베딩(embedding — 문장을 뜻이 담긴 숫자 배열로 변환하는 것) 모델을 갖춰야 돌아가고, 회상이 얼마나 정확한지는 그 모델과 설정에 달려 있다. 상주 방식이 "칸 관리"라는 숙제를 진다면, 검색 방식은 "검색 엔진 준비"라는 숙제를 진다.

정리 — 기억을 어디에 두었나

결국 두 봇은 "세션을 넘어 사용자를 기억하라"라는 같은 목표를, 기억을 어디에 두느냐 하나로 정반대 층에서 푼다. Hermes는 소수의 핵심을 대화 첫머리에 늘 상주시켜 검색 없이 즉시 꺼내 쓰고, OpenClaw는 방대한 기록을 대화 밖 창고에 쌓아 두고 필요할 때 의미로 검색해 꺼낸다.

	Hermes	OpenClaw
회상 방식	시스템 프롬프트에 늘 상주 — 검색 없이 즉시 참조	마크다운에 쌓아 두고 의미로 검색해 회상
대가	매 세션 토큰 비용 고정 · 칸이 작아 세밀한 큐레이션 필요	용량 걱정은 없으나 임베딩 모델 설정·품질에 의존

어느 쪽이 옳다기보다, 강한 자리가 다르다. 기억을 소수의 핵심으로 좁혀 늘 곁에 두고 즉시 반응하게 하고 싶다면 Hermes의 상주 방식이 강하다 — 대신 무엇을 그 좁은 칸에 넣을지 부지런히 관리해야 한다. 대화 기록을 넓게 쌓아 두었다가 나중에 "단어가 달라도 뜻으로" 회상하고 싶다면 OpenClaw의 검색 방식이 강하다 — 대신 임베딩 모델을 갖추고 검색 품질을 챙겨야 한다. "어제 한 말을 오늘도 아는" 연속성은 자율 에이전트의 진짜 전제 조건이지만, 그 연속성을 늘 머릿속에 둘 것인가, 필요할 때 찾아올 것인가가 이 두 봇을 가르는 첫 갈림길이었다.

---

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