AI 챗봇이나 에이전트를 만들다 보면 누구나 같은 고민을 합니다. 사용자가 이전에 했던 말, 선호, 프로젝트 정보 같은 것들을 LLM이 기억하면 서비스 품질이 크게 올라가지만, 문제는 그 기억을 구현하는 과정이 너무 복잡하다는 점입니다. 벡터 DB를 붙이고, 메모리 파이프라인을 만들고, 엔티티 추출까지 직접 설계해야 하는 부담은 언제나 개발자를 잡아끕니다.
Memori는 이런 어려움을 단 한 줄로 해결하는 SQL 기반 메모리 엔진입니다. 복잡한 구조 없이 memori.enable()만 호출하면 LLM은 자동으로 대화를 기억하고, 사용자 정보를 추론하며, 세션이 바뀌어도 맥락을 유지합니다. 이 글에서는 Memori가 무엇인지, 기존 방식과 무엇이 다른지, 어떤 방식으로 동작하는지, 그리고 왜 주목해야 하는지를 자세히 정리했습니다.
Memori란 무엇인가?
Memori는 LLM이 대화를 스스로 기억하도록 만들어주는 오픈소스 SQL-native 메모리 엔진입니다. 한 줄의 코드로 활성화되며, SQLite, PostgreSQL, MySQL 등 기존에 사용하던 SQL 데이터베이스 위에 메모리 저장 구조를 바로 얹을 수 있습니다.
별도의 벡터DB나 복잡한 인프라를 추가로 구성할 필요도 없고, 메모리 저장소는 전부 사용자의 데이터베이스 안에 안전하게 보관됩니다.
Memori의 핵심은 ‘대화 기억 자동화’입니다. 개발자가 별도의 파이프라인을 구성하지 않아도 Memori가 LLM 호출을 가로채 컨텍스트를 주입하고, 응답 이후에는 중요한 정보를 자동으로 추출해 SQL DB에 저장합니다.
왜 Memori가 필요한가?
LLM 서비스에서 메모리는 사용자 경험을 크게 좌우합니다. 하지만 기존 방식에는 다음과 같은 문제가 있습니다.
1. 벡터DB는 비용과 구조가 과합니다
많은 서비스가 대화 기억을 위해 벡터 데이터베이스를 사용합니다. 하지만 단순히 사용자 선호나 대화 이력을 저장할 목적이라면 벡터DB는 비용과 시스템 복잡도가 지나치게 높습니다.
2. 메모리 파이프라인 구축이 어렵습니다
엔티티를 추출하고, 대화 컨텍스트를 선별하고, 저장 구조를 설계하는 과정은 개발자에게 반복적인 부담을 줍니다.
3. 데이터가 외부로 나가는 것에 대한 우려
외부 서비스가 제공하는 메모리 엔진은 다시 데이터 이동을 만들 수 있습니다. 반면 Memori는 모든 데이터를 사용자가 제어하는 SQL DB에 저장합니다.
Memori는 이런 문제를 한 번에 해결합니다. SQL이라는 가장 익숙한 환경에서, LLM 메모리를 자동화된 형태로 제공하므로 추가 학습 없이 바로 사용할 수 있습니다.
Memori의 핵심 특징
1. 한 줄로 메모리 활성화
memori.enable() 한 줄이면 LLM 호출 사이에서 자동으로 컨텍스트를 추출하고 주입합니다.
OpenAI, Anthropic, LangChain, LiteLLM 등과 모두 자연스럽게 연동됩니다.
2. SQL-Native Storage
모든 메모리는 SQLite, PostgreSQL, MySQL 등 평소 사용하는 DB에 그대로 저장됩니다.
확장성, 이동성, 감사 가능성이라는 SQL의 장점을 그대로 활용할 수 있고, 원하는 형태로 직접 조회할 수도 있습니다.
3. 80~90% 비용 절감
벡터DB를 사용하지 않기 때문에 메모리 저장을 위한 비용 부담이 사실상 사라집니다.
4. Vendor Lock-in 없음
데이터는 전부 SQL DB에 저장되므로 언제든지 다른 환경으로 이동할 수 있습니다.
SQLite 하나만으로 독립적인 메모리 파일을 만들어 서비스 이동도 쉽습니다.
5. Intelligent Memory
Memori는 단순 저장 엔진이 아닙니다.
대화 속에서 다음 정보를 자동으로 추출합니다.
- 엔티티
- 관계
- 선호
- 규칙
- 상황적 맥락
이런 요소들은 우선순위에 따라 분류되어 LLM 컨텍스트로 다시 제공됩니다.
Memori는 어떻게 동작할까? Architecture Overview
Memori의 동작 방식은 크게 세 단계로 나뉩니다.
1. Pre-Call: 컨텍스트 주입
- 애플리케이션이 LLM에 메시지를 보냅니다.
- Memori가 이를 가로채 관련 있는 기억을 SQL DB에서 검색합니다.
- Retrieval Agent 또는 Conscious Agent가 적절한 메모리를 선별합니다.
- LLM 요청 메시지에 기억 정보를 자동으로 합쳐 보냅니다.
2. Post-Call: 메모리 기록
- LLM이 응답을 반환하면
- Memory Agent가 해당 응답에서 의미 있는 정보를 추출합니다.
- 정보는 사실, 선호, 기술, 규칙, 컨텍스트 등으로 분류됩니다.
- SQL DB에 저장되며, 전체 대화는 Full-text search 인덱스로 정리됩니다.
3. Background Process: 장·단기 기억 자동 관리
6시간 주기로 Conscious Agent가 데이터를 분석해 장기 저장된 기억 중 현재 중요한 정보를 단기 기억으로 가져옵니다.
이 과정은 개발자 개입 없이 이루어집니다.
지원되는 SQL 데이터베이스
Memori는 아래와 같은 대부분의 SQL 기반 저장소를 자연스럽게 사용할 수 있습니다.
- SQLite
- PostgreSQL
- MySQL
- Neon
- Supabase
기존 인프라 그대로 사용하면 되므로 추가 구성 없이 바로 도입이 가능합니다.
다양한 LLM 프레임워크와의 호환성
Memori는 단일 프레임워크에 종속되지 않습니다.
주요 LLM 에이전트 프레임워크와 모두 통합되어 다음과 같은 환경에서 직접 메모리 엔진처럼 동작합니다.
- AgentOps
- Agno
- AWS Strands
- Azure AI Foundry
- AutoGen
- CamelAI
- CrewAI
- Digital Ocean AI
- LangChain
- OpenAI Agent
- Swarms
기존 프로젝트에 거의 수정 없이 바로 추가할 수 있는 점이 실무 개발자들에게 큰 장점으로 작용합니다.
SQL 기반 LLM 메모리의 실용성을 보여주는 솔루션
Memori는 LLM 서비스에서 언제나 문제가 되던 ‘메모리 기능’을 단순화하고, SQL이라는 가장 익숙한 방식으로 재해석한 엔진입니다. 단 한 줄로 활성화되며, 벡터DB 없이도 충분히 강력한 기억 기능을 제공합니다.
여기에 자동화된 정보 추출, SQL 기반의 비용 절감, 저장소 완전 통제, 프레임워크 호환성까지 갖추고 있어 실무 환경에서 즉시 적용할 수 있는 수준입니다.
AI 서비스에서 사용자 경험을 한 단계 끌어올리고 싶다면, Memori는 그 출발점으로 충분한 가치가 있습니다.
대화 기억을 위한 복잡한 구조를 제거하고, SQL 기반으로 투명하고 확장 가능한 메모리 엔진을 구축할 수 있기 때문입니다.
Memori는 앞으로 AI 에이전트와 챗봇의 구현 방식에 큰 변화를 가져올 수 있는 기술로 보이며, LLM 중심의 개발을 단순하고 실용적으로 만든다는 점에서 주목할 만한 솔루션입니다.
GitHub - GibsonAI/Memori: Open-Source Memory Engine for LLMs, AI Agents & Multi-Agent Systems
Open-Source Memory Engine for LLMs, AI Agents & Multi-Agent Systems - GibsonAI/Memori
github.com
'인공지능' 카테고리의 다른 글
| Claude Opus 4.5의 모든 것 - 핵심 기능과 성능 (0) | 2025.11.25 |
|---|---|
| 여러 LLM을 한 번에 비교하는 방법: LLM Council로 살펴보는 멀티 모델 평가의 새로운 흐름 (0) | 2025.11.24 |
| 텍스트 한 줄로 3D 세계를 만든다고? Meta WorldGen의 핵심 기술 완전 정리 (0) | 2025.11.24 |
| AI 시대에 진짜 중요한 개발 역량 5가지: 코드는 AI가 짜고, 개발자는 미래를 설계한다 (0) | 2025.11.24 |
| 구글의 ‘중첩 학습(Nested Learning)’ 패러다임 (0) | 2025.11.24 |
