로컬 모델만으로는 부족하다. 로컬 에이전트 메모리가 필요하다
Local models are only half the story. I want local agent memory too
핵심 요약
모델 교체보다 중요한 것은 에이전트의 경험과 지식을 담는 로컬 메모리 주권 확보임.
- 모델 교체성 — 모델은 쉽게 바꿀 수 있지만 에이전트의 학습된 경험은 특정 벤더에 종속되기 쉬움.
- 메모리 주권 — 단순 채팅 로그가 아닌 실행 이력과 학습된 기술을 로컬에서 직접 관리하고 검사해야 함.
- 로컬 우선 전략 — 프라이버시와 디버깅을 위해 에이전트의 실행 상태와 설정을 로컬 파일 시스템에 보관함.
- 실행 기반 학습 — 단순 데이터 저장이 아닌 에이전트가 무엇을 배웠고 무엇이 실패했는지 재사용 가능한 형태로 저장함.
최근 Claude, GPT/Codex, 그리고 로컬 모델 사이를 오가는 사람들을 보면서 한 가지 분명해진 사실이 있습니다.
모델은 그 주변의 워크플로우보다 교체하기 쉬워지고 있다는 점입니다.
한 달 전에는 모두가 Claude Code에 깊이 빠져 있었습니다. 그러다 Codex가 좋아지고, GPT가 다시 매력적으로 느껴지고, 로컬 모델들이 특정 영역에서 따라잡으면서 사람들은 갑자기 스택의 일부를 옮기기 시작합니다. 저는 무엇이 더 낫다고 말하려는 게 아닙니다. 저 역시 상황에 따라 다른 모델을 사용하니까요.
하지만 이 현상을 보면서 제가 간과하고 있던 의존성에 대해 생각하게 되었습니다. 바로 메모리입니다.
모델은 하나의 요소일 뿐입니다. 언제든 교체할 수 있죠. 하지만 에이전트의 장기 기억, 즉 실제 학습된 경험이 벤더가 통제하는 블랙박스 안에 있다면, 당신은 그것을 온전히 소유한 것이 아닙니다. 당신은 에이전트의 뇌를 빌려 쓰고 있는 셈이죠.
취미 프로젝트라면 괜찮을지도 모릅니다. 하지만 실무, 특히 고객 데이터가 민감한 작업에서는 금방 불편해집니다. 감사 추적이 필요할 수도 있고, 데이터가 어디에 있는지 설명해야 할 수도 있습니다. 혹은 에이전트의 메모리가 블랙박스 SaaS 계층으로 사라지지 않는다는 것을 증명해야 할 수도 있죠.
짜증 나는 점은 에이전트 작업에 메모리를 실제로 사용해보려 하면 '메모리'라는 개념이 생각보다 복잡하다는 것입니다.
채팅 로그만으로는 부족합니다. 벡터 DB도 충분하지 않죠. 물론 유사한 청크를 검색할 수는 있지만, 그것이 에이전트가 무슨 일이 있었는지 학습했다는 것을 의미하지는 않습니다.
예를 들어, 에이전트가 배포 문제를 해결하는 데 30분을 썼다면, 저는 단순히 우리가 Docker에 대해 이야기했다는 사실만 기억하기를 원하지 않습니다. 어떤 명령어가 실패했고, 어떤 수정이 효과가 있었으며, 무엇을 반복하지 말아야 하고, 다음번에 무엇을 재사용할 수 있는지 기억하기를 원합니다.
코딩 에이전트도 마찬가지입니다. 특정 저장소가 pnpm을 사용한다거나, 어떤 해결책이 임시방편이었다는 것을 학습했다면, 그것은 에이전트의 작업 경험의 일부가 되어야 합니다. 그렇지 않으면 에이전트는 매 세션마다 똑같은 사실을 계속해서 재발견하게 될 뿐입니다.
그래서 저는 에이전트 스택을 로컬 우선의 투명한 방식으로 옮기고 있습니다. 단순히 개인정보 보호 때문만이 아니라, 제어 가능성과 디버깅을 위해서입니다.
참고로 제 설정은 그리 특별하지 않습니다. 대부분의 에이전트 작업에는 Hermes Agent를, 유사한 실험에는 OpenClaw를 사용하고, 더 많은 제어가 필요할 때는 OpenAI 호환 엔드포인트를 통해 로컬 모델을 사용합니다.
모델 측면은 사실 쉬운 부분이었습니다.
제가 과소평가했던 부분은 메모리였습니다.
제가 원했던 것은 실행 추적, 정책, 프로젝트 지식, 재사용 가능한 기술 등 검사 가능한 경험 계층에 가까운 것이었습니다. 단순히 컨텍스트에 다시 밀어 넣는 오래된 메시지 뭉치가 아니고요.
지금까지 찾은 것 중 가장 가까운 것은 MemOS Local Plugin입니다.
제게 의미가 있었던 부분은 '실행을 통한 학습'이라는 전체적인 관점이었습니다. '채팅 로그를 더 많이 저장하는 것'으로서의 메모리가 아니라, 에이전트가 작업을 수행하고, 무엇이 효과가 있었고 무엇이 실패했는지 확인하며, 그 경험을 재사용 가능한 것으로 바꾸는 메모리 말입니다.
그게 제가 실제로 원했던 것에 훨씬 가깝습니다.
제가 이 방식을 고수하는 이유는 마법 같은 메모리 성능 때문이 아닙니다. 메모리가 지루할 정도로 눈에 보이기 때문입니다.
Hermes의 경우, 런타임 데이터를 클라우드 대시보드 뒤에 숨기지 않고 로컬에 보관합니다.
설정, 로컬 데이터베이스, 기술 패키지, 로그를 제 컴퓨터에서 직접 볼 수 있습니다. 신비로운 것은 없습니다. 검사하고, 백업하고, diff를 확인하고, 잘못된 상태를 지울 수 있습니다. SaaS 대시보드가 적절한 버튼을 노출해주기를 기다릴 필요가 없죠.
백엔드 설정도 유연합니다. 임베딩과 LLM 백엔드는 별도로 구성되므로, 로컬로 유지하거나, OpenAI 호환 로컬 엔드포인트를 가리키거나, 설정에 필요하다면 클라우드 제공업체를 사용할 수도 있습니다.
