JarvisHub - An Open Harness for Canvas-Native Multimodal Creative Agents

Y. Lin, Z. Lin, Z. Xing, B. Li, et al., "JarvisHub: An Open Harness for Canvas-Native Multimodal Creative Agents," arXiv:2607.23588, 2026.

저자

저자 명단이 26명입니다. 기여자 표기는 알파벳순이고, 코어 기여자로 린윈룽, Zixu Lin, 싱자오후 세 명이 적혀 있습니다. 학술 자문은 팡톈위와 웨샹위 두 명입니다.

이 조합이 왜 모였는지는 코어 기여자 두 명의 이력을 보면 짐작이 됩니다. 린윈룽은 포스터 생성(PosterCraft), 자기진화 이미지 생성 에이전트(GenEvolve), 에이전틱 검색 기반 이미지 생성(Gen-Searcher)을 잇달아 해 온 연구자입니다. 관심의 단위가 결과물 한 장에서 생성 루프로, 다시 프로젝트 전체로 커져 왔습니다. 싱자오후는 의료 영상 확산 모델에서 출발한 연구자로, 생성 결과에 근거를 남기는 문제를 오래 다뤘습니다. 오류 비용이 큰 도메인에서 훈련된 감각입니다.

두 갈래가 만나는 지점이 이 논문입니다. 생성 품질을 더 올리는 대신, 생성 과정을 어디에 어떻게 남길 것인가를 묻습니다. GitHub 저장소가 LYL1015/JarvisHub인 것으로 보아 린윈룽이 실질적인 관리 주체입니다.

배경

이미지, 영상, 오디오, UI 컴포넌트를 한 번의 프롬프트로 그럴듯하게 뽑는 일은 이제 어렵지 않습니다. 문제는 실제 창작이 프롬프트 한 번으로 끝나지 않는다는 점입니다.

참조 자료를 모으고, 스타일과 캐릭터를 정하고, 레이아웃이나 샷을 계획하고, 후보를 여러 개 뽑고, 부분을 고치고, 대안을 비교하고, 피드백을 반영하고, 중간 결과를 모아 최종 산출물로 조립합니다. 이 과정에서 쌓이는 것들이 있습니다. 프롬프트, 참조 이미지, 초안, 후보, 편집 내역, 실패한 시도, 버전, 피드백입니다.

논문의 출발점은 이것들을 부산물로 보지 말자는 주장입니다. 저자들은 이 재료들이 창작 프로젝트의 상태(project state) 자체이며, 다음 계획과 수정과 평가에 필요한 맥락을 제공한다고 봅니다.

이렇게 보면 에이전트에게 구체적인 요구가 생깁니다. 다음 수를 두려면 에이전트가 어떤 재료가 이미 있는지, 서로 어떻게 연결돼 있는지, 어떤 후보가 채택되고 어떤 것이 버려졌는지, 어느 부분을 다음에 손봐야 하는지를 알아야 합니다. 그런데 이 맥락은 평범한 대화 기록에 담기지 않습니다. 공간 배치, 버전 분기, 참조 관계, 미완성 산출물이 섞여 있기 때문입니다.

기존 시스템들이 이 요구를 부분적으로만 충족한다는 것이 저자들의 진단입니다. 프롬프트-출력 도구는 개별 결과물을 잘 뽑지만 중간 결정, 실패한 시도, 대안 후보, 수정 이력을 감추거나 버립니다. 챗봇형 창작 에이전트는 여러 단계 지시를 따르고 도구를 호출할 수 있지만, 주된 맥락이 선형 대화라서 공간 배치나 자산 사이의 관계, 버전 분기, 국소 편집 대상을 표현하기 어렵습니다. 노드 기반 워크플로 도구는 실행 단계가 눈에 보이지만 사람이 미리 짜 둔 파이프라인 중심이라, 에이전트가 계속 살펴보고 고치고 늘리고 검증할 수 있는 편집 가능한 프로젝트 상태와는 다릅니다.

상업 제품 쪽에서도 같은 방향의 이동이 보입니다. Claude Design은 대화형 디자인 생성과 반복 정제를 지원하고, Google Stitch는 프롬프트 기반 UI 생성을 다중 페이지 프로토타입과 프런트엔드 코드로 잇습니다. TapNow와 LibTV는 서사 콘텐츠 제작을 위해 스크립트, 캐릭터, 스토리보드, 이미지, 영상, 오디오를 조직하고, MiniMax Hub는 멀티모달 워크플로에서 이미지·영상·오디오·텍스트 생성 도구를 조율합니다.

문제는 이들이 전부 닫혀 있다는 점입니다. 사용자에게 보이는 기능은 관찰할 수 있어도, 프로젝트 상태가 어떻게 표현되는지, 행동이 어떻게 검사되는지, 도구가 어떻게 스케줄되는지, 피드백이 어떻게 쓰이는지, 실패가 어떻게 복구되는지는 들여다볼 수 없습니다. 저자들이 비어 있다고 본 자리가 여기입니다. 창작 생성 제품이 하나 더 필요한 것이 아니라, 에이전트가 진화하는 멀티모달 프로젝트 위에서 어떻게 작동하는지를 연구할 수 있는 열린 하네스가 필요하다는 것입니다.

어떻게 만들었나

아이디어는 캔버스의 확장입니다. 캔버스는 사용자를 위한 시각 인터페이스일 뿐 아니라, 에이전트가 읽고 쓰는 공유 프로젝트 상태입니다.

구조는 세 레이어로 구분합니다. 캔버스 상태 계층이 노드, 속성, 배치, 버전, 의존 링크 같은 프로젝트 재료를 저장합니다. 프로토콜 브리지가 에이전트의 읽기와 쓰기를 검사합니다. 권한, 연산 형식, 검증, 로깅이 여기에 들어갑니다. 에이전트 런타임이 허가된 행동을 고르고, 도구를 호출하고, 상태를 동기화하고, 궤적을 기록합니다.

캔버스 상태

턴 \(t\)에서 창작 프로젝트를 다음과 같이 표현합니다.

\[C_t = (G_t, X_t, M_t, U_t, L_t), \qquad G_t = (V_t, E_t)\]

\(G_t\)는 타입이 붙은 산출물 그래프입니다. \(V_t\)는 캔버스 노드 집합이고, \(E_t \subseteq V_t \times R \times V_t\)는 방향이 있는 타입 관계입니다. 각 간선은 \((v_i, r, v_j)\)로 쓰며, \(r \in R\)은 참조 사용, 버전 계보, 생성 의존, 그룹핑, 워크플로 연속 같은 관계를 나타냅니다.

나머지 항은 내용과 상호작용 기록입니다. \(X_t\)는 편집 가능한 내용과 산출물 페이로드를, \(M_t\)는 출처와 실행 메타데이터와 런타임 상태를, \(U_t\)는 사용자의 선택과 편집과 피드백을, \(L_t\)는 공간 위치와 그룹 배치를 담습니다. 이렇게 나눠 두면 에이전트가 어떤 산출물이 무엇을 담고 있는지, 어떻게 만들어졌는지, 사용자가 어떻게 상호작용했는지, 캔버스 어디에 놓여 있는지를 각각 볼 수 있습니다.

노드 하나는 다음과 같이 표현됩니다.

\[v_i = (\mathrm{id}_i, k_i, p_i, x_i, y_i, m_i, s_i), \qquad k_i \in K_{\text{node}}\]

\(\mathrm{id}_i\)는 안정적인 식별자, \(k_i\)는 노드 종류, \(p_i\)는 위치와 국소 배치, \(x_i\)는 프롬프트나 설정 필드 같은 편집 가능한 입력, \(y_i\)는 생성된 출력이나 산출물 핸들, \(m_i\)는 출처와 실행 진단, \(s_i\)는 런타임 상태입니다.

이 표현이 주는 성질이 세 가지입니다. 첫째, 산출물에 주소가 있습니다. 에이전트가 "그 이미지"라는 모호한 대화 표현 대신 특정 후보 이미지나 영상 클립, 웹페이지 렌더, 슬라이드를 지목할 수 있습니다. 둘째, 산출물이 재사용됩니다. 참조, 초안, 거부된 후보, 중간 결과가 나중에 다른 생성이나 편집의 입력이 될 수 있습니다. 셋째, 의존 관계를 들여다볼 수 있습니다. 어떤 재료가 결과에 영향을 줬는지, 어느 버전이 선택됐는지, 어떤 하위 산출물이 그것에 의존하는지 추적할 수 있습니다.

여기에 런타임 상태가 캔버스 상태의 일부라는 점이 더해집니다. 그래서 이후 단계가 완료되거나 선택된 산출물을, 계획 중이거나 실행 중이거나 실패했거나 아직 검증되지 않은 결과와 구분할 수 있습니다.

프로토콜 브리지

긴 호흡의 창작이 굴러가려면 캔버스 갱신이 명시적이고, 유효하고, 복구 가능해야 합니다. JarvisHub는 이것을 에이전트와 캔버스 사이의 프로토콜 브리지로 강제합니다.

턴 \(t\)에서 에이전트는 사용자 질의 \(q_t\)를 받고 현재 캔버스 상태 \(C_t\)를 관찰합니다. 브리지는 역량 매니페스트 \(\Gamma_t\)를 제공하는데, 현재 프로젝트에서 사용 가능한 노드 타입, 변경 연산, 도구, 산출물 핸들의 목록입니다. 그리고 이번 요청에서 에이전트가 할 수 있는 일을 제한하는 실행 허가 \(\Omega_t\)를 도출합니다. \((q_t, C_t, \Gamma_t, \Omega_t)\)를 조건으로 에이전트가 행동 \(a_t\)를 제안하고, 하네스는 그것이 검사된 도구 호출, 캔버스 변경, 평가 요청, 명확화 요청, 사용자 대면 응답 중 하나로 인코딩될 수 있을 때만 실행합니다.

유효한 행동을 실행하면 관찰 \(o_t\)가 나옵니다. 해당 턴은 사람 사용자, 모델 기반 비평가, 보조 에이전트, 구조화된 평가자로부터 피드백 신호 \(f_t\)를 받을 수도 있습니다. 이 피드백이 복구나 후속 결정 \(r_t\)를 유도합니다. 캔버스는 다음과 같이 진화합니다.

\[C_{t+1} = \mathcal{F}(C_t, a_t, o_t, f_t, r_t)\]

\(\mathcal{F}\)는 브리지가 구현한 상태 전이 연산자입니다. 채택된 행동과 반환된 증거를 현재 캔버스에 씁니다. 노드를 만들거나, 필드를 갱신하거나, 의존 관계를 연결하거나, 산출물을 붙이거나, 실패를 기록하거나, 체크포인트를 만들거나, 사람에게 수정을 요청하는 방식으로요.

이 설계의 요점은 캔버스 상호작용이 감사 가능해진다는 것입니다. 에이전트가 캔버스를 고치면 궤적에 그 변경이 기록되고, 생성된 산출물을 쓰면 산출물 핸들과 그것을 만들어 낸 관찰이 함께 기록됩니다. 언어 생성 안에 숨지 않습니다.

에이전트 런타임

런타임은 \((q_t, C_t, \Gamma_t, \Omega_t)\)를 받아 이번 턴의 허가된 행동 공간을 만듭니다.

\[A_t = \mathcal{A}(\Omega_t, \Gamma_t, C_t, q_t), \qquad a_t \in A_t\]

저자들은 이 식이 구현 도구의 목록이 아니라 런타임 계약이라고 못 박습니다. 채택된 행동은 관찰된 캔버스에 근거해야 하고, 역량 매니페스트에 노출돼 있어야 하고, \(\Omega_t\)가 허용해야 하고, 프로토콜 브리지를 통해 커밋돼야 합니다. 이렇게 해야 공유 캔버스가 프로젝트 상태로 남고, 런타임이 별도의 숨은 상태를 따로 들고 있지 않게 됩니다.

무엇으로 구성돼 있나

런타임이 쓰는 도구는 다섯 계열로 묶여 있습니다.

도구 계열이 무엇을 호출할 수 있는지를 정한다면, 그것들을 긴 창작 과제에 걸쳐 어떻게 배열할지는 세 가지 상위 장치가 결정합니다.

스킬은 재사용 가능한 창작 절차를 인코딩합니다. 스토리보딩, 참조 기반 생성, 디자인-투-웹 재구성, 영상 프롬프팅, 덱 구성 같은 것들입니다. 모든 단계를 브리지에 하드코딩하지 않고도 런타임에 과제 구조를 줍니다.

메모리는 사용자 선호, 이전 결정, 절차 지식을 턴 사이에 보존합니다. 런타임이 앞선 프로젝트 맥락과 어긋나지 않는 행동을 고르도록 돕습니다.

서브에이전트는 워크플로가 분기할 수 있을 때 독립적인 하위 과제를 맡습니다. 예를 들어 서로 다른 영상 샷을 병렬로 탐색하되, 부모 에이전트가 쓸 만한 결과를 골라 공유 캔버스 그래프에 다시 통합합니다.

피드백과 궤적

피드백의 목적이 중간 결과를 평가하는 것이 아니라 다음 상태 전이를 결정하는 것이라는 서술이 이 논문에서 가장 명확한 설계 선언입니다. 채택된 노드에서 이어갈 것인가, 실패한 노드를 국소적으로 수리할 것인가, 사용자에게 명확화를 요청할 것인가, 증거가 부족하니 멈출 것인가를 정합니다.

피드백을 실행 가능하고 추적 가능하게 만들기 위해, 하네스는 각 피드백 신호를 그것이 발생한 상태와 실행 맥락과 함께 기록합니다. 궤적은 다음과 같이 정의됩니다.

\[\tau = \{(q_t, C_t, \Gamma_t, \Omega_t, a_t, o_t, f_t, r_t, C_{t+1})\}_{t=1}^{T}\]

한 턴에서 사용자 요청, 실행 전 캔버스 상태, 사용 가능한 역량, 허용된 행동 제약, 선택된 행동, 도구 관찰, 피드백 신호, 피드백이 유도한 복구 결정, 갱신된 캔버스 상태를 전부 남깁니다.

결과

먼저 짚어야 할 것이 있습니다. 이 논문의 실험은 정량 벤치마크가 아니라 정성 시연입니다. 리더보드도 없고, 베이스라인과의 수치 비교도 없습니다. 저자들 본인이 결론에서 이 점을 명시합니다.

실험 환경은 모두 동일합니다. 메인 에이전트 백엔드는 GPT-5.5, 이미지 생성 백엔드는 GPT Image 2, 영상 생성 백엔드는 Seedance 2.0, 멀티모달 평가 백엔드는 Gemini 3.1 Pro입니다.

과제는 세 가지입니다.

각 과제마다 두 가지 뷰를 함께 보고합니다. 캔버스 중심 제작 과정을 보여 주는 워크스페이스 트레이스와 최종 결과물입니다. 이 짝을 보여 주는 방식 자체가 논문의 주장입니다. 계획, 참조, 자산, 의존 관계, 에이전트 진행 상황이 긴 작업 내내 들여다보이는 상태로 남고, 축적된 캔버스 상태가 일관된 출력을 뒷받침한다는 것입니다.

서사 미디어 사례는 "카우보이 로봇 좀비 청소부"라는 짧은 드라마 프롬프트를 일관된 시각 시퀀스로 바꿉니다. 웹 개발 사례는 Awwwards 스타일의 밝은 디자인과 풍부한 애니메이션을 요구하는 개인 사진 웹사이트 브리프를 렌더된 사이트로 만듭니다. 발표 덱 사례는 강의 내용을 레이아웃, 다이어그램 스타일, 강조 색, 슬라이드 조직이 일관된 슬라이드로 만듭니다.

저자들이 논의 절에서 던지는 세 가지 질문이 결과보다 중요합니다.

왜 캔버스를 에이전트 작업공간으로 봐야 하는가. 캔버스가 사용자에게 시각 인터페이스를 주기 때문만이 아니라, 사람과 에이전트 양쪽의 공유 작업공간이 될 수 있기 때문입니다. 사용자는 에이전트가 읽고 고치는 바로 그 상태를 들여다보고 이끌 수 있습니다.

열린 하네스가 앞으로의 창작 에이전트 연구에 무엇을 열어 주는가. 세 가지를 듭니다. 프롬프트와 정답만이 아니라 초기 캔버스, 참조 자료, 사용 가능한 도구, 제약, 피드백 이벤트, 기대 체크포인트를 명시하는 프로젝트 상태 벤치마크. 최종 산출물 품질과 함께 맥락 보존, 도구 사용 적절성, 의존 관계 정확성, 피드백 준수, 수리 성공률 같은 과정 수준 지표를 결합하는 평가 프로토콜. 그리고 매 실행이 캔버스 상태, 에이전트 행동, 도구 관찰, 피드백 신호, 수리 결정, 최종 결과의 구조화된 예시를 만들어 내는 데이터 플라이휠.

왜 궤적이 분석 대상이어야 하는가. 창작 과제에서는 최종 산출물만으로 에이전트 행동을 온전히 특징지을 수 없기 때문입니다. 여러 결과물이 모두 수용 가능할 수 있고, 시각적으로 강한 결과가 취약하거나 잘못된 과정에서 나올 수도 있습니다. 반대로 불완전한 최종 결과가 쓸 만한 중간 산출물과 복구 가능한 결정을 담고 있을 수도 있습니다. 궤적을 보면 과정 수준의 실패가 눈에 띕니다. 참조를 무시하는 것, 채택된 선택을 잃어버리는 것, 쓸 만한 변형을 덮어쓰는 것, 국소 수리로 충분한데 전체를 다시 생성하는 것 같은 실패들입니다.

회고

논문에서 인정한 한계는 네 가지입니다.

첫째, 실험이 완성된 벤치마크나 리더보드가 아니라 정성 시연입니다. 논문이 스스로 제안한 프로젝트 상태 벤치마크를 정작 자기는 아직 만들지 못했습니다.

둘째, JarvisHub는 오케스트레이션과 프로젝트 상태 관리에 집중하므로, 최종 산출물 품질은 여전히 런타임이 쓰는 외부 모델과 도구에 달려 있습니다. 하네스가 좋아도 GPT Image 2가 못 그리면 결과가 좋아지지 않습니다.

셋째, 프로토콜 브리지는 캔버스 행동을 명시적이고 복구 가능하게 만들지만, 에이전트의 창작 결정이 의미상 옳다는 것을 보장하지는 않습니다. 형식 검증과 내용 검증은 다른 문제입니다.

넷째, 궤적 기록이 분석과 학습에 유용하지만 원본 궤적을 연구 데이터로 쓰려면 품질 필터링, 동의, 익명화, 저작권 검토가 선행돼야 합니다.

여기에 논문이 직접 언급하지 않은 문제를 하나 더 짚고 싶습니다. 확장성입니다.

캔버스를 메모리로 쓴다는 설계는 프로젝트가 길어질수록 상태가 커진다는 뜻이기도 합니다. 벡터 스토어 기반 메모리는 검색으로 관련된 조각만 꺼내 쓰지만, 캔버스는 그래프 전체가 프로젝트 상태입니다. 노드 수 \(N_t\)가 늘어나면 에이전트가 매 턴 관찰해야 하는 \(C_t\)도 같이 커집니다.

논문은 이 문제에 대한 장치를 갖고 있기는 합니다. 역량 매니페스트 \(\Gamma_t\)와 실행 허가 \(\Omega_t\)가 이번 턴에 볼 수 있고 건드릴 수 있는 범위를 좁힙니다. 노드에 타입과 주소가 붙어 있으니 원칙적으로는 필요한 부분만 지목할 수 있습니다.

문제는 이것이 논문에서 설계 원칙으로만 서술되고 수치로 검증되지 않았다는 점입니다. 노드가 수백 개로 늘어난 프로젝트에서 \(\Gamma_t\)가 실제로 얼마나 줄어드는지, 에이전트가 관련 노드를 제대로 골라내는지, 컨텍스트 길이가 어떻게 증가하는지에 대한 측정이 없습니다. 캔버스 네이티브 설계의 진짜 승부처가 여기인데 실험이 정성 시연 세 건이라 확인할 방법이 없습니다.

이 논문을 평가할 때 유의할 점도 있습니다. 이것은 방법론 논문이 아니라 시스템 논문이자 포지션 논문에 가깝습니다. 새로운 알고리즘을 제안해 기존 방법을 이겼다는 구조가 아니라, 창작 에이전트 연구가 무엇을 열어 두고 무엇을 공유해야 하는지를 코드와 함께 제안하는 구조입니다. 그런 논문에 벤치마크 승리를 요구하는 것은 초점이 어긋난 요구입니다. 다만 저자들이 스스로 프로젝트 상태 벤치마크를 만들자고 제안한 이상, 다음 작업에서 그 숫자가 나와야 이 주장이 검증됩니다.

정리

창작 에이전트의 메모리를 사용자가 볼 수 없는 곳이 아니라 사용자가 보는 캔버스 자체에 두자는 제안입니다. 프롬프트, 참조, 초안, 후보, 편집, 버전, 피드백이 전부 타입과 주소가 붙은 노드가 되고, 에이전트가 무엇을 기억하는지가 화면에 무엇이 남아 있는지와 같아집니다. 개입 지점이 명시적으로 생긴다는 것이 이 설계의 실질적 이득입니다.

프로토콜 브리지가 이 구조를 지탱합니다. 에이전트는 역량 매니페스트에 노출되고 실행 허가가 허용하는 행동만 할 수 있고, 모든 변경은 브리지를 통해 커밋되며 궤적에 남습니다. 덕분에 최종 산출물이 아니라 과정을 분석 대상으로 삼을 수 있게 됩니다.

닫힌 상업 제품들 사이에 열린 하네스를 놓았으니 이후 연구가 기대됩니다.