OpenMemory (오픈메모리)

리뷰

OpenMemory는 LLM 에이전트와 코딩 어시스턴트가 세션을 넘기는 영구 컨텍스트를 자체 디스크에 쌓아 두는 오픈소스 메모리 저장소예요. MCP 서버 인터페이스를 같이 제공해서 Claude Desktop·Codex·Copilot 같은 클라이언트가 같은 메모리에 붙어 쓰는 구조예요.

코딩 에이전트를 본격적으로 쓰면 매 세션마다 같은 컨텍스트를 다시 알려 줘야 하는 게 누적 비용이 돼요. 어제 Claude에 설명한 모듈 구조를 오늘 Codex에 또 설명하는 식이죠. OpenMemory처럼 MCP를 표준 인터페이스로 두면 여러 에이전트가 한 메모리에 붙어서, 한 번 정리한 컨텍스트를 여러 도구가 공유할 수 있어요. 데이터가 본인 디스크에 남으니까 API 제공자에게 코드·대화 데이터가 학습용으로 흘러가는 상황을 피할 카드도 돼요.

사용 예시

LLM은 한 세션이 끝나면 컨텍스트가 사라져요. OpenMemory는 그 컨텍스트를 본인 디스크의 SQLite나 Postgres에 저장하고, 다음 세션이 시작될 때 다시 끌어와요. 단순 벡터 검색(RAG)과 다른 부분은 메모리를 다섯 종류로 나눈 점이에요.

• episodic memory: 언제 무슨 일을 했는지 시점 기반 기록
• semantic memory: 사실·개념 — 이 프로젝트 인증 모듈은 Supabase 기반이라는 식
• procedural memory: 절차·workflow — 배포 단계, 디버깅 순서
• emotional memory: 사용자 선호와 톤
• reflective memory: 회고·메타 정보

저장된 메모리는 시간 기반 지식 그래프로 묶여서, “지난주 인증 문제 해결할 때 무슨 가설을 검토했지?” 같은 질문에 시간 축과 주제 축 양쪽으로 접근해요. 설치는 Python(pip install openmemory-py) 또는 Node(npm install openmemory-js)로 SDK를 깔거나, MCP 서버를 띄워 MCP 호환 클라이언트에 그대로 연결해요.

확인할 점

분류 자체가 마케팅 표현일 수 있어요. 5종 메모리가 실제 구현에서 얼마나 분리돼 검색되는지는 본인 워크로드로 직접 측정해야 해요. RAG 벡터 DB와 비교할 때 검색 품질·지연 속도는 본인 코퍼스로 재보는 게 맞아요.

MCP 서버는 OpenMemory가 노출하는 한 표면이라, 라이브러리 전체를 “MCP 전용 도구”로 오해하지 않는 게 좋아요. 민감 데이터를 평문으로 SQLite에 쌓으면 백업 디스크 한 장이 통째로 빠져나갈 위험이 있으니 암호화 옵션을 먼저 확인하고, 다중 클라이언트 동시 접근 시 잠금 동작도 운영 환경에서 미리 점검하는 게 안전해요.