Post

[리뷰] "AI가 드디어 나를 기억하기 시작했다" – SQL 네이티브 AI 메모리 엔진 'Memori' 완벽 해부 🧠

Posted
[Review] "AI Finally Starts Remembering Me" – A Deep Dive into the SQL-Native AI Memory Engine 'Memori' 🧠
[Review] "AI Finally Starts Remembering Me" – A Deep Dive into the SQL-Native AI Memory Engine 'Memori' 🧠
By
28 min read
[리뷰] "AI가 드디어 나를 기억하기 시작했다" – SQL 네이티브 AI 메모리 엔진 'Memori' 완벽 해부 🧠

“우리는 지금까지 AI에게 매번 처음 만난 사람처럼 인사를 건네야 했습니다. 컨텍스트 윈도우라는 좁은 방 안에서, AI는 끊임없이 과거를 잊어버리는 금붕어와 같았죠. 하지만 이제 그 지긋지긋한 ‘기억상실증’을 끝낼 때가 왔습니다.”

안녕하세요. 밤낮없이 터미널 창과 씨름하며 새로운 기술 스택의 이면을 파헤치는 것을 즐기는 현직 개발자이자 기술 칼럼니스트입니다. 여러분, 최근 AI 에이전트나 챗봇을 개발하시면서 제일 짜증 나고 답답한 부분이 무엇인가요? 저는 단연코 ‘기억(Memory)의 관리’라고 말하고 싶습니다.

우리는 사용자의 취향이나 이전 대화 내역을 간직하기 위해 무겁고 복잡한 벡터 데이터베이스(Vector DB) 인프라를 띄우고, RAG(Retrieval-Augmented Generation) 파이프라인을 구축하며, 아까운 토큰 제한을 넘지 않으려고 온갖 프롬프트 엔지니어링 묘기를 부려왔습니다. LangChain의 ConversationSummaryMemory 같은 걸 써보신 분들은 아실 겁니다. 대화가 길어질수록 요약에 또 요약을 거듭하다 보면 결국 핵심 문맥은 다 뭉개지고, 인퍼런스(Inference) 비용은 천정부지로 솟구치죠.

그런데 말입니다. 최근 제 GitHub 피드와 개발자 커뮤니티를 뜨겁게 달구고 있는 심상치 않은 오픈소스 프로젝트가 하나 있습니다. 바로 2025년 말 혜성처럼 등장해 생태계를 뒤흔들고, 급기야 2026년 3월 Memori Cloud라는 매니지드 서비스까지 런칭하며 광폭 행보를 보이는 Memori(메모리)입니다.

오늘은 비싼 벡터 DB에 의존하던 기존의 맹목적인 관행을 부수고, 우리가 가장 사랑하고 익숙한 SQL을 기반으로 AI에게 영구적이고 구조화된 기억을 심어주는 이 발칙하고 매력적인 프레임워크에 대해 아주 딥(Deep)하게 파헤쳐보려고 합니다. 커피 한 잔 준비하시고, 바로 시작해볼까요? ☕

⚡ TL;DR (The Core)

Memori는 값비싼 벡터 데이터베이스를 맹신하는 대신, SQLite, PostgreSQL, MySQL 등 표준 SQL 데이터베이스를 활용해 AI 에이전트에게 영구적이고 쿼리 가능한(Queryable) 기억을 제공하는 오픈소스 메모리 엔진입니다,. 단 한 줄의 코드(memori.enable())로 맥락 주입을 자동화하여 토큰 낭비를 막고, 인퍼런스 비용을 극단적으로 절감하며, 완벽한 데이터 통제권을 개발자에게 쥐여주는 혁신적인 도구입니다.

🧠 The Architecture / Technical Deep Dive: 왜 하필 SQL인가?

사실 처음 Memori의 아키텍처 문서를 접했을 때 제 솔직한 반응은 이랬습니다. “아니, 생성형 AI 시대에 웬 구시대의 유물인 SQL이야? 당연히 임베딩(Embedding)해서 고차원 벡터 공간에 때려 넣어야지!” 하지만 이 프레임워크의 내부 동작 원리를 코드로 직접 뜯어보고 나서는, 이들의 엔지니어링적 결단에 이마를 탁 칠 수밖에 없었습니다.

Memori의 설계 철학은 철저하게 ‘해석 가능성(Interpretability)’과 ‘실용성’에 초점을 맞추고 있습니다. 이를 세 가지 핵심 아키텍처 관점에서 분석해 보겠습니다.

1. 인터셉터 패턴(Interceptor Pattern)을 통한 극단적 단순화 Memori는 LLM 호출 과정의 앞뒤에 조용히, 그러나 치명적으로 개입하는 인터셉터 패턴을 사용합니다. 기존에 우리는 컨텍스트를 주입하기 위해 프롬프트를 수동으로 조립하는 장황한 코드를 작성해야 했습니다. 하지만 Memori는 다릅니다. LLM API가 호출되기 직전(Pre-call), Memori 엔진이 SQL DB에서 현재 상호작용 중인 사용자와 관련된 ‘핵심 기억(Context)’을 꺼내 시스템 프롬프트에 몰래 주입합니다. 그리고 LLM의 응답이 완료된 직후(Post-call)에는 메인 스레드의 지연(Latency)을 유발하지 않는 비동기 증강(Asynchronous Augmentation) 방식을 통해 대화 내용을 분석합니다,. 대화 속에서 새로운 사실을 추출해 백그라운드에서 조용히 DB에 저장하는 것이죠.

2. 관계형 데이터베이스(RDB) 기반의 다층적 기억 구조 벡터 DB는 “의미적으로 비슷한 문장”을 찾는 데는 탁월한 성능을 발휘하지만, “이 사용자의 직업은 무엇이고, 매운 음식을 좋아하는지” 같은 명확한 ‘팩트(Fact)’를 구조적으로 관리하는 데는 의외로 멍청합니다. Memori는 이 문제를 해결하기 위해 데이터를 다음과 같은 계층적(Hierarchical) 구조로 쪼개어 SQL에 저장합니다.

  • Entity (엔티티): 사용자, 장소, 사물 등 핵심 주체 (마스터 데이터 역할)
  • Session (세션): 특정 시간대에 이루어진 논리적인 대화의 묶음
  • Process (프로세스): 현재 상호작용 중인 AI 에이전트, 프로그램, 또는 특정 워크플로우

Memori의 엔진은 이 구조 위에서 대화를 분석하여 사실(Facts), 선호도(Preferences), 규칙(Rules), 식별 데이터(Identities), 그리고 관계(Relationships)로 카테고리화하여 저장합니다,. 이는 마치 인간의 대뇌 피질이 장기 기억을 범주화하여 저장하는 방식과 매우 유사합니다.

3. 완벽한 데이터베이스 불가지론 (Database Agnostic) Memori가 정말 매력적인 이유는 개발 생태계와의 호환성입니다. 로컬에서 토이 프로젝트를 만들 때는 가볍게 SQLite를 띄워 파일 형태(.db)로 기억을 관리하고, 트래픽이 몰리는 프로덕션 환경에 배포할 때는 환경 변수 하나만 바꿔서 기업용 PostgreSQL이나 MySQL로 즉각 전환할 수 있습니다,. 최근에는 문서 지향적인 MongoDB 스토리지까지 완벽하게 지원하기 시작했죠. Memori가 내부 어댑터를 통해 이 모든 저장/검색 과정을 완벽하게 추상화해주기 때문에, 개발자는 번거로운 SQL 쿼리를 단 한 줄도 직접 짤 필요가 없습니다.

💥 Why it Matters (Impact): 이것이 생태계를 어떻게 바꿀 것인가?

제가 일개 오픈소스 라이브러리인 Memori에 이토록 열광하는 이유는, 이것이 AI 애플리케이션 아키텍처의 패러다임을 근본적으로 뒤흔들 잠재력을 가지고 있기 때문입니다. 그 파장을 3가지 관점에서 날카롭게 짚어보겠습니다.

1. 비용(Cost)과 성능(Performance)의 기적적인 타협 💸 LLM 인퍼런스 비용을 갉아먹는 주범은 바로 ‘불필요하게 긴 컨텍스트 윈도우’입니다. 기존 RAG 시스템에서는 AI가 과거를 기억하게 만들려고 이전 대화 내용이나 관련 텍스트 덩어리(Chunk)를 통째로 프롬프트에 우겨넣었습니다. 당연히 토큰 소모량은 폭발하고 응답 속도는 굼벵이처럼 느려지죠. 하지만 Memori는 SQL에서 정확히 필요한 팩트와 선호도만 필터링하여 주입합니다. 전통적인 벡터 DB 기반 스택과 비교했을 때 인프라 구축 및 인퍼런스 비용을 최대 80~90%까지 절감할 수 있습니다,. 심지어 Memori Cloud 매니지드 서비스 도입 시 최대 98%의 인퍼런스 비용 절감 효과를 낼 수 있다고 하니, 런웨이(Runway)가 생명인 AI 스타트업 입장에서는 가뭄의 단비 같은 소식입니다.

2. 완벽한 데이터 주권과 강력한 보안 (Data Sovereignty & RBAC) 🛡️ 엔터프라이즈 환경에서 생성형 AI 도입을 망설이는 가장 큰 이유는 “우리의 핵심 고객 데이터가 통제 불가능한 외부 벡터 스토어나 서드파티 클라우드에 종속(Vendor Lock-in)되는 것 아니냐”는 불안감 때문입니다. Memori는 다릅니다. 데이터가 여러분이 이미 통제하고 있는 사내 SQL 데이터베이스에 그대로 머뭅니다 (BYODB 아키텍처). 더욱 놀라운 점은, RDB의 꽃인 역할 기반 접근 제어(RBAC, Role-Based Access Control)를 그대로 상속받는다는 점입니다. 특정 권한이 있는 관리자급 에이전트만 특정 사용자의 민감한 기억 테이블(예: 결제 선호도)을 조회할 수 있도록 데이터베이스 단에서 통제할 수 있습니다. 엔터프라이즈급 보안이 기본으로 탑재된 셈입니다.

3. 상태 보존형(Stateful) 멀티 에이전트 시대의 개막 🤖🤝🤖 지금까지의 AI 에이전트들은 각자의 격리된 세션 내에서만 동작하는 ‘단절된 섬’이었습니다. 하지만 Memori를 중앙 기억 장소(Memory Fabric)로 활용하면 어떨까요? ‘고객 지원 CS 에이전트’가 파악한 고객의 불만 사항과 환불 규칙(Rule)을, 다음날 접속한 ‘세일즈 추천 에이전트’가 동일한 SQL DB를 쿼리하여 즉각적으로 영업 전략에 반영할 수 있습니다. 에이전트 간의 소통이 느리고 불안정한 API 체인이 아니라, 빠르고 무결성이 보장된 공유 관계형 데이터베이스를 통해 이루어지는 진정한 ‘멀티 에이전트 생태계’가 열리는 것입니다.

🛠️ Hands-on / Use Case (Blueprint): 내 프로젝트에 당장 적용해보기

백문이 불여일견입니다. 실제 코드로 보면 이 프레임워크가 얼마나 미친 듯이 직관적이고 우아한지 체감하실 수 있을 겁니다. 여러분이 파이썬(Python) 기반으로 ‘개발자를 위한 맞춤형 코딩 어시스턴트 에이전트’를 만들고 있다고 상상해 봅시다.

기존에 LangChain에서 벡터 스토어 객체를 초기화하고, 리트리버(Retriever)를 만들고, 복잡한 Memory 컴포넌트를 줄줄이 달았던 과거는 이제 잊어버리세요. Memori를 사용하면 코드는 이렇게 짧아집니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# [과거의 방식] 복잡한 RAG 기반 메모리 파이프라인
# from langchain.vectorstores import Pinecone
# from langchain.memory import VectorStoreRetrieverMemory ... (어휴, 벌써 피곤하네요)

import memori
from openai import OpenAI

# 1. 단 한 줄로 Memori 엔진 활성화 (로컬 테스트용 SQLite 사용 시)
memori.enable(db_url="sqlite:///my_agent_memory.db")

client = OpenAI(api_key="your-api-key")

# 2. 평소처럼 LLM 호출 (Memori가 이 호출을 가로채서 컨텍스트를 주입합니다)
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "user", "content": "나 오늘부터 사이드 프로젝트 백엔드는 무조건 Go 언어만 쓸 거야. 앞으로 코드 짤 때 참고해."}
    ],
    user_id="dev_user_123",  # Memori가 이 식별자를 기반으로 Entity를 매핑합니다
    session_id="session_001"
)

print(response.choices[0].message.content)

여기까지는 평범해 보입니다. 핵심은 며칠 뒤, 완전히 새로운 세션에서 이 사용자가 질문을 던질 때 나타납니다.

1
2
3
4
5
6
7
8
9
10
11
12

# 며칠 뒤, 메모리에 의존하는 완전히 새로운 세션
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "user", "content": "나 새로운 오픈소스 만들려고 하는데, 빠른 개발을 위해 프레임워크 뭐 쓸까 추천 좀 해줘."}
    ],
    user_id="dev_user_123",  # 동일한 사용자 ID
    session_id="session_002" # 이전과 독립된 새로운 세션
)

print(response.choices[0].message.content)
# AI 응답 예측: "최근에 백엔드를 Go 언어로만 작성하기로 결정하셨죠? Go의 강력한 동시성 처리 성능을 극대화하면서도 빠르게 개발할 수 있는 Gin이나 Echo 프레임워크를 추천해 드립니다."

놀랍지 않나요? 우리는 그저 user_id 파라미터만 넘겨줬을 뿐입니다. Memori가 백그라운드에서 “이 사용자는 Go 언어를 선호함”이라는 선호도(Preference) 데이터를 추출해 SQL 테이블에 저장해두었다가, 다음 대화에 알아서 적절한 컨텍스트로 주입해낸 것입니다. 개발자는 더 이상 메모리 관리에 얽매이지 않고 핵심 비즈니스 로직에만 집중할 수 있게 됩니다.

[💡 한눈에 보는 비교 분석: Memori vs 기존 Vector DB 기반 RAG]

비교 지표Traditional Vector DB Memory (RAG)Memori (SQL-Native Memory)
데이터 형태비정형 벡터(Vector) 임베딩 덩어리정형화된 관계형 데이터 (Facts, Rules 등)
해석 가능성(가독성)인간이 읽거나 특정 데이터만 수정하기 극도로 어려움인간이 쉽게 읽고 SQL 쿼리로 직접 수정/삭제 가능
인프라 및 유지 비용고비용 (전용 벡터 DB 클러스터 및 임베딩 API 지속 호출 필요)저비용 (기존 RDB 활용, 구조화된 컨텍스트로 토큰 대폭 절감)
기억의 업데이트기존 벡터 검색 후 삭제 및 재임베딩 연산 필요 (매우 복잡함)단순하고 명확한 SQL UPDATE / DELETE 처리
가장 적합한 용도수만 장의 PDF 기반 대규모 지식 검색 (Knowledge Base 문서)사용자 프로필, 대화 히스토리, 상태 유지 및 개인화 (State/Profile)

🕵️‍♂️ Honest Review (The Truth): 완벽한 도구는 없다, 날카로운 한계점 분석

자, 여기까지 들으면 당장 내일 출근해서 회사 코드베이스를 다 엎어버리고 Memori를 도입하고 싶어지실 겁니다. 하지만 현업에서 숱한 삽질을 경험한 개발자로서 냉정하게 한계점과 진입 장벽도 짚고 넘어가야겠죠. 장점만 찬양하는 무비판적인 리뷰는 우리에게 아무런 영양가가 없으니까요.

첫째, 이것은 RAG의 ‘완전한 대체재’가 아닙니다. 가장 주의해야 할 오해입니다. Memori는 에이전트의 ‘상태(State)’와 사용자의 ‘개인화된 기억(Preferences/Facts)’을 관리하는 데는 가히 신(God)에 가깝습니다. 하지만 만약 여러분이 사내 규정집 PDF 10만 장을 던져주고 거기서 의미론적(Semantic)으로 가장 유사한 문서를 찾아오는 시스템을 원한다면? 여전히 Vector DB와 전통적인 RAG 파이프라인이 정답입니다. Memori는 ‘방대한 지식(Knowledge)’이 아니라 ‘유동적인 기억(Memory)’을 다루는 툴이라는 점을 아키텍처 설계 단계에서 명확히 구분해야 합니다.

둘째, ‘비동기 증강(Asynchronous Augmentation)’에 숨겨진 환각(Hallucination) 리스크. Memori가 사용자의 일상적인 대화 속에서 팩트와 규칙을 추출하는 과정 역시, 내부적으로는 파싱을 위한 가벼운 LLM(Small LLM)을 활용합니다. 만약 추출을 담당하는 LLM이 대화의 미묘한 뉘앙스나 반어법을 오해해서 완전히 ‘잘못된 규칙’을 SQL에 영구적으로 기록해버린다면 어떻게 될까요? 잘못 추출된 기억이 다음 프롬프트에 지속적으로 주입되어 연쇄적인 환각(Hallucination) 오류를 일으킬 위험이 존재합니다. 비록 SQL 테이블 형태라 개발자가 직접 DB 콘솔에 들어가서 지울 수는 있다고 하지만, 대규모 트래픽이 발생하는 프로덕션 환경에서는 이 ‘기억 추출의 품질’을 주기적으로 모니터링하고 정제하는 또 다른 파이프라인 구축이 불가피할 수 있습니다.

셋째, 매직 코드(Magic Code)가 주는 제어권 상실의 불안감. memori.enable() 같은 극단적인 추상화 코드는 개발 초반 빠른 프로토타이핑에는 최고입니다. 그러나, 프레임워크가 블랙박스처럼 작동하는 것을 극도로 꺼리는 시니어 엔지니어들에게는 엄청난 불안 요소가 될 수 있습니다. 엣지 케이스에서 에러 트래킹을 할 때 Memori가 정확히 어떤 프롬프트를 주입했는지, 어느 시점에 DB 커넥션 풀을 얼마나 점유하는지 완벽하게 통제하려면 결국 커스텀 설정(Custom Config)의 늪으로 깊게 파고들어야 하는 진입 장벽이 존재합니다.

🚀 Closing Thoughts: AI는 이제 ‘도구’에서 진정한 ‘동반자’로 진화한다

CEO Adam B. Struck과 CTO Michael Montero가 이끄는 Memori Labs는 2026년 3월 Memori Cloud를 발표하며 단순한 오픈소스 실험을 넘어 엔터프라이즈 AI 인프라 시장을 본격적으로 장악하겠다는 선언을 했습니다. “데이터베이스 프로비저닝조차 귀찮다면 우리가 클라우드에서 다 매니지드 해줄게”라는 그들의 강력한 자신감이 돋보이는 대목입니다.

소프트웨어 개발의 역사를 되돌아보면, 거대한 혁신은 늘 ‘비정상적으로 복잡했던 것을 압도적으로 단순화’하는 과정에서 폭발적으로 일어났습니다. 우리가 서버 인프라를 직접 물리적으로 깔고 랙에 꽂다가 AWS EC2 인스턴스 클릭 한 번으로 넘어갔을 때처럼 말이죠. 저는 Memori가 현재의 AI 생태계에 던지는 묵직한 메시지가 매우 명확하다고 봅니다.

“컨텍스트 윈도우와 메모리 파이프라인 관리는 우리(Memori)가 할 테니, 당신은 사용자의 삶을 바꾸는 압도적인 비즈니스 로직과 경험(UX)을 만드는 데만 집중하라.”

당장 이번 주말, 먼지 쌓여있던 토이 프로젝트를 열고 OpenAI API 키와 로컬 SQLite를 이용해 Memori 프레임워크를 한번 가볍게 적용해보세요. AI가 어제 당신이 새벽에 스쳐 지나가듯 했던 농담을 정확히 기억하고, 당신이 선호하는 깐깐한 코딩 스타일을 일관되게 유지하며 대화를 이어가는 순간… 기술이 주는 찌릿한 전율과 마주하게 될 것입니다.

단순히 프롬프트에 답하는 ‘자판기’ 같았던 인공지능이, 비로소 나의 과거를 이해하고 맥락을 공유하는 나만의 ‘진정한 동반자’로 눈을 뜨는 듯한 그 짜릿한 기분을, 동료 개발자 여러분도 꼭 한 번 느껴보시길 강력히 권해드립니다.

오늘도 여러분의 코드와 터미널 창에 평화가 가득하기를 바랍니다. Happy Hacking! 👨‍💻👩‍💻

References

  • https://github.com/MemoriLabs/Memori
  • https://memorilabs.ai/
  • https://www.infoq.com/news/2025/12/memori-sql-mongodb-memory/
  • https://opensourceforu.com/2026/03/open-source-memory-engine-from-memori-labs-goes-fully-hosted-with-memori-cloud/
  • https://medium.com/@ankush-choubey/the-open-source-sql-native-memory-engine-for-ai
Tech
This post is licensed under CC BY 4.0 by the author.