요즘은 다양한 agent를 이용중인데, 불편함이 생겼다. 두 도구에서 Subscription 기반으로 OAuth 연동을 통해 Claude, Codex, Gemini 그리고 필요할때마다 OpenRouter에서 제공하는 Model들을 잘 사용하고 있었는데., Claude쪽이 말썽이다. 이유는 Anthropic이 3rd party에서는 API를 이용하라고 강제했기 때문이다. 물론 이 글을 작성하는 시점에 '조건부 허용' 이라는 기사가 떴다. (https://venturebeat.com/technology/anthropic-reinstates-openclaw-and-third-party-agent-usage-on-claude-subscriptions-with-a-catch) 사실 우회하는 방법은 많지만, 'FM'은 아니기에 우회 방법은 사용하지 않기로 정했다.
그러나 이런 상황들은 LLM Provider의 정책에 의해 언제든 바뀔 수 있는 부분이다. 물론 API 방식으로 사용하면 해결되지만, 비용도 고려해야 하기에 여러가지 고민을 해보았다.
A라는 Workspace에서 Pi나 Goose에서 작업을 하다가, Claude를 써야 할 경우에 해당 Workspace에서 Claude Code를 실행해서 작업을 이어나간다. 이럴 경우 Workspace에 저장된 내용을 Claude가 읽어서 작업을 시작해야 한다. 또 다른 경우는 하나의 도구만 쓰더라도 새롭게 세션을 열면 다시 설명을 해야 한다.
사람으로 치면 같이 일하던 동료가 바뀌거나 혹은 아침에 기억상실 상태로 출근하는 상황이다.
그래서 최근에는 AI agent에 'memory'를 붙이려는 시도가 많다. 단순히 대화 로그를 저장하는 수준이 아니라 프로젝트의 의사 결정, 실패 사례, 사용자 선호, 반복되는 작업 절차를 기억하게 만드는 흐름이다.
본 글에서는 Pi Coding Agent를 고려해서 세 가지 memory 도구를 비교했다.
- pi-hermes-memory
- Engram
- pi-hindsight
위 세 도구 모두 'AI agent'가 세션이 끝나도 기억을 유지하게 한다는 철학이다. 물론 접근 방식은 다르다.
결론부터 이야기하면, 내 기준에서는 세 도구의 용도를 아래처럼 정리했다.
- pi-hermes-memory: Pi에 바로 붙여 쓰기 좋은 경량 memory extension (이 경우 Pi내에서만 동작한다.)
- pi-hindsight: Hindsight라는 별도 memory system을 Pi에 연결하는 Adapter
- Engram: 여러 agent가 함께 쓸 수 있는 범용 memory layer
Pi만 사용한다면 -> pi-hermes-memory, Claude Code, Codex, Gemini CLI, OpenCode 등 여러 agent를 함께 쓴다면 -> Engram, 장기적으로 agent memory architecture를 연구하거나 제품화 관점으로 본다면 -> Hindsight
지금은 Engram을 먼저 보기로 했다. 이유는 단순하다. 지금 환경이 하나의 agent만 쓰는 방향이 아니라, 여러 agent를 상황에 맞게 섞어 쓰는 방향으로 가고 있기 때문이다. 만약 Pi만 쓴다면 pi-* 를 선택했을거다.
이제 도구들의 특성을 하나하나 살펴보다.
pi-hermes-memory
이름 그대로 Pi에 memory를 붙이는 extension이다. 소개에는 'Persistent memory + session search + secret scanning for Pi'라고 설명되어 있다.
Pi agent가 세션을 종료하면 모든 것을 잊어버리는 문제를 해결하기 위해 만들어졌고, 과거 대화 검색, persistent memory, 실패 학습, correction detection, secret scanning, procedural skills 등을 제공한다.
이 도구의 장점은 Pi를 사용하고 있다면 가장 빠르게 붙일 수 있다. 별도의 서버를 띄우거나 복잡한 memory architecture를 이해할 필요가 없다. 설치하고 과거 세션을 indexing하고 Pi가 필요할 때 기억을 검색하게 만들면 된다.
마음에 들었던 부분은 '실패를 기억'한다는 점이다.
예를 들어 agent가 어떤 방식으로 문제를 해결하려다 실패를 하거나 사용자가 "아니, 이 프로젝트에서는 npm 말고 pnpm을 써야 해"라고 고쳐주었다고 하면, corection이나 failure를 기억해두고 다음 세션에서 같은 실수를 반복할 가능성을 낮춘다.
실제 memory category를 failure, correction, insight, preference, convention 등을 나눠서 저장하도록 설계되어 있다. 그리고 background learning을 통해 일정 턴마다 중요한 내용을 저장한다.
만약 기억해둔 내용을 매번 프롬프트에 잔뜩 주입하면 토큰 효율성이 떨어진다. 이러면 기억은 되지만 context가 빠르게 비대해지게 된다. 그래서 기본적으로 전체 Markdown memory를 매번 주입하지 않고, memory policy만 넣은 뒤 필요할 때 memory search를 호출하도록 설계되어 있다.
즉, '모든 기억을 항상 보여주기' 보다는 '필요할 때 찾아오기'이다.
단점도 존재한다.
기본적으로 Pi 중심이다. Pi 하나를 잘 쓰게 만드는 데는 좋지만, 다양한 agent를 쓰는 환경에서는 Pi내에서만 memory가 갇힌다.
또한 저장구조도 무제한이라고 보기는 어렵다. MEMORY.md와 USER.md가 5,000자 제한이 있다.
정리하면 Pi를 더 똑똑하게 만드는 도구다. Pi를 메인 agent로 쓴다면 매우 실용적이다. 그러나 여러 agent가 같은 기억을 공유하는 구조를 원한다면 조금 아쉬울 수 있다.
Engram
Pi 전용 extension이기 보다는 AI coding agent를 위한 범용 persistent memory system이다. 프로젝트 소개에서는 Engram을 'Agent-agnostic'이라고 설명하고 있다.
Claude Code, OpenCode, Gemini CLI, Codex, VS Code 등 MCP를 지원하는 다양한 agent와 함께 사용할 수 있다.
Provider의 구독 모델로만 사용하는 환경에서는 코딩 agent의 사용 방식이 하나의 도구에 고정되지 않을 가능성이 높다. 어떤 작업은 Claude Code가 편하고, 어떤 작업은 Codex가 좋고, 여유롭게 작업하려면 Gemini CLI나 OpenCode를 사용할 수도 있다.
그런데 각 agent가 서로 다른 기억을 가지고 있다면, 결국 사용자는 매번 같은 설명을 반복해야 한다.
Engram은 이 문제를 'agent 바깥의 공용 memory layer'로 해결한다.
즉, agent가 기억하는 것이 아니라, Engram이라는 별도의 memory brain이 있고 여러 agent가 여기에 접근하는 구조다. 어제 배운 architecture, decision, bug fix 이유, 사용자 선호, context compaction 이후에도 알아야 할 내용을 기억하지 못하는 문제를 해결한다.
Go binary 하나와 SQLite 중심으로 동작하기에 별도의 서버를 고려하지 않고, 로컬 환경에서 동작하는게 큰 장점이다.
물론 아주 완벽한 만능은 아니다. 검색 구조를 보면 기본은 SQLite + FTS5 중심이다. Hindsight처럼 semantic vector search, BM25, graph, temporal link, reranking까지 지원하는 구조는 아니다. 따라서 memory 검색 품질이나 장기 학습 구조를 아주 길게 유지하려면 Hindsight 쪽이 더 적합할 수 있다.
그리고 agent가 memory를 잘 사용하도록 행동 규칙을 알려줘야 한다. agent에게 언제 저장하고, 언제 검색하고, session이 종료될 때 summary를 남기고 compaction 이후에는 context를 회복하라고 가르쳐야 한다. 도구만 붙인다고 자동으로 좋은 기억이 생기지 않는다.
그래도 큰 노력없이 여러 agent를 함께 쓰는 개발자라면 Engram이 가장 먼저 검토할 만하다.
pi-hindsight
이 도구는 완전한 memory engine이라기 보다는 Hindsight라는 별도의 memory system을 Pi에 연결하는 Adapter이다. Pi에서 모델 호출 전에 관련 project의 memory를 recall하고, agent run 이후 structure d session delta를 retain 하며, retain/recall/reflect 도구를 제공하는 방식이다.
즉, 핵심은 Hindsight이다.
Hindsight는 'Agent Memory That Learn'을 표방한다. Retain은 기억할 정보를 저장, Recall은 관련 메모리를 검색, Reflect는 기존 메모리와 experience로 부터 새로운 observation이나 insight를 생성하는 방식이다.
꽤 흥미롭다. 단순 검색을 넘어서기 때문이다.
Hindsight 관련 문서에서는 memory bank, world facts, experiences, mental models 같은 구조를 언급한다. agent가 대화에서 facts를 추출하고, entity graph를 만들고, mental model을 합성해 시간이 지나도 사용자와 패턴을 기억하게 만드는 방향을 설명한다. 이것은 단순히 '대화 로그를 검색한다.' 와는 다른 방식이다.
예를 들어 FTS 기반 memory는 auth, pnpm, deployment와 같은 키워드가 잘 맞으면 좋은 결과를 줄 수 있다. 반면 Hindsight식 접근은 사람, 프로젝트, 의사결정, 시간적 맥락, 반복되는 패턴을 더 구조화해서 다루려는 쪽에 가깝다. 그래서 복잡하다.
Hindsight는 Server, API, UI, provider 설정 같은 운영 요소가 들어간다. 그래서 개인이 Pi 하나에 memory를 붙이는 싶다는 목적이라면 과할 수 있다. 그러나 장기적으로 agent memory를 제품화하거나, 기업용 agent platform의 memory layer를 설계하고 싶다면 Hindsight는 참고할 가치가 크다.
그래서 지금 시점에서는 실사용 1순위가 아니기에 잠시 넣어두고 memory에 대해서 공부하기 위한 용도로 활용하기로 했다.
위에서 언급한 세 도구를 비교해보면,
나의 선택은
난 지금 한가지를 먼저 써야 하기에 Engram을 선택했다. 이유는 단순하다. Warp내에서 Pi, Claude Code, Codex, Gemini CLI를 쓰는 식으로 흘러가기에 memory도 특정 agent가 공유하는 외부 계층에 있는 것이 필요했다. 많은 노력을 들이지 않아도...
그래서 Engram은 현실적이다.
맺음말
Ai agent의 생산성은 모델 성능만으로 결정되지 않는다. 좋은 모델을 쓰는것도 중요하지만, 그 모델이 내 프로젝트의 맥락을 얼마나 기억하는지, 어제의 실패를 반복하지 않는지, 내가 선호하는 방식을 이해하는지도 중요하다.
0 Comments:
댓글 쓰기