오픈소스 agent memory Stash, HN이 바로 찌른 약점

아이디어는 먹혔고, 의심은 더 빨랐다

Hacker News에서 Stash가 주목받은 이유는 간단하다. Claude나 ChatGPT 안에 묶여 있던 장기 memory를 오픈소스 레이어로 떼어내 모든 agent에 붙이겠다는 약속이기 때문이다. 다만 스레드 분위기는 환호보다 검증에 가까웠다. “기억을 오래 남기는 것”보다 “그 기억이 context를 오염시키지 않느냐”가 먼저 쟁점이 됐다.

프로젝트 소개 페이지에 따르면 Stash는 28개 MCP 도구, 6단계 파이프라인, PostgreSQL + pgvector를 기반으로 동작한다. 구조도는 episodes를 facts로, facts를 relationships와 patterns로 끌어올리고, goals·failures·hypotheses까지 저장하는 식이다. 또한 namespace 구조를 써서 사용자 정보, 프로젝트 정보, agent 자기 지식을 분리한다고 설명한다. 핵심 메시지는 model-agnostic persistence다. 모델을 바꿔도 memory는 남고, 필요한 부분만 다시 불러온다는 구상이다.

HN이 바로 던진 반론

문제는 실전이다. 초반 댓글부터 “memory는 이론상 좋아도 커질수록 그냥 또 다른 혼잡이 된다”는 반응이 나왔다. 어떤 사용자는 프로젝트마다 AGENTS.md와 PROJECT.md를 손으로 관리하는 편이 더 낫다고 했고, 다른 사용자는 이 구조가 결국 pgvector + recall/remember를 감성적으로 다시 포장한 것 아니냐고 밀어붙였다. 특히 팀 프로젝트에서는 memory가 금방 낡고, 내가 맡은 티켓과 무관한 정보가 과하게 섞일 수 있다는 지적이 많았다. 질문은 저장 기술보다 선택 기술에 가까웠다. 무엇을 승격해 남기고, 무엇을 버리며, 무엇을 현재 세션에서 제외할지에 대한 답이 더 중요하다는 뜻이다.

왜 이 논쟁이 중요하나

지금 agent 도구 시장의 병목은 “기억을 저장할 수 있느냐”가 아니다. 이미 많은 도구가 저장은 한다. 병목은 recall precision과 namespace hygiene다. 어떤 기억을 지금 불러와야 하고, 어떤 기억은 오히려 빼야 하는지를 정교하게 다뤄야 한다. HN이 Stash에 매달린 이유도 여기에 있다. 오픈소스 memory 레이어에 대한 수요는 분명하다. 하지만 그 수요가 바로 제품 적합성으로 이어지지는 않는다. Stash가 증명해야 할 것은 memory의 존재가 아니라, memory가 context를 더럽히지 않으면서 실제 작업을 더 빨리 이어붙일 수 있다는 점이다.

출처: Stash 소개 페이지 · Hacker News 토론