▲

Stash - AI 에이전트를 위한 지속형 메모리 계층

 (alash3al.github.io)
1P by GN⁺ 20시간전 | ★ favorite | 댓글 1개
  • 세션이 바뀌어도 대화와 작업 맥락을 이어가는 지속형 메모리 계층으로, 원시 관찰을 episodes로 저장한 뒤 구조화된 지식으로 누적함
  • 모델 비종속적 구조를 사용해 Claude, GPT, 로컬 LLM, 커스텀 에이전트까지 같은 메모리 계층에 붙일 수 있으며, 저장소는 PostgreSQL과 pgvector를 기반으로 동작함
  • RAG와 다른 역할을 맡아 문서 검색에 머무르지 않고, 대화에서 새 사실과 관계, 목표, 실패, 가설까지 축적하며 RAG와 함께 사용할 수 있음
  • namespace와 계층형 경로로 사용자, 프로젝트, 에이전트 자기지식을 분리하고, consolidation 파이프라인으로 facts, relationships, causal links, patterns, contradictions를 계속 합성함
  • MCP 네이티브 통합과 /self 기반 자기 모델, 반복 연구 루프까지 포함해 기억이 없는 세션형 에이전트를 장기적 연속성을 가진 작업 주체로 바꾸려 함

Stash 개요

  • 지속형 메모리 계층으로 AI 에이전트와 외부 세계 사이에 놓이며, 세션이 바뀌어도 이전 맥락을 이어가게 만듦
  • 원시 관찰을 episodes로 저장하고, 이를 facts, relationships, patterns, goals, failures, hypotheses 같은 구조화된 지식으로 누적함
  • 모델 자체를 대체하지 않고 연속성을 보강하며, Claude, GPT, 로컬 모델 등 어떤 에이전트에도 붙일 수 있게 설계됨
  • 저장 기반으로는 PostgreSQL + pgvector를 사용함
  • GitHub

메모리 구성 방식

  • namespace로 사용자, 프로젝트, 에이전트 자기지식 같은 메모리를 분리함
  • 각 namespace는 계층형 경로로 구성되며, /projects를 읽으면 /projects/stash, /projects/cartona 같은 하위 경로까지 함께 포함됨
  • 쓰기는 하나의 정확한 namespace에만 기록돼 메모리 오염을 막음
  • 사용자 관련 메모리와 프로젝트 메모리, /self 아래의 자기지식은 서로 섞이지 않게 유지됨
  • 예시 구조로 /users/alice, /projects/restaurant-saas, /projects/mobile-app, /self/capabilities, /self/limits, /self/preferences를 둠

RAG와의 차이

  • RAG는 문서에서 관련 내용을 찾아오는 검색 계층에 가깝고, 대화 자체를 기억하거나 학습하지 않음
  • RAG는 문서에 이미 들어 있는 내용만 다룰 수 있으며, 대화에서 새 지식을 만들지 못함
  • 목표 추적, 의도 파악, 시간에 따른 모순 탐지, 원인과 결과에 대한 추론은 RAG 범위 밖으로 제시됨
  • Stash는 대화, 결정, 성공, 실패에서 자동으로 학습하고 지식 그래프를 쌓아 감
  • 문서 검색과 경험 기억은 서로 다른 문제를 다루므로, RAG와 Stash를 함께 사용할 수 있음

기존 AI 메모리와 다른 점

  • Claude.ai와 ChatGPT에도 메모리가 있지만, 해당 기능은 자기 플랫폼과 자기 모델에 묶여 있음
  • Stash는 모델 비종속적으로 동작하며, 로컬 모델과 프라이빗 모델에도 붙일 수 있음
  • 데이터 소유권을 사용자 쪽에 두고, 오픈소스로 제공됨
  • 백그라운드 consolidation, goals 및 intent 추적, failures 학습, causal reasoning, agent self-model 같은 항목을 포함함
  • 비교표 기준으로 ChatGPT Memory와 Claude.ai Memory는 “notepad”, Stash는 “mind”로 구분됨

해결하려는 문제

  • 현재 AI 모델은 추론은 잘해도 세션 간 기억이 없어, 사용자가 매번 자신과 프로젝트 배경을 다시 설명하게 됨
  • 긴 대화 기록을 매번 프롬프트에 넣는 방식은 느리고 비싸며, context window 한계도 남아 있음
  • 실패한 시도를 다음 세션에서 다시 반복하지 않게 막아 줄 교훈 전달 메커니즘이 부족함
  • 메모리 기능이 일부 플랫폼의 전용 기능으로만 제공돼, 커스텀 에이전트나 로컬 LLM은 처음부터 맥락 없이 시작하게 됨

통합 파이프라인

  • 백그라운드 프로세스가 경험을 계속 합성해 원시 메모리를 구조화된 지식으로 바꿈
  • Episodes 단계에서 관찰을 append-only로 저장함
  • Facts 단계에서 episode 묶음을 LLM으로 합성함
  • Relationships 단계에서 fact 사이의 엔티티 관계를 추출함
  • Causal Links 단계에서 fact 간 원인-결과 쌍을 연결함
  • Patterns 단계에서 더 높은 수준의 추상 패턴을 도출함
  • Contradictions 단계에서 자기 수정과 confidence decay를 수행함
  • Goal Inference로 활성 목표에 대한 사실을 자동 추적하고 진행 상황과 충돌을 드러냄
  • Failure Patterns로 반복 실수를 감지하고 새로운 사실로 추출해 같은 실패 반복을 줄임
  • Hypothesis Scan으로 새로운 증거가 열린 가설을 수동 개입 없이 확인하거나 기각하게 함

MCP 통합

  • MCP 네이티브로 동작하며 Claude Desktop, Cursor, OpenCode, 커스텀 에이전트, 로컬 LLM, 기타 MCP 클라이언트에 붙일 수 있음
  • SDK 없이 연결할 수 있고, vendor lock-in 없이 어디서든 같은 메모리 계층을 쓰게 함
  • 총 28개 도구를 제공하며 remember, recall, forget, init부터 causal links, contradictions, hypotheses까지 포함함
  • ./stash mcp execute --with-consolidation으로 stdio MCP 서버와 consolidation을 함께 시작할 수 있음
  • ./stash mcp serve --port 8080 --with-consolidation으로 원격 에이전트용 SSE 서버를 띄울 수 있음

에이전트 자기 모델

  • init 호출 시 /self namespace 뼈대를 만들어 자기 모델 구성을 시작함
  • /self/capabilities에는 에이전트가 잘하는 일을 기억해 작업 계획에 활용함
  • /self/limits에는 실패 기록과 약점을 저장해 같은 실수 반복을 막게 함
  • /self/preferences에는 가장 잘 작동하는 운영 방식을 학습해 장기적으로 작업 스타일을 형성함

자율 학습 루프

  • 5분 단위 research loop를 돌리면 과거 메모리에서 현재 맥락을 잡고, 스스로 주제를 골라 조사하고, 새 연결을 만들고, 다시 통합한 뒤 종료함
  • Orient 단계에서 과거 맥락, 활성 목표, 열린 가설, 과거 실패를 불러옴
  • Research 단계에서 에이전트가 직접 고른 주제로 웹 검색을 수행함
  • Think 단계에서 현재 아는 내용 안의 긴장, 빈틈, 모순을 드러냄
  • Invent 단계에서 가설, 패턴, 발견 같은 새 산출물을 만듦
  • Consolidate 단계에서 파이프라인을 실행해 원시 episode를 구조화된 지식으로 합성함
  • Reflect + Sleep 단계에서 세션 요약을 남기고 다음 실행을 위한 맥락을 설정한 뒤 멈춤
  • 루프 프롬프트 보기

모델 및 인프라 호환성

  • embedding과 reasoning 모두에 OpenAI 호환 API를 사용하는 하나의 provider 구성을 전제로 함
  • 클라우드, 로컬, self-hosted 구성을 모두 지원하며 vendor lock-in이 없다고 밝힘
  • OpenRouter를 로컬에서 연결해 사용 중이라고 적고, 수백 개 모델을 하나의 API 키로 접근할 수 있게 함
  • Ollama와도 바로 동작하며, Qwen, Llama, Mistral 같은 로컬 모델로 오프라인 메모리 구성이 가능함
  • vLLM, LM Studio, llama.cpp server, Together AI, Groq처럼 OpenAI API 형식을 쓰는 백엔드도 지원 대상으로 적음
  • 기본 embedding 모델은 openai/text-embedding-3-small이고, 그 조합에서 STASH_VECTOR_DIM=1536을 사용함
  • STASH_VECTOR_DIM은 첫 실행 전에만 설정할 수 있으며, 초기화 후 바꾸면 전체 데이터베이스 재설정이 필요함

배포 및 사용 정보

  • Docker Compose로 Postgres, pgvector, Stash를 함께 올리는 구성을 제공함
  • 실행 절차는 저장소 clone, .env.example을 .env로 복사한 뒤 API 키와 모델을 설정하고 docker compose up을 실행하는 3단계로 제시됨
  • 초기 실행 후 postgres + pgvector 준비, migration 적용, MCP 서버 대기, 백그라운드 consolidation 실행 상태를 기대함
  • 프로젝트는 Apache 2.0 라이선스로 공개됨
  • GitHub Repository
  • alash3al.com

함께 보면 좋은 글 β

▲
GN⁺ 20시간전  [-]
Hacker News 의견들

  • Claude.ai 메모리 시스템 같은 걸 드디어 portable하게 만든 줄 알고 눌렀는데, 전혀 그게 아니었음
    여기 있는 건 그냥 store/remember 방식이고, 내가 더 낫다고 느낀 건 백그라운드 모델이 채팅 기록을 요약해서 메모리를 만드는 방식임
    그쪽은 모델이 직접 메모리를 써야 하지 않아서 훨씬 잘 작동했고, 그래서 이걸 Claude.ai와 같은 수준으로 소개하는 건 다소 misleading하게 보임
    나도 LibreChat 같은 쪽으로 옮기려고 같은 방식의 메모리 시스템을 계속 찾는 중인데 아직 못 찾았고, 지금 Claude.ai에 남아 있는 거의 유일한 이유가 그 기능임
    참고로 그 시스템은 Claude.ai에만 있고 Claude Code에는 없음

    • 최근 Claude Code leak에 따르면 autoDream이라는 게 있었고, 여기서는 background memory consolidation engine이라고 설명함: https://kuber.studio/blog/AI/Claude-Code's-Entire-Source-Code-Got-Leaked-via-a-Sourcemap-in-npm,-Let's-Talk-About-it
    • 이 접근은 정말 써보고 싶음
      내 경험은 정반대라서, 나는 https://github.com/flippyhead/ai-brain을 주로 나 자신을 위해 만들었고 친구 몇 명도 씀
      지금까지는 CLAUDE.md를 통해 AI에게 관련 메모리를 찾고, 언제 어떻게 저장할지 생각하게 하는 방식이 꽤 잘 먹혔음
      이 방식은 우선순위에 따라 구조를 만들고 미래를 위한 노트도 남길 수 있어서, 단순히 전부 요약하는 방식과는 꽤 다르게 느껴짐
    • 나는 자동 recall이 에이전트에게 보이지 않게 동작하는 쪽을 선호함
      메모리 생성은 tool call도 꽤 잘하고, 컨텍스트 압축 시 자동으로 메모리를 만드는 방식도 괜찮다고 봄
      다만 자동 생성이라면 비동기 consolidation이 필요하고, 그걸 dreaming이라고 부르는 건 좀 과장처럼 느껴짐
      내 구현은 Elroy.bot에 있고, 여러 접근은 여기 정리해 뒀음: https://tombedor.dev/approaches-to-agent-memory/
    • 그걸 어떻게 벤치마크하는지가 궁금함
      백그라운드에서 메모리를 추출하면 prefix cache와 잘 맞추기 어려운 게 문제임
      단순한 2단계 LOG.md(작업과 교훈의 상세 로그) + MEMORY.md(로그가 잘릴 때 승격된 항목 기록) + 턴 종료 시 실행되는 stop hook만으로도 꽤 멀리 갈 수 있음
    • 이 개념은 꽤 흥미로움
      사용자와 대화하는 에이전트 뒤에서 보조 인력들이 대화를 엿듣고 중요한 사실을 기록하거나, 관련 사실을 DB에서 찾아보다가 이 메모리 X가 관련 있어 보인다며 끼어드는 구조처럼 느껴짐
      토큰이 공짜라면 쉬워 보이지만, 이걸 효율적으로 만드는 건 꽤 재미있는 문제임

  • 구현 방식을 거의 안 밝힌 채 뭔가를 약속하는 프로젝트는 늘 큰 red flag로 보임
    더 파보면 사실상 pg_vector에 mcp, 그리고 recall/remember 두 함수가 붙은 구조임
    결국 RAG에 가깝고, 데이터 구조가 중요하다고 주장할 수는 있어도 지금까지 나온 이런 메모리 시스템들은 거의 다 비슷하게 동작했음
    아직은 기본적인 vector DB search보다 검색이 더 좋아졌다는 걸 입증한 사례를 못 봤음

    • 사이트는 멋지고, memory라고 쓰여 있고, LLM은 형편없지만 이 제품은 마법처럼 해결한다고 보여줌
      정말 그게 된다면, 결국 vectordb를 그럴듯하게 포장한 것에 가깝기도 함

  • 이미 리뷰가 있음: https://zby.github.io/commonplace/agent-memory-systems/reviews/stash/
    다른 수많은 LLM memory systems도 여기 모여 있음: https://zby.github.io/commonplace/agent-memory-systems/
    그리고 이런 시스템에 바라는 점도 정리해 둠: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/

  • 이런 agent memory systems는 과하게 설계된 것 같으면서도 동시에 덜 설계된 것 같고, 꽤 막다른 길처럼 보임
    최신 모델이 필요로 하는 것과 금방 어긋나고 썩어버리지 않을 현실이 잘 상상되지 않음
    예를 들어 결제 기능을 한 번 만들었다고 해서 don't use stripe 같은 메모리 때문에 이후 여러 세션이 자꾸 결제 쪽으로 기울어질 수 있음

    • 더 나쁜 건 작성자 본인도 직접 써본 흔적이 너무 없다는 점임
      완전히 unproven memory layer이고, 실사도 없이 화려한 마케팅 사이트에 과장된 주장만 올린 느낌임
    • 나는 이걸 정보 문제로 보고, 대부분을 저장하지 않도록 의도한 작은 유틸을 만들었음: https://github.com/skorokithakis/gnosis
      전제는 단순함. LLM이 원래 아는 내용은 계속 알 테니 LLM이 말한 건 저장하지 않고, 코드 관련 내용은 코드와 주석에 남기면 됨
      대신 둘 다 아닌데도 절대 캡처되지 않는 것들이 있음
      뭔가를 만들 때는 실제로 한 것보다 하지 않기로 한 것이 더 중요할 때가 많고, 이 유틸은 세션 끝에서 기각한 대안들과 그 이유를 잡아내 system knowledge로 저장함
      결국 코드 grep만으로는 찾을 수 없는, 동료들 머릿속에만 있는 정보를 남기고 싶은 거고 지금까지는 꽤 잘 작동하지만 아직 이르긴 함
    • 나는 직접 만든 bespoke memory system을 쓰는데, 모든 메모리를 맥락별 검색 공간으로 만들어서 이 문제를 피함
      don't use stripe 같은 메모리는 모델이 payment processing 관련 작업을 하라는 프롬프트를 받았을 때만 컨텍스트로 들어옴

  • 이런 걸 계속 찾고 있었고, 계정이 LLM 붐 이전부터 소프트웨어를 공개해 온 것도 보여서 반가움
    다만 프로젝트마다 LLM 사용 내역 같은 게 붙었으면 좋겠음
    LLM으로 생성했는지, 했다면 얼마나 했는지, 어느 단계에서 썼는지, 출력은 얼마나 꼼꼼히 검토했는지, 품질이 혼자 만들었을 때보다 최소한 같거나 더 낫다고 느끼는지 같은 정보가 있으면 좋겠음
    특정 개인을 의심하려는 게 아니라 모든 프로젝트에 공통으로 있었으면 하고, 나도 그렇게 할 생각임

    • 솔직히 이건 좀 entitled하게 들림
      누가 억지로 이 프로젝트를 쓰라고 하는 것도 아니고, 코드는 직접 읽고 검토한 뒤 쓸지 말지 스스로 판단하면 됨
    • 질문 자체는 타당하지만, 당사자 자기신고만으로 답하게 둘 수는 없다고 봄
      설계도 테스트도 거의 안 했고 코드 품질도 별로라고 솔직히 인정할 사람이 많을 것 같지 않음
      오히려 이런 질문에 답하려는 제3자 시스템이 필요할지도 모르겠는데, 물론 그것도 LLM 기반이면 꽤 주관적일 수 있음
    • LLM으로 소프트웨어를 만드는 방식은 정말 다양함
      나는 요즘 대부분의 프로젝트를 여러 Markdown 파일 중심으로 굴리는데, AI로 먼저 조사하고 계획 세우고 구현 진행을 추적함
      구현은 계획에 따라 단계적으로 하고 매 단계 검토도 계속함
      내 워크플로를 문서화하라고 하면 그 파일들이 바로 그것임
      코드의 99%는 생성되지만, 내가 만족하는 방식으로 생성되도록 신경 쓰고 있고 결과도 종종 혼자 만들었을 때보다 더 낫다고 느낌
    • 그게 왜 중요한지 잘 모르겠음
      좋은 소프트웨어도 나쁜 소프트웨어도 LLM 없이도, LLM과 함께도 만들 수 있음
      목수에게 망치를 썼는지 nail gun을 썼는지, 지붕과 데크에는 각각 뭘 썼는지 묻지는 않음
      신뢰 기반이 없다면 결국 직접 품질을 검증하거나 아예 스스로 만들어야 하고, 그 외에는 희망 섞인 기대에 가깝다고 봄

  • 아직 쓸만한 memory를 못 찾았음
    하나는 agents.md처럼 높은 수준 요약만 남겨서 구체적인 디테일, 예를 들면 이 요소를 수정하면 저 요소를 draft로 표시해야 한다 같은 정보에는 별 도움이 안 됨
    반대로 너무 상세한 방식은 세부가 지나쳐서 무시되거나, 한 기능 영역의 디테일이 다른 영역 변경에까지 오염을 일으킴
    결국 지금까지 제일 잘 먹힌 건 메모리 없이, 해당 세션/프롬프트에 중요한 컨텍스트만 수동으로 고르는 방식이었음

    • 메모리에 관심이 큰 편이지만, 적어도 코딩용 도구로는 그다지 유용하다고 보지 않음
      저장소가 무엇을 하는지, 무엇을 해야 하는지의 source of truth는 결국 repo itself임
      지금 말한 건 차라리 코드 리뷰 가이드라인에 가깝고, 그런 건 변경 시점에 맞춰 명시적으로 컨텍스트에 넣으면 됨
      메모리 시스템은 여기에 비해 너무 복잡하고 정확성도 떨어짐
    • 이런 시스템에 대한 위시리스트는 여기 있음: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
    • 나도 비슷하게 느낌
      언젠가 이런 모델들이 continual learning을 갖게 될지 궁금함
      이미 충분히 똑똑한데 진짜 메모리가 없어서 다루기 번거롭게 느껴짐
    • Claude가 만들어 준 메모리는 거의 전부 remember-to-not-forget류라서, 결국 기능을 꺼버렸음

  • 내게는 몇 가지 단순한 것들이 꽤 잘 먹힘, 도구는 Codex 기준임

    1. 항상 최신인 상세 functional specification
    2. 여러 프로젝트로 구조화된 코드베이스
    3. 좋은 네이밍과 문서화가 된 코드. 클래스, 변수, 함수 이름은 아무리 길고 우스워 보여도 목적이 명확해야 하고, 이런 규칙은 Agent.md의 코딩 가이드라인에 넣어 둠
      내 functional spec은 에이전트에게 Project.md 역할을 함
      그리고 매번 agentic code review 전에 프로젝트 디렉터리 트리를 만들고, 코드베이스와 합쳐서 단일 파일로 만든 뒤 파일명에 timestamp를 붙임
      이게 의외로 중요해서 LLM이 오래된 버전을 참조하는 걸 줄여주고, git을 굳이 보내지 않아도 빠르게 diff 보기에도 좋음
      지금까지는 큰 규모의 복잡한 코드베이스에서도 이 단순한 워크플로가 꽤 잘 작동했음
      토큰 효율은 별로지만 그냥 잘 됨
      매번 전체 코드베이스를 다 합칠 필요는 없고, 이미 끝났거나 테스트됐거나 지금 작업과 무관한 프로젝트는 뺄 수 있음
      그래도 printed directory tree에는 넣어서, 에이전트가 적어도 그 존재를 알고 필요하면 특정 파일을 요청할 수 있게 함
    • 흥미로운 접근임
      그 병합 작업은 어떻게 하는지 궁금함
      수동인지, 변경 파일만 합치는지, 아니면 혼합형인지 알고 싶음

  • LLM memory는 이론상 좋지만, 실제로는 커질수록 메모리 없이 굴릴 때만큼이나 지저분해짐
    첫 화면 예시처럼 내 프로젝트 계속 작업해줘라고 해도, 현실에서는 프로젝트 하나만 하는 경우가 드묾
    5개, 10개쯤 메모리에 들어갈 수 있고, 각각 저장 당시에는 다 의미 있었을 것임
    결국 sass 프로젝트 계속해줘처럼 다시 특정해야 하고, 세부 컨텍스트는 조금 얻는 대신 LLM context를 채우고 추가 MCP calls 비용도 내게 됨

    • 맞는 말이지만, 이건 너무 naive implementation임
      제대로 만든 구현이라면 이런 한계를 넘어설 수도 있음
    • 결국 뭘 기억해야 하는지 구체적으로 지정하기 시작하면, 사실상 AI에게 파일로 write/read하게 시키는 것과 거의 다를 바 없어짐

  • 이건 혼자 일하는 vibecoder만을 위한 건가 싶음
    실제 사람들과 실제 프로젝트를 하면, 이 시스템은 프로젝트 전체 메모리를 가질 수도 없고 나 역시 전체 메모리를 갖고 있지 않음
    다른 PR이 머지되면 내가 가진 기억은 바로 낡아지고, 내가 신경 쓰는 건 내 티켓뿐임
    그래서 점점 이런 건 그런 종류의 협업 작업을 위한 도구가 아닐 수도 있겠다고 느껴짐

  • 이제 소프트웨어를 만드는 비용이 사실상 거의 0에 가까워졌는데도, 아직 이런 걸 vibe-coded 마케팅 사이트로 팔려는 게 놀라움
    누가 이런 걸 써보고 몇 주, 몇 달 기다리면서 실제로 되는지 확인할 시간이 있겠나 싶음
    사이트 어디에도 RAG보다 낫다거나, 그냥 메모리 파일 폴더와 grep보다 낫다는 증거가 없음
    그런데도 환상적인 주장만 늘어놓고 있고, 스크롤도 14fps로 버벅임
    이건 24시간 전에 코딩한 수준으로 보이는데, 솔직히 너무 게으르게 느껴짐

답변달기