AI 뉴스

Memora: 장기 작업을 위한 확장형 메모리 시스템 — AI 에이전트 메모리의 새로운 설계

노동1호 2026. 7. 1. 04:02

AI 에이전트가 사용자와 오래 상호작용하려면 단순히 대화를 이어가는 것만으로는 부족합니다. 누가 어디서 일하고, 어떤 도구를 선호하는지, 지난 회의에서 어떤 결정을 내렸는지 같은 사실들이 누적되어야 비로소 진짜 "도움이 되는" 에이전트가 됩니다. Memora는 이런 장기 메모리(life-long memory) 문제를 하나의 프레임워크로 풀어내려는 Python 오픈소스 프로젝트입니다. 이번 글에서는 Memora가 어떤 구조로 메모리를 다루고, 일반적인 RAG나 그래프 데이터베이스와 어떻게 다른지, 그리고 실제 도입 시 무엇을 검증해야 하는지 정리합니다.

memory brain network

Memora가 풀고자 하는 문제

기존 AI 에이전트 개발에서 개발자가 직접 처리해야 했던 일은 대부분 "기억의 생명주기"와 관련이 있습니다.

  • 어떤 정보를 메모리로 저장할 것인지
  • 저장된 정보를 언제 갱신하거나 삭제할 것인지
  • 사용자 질문과 관련된 기억을 어떻게 검색할 것인지
  • 중복되거나 충돌하는 기억을 어떻게 관리할 것인지

Memora는 이 모든 과정을 프레임워크 내부에서 처리하는 것을 목표로 합니다. 개발자는 저수준의 저장·검색 로직보다 에이전트의 업무 기능과 응답 생성에 더 집중할 수 있게 됩니다.

기존 메모리 구조의 한계

일반적인 RAG(Retrieval-Augmented Generation) 시스템은 문서나 대화 원문을 일정 크기로 분할하고, 각 조각을 임베딩하여 벡터 데이터베이스에 저장합니다. 질문이 들어오면 의미적으로 가까운 조각을 검색해 LLM 프롬프트에 끼워 넣는 방식입니다. 구현이 단순하다는 장점이 있지만, 다음과 같은 문제가 발생하기 쉽습니다.

  • 긴 문맥이 여러 조각으로 분리되면서 의미가 끊김
  • 유사한 표현의 정보가 중복 저장됨
  • 의미적 유사도가 실제 질문 의도와 일치하지 않음
  • 압축된 요약만 저장하면 세부 정보가 손실됨

그래프형 지식베이스는 관계 표현에 유리하지만, 스키마와 관계 구조를 지속적으로 관리해야 하는 부담이 따릅니다. Memora는 이 둘 사이의 중간 지점을 노립니다.

Memora의 핵심 설계: 원문과 검색 구조의 분리

Memora의 각 메모리는 세 가지 요소로 구성됩니다.

  • Memory value*는 실제 저장되는 전체 정보입니다. 원문과 세부 내용을 압축하지 않고 그대로 보존하며, 검색 인덱스에는 직접 포함되지 않습니다. 정보 손실 없이 원래 문맥을 유지하는 역할을 맡습니다.
  • Primary abstraction*은 해당 메모리가 무엇에 관한 것인지를 나타내는 대표 요약입니다. 메모리마다 하나씩 생성되며, 검색·갱신·병합·중복 제거의 기준이 됩니다. 쉽게 말해 메모리의 "이름표"입니다.
  • Cue anchors*는 하나의 메모리에 접근할 수 있는 여러 의미적 단서입니다. 인물, 대상, 사건, 핵심 속성 등을 조합하여 구성되며, 하나의 기억에 여러 단서를 연결할 수 있습니다. 여러 기억이 동일한 단서를 공유하는 다대다 구조가 자연스럽게 형성됩니다.

중요한 점은 Memora가 모든 원문을 직접 임베딩하지 않는다는 것입니다. 실제 검색에는 Primary abstraction과 Cue anchors만 사용되고, 검색이 완료되면 그 결과에 연결된 원본 Memory value가 반환됩니다. 이 구조의 목적은 검색 표현과 실제 저장 정보를 분리해 검색 인덱스를 간결하게 유지하면서도 원문의 세부 정보를 그대로 보존하는 데 있습니다. 원문 전체를 임베딩할 때 발생하는 의미적 잡음을 줄이려는 의도입니다.

메모리 처리 흐름

Memora의 메모리 처리는 네 단계로 이루어집니다.

1단계: 메모리 수집

에이전트가 대화 또는 문서를 처리하면서 사실 정보, 사건 및 경험, 절차와 작업 방법을 자동으로 추출합니다. 긴 대화는 주제별 에피소드로 분할되고, 핵심 정보는 구조화된 메모리 항목으로 변환됩니다.

2단계: 지능형 저장

ChromaDB를 기본 저장소로 사용하여 의미 임베딩 기반 저장과 검색을 수행합니다. 새 정보가 입력되면 기존 메모리와 비교하여 유사하거나 중복되는 정보에 대해 중복 제거, 기존 기억과의 병합, 오래된 정보의 갱신 작업을 자동으로 수행합니다. 선택적으로 Cue index를 생성하여 구조화된 검색을 지원합니다.

3단계: 적응형 검색

질문 유형과 설정에 따라 네 가지 검색 전략을 제공합니다.

  • Semantic 검색: 질문과 메모리 표현 사이의 벡터 유사도를 계산합니다. 구현이 단순하고 일반적인 질문에 잘 적용됩니다.
  • Prompted 검색: LLM이 검색 과정을 단계적으로 수행합니다. 복합 질문이나 여러 기억을 결합해야 하는 경우에 적합하지만, LLM 호출이 추가되므로 비용과 응답 시간이 증가할 수 있습니다.
  • Hybrid 검색: 벡터 기반 의미 검색과 BM25·키워드 검색을 결합합니다. 고유명사, 제품명, 코드, 날짜 등의 검색 누락을 줄이는 데 유리합니다.
  • GRPO 검색: 강화학습으로 훈련된 검색 정책을 사용합니다. LLM 기반 반복 검색을 로컬 미세조정 모델로 대체하는 것을 목표로 하는 실험적 기능입니다.

4단계: 답변 생성

memory brain network

검색된 메모리를 정해진 형식으로 구성하여 LLM 프롬프트에 삽입하고, LLM은 질문과 검색된 기억을 함께 사용하여 응답을 생성합니다. 답변이 저장된 메모리에 근거하도록 유도합니다.

메모리 관리 기능

Memora는 메모리를 계속 추가하기만 하는 평면형 저장소와 다릅니다. 중복 기억 제거, 유사 기억 병합, 변경된 사실 갱신, 메모리 구조 재정리 기능을 제공합니다. Primary abstraction이 메모리 갱신과 통합의 기준으로 사용되기 때문에, 시간이 지나면서 메모리가 무제한으로 중복 축적되는 문제를 줄일 수 있습니다.

메모리 값과 추상화 방식을 다르게 구성하면 사실적 기억(인물, 장소, 속성, 설정), 일화적 기억(특정 시점의 사건이나 대화), 절차적 기억(작업 방법이나 반복 가능한 절차)을 모두 표현할 수 있습니다. 서버 배포 절차, 오류 점검 순서, 문서 생성 규칙 같은 것이 절차적 기억에 해당합니다.

다중 에이전트와 저장 인프라

같은 환경에서 동작하는 여러 에이전트가 공통 메모리 공간을 사용할 수 있습니다. 한 에이전트가 저장한 정보를 다른 에이전트가 재사용할 수 있고, 에이전트 또는 역할별로 메모리 범위를 제한할 수도 있습니다. 이를 통해 에이전트 간 지식 중복을 줄이고 작업 인수인계를 개선하며, 공통 프로젝트 정보의 일관성을 유지할 수 있습니다.

저장 인프라 측면에서는 ChromaDB와 Redis 연결 기능을 제공하여 로컬 또는 원격 저장 환경에 모두 적용할 수 있고, 저장 백엔드를 변경하더라도 메모리의 추상화·단서 구조는 그대로 유지됩니다.

기본 사용 흐름

Python 3.10 이상 환경에서 GitHub 저장소를 복제하고 패키지를 설치한 뒤 다음과 같은 흐름으로 사용합니다.

  1. MemoraClient를 생성하고 사용자 또는 에이전트 식별자를 지정
  2. add()를 사용하여 대화나 문서를 메모리에 추가
  3. query()를 사용하여 의미 기반 검색 수행
  4. advance_query()를 사용하여 Prompted 또는 GRPO 방식의 고급 검색 수행

에이전트 연동 구조는 사용자 메시지를 받으면 관련 메모리를 먼저 검색하고, 검색 결과와 사용자 질문을 이용해 답변을 생성한 뒤, 생성된 답변과 사용자 메시지를 다시 메모리에 저장하는 단순한 사이클로 구성됩니다.

성능 평가 방식

Memora는 LoCoMo와 LongMemEval 같은 장기 메모리 벤치마크를 지원합니다. LoCoMo는 장기간 이어지는 대화에서 단일 단계 질문, 다단계 질문, 시간 관계 질문, 개방형 질문을 평가합니다. LongMemEval은 에피소드 메모리와 의미 검색 설정을 적용하여 실제 장기 대화 환경에서 정보 유지와 검색 성능을 검증합니다. GRPO 기반 검색 정책 학습은 Qwen 3B/7B 계열 모델과 LoRA 미세조정을 예시로 제시하며, GPU 환경이 필요합니다.

도입 전 검증 체크리스트

Memora는 분명 흥미로운 설계이지만, 실제 운영 환경에 적용하기 전에는 다음 항목을 우선 검증해야 합니다.

  • 한국어 문서의 추상화와 Cue 생성 품질
  • 기존 RAG와 비교한 검색 정확도와 재현율
  • 메모리 병합 과정의 오류율 (서로 다른 사건이 잘못 통합되는 경우)
  • 장기간 운영 시 데이터 증가량과 검색 속도 변화
  • LLM 및 임베딩 API 비용
  • 개인정보 저장과 접근 제어 방식

또한 Primary abstraction과 Cue anchors의 품질이 검색 성능에 직접 영향을 주기 때문에, 자동 생성된 추상화가 부정확하면 원문이 정확하더라도 검색에서 누락될 수 있다는 점에 주의가 필요합니다. 공개 저장소에는 아직 릴리스가 없고 참여자와 이용 지표가 적어, 대규모 운영 안정성이 충분히 검증되었다고 보기 어려운 점도 감안해야 합니다.

정리

Memora는 원문 전체를 단순히 벡터화하는 방식에서 벗어나, 세부 정보는 Memory value에 보존하고 대표 의미는 Primary abstraction으로, 다양한 검색 경로는 Cue anchors로 구성하는 분리된 구조를 제안합니다. 핵심 가치는 정보 보존과 검색 효율 사이의 균형에 있습니다. 단순한 문서 검색보다 장기간 사용자와 상호작용하는 개인화 에이전트, 다수의 개발·업무 문서를 지속적으로 축적하는 시스템, 여러 역할의 에이전트가 지식을 공유하는 환경, 과거 결정과 작업 절차를 재사용해야 하는 프로젝트에서 활용 가능성이 높습니다. 초기 단계에서는 핵심 문서 일부를 대상으로 소규모 PoC를 수행하고, 일반 RAG 및 하이브리드 검색 방식과 성능을 비교해 보는 접근이 적절합니다.