왜 집 안에서
기억 작업은 가족의 기계 밖으로 절대 안 나가. embedding 은 bge-m3(다국어, 1024차원)에서 나오고, 2026-06-03부터는 서버 맥에서 도는 OpenAI 호환 MLX 서버 oMLX 가 bge-m3-mlx-fp16 으로 서빙해. ChromaDB 는 벡터를 <app-data>/chroma/ 에 저장해. 어떤 기억 작업도 업체 API 로 나가지 않아.
6월까지는 같은 모델이 Ollama 로 돌았어. 옮긴 건 취향 문제가 아니었어. Ollama 업데이트가 embedding 경로를 망가뜨렸고, 그대로 있으면 모델을 잃을 판이라 모델을 지키려고 retrieval 을 oMLX 로 옮긴 거야. 코드 기본값은 아직 Ollama 를 가리켜. 실제 선택은 office 의 환경 설정에 있고, 어느 쪽인지는 collection 이름이 말해줘. 지금 쓰는 한 쌍은 이름에 provider, 모델, 차원을 달고 있거든.
collection 둘
- messages — user 와 assistant 메시지. 저장될 때마다 embedding 돼. '어디서 X 얘기했지?' 검색과 RAG 에 써.
- vault — 영혼의
core/,memory/,principles/,index/,library/트리와Pippa.md,instructions.md. 두뇌 없는 작업이 30분마다 다시 색인하는데, 수정 시각이 바뀐 파일만 건드려. 2026-09-13부터는 공용 vault 도 영혼마다의 파티션 옆에 자기 파티션을 가져(레슨 8).
일부러 빼 둔 트리는 하나야. playbook/ 은 처음부터 색인 대상이 아니었고, 여전히 Read 한 번이면 닿아. library/ 엔 따로 사연이 있어. 2026-07-25에 embedding 에서 빠졌는데, 그때 거기엔 claude.ai 와 ChatGPT 에서 가져온 대화 모음이 들어 있었고 그게 vault 조각 전체의 96%였어. retrieval 은 5월부터 그걸 입구에서 버려 왔고. 그 대화 모음이 vault 밖으로 옮겨 가자, 2026-10-01에 아빠가 영혼의 library 참고 노트도 다른 기억과 똑같은 기억이라고 정했어. 그래서 영혼마다의 library/ 와 공용 library/ 가 같은 관련도 기준과 범위 규칙 아래 다시 색인돼.
왜 하필 bge-m3
다국어야. 한국어와 영어를 같은 vector space 에서 다뤄. 피파의 vault 엔 둘 다 있어. 영어 전용 embedding 은 대부분 한국어 항목에서 무너져.
embedding 결과는 기억 자체가 아니라 후보 목록이야. vector 거리가 가깝다고 지금 질문의 답이라는 보장은 없어. 그래서 조각마다 출처 경로와 조각 경계를 같이 남기고, reranker 를 거친 뒤에도 원문을 읽고 판단해야 해. 검색 점수가 기억의 진실을 대신하면 안 돼.
embedding 을 집 안에 두는 이유도 비용만은 아니야. 가족의 대화와 vault 조각이 검색되려고 바깥 API 로 나가는 일이 없고, provider 가 잠깐 멈춰도 기억 원본은 그대로야. 색인은 다시 만들 수 있는 거울이고, 원본은 Markdown 과 JSONL 이야.