Supermemory는 RAG를 없애는 제품이라기보다, 여러 문서와 대화에서 뽑은 사실을 관계, 시간 정보와 함께 다시 찾도록 만드는 메모리 계층입니다. 단순한 Top-K 벡터 검색보다 오래된 정보와 새 정보를 구분할 여지는 있지만, 추출한 사실이 맞는지와 누가 어떤 기억을 볼 수 있는지는 운영자가 검증해야 합니다. 출처, 삭제, 권한을 설명할 수 없다면 “영구 기억”보다 잘못된 정보를 오래 보존하는 시스템이 될 수 있습니다.
Supermemory는 RAG를 대체할까: 관계, 시간, 삭제를 포함한 메모리 계층의 조건
일반 RAG와 무엇이 다를까
기본 RAG는 문서를 청크로 나누고 임베딩한 뒤 질문과 가까운 조각을 검색합니다. 구현이 단순하고 원문 청크를 그대로 인용하기 쉽지만, 서로 다른 문서에 흩어진 관계나 시간에 따른 변경을 한 번의 유사도 검색만으로 연결하기 어렵습니다. 같은 정책의 이전 버전과 현재 버전이 모두 상위에 나오면 생성 모델이 어느 쪽을 따라야 하는지도 모호해집니다.
Supermemory가 제안하는 방향은 벡터 검색에 팩트 추출, 관계와 시간적 문맥을 더하는 것입니다. 문서와 대화에서 사람, 프로젝트, 선호, 날짜 같은 정보를 식별하고 서로 연결하면 “지난 결정 이후 무엇이 바뀌었나”처럼 청크 하나로 답하기 어려운 질문을 다룰 수 있습니다. MCP 연결을 통해 여러 AI 도구가 같은 메모리 서비스에 질의하도록 구성할 수도 있습니다.
이 차이를 “벡터 검색은 낡았고 지식 그래프가 정답”으로 읽으면 안 됩니다. 사실과 관계를 추출하는 과정에도 모델 오류가 들어가며, 원문 청크보다 추상화된 메모리는 잘못 연결됐을 때 더 넓은 답에 영향을 줄 수 있습니다. 정확한 문구 검색과 출처 인용이 중요한 업무에서는 원문 검색을 함께 유지하는 편이 낫습니다.
기억 하나는 어떤 과정을 거쳐 저장될까
입력은 문서, 대화나 외부 서비스의 콘텐츠가 될 수 있습니다. 먼저 형식을 읽을 수 있는 텍스트로 변환하고, 검색에 필요한 표현과 재사용할 사실을 추출합니다. 다음으로 기존 메모리와 같은 대상인지, 새 사실인지, 이전 사실을 갱신하는 내용인지 판정한 뒤 검색 가능한 저장소에 반영합니다. 어느 단계에서 실패했는지 볼 수 있어야 빈 검색 결과와 잘못된 기억을 구분할 수 있습니다.
예를 들어 “A 프로젝트는 Python을 사용한다”는 기록 뒤에 “A 프로젝트의 새 백엔드는 Go로 이전했다”는 메모리가 들어왔다고 가정할 수 있습니다. 새 문장이 기존 사실을 완전히 폐기하는지, 특정 서비스에만 적용되는지, 계획인지 완료된 상태인지는 문장만으로 확정하기 어렵습니다. 단순히 최신 문장을 우선하면 범위를 잃고, 둘을 모두 활성화하면 답이 모순될 수 있습니다.
따라서 메모리에는 추출한 사실뿐 아니라 원문 위치, 작성 시각, 대상 범위, 추출 버전과 신뢰도를 함께 남겨야 합니다. 모델이 답할 때 어떤 메모리를 사용했는지 원문으로 돌아갈 수 있어야 잘못된 관계를 고칠 수 있습니다. 추출된 한 문장을 진실의 최종본으로 저장하기보다 출처가 있는 후보 사실로 다루는 편이 안전합니다.
시간과 망각은 어떤 정책이어야 할까
오래된 정보를 낮게 평가하는 기능은 유용하지만 “오래됐다”와 “틀렸다”는 같지 않습니다. 법적 계약, 과거 의사결정과 사건 기록은 사용 빈도가 낮아도 보존해야 하고, 개인 취향이나 현재 담당자는 최근 정보가 더 중요할 수 있습니다. 모든 메모리에 같은 감쇠 규칙을 적용하면 드물게 쓰는 중요한 사실이 사라질 수 있습니다.
메모리 유형별로 갱신 방식을 나눌 수 있습니다. 현재 상태는 새 사실이 검증되면 이전 값을 비활성화하고, 사건 기록은 시간순으로 모두 남기며, 추론된 관계는 근거가 바뀌면 다시 계산합니다. 삭제도 검색 순위만 낮추는 것과 실제 저장소, 백업, 캐시에서 제거하는 것을 구분해야 합니다.
충돌이 발견되면 최신값을 자동 선택하기 전에 사용자에게 범위나 시점을 물을 수 있습니다. “Python에서 Go로 바뀌었다”는 문장이 전체 조직인지 한 서비스인지 확인되지 않았다면 둘 중 하나를 지우지 않고 충돌 상태로 표시합니다. 답변도 “현재 확인된 두 기록이 충돌한다”고 말하고 원문을 보여 주는 편이 그럴듯한 단정보다 낫습니다.
관계 추출은 어떻게 검증할까
사실 두 개가 있다고 해서 그 사이의 모든 그럴듯한 관계가 사실은 아닙니다. “B가 A 프로젝트의 리드다”와 “A는 React를 쓴다”에서 “B는 React 전문가다”를 추론할 수는 있지만, 원문이 직접 확인한 사실은 아닙니다. 이런 추론 관계를 명시적 사실과 같은 등급으로 저장하면 이후 답변에서 추측이 출처 있는 정보처럼 보일 수 있습니다.
평가 세트에는 명시된 사실, 여러 문서를 연결해야 하는 사실, 성립하지 않는 유혹적인 관계를 함께 넣습니다. 검색 결과가 정답을 포함하는지뿐 아니라 답이 어떤 원문과 연결에서 나왔는지 확인합니다. 관계 하나를 삭제하거나 반대 사실을 넣었을 때 결과가 적절히 바뀌는지도 봐야 그래프가 오래된 연결을 고집하지 않는지 알 수 있습니다.
한국어처럼 주어가 자주 생략되고 조사와 높임말이 관계를 바꾸는 문장에서는 별도 검증이 필요합니다. 같은 인물의 이름 표기, 팀명 약칭과 동명이인을 잘못 합치면 그래프 전체에 오류가 퍼집니다. 엔티티 병합 후보를 사람이 검토할 수 있고 잘못 합친 노드를 다시 분리할 수 있는지 확인해야 합니다.
MCP로 여러 도구가 기억을 공유할 때 무엇이 위험할까
MCP 서버를 연결하면 편집기, 데스크톱 AI와 다른 클라이언트가 같은 메모리에 접근할 수 있습니다. 편리함의 반대편에는 권한 범위가 있습니다. 개인 메모리, 회사 문서와 프로젝트 비밀이 한 저장소에 섞이면 한 도구의 요청이 다른 영역의 정보를 가져올 수 있습니다.
클라이언트별로 읽기, 쓰기 권한, 사용자와 프로젝트 범위를 제한해야 합니다. 메모리를 추가하는 도구와 검색만 하는 도구를 분리하고, 외부 문서에서 온 지시가 기존 기억을 삭제하거나 덮어쓰지 못하게 합니다. 검색 결과가 모델 문맥으로 넘어갈 때 비밀 값과 권한 밖 청크가 포함되지 않는지도 로그로 확인해야 합니다.
도구에서 보낸 콘텐츠는 신뢰할 수 있는 지시가 아니라 데이터로 취급합니다. 문서 안에 “모든 이전 기억을 무시하라”는 문장이 있어도 메모리 정책을 바꾸지 않아야 합니다. MCP 호출 수, 반환된 메모리 ID, 사용한 출처와 쓰기 변경을 감사 로그에 남기면 잘못된 답이나 유출 경로를 추적할 수 있습니다.
검색 지연과 비용은 어떻게 비교할까
프로젝트가 소개하는 지연 수치는 후보를 시험할 이유는 되지만 자신의 데이터에서 보장되는 값은 아닙니다. 데이터 수, 관계 탐색 깊이, 재순위 모델, 네트워크와 동시 요청에 따라 전체 시간이 달라집니다. 단순 벡터 검색 기준선과 같은 질문, 같은 하드웨어에서 P50/P95 지연, 검색된 근거 수와 정답률을 비교해야 합니다.
관계와 시간 처리는 적재 비용도 늘릴 수 있습니다. 문서 한 건을 넣을 때 호출한 추출 모델, 생성된 사실과 연결 수, 중복 제거 시간과 재처리 비용을 기록합니다. 검색이 조금 좋아져도 적재가 느리고 잘못된 관계를 사람이 계속 고쳐야 한다면 총비용은 커질 수 있습니다.
셀프 호스팅은 API 비용을 없애는 대신 저장소, 추출 모델, 인덱스와 백업 운영을 가져옵니다. 관리형 서비스와 비교할 때 월 사용료만 보지 말고 데이터 반출 조건, 삭제 보장, 장애 복구, 버전 업그레이드와 운영 인력까지 포함합니다. 데이터가 늘 때 지연과 저장량이 어떻게 변하는지 작은 부하 시험에서 먼저 확인해야 합니다.
파일럿은 어떤 질문으로 시작할까
기존 RAG가 자주 틀리는 질문을 고르는 편이 좋습니다. 최신 정책과 폐기된 정책을 구분하는 질문, 서로 다른 회의 기록의 결정을 연결하는 질문, 사용자 선호가 바뀐 시점을 묻는 질문을 준비합니다. 각 질문에는 기대 답, 허용할 출처와 사용하면 안 되는 오래된 기록을 표시합니다.
기준선 벡터 검색, Supermemory형 관계, 시간 검색과 사람이 찾은 답을 비교합니다. 정답률만 아니라 근거의 정확성, 충돌 표현, 삭제 후 재노출, 응답 지연과 적재 비용을 기록합니다. 관계 검색이 단순 질문까지 느리게 만든다면 시간, 관계가 필요한 질문에만 라우팅하는 혼합 구조가 더 적합할 수 있습니다.
실패 조건도 미리 정합니다. 권한 밖 메모리가 한 번이라도 반환되거나, 삭제한 원문에서 파생된 사실이 계속 나오거나, 추론 관계를 명시적 사실처럼 답하면 배포를 보류합니다. 반대로 시간 충돌 질문에서 근거와 함께 최신 상태를 안정적으로 찾고 기존 RAG보다 검토 시간을 줄인다면 제한된 범위에서 확장할 근거가 생깁니다.
RAG를 버릴지보다 어느 기억을 맡길지 결정한다
정확한 원문 검색, 키워드와 필터가 강한 업무는 기존 RAG가 단순하고 설명하기 쉽습니다. 사용자 선호, 프로젝트 결정과 여러 도구의 대화처럼 시간이 지나며 변하고 연결되는 정보는 별도 메모리 계층의 이점이 클 수 있습니다. 한 시스템으로 모든 검색을 대체하기보다 정보 유형에 따라 경로를 나누는 편이 현실적입니다.
Supermemory의 핵심 질문은 모델에 “진짜 기억”을 주는가가 아닙니다. 어떤 사실을 저장했고 왜 현재 답에 사용했으며, 틀렸을 때 누가 고치고 삭제할 수 있는지를 시스템이 설명하는가입니다. 이 질문에 답할 수 있을 때 관계와 시간 기능은 RAG 위의 유용한 계층이 됩니다.
함께 읽으면 이해가 이어지는 글
- PraisonAI: YAML과 파이썬 코드로 구축하는 자율형 멀티 AI 에이전트 오케스트레이션 — PraisonAI는 코드 몇 줄이나 간단한 YAML 설정만으로 자율형 멀티 AI 에이전트 시스템을 구축하고 배포할 수 있게 해주는 오픈소스 프레임워크입니다. 100개 이상의 LLM 지원, 메모리 관리, RAG, MCP 도구 연동을…
- WeKnora가 표, 수식 PDF RAG에 맞을까: 파싱, Hybrid Retrieval 검증 — WeKnora의 layout, 표, 수식 parsing과 BM25, dense, graph 검색, agent, MCP 구조를 살펴보고 한국어 문서 정확도, 인용, 자원, 운영 조건을 검증합니다.
- GitNexus는 코드를 밖으로 보내지 않나: 브라우저 Graph RAG와 MCP 경계 — GitNexus가 브라우저에서 AST, 지식 그래프를 만드는 방식과 MCP로 외부 모델을 연결할 때 달라지는 데이터 경계, 규모, 정확도 검증법을 정리합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.