자비스 OS 개인 AI 비서 프로젝트 상세 조사

#자비스 OS 개인 AI 비서 프로젝트 상세 조사

조사 대상: battlesbudz/jarvis-os. 사용자가 ‘개인 AI 비서 프로젝트’라고 지정한 범주와 설명이 일치하는 저장소를 대상으로 삼았다. 동명의 Linux 운영체제 연구 프로젝트와 구분한다.

조사일: 2026년 9월 16일. 공개 문서·릴리스·개발 이슈를 조사했으며 실제 설치, 실행 성능 측정, 보안 감사는 수행하지 않았다. 검색 도구가 제공한 자료에는 수일~수개월 전 수집본이 섞여 있으므로, 수치·이슈 상태·배포 버전은 조회된 자료의 상태로 해석해야 한다.

#1. 중요 — 어떤 프로젝트이고 무엇을 주목해야 하는가

#개인 비서를 운영하는 통합 소프트웨어

Jarvis OS는 사용자가 직접 호스팅할 수 있는 개인 AI 비서 시스템이다. 기억과 계획, 모델 선택, 도구 실행, 백그라운드 작업, 결과 검토, 계정·기기 연결을 한곳에 묶는다. 여기서 OS는 개인 AI의 운영 환경을 뜻한다. Windows나 macOS를 대체하는 부팅용 운영체제로 설명되어 있지는 않다. 공식 소개

조사 판단: 이 프로젝트의 가치는 대화 모델 하나보다, 요청을 실제 작업으로 바꾸고 진행 상태와 결과를 남기는 전체 흐름에 있다. 완성된 소비자 제품을 바로 쓰려는 사람보다, 자신의 비서를 구성하고 운영하려는 사람에게 검토 가치가 크다.

#핵심 기능 범위

아래는 개발자가 공식 README에 구현되어 있다고 명시한 범위다. 본 조사에서 동작을 재현했다는 뜻은 아니다.

채널마다 인증 설정이 필요하며, 자체 호스팅은 아직 원클릭 방식이 아니다. 기능 및 구현 상태

#이름이 비슷한 프로젝트와의 구분

이름만으로 자료를 합치면 Linux 커널 기능을 개인 비서의 기능으로 오인할 수 있다. 설치·라이선스·보안 정보는 반드시 저장소 소유자까지 확인해야 한다.

#2. 정확 — 구조, 설치, 구현 상태와 한계

#2.1 시스템 구조

공식 아키텍처는 사용자 화면, 서버, 모델 라우팅, 에이전트 실행, 기억, 작업, 승인, 외부 도구를 구분한다. 서버는 Express, 데이터 접근은 Drizzle, 저장소는 PostgreSQL을 사용하며, 클라이언트는 Expo 앱과 Next.js 대시보드로 나뉜다. 아래 그림은 해당 문서를 단순화한 것이다. 아키텍처 문서

flowchart TD
    U[사용자 요청] --> C[앱 · 대시보드 · 메신저]
    C --> S[Express 서버]
    S --> R[모델 선택 · 문맥 구성]
    R --> A[에이전트 실행]
    A --> M[기억 · SOUL · G-Brain]
    A --> J[백그라운드 작업 · 결과물]
    A --> P[승인 · 실행 기록]
    A --> T[도구 · 외부 서비스]
    T --> D[데스크톱 · Android 연결]
    S --> DB[(PostgreSQL)]
    M --> DB
    J --> DB
    P --> DB

공식 문서는 거대한 라우트 파일과 폭넓은 에이전트 폴더를 향후 정리할 대상으로도 언급한다. 따라서 구조가 문서화되어 있다는 점과 내부 정리가 완료되었다는 점은 구분해야 한다. 구조 및 개선 과제

#2.2 기억과 지식 관리

README는 GBrain에서 영향을 받은 기억·지식 관리 계층을 소개한다. 다만 세부 설계 문서의 본문은 이번 조사 도구로 확보하지 못했으므로, 특정 그래프 알고리즘이나 기억 정확도까지 확정할 수 없다. 프로젝트 소개

공식 문서 색인은 다음 자료를 구분한다.

• gbrain-implementation-plan.md: G-Brain 파생 지식 계층의 구현 계획.
• gbrain-spec-sheet.md: 테이블, 연결 계층, 투영, 검색, 유지보수의 설계 규약.
• memory-os-temporal-graph-plan.md: 더 넓은 Memory OS와 시간 기반 그래프 계획.

해석: 대화 기록, 장기 기억, 기억에서 파생한 지식 노트를 구분하려는 설계 방향은 확인된다. 그러나 계획 문서가 있다는 사실만으로 모든 기능이 출시되었다고 볼 수는 없다. 공식 문서 색인

기여 문서는 기억·SOUL·검색·기억 검토 변경 시 관련 테스트를 실행하고 데이터베이스 요구 조건을 명시하도록 한다. 이는 기억의 일관성을 중요한 유지보수 대상으로 취급한다는 근거다. 실제 기억 보존율이나 오류 수정 성공률을 보여주는 독립 측정치는 이번에 확보하지 못했다. 기여 가이드

#2.3 작업의 실행과 결과 전달

운영 문서는 준비 상태 점검 후 요청을 분류하고, 간단한 요청은 즉시 응답하며, 여러 단계의 작업은 대기열로 보내고, 결과를 Inbox나 결과물 화면에 노출하는 흐름을 설명한다. 진단 도구는 환경이 차단 상태인지, 일부 기능만 제한되는지 구분하도록 설계되어 있다. 운영 가이드

활용 예시 — 조사자의 설명: “자료를 조사해 보고서를 만들어 줘”라는 요청에서는 접수 응답, 실제 조사 작업, 완성 보고서가 서로 다른 상태가 된다. 사용자 입장에서는 대화가 끝났다는 이유만으로 작업까지 완료되었다고 생각하지 않도록, 결과물의 존재와 작업 상태를 함께 확인하는 것이 중요하다.

진행 화면 개선안인 이슈 #266은 대화·음성·프로젝트·Inbox·Mission Control에서 동일한 작업 ID와 진행 상태를 일관되게 보여주는 Live Action Card를 제안한다. 취소·재시도·재개·결과물 열기를 공통 표현으로 묶고, 재접속 시 중복 카드나 상태 역행을 방지하려는 계획이다. 조회된 페이지에서는 Open 상태였다. Live Action Card 개발 이슈

#2.4 음성·모바일·웨어러블의 현재와 계획

음성 로드맵 #280은 계속 대화하면서 뒤에서 도구 작업을 수행하고, 응답 도중 말을 끊을 수 있는 경험을 목표로 한다. 음성 출력 중지, 듣기 중지, 실제 작업 취소를 별개로 취급한다. 기존 앱 음성 루프와 Android 음성 기반 작업은 선행 작업으로 언급되지만, 연속 음성 전체 계획은 조회본에서 Open이었다. 연속 음성 로드맵

실기기 검증 이슈 #286에는 다음 항목이 남아 있다.

이 목록은 합격 결과가 아니라 검증해야 할 수용 기준이다. 범용 웨어러블 지원이나 안정적인 상시 음성 비서가 이미 완성되었다고 해석하면 안 된다. 실기기 수용 기준

#2.5 보안 문서와 새 승인 방식의 차이

기존 SECURITY.md는 이메일 발송, 일정 변경, 외부 게시, 구매, 배포, 기기 제어, 기억 변경 등을 승인과 기록이 필요한 작업으로 분류한다. 자체 호스팅 운영자는 비밀키 관리, HTTPS, 접근 폴더 제한, 제공자 지출 한도, 기기 권한을 관리해야 한다. 데스크톱 접근 루트는 홈 폴더 전체보다 특정 작업 폴더로 제한하도록 안내한다. 보안 정책

반면 2026년 8월 17일 생성된 이슈 #269는 인증된 사용자의 명확한 명령을 하나의 제한된 실행 권한으로 취급해 같은 작업을 다시 승인받는 절차를 줄이려 한다. 제안된 권한은 범위·만료·취소·실행 이력을 가지며, 재시도가 외부 행동을 중복 발생시키지 않도록 설계된다. 지속적인 실행 허용 범위를 AI가 스스로 만들 수 없도록 하고, 사용자별·전체 긴급 중지도 요구한다. 금융 거래에는 해당 거래를 특정한 현재의 명시적 명령을 요구한다. Trusted Execution 계획

조사 판단: 승인 정책은 전환 중인 것으로 보는 편이 타당하다. 기존 문서는 현재의 운영 원칙을, 새 이슈는 변경하려는 제품 규약을 설명할 수 있다. 두 자료를 합쳐 “모든 행동이 항상 이중 승인된다”거나 “모든 기능이 이미 재확인 없이 실행된다”고 단정할 수 없다. 실제 사용할 버전에서 정책과 실행 결과가 일치하는지 확인해야 한다.

또한 자체 호스팅은 모든 데이터의 로컬 처리를 보장하는 말이 아니다. 선택한 모델 제공자, 메시징 서비스, 호스팅 구성에 따라 외부 전송 경로가 생길 수 있다. 이는 공개된 구성요소와 연결 구조에 근거한 해석이다. 구조 문서

#2.6 설치 조건과 시작 순서

공식 자체 호스팅 문서의 요구 사항은 Node.js 22.x, npm 10.x, PostgreSQL 16 이상, Git, 사용 가능한 모델 제공자 연결이다. 서버 기본 주소는 http://localhost:5000, 대시보드는 http://localhost:3001이다. 자체 호스팅 안내

다음은 설치 흐름 요약이며, 이 조사에서 실행한 명령은 아니다.

git clone https://github.com/battlesbudz/jarvis-os.git
cd jarvis-os
npm install
cp .env.example .env

데이터베이스 생성 후 .env에 아래 값을 설정한다.

npm run db:push
npm run server:dev

별도 터미널에서 앱과 대시보드를 시작한다.

# 앱: 저장소 루트
npm run expo:dev

# 대시보드: 별도 터미널
cd dashboard
npm install
npm run dev

기본 설정이 된 후 진단·테스트·빌드를 확인한다. 설치 및 검증 절차

# 저장소 루트에서 실행
npm run jarvis:doctor
npm test
npm run server:build
npm --prefix dashboard run build

문서상 DB 테스트는 별도 테스트 데이터베이스를 지정하지 않으면 건너뛸 수 있다. 따라서 테스트 통과 메시지만으로 DB를 포함한 전체 동작이 검증됐다고 판단하면 안 된다. 테스트 조건

Railway 배포 문서는 Node 22와 Railpack을 사용하고, 데이터베이스 주소를 저장소에 넣지 않고 서비스 환경변수로 관리하도록 설명한다. Node 버전 감지가 틀리면 RAILPACK_NODE_VERSION=22로 지정하는 방법을 제시한다. Railway 안내

#2.7 배포물과 지원 플랫폼

조회된 릴리스 페이지에는 아래 배포물이 있었다. 수집 시점이 오래된 페이지이므로 2026년 9월의 최신 버전 목록으로 보증하지 않는다.

앱 APK의 릴리스 설명에는 프로젝트 측 서버 주소가 지정되어 있었다. APK를 설치하는 것과 자신의 서버로 자체 호스팅하는 것은 별도 문제다. 서버 주소 설정과 빌드 구성을 확인해야 한다. Android Daemon은 서버 URL과 페어링 코드를 이용한 연결을 안내한다. 공식 릴리스

Mac 사용자 관점: 이번에 확인한 배포물만으로 macOS 데스크톱 제어 커넥터가 완성되어 있다고 말할 수 없다. 웹 화면 접근 가능성과 Mac의 파일·앱을 직접 제어하는 기능은 나누어 평가해야 한다. iOS 역시 앱 개발 기반의 존재와 실제 배포·기기 제어 지원은 별개다.

#2.8 라이선스, 비용, 유지보수

라이선스 파일은 MIT이며 저작권 표기는 2026 battlesbudz다. 라이선스 원문

고정 월요금이나 공식 최소 운영 예산은 확보하지 못했다. 운영비는 다음처럼 분해해 계산하는 것이 적절하다. 아래는 요금표가 아닌 조사자의 비용 산정 틀이다.

월 운영비 = 서버 + 데이터베이스·백업 + 모델·임베딩 호출 + 선택적 음성 처리 + 외부 서비스 + 유지보수 시간

특히 “직접 호스팅하니 무료”라는 가정은 피해야 한다. 조사·장기 기억 추출·반복 작업이 늘어나면 호출량과 저장량을 함께 측정해야 한다. 호스팅 규모와 실제 사용 모델이 정해지지 않아 금액은 임의로 제시하지 않는다.

기여 가이드는 제공자 선택, 기기 연결, 기억, 승인 정책 등 영역별 검증을 구분한다. 개발 참여자가 참고할 테스트 경로는 존재하지만, 테스트 목록만으로 보안 감사나 장기간 안정성 검증을 대체할 수는 없다. 기여 및 검증 안내

#2.9 확인 수준과 미확인 사항

ROADMAP.md, JARVIS_ROADMAP.md, 일부 기억 설계 문서와 PR 본문은 접근에 실패했다. 대신 직접 읽을 수 있었던 공식 문서와 이슈 본문으로 범위를 제한했다. 검색 결과의 별 수 등도 수집본 사이에 차이가 있어 실시간 수치처럼 제시하지 않는다.

#3. 빈도 — 공개 활동과 반복되는 개발 과제

#3.1 활동은 확인되지만 확산 규모는 불명확

2026년 8월 17~18일에 작성된 공개 이슈들에서 승인 체계, 음성 대화, 백그라운드 실행, 진행 표시를 개선하려는 활동이 확인된다. PR 목록 조회본에는 8월 28일 생성된 Trusted Execution 관련 #292도 나타났다. 이는 최근 개발 작업이 있었다는 근거지만, 현재 병합 여부나 전체 출시 완료를 뜻하지 않는다. 이슈 목록, PR 목록

사용자 수, 설치 수, 장기 활성 사용자, 독립적인 성능 비교 자료는 확보하지 못했다. 공개 저장소가 존재하고 개발 기록이 많다는 점을 대중적 검증과 동일시해서는 안 된다.

#3.2 문서에서 반복되는 네 가지 문제

이는 문서들의 정성적 비교이며, 업계 전체 언급 빈도를 통계로 측정한 결과는 아니다. 권한 체계, 음성 계획, 상태 표시, 장애 검증

#3.3 국내 정보 확인 결과

해외 공식 자료 확인 후 battlesbudz/jarvis-os 한국, Jarvis OS 개인 AI 비서 등의 검색으로 국내 자료를 추가 확인했다. 이번 검색 범위에서는 해당 저장소를 구체적으로 검증한 국내 공식 자료나 독립적인 장기 사용 후기를 확보하지 못했다.

일반적인 ‘자비스형 비서’, 다른 OpenJarvis 프로젝트, 개인 AI 제품에 관한 글은 이 저장소의 기능 증거로 사용하지 않았다. 국내 인지도나 한국어 사용자 기반에 관해서는 판단을 유보한다.

#4. 추천 — 개인 비서 구축에 어떻게 활용할 것인가

#4.1 적합한 목적

아래는 앞선 자료에 근거한 조사자의 제안이다.

프로젝트 전체를 곧바로 자신의 생산성 환경으로 옮기기보다, 실제 반복 업무 하나가 끝까지 성공하는지를 먼저 확인하는 편이 판단에 도움이 된다.

#4.2 최소 검증 시나리오

1. 대화: 선택한 모델로 한국어 요청과 응답이 정상 작동하는지 확인한다.
2. 기억: 테스트용 선호를 저장하고 새 대화에서 조회한 뒤 수정·삭제 결과를 확인한다.
3. 백그라운드 조사: 짧은 조사 요청을 맡겨 완료된 문서를 실제로 받을 수 있는지 확인한다.
4. 복구: 진행 중 화면을 닫거나 다시 연결해 작업과 결과가 중복되지 않는지 살핀다.
5. 채널: 자주 쓰는 메신저 하나만 연결해 같은 사용자와 작업으로 이어지는지 확인한다.
6. 권한: 허용한 폴더·기기·계정 범위가 실제 행동에 반영되는지 확인한다.

평가 기록에는 응답 시간, 결과물 확보 여부, 기억 수정 반영 여부, 실패 원인, API 사용량을 남긴다. 문서의 기능 목록보다 이 결과가 개인에게 적합한지 판단하는 데 직접적인 근거가 된다.

#4.3 Obsidian과 연결하려는 경우

처음에는 테스트 노트만 들어 있는 별도 폴더로 다음 흐름을 검증하는 방안을 제안한다.

노트 읽기 → 출처가 있는 요약 → 별도의 결과 파일 생성 → 사람이 검토

이 제안은 현재 Obsidian 연결 기능이 내장되어 있다는 주장이 아니다. 연결 방식을 추가로 확인하거나 구현해야 할 수 있다. 특히 원본 노트와 AI가 만든 파생 기억을 구분하고, 어떤 문장에서 기억이 추출됐는지 추적할 수 있어야 한다.

기존 개인 자비스 기획과 연결해서 읽을 자료:

• Jarvis 구축 프로젝트 — 실행 가능성과 필요성 판단

#4.4 최종 판단

Jarvis OS는 개인 비서를 구성하는 여러 요소를 한 시스템으로 연결하려는 참고 프로젝트로 가치가 있다. 동시에 음성의 연속성, 실행 권한 통합, 작업 상태 표시처럼 일상 사용의 신뢰도를 결정하는 부분은 공개 개발 과제로 남아 있다.

구조와 설치 요구 조건에 대한 판단 신뢰도는 비교적 높다. 실제 안정성·한국어 경험·Mac 직접 제어·월 운영비는 별도 시험이 필요하다. 도입 여부를 결정할 때는 기능의 수보다 자신의 반복 업무 한 가지에 대한 성공률과 유지보수 부담을 기준으로 삼는 것이 좋다.

#5. 참조 사이트

아래는 본문 작성에 사용한 주요 1차 자료다. 확인 날짜는 모두 2026-09-16이며, 페이지별 웹 수집 시점은 서로 다르다.

조사 한계: 문서 간 비교는 했으나 근거 대부분은 동일 프로젝트가 발행한 자료다. 독립 기관의 평가나 실제 운영 시험에 의해 기능·안전성·성능이 교차 검증된 보고서로 해석해서는 안 된다.