2026 Agent Memory 오픈 소스 추천

Semantica의 기본 기억 모듈은 벡터 저장소와 대화 기록을 함께 다루고, 기본 최대 기억 수를 10000개로 설정합니다. 반면 Letta는 에이전트 상태 자체를 관리하고, Zep의 Graphiti는 시간에 따라 바뀌는 관계를 그래프로 다룹니다. 따라서 2026 Agent Memory 오픈 소스 추천의 결론은 하나의 승자를 고르는 것이 아니라 기억 문제에 맞춰 후보를 좁히는 것입니다. 가벼운 공통 기억층은 Mem0부터, 상태화 에이전트는 Letta, 시간 관계 그래프는 Zep, 결정 근거와 추적성이 중요하면 Semantica를 먼저 평가하는 편이 합리적입니다. (Semantica 공식 문서)

이 글은 대화형 또는 작업형 에이전트에 장기 기억을 추가하려는 개발자, 자체 운영과 데이터 통제가 필요한 기업 팀, 벡터 기억과 그래프 기반 에이전트 런타임 사이에서 설계를 비교하는 아키텍트에게 적합합니다.

마지막 업데이트: 2026년 8월 14일. 각 프로젝트의 공식 저장소와 문서를 기준으로 라이선스, 자체 운영 방식, 저장소 의존성, 기능 경계를 다시 확인했습니다.

첫 단계: 에이전트가 기억해야 할 대상을 다섯 가지로 나누기

비교 전에 먼저 저장할 대상을 정해야 합니다. 다음 항목을 한데 섞으면 검색이 잘되는지와 에이전트가 안정적으로 행동하는지를 구분하기 어렵습니다.

• 사용자 선호: 말투, 자주 쓰는 도구, 개인 설정입니다.
• 작업 상태: 진행 중인 업무, 완료 조건, 다음 단계입니다.
• 사건 시간선: 언제 어떤 일이 있었는지에 대한 기록입니다.
• 지식 관계: 사람, 문서, 서비스, 사건 사이의 연결입니다.
• 결정 근거: 왜 특정 도구나 정책을 선택했는지에 대한 설명입니다.

예를 들어 고객 지원 에이전트가 사용자의 언어 선호만 기억하면 Mem0 같은 기억층으로 충분할 수 있습니다. 그러나 “지난주 정책 변경 때문에 이번 답변이 달라졌다”를 설명해야 한다면 시간 정보와 출처가 필요합니다. “이 고객에게 어떤 예외를 승인했는가”까지 추적해야 한다면 결정 객체와 인과 관계가 있는 Semantica 쪽이 더 자연스럽습니다.

두 번째 단계: 네 프로젝트를 같은 층으로 비교하지 않기

네 프로젝트는 모두 Agent Memory라는 검색어로 묶이지만 실제 추상화 계층이 다릅니다.

Mem0의 공식 문서는 라이브러리 방식과 자체 운영 서버 방식을 구분합니다. 라이브러리 기본 구성에는 로컬 Qdrant와 SQLite 기록 저장소가 포함되며, 자체 운영 서버 구성은 PostgreSQL과 pgvector를 기본 벡터 저장소로 사용합니다. 따라서 “Mem0가 자체 운영 가능한가”라는 질문에는 가능하다고 답할 수 있지만, 설치 방식에 따라 필요한 구성은 달라집니다. (Mem0 공식 문서)

Letta는 단순 검색 API보다 에이전트의 상태와 기억 블록을 중심으로 설계되었습니다. 공식 문서의 Docker 방식에서는 서버가 데이터를 보존할 경로를 필요로 하고, 자체 PostgreSQL을 연결할 때 pgvector 확장을 요구합니다. 이 점 때문에 Zep과 Letta의 차이는 단순히 벡터 대 그래프가 아니라, 기억을 외부 계층으로 붙이는가 또는 에이전트 런타임의 상태로 관리하는가에 가깝습니다. (Letta 공식 문서)

Zep은 제품 영역이고 Graphiti는 그 안에서 공개된 컨텍스트 그래프 구성 요소입니다. Graphiti는 로컬 실행이 가능한 공개 프레임워크로 소개되지만, Zep의 모든 상용 기능을 Graphiti와 동일하게 볼 수는 없습니다. Graphiti는 Neo4j, FalkorDB, Amazon Neptune 같은 그래프 저장소와 여러 모델 공급자를 연결할 수 있습니다. (Graphiti 공식 페이지)

Semantica는 단순한 벡터 기억 모듈만 제공하는 프로젝트가 아닙니다. 공식 문서는 사실의 출처, 결정 객체, 인과 연결, 정책 검사, 다단계 그래프 검색을 하나의 컨텍스트 계층으로 설명합니다. 기본 AgentMemory는 벡터 기반으로 동작하지만, 전체 프로젝트는 여러 그래프 저장소와 벡터 저장소를 조합하는 구조입니다.

세 번째 단계: 기억을 쓰고 바꾸고 지우는 경로를 검사하기

운영 환경에서는 “검색 결과가 나오는가”보다 잘못 저장된 기억을 어떻게 고치는지가 더 중요합니다.

Mem0는 기억 추가와 검색을 중심으로 시작하기 쉽고, 모델과 임베딩, 벡터 저장소, 재순위 모델을 바꿀 수 있습니다. 대신 충돌하는 사용자 정보가 들어왔을 때 어떤 규칙으로 기존 사실을 갱신할지, 삭제 요청이 모든 보조 저장소에 반영되는지는 실제 구성과 버전을 기준으로 시험해야 합니다.

Letta는 에이전트가 자신의 기억 블록을 읽고 수정하는 흐름에 더 적합합니다. 장기 실행 에이전트가 대화 중 상태를 바꾸는 구조에는 강하지만, 여러 에이전트가 같은 사실을 공유할 때 누가 어떤 상태를 변경했는지 별도 감사 설계를 추가해야 할 수 있습니다.

Graphiti는 시간 논리를 사용해 새 사실이 들어올 때 이전 관계를 현재 상태에서 무효화하면서 이력을 보존하는 방향을 제시합니다. 이 모델은 “현재 담당자는 누구인가”와 “과거 담당자는 누구였는가”를 함께 물어야 하는 업무에 유리합니다. 다만 그래프 엔터티 병합과 관계 추출 오류를 검증하지 않으면 잘못된 연결이 장기간 남을 수 있습니다.

Semantica는 기억 삭제뿐 아니라 출처, 결정 기록, 정책 예외와 같은 감사 대상까지 관리하려는 설계입니다. 규제 업무나 내부 승인 흐름에는 장점이 있지만, 단순한 사용자 선호 저장만 필요한 팀에는 구성 요소가 많게 느껴질 수 있습니다.

네 번째 단계: Semantica와 Mem0의 자체 운영 범위를 따로 확인하기

Semantica와 Mem0 중 자체 운영에 더 적합한 대상을 고를 때는 “둘 다 공개 저장소인가”만 보면 안 됩니다.

Mem0는 애플리케이션에 라이브러리로 넣거나 자체 운영 서버로 실행하는 두 경로를 공식 문서에서 구분합니다. 자체 운영 서버에는 대시보드, 사용자별 API 키, 요청 감사 기록이 포함된다고 설명되어 있어 팀 단위 테스트에 진입하기 쉽습니다. 다만 모델, 임베딩, 데이터베이스를 운영자가 선택하고 유지해야 합니다.

Semantica는 MIT 라이선스와 자체 운영 가능성을 공식 저장소에 명시하고, Neo4j, FalkorDB, Apache AGE, Amazon Neptune 같은 그래프 저장소와 Qdrant, Pinecone 같은 벡터 저장소 연결을 안내합니다. 즉, 데이터 통제와 확장성은 넓지만 기본 설치 하나로 모든 운영 의존성이 끝나는 구조는 아닙니다. (Semantica 공식 저장소)

따라서 사용자 선호와 사실 검색이 중심이면 Mem0가 먼저입니다. 조직 지식, 결정 근거, 정책 검사까지 한 데이터 모델로 묶어야 하면 Semantica를 검토해야 합니다. 둘을 직접 비교할 때는 동일한 검색 정확도를 가정하지 말고, 서로 다른 추상화가 요구사항을 얼마나 덜 왜곡하는지 평가해야 합니다.

다섯 번째 단계: 벡터 기억과 지식 그래프를 업무 질문으로 나누기

다음처럼 질문을 바꾸면 선택이 빨라집니다.

• “사용자가 지난 대화에서 선호한 설정은 무엇인가?”
  → Mem0 같은 기억층이 적합합니다.
• “에이전트가 이전 단계에서 무엇을 완료했고 다음에 무엇을 해야 하는가?”
  → Letta가 더 자연스럽습니다.
• “계약 담당자가 시간에 따라 어떻게 바뀌었는가?”
  → Zep의 Graphiti 계열을 평가할 수 있습니다.
• “왜 이 결정을 내렸고 어떤 정책과 출처가 영향을 주었는가?”
  → Semantica가 더 직접적인 모델을 제공합니다.

장기 기억을 벡터로 할지 지식 그래프로 할지는 저장 용량의 문제가 아닙니다. 의미가 비슷한 문장을 찾는 것이 핵심이면 벡터 검색이 단순합니다. 관계의 방향, 시간 변화, 출처, 정책 위반 여부가 답변에 포함되어야 하면 그래프가 필요합니다. 두 방식은 함께 사용할 수 있지만, 검색 결과를 합치는 기준과 충돌 해결 규칙을 별도로 정의해야 합니다.

여섯 번째 단계: 다중 에이전트와 거버넌스를 검증하기

다중 에이전트 환경에서는 공유 기억과 개인 상태를 분리해야 합니다.

Letta는 에이전트 단위 상태를 중심으로 하므로 개인별 실행 흐름을 만들기 쉽습니다. 그러나 팀 에이전트가 공통 지식을 쓸 때는 공유 범위, 수정 권한, 삭제 권한을 애플리케이션에서 명시해야 합니다.

Mem0는 여러 사용자와 에이전트에 연결할 수 있는 기억 계층으로 쓰기 좋지만, 테넌트 분리와 접근 제어가 실제 배포 설정에서 제대로 적용되는지 확인해야 합니다. 자체 운영 문서에 인증과 API 키가 언급되어 있어도 조직의 권한 체계 전체가 자동으로 해결되는 것은 아닙니다. (Mem0 공식 저장소)

Semantica는 출처와 결정 추적을 중심으로 설명되므로 감사 가능성이 중요한 프로젝트에 유리합니다. 공식 저장소는 W3C PROV 계열 출처와 결정 인과 체인을 주요 기능으로 제시합니다. 다만 “기능이 문서에 있다”와 “운영 중 모든 요청을 완전하게 감사할 수 있다”는 서로 다른 주장입니다. 실제 권한 모델과 로그 보존 정책을 확인해야 합니다.

다음 항목을 두 후보에 동일하게 적용해 보십시오.

• [ ] 사용자별 기억과 조직 공용 기억의 저장 공간을 분리했습니다.
• [ ] 기억을 만든 에이전트와 수정한 주체를 기록했습니다.
• [ ] 오래된 사실을 현재 사실과 구분하는 필드를 만들었습니다.
• [ ] 사용자가 삭제를 요청했을 때 원문, 벡터, 그래프 관계를 함께 지울 수 있습니다.
• [ ] 검색 결과에 출처와 생성 시점을 표시할 수 있습니다.
• [ ] 잘못된 기억을 다시 쓰기 전에 승인 또는 검수 단계를 둘 수 있습니다.
• [ ] 에이전트별 도구 권한과 기억 접근 범위를 테스트했습니다.

일곱 번째 단계: 생산 환경에서 기억 효과를 공정하게 검수하기

속도나 비용 숫자를 프로젝트 이름만 보고 비교하면 안 됩니다. 모델, 임베딩, 데이터 크기, 검색 범위가 달라지기 때문입니다. 공식 문서에 없는 지연 시간이나 정확도를 일반적인 성능처럼 쓰는 것도 피해야 합니다.

두 후보를 정했다면 같은 데이터 세트를 만들고 다음 순서로 시험하십시오.

1. 사용자 선호, 작업 상태, 시간 사건, 관계 지식, 결정 근거를 각각 별도 묶음으로 준비합니다.
2. 새 사실 추가, 기존 사실 변경, 충돌 사실 입력, 삭제 요청을 모두 포함합니다.
3. 단순 의미 검색과 관계 추론 질문을 나눕니다.
4. 답변의 정답 여부뿐 아니라 최신성, 출처 표시, 잘못된 기억 회피 여부를 기록합니다.
5. 동일한 모델과 임베딩 설정으로 반복합니다.
6. 운영자가 삭제와 복구를 수행하는 데 필요한 단계와 권한을 기록합니다.

Mem0의 공식 문서는 자체 평가 절차와 검색 조정 항목을 제공하고, Letta는 자체 운영 시 임베딩 모델을 명시해야 한다고 안내합니다. 따라서 두 프로젝트를 시험할 때는 기본 설정을 그대로 비교하지 말고, 실제 배포 예정 모델과 저장소를 고정해야 합니다.

최종 선택: 네 가지 팀 유형별 우선 후보

빠른 원형 팀이라면 Mem0를 먼저 보십시오. 애플리케이션에 기억층을 추가하는 경로가 명확하고, 자체 운영 서버와 라이브러리 방식을 나눠 시험할 수 있습니다.

상태화 에이전트 팀이라면 Letta가 우선입니다. 장기 실행 에이전트, 기억 블록, 도구 호출, 에이전트 상태를 한 런타임에서 다루려는 경우에 맞습니다. Letta는 과거 MemGPT로 불리던 프로젝트이므로 오래된 자료를 볼 때 이름이 달라질 수 있습니다. (Letta 공식 저장소)

시간 관계와 사건 이력 중심 팀이라면 Zep의 상용 기능과 Graphiti 공개 구성 요소를 분리해 검토하십시오. Graphiti를 자체 운영할지, Zep 제품을 사용할지는 기능 범위와 데이터 통제 조건에 따라 달라집니다.

감사, 결정 근거, 정책 검증이 중요한 팀이라면 Semantica를 평가하십시오. 다만 그래프 저장소와 벡터 저장소 운영까지 감당할 수 있어야 하며, 초기부터 전체 데이터를 옮기기보다 작은 업무 흐름으로 검증하는 편이 안전합니다.

두 후보를 정한 뒤에는 생산 데이터를 바로 이전하지 마십시오. 동일한 데이터 세트로 한동안 이중 기록과 이중 검색을 실행하고, 삭제·충돌·시간 변경·권한 테스트를 통과한 쪽을 본 운영으로 선택하는 방식이 적합합니다. 배포 공간이 필요하다면 ZavCloud의 도움말 센터에서 원격 개발 환경을 확인하고, 한국에서 테스트할 때는 맥 미니 렌탈 환경을 후보로 비교할 수 있습니다.

현재 로컬 노트북이나 일반 클라우드 개발 서버에서 이 작업을 진행하면 저장소를 다시 만들 때마다 환경이 달라지고, 그래프 데이터베이스와 임베딩 모델을 함께 띄울 때 권한과 백업 구성이 복잡해지며, 장시간 이중 테스트를 유지하기 어렵다는 문제가 생깁니다. 반대로 ZavCloud의 Mac 환경을 사용하면 고정된 개발 공간에서 두 후보를 같은 조건으로 반복 검증하기 쉽습니다. 장기 고정 부하나 물리 장비 접근이 필요한 운영에는 직접 서버가 더 적합하지만, 임시 Agent Memory 검증과 이전 전 테스트라면 먼저 일관된 원격 개발 환경에서 시험하는 편이 낭비가 적습니다.