Stanford Scaling Intelligence Lab
Apache 2.0 오픈소스
OpenJarvis, 88.7%를 로컬에서
처리한다는 수치 확인했습니다
“AI는 클라우드에 있어야 제대로 돌아간다”는 말, 사실 스탠퍼드 연구팀이 이미 수치로 뒤집어 놨습니다. 2026년 3월 12일 공개된 OpenJarvis는 단순한 로컬 챗봇이 아닙니다. 개인 기기 위에서 에이전트가 학습하고, 도구를 쓰고, 스스로 개선되는 구조를 담았습니다. 이 글에서는 공식 발표문과 arXiv 논문 수치를 직접 확인하면서, 실제로 어디까지 되고 어디서 막히는지 짚었습니다.
“클라우드가 없으면 AI가 제대로 안 된다”는 말이 흔들리는 순간
AI를 쓸 때마다 개인 파일, 메시지, 메모가 외부 서버를 오가는 구조에 불편함을 느낀 적 있다면, 이번 발표가 유독 눈에 띄었을 겁니다. 스탠퍼드 Scaling Intelligence Lab 연구팀은 2026년 3월 12일 OpenJarvis를 공개하면서, 이 불편함이 “기분”이 아니라 실제로 해결 가능한 공학 문제라고 선언했습니다.
💡 공식 발표문과 arXiv 논문(2511.07885)을 나란히 놓고 보면, 같은 수치가 완전히 다른 맥락에서 읽힙니다. 발표문에서 “88.7%”는 희망적 수치처럼 보이지만, 논문 원문에서는 “도메인별로 정확도가 다르다”는 단서가 명시돼 있습니다.
스탠퍼드 연구팀의 “Intelligence Per Watt” 연구 (arXiv:2511.07885, 2025.11~2026.02)에서 20개 이상의 최신 로컬 모델을 8종의 가속기에서 실제 쿼리 1백만 건에 테스트했습니다. 그 결과가 88.7%입니다. 이 수치는 “단일 턴 채팅 및 추론 쿼리”에 한정된 결과이며, 도메인에 따라 정확도 차이가 있다는 단서가 원문에 명시돼 있습니다. (출처: arXiv:2511.07885v3, 2026.02.26 업데이트)
다시 말해, 모든 AI 작업을 로컬에서 완전히 처리한다는 뜻이 아닙니다. 단순 대화와 추론 수준에서는 10번 중 9번 가까이 로컬로 해결이 된다는 의미로, 이게 실생활에서 갖는 함의는 상당합니다. 매달 나가는 API 비용과 응답 지연, 데이터 전송 이슈 중 상당 부분을 기기 안에서 처리할 수 있는 근거가 생긴 겁니다.
OpenJarvis가 기존 로컬 AI와 다른 지점
로컬에서 AI 모델을 돌리는 툴은 이미 많습니다. Ollama, LM Studio, llama.cpp 같은 이름들이 익숙하죠. 그런데 스탠퍼드 연구팀이 OpenJarvis에서 직접 지적한 문제가 있습니다. 기존 로컬 AI 프로젝트 대부분에서 “로컬 컴포넌트는 얇은 오케스트레이션 레이어”에 불과하고, 실제 추론은 여전히 외부 클라우드 API를 통해 처리된다는 점입니다. (출처: Stanford Scaling Intelligence Lab 공식 블로그, 2026.03.12)
💡 공식 발표문 원문과 기존 로컬 AI 프레임워크 생태계를 같이 놓고 보면 이런 차이가 보입니다. OpenClaw 계열 250,000 GitHub 스타를 자랑하는 프레임워크들도 실제로는 클라우드 API를 ‘두뇌’로 쓰고 있다는 점, 발표문은 이를 명시적으로 문제로 정의합니다.
솔직히 말하면, 이게 꽤 날카로운 지적입니다. 로컬에서 모델을 돌리는 것처럼 보여도, Anthropic이나 OpenAI API가 없으면 실제 작업이 안 되는 앱이 많습니다. OpenJarvis는 이 구조 자체를 바꾸겠다고 선언한 겁니다. 클라우드 호출은 “기본값”이 아니라 “선택지”로 밀어두는 것이 핵심입니다.
또 하나 중요한 차이점은 표준화된 추상 레이어입니다. 현재 로컬 AI 생태계는 모델 서버, 오케스트레이션, 메모리 저장소, 도구 인터페이스가 제각각입니다. 팀마다 스택을 처음부터 조립해야 하고, 서로 호환이 안 됩니다. OpenJarvis는 이 조각들을 Intelligence, Engine, Agents, Tools & Memory, Learning이라는 5개 공통 레이어로 정의해서 재사용이 가능하도록 만들었습니다.
5개 층이 맞물려 돌아가는 구조, 핵심만 짚으면
OpenJarvis는 5개의 독립적으로 교체 가능한 레이어로 구성됩니다. 각 레이어를 따로 벤치마킹하거나, 전체 시스템으로 함께 평가할 수 있다는 점이 연구 플랫폼으로서의 강점입니다.
| 레이어 | 역할 | 주요 지원 요소 |
|---|---|---|
| Intelligence | 모델 레이어 | Qwen, GPT-OSS, Gemma, Granite, GLM 등 통합 카탈로그 |
| Engine | 추론 런타임 | Ollama, vLLM, SGLang, llama.cpp, Apple Foundation Models |
| Agents | 행동 레이어 | Orchestrator(복잡 작업 분해), Operative(반복 워크플로) |
| Tools & Memory | 도구·메모리 연결 | MCP, Google A2A, 로컬 시맨틱 인덱싱, 26개+ 메시지 채널 |
| Learning | 자기 개선 루프 | SFT, LoRA, GRPO, DPO, DSPy 프롬프트 최적화, GEPA |
여기서 가장 눈에 띄는 레이어는 Learning입니다. 기존 로컬 AI가 “모델을 실행하는 것”에 그쳤다면, OpenJarvis는 실제 사용 내역(trace data)을 기반으로 모델 가중치, 프롬프트, 에이전트 로직, 추론 엔진까지 4개 층에 걸쳐 최적화가 일어납니다. `jarvis optimize` 명령어 하나로 이 과정을 시작할 수 있습니다. (출처: Stanford OpenJarvis 공식 문서, 2026.03.12)
Engine 레이어도 실용적입니다. `jarvis init`을 실행하면 현재 기기의 하드웨어를 자동 감지해서 어떤 추론 엔진과 모델 조합이 맞는지 추천해줍니다. M 시리즈 맥북이면 Apple Foundation Models 백엔드가, NVIDIA GPU라면 vLLM이 올라오는 식입니다. `jarvis doctor`는 설정 상태를 점검하는 명령어입니다.
에너지가 왜 AI 성능 지표가 됐나
로컬이 클라우드보다 느리다고만 알고 있었다면
기대했던 것과 달랐던 수치가 하나 있습니다. 로컬 가속기는 동일 모델을 실행할 때 클라우드 가속기보다 최소 1.4배 낮은 IPW(Intelligence Per Watt)를 기록합니다. 즉 에너지 효율이 더 높다는 뜻입니다. IPW는 정확도(task accuracy)를 전력 소비(watt)로 나눈 값으로, 스탠퍼드 연구팀이 직접 정의한 지표입니다. (출처: arXiv:2511.07885v3)
📊 IPW(Intelligence Per Watt) 수치 직접 확인
$$\text{IPW} = \frac{\text{Task Accuracy}}{\text{Power (Watt)}}$$
• 로컬 가속기: 클라우드 동일 모델 대비 최소 1.4× 낮은 전력 소비
• 2023→2025 전체 IPW 향상: 5.3×
• 같은 기간 로컬 처리 가능 쿼리 비율: 23.2% → 71.3%
(출처: arXiv:2511.07885v3, 2026.02.26 업데이트)
이 수치가 의미하는 바를 한 문장으로 정리하면 이렇습니다. 2023년에는 로컬 AI가 쿼리 4개 중 1개 정도만 처리할 수 있었는데, 2025년에는 이미 10개 중 7개를 커버하게 됐습니다. 클라우드 AI가 발전하는 동안, 로컬 AI도 그 이상의 속도로 효율이 올라간 겁니다.
OpenJarvis는 이 에너지 지표를 프레임워크 안에 기본으로 내장했습니다. NVIDIA GPU(NVML), AMD GPU, Apple Silicon(powermetrics)에서 50ms 간격으로 전력 소비를 측정하고, `jarvis bench` 명령어로 지연, 처리량, 쿼리당 에너지를 표준화된 방식으로 비교할 수 있습니다. 배터리로 동작하는 노트북에서 AI를 돌릴 때 에너지가 단순 참고 지표가 아니라 설계 제약 조건이 된다는 점을 반영한 구조입니다.
OpenAI API 코드를 그대로 쓸 수 있다는 말, 진짜입니다
마이그레이션 비용이 0에 가까운 이유
개발자 관점에서 OpenJarvis에서 실용적으로 눈길을 끄는 기능이 있습니다. `jarvis serve` 명령어가 FastAPI 서버를 SSE 스트리밍으로 실행하는데, 이게 OpenAI 클라이언트와의 드롭인 교체(drop-in replacement)로 설계돼 있다는 점입니다. (출처: OpenJarvis 공식 문서, open-jarvis.github.io, 2026.03.12)
# 설치 → 초기화 → 바로 실행
pip install openjarvis jarvis init # 하드웨어 자동 감지 + 엔진 추천 jarvis doctor # 설정 검증 jarvis ask "오늘 일정 요약해줘" # 즉시 사용 jarvis serve # OpenAI 호환 API 서버 실행
이게 왜 중요하냐면, 기존에 ChatGPT API나 Claude API로 만든 앱이 있다면 엔드포인트 주소 하나만 바꿔서 OpenJarvis 로컬 서버로 전환이 됩니다. 코드를 새로 짤 필요가 없습니다. 이 부분은 단순 홍보 문구가 아니라 공식 문서에서 “OpenAI 클라이언트의 drop-in replacement”라고 명시한 내용입니다.
인터페이스도 선택지가 넓습니다. CLI, 브라우저 대시보드, macOS·Windows·Linux 데스크탑 앱, Python SDK까지 4가지 방식으로 접근할 수 있습니다. Python SDK에서는 Jarvis() 객체와 ask(), ask_full() 메서드를 제공합니다. 네트워크 연결 없이 모든 핵심 기능이 작동하는 것도 공식 문서에서 확인된 내용입니다.
막상 써보면 이 조건에서 걸립니다
88.7%가 커버 못 하는 11.3%가 어디냐면
솔직하게 짚어야 할 부분이 있습니다. 공식 발표문에서도 “로컬 컴포넌트가 클라우드를 완전히 대체한다”고는 말하지 않습니다. 연구팀 자체 표현도 “클라우드를 선택적으로만 호출”이지, “클라우드 없이 모든 걸 처리”가 아닙니다.
⚠️ 현실적 제한 — 공식 문서 기준
- 88.7% 수치는 단일 턴(single-turn) 채팅·추론 쿼리 기준이며 도메인별 편차 존재 (확인: arXiv:2511.07885)
- 멀티 턴 장기 세션, 멀티모달 처리 능력은 공식 수치로 공개된 데이터 없음 (확인 필요)
- Learning 레이어(로컬 학습)는 상당한 저장 공간과 추론 전력을 추가로 요구함
- Apple Silicon 외 저사양 기기에서의 실측 성능 데이터는 아직 제한적
- 오픈소스 초기 릴리즈이므로 엔터프라이즈 수준 안정성은 미확인
여기서 걸리는 또 하나의 현실적인 문제는 하드웨어 요건입니다. 공식 문서에서 `jarvis init`이 하드웨어를 자동 감지한다고 하지만, 8GB RAM 기기에서 9B 모델을 돌렸을 때 실측 속도가 토큰당 3.9개/초 수준에 그쳤다는 커뮤니티 실험 사례가 있습니다 (LocalLLaMA 스레드, 2026.03.13 — Apple A18 Pro, MacBook Neo 기준). 이 수치는 실용적 속도로 쓰기에는 부족한 편입니다.
결론부터 말씀드리면, M2 Pro 이상 또는 NVIDIA RTX 3060 이상의 기기에서 효율이 올라가고, 그 이하에서는 모델 크기를 더 줄이거나 클라우드 폴백을 활용해야 합니다. OpenJarvis 자체가 이 “하이브리드 폴백” 구조를 공식 지원하기 때문에, 저사양 기기라고 해서 쓸 수 없다는 뜻은 아닙니다. 다만 기대치를 조정해야 합니다.
자주 묻는 것들
Q1. OpenJarvis 설치에 GPU가 반드시 필요한가요?
필수는 아닙니다. `jarvis init`이 현재 기기의 하드웨어를 자동 감지해서 적합한 모델과 백엔드를 추천해줍니다. CPU 전용 기기에서도 작동은 하지만, 속도는 실용 수준에 못 미칠 수 있습니다. M2 Pro 이상(Apple Silicon)이나 VRAM 8GB 이상의 NVIDIA GPU 환경에서 체감 차이가 납니다. (출처: OpenJarvis 공식 문서)
Q2. 기존에 ChatGPT API로 만든 앱을 OpenJarvis로 전환할 수 있나요?
`jarvis serve`를 실행하면 OpenAI 클라이언트 호환 API 서버가 로컬에 뜹니다. 엔드포인트 주소만 바꾸면 기존 코드를 그대로 쓸 수 있도록 설계돼 있습니다. 이 부분은 공식 문서에서 “drop-in replacement for OpenAI clients”로 명시돼 있습니다. (출처: open-jarvis.github.io)
Q3. Learning 레이어가 개인 데이터를 외부로 보내지 않는다는 걸 어떻게 확인하나요?
OpenJarvis는 Apache 2.0 오픈소스이므로 소스 코드를 직접 확인할 수 있습니다. 공식 블로그에서도 “모든 저장과 제어는 기기 안에서 로컬로 유지된다(keeping storage and control local by default)”고 명시합니다. 단, 클라우드 폴백 기능을 사용할 경우 해당 요청은 외부로 전송됩니다. 이 구분을 설정에서 명시적으로 제어할 수 있습니다. (출처: Stanford Scaling Intelligence Lab 블로그, 2026.03.12)
Q4. 88.7% 쿼리 처리 수치는 어떤 기준인가요?
arXiv:2511.07885 논문 기준으로, 20개 이상의 로컬 모델을 8종의 가속기에서 실제 단일 턴 채팅·추론 쿼리 100만 건에 테스트한 결과입니다. “단일 턴”이라는 제한이 있으며, 멀티 턴 대화나 멀티모달 쿼리는 포함되지 않습니다. 도메인별로 정확도 편차가 있다고 원문에 명시돼 있습니다. (출처: arXiv:2511.07885v3)
Q5. Windows에서도 쓸 수 있나요? 맥이나 리눅스만 지원하는 건 아닌가요?
공식 문서 기준으로 macOS, Windows, Linux 모두 지원합니다. 데스크탑 앱(Tauri 기반)은 세 플랫폼에서 모두 사용 가능합니다. 단, 에너지 측정 기능은 플랫폼마다 지원 방식이 다릅니다. Apple Silicon은 powermetrics, NVIDIA GPU는 NVML, AMD GPU는 별도 경로를 씁니다. (출처: OpenJarvis 공식 문서, 2026.03.12)
마치며 — 지금 당장 쓰는 분과 아닌 분의 기준
OpenJarvis는 “로컬 AI를 한번 돌려본다”는 수준을 넘습니다. 5개 레이어가 표준화된 방식으로 맞물려 있고, 에너지 효율을 측정 지표로 내장하고, OpenAI 호환 API 서버까지 제공합니다. 스탠퍼드 Hazy Research와 Scaling Intelligence Lab이 만든 인프라인 만큼, 연구 플랫폼으로서의 완성도는 높습니다.
생각보다 간단하게 시작할 수 있고, 생각보다 빠르게 실용적인 조건에 닿습니다. 다만 Learning 루프와 멀티 턴 처리에서 아직 공개된 실측 데이터가 부족한 건 사실입니다. 지금 당장 프로덕션 용도로 쓰기엔 이른 부분이 있지만, 개인 데이터를 클라우드에 보내지 않고 AI를 쓰고 싶다는 요구에 가장 구체적인 대안을 제시한 프레임워크입니다.
가장 쉬운 진입 방법은 공식 GitHub에서 pip install openjarvis를 실행하고 `jarvis init`을 해보는 겁니다. ENERGY 리더보드 1위에게는 맥 미니를 증정하는 이벤트도 현재 진행 중입니다 — 이건 공식 발표문에서 직접 확인한 내용입니다.
본 포스팅 참고 자료
- Stanford Scaling Intelligence Lab 공식 블로그 — OpenJarvis 발표문
https://scalingintelligence.stanford.edu/blogs/openjarvis/ - arXiv:2511.07885 — Intelligence Per Watt 논문 (v3, 2026.02.26)
https://arxiv.org/abs/2511.07885 - OpenJarvis GitHub 공식 저장소
https://github.com/open-jarvis/OpenJarvis - OpenJarvis 공식 문서
https://open-jarvis.github.io/OpenJarvis/ - MarkTechPost 기술 분석 — Stanford Researchers Release OpenJarvis (2026.03.12)
https://www.marktechpost.com/2026/03/12/…
※ 본 포스팅은 2026년 3월 19일 기준으로 작성됐습니다. OpenJarvis는 오픈소스 초기 릴리즈이며, 본 포스팅 작성 이후 서비스 정책·UI·기능·지원 모델이 변경될 수 있습니다. 수치 및 사양은 각 출처 원문을 직접 확인하시기 바랍니다.
댓글 남기기