기술 요약: OPENJARVIS – 분해형 종단간 최적화 가능 개인 AI 스택

1. 문제 제기

개인 AI 스택 (예: OpenClaw, Hermes Agent) 은 일상 업무 흐름의 핵심이 되었으나, 현재 거의 전적으로 클라우드 호스팅된 최첨단 모델에 의존하고 있습니다. 이 아키텍처는 네 가지 치명적인 문제를 야기합니다:

1. 개인정보 보호: 쿼리에 종종 민감한 로컬 데이터가 포함되어 제 3 자 서버로 전송됩니다.
2. 비용: API 및 구독 비용이 반복적으로 발생하여 중량 사용자의 경우 연간 수천 달러에 달합니다.
3. 의존성: 사용자는 모델에 대한 소유권이 없으며 지속적인 네트워크 연결이 필요합니다.
4. 에너지: 클라우드 추론은 로컬 실행보다 토큰당 에너지 소비량이 수배 더 많습니다.

소비자용 하드웨어가 이제 최첨단 모델보다 개인 AI 작업에서 불과 612 개월 뒤처지는 오픈 가중치 모델 (1B128B 파라미터) 을 지원하지만, 기존 클라우드 설계 스택에 로컬 모델을 단순히 대체하는 것은 실패합니다. 실험 결과, OpenClaw 나 Hermes Agent 와 같은 프레임워크 내에서 클라우드 모델 (예: Claude Opus 4.6) 을 로컬 모델 (예: Qwen3.5-9B) 로 대체할 경우 정확도가 25~39 퍼센트 포인트 (pp) 하락하는 것으로 나타났습니다.

근본 원인은 기존 스택이 단일화 (monolithic) 되어 있기 때문입니다: 에이전트 프롬프트, 도구 설명, 메모리 구성, 런타임 설정이 특정 클라우드 모델을 위해 공동 설계되어 융합되어 있습니다. 기존 최적화 방법 (예: GEPA 나 DSPy 와 같은 프롬프트 최적화 도구) 은 프롬프트 원시 (primitive) 만 튜닝할 수 있어 격차의 불과 5 pp만 해소합니다. 단일 원시를 고립적으로 최적화하는 것은 전체 스택에 걸친 불일치를 해결할 수 없습니다.

2. 방법론: OPENJARVIS 아키텍처

로컬 모델이 클라우드 시스템과 경쟁할 수 있도록 하기 위해, 저자들은 개인 AI 시스템을 다섯 가지 유형화되고 독립적으로 편집 가능한 원시로 분해하는 아키텍처인 OPENJARVIS를 제안합니다.

2.1 명세 추상화 (Spec Abstraction)

OPENJARVIS 는 개인 AI 시스템을 다섯 가지 원시로 구성된 **유형화된 명세 (typed specification, spec)**로 표현합니다:

1. 지능 (Intelligence): 언어 모델 아키텍처, 가중치, 생성 파라미터.
2. 엔진 (Engine): 추론 런타임, 하드웨어 실행 경로, 배치 및 양자화 설정.
3. 에이전트 (Agents): 추론 루프, 프롬프트, 도구 사용 정책.
4. 도구 및 메모리 (Tools & Memory): 외부 인터페이스, 검색 메커니즘, 영구 사용자 상태.
5. 학습 (Learning): 트레이스 (예: LoRA, 프롬프트 최적화 도구, 또는 제안된 검색 알고리즘) 에서 시스템을 업데이트하는 최적화기.

이 분해는 전체 스택을 단일 최적화 가능 객체로 취급하게 하여 모든 구성 요소를 자유도로 노출시킵니다.

2.2 LLM 기반 명세 검색 (LLM-Guided Spec Search)

핵심 최적화 알고리즘은 LLM 기반 명세 검색으로, 로컬과 클라우드의 협업을 통해 네 가지 편집 가능한 원시 (지능, 엔진, 에이전트, 도구 및 메모리) 를 공동 최적화하면서 학습 원시를 사용하여 이 과정을 주도합니다.

• 검색 시간 (클라우드): 최첨단 클라우드 모델 ("교사") 은 반성적 제안자 역할을 합니다. 현재 로컬 명세에서 실행 트레이스를 분석하고, 실패 군집 (예: "학생이 다중 홉 캘린더 조회에서 실패함") 을 진단한 후, 여러 원시에 걸쳐 동시에 조정된 편집을 제안합니다 (예: 도구 설명을 다시 작성하고 동시에 런타임 설정을 조정).
• 추론 시간 (로컬): 결과적으로 최적화된 명세는 기기 내에서 완전히 실행됩니다. 추론 시 클라우드 모델은 관여하지 않습니다.
• 게이트 (The Gate): 성능 저하를 방지하기 위해 "게이트" 메커니즘은 특정 실패 군집에서 성능을 향상시키되 다른 군집에서 허용할 수 없는 후퇴 (허용 오차 $\epsilon$로 정의됨) 를 초래하지 않는 경우에만 편집을 승인합니다.
• 공동 최적화: 단일 원시 최적화기와는 달리, 이 방법은 단일 편집이 여러 원시에 걸쳐 확장되도록 하여 결합된 효과 (예: 새로운 프롬프트 구조에 맞춰 모델 가중치를 업데이트) 를 포착합니다.

3. 주요 기여

1. OPENJARVIS 아키텍처: 개인 AI 를 다섯 가지 유형화된 원시로 분해하여 스택을 종단간 최적화 가능하게 만들고, 정확도, 비용, 지연 시간과 관련하여 측정 가능하게 하는 새로운 프레임워크.
2. LLM 기반 명세 검색: 검색 시 최첨단 클라우드 모델을 활용하여 로컬 명세에 대한 편집을 제안하는 검색 알고리즘으로, 단일 원시 기준 대비 7~11 배 낮은 최적화 비용으로 로컬 - 클라우드 정확도 격차를 13~32 pp 해소합니다.
3. 파레토 최적 로컬 구성: 최적화된 온디바이스 명세가 8 개 벤치마크 중 4 개에서 클라우드 정확도와 일치하거나 이를 초과하며, 한계 API 비용을 약 800 배 줄이고 종단간 지연 시간을 4 배 단축한다는 실증적 증거.
4. 종합 분석: 제안자(LLM 진단 대 진화/무작위 검색) 와 이동 공간 (move space)(네 가지 원시 전체 최적화 대 단일 원시 최적화) 모두에서 성취가 도출되었음을 보여주는 제거 연구 (ablation study).

4. 실험 결과

저자들은 8 개 벤치마크(PinchBench, GAIA, LiveCodeBench, DeepResearchBench 포함), 4 개 계열의 11 개 로컬 모델, 그리고 7 개 하드웨어 플랫폼에 걸쳐 OPENJARVIS 를 평가했습니다.

• 이식성 회복: 단순히 로컬 모델을 클라우드 프레임워크로 교체하면 정확도가 2439 pp 하락합니다. 동일한 로컬 모델로 OPENJARVIS 명세를 사용할 경우 이 하락분의 **5677%**를 회복하여 잔여 격차를 5.6~16.5 pp로 줄입니다.
• 클라우드 대비 정확도: 가장 우수한 단일 온디바이스 명세 (Qwen3.5-122B) 는 평균 정확도 **80.3%**를 달성하여 최상위 클라우드 기준 (Claude Opus 4.6, 83.5%) 과 3.2 pp 차이 내에 있습니다. 8 개 벤치마크 중 4 개에서 최상위 로컬 모델은 클라우드 성능과 일치하거나 이를 초과합니다.
• 효율성 향상: 로컬 구성은 클라우드 기준 대비 한계 API 비용을 약 800 배 줄이고 종단간 지연 시간을 4 배 단축합니다.
• 검색 효과성:
  • LLM 기반 명세 검색은 벤치마크 전반에 걸쳐 로컬 모델을 13~32 pp 향상시켰습니다.
  • 편집 가능 집합을 프롬프트만으로 네 가지 원시 전체로 확장하면 5.5~16.5 pp가 추가되었습니다.
  • 동일한 이동 공간에서 진화적 검색 대비 LLM 교사를 사용하여 실패를 진단하면 10.0 pp가 추가되었습니다.
  • 승인된 편집은 모든 원시에 분포되었습니다: 지능 (16~44%), 에이전트, 도구, 엔진. 이는 최적화 과정에서 단일 구성 요소가 지배하지 않음을 확인시켜 줍니다.

5. 중요성과 주장

본 논문은 로컬 개인 AI 가 단순한 모델 교체를 넘어선 것을 요구한다고 주장합니다: 즉, 이식 가능하고 측정 가능하며 최적화 가능한 스택이 필요합니다. OPENJARVIS 는 다음을 보여줍니다:

• 로컬 - 클라우드 동등성 달성 가능: 올바른 아키텍처를 통해 온디바이스 시스템은 로컬 속성 (개인정보 보호, 비용, 소유권) 을 포기하지 않고도 최첨단 클라우드 성능에 근접할 수 있습니다.
• 분해가 핵심: 성능 격차는 능력 한계가 아닌 아키텍처적 문제입니다. 클라우드 설계 스택의 가정을 편집 가능한 원시로 노출함으로써 로컬 모델을 그들의 강점에 맞게 재구성할 수 있습니다.
• 하이브리드 검색의 효율성: 클라우드 모델을 검색 단계 (진단 및 제안) 에만 사용하고 최적화된 명세를 추론 시기에 로컬에서 실행함으로써, 지속적인 클라우드 의존성 없이 최첨단 기능을 로컬 기기로 이전합니다.

저자들은 결과적으로 생성된 로컬 명세가 추론 시 클라우드 호출을 전혀 하지 않는다고 강조합니다. 검색 단계는 일회성 비용이 발생하지만 (6 개월 사용 후 쿼리당 $0.001 미만으로 분산됨), 운영 모델은 반복적인 클라우드 구독에서 일회성 최적화 후 로컬 실행으로 전환됩니다.

저자가 지적한 한계점:

• 통계적 정밀도는 구성당 5 회 독립 실행으로 제한됩니다.
• 잠재적인 LLM 판사 편향 (GPT-5-mini 사용) 은 GPT 계열 출력을 선호할 수 있습니다.
• 평가는 현재 단일 머신 배포로 제한되어 있습니다.
• 일부 클라우드 기준은 평가 하네스 내 도구 통합 문제로 인해 예상치 못한 낮은 점수를 보였습니다.