OpenHuman — 로컬 메모리와 데스크톱 UX를 결합한 개인 AI 슈퍼 인텔리전스

OpenHuman은 사용자의 메일, 문서, 채팅, 저장소, 캘린더 같은 업무 맥락을 로컬 Memory Tree로 압축하고, 이를 데스크톱 AI 에이전트·마스코트·음성·도구 호출에 연결하려는 오픈소스 개인 에이전트 프로젝트다.

핵심 방향은 “플러그인부터 설치하는 에이전트”가 아니라 “사용자의 일상 맥락을 먼저 기억하는 데스크톱 개인 AI”에 가깝다.

Figure 1. 저장소 README의 공식 히어로 이미지. 제품이 지향하는 “개인 AI/의인화된 에이전트” 브랜딩을 보여준다.

 

분석 기준: main 브랜치의 README, CONTRIBUTING, AGENTS.md, package/Cargo manifest, GitBook 문서, docs/gitbooks 이미지 자산, GitHub Discussions 목록을 기준으로 작성했다.

GitHub Wiki URL은 별도 위키가 아니라 메인 저장소로 리디렉션되며, 실제 문서화는 gitbooks/와 GitBook 링크가 중심이다.

---

Quick Links

구분	링크
GitHub 저장소	https://github.com/tinyhumansai/openhuman
공식 웹/다운로드	https://tinyhumans.ai/openhuman
공식 문서	https://tinyhumans.gitbook.io/openhuman/
Architecture 문서	https://tinyhumans.gitbook.io/openhuman/developing/architecture
Memory Tree 문서	https://tinyhumans.gitbook.io/openhuman/features/memory-tree
Integrations 문서	https://tinyhumans.gitbook.io/openhuman/features/integrations
TokenJuice 문서	https://tinyhumans.gitbook.io/openhuman/features/token-compression
Product Hunt	README 배지에 연결되어 있음
논문	저장소와 공식 문서에서 별도 논문 링크는 확인되지 않음

---

Key Features

1. UI-first 데스크톱 개인 에이전트

OpenHuman은 터미널 우선 도구가 아니라 Tauri 기반 데스크톱 애플리케이션으로 설계되어 있다.

README는 “clean desktop experience”, “short onboarding”, “no config-first setup”을 전면에 내세우며, 앱 내부에서는 채팅, 연결 계정, 메모리, 마스코트, 음성 기능을 하나의 인터페이스에 묶는다.

Figure 2. GitBook 자산의 데모 스크린샷. 왼쪽의 마스코트, 중앙의 채팅/액션 카드, 하단 음성 입력 UI가 “사람처럼 상호작용하는 데스크톱 에이전트” 방향을 보여준다.

2. 마스코트, 음성, Google Meet 참여형 에이전트

공식 문서는 OpenHuman의 에이전트가 “얼굴”을 가지며, 말을 하고, 주변 상태에 반응하고, Google Meet에 참여하는 형태까지 지향한다고 설명한다. 이는 단순 챗봇 UI보다 강한 의인화·상시성·상호작용성을 목표로 한 설계다. 기술적으로는 STT, TTS, 립싱크, 회의 참여, 백그라운드 사고 루프가 하나의 사용자 경험으로 연결된다.

Figure 3. docs/mascot.gif의 첫 프레임 미리보기. 원본 애니메이션은 figures/mascot.gif에 함께 보존했다. 마스코트는 OpenHuman이 일반적인 “사이드바 챗봇”이 아니라 동반자형 데스크톱 에이전트를 지향한다는 점을 시각적으로 보여준다.

3. 118+ 통합과 20분 주기의 Auto-Fetch

README와 GitBook 문서는 Gmail, Notion, GitHub, Slack, Stripe, Calendar, Drive, Linear, Jira 등 다수의 외부 연결을 OAuth 기반으로 제공하며, 모든 연결이 typed tool과 Memory Tree 입력원으로 노출된다고 설명한다.

Auto-Fetch는 활성 연결을 주기적으로 순회해 새 데이터를 가져오고, 이를 Memory Tree에 밀어 넣는다.

Figure 4. 통합/Auto-Fetch 문서 기반으로 재구성한 루프. 연결 계정 → 스케줄러 → provider sync → Memory Tree ingest → agent use가 반복되면서 에이전트의 장기 맥락이 갱신된다.

4. Memory Tree + Obsidian Wiki

OpenHuman의 가장 차별적인 기능은 Memory Tree다. 연결된 데이터를 Markdown 기반으로 정규화하고, 3k 토큰 이하 청크로 나누고, 점수화한 뒤 SQLite에 저장하고, 계층적 요약 트리로 접는다. 동일한 청크와 요약은 Obsidian 호환 vault로도 내보내져 사용자가 그래프와 파일 형태로 확인할 수 있다.

Figure 5. GitBook 자산의 Memory Tree 도식. 원본 문서/청크가 leaf가 되고, 여러 summary node를 거쳐 root summary로 축약되는 계층형 기억 구조를 보여준다.

Figure 6. GitBook 자산의 Obsidian 그래프 화면. Memory Tree가 단순 내부 벡터 DB가 아니라 사용자가 열람 가능한 wiki/graph 형태로 노출된다는 점이 중요하다.

5. TokenJuice: 도구 출력과 메모리의 토큰 압축 레이어

TokenJuice는 도구 호출 결과, 스크래핑 결과, 이메일 본문, 검색 payload 등을 LLM 컨텍스트에 넣기 전에 압축하는 레이어다. HTML을 Markdown으로 변환하고, 중복·장황한 출력·긴 URL 등을 축약하며, built-in/user/project rule overlay를 통해 컨텍스트 예산을 관리한다.

공식 README는 비용·지연을 줄이는 토큰 절감 효과를 강조한다.

Figure 7. TokenJuice 문서를 바탕으로 재구성한 흐름. 대용량 도구 결과가 규칙 오버레이와 압축 연산을 거쳐 모델에 전달되는 budgeted context로 바뀐다.

6. 모델 라우팅과 optional local AI

OpenHuman은 reasoning, fast, vision 같은 작업 유형에 따라 적합한 LLM으로 라우팅하는 모델 라우팅을 내세운다.

또한 Ollama 기반의 optional local AI를 문서화하고 있어, 클라우드 모델과 로컬 모델을 모두 고려하는 구조다.

다만 실제 의료·연구용 적용에서는 어떤 데이터가 로컬에 남고 어떤 payload가 외부 provider로 나가는지 정책적으로 검증해야 한다.

7. Privacy & Security: 로컬 우선 메모리와 서버 경계

문서는 원시 워크플로 데이터가 로컬 장치에 머무르고, 서버는 OAuth, LLM, 검색, TTS 같은 외부 작업을 중계하는 구조를 설명한다.

OS keychain, 로컬 암호화, short-lived token, prompt injection 대응, 권한/스코프 관리 등이 프라이버시 기능으로 제시된다.

Figure 8. GitBook의 privacy/security 자산. 원시 메시지·이메일·문서·키는 on-device 영역에 두고, 서버는 요약/압축된 그래프 또는 외부 작업만 처리한다는 보안 경계를 시각화한다.

8. Batteries included: search, scraper, coder toolset, voice

README는 OpenHuman에 web search, web-fetch scraper, filesystem/git/lint/test/grep 기반 coder toolset, native voice, ElevenLabs TTS, mascot lip-sync가 기본 연결되어 있다고 설명한다.

즉, “개인 메모리 + 외부 tool trunk + 데스크톱 UX”를 단일 harness로 묶는 전략이다.

---

Tech Stack

계층	구성
Desktop shell	Tauri v2, CEF runtime, single-instance/updater, IPC command layer
Frontend	React 19.1.0, Vite ^8.0.0, TypeScript ~5.8.3, Redux Toolkit ^2.11.2
Backend/Core	Rust 1.93.0, edition 2021, Tokio async runtime
Core crates	openhuman, openhuman-core, slack-backfill, gmail-backfill-3d, inference-probe
Rust dependencies	tokio, axum, rusqlite, reqwest, serde, socketioxide, whisper-rs, sentry, tracing 등
Package manager	pnpm 10.10.0, Node.js >= 24.0.0
Storage	SQLite, local content store, Obsidian-compatible vault, OS keychain
AI/tooling	model router, TokenJuice, MCP/native tools, optional Ollama/local AI, voice STT/TTS
Test/quality	pnpm typecheck, pnpm format:check, cargo check, Playwright/Vitest 관련 스크립트

 

버전은 README.md, CONTRIBUTING.md, app/package.json, Cargo.toml, rust-toolchain.toml, app/src-tauri/Cargo.toml의 main 브랜치 manifest를 우선 기준으로 정리했다.

릴리스/앱 패치 버전은 빠르게 변할 수 있으므로 실제 빌드 전 manifest를 다시 확인해야 한다.

---

Architecture

Figure 9. README, AGENTS.md, GitBook 문서, manifest, 소스 트리 구조를 종합해 재구성한 아키텍처 다이어그램. 저장소에 공식 PNG 아키텍처 다이어그램은 확인되지 않아 분석 기반으로 작성했다.

 

OpenHuman의 현재 구조는 크게 네 계층으로 읽을 수 있다.

1. React/Tauri desktop UX

app/는 실제 데스크톱 앱 계층이다. app/src에는 React UI, provider chain, state slice, services, routes가 있고, app/src-tauri는 Tauri shell, CEF runtime, native bridge, updater, single-instance, IPC command를 담당한다.

프론트엔드는 가능한 한 UI와 사용자 상호작용에 집중하고, 상태가 오래 유지되어야 하는 agent/tool/memory 로직은 Rust core에 위임한다.

2. In-process Rust core

AGENTS.md는 OpenHuman을 “React + Tauri v2 app with Rust core in-process”로 설명한다.

즉, core를 별도 sidecar 서버로만 보는 오래된 이해보다, Tauri host 안에서 Tokio task로 실행되는 Rust core가 현재 구조를 더 잘 설명한다.

프론트엔드는 HTTP JSON-RPC를 직접 외부 서버처럼 다루기보다 Tauri의 core_rpc_relay 같은 안전한 relay를 통해 core에 요청을 전달한다.

3. Domain modules under src/openhuman

src/openhuman/에는 Memory Tree, integrations, auto_fetch, event_bus, model_router, llm, tokenjuice, content_store, docstore, native tools, search, voice, skills, sync_engine 등 도메인 모듈이 분리되어 있다.

src/core는 transport/dispatch 성격이 강하고, 실제 제품 로직의 중심은 src/openhuman/* 모듈군으로 해석된다.

4. Memory Tree as durable context engine

Memory Tree는 단순한 “채팅 기록 저장소”가 아니라 agent의 durable context engine이다.

외부 연결에서 들어온 데이터가 canonicalize → chunk → score → queue → worker → source/topic/global tree summary → retrieval/UI/Obsidian export 순서로 처리된다.

Figure 10. Memory Tree GitBook 설명과 memory-tree-pipeline.excalidraw 자산을 참고해 정리한 비동기 파이프라인. 로컬 SQLite 작업 큐와 background worker가 장기 메모리 구축을 담당한다.

5. 문서 간 불일치: QuickJS 언급은 구버전 흔적으로 보는 편이 안전

일부 GitBook architecture 문서에는 QuickJS/skill runtime 관련 흔적이 남아 있지만, 현재 AGENTS.md는 QuickJS runtime이 제거되었고 이 저장소에서는 skills가 metadata/registry 중심이라고 명시한다.

따라서 현재 분석에서는 “QuickJS 기반 런타임”을 핵심 아키텍처로 보지 않고, Rust core + Tauri shell + registry-driven tools/skills 구조로 해석했다.

---

Source Code Structure

openhuman/
├─ app/                 # React/Tauri 데스크톱 앱
│  ├─ src/              # UI, providers, state, services, routes
│  └─ src-tauri/        # Tauri shell, IPC, native bridge, CEF/runtime config
├─ src/
│  ├─ core/             # core transport/dispatch, JSON-RPC/CLI 성격
│  └─ openhuman/        # agent, memory_tree, integrations, tokenjuice, llm, tools 등 도메인 로직
├─ packages/            # workspace packages
├─ gitbooks/            # 공식 문서 원본
├─ docs/                # 이미지, Excalidraw, mascot 등 문서/브랜딩 자산
├─ examples/            # 예제
├─ e2e/                 # end-to-end 테스트
├─ scripts/             # 설치/빌드/개발 스크립트
├─ tests/               # 테스트
├─ Cargo.toml           # Rust workspace/root crate
├─ package.json         # pnpm workspace/root scripts
└─ rust-toolchain.toml   # Rust toolchain pinning

 

설계상 눈에 띄는 점은 “프론트엔드 앱”과 “agent core”가 명확히 분리되어 있지만, core가 제품 밖의 원격 서버가 아니라 데스크톱 앱 내부의 Rust runtime과 로컬 저장소를 강하게 활용한다는 점이다.

---

Usage & Setup

바이너리/스크립트 설치

README 기준 설치 경로는 공식 웹사이트에서 DMG/EXE를 받거나, 운영체제별 스크립트를 실행하는 방식이다.

# macOS / Linux x64
curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh | bash

# Windows
irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 | iex

소스 개발 환경

필수 전제 조건은 Git, Node.js 24+, pnpm 10.10.0, Rust 1.93.0, CMake, Ninja, ripgrep, 플랫폼별 desktop build prerequisite다.

# 1. clone + submodule
# 실제 사용 시 본인 fork 또는 upstream URL 사용
git clone --recurse-submodules https://github.com/tinyhumansai/openhuman.git
cd openhuman

# submodule을 빠뜨렸다면
git submodule update --init --recursive

# 2. install
pnpm install

# 3. web-only UI 개발
pnpm dev

# 4. desktop shell 개발
pnpm --filter openhuman-app dev:app

# 5. Rust core 단독 실행/점검
cargo run --manifest-path Cargo.toml --bin openhuman-core
cargo check -p openhuman --lib

# 6. frontend quality gate
pnpm typecheck
pnpm format:check

 

본 리포트는 저장소 문서와 소스 구조 분석 결과이며, 위 명령의 로컬 빌드 성공 여부는 이 환경에서 실행 검증하지 않았다.

특히 Tauri/CEF vendored source, platform prerequisite, submodule 상태에 따라 빌드 난이도가 달라질 수 있다.

---

Discussions & Community Signals

Discussions 목록을 보면 단순 기능 토론보다 초기 제품 운영 이슈가 많이 보인다.

관찰 주제	해석
중국어/다국어 지원 요청	글로벌 사용자 유입과 localization 요구가 존재한다. README 자체도 영어/중국어/일본어/한국어 문서를 제공한다.
macOS local network access / Info.plist 이슈	Tauri/네이티브 앱 권한과 클라우드 연결 경계가 실제 사용성 이슈로 드러난다.
sign-in / connections auth issue	OAuth/연결 계정이 제품 핵심이므로 auth 안정성이 adoption에 직접 영향을 준다.
antivirus false-positive 제보	Windows 배포, 서명, updater, native binary 신뢰성 문서화가 중요하다.
client/server architecture 질문	사용자는 로컬 core와 backend/cloud boundary를 명확히 알고 싶어한다. 프라이버시 문서와 architecture 문서의 정합성이 중요하다.

 

이 신호들은 OpenHuman이 아이디어 단계가 아니라 실제 사용자가 설치·로그인·연결·권한 문제를 겪는 early beta 제품이라는 점을 보여준다.

---

Personal Insights

의료 AI 관점

OpenHuman의 Memory Tree 구조는 장기 환자 맥락, 진료 전후 문서, 의료진 커뮤니케이션, 환자별 longitudinal record를 에이전트가 기억하게 만드는 데 기술적으로 매력적이다.

특히 Obsidian-compatible vault와 source-backed graph는 “왜 이 에이전트가 이런 답을 했는가”를 추적하는 audit surface가 될 수 있다.

 

다만 의료 AI에 바로 적용하려면 현재 문서상의 privacy guarantee만으로는 부족하다.

PHI/PII 처리, HIPAA/GDPR, 접근제어, de-identification, 데이터 보존 정책, audit log, external LLM provider로 나가는 payload 제한, prompt injection 방어, 모델 hallucination 검증 체계가 필요하다.

TokenJuice 같은 압축 계층은 비용·속도에는 유리하지만, 임상에서는 압축 중 evidence가 누락될 위험이 있으므로 citation-preserving summarization이 필수다.

Bioinformatics 관점

Bioinformatics에서는 논문, 실험 노트, 파이프라인 로그, GitHub issue, Slack 토론, sequencing QC 결과, analysis notebook이 여러 곳에 흩어져 있다.

OpenHuman의 integration + auto-fetch + Memory Tree는 이런 분산 지식을 “랩 맥락 메모리”로 묶는 데 적합하다.

연구자가 “지난달 특정 variant filtering 기준을 왜 바꿨지?”라고 물으면, Slack/GitHub/문서/코드 변경을 함께 검색해 근거를 찾아주는 형태가 가능하다.

 

반대로 생물정보 데이터는 파일 크기와 provenance 요구가 크다.

원시 FASTQ/BAM/VCF 자체를 Memory Tree에 넣기보다, QC summary, pipeline metadata, commit hash, parameter diff, result table 요약을 source-backed chunk로 관리하는 편이 현실적이다.

또한 LLM이 생물학적 결론을 과잉 일반화하지 않도록, 답변에는 원문 문서와 실험 provenance를 강제 연결하는 설계가 필요하다.

Autonomous Agent 개발 관점

OpenHuman은 “도구를 가진 챗봇”보다 “지속 메모리 + 백그라운드 수집 + 도구 라우팅 + 데스크톱 UX”를 결합한 agent harness에 가깝다.

Memory Tree는 cold-start 문제를 줄이고, Auto-Fetch는 사용자가 매번 context를 복사해 붙여넣는 일을 줄이며, TokenJuice는 장기 맥락과 대량 도구 출력을 모델 budget 안에 넣는 데 도움을 준다.

 

Autonomous Agent로 확장할 때 핵심 리스크는 권한과 행동 통제다.

파일시스템, git, lint/test, 외부 OAuth tool, messaging channel이 모두 연결되면 agent의 행동 반경이 커진다.

따라서 고위험 action approval, scoped permission, rollback, human-in-the-loop, tool-call audit log, prompt-injection quarantine, connection별 rate/budget limit가 architecture의 일급 요소가 되어야 한다.

---

Harvested / Generated Figure Map

파일	출처/성격	연결 기능
figures/the_tet.png	저장소 docs/the-tet.png	README 히어로/브랜딩
figures/demo.png	GitBook asset	데스크톱 앱 UI, 마스코트, 채팅 UX
figures/mascot.gif	저장소 docs/mascot.gif	마스코트 애니메이션 원본
figures/mascot_preview.png	GIF 첫 프레임 변환	문서 내 마스코트 이미지 표시용
figures/privacy_shield.png	GitBook privacy/security asset	로컬 데이터·서버 경계 설명
figures/memory_tree_schema_repo.png	GitBook Memory Tree asset	계층 요약 구조
figures/obsidian_graph_repo.png	GitBook Obsidian asset	Memory Tree의 Obsidian graph 결과
figures/architecture_overview.png	분석 기반 생성	전체 시스템 아키텍처
figures/memory_tree_pipeline.png	문서/Excalidraw 기반 생성	Memory Tree 비동기 파이프라인
figures/tokenjuice_flow.png	분석 기반 생성	TokenJuice 압축 흐름
figures/auto_fetch_loop.png	분석 기반 생성	integrations + auto-fetch 루프

---

Source References

• README: https://github.com/tinyhumansai/openhuman/blob/main/README.md
• CONTRIBUTING: https://github.com/tinyhumansai/openhuman/blob/main/CONTRIBUTING.md
• AGENTS.md: https://github.com/tinyhumansai/openhuman/blob/main/AGENTS.md
• Root package manifest: https://github.com/tinyhumansai/openhuman/blob/main/package.json
• App package manifest: https://github.com/tinyhumansai/openhuman/blob/main/app/package.json
• Root Cargo manifest: https://github.com/tinyhumansai/openhuman/blob/main/Cargo.toml
• Tauri Cargo manifest: https://github.com/tinyhumansai/openhuman/blob/main/app/src-tauri/Cargo.toml
• Rust toolchain: https://github.com/tinyhumansai/openhuman/blob/main/rust-toolchain.toml
• GitBook Memory Tree: https://tinyhumans.gitbook.io/openhuman/features/memory-tree
• GitBook Auto-Fetch: https://tinyhumans.gitbook.io/openhuman/features/obsidian-wiki/auto-fetch
• GitBook Integrations: https://tinyhumans.gitbook.io/openhuman/features/integrations
• GitBook TokenJuice: https://tinyhumans.gitbook.io/openhuman/features/token-compression
• GitBook Privacy & Security: https://tinyhumans.gitbook.io/openhuman/features/privacy-and-security
• GitHub Discussions: https://github.com/tinyhumansai/openhuman/discussions