벡터 검색만으로 AI의 기억을 만들 수 있을까: OpenHuman의 Memory Tree
AI 에이전트와 RAG, 세컨드 브레인을 공부하면서 한 가지 의문이 생겼다. AI가 현재 대화만 이해하는 데서 그치지 않고, 내가 이전에 남긴 기록과 작업 맥락까지 계속 기억하게 만들 수 있을까?
처음에는 개발자가 학습 기록, 에러 해결 과정, 설계 판단을 남기면 문서를 청킹하고 임베딩해 다시 찾아주는 서비스를 생각했다. 정확한 키워드를 몰라도 상황만 설명하면 관련 기록을 찾는 구조다. 그러다 개인의 이메일·문서·메시지·저장소까지 장기 기억으로 만들려는 오픈소스 프로젝트 OpenHuman을 발견했다.
OpenHuman을 살펴보며 질문이 조금 달라졌다. 검색 결과가 질문과 비슷한가뿐 아니라, 어떤 정보가 현재 유효하고 다른 기록과 어떻게 연결되는가도 기억의 품질을 결정하지 않을까?
대화 기록을 많이 저장하면 장기 기억이 될까
LLM이 한 번에 참고할 수 있는 컨텍스트 윈도우는 유한하다. 새 대화를 시작하면 이전 맥락이 자동으로 모두 따라오지 않고, 이메일·GitHub·Notion·Slack에 흩어진 데이터도 모델이 알아서 읽을 수 없다. 따라서 외부 저장소와 검색 계층이 필요하다.
하지만 저장과 검색만으로 문제가 끝나지는 않는다. 벡터 검색은 의미가 비슷한 문장을 찾는 데 강하지만, 과거의 결정과 현재의 결정을 함께 반환하거나 프로젝트 전체 흐름보다 질문에 가까운 일부 문장만 고를 수 있다. 에이전트 실행이 중단됐을 때 어디까지 수행했는지는 지식 검색과 별개의 실행 상태 문제이기도 하다. 장기 기억은 컨텍스트 윈도우, 외부 메모리, 검색, 시간 정보와 실행 상태를 나누어 설계해야 한다.
먼저 인정해야 할 RAG의 장점
일반적인 RAG는 다음 흐름으로 동작한다.
문서 수집 → 청킹 → 임베딩 생성 → 벡터 DB 저장 → 질문 임베딩 → 유사도 검색 → LLM 컨텍스트에 포함 → 답변 생성
구현이 비교적 단순하고 대량의 비정형 문서를 다루기 좋다. 정확한 키워드를 몰라도 의미 기반으로 검색할 수 있고, 모델을 다시 학습하지 않아도 기존 문서를 근거로 쓸 수 있다. 이전에 RAG의 청킹 전략을 정리하면서 검색할 문서를 어떤 단위로 나눌지가 중요하다는 점을 살펴봤다. OpenHuman은 여기서 한 단계 더 나아가 검색 대상을 장기적인 기억 구조로 어떻게 구성할지를 고민하는 사례로 볼 수 있다.
RAG는 원문 청크의 유사도를 중심으로 찾고, Memory Tree는 압축된 계층에서 관련 가지를 좁혀 내려가는 접근을 취한다.
벡터 검색만 개인 기억에 사용하면 상하위 관계가 약하고 비슷한 내용이 중복될 수 있다. 중요한 결정과 임시 메모를 구분하기 어렵고, 오래된 결정도 현재 기록과 함께 검색될 수 있다. 원문이 청크로 분절되어 반환되면 결론에 도달한 과정도 놓치기 쉽다. 데이터가 늘수록 가까운 문장이 반드시 필요한 문장이라는 보장도 약해진다.
물론 이는 벡터 검색 자체의 결함이라기보다 벡터 유사도 하나에 너무 많은 역할을 맡겼을 때의 한계다. 날짜·프로젝트 메타데이터 필터, 재랭킹, 요약 계층, Graph RAG를 조합하면 상당 부분 보완할 수 있다.
OpenHuman의 Brain: 검색할 문서가 아니라 기억 구조 만들기
현재 공식 문서에 따르면 OpenHuman은 연결된 데이터를 출처가 표시된 Markdown으로 정규화하고, 3,000토큰 이하의 결정적 청크로 나눈다. 청크는 로컬 SQLite의 memory_tree/chunks.db와 Obsidian 호환 wiki/의 Markdown 파일에 저장된다. 이후 임베딩·엔티티·중요도 성격의 점수를 계산하고, 출처·주제·날짜별 요약 트리를 만든다. 활성 연결은 20분 주기로 다시 수집한다.
이를 기억을 담당하는 Brain이라고 해석하면 흐름은 다음과 같다.
개인 데이터 수집 → 요약·압축 → 관련 정보 분류 → 계층 생성 → Markdown 저장 → 관련 가지 탐색 → 필요한 맥락 제공
Memory Tree의 차이는 원문 조각만 꺼내는 대신 상위 요약에서 관련 범위를 좁히고 하위 기록으로 내려갈 수 있다는 데 있다. 같은 청크가 Markdown으로도 남으므로 사용자가 Obsidian에서 읽고 수정할 수 있고, 기억이 벡터 DB 안에만 갇히지 않는다. 반복 기록을 압축해 장기 맥락을 유지하려는 설계도 드러난다.
다만 저장소의 설명만으로 이 방식이 일반 RAG보다 항상 정확하거나 효율적이라고 결론 내릴 수는 없다. 요약 중 정보가 사라질 수 있고, 서로 충돌하는 기록과 최신 상태를 어떻게 판정하는지, 데이터가 커졌을 때 검색 성능이 어떤지는 별도 평가가 필요하다.
Orchestrator와 Deep Researcher는 어떻게 봐야 할까
OpenHuman의 현재 README는 코딩 도구, 브라우저 제어, 일정 실행, 메모리 도구, 하위 에이전트 조정을 기본 도구 모음으로 소개한다. 따라서 Orchestrator는 한 에이전트의 단순 반복 루프보다 여러 도구와 하위 에이전트를 조정하는 역할로 이해할 수 있다. 일반적으로 그래프 실행, 체크포인트, 승인 대기, 재시작 후 복구 같은 durable execution은 긴 작업의 중간 상태를 보존하는 방법이다.
하지만 현재 공식 문서에서 OpenHuman이 이 기능들을 그래프 기반 durable workflow로 모두 제공한다고 확인되지는 않았다. 이 부분은 제품의 검증된 기능이라기보다 에이전트 실행 계층을 설계할 때 필요한 기준으로 구분해야 한다.
Deep Researcher와 SuperContext도 마찬가지다. 질문을 받은 뒤 검색을 시작하는 대신, 메모리·파일·웹을 미리 탐색해 맥락을 준비하면 에이전트의 cold start를 줄일 수 있다는 개념은 타당하다. OpenHuman의 자동 수집과 Memory Tree 사전 구성은 이 방향과 닿아 있다. 다만 현재 공식 README와 문서에서 Deep Researcher, SuperContext라는 명칭과 독립 구성 요소는 확인하지 못했으므로 OpenHuman의 확정 기능처럼 단정해서는 안 된다.
RAG와 Memory Tree는 대체 관계가 아니다
| 기준 | 일반적인 RAG | Memory Tree 접근 |
|---|---|---|
| 저장 | 원문 청크와 벡터 | 원문 청크, SQLite, Markdown 요약 계층 |
| 검색 | 질문과 가까운 청크 | 관련 요약·가지 탐색 후 세부 조회 |
| 관계·시간 | 메타데이터를 별도 설계 | 계층과 날짜별 요약에 반영하려는 구조 |
| 사람의 확인 | DB만으로는 어려움 | Obsidian에서 읽고 편집 가능 |
| 강점 | 대규모 비정형 검색 | 장기적이고 구조화된 맥락 관리 |
| 비용·위험 | 노이즈와 재랭킹 비용 | 요약 손실과 갱신 복잡도 |
RAG는 많은 문서에서 관련 내용을 빠르게 찾는 데 적합하고, Memory Tree는 개인의 장기 맥락을 구조화해 관리하려는 접근에 가깝다. 실제로는 상위 요약으로 범위를 좁힌 뒤 하위 원문을 벡터 검색하는 하이브리드 구성이 자연스럽다.
개발 기록 서비스에 적용한다면
OpenHuman이 다루는 범위는 이메일, 일정, 메시지, 문서, 저장소와 에이전트 실행까지 넓다. 내가 생각한 서비스는 학습 기록, 에러와 원인·해결 방법, 기술 선택과 트레이드오프, 요구사항과 ADR, 커밋·이슈·PR·코드 리뷰, 장애와 재발 방지처럼 개발 기록에 집중한다.
개발 기록은 프로젝트·기술·학습이라는 상위 맥락과 원본 근거를 함께 보존할 수 있다.
OpenHuman과 유사한 제품이 존재한다고 해서 개발 기록 검색 서비스의 의미가 사라지는 것은 아니다. 범용 개인 AI와 개발 기록에 특화된 지식 시스템은 해결 범위가 다르다. 특화 서비스는 이전 구현과 현재 구현, 프로젝트와 기술처럼 개발 도메인의 관계를 더 정교하게 표현할 수 있다.
처음에는 개인 개발 기록을 임베딩해 검색하는 RAG 기반 서비스를 생각했다. 하지만 OpenHuman을 살펴보면서 검색 정확도뿐 아니라 정보의 구조, 시간에 따른 변화, 기록 간 관계가 중요하다는 생각이 들었다. 벡터 DB에 모든 기록을 넣는 것만으로는 어떤 정보가 현재 유효한지, 왜 바뀌었는지까지 알 수 없다.
그렇다고 처음부터 복잡한 지식 그래프와 에이전트 오케스트레이션을 만들면 핵심 가치를 검증하기 전에 개발 복잡도만 커질 수 있다. 초기 MVP라면 다음 정도가 현실적이다.
- 원본 Markdown은 그대로 보존한다.
- PostgreSQL에 프로젝트·날짜·기술·상태 메타데이터를 둔다.
- pgvector로 원문 청크를 의미 검색한다.
- 상위 요약과 하위 원문을 연결하고 원문 출처를 표시한다.
- 오래된 결정과 현재 결정을 구분하고 변경 이유를 남긴다.
- 사용자가 요약과 기억 구조를 수정할 수 있게 한다.
검색할 때는 상위 프로젝트 맥락을 먼저 고르고 관련 원문을 추가 조회한다. 데이터가 쌓이고 실제 실패 사례가 확인된 뒤 관계 그래프, 요약 자동 갱신, 오래된 기록 감지를 확장하면 된다. OpenHuman은 내가 생각했던 서비스를 대체하는 제품이라기보다 개인 AI의 기억을 설계할 때 고려할 범위를 넓혀준 사례에 가깝다.
한계까지 포함해서 보기
OpenHuman은 현재 Early Beta다. 다양한 통합의 안정성, 대량 데이터 성능, 여러 에이전트의 비용은 직접 검증해야 한다. 로컬에는 Memory Tree와 Markdown Vault가 남지만, 기본 설정의 로그인·모델 라우팅·웹 검색 프록시·관리형 OAuth와 도구 호출에는 OpenHuman 호스팅 서비스가 관여한다. 따라서 로컬 저장이라는 표현만 보고 모든 개인 데이터 처리가 기기 안에서 끝난다고 이해하면 안 된다.
자동 요약은 정보 손실과 잘못된 기억의 장기 보존 위험도 만든다. 새 기록이 기존 기록과 충돌할 때의 규칙, 권한 범위, 삭제와 정정, 요약의 출처 추적이 필요하다. 사람이 읽을 수 있다는 장점도 사용자가 계속 관리해야 하는 비용이 될 수 있다. 그러므로 OpenHuman은 장기 기억 문제를 해결했다고 보기보다, 이를 해결하려는 구조를 제안하고 구현 중인 프로젝트로 보는 편이 정확하다.
오늘 학습한 점
AI의 장기 기억은 대화 내용을 많이 저장하는 문제가 아니라 검색, 구조화, 시간 관리, 압축과 관계 표현을 함께 설계하는 문제였다. RAG는 여전히 유용하지만 개인 기억 전체를 만드는 유일한 방법은 아니다. Memory Tree는 사람이 읽고 수정할 수 있는 계층적 기억이라는 관점을 보여준다. 실제 개발 기록 서비스에서는 원본 보존, 의미 검색, 메타데이터 필터와 출처 표시부터 검증한 뒤 계층 구조를 더하는 순서가 현실적이다.