JarvisHub: 캔버스 네이티브 멀티모달 창작 에이전트용 오픈 하니스

단회성 프롬프트-응답 방식은 생성 과정의 중간 산출물과 버전 정보를 보존하지 못해 장기 창작 작업에서 문맥 손실이 발생했다. JarvisHub는 캔버스를 읽기·쓰기 가능한 공유 프로젝트 상태로 삼아 참조, 버전, 실패 기록, 피드백을 구조적으로 유지함으로써 에이전트의 계획과 수정을 연속적으로 이어가게 했다. 이로 인해 작업 과정의 추적성, 국소적 수리, 인간과의 상호조정이 가능해져 장기 멀티모달 파이프라인을 연구·평가할 수 있는 기반이 마련되었다.

기존 프롬프트 기반 도구는 고품질 개별 자산을 생성하는 데 유효했지만 생성 과정의 중간 산출물, 버전, 의존성, 레이아웃 정보를 일시적 컨텍스트로만 취급해 장기 계획과 수정에 필요한 문맥을 잃었다. 선형 대화 기반 에이전트는 대화 기록을 컨텍스트로 사용하나 공간적 레이아웃, 분기된 버전, 로컬 편집 대상을 표현하기에 적합하지 않았다. 노드 기반 워크플로는 절차를 가시화했으나 수동 파이프라인 중심으로 에이전트가 연속적으로 상태를 읽고 쓰는 런타임을 제공하지 못했다.

JarvisHub는 캔버스를 단순 UI가 아닌 공유 프로젝트 상태로 재정의해 이러한 한계를 극복했다. 캔버스 상태를 수식적으로 C_t=(G_t,X_t,M_t,U_t,L_t)로 모델링하고 G_t=(V_t,E_t)로 아티팩트 그래프를 구성해 노드별 id, kind, 위치, 입력 필드, 출력 핸들, 메타데이터, 상태를 명시했다. 이 표현은 에이전트가 특정 이미지 후보나 영상 클립을 불분명한 자연어 참조 대신 주소able 핸들로 지정해 후속 세대로 전달하고, 거부된 후보나 실패 로그를 재활용하거나 국소 수리의 근거로 사용할 수 있게 했다.

캔버스 기반 표현과 함께 프로토콜 브리지를 도입해 각 턴에서 가능한 행동 공간을 매니페스트 Γ_t와 실행 그랜트 Ω_t로 제한했다. 런타임은 관찰·행동 선택·툴 호출·검증·커밋의 순환을 수행하며, 모든 요청·행동·관찰·피드백을 트레이저리 τ로 기록했다. 결과적으로 에이전트는 단발성 툴 호출을 넘어 지속적이고 가시적인 프로젝트 관리를 수행할 수 있게 되었고, 프로세스 수준의 평가지표와 재현 가능한 학습 데이터를 확보할 수 있었다.

전체 접근은 캔버스를 중심으로 한 턴 기반 실행 루프이다. 각 턴에서 런타임은 현재 캔버스를 관찰해 사용자 요청을 콘텍스트에 맞춰 해석하고, 프로토콜 브리지가 발행한 매니페스트와 실행 그랜트로 허용된 연산을 선별한 뒤 해당 능력을 호출하고 반환된 관찰을 캔버스에 커밋한다. 이 루프는 캔버스의 읽기·쓰기 권한을 명시적으로 통제해 변경의 검증과 기록을 표준화했다.

핵심 메커니즘은 세 계층으로 구성된다. 캔버스 상태 계층은 노드·간선·입력·출력·메타데이터·레이아웃을 저장해 아티팩트를 주소 가능하게 만들었고, 프로토콜 브리지는 권한 매니페스트 Γ_t와 실행 그랜트 Ω_t를 통해 턴별 허용 범위를 도출하며 입력된 액션을 검증해 상태 전이를 수행하는 함수 ℱ를 적용했다. 에이전트 런타임은 도구 패밀리(캔버스 도구, 생성 도구, 네이티브 도구, 복구 도구, MCP 도구)와 지원 모듈(스킬, 메모리, 서브에이전트)을 사용해 장기 작업을 오케스트레이션했다.

학습 전략과 실행 세부에서는 스킬이 재사용 가능한 창작 절차를 인코딩해 런타임이 반복적 구조를 하드코딩하지 않고도 작업을 구성하도록 했고, 메모리는 사용자 선호와 이전 결정을 보존해 일관성을 유지했으며, 서브에이전트는 병렬 탐색이 필요한 하위작업을 처리해 부모 에이전트가 선택·통합 작업에 집중하도록 설계되었다. 트레이저리는 τ = {(q_t,C_t,Γ_t,Ω_t,a_t,o_t,f_t,r_t,C_{t+1})}_{t=1}^T 형태로 정의되어 각 턴의 전후 상태와 피드백·수리 결정을 함께 저장했다.

실험은 정량적 리더보드가 아닌 질적 사례 시연에 초점을 맞추었다. 평가 환경은 JarvisHub 구현 위에서 동작하며, 에이전트 백엔드로 논문에 명시된 GPT-5.5를 사용했고 이미지·비디오·멀티모달 평가에 각각 GPT Image 2, Seedance 2.0, Gemini 3.1 Pro를 연결했다. 세 가지 대표적 장기 작업(내러티브 미디어, 인터랙티브 웹 개발, 프레젠테이션 생성)을 통해 워크스페이스 트레이스와 최종 산출물을 페어로 제시해 캔버스의 상태 보존과 작업 연속성이 유지되는 양상을 보였다.

내러티브 미디어 사례에서는 플랜, 레퍼런스, 샷 후보, 의존관계, 생성 진행도가 캔버스에 보존되어 샷 간 시각적 연속성과 캐릭터 정체성이 유지된 키 프레임 시퀀스가 산출되었다. 웹 개발 사례에서는 디자인 레퍼런스와 프론트엔드 미리보기, 구현 아티팩트가 캔버스에 결합되어 타이포그래피·이미지 배치·페이지 구조의 일관성이 유지된 렌더링 결과를 생성했다. 프레젠테이션 사례에서는 슬라이드 수준의 구조와 다이어그램 스타일이 캔버스에 기록되어 전체 데크의 시각적 통일성이 확보되었다.

논문 자체에서 제시된 수치 기반 벤치마크나 비교 실험은 없었고, 결과는 주로 정성적 관찰과 작업 트레이스의 가시성으로 평가되었다는 한계가 있다. 또한 최종 아티팩트 품질은 외부 생성 모델에 의존하므로 하니스는 오케스트레이션과 상태 관리 측면에서의 기여에 집중되었다.

전체 아키텍처는 캔버스 상태, 프로토콜 브리지, 에이전트 런타임으로 구성되어 캔버스를 단일한 외부 메모리이자 액션 공간으로 취급한다. 캔버스 상태는 수식적 표현 C_t=(G_t,X_t,M_t,U_t,L_t)로 정의되며 그래프 G_t=(V_t,E_t)는 타입화된 아티팩트를 노드로 표현해 주소 가능한 참조와 의존성 추적을 가능하게 한다. 이 구조는 에이전트가 특정 후보물을 대상으로 국소 편집·재생성·비교를 수행하고, 실행 상태(s_i)를 통해 완료·실행중·실패·선택 상태를 구분하게 한다.

수식적 구성요소에 대한 상세 설명은 다음과 같다. 원문 수식: C_t=(G_t,X_t,M_t,U_t,L_t), G_t=(V_t,E_t). 변수 의미: G_t는 아티팩트 그래프(노드 집합 V_t와 타입 간선 E_t), X_t는 노드 입력 및 페이로드, M_t는 실행·출처·진단 메타데이터, U_t는 사용자 상호작용 기록, L_t는 공간적 레이아웃 정보이다. 처리 흐름은 사용자 요청 q_t과 현재 캔버스를 런타임이 관찰한 뒤 매니페스트 Γ_t와 실행 그랜트 Ω_t를 통해 허용된 행동 집합 A_t를 결정하고, 선택된 액션 a_t를 툴로 실행해 관찰 o_t을 얻은 뒤 프로토콜 브리지의 상태전이 함수 ℱ를 통해 C_{t+1}을 생성하는 순서이다. 간단한 예로 특정 이미지 후보를 편집하는 액션은 해당 노드 v_i의 x_i(입력) 필드를 변경하고 y_i(출력 핸들)를 갱신하며 m_i에 실행 로그를 추가해 캔버스에 커밋된다. 이 흐름의 해석은 각 턴의 변경이 감사 가능하고 되돌릴 수 있음을 의미한다.

상태 전이의 형식적 정의는 원문 수식: C_{t+1}=ℱ(C_t,a_t,o_t,f_t,r_t)이다. 변수 의미는 C_t가 이전 캔버스, a_t가 제안된 행위, o_t가 툴 관찰, f_t가 피드백 신호, r_t가 피드백 기반 수리 결정이다. 연산 흐름은 에이전트가 a_t를 제안하면 브리지가 이를 검증해 툴 호출을 허가하고 반환된 o_t과 f_t를 바탕으로 ℱ가 노드 생성·업데이트·간선 연결·체크포인트 생성을 수행해 C_{t+1}을 만든다. 작은 사례로 툴이 생성한 이미지가 있을 때 ℱ는 새로운 노드 v_new를 만들고 y_new에 아티팩트 핸들을 저장하며 m_new에 생성 메타데이터를 기록한다. 이 정의는 캔버스가 단순 뷰가 아니라 상태 변화의 원천임을 수학적으로 보장한다.

툴 패밀리와 런타임 계약 측면에서는 캔버스 도구가 노드 CRUD 및 그룹·선택 연산을 지원하고, 생성 도구는 이미지·비디오·오디오 생성물을 반환하며, 네이티브 도구는 외부 환경(브라우저·파일·코드)에서 검사 가능한 아티팩트를 생성한다. 복구 도구는 출력의 결함을 검사하고 국소 수리·검증·체크포인트 복원을 수행하며, MCP 도구는 외부 서비스 확장을 동일 매니페스트·그랜트 계약으로 통합한다. 스킬·메모리·서브에이전트는 툴 호출 순서를 결정하는 상위 논리를 제공해 장기 작업의 절차적 일관성을 확보한다.

논문의 실험은 주로 정성적 시연에 기반해 하니스의 동작성·추적 가능성·워크플로 통합을 보여주었으나 완성된 벤치마크나 정량적 비교는 제공되지 않았다. 하니스 자체는 오케스트레이션과 상태 관리를 담당하므로 최종 에셋 품질은 외부 생성 모델과 도구의 성능에 의존한다. 또한 프로토콜 브리지는 연산의 검증과 기록을 보장하지만 에이전트의 창의적 판단이 항상 의미론적으로 적절하다는 보증은 제공하지 않으며, 트레이저리 데이터의 재사용은 동의·익명화·저작권 검토 등 추가 작업이 필요하다.