2026년 개인 AI 경쟁의 초점은 「모델이 얼마나 똑똑한가」에서 「Agent가 나를 기억하는가」로 옮겨가고 있습니다. ChatGPT Memory, Claude 프로젝트 컨텍스트, 각종 Coding Agent의 AGENTS.md——모두 같은 고통을 겨냥합니다: 대규모 언어 모델은 본질적으로 stateless이며, system prompt의 몇 줄 bullet은 메모지일 뿐 지능이 아닙니다. 오픈소스 OpenHuman(TinyHumans AI, GPL-3.0)은 한 걸음 더 나아가 「기억」을 CPU·스케줄러와 동급의 Memory OS(기억 운영체제)로 끌어올립니다. 외부 벡터 DB 래퍼가 아니라 로컬 우선·감사 가능·편집 가능한 Memory Tree 파이프라인입니다. 이 글은 아키텍처 관점에서 이 변화를 풀고, Apple Silicon 개발자가 Mac mini M4 Cloud Mac에서 7×24 개인 Agent를 돌리는 이유를 정리합니다.
왜 Memory OS인가 — 더 긴 컨텍스트 창만으로는 부족
컨텍스트 창이 8K에서 1M token으로 넓어져도 대화가 끝나면 모델 가중치에 아무것도 남지 않는다는 사실은 변하지 않습니다. 제품의 「기억」은 보통 다음 중 하나입니다:
- 사용자 선호 몇 줄을 system prompt에 적기;
- 세션 안에서 RAG로 벡터 DB에서 비슷한 조각 끌어오기;
- 플러그인으로 Notion / Google Drive를 임시 마운트.
이 방법들은 증상 완화에는 도움이 되지만 OS급 추상——통일 ingest 규격, 영구 포맷, 검색 스코프, 수명 주기 관리, 사람이 읽을 수 있는 저장——이 없습니다. OpenHuman의 Memory OS 은유가 여기를 메웁니다. Memory Tree는 「또 하나의 벡터 DB 래퍼」가 아니라 메일, Slack, GitHub, 회의 전사 등 이종 데이터를 deterministic pipeline으로 Agent가 조회 가능하고 사용자가 열 수 있는 Markdown 지식베이스로 바꿉니다. 공식 문서는 「You can't trust a memory you can't read.」라고 말합니다.
OpenHuman이란
OpenHuman은 TinyHumans의 로컬 우선 개인 AI Agent 데스크톱 앱입니다. Rust + Tauri 스택으로 「디지털 생활의 기억과 실행자(memory and doer)」를 목표로 합니다——채팅창만이 아닙니다. Terminal-first Agent 프레임워크와 달리 다음을 강조합니다:
- Memory Tree + Obsidian Wiki: 구조화된 장기 기억;
- Auto-fetch: 수동 prompt 없이 연결된 SaaS에서 주기적으로 가져오기;
- 전체 도구 체인: 웹 검색, 코드 도구, 브라우저 제어, Cron, 멀티 Agent 조율, 음성·Google Meet Agent;
- 118+ OAuth 연동(공식 비교표. 최신은 GitBook 참고).
2026년 5월 전후 GitHub·Product Hunt에서 큰 관심을 받았습니다——차별점의 핵심은 Chat UI가 아니라 Memory OS입니다.
Memory OS 핵심: Memory Tree 결정론 파이프라인
OpenHuman Memory Tree 문서에 따르면 새 데이터는 항상 같은 hot path를 탑니다:
source adapters (chat / email / document)
↓
canonicalize → 정규화 Markdown + 출처 메타데이터
↓
chunker → 결정론 ID, ≤3k token 청크
↓
content_store → 디스크 atomic .md 파일
↓
store → chunks.db (SQLite)
↓
score → 시그널 + embedding + 엔티티 추출
↓
source / topic / global trees → 스코프별 요약 트리
↓
retrieval → search / drill_down / topic / global / fetch
Ingest 3원칙
- Deterministic(결정론): 청크 ID는 콘텐츠 주소. 재 ingest해도 중복 행이 생기지 않음.
- Fast(고속): hot path에서 LLM 호출 없이 저렴한 휴리스틱으로 점수.
- Bounded write(유계 쓰기): 단일 트랜잭션으로 영속화, 반쯤 ingest가 DB를 오염시키지 않음.
무거운 작업——embedding, 엔티티 추출, seal 요약, 일별 digest——은 백그라운드 job queue로 갑니다. 기본 3 worker가 소비하고 semaphore로 LLM 동시 호출을 제한해 Auto-fetch 피크가 API quota를 잡아먹지 않게 합니다.
3층 트리: Source, Topic, Global
Memory OS의 「파일 시스템」은 평면 key-value가 아니라 독립적으로 자라는 3그루 요약 트리입니다:
| 트리 유형 | 스코프 | 전형적 질의 |
|---|---|---|
| Source tree | 연결 소스마다(Gmail label, Slack 채널, 단일 문서 등) | 「Stripe webhook이 지난주 화요일 15시에 뭐라고 했지?」 |
| Topic tree | 엔티티(사람, 프로젝트, repo, ticker) 열기로 lazy load | 「이 고객과 최근 모든 교류 요약?」 |
| Global tree | UTC 일별 글로벌 digest | 「오늘 전체적으로 무슨 일이 있었지?」 |
벡터 유사도는 바닥에서 여전히 작동하지만 트리 구조가 압축과 탐색을 제공——Memory OS와 「순수 RAG 벡터 주머니」의 분수령입니다. Leaf 수명 주기는 pending_extraction → admitted → buffered → sealed(또는 dropped). 검색 시 provenance를 거슬러 올라가며 파이프라인 전체를 다시 돌릴 필요가 없습니다.
Obsidian Wiki: 기억은 읽히고, 고쳐지고, 지워져야 한다
Memory Tree의 이중 쓰기 설계는 엔지니어링적으로 정직합니다. 같은 청크가 memory_tree/chunks.db와 wiki/ 아래 .md로——Obsidian vault 호환, Karpathy obsidian-wiki 워크플로에서 영감. 데스크톱 Intelligence 페이지에 「Obsidian에서 열기」 딥링크가 있고 검색 hit에서 원본 Markdown으로 돌아갈 수 있습니다.
개발자에게 의미하는 것:
wiki/를 Git으로 관리(민감 정보는 제외);- Agent가 틀리면 사람이 md를 직접 수정;
- 감사 시 기억은 블랙박스 embedding이 아니라 평문 + 점수 + 출처.
Auto-fetch: Memory OS가 능동적으로 「장부」를 쓴다
대부분 Agent 기억은 수동입니다——파일 @, 링크 붙여넣기, 수동 export. OpenHuman Auto-fetch는 약 20분마다 활성 연결을 순회해 새 메일, 메시지, PR을 Memory Tree에 씁니다. Scheduler는 UTC 0:00에 global daily digest와 stale buffer flush도 실행합니다.
제품 감각이 바뀝니다: 아침에 Agent를 열면 「어제 컨텍스트」가 이미 있다——매번 클라우드에서 cold mount하는 게 아니라 OS page cache에 가깝습니다.
agentmemory 백엔드: Cursor, Codex와 기억 공유
Cursor나 Claude Code 쪽에서 agentmemory(npx -y @agentmemory/agentmemory)를 self-host 중이라면 OpenHuman은 선택 backend를 제공합니다. config.toml에서 memory.backend = "agentmemory"로 두면 OpenHuman은 REST thin client가 되고 저장·embedding·하이브리드 검색(BM25 + vector + graph)은 agentmemory가 담당합니다.
전형적 매핑(공식 문서):
store→POST /agentmemory/rememberrecall→POST /agentmemory/smart-search- 수명 주기: consolidation, retention scoring, auto-forget, graph extraction
Memory Tree chunking/sealing pipeline과 trait backend는 직교——agentmemory로 바꿔도 Obsidian wiki 문서 ingest는 그대로. Agent 쪽 recall만 공유 저장소를 탑니다. 마이그레이션은 SQLite export → agentmemory POST → 설정 변경 재시작(현재 hot migration 없음).
Memory OS vs 벡터 DB vs 채팅 컨텍스트
| 방식 | 강점 | 전형적 약점 |
|---|---|---|
| 채팅 기록 연장 | 인프라 제로 | 구조화 없음, 세션 간 압축 없음, token 비용 선형 증가 |
| 순수 벡터 RAG | 의미 유사 recall 빠름 | 타임라인/엔티티 추적/「오늘 무슨 일」에 약함 |
| OpenHuman Memory OS | 트리형 요약 + 평문 wiki + Auto-fetch + 멀티 스코프 검색 | 로컬 디스크·macOS 데스크톱 필요; beta API 진화 중 |
OpenClaw 등 다른 Agent와 기억 차이
OpenClaw(이 블로그에서 여러 번 다룬 Gateway 오케스트레이션)는 멀티채널 라우팅, Daemon 헬스체크, SSH 터널 vs WSS에 강합니다——OpenClaw와 클라우드 Mac 자동화 참고. 기억은 플러그인·외부 DB에 의존하는 경우가 많고 Memory Tree는 내장하지 않습니다. OpenHuman은 기억을 제품화해 Intelligence 페이지에 저장 지표, 엔티티 관계 그래프, ingest 히트맵, Obsidian 진입점을 둡니다.
엔지니어링상 둘은 같은 Cloud Mac에 공존 가능합니다: OpenHuman은 장기 개인 지식 OS, OpenClaw는 Telegram/Webhook 트리거 작업 편성——단 OPENHUMAN_WORKSPACE와 OpenClaw 설정 디렉터리를 나누고 launchd나 tmux로 CPU/메모리 피크를 격리(대형 embedding과 Gateway 피크 겹침 방지).
Mac mini M4 Cloud Mac에서 OpenHuman 실행
데스크톱 Agent인데 Cloud Mac? 다음 세 유형에는 이유가 분명합니다:
- Windows/Linux 메인 개발자: Tauri OpenHuman + Ollama Metal embedding에 macOS가 필요하지만 Mac 구매는 원치 않음——Windows 원격 Xcode와 같은 논리.
- 7×24 Auto-fetch: 노트북 절전이 주기 sync를 끊음; 전용 M4는 SSH+VNC 상시로 Memory Tree가 계속 자람.
- 대용량 wiki: chunks.db + Obsidian + Hugging Face/Ollama 캐시 성장 빠름——1TB/2TB 확장은 M4 스토리지 FAQ 참고.
하드웨어: 16GB vs 24GB와 Ollama
Memory Tree fast-score path는 GPU를 쓰지 않지만 백그라운드 embedding·요약은 LLM을 호출합니다. Local AI(Ollama)를 켜면 M4 유니파이드 메모리는 MLX/Ollama 실험과 같은 계열: 16GB는 가벼운 sync+작은 embed, 24GB는 worker 병렬·큰 embed·IDE 동시 실행. 디스크는 AI+Memory OS면 1TB부터 권장.
배포 단계 요약
- Vuncloud Mac mini M4 렌트, SSH 로그인, workspace를 영구 볼륨에 둠.
- OpenHuman release 설치, OAuth 연동 설정.
- 첫 수동 Run ingest,
wiki/와 Intelligence 지표 증가 확인. - (선택) Ollama 설치, Local AI로 on-device embedding.
- (선택) agentmemory 연결, Cursor 워크플로와 recall 공유.
Mac 구매 vs Cloud Mac 렌트
Memory Tree가 프로덕션급 제2의 뇌이고 Auto-fetch가 업무 메일·코드 repo에 연결돼 있다면 로컬 Mac mini의 프라이버시·월 0원이 매력적——제2 거점 백업이나 팀 read-only wiki 미러가 필요해질 때까지. OpenHuman+agentmemory 단기 검증은 주 단위 전용 노드가 유연하고, 장기 고가동은 로컬 vs 원격 렌트 TCO 참고. 같은 머신에서 GitHub Actions macOS runner도 돌리는 CI 팀은 임대 기간을 병렬 분할하는 패턴이 흔합니다.
FAQ
Memory OS란? 로컬 Memory Tree + Obsidian wiki + Auto-fetch 전체 은유——기억에 ingest, 저장, 인덱스, 스케줄, 검색 API가 있는 OS.
데이터 위치? 기본 ~/.openhuman/memory_tree/chunks.db와 wiki/. 로컬 SQLite + Markdown.
Cursor와 agentmemory 공유? 가능. memory.backend = "agentmemory"로 로컬 REST 지정.
RAG 벡터 DB와 차이? Source/Topic/Global 트리, digest, 편집 가능 wiki. similarity search만이 아님.
Mac 필수? 데스크톱은 macOS 대상. 24/7은 Cloud Mac이 일반적.
OpenClaw와 충돌? 필수는 아님. 디렉터리·리소스 분리.
beta 안정? 활발하지만 빠르게 변함. 프로덕션은 chunks.db·wiki/ 백업.
결론
OpenHuman이 보여 주는 Memory OS 노선은 개인 AI를 「채팅 + 임시 RAG」에서 「로컬 우선·감사 가능·동기화 가능한 지식 OS」로 밀어 올립니다. Memory Tree의 결정론 ingest, 3층 요약 트리, Obsidian 이중 쓰기가 「Agent가 왜 나를 기억하는가」에 답합니다——더 큰 context가 아니라 구조화된 기억층으로. Apple Silicon 개발자는 Mac mini M4에서 Ollama·agentmemory를 맞추고 필요 시 Cloud Mac 상시 sync로 확장——2026년에 현실적인 개인 AI 엔지니어링 경로입니다.
Mac mini M4 렌트, 7×24 OpenHuman Memory OS
Vuncloud 전용 Mac mini M4 Cloud Mac에서 OpenHuman, Ollama 로컬 embedding, 영구 Memory Tree 워크스페이스 배포——Auto-fetch가 노트북 절전으로 끊기지 않습니다. 지연에 맞춰 US East, US West, APAC 노드를 고르세요.