AI 에이전트를 여러 환경에서 쓰면 같은 설명을 반복하게 됩니다. 2026년 4월 1일 저는 외부 메모리 서비스인 Supermemory를 사용하던 구성을 걷어내고, Mac mini에 OpenMemory를 셀프호스팅하는 방향으로 전환했습니다.
이 글은 당시의 선택과 구축 기록을 현재 읽기 쉽게 다시 정리한 사례입니다. 특정 서비스가 항상 더 낫다는 비교나, 지금도 그대로 실행되는 설치 설명은 아닙니다. 저장소 구조, 환경변수, MCP 연결 방식은 버전에 따라 바뀔 수 있으므로 실제 설치 전에는 Mem0 공식 저장소의 최신 문서를 기준으로 확인해야 합니다.
교체 이유는 기능보다 기억의 통제 가능성이었습니다
당시 Supermemory를 사용하며 기록한 문제는 세 가지였습니다. 대화에서 저장할 필요가 없는 표현까지 사실로 추출되는 경우, 질문과 관련 없는 기억이 다시 주입되는 경우, 그리고 어떤 데이터가 남았는지 세밀하게 관리하기 어려운 점이었습니다.
이는 당시 개인 사용 환경의 관찰입니다. 서비스 전체의 품질이나 현재 동작을 대표하지 않습니다. 전환 결정을 내릴 때는 편리함과 비용만 비교하지 않고, 잘못 저장된 기억을 찾아 수정하거나 삭제할 수 있는지도 함께 봤습니다.
| 판단 항목 | 확인할 질문 |
|---|---|
| 저장 통제 | 어떤 정보가 기억으로 남았는지 확인·수정·삭제할 수 있는가 |
| 검색 품질 | 관련 없는 기억이 답변 문맥에 섞일 때 원인을 추적할 수 있는가 |
| 데이터 위치 | 외부 저장과 로컬 저장 중 어느 위험을 감수할 것인가 |
| 운영 부담 | 업데이트, 백업, 장애 복구를 직접 담당할 수 있는가 |
| 연결 방식 | 사용하는 클라이언트에서 지원되는 인터페이스인가 |
당시 구성은 네 개의 책임으로 나눴습니다
AI 클라이언트
→ MCP 연결
→ OpenMemory API
→ 로컬 LLM: 기억 추출
→ 임베딩 모델: 검색용 벡터 생성
→ Qdrant: 기억 벡터 저장Mac mini M4 24GB, Docker Desktop, Ollama를 사용했고 OpenMemory와 Qdrant를 컨테이너로 실행했습니다. 외부에서도 접근할 필요가 있는 환경에는 별도 사설 네트워크를 고려했습니다. 이 구성은 인터넷에 서비스를 공개하라는 의미가 아닙니다. 인증과 접근 제어가 확인되지 않은 MCP 또는 관리 화면을 공용 네트워크에 노출하면 안 됩니다.
최소 시험은 기억 한 건의 생애를 따라갑니다
설치 명령 대신 클라이언트와 저장소의 경계를 확인할 수 있는 시험을 먼저 정합니다. 다음은 새 시험을 설계할 때 쓸 가상 자료이며 실제 통과 기록은 아닙니다. 전용 테스트 사용자에 “연습 프로젝트의 정기 점검일은 화요일”을 넣고, 추출된 문장과 저장 식별자를 확인한 뒤 “연습 프로젝트를 언제 점검하나요?”로 검색합니다.
답이 틀리면 먼저 저장 문장에 화요일이 남아 있는지 확인합니다. 문장이 없으면 추출·저장 문제이고, 문장은 있지만 검색에서 빠지면 인덱스·필터·검색 문제입니다. 마지막으로 같은 기억을 삭제한 뒤 원본 저장소와 검색 결과를 각각 확인합니다. 삭제 요청의 성공 응답만으로 삭제 완료를 단정하지 않습니다.
여러 AI 클라이언트에서 공유하려면 동일 사용자 식별자가 쓰이는지도 별도로 확인해야 합니다. 한 클라이언트의 저장·검색 성공이 다른 클라이언트의 권한과 연결까지 검증하지는 않습니다.
연결 실패와 검색 실패를 다른 문제로 봅니다
당시 구성도를 점검 순서로 바꾸면 MCP 연결, API 응답, 기억 추출, 벡터 저장, 검색 결과 순입니다. 클라이언트에서만 실패하는지, 직접 저장도 실패하는지부터 구분하면 어느 구간의 설정과 로그를 볼지 좁힐 수 있습니다. 정답 문장이 아예 저장되지 않은 상태라면 임베딩 모델의 순위를 비교하기보다 추출 결과부터 확인하겠습니다.
벡터 차원 오류가 보이면 과거 패치를 먼저 복사하지 않습니다. Qdrant 공식 컬렉션 문서는 같은 벡터 공간에 저장되는 벡터의 차원과 거리 기준을 맞추도록 설명합니다. 실제 모델 응답의 벡터 길이와 대상 컬렉션 설정을 대조하는 것이 출발점입니다. 특정 차원 숫자가 모든 모델의 정답은 아닙니다.
전환 이전의 기대는 Supermemory 첫 도입 평가에, 연결 과정에서 부딪힌 차원 문제와 노트북 연동은 2026년 4월 2일의 연결 일기에 따로 남겼습니다.
기억 품질은 저장과 검색을 따로 평가합니다
기억 시스템의 실패는 저장하지 말아야 할 문장을 저장하는 문제와, 저장된 정답을 찾지 못하는 문제로 나뉩니다. 로컬 운영으로 바꿔도 이 두 문제가 자동으로 해결되지는 않습니다. 대신 모델과 검색 설정, 원본 데이터를 직접 확인할 수 있는 범위가 넓어집니다.
| 시험 | 남길 결과 |
|---|---|
| 정확한 사실 저장 | 원문에서 어떤 문장이 기억으로 추출됐는지 |
| 불필요한 표현 제외 | 감정·추측이 사실처럼 저장되지 않았는지 |
| 동의어 검색 | 다른 표현의 질문에서도 정답 근거가 상위에 오는지 |
| 삭제 | 삭제 뒤 검색 결과와 원본 저장소에서 사라졌는지 |
| 클라이언트 분리 | 다른 사용자나 프로젝트 기억이 섞이지 않는지 |
셀프호스팅이 맡게 만드는 책임
로컬에 데이터를 두면 외부 SaaS 의존은 줄지만 운영 책임은 사라지지 않습니다. 호스트 디스크가 고장 나면 기억도 함께 사라질 수 있고, 잘못된 접근 권한은 같은 머신의 다른 프로세스에 데이터를 노출할 수 있습니다.
- 벡터 데이터와 메타데이터의 백업·복구 절차
- 모델과 애플리케이션 업데이트 전 호환성 확인
- MCP 연결과 관리 화면의 접근 제한
- 기억 삭제 요청이 실제 저장소까지 반영되는지 확인
- 오류 로그에 대화 원문이나 비밀값이 남지 않게 하는 정책
당시 선택의 핵심은 “무료 로컬 서비스”가 아니라, 기억이 생성되고 검색되는 과정을 직접 관찰할 수 있다는 점이었습니다. 편리함이 우선이면 관리형 서비스가 더 적합할 수 있고, 세밀한 통제와 디버깅이 우선이면 셀프호스팅을 검토할 수 있습니다.
사례 기준일: 2026-04-01. 당시 구축 기록을 바탕으로 2026-09-03에 재구성했습니다. 현재 저장소 구조, 명령, 서비스 기능, 성능은 이 글에서 재검증하지 않았습니다.
편집 메모: 2026-09-10. 당시 경험과 수치를 보존하고 판단 기준과 관련 글 연결을 보완했습니다. 새 설치·성능 시험이나 현재 운영 상태의 재검증을 한 것은 아닙니다.
편집: 2026-09-13. 기존 기록의 구조를 정리한 것으로 새 실행·성능 시험이나 현재 서비스 상태 확인을 뜻하지 않습니다.