2026년 5월 28일 KST 기준 OpenHuman GitHub 저장소는 Early Beta 상태의 오픈소스 개인 AI 에이전트 하네스로, Memory Tree, Obsidian-style Markdown vault, 118개 이상 OAuth 연동, 20분 auto-fetch, TokenJuice 압축, 모델 라우팅을 전면에 내세운다. 최신 릴리스는 2026년 5월 27일 공개된 v0.56.0으로 표시된다.
처음 보면 꽤 매혹적이다. “내 자료를 기억하는 개인 AI”, “Obsidian Wiki”, “로컬 메모리”, “Gmail·Notion·GitHub·Slack 연결”, “토큰 비용 최대 80% 절감” 같은 단어가 한꺼번에 나온다. 개인 지식 자동화에 관심 있는 사람이라면 손이 근질근질하다. 나도 이런 구조를 보면 바로 내 볼트와 비교하게 된다. 직업병이다. 폴더 구조를 보면 혈압보다 tree 명령이 먼저 떠오른다.
그런데 OpenHuman을 볼 때는 기대와 경계를 같이 봐야 한다. README는 local-first 지식베이스를 말하면서도, 기본 managed experience에서는 계정 로그인, 모델 라우팅, 웹 검색 프록시, OAuth/Composio 연동에 OpenHuman hosted backend를 쓴다고 분명히 적고 있다. 즉 “로컬”이라는 단어 하나만 보고 개인정보 경로가 모두 내 컴퓨터 안에서 끝난다고 생각하면 위험하다.
OpenHuman은 개인 AI 에이전트의 중요한 방향을 잘 보여준다. 다만 도입 전에는 Memory Tree보다 먼저 로컬/managed 경계, OAuth 권한, 저장 위치, 설치 검증, 라이선스와 백업 전략을 확인해야 한다.
지금 결론
OpenHuman의 흥미로운 점은 AI 비서를 채팅창이 아니라 개인 작업 하네스로 보려는 점이다. 이메일, 캘린더, 문서, 코드 저장소, 업무 도구를 연결하고, 그 데이터를 Markdown chunk와 Memory Tree로 압축해 에이전트가 기억하게 만든다. 이 방향 자체는 매우 강하다.
하지만 개인 자료가 많이 연결될수록 질문은 더 엄격해져야 한다. 어디까지 로컬에 저장되는지, 어떤 요청이 hosted backend로 가는지, OAuth token과 tool call은 누가 처리하는지, 자동 수집 주기는 어떻게 끄는지, Obsidian vault와 SQLite를 백업·삭제할 수 있는지 확인해야 한다.
TECHTAEK식으로 줄이면 이렇다. OpenHuman은 “설치해볼 가치가 있는 하네스”지만, “주 계정 전체 연결”로 시작하면 안 된다. sandbox 계정, 테스트 vault, read-only 범위, 설치 파일 검증, 로그 확인부터 가야 한다. 개인 AI 비서에게 처음부터 집 비밀번호와 금고 번호를 같이 주면 너무 친해진 거다.
OpenHuman이 해결하려는 문제
대부분의 AI 비서는 매번 차갑게 시작한다. 어제 내가 무슨 프로젝트를 했는지, 어떤 회의가 있었는지, 내 코드 저장소가 어떤 구조인지, Obsidian에 어떤 노트가 있는지 모른다. 그래서 사용자는 매번 맥락을 복붙하거나, 플러그인을 붙이거나, RAG를 따로 만들어야 한다.
OpenHuman의 방향은 이 cold start를 줄이는 것이다. README는 118개 이상 third-party integrations와 20분 auto-fetch를 설명한다. Gmail, Notion, GitHub, Slack, Stripe, Calendar, Drive, Linear, Jira 같은 도구를 연결하면 활성 연결에서 데이터를 끌어와 memory tree에 넣는 구조다.
Memory Tree + Obsidian Wiki도 흥미롭다. 연결된 데이터를 3k token 이하 Markdown chunk로 정규화하고, 점수화하고, 계층적 summary tree로 접어 SQLite에 저장하며, 같은 chunk를 Obsidian 호환 vault의 .md 파일로 남긴다고 설명한다. 내 볼트 운영과 바로 비교되는 지점이다. 사람이 읽고 고칠 수 있는 Markdown을 중간 산출물로 둔다는 점은 좋은 방향이다.
TokenJuice도 실무적으로 볼 만하다. README는 HTML, 이메일, 도구 출력, 검색 payload를 LLM에 넣기 전에 압축하고, CJK와 이모지 같은 multi-byte 텍스트를 grapheme 단위로 보존한다고 설명한다. 한국어 사용자에게는 이 부분이 중요하다. 압축하다가 한글이 이상하게 깨지면 그건 비용 절감이 아니라 의미 절감이다.
먼저 확인할 로컬·managed 경계
OpenHuman README에서 가장 중요한 문장은 “Local + managed services, upfront” 쪽이다. OpenHuman은 Memory Tree, Obsidian-style Markdown vault, workspace config, local runtime state를 로컬에 저장한다고 설명한다. 동시에 default managed experience에서는 account sign-in, model routing, web search proxying, managed integration/OAuth flows through Composio connector layer에 hosted backend를 쓴다고 밝힌다.
이 구분은 사소하지 않다. 개인 AI 비서는 내 이메일, 캘린더, 문서, 저장소를 연결할수록 강해진다. 동시에 공격 표면과 오해 가능성도 커진다. “로컬 우선”이라는 말이 “모든 처리가 로컬”이라는 뜻은 아니다. 문장 하나 차이가 데이터 경로 전체를 바꾼다.
도입 전에 적어야 할 질문은 단순하다. 어떤 데이터가 로컬 vault에 남는가. 어떤 데이터가 hosted backend로 전달되는가. OAuth token은 어디에 저장되고, token refresh는 누가 처리하는가. auto-fetch가 끌어온 데이터는 삭제할 수 있는가. workspace를 지우면 SQLite와 Markdown chunk도 함께 지워지는가.
이 질문에 답하지 못하면 아직 메인 계정을 연결하면 안 된다. 먼저 테스트용 Gmail, 빈 Notion workspace, 공개 GitHub repo, 샘플 캘린더로 흐름을 확인하는 편이 좋다. 안전한 AI 도입은 의심이 많은 사람의 취미처럼 보이지만, 실제로는 운영자의 예의다.
도입 전 7칸 체크리스트
첫 번째는 설치 경로다. README는 Homebrew tap, signed apt repo, Windows MSI 같은 native package 경로를 권장하고, curl | bash류 script install은 무결성 검증이 없다고 경고한다. 개인 AI 비서는 로컬 파일과 계정 연동을 다루므로 설치 파일 검증은 귀찮아도 해야 한다.
두 번째는 계정 범위다. 처음부터 메인 Gmail, 회사 Slack, 실제 Stripe, production GitHub를 연결하지 말자. 테스트 계정이나 최소 권한 계정으로 시작한다. 연결은 쉬운데 연결 해제와 데이터 삭제가 명확하지 않으면 신뢰가 쌓이지 않는다.
세 번째는 자동 수집 주기다. 20분 auto-fetch는 편하지만, 무엇을 언제 가져오는지 모르면 불안하다. auto-fetch 대상, 끄는 방법, 수집 로그, 실패 로그를 확인해야 한다. 자동 수집은 기억력이 아니라 운영 정책이다.
네 번째는 vault 위치다. Obsidian 호환 Markdown vault가 어디에 생성되는지, 기존 vault와 섞이는지, 별도 vault로 분리할 수 있는지 봐야 한다. 나는 Obsidian no-focus 운영을 선호하기 때문에 자동으로 앱을 열거나 기존 노트를 바꾸는 흐름은 특히 조심해서 본다.
다섯 번째는 SQLite와 backup이다. Memory Tree가 SQLite에 저장된다면 백업, migration, corruption recovery가 중요하다. 개인 메모리는 쌓일수록 시스템보다 귀해진다. AI가 똑똑해지는 것보다 내 자료가 안 날아가는 게 먼저다.
여섯 번째는 라이선스다. GitHub 페이지는 GPL-3.0 license를 표시한다. 개인 사용에는 큰 문제가 아닐 수 있지만, 회사 내부 도구로 수정·배포하거나 제품에 섞을 계획이라면 법무나 오픈소스 정책 확인이 필요하다. 라이선스는 재미없지만, 나중에 재미없게 터지는 것보다 지금 재미없게 보는 게 낫다.
일곱 번째는 모델 라우팅과 비용이다. OpenHuman은 backend model routing과 one subscription을 말하지만, 실제 비용 구조, local Ollama 옵션, hosted model 사용 범위, token compression 적용 위치를 확인해야 한다. “자동으로 적합 모델 선택”은 좋지만, 운영자는 어느 순간 어떤 모델이 돈을 쓰는지 알아야 한다.
| 체크 칸 | 확인 질문 | 시작 기준 |
|---|---|---|
| 설치 | package signature나 OS 패키지 경로인가 | Homebrew/apt/MSI 우선 |
| 계정 | 테스트 계정부터 연결했나 | 메인 계정 보류 |
| auto-fetch | 20분 수집 대상과 중지 방법을 아나 | 로그 확인 후 확대 |
| vault | 기존 Obsidian과 분리되나 | 별도 테스트 vault |
| backup | SQLite와 Markdown 백업이 가능한가 | 복구 절차 확인 |
| 라이선스 | GPL-3.0 영향을 확인했나 | 회사 사용 전 검토 |
| 비용 | hosted/local 모델 경계를 아나 | 라우팅 로그 확인 |
내 Obsidian/LLM Wiki 운영에 가져올 아이디어
OpenHuman에서 가장 참고할 만한 부분은 Memory Tree와 Obsidian Wiki의 조합이다. 내 볼트도 인박스, 프로젝트, 영역, 리소스, 아카이브로 나뉘고, .claude/MEMORY와 LLM Wiki를 따로 운영한다. OpenHuman식으로 보면 이 구조는 사람이 직접 관리하는 memory tree에 가깝다.
가져올 아이디어는 세 가지다. 첫째, 자동 수집된 자료를 바로 지식으로 믿지 않고, Markdown chunk와 source link를 남기는 흐름이다. 둘째, 긴 자료를 에이전트에게 넘기기 전에 3k token 이하 요약 단위로 쪼개는 습관이다. 셋째, 모델 호출 전에 중복과 장황한 출력을 줄이는 compression layer 개념이다.
반대로 그대로 가져오면 안 되는 것도 있다. OAuth를 대량으로 연결해 자동 수집하는 흐름은 개인 볼트에서는 너무 강할 수 있다. 특히 회사 계정, 가족 일정, 결제, 투자, 의료, 세금 자료는 “에이전트가 알면 편하다”보다 “에이전트가 몰라도 되는 것”을 먼저 정해야 한다.
내 기준으로는 OpenHuman을 바로 메인 시스템으로 옮기기보다, 별도 vault에서 작은 실험으로 보는 게 맞다. 예를 들어 공개 GitHub repo 1개, 테스트 캘린더 1개, 샘플 문서 20개를 연결하고, Memory Tree가 어떤 Markdown을 만드는지 확인한다. 그다음 기존 Obsidian/LLM Wiki와 충돌하지 않는 부분만 가져온다.
흔한 실수 TOP 5
첫 번째 실수는 “local-first”를 “cloud 없음”으로 읽는 것이다. README는 로컬 저장과 managed backend 사용을 함께 설명한다. 이 경계를 확인하지 않으면 개인정보 경로를 오해하기 쉽다.
두 번째 실수는 OAuth를 한 번에 많이 연결하는 것이다. Gmail, Notion, GitHub, Slack을 동시에 붙이면 멋있어 보이지만, 문제가 생겼을 때 원인을 추적하기 어렵다. 하나씩 연결하고 로그를 보는 편이 낫다.
세 번째 실수는 기존 Obsidian vault와 바로 섞는 것이다. 자동 생성 Markdown은 편하지만, 기존 지식 체계와 충돌할 수 있다. 테스트 vault에서 chunk 품질과 파일명 규칙을 먼저 보는 게 안전하다.
네 번째 실수는 설치 편의성을 보안 검증보다 앞에 두는 것이다. README가 직접 native package 경로를 권장하고 script install의 무결성 문제를 언급한다. 로컬 파일 접근 도구는 설치부터 보수적으로 가야 한다.
다섯 번째 실수는 “개인 AI 비서”를 처음부터 생활 전체에 붙이는 것이다. 좋은 개인 AI는 한 번에 나를 전부 아는 도구가 아니라, 작은 범위에서 믿을 수 있는 기억을 쌓는 도구에 가깝다. 친해지는 것도 단계가 있다. 첫 만남에 주민등록등본 주면 관계가 좀 무겁다.
언제 써볼 만하고 언제 기다릴까
써볼 만한 사람은 개인 지식관리, Obsidian, 로컬 AI, 에이전트 하네스, workflow automation을 이미 다뤄본 사람이다. 특히 “내 자료를 Markdown으로 정리하고, AI가 그걸 계속 참고하게 만들고 싶다”는 욕구가 있다면 OpenHuman은 좋은 관찰 대상이다.
반대로 기다리는 게 나은 사람도 있다. 회사 보안 정책이 엄격하거나, OAuth 권한 경계를 직접 확인하기 어렵거나, 기존 Obsidian vault가 이미 민감한 자료로 꽉 차 있거나, 베타 소프트웨어의 rough edge를 감당하기 싫다면 아직 메인 도구로 쓰지 않는 편이 안전하다.
내 추천은 sandbox-first다. 테스트 계정, 테스트 vault, 공개 repo, 샘플 문서로 2시간만 본다. 설치, 연결, 자동 수집, Markdown 생성, 검색, 삭제, 백업까지 한 번 돌려본다. 이 2시간에서 불안한 지점이 보이면 메인 계정 연결은 멈춘다. 반대로 흐름이 투명하고 내가 통제할 수 있다면 그때 범위를 넓힌다.
OpenHuman이 보여주는 방향은 분명하다. 개인 AI 에이전트는 채팅창을 넘어 내 자료를 계속 읽고, 정리하고, 기억하고, 작업 도구를 호출하는 쪽으로 간다. 그래서 더더욱 운영 기준이 필요하다. 기억력이 좋은 비서는 좋다. 그런데 무엇을 기억하면 안 되는지도 아는 비서가 더 좋다.
FAQ
Q. OpenHuman은 완전히 로컬에서만 동작하나?
README 기준으로는 아니다. Memory Tree, Obsidian-style Markdown vault, workspace config, local runtime state는 로컬에 저장된다고 설명하지만, 기본 managed experience는 account sign-in, model routing, web search proxying, OAuth/Composio 연동에 hosted backend를 사용한다고 안내한다.
Q. 118개 이상 OAuth 연동은 바로 써도 괜찮나?
바로 메인 계정을 연결하기보다 테스트 계정으로 시작하는 편이 안전하다. 어떤 데이터가 수집되는지, auto-fetch 로그가 남는지, 연결 해제와 데이터 삭제가 어떻게 되는지 확인한 뒤 범위를 넓히는 게 좋다.
Q. Obsidian 사용자는 무엇을 먼저 봐야 하나?
기존 vault와 분리되는지 먼저 봐야 한다. 자동 생성 Markdown이 어떤 폴더 구조와 파일명으로 저장되는지, 기존 노트를 수정하는지, 수동 편집 후 다시 ingest될 때 충돌이 없는지 확인해야 한다.
Q. TokenJuice는 왜 중요한가?
개인 자료는 이메일, 문서, 웹페이지처럼 장문이 많다. LLM에 그대로 넣으면 비용과 latency가 커진다. TokenJuice는 도구 출력과 문서를 압축해 모델 입력을 줄이려는 계층이다. 다만 실제 품질은 내 데이터로 직접 확인해야 한다.
Q. 회사에서 써도 되나?
바로 도입하기보다 보안, OAuth, 데이터 보존, hosted backend, GPL-3.0 license, 감사 로그를 먼저 검토해야 한다. 개인 실험과 회사 도입은 기준이 다르다. 회사 데이터는 호기심보다 정책이 먼저다.
함께 보면 좋은 글
- 프롬프트보다 로그가 먼저 보일 때 2026 – AI 에이전트가 실패하는 흔한 이유
- AI 자동화는 어디서 멈춰야 할까 2026 – 권한 비용 검수 3가지 기준
- Obsidian + Claude + Antigravity 연동 – 내 노트가 블로그로 자동 발행되는 파이프라인