Stash 메모리 레이어, 오픈소스 에이전트 기억 경쟁이 본격화됐다

AI 에이전트를 한두 주만 운영해 본 팀이라면 같은 문제를 겪습니다. 세션이 바뀌면 맥락이 끊기고, 이전 결정이 사라지고, 실패한 접근을 다시 반복합니다. Stash는 바로 그 문제를 겨냥한 오픈소스 메모리 레이어입니다. 공식 소개 페이지는 이 프로젝트를 "persistent cognitive layer"라고 부르며, PostgreSQL + pgvector, MCP 네이티브, 28개 도구, 6단계 이상 파이프라인 구조를 강조합니다.

흥미로운 점은 Stash가 자신을 단순 RAG 도구로 설명하지 않는다는 것입니다. 프로젝트는 대화와 경험을 episodes, facts, relationships, patterns 같은 계층으로 정리하고, 목표 추적, 실패 패턴, 가설 관리까지 메모리로 끌어오겠다고 말합니다. 이 주장은 과감하지만, 적어도 방향성은 분명합니다. 메모리를 모델 내부의 폐쇄형 기능이 아니라 외부화 가능한 인프라 계층으로 보겠다는 것입니다.

왜 지금 메모리 레이어가 중요해졌나

최근 에이전트 경쟁은 도구 호출과 실행력 중심으로 이동했습니다. 하지만 실제 현장에서는 기억이 약하면 자동화 수준이 쉽게 멈춥니다. 사용자의 선호, 프로젝트 이력, 이전 실패, 결정 이유를 계속 다시 설명해야 하기 때문입니다. Stash는 이 병목을 겨냥해, 세션을 넘어서 기억을 유지하고, 모델이 바뀌어도 메모리가 남는 구조를 제안합니다.

이 흐름은 Karpathy 스타일 LLM 위키와 지속형 지식베이스, OpenAI 워크스페이스 에이전트 엔터프라이즈 전략, Anthropic 매니지드 에이전트 Brain/Hands 구조와도 연결됩니다. 업계 전체가 "한 번 똑똑하게 답하는 모델"에서 "지속적으로 이어지는 시스템"으로 이동하고 있기 때문입니다.

RAG와 무엇이 다른가

Stash 소개 페이지가 가장 강조하는 대목은 "RAG는 검색이고, Stash는 기억"이라는 구분입니다. 물론 실제로는 과장이 섞여 있을 수 있습니다. 하지만 이 구분은 제품 설계 관점에서 꽤 유용합니다. RAG는 문서를 찾아오는 데 강하고, 메모리 레이어는 경험과 상태를 보존하는 데 강합니다.

예를 들어 RAG는 사내 문서 1만 건 중 관련 페이지를 찾아오는 데 탁월할 수 있습니다. 반면 메모리 레이어는 "이 사용자는 지난주 결제 흐름을 싫어했고, Stripe 복잡성을 피하고 싶어 했다" 같은 장기 맥락을 관리하는 데 더 적합합니다. 둘은 경쟁 관계라기보다 상호 보완적입니다. 한국 개발팀도 이 둘을 섞어 쓰는 하이브리드 구조를 더 많이 택하게 될 가능성이 큽니다.

비교표, RAG 도구와 메모리 레이어의 차이

이 차이는 한국 시장에서도 중요합니다. 고객지원, 영업 보조, 개발자 코파일럿, 사내 비서형 시스템은 모두 기억의 품질에 따라 체감 성능이 크게 달라지기 때문입니다.

개발자 관점에서 봐야 할 실제 포인트

첫째, Stash는 MCP 통합을 전면에 내세웁니다. 이는 Claude Desktop, Cursor, 커스텀 에이전트 같은 MCP 호환 클라이언트와 연결을 쉽게 만들려는 의도입니다. 둘째, 백엔드로 PostgreSQL과 pgvector를 사용해 비교적 익숙한 스택을 택했습니다. 셋째, 단순 저장뿐 아니라 goal inference, failure patterns, contradiction scan 같은 후처리 파이프라인을 제안합니다.

다만 현실적으로는 몇 가지 질문이 남습니다. 얼마나 빠르게 동작하는가, 장기 누적 시 품질이 유지되는가, 잘못된 기억을 어떻게 교정하는가, 개인정보와 프로젝트 메모리를 어떻게 분리하는가 같은 문제입니다. 프로젝트가 제안하는 namespace 구조는 이런 분리에 도움을 줄 수 있지만, 실제 운영에서는 여전히 세밀한 정책이 필요합니다.

한국 시장, 어디에 기회가 있나

한국에서는 범용 메모리 레이어 자체보다 이를 활용한 버티컬 제품화가 더 큰 기회일 수 있습니다. 예를 들어 고객센터 AI, 학습 코치, 병원 예약 보조, B2B 영업 비서, 개발자 도구 등은 장기 맥락 기억이 핵심 가치가 됩니다. 사용자가 매번 배경을 설명하지 않아도 되는 경험은 생각보다 큰 차이를 만듭니다.

또한 메모리를 외부 계층으로 빼면 공급사 종속을 줄일 수 있습니다. ChatGPT나 Claude의 내부 메모리 기능은 편하지만 플랫폼 종속적입니다. 반면 오픈소스 메모리 레이어를 직접 운영하면 데이터 위치, 보관 기간, 정책 제어가 쉬워집니다. 이는 오픈AI 에이전트 SDK 프로덕션 분석, Google Gemini 엔터프라이즈 에이전트 플랫폼, OpenAI Workspace Agents 기사와 함께 볼 때 더 분명해집니다.

참고할 외부 자료

• Stash 공식 소개 페이지
• Stash GitHub 저장소
• HN의 Stash 관련 토론
• Model Context Protocol 공식 사이트
• PostgreSQL 공식 사이트
• pgvector GitHub 저장소
• OpenRouter 공식 사이트

함께 읽을 기사

• Karpathy 스타일 LLM 위키와 지속형 지식베이스
• OpenAI 워크스페이스 에이전트 엔터프라이즈 전략
• Google Gemini 엔터프라이즈 에이전트 플랫폼
• Anthropic 매니지드 에이전트 Brain/Hands 구조
• OpenAI 에이전트 SDK와 프로덕션 하니스 분석
• Karpathy 스타일 위키형 지속 메모리 구조

자주 묻는 질문

Q1: Stash는 무엇인가?

A: 세션 간 지속 기억을 제공하려는 오픈소스 메모리 레이어입니다. PostgreSQL과 pgvector, MCP 통합을 바탕으로 에이전트가 이전 맥락을 다시 불러오도록 설계됐습니다.

Q2: 주요 장점은 무엇인가?

A: 모델을 바꿔도 기억을 유지할 수 있고, 대화뿐 아니라 목표와 실패 패턴까지 외부 계층에 저장하려는 점입니다. 장기 프로젝트형 에이전트에 특히 유리할 수 있습니다.

Q3: 도입 시 고려사항은 무엇인가?

A: 잘못된 기억 보정, 개인정보 분리, 성능 저하, 메모리 품질 관리가 핵심입니다. 초기에는 작은 범위에서 namespace 정책과 삭제 정책을 먼저 정하는 편이 안전합니다.

Q4: 비용 구조는 어떤가?

A: 오픈소스라 라이선스 비용은 낮을 수 있지만, DB 운영과 임베딩, 후처리 파이프라인 비용이 발생합니다. 사용량이 커질수록 저장·벡터 검색 비용 최적화가 중요해집니다.

Q5: 한국에서도 활용 가능성이 높은가?

A: 높습니다. 고객지원, 영업, 개발자 도구, 교육형 서비스처럼 장기 맥락이 중요한 제품에서 특히 효과가 큽니다. 단, 단순 챗봇보다 운영 설계 역량이 더 필요합니다.