3월에 누군가 “프로젝트 메모리는 Postgres가 좋겠어”라고 말했습니다. 4월에는 “아니, 이 메모리 프로젝트는 Neo4j로 가자”로 바뀌었죠. 오늘 “그래서 어떤 DB를 쓰기로 했지?”라고 물으면, 검색은 두 문장을 모두 찾아냅니다. 문제는 그다음입니다. AI는 종종 옛날 답을 고르거나 둘을 뒤섞어 자신 있게 틀린 답을 내놓습니다.
개발자 Mark Huang이 자신의 블로그에 “AI 메모리”를 RAG, 벡터, 그래프 관점에서 해부한 글을 올렸습니다. 핵심은 단순합니다. 2026년의 “AI 메모리”는 하나의 기능이 아니라 서로 다른 5개 층위이고, 각 층위는 저마다 다른 방식으로 실패한다는 것입니다. 그리고 가장 중요한 구분 하나, 검색(retrieval)은 텍스트를 찾고, 메모리는 무엇이 지금 유효하고 신뢰할 만한지를 결정합니다.
출처: AI Memory Beyond RAG: Vectors, Graphs, and Dense-Mem – markhuang.ai
“AI 메모리”는 하나가 아니다
요즘 제품 설명에서 “장기 기억” “메모리” 같은 말이 흔하게 등장합니다. 그런데 같은 단어가 전혀 다른 것을 가리킵니다. Mark Huang은 이를 5개 층위로 정리합니다.
가장 단순한 건 프롬프트 메모리입니다. 지시사항을 맥락에 넣어두는 방식이죠. RAG는 외부 텍스트를 찾아 맥락에 주입하고, 벡터 메모리는 의미적으로 비슷한 항목을 꺼내옵니다. 그래프 메모리는 사실과 관계, 이력, 충돌을 저장하고, 마지막 지속형 메모리는 이 모두를 검색·상태·출처·갱신 정책과 함께 묶습니다.
흥미로운 건 실패 양상이 전부 다르다는 점입니다. 프롬프트 메모리는 맥락이 비거나 모호하면 규칙을 놓칩니다. RAG는 오래되거나 불완전한 근거를 끌어옵니다. 벡터 메모리는 비슷한 텍스트를 찾아도 그게 정답이 아닐 수 있죠. 그래프 메모리는 검증 관문이 없으면 틀린 사실이 그대로 쌓입니다. 그래서 “메모리 기능 있어요”라는 말만으로는 그 시스템이 무엇을 잘하고 무엇을 못 하는지 알 수 없습니다.
RAG의 한계는 RAG가 아니다
RAG에 대한 흔한 오해부터 짚고 갑니다. 많은 사람이 RAG를 “키워드로 검색해서 주변 100자쯤 긁어다 프롬프트에 붙이는 것”으로 이해합니다. 그런 구현이 있을 수는 있지만, RAG의 본질은 아닙니다.
RAG(검색 증강 생성)는 외부 정보를 검색해 모델에게 추가 맥락으로 건네는 방식입니다. 그 ‘검색’ 부분이 키워드일 수도, 벡터일 수도, 둘을 섞은 하이브리드일 수도, 그래프 탐색이나 SQL 필터일 수도 있습니다. 전형적인 벡터 RAG는 다음 순서로 작동합니다.
- 원본 문서를 모은다
- 문서를 청크(chunk) 단위로 쪼갠다
- 각 청크를 벡터로 변환(임베딩)한다
- 벡터와 메타데이터를 인덱스에 저장한다
- 질문이 들어오면 질문도 벡터로 바꾼다
- 가장 가까운 청크들을 꺼낸다
- 그 청크들을 프롬프트에 주입한다
그러니 RAG의 품질은 어떻게 쪼개고, 임베딩하고, 인덱싱하고, 거르고, 재정렬하느냐에 크게 좌우됩니다.
여기서 진짜 한계가 드러납니다. 앞서 본 Postgres→Neo4j 예시처럼, 같은 사람이 시간차를 두고 모순된 말을 했을 때입니다. 순수 검색 시스템은 3월 발언과 4월 발언을 모두 찾아 모델에게 건넨 뒤 “알아서 잘 판단하겠지” 하고 맡깁니다. 이건 벡터 검색이 잘못된 게 아닙니다. 상태 관리(state management)의 실패입니다. 검색은 “질문과 비슷한 텍스트가 뭐냐”까지만 알 뿐, 그게 지금도 유효한 사실인지는 모릅니다.
그래프 메모리가 채우는 빈칸
지속형 메모리가 답하려면 “비슷한 텍스트”보다 훨씬 많은 걸 알아야 합니다. 누가 언제 말했는지, 그게 근거인지 주장인지 확정된 사실인지, 기존 사실과 충돌하는지, 오래된 사실이 대체되었는지 같은 것들이죠.
그래서 그래프 데이터베이스가 등장합니다. 그래프는 관계를 직접 저장합니다. “사용자가 Neo4j를 선호한다”, “이 주장이 옛 Postgres 선호를 대체했다”, “이 사실은 근거가 약하다” 같은 연결을 1급 시민으로 다루죠. 벡터 검색이 “의미적으로 무엇이 가까운가”에 답한다면, 그래프 검색은 “무엇이 연결되어 있고, 지금 유효하며, 뒷받침되거나 충돌하는가”에 답합니다.
핵심은 그래프 DB가 마법이어서가 아닙니다. 메모리라는 것 자체가 관계적이고 역사적이기 때문입니다. Mark Huang이 제시하는 설계 원칙도 같은 맥락입니다. 원시 근거(raw evidence)는 곧바로 사실이 되어선 안 되고, 먼저 관문을 통과해야 하며, 충돌이 생기면 조용히 덮어쓰는 대신 사용자에게 되묻게 한다는 것입니다. 그는 이 아이디어를 Dense-Mem이라는 자신의 실험 프로젝트로 연습하고 있는데, 구체적 구현보다 그 ‘경계(boundary)’ 설정이 핵심입니다. 호스트 모델은 후보 메모리를 발견하고, 메모리 층은 저장·임베딩·출처·충돌 검사·회상을 책임지도록 역할을 나누는 것이죠.
정리하면, 메모리는 회상보다 큰 문제다
그렇다고 “그래프 + 벡터가 RAG보다 무조건 더 정확하고 빠르다”고 말하는 건 지나친 단순화입니다. 더 나은 임베딩 모델은 의미 매칭을 개선하지만 출처나 사실 확정은 해결하지 못합니다. 그래프 DB는 관계 탐색에 강하지만 임베딩과 짝을 이루지 않으면 의미 유사도를 다루지 못합니다. 잘못 설계된 그래프 스키마는 느리고, 엉성한 벡터 인덱스는 엉뚱한 걸 꺼내옵니다. 공짜 점심은 없고, 각 층이 분명한 자기 역할을 가질 때 비로소 구조가 작동합니다.
이 글이 던지는 진짜 메시지는 용어 정리를 넘어섭니다. RAG는 여전히 시스템의 일부, 회상(recall) 장치입니다. 하지만 메모리는 회상보다 큽니다. 무엇을 간직할지, 그것이 참인지 어떻게 아는지, 어떻게 갱신하는지, 그리고 언제 다시 꺼낼지를 정하는 일이죠. AI에게 “기억”을 붙이려는 시도가 늘어나는 지금, 검색과 기억을 같은 것으로 착각하는 순간 시스템은 옛 텍스트를 잘 찾으면서도 어떤 사실이 현재 유효한지는 모르는 상태에 빠집니다.
답글 남기기