VISUALSKILL: Multimodal Skills for Computer-Use Agents
https://arxiv.org/abs/2606.18448
Ziyan Jiang, Li An, Yujian Liu, Jiabao Ji, Qiucheng Wu, Jacob Andreas, Yang Zhang, Shiyu Chang | UC Santa Barbara, MIT CSAIL, MIT-IBM Watson AI Lab | arXiv:2606.18448 | 2026년 6월
1. 서론: GUI 에이전트의 다음 병목은 텍스트 지식이 놓친 화면 상태다
컴퓨터 사용 에이전트는 이제 브라우저나 데스크톱 앱을 열고, 스크린샷을 읽고, 키보드와 마우스 액션을 조합해 실제 작업을 수행한다. 표준화된 벤치마크에서 점수는 빠르게 올라갔지만, 긴 작업을 끝까지 유지하거나 처음 보는 소프트웨어에서 안정적으로 행동하는 문제는 아직 남아 있다. VISUALSKILL은 이 병목을 모델 크기나 프롬프트 기교보다, 에이전트가 작업 중 불러오는 스킬의 표현 방식에서 찾는다.
기존 스킬 라이브러리는 대체로 텍스트 중심이다. “서식 메뉴를 열고 문자 효과를 선택하라” 같은 절차 설명은 저장할 수 있지만, 실제 GUI에서는 메뉴 화살표의 위치, 비활성화된 라디오 버튼, 대화상자 하단의 저장 버튼처럼 말로만 전달하기 어려운 단서가 많다. 논문은 이 간극 때문에 텍스트 스킬이 UI 요소 식별과 작업 상태 검증에서 흔들린다고 본다.
핵심 아이디어는 단순하다. 애플리케이션별 스킬을 중앙 인덱스와 주제별 guide 파일로 나누고, 각 guide가 텍스트 본문과 실제 화면 figure를 함께 담도록 만든다. 에이전트는 처음부터 모든 파일을 읽지 않고, 현재 행동과 맞는 주제를 찾으면 load_topic MCP 도구로 해당 주제의 텍스트와 이미지를 함께 가져온다.
실험 수치도 이 주장을 명확하게 밀어 준다. CUA-World와 OSExpert-Eval 두 벤치마크에서 Claude Code CLI 기반 에이전트는 스킬이 없을 때 평균 0.303점을 얻고, Stage 2 VISUALSKILL을 쓰면 0.456점까지 올라간다. 같은 원천 자료에서 만든 텍스트 전용 스킬과 비교해도 VISUALSKILL은 0.373 대 0.456으로 8.3점의 절대 향상을 보인다.
이 결과가 흥미로운 이유는 “그림을 넣으면 좋아진다”는 일반론보다 훨씬 좁은 질문을 던지기 때문이다. 논문은 같은 문서, 같은 주제 구조, 같은 에이전트, 같은 벤치마크를 두고 modality만 비교한다. 따라서 성능 차이는 더 풍부한 프롬프트 때문이라기보다, 스킬 아티팩트 안에 보존된 시각 증거가 에이전트의 행동 선택에 얼마나 영향을 주는지 보여 주는 증거로 읽을 수 있다.
특히 GUI 작업은 언어적 instruction following과 다르게, 클릭 좌표의 작은 오차가 전체 trajectory를 망가뜨린다. 드롭다운의 텍스트 필드를 누를지, 오른쪽의 작은 화살표를 누를지, 모달 창의 제목줄을 누를지, 하단의 저장 버튼을 누를지 같은 선택이 성공과 실패를 가른다. VISUALSKILL은 이 차이를 스킬 내부의 시각 자료와 실행 중 검색 메커니즘으로 다루려는 시도다.
Figure 1: 텍스트 설명만으로는 아이콘, 버튼, 대화상자 위치를 충분히 특정하기 어렵다는 동기 그림.
Figure 1은 논문의 문제의식을 가장 압축적으로 보여 준다. 텍스트 전용 스킬은 작업 절차를 설명해도 에이전트가 어떤 아이콘을 봐야 하는지, 어떤 버튼이 같은 대화상자 안에서 실제 목표인지 분리하기 어렵다. 반면 멀티모달 스킬은 설명 바로 옆에 참고 화면을 붙여 UI 요소의 모양과 위치를 보존하므로, 다음 클릭을 고를 때 언어 설명과 시각 단서가 같은 주제를 가리키게 만든다. 특히 작은 아이콘과 인접 버튼이 많은 화면에서는 이 차이가 좌표 선택의 불확실성을 직접 줄인다.
2. 배경 및 관련 연구: 에이전트 스킬은 지식 저장소에서 실행 보조 장치로 이동한다
2.1 Computer-use agent의 신뢰성 문제
컴퓨터 사용 에이전트의 성능 평가는 한 번 성공한 데모보다 반복 실행에서 얼마나 흔들리는지를 봐야 한다. 기존 위키의 [[concepts/computer-use-agent-reliability]] 관점과 연결하면, VISUALSKILL은 같은 작업을 다시 시켰을 때 필요한 절차 지식과 화면 상태 지식을 어떻게 안정적으로 꺼내 줄 것인가라는 질문에 놓인다. UI가 길고 복잡할수록 모델의 일반 지식만으로는 메뉴 구조와 상태 전이를 모두 기억하기 어렵다.
CUA-World와 OSExpert-Eval은 그런 약점을 잘 드러내는 벤치마크다. 전자는 Writer, Calc, Impress, QGIS, OpenToonz처럼 서로 다른 애플리케이션 도메인을 포함하고, 후자는 LibreOffice, GIMP, Tableau 같은 unseen UI에서 장기 조합 작업을 요구한다. 같은 에이전트가 모든 도메인을 처리해야 하므로, 특정 앱의 메뉴와 대화상자 지식을 task prompt에 계속 넣는 방식은 금방 한계에 부딪힌다.
논문이 채택한 해법은 agent skill을 작업 시점의 외부 지식 구조로 다루는 것이다. 에이전트의 파라미터 안에 모든 앱 사용법을 넣기보다, 앱별 스킬을 파일 시스템에 두고 필요할 때만 불러오게 한다. 이 접근은 [[concepts/agent-skills]]에서 정리한 progressive disclosure와 맞닿아 있다. 모델은 처음에 인덱스만 읽고, 실제로 연관된 topic이 생길 때 세부 guide를 가져온다.
2.2 텍스트 스킬이 GUI에서 부족한 이유
텍스트 스킬은 메뉴 경로, 단축키, 필드 이름처럼 언어로 안정적으로 부를 수 있는 정보를 잘 담는다. 그러나 GUI에는 이름보다 모양과 상대 위치가 더 중요한 요소가 많다. 예를 들어 브러시, 선택, 채우기 아이콘은 화면에서 픽토그램으로 구분되며, 드롭다운은 텍스트 필드와 작은 화살표가 하나의 위젯처럼 붙어 있다. 이때 “드롭다운을 클릭하라”는 문장은 좌표를 충분히 제한하지 못한다.
또 다른 문제는 상태 검증이다. 에이전트가 어떤 메뉴를 선택한 뒤 실제로 스타일이 적용됐는지 확인하려면, 스크린샷의 툴바 텍스트, 상태바 메시지, 미리보기 패널 변화처럼 후속 화면을 읽어야 한다. 텍스트 스킬이 이 상태를 길게 설명할 수는 있지만, 실제 화면의 픽셀 단서를 언어로 변환하는 과정에서 중요한 정보가 빠지기 쉽다. VISUALSKILL은 이 변환 손실을 줄이기 위해 figure를 원형에 가깝게 보존한다.
이 지점은 [[concepts/multimodal-agent-memory]]와도 이어진다. 멀티모달 메모리에서 원본 이미지, dense caption, 상태 기록이 서로 다른 병목을 만들듯, GUI 스킬에서도 원본 화면과 텍스트 설명은 대체 관계보다 보완 관계에 가깝다. 텍스트는 작업 순서를 압축하고, 이미지는 UI 요소 식별과 상태 확인의 증거를 남긴다.
2.3 MCP 도구로 읽는 스킬의 의미
VISUALSKILL은 스킬 폴더를 그냥 파일로 노출하지 않고 load_topic이라는 MCP 도구로 읽게 한다. 이 선택은 작은 구현 세부사항처럼 보이지만, 실험에서는 중요한 차이를 만든다. 파일을 직접 읽게 하면 에이전트가 텍스트 guide만 읽고 이미지 파일은 건너뛰기 쉽다. 도구 호출이 텍스트와 이미지를 한 번에 반환하면, figure가 해당 문장 바로 뒤에 붙어 행동 결정 문맥에 들어온다.
이 설계는 [[concepts/mcp-transport-boundary]]가 말하는 연결 경계와도 다르게 읽을 수 있다. VISUALSKILL의 MCP는 원격 서비스의 복잡한 인증 문제보다, 같은 로컬 실행 안에서 스킬 내용을 어떤 구조로 반환할지에 초점이 있다. 기능 목록보다 중요한 것은 tool result의 shape이다. TextContent와 ImageContent가 교차하는 반환 구조가 에이전트의 실제 관찰 채널을 바꾼다.
따라서 논문의 기여는 멀티모달 자료를 저장했다는 점에만 있지 않다. 자료를 저장한 뒤 에이전트가 언제, 어떤 단위로, 어떤 순서로, 어떤 modality로 그 자료를 소비하게 할지까지 하나의 실험 변수로 잡았다. 이 덕분에 Figure 보존, topic indexing, MCP loading, UI exploration이 하나의 agent memory pipeline처럼 결합된다.
3. 방법론: VISUALSKILL은 앱별 인덱스와 주제별 화면 증거를 함께 저장한다
3.1 스킬 정의: index와 guide의 이층 구조
논문에서 하나의 VISUALSKILL은 하나의 대상 애플리케이션을 위한 구조화된 참조물이다. 루트에는 skill.md 인덱스가 있고, 그 아래에는 topic별 guide 파일 집합이 있다. 각 topic은 “언제 이 guide를 불러야 하는가”를 한 문장으로 설명하며, 실제 guide는 절차 텍스트와 관련 figure 묶음을 함께 가진다. 수식으로는 guide를 $g_t=(p_t,F_t)$처럼 둘 수 있다.
이 구조의 장점은 애플리케이션 전체 매뉴얼을 한 번에 context에 넣지 않아도 된다는 점이다. 에이전트는 task를 수행하면서 현재 하려는 행동과 인덱스의 when-to-use 문장을 비교한다. 관련 topic이 보이면 load_topic을 호출하고, 호출 결과로 그 topic의 본문과 figure가 함께 들어온다. 긴 작업이 여러 UI 표면을 지나가면 topic 호출도 여러 번 일어난다.
텍스트 전용 control도 같은 topic 구조를 쓴다. 차이는 figure를 남기느냐, 그림 정보를 언어로 흡수하느냐뿐이다. 같은 원천 문서와 같은 LLM 호출에서 멀티모달 버전과 텍스트 전용 버전을 나란히 만들기 때문에, 두 조건의 내용 범위와 주제 분할이 최대한 맞춰진다. 이 점이 modality 효과를 비교할 때 중요하다.
VISUALSKILL이 저장하는 figure는 단순 장식이 아니다. 메뉴가 열린 상태, 특정 탭이 선택된 상태, 버튼이 회색으로 비활성화된 상태, 드롭다운이 펼쳐진 상태처럼 작업 중간의 화면 증거를 담는다. 이런 자료는 “어떤 조작을 해야 하는가”와 “조작 뒤 어떤 화면이면 성공인가”를 판단하게 해 준다.
Figure 2: 같은 topic을 VISUALSKILL과 text-only control로 만든 예시.
Figure 2는 같은 원천 자료에서 나온 두 스킬이 무엇을 공유하고 무엇을 달리하는지 보여 준다. topic, 절차, 설명 범위는 맞춰져 있지만, VISUALSKILL 쪽은 문장과 연결된 화면 이미지를 그대로 유지한다. 이 구조 덕분에 실험의 차이는 더 많은 정보를 임의로 넣은 효과와 구분되며, 시각 자료를 보존하고 호출 결과에 포함한 효과로 해석하기 쉬워진다. 즉 비교 대상의 범위를 맞춘 상태에서 modality가 행동 품질에 미치는 영향을 비교적 깨끗하게 볼 수 있다.
3.2 Stage 1: 공식 문서에서 topic과 figure를 채굴한다
Stage 1은 애플리케이션의 공식 사용자 가이드를 출발점으로 삼는다. 논문은 성숙한 데스크톱 애플리케이션이 이미 구조화된 매뉴얼을 갖고 있다는 사실을 활용한다. 매뉴얼의 table of contents는 topic set을 만드는 자연스러운 출발점이 되고, 각 topic에 해당하는 페이지에서 텍스트와 그림을 추출해 per-topic guide의 재료로 사용한다.
이 단계에서 얻는 figure는 벤더가 문서에 넣어 둔 화면 자료다. 장점은 품질이 높고 공식 설명과 잘 맞는다는 점이며, 단점은 실제 실행 환경의 최신 UI와 어긋날 수 있다는 점이다. 따라서 Stage 1만으로도 절차 지식은 꽤 많이 확보되지만, 동적 대화상자나 작업 중 나타나는 임시 상태까지 다루기에는 부족하다.
Stage 1은 텍스트 전용 control을 만들 때도 같은 자료를 사용한다. LLM은 멀티모달 버전의 본문과 텍스트 전용 버전의 본문을 같은 호출에서 생성하며, 텍스트 전용 버전은 figure에 들어 있는 내용을 말로 풀어 넣는다. 이 matching은 평가에서 매우 중요하다. 비교 대상이 다른 topic을 포함하면 visual modality 자체의 효과를 분리할 수 없기 때문이다.
문서 기반 스킬은 엔지니어링 관점에서도 매력적이다. 새로운 앱을 지원할 때 처음부터 사람이 데모를 녹화하거나 수백 개 task를 실행하지 않아도, 공식 manual을 파싱해 초기 스킬을 만들 수 있다. VISUALSKILL의 Stage 1은 이 초기 버전을 빠르게 확보하는 bootstrap 단계라고 볼 수 있다.
3.3 Stage 2: 살아 있는 애플리케이션을 탐색해 문서의 빈틈을 보강한다
Stage 2는 실제 애플리케이션을 띄워 UI exploration을 수행한다. 논문은 이 단계를 다시 두 하위 경로로 나눈다. 첫 번째는 free explorer로, idle 상태의 화면을 여러 region으로 분할하고 각 region을 worker agent가 탐색한다. 두 번째는 trajectory-targeted explorer로, 훈련 task에서 에이전트가 실패하거나 비효율적으로 움직인 UI 지점을 찾아 다시 캡처한다.
free explorer는 메뉴, toolbar, sidebar, palette처럼 기본 화면에서 접근 가능한 표면을 넓게 훑는다. planner agent가 어떤 region을 볼지 정하고, worker agent는 격리된 Docker 컨테이너 안에서 해당 region을 조작하며 interactive element의 crop과 설명을 남긴다. 이 방식은 앱 전체를 사람이 손으로 문서화하는 비용을 줄이고, 문서에 없거나 위치가 달라진 UI 단서를 잡는 데 유리하다.
trajectory-targeted explorer는 더 구체적이다. 훈련 split에서 실제 에이전트가 이상하게 움직인 trace를 reviewer agent가 보고, 어떤 UI 영역에 지식이 부족했는지 식별한다. 그다음 worker가 해당 영역을 다시 열어 캡처하고, 기존 topic guide에 patch를 넣는다. 이 과정은 실패 trajectory를 스킬 수리 신호로 쓰는 구조이며, [[concepts/agent-skill-repair-loop]]과도 잘 맞는다.
Stage 2의 결과물은 Stage 1 스킬을 대체하지 않는다. 공식 문서에서 온 절차 지식을 유지하면서, 살아 있는 UI에서 얻은 screenshot과 상태 전이 지식을 덧붙인다. 논문 실험에서 Stage 2가 가장 큰 향상을 만든 이유도 이 보완 관계 때문이다. 매뉴얼은 넓은 절차를 주고, exploration은 실제 클릭 지점과 사후 확인 화면을 준다.
Figure 3: Position 탭을 처음 열었을 때 Normal 라디오가 선택되고 일부 필드가 비활성화된 상태.
Figure 3은 trajectory-targeted explorer가 왜 필요한지 보여 주는 예다. 문서에는 “Position 탭에서 Subscript를 선택한다”는 절차가 있을 수 있지만, 실제 화면에서는 Normal 라디오, Raise/lower 입력칸, Relative font size 입력칸, Automatic 체크박스의 초기 상태를 함께 봐야 한다. 이런 스크린샷은 에이전트가 현재 상태와 목표 상태의 차이를 시각적으로 비교하는 데 쓰인다.
Figure 4: Subscript 라디오를 클릭한 뒤 Raise/lower와 Relative font size가 자동 설정된 상태.
Figure 4는 같은 대화상자에서 action 이후 화면이 어떻게 바뀌는지를 담는다. Subscript 라디오를 선택하면 Raise/lower가 8%, Relative font size가 58%로 채워지고 Automatic 체크박스도 켜진다. 텍스트 지시만 있으면 이 값들이 사후 검증 단서라는 점이 약해지지만, figure가 함께 오면 에이전트는 스크린샷을 보고 조작 성공 여부를 더 구체적으로 판단할 수 있다. 이처럼 VISUALSKILL의 figure는 클릭 전 target과 클릭 후 confirmation을 한 쌍으로 묶는다.
4. 실험 설정: 같은 에이전트와 같은 자료에서 modality 차이만 비교한다
4.1 Agent와 도구 표면
논문은 Claude Code CLI 기반 computer-use agent를 사용하고, underlying model로 Claude Opus 4.6을 둔다. 에이전트는 스크린샷을 관찰하고 고정된 GUI 도구 집합으로 키보드와 마우스 조작을 수행한다. 모든 조건에서 CLI, 도구 표면, per-step prompt를 고정하므로, 성능 차이는 스킬 artifact와 loading 방식에서 나온 것으로 해석한다.
CUA-World에서는 각 task가 init.max_steps에 포함한 step cap을 그대로 사용한다. task 난이도에 따라 40에서 200 action까지 허용된다. OSExpert-Eval은 시간 기반으로, benchmark 기본값인 15분 per-task cap을 쓴다. 이 설정은 모델이 스킬을 불러오는 비용과 실제 GUI 조작 비용이 함께 들어가는 환경을 만든다.
GUI 도구는 key, type, mouse_move, left_click, drag, right_click, screenshot 등으로 구성된다. 이 도구 표면은 사람이 데스크톱을 다루는 조작과 비슷하지만, 좌표 기반 클릭의 불안정성을 그대로 갖는다. VISUALSKILL이 다루려는 핵심도 여기에 있다. 어떤 좌표를 눌러야 하는지, 클릭 뒤 어떤 화면이면 다음 단계로 넘어가도 되는지 판단하는 데 figure가 들어간다.
| Action | Behaviour | 리뷰 관점의 의미 |
|---|---|---|
| key | 키 또는 키 조합을 누른다. | 단축키가 안정적인 앱에서는 텍스트 절차만으로도 충분할 수 있다. |
| type | 문자열을 입력한다. | 필드가 정확히 focus된 상태인지 스크린샷 검증이 필요하다. |
| mouse_move | 커서를 좌표로 이동한다. | GUI 요소 위치 지식이 직접 좌표 선택으로 이어진다. |
| left_click | 왼쪽 버튼을 클릭한다. | 아이콘, 화살표, 버튼의 작은 차이를 figure가 보완한다. |
| left_click_drag | 현재 위치에서 특정 좌표까지 drag한다. | 도형 편집이나 캔버스 작업에서 시각적 경계가 중요하다. |
| right_click | 오른쪽 버튼을 클릭한다. | context menu가 열린 후의 상태 확인이 필요하다. |
| screenshot | 현재 화면을 관찰한다. | 스킬 figure와 현재 화면을 비교하는 verification 단서가 된다. |
4.2 Benchmark와 metric
평가 벤치마크는 두 축이다. CUA-World는 Writer, Calc, Impress, QGIS, OpenToonz 다섯 도메인을 사용한다. 각 도메인은 train/test split을 갖고, train split은 Stage 2 patch를 만들 때 사용된다. test split은 held-out evaluation으로 남겨, UI exploration이 단순히 같은 task를 외운 것이 아닌지 확인한다.
OSExpert-Eval은 LibreOffice, GIMP, Tableau 세 도메인을 제공한다. 여기서는 unseen UI와 장기 compositional workflow가 강조된다. VISUALSKILL이 특히 GIMP와 Tableau에서 이득을 보인다는 결과는, visually intensive tool에서 스킬 figure가 단순 설명 이상의 역할을 할 수 있음을 보여 준다.
점수는 도메인별 평균으로 보고되며 모두 0에서 1 사이로 정규화된다. CUA-World는 checklist-based VLM verifier가 task를 여러 weighted subtask로 나눠 부분 점수를 주고, OSExpert-Eval은 benchmark가 제공하는 deterministic state verifier가 성공 여부를 반환한다. 서로 다른 채점 방식이지만 도메인 평균과 전체 평균을 나란히 둬 비교한다.
4.3 Skill condition과 matched control
실험 조건은 no-skill baseline, Stage 1 text, Stage 1 VISUALSKILL, Stage 2 text, Stage 2 VISUALSKILL로 나뉜다. Stage 1 조건은 공식 문서 기반 스킬만 사용하고, Stage 2 조건은 UI exploration으로 보강된 스킬을 사용한다. text와 VISUALSKILL은 같은 단계 안에서 같은 topic과 같은 원천 자료를 공유한다.
이 matched control 설계가 없으면 결과 해석이 흐려진다. 멀티모달 스킬이 더 많은 topic을 포함하거나 더 상세한 절차를 담았다면, 성능 차이가 figure 때문인지 coverage 때문인지 알기 어렵다. 논문은 같은 source context에서 두 버전을 동시에 만들고, topic set을 공유하게 하여 이 문제를 줄인다.
다만 matched control은 완벽한 통제를 의미하지 않는다. 그림 정보를 텍스트로 verbalize하는 과정에서도 압축과 강조 선택이 들어가고, 이미지가 tool result에 포함되는 방식은 agent의 attention과 행동 계획을 동시에 바꾼다. 따라서 결과는 “순수 modality 효과”라기보다, 시각 자료 보존과 로딩 프로토콜을 결합한 시스템 효과로 읽는 편이 정확하다.
5. 주요 실험 결과: Stage 2 VISUALSKILL은 평균 0.456까지 끌어올린다
5.1 전체 성능 표
Table 1은 논문의 중심 결과다. No-skill baseline은 전체 평균 0.303이고, Stage 1 VISUALSKILL은 0.363, Stage 2 VISUALSKILL은 0.456이다. Stage 2 text control이 0.373이므로, 같은 Stage 2 자료를 쓰더라도 figure를 보존한 버전이 8.3점 절대 이득을 낸다. 특히 GIMP, Tableau, OpenToonz처럼 화면 요소와 도구 아이콘이 많은 도메인에서 차이가 크다.
| Method | OSExpert LibreOffice | GIMP | Tableau | CUA Writer | Calc | Impress | QGIS | OpenToonz | All Avg |
|---|---|---|---|---|---|---|---|---|---|
| No-skill baseline | 0.292 | 0.167 | 0.100 | 0.135 | 0.512 | 0.345 | 0.660 | 0.210 | 0.303 |
| Stage 1 Text | 0.333 | 0.167 | 0.150 | 0.153 | 0.603 | 0.505 | 0.715 | 0.124 | 0.344 |
| Stage 1 VISUALSKILL | 0.375 | 0.167 | 0.200 | 0.228 | 0.585 | 0.496 | 0.706 | 0.145 | 0.363 |
| Stage 2 Text | 0.417 | 0.167 | 0.150 | 0.225 | 0.620 | 0.509 | 0.708 | 0.185 | 0.373 |
| Stage 2 VISUALSKILL | 0.500 | 0.333 | 0.300 | 0.276 | 0.656 | 0.580 | 0.726 | 0.274 | 0.456 |
먼저 Stage 1만 보아도 스킬의 기본 효과가 확인된다. 전체 평균은 0.303에서 0.363으로 올라간다. 공식 문서에서 채굴한 topic과 절차만으로도 에이전트는 메뉴, 기능, 작업 순서를 더 잘 찾는다. 다만 Stage 1에서 text와 VISUALSKILL의 차이는 0.344 대 0.363으로 상대적으로 작다. 문서 기반 figure는 이미 설명된 메뉴를 보조하는 성격이 강하기 때문이다.
Stage 2에서 변화가 커진다. UI explorer가 live application에서 얻은 screenshot과 상태 전이 정보를 추가하면 VISUALSKILL은 0.456까지 오른다. Stage 2 text도 Stage 1보다 좋아지지만 0.373에 머문다. 논문은 이 차이를 visual figure가 실제 UI element identification과 workflow state verification에 더 직접적으로 기여한 결과로 해석한다.
도메인별로 보면 GIMP는 Stage 2 text가 0.167인데 VISUALSKILL은 0.333이다. Tableau도 0.150에서 0.300으로 오른다. OpenToonz는 0.185에서 0.274로, Writer는 0.225에서 0.276으로 오른다. 이 패턴은 icon, palette, modal dialog처럼 시각 단서가 많은 도메인에서 멀티모달 스킬의 이득이 커진다는 논문 주장과 잘 맞는다.
반대로 Calc나 QGIS처럼 문서화된 절차와 데이터 조작 규칙이 상대적으로 강한 도메인에서는 차이가 작다. Calc는 Stage 2 text가 0.620, VISUALSKILL이 0.656이고 QGIS는 0.708에서 0.726이다. 이 경우에도 이득은 남지만, 화면 figure보다 명령 순서와 데이터 상태 이해가 더 큰 병목으로 보인다.
5.2 도메인별 해석
OSExpert LibreOffice에서는 0.292에서 0.500으로 올라간다. 이 도메인은 문서 편집과 대화상자 조작이 많아 official manual과 live UI screenshot이 모두 도움을 준다. VISUALSKILL은 menu path를 알려 주는 동시에, 실제 대화상자가 어떻게 보여야 하는지 캡처로 제공한다.
GIMP에서는 0.167에서 0.333으로 두 배가 된다. GIMP의 도구는 아이콘과 palette 중심으로 움직이며, 같은 색상이나 브러시 선택이라도 위치와 모양을 잘못 읽으면 action이 어긋난다. 이 결과는 visual reference가 creative tool에서 특히 크게 작용한다는 사례다.
Tableau에서는 0.100에서 0.300으로 오른다. Tableau는 시각 분석 도구라 panel, shelf, drag target, chart state가 많다. 텍스트로만 “필드를 놓는다”라고 설명하면 충분하지 않으며, 스킬 figure가 target region과 성공 상태를 좁혀 준다.
Writer에서는 0.135에서 0.276으로 오른다. Writer는 문서 편집 절차가 익숙해 보여도 실제 task에서는 style dropdown, paragraph dialog, position tab처럼 작은 UI target이 많다. 논문 부록의 Heading 예시는 바로 이 약점을 보여 준다.
Calc에서는 0.512에서 0.656으로 오른다. 초기 baseline이 상대적으로 높지만 스킬 이득이 유지된다. spreadsheet 작업은 formula와 cell range 판단이 중요하므로 text knowledge가 큰 몫을 하고, figure는 메뉴와 formatting workflow에서 보조 역할을 한다.
Impress에서는 0.345에서 0.580으로 큰 폭으로 개선된다. 프레젠테이션 도구는 객체 선택, style panel, slide layout, toolbar state가 얽히므로, visual skill이 현재 선택된 대상과 가능한 조작을 더 잘 구분하게 만든다.
QGIS에서는 0.660에서 0.726으로 오른다. QGIS는 기본 baseline이 높고, 문서화된 작업 흐름이 비교적 강한 도메인이다. 그래도 VISUALSKILL은 layer panel, attribute table, map canvas 주변의 상태 단서를 추가해 작은 이득을 만든다.
OpenToonz에서는 0.210에서 0.274로 올라간다. 애니메이션 도구는 UI가 복잡하고 visual affordance가 많지만, Stage 2에서도 절대 점수는 높지 않다. 이는 figure가 유용하더라도 도메인 자체의 장기 계획과 tool complexity가 별도 병목으로 남는다는 뜻이다.
Figure 5: exam_paper_formatting task에서 header들이 아직 일반 본문 텍스트인 초기 상태.
Figure 5는 Writer 계열 task에서 스킬이 무엇을 확인해야 하는지 보여 준다. 세 개의 header가 아직 일반 본문 텍스트이고, toolbar의 paragraph-style dropdown은 Default Paragraph를 가리킨다. 성공하려면 특정 텍스트 범위를 선택하고 Heading style을 적용해야 하며, 이때 스킬은 어떤 화면 상태가 시작점인지, 어떤 UI control을 열어야 하는지, 적용 뒤 어떤 표시가 바뀌는지를 연결한다.
6. 추가 분석 및 Ablation Study: 그림은 저장보다 로딩 방식에서 더 큰 차이를 만든다
6.1 MCP tool과 Direct Read 비교
논문은 스킬을 폴더로 저장한 뒤 어떻게 읽게 할지도 따로 ablation한다. Direct Read 조건에서는 에이전트가 guide.md를 직접 읽고, 필요한 figure 파일은 추가 Read로 열어야 한다. MCP tool 조건에서는 load_topic 호출 하나가 텍스트와 figure를 교차 순서로 반환한다. 같은 스킬 artifact를 쓰지만, 실제로 figure가 agent context에 들어오는 빈도가 크게 달라진다.
| Method | Load rate | Figures/task | Last @ step | Writer | OpenToonz | QGIS |
|---|---|---|---|---|---|---|
| Direct Read | 92.6% | 0.8 | 1.5 | 0.236 | 0.246 | 0.695 |
| MCP tool | 100% | 7.9 | 10.4 | 0.276 | 0.274 | 0.726 |
Direct Read는 92.6%의 trajectory에서 스킬에 접근하지만 평균 figure 수는 task당 0.8개뿐이다. 마지막 consult도 median step 1.5에 머문다. 에이전트가 초반에 guide 텍스트를 읽고 이후에는 UI가 바뀌어도 다시 참고하지 않는다는 뜻이다. 이 조건에서는 스킬 폴더 안에 image가 있어도 실제 행동 결정으로 들어오는 빈도가 낮다.
MCP tool은 load rate 100%, task당 figure 7.9개, 마지막 consult step 10.4를 보인다. tool result가 문장과 이미지를 함께 반환하므로, 에이전트는 topic을 불러올 때 figure를 별도 비용으로 선택하지 않아도 된다. 성능도 Writer 0.236에서 0.276, OpenToonz 0.246에서 0.274, QGIS 0.695에서 0.726으로 꾸준히 오른다.
이 실험은 VISUALSKILL의 실용적 교훈을 잘 보여 준다. 멀티모달 자료를 저장하는 일과, 그 자료가 실행 중 실제로 호출되게 만드는 일은 다르다. 많은 agent memory 시스템이 저장 품질에 집중하지만, GUI 작업에서는 retrieval interface가 action loop와 얼마나 가까운지까지 성능 변수로 들어간다.
6.2 Stage 1, Stage 2(a), Stage 2(b)의 기여
| Condition | Writer | Calc | Impress | Avg |
|---|---|---|---|---|
| No-skill baseline | 0.135 | 0.512 | 0.345 | 0.331 |
| Stage 1 Text | 0.153 | 0.603 | 0.505 | 0.420 |
| Stage 1 VISUALSKILL | 0.228 | 0.585 | 0.496 | 0.436 |
| Stage 2(a) only VISUALSKILL | 0.236 | 0.608 | 0.543 | 0.462 |
| Stage 2(b) only VISUALSKILL | 0.255 | 0.600 | 0.505 | 0.453 |
| Stage 2 Text full | 0.225 | 0.620 | 0.509 | 0.451 |
| Stage 2 VISUALSKILL full | 0.276 | 0.656 | 0.580 | 0.504 |
Table 3은 Stage별 기여를 CUA-World LibreOffice 도메인에서 분리한다. Stage 1만으로도 평균은 0.331에서 0.436으로 오른다. 공식 문서가 이미 상당한 절차 지식을 담고 있기 때문이다. 그러나 Stage 1 text와 Stage 1 VISUALSKILL의 차이는 0.420 대 0.436으로 제한적이다. manual figure만으로는 live UI에서 마주치는 동적 상태를 충분히 덮지 못한다.
Stage 2(a) free explorer만 추가하면 평균은 0.462가 되고, Stage 2(b) trajectory-targeted explorer만 추가하면 0.453이 된다. 두 경로는 다른 표면을 보강한다. free explorer는 idle 화면의 toolbar와 sidebar를 넓게 훑고, trajectory-targeted explorer는 실제 실패 trace가 드러낸 modal dialog와 메뉴 상태를 집중적으로 보강한다.
두 경로를 합친 full VISUALSKILL은 0.504까지 올라간다. 각각을 단독으로 쓴 것보다 4~5점 더 높고, full text control 0.451보다도 높다. 이 결과는 UI exploration이 단순 데이터 증강을 넘어, 문서 기반 topic을 실제 화면 증거와 연결하는 patch 과정임을 보여 준다.
6.3 실패 trace가 말해 주는 click target 문제
| # | Action | Comment |
|---|---|---|
| 1 | click(75, 118) | 드롭다운 화살표 대신 텍스트 필드를 클릭 |
| 2 | triple_click(...) | 불필요한 반복 선택 |
| 3 | triple_click(...) | 불필요한 반복 선택 |
| 4 | hotkey ctrl+a | Ctrl+A로 우회 |
| 5 | type_text "Heading 2" | highlight된 텍스트를 교체 |
| 6 | verify screenshot | 상태 확인에 action budget 사용 |
| 7 | key_press Return | 실제 적용은 여기서 발생 |
| 8 | verify screenshot | 다시 상태 확인 |
Table 4의 trace는 논문 전체에서 가장 현실적인 실패 사례다. 정답 경로는 드롭다운 화살표를 열고 Heading 2를 고르는 2-action 절차지만, 에이전트는 텍스트 필드를 눌러 불필요한 선택과 입력을 반복한다. 이 차이는 “style dropdown을 열라”는 텍스트 설명만으로는 작은 화살표와 필드 내부를 충분히 분리하지 못한다는 점을 보여 준다.
Figure 6: style dropdown의 작은 화살표를 클릭해 paragraph style 목록이 열린 화면.
Figure 6은 Table 4의 실패가 어떤 화면에서 생기는지 설명한다. 드롭다운의 오른쪽 화살표를 열어야 style 목록이 나타나지만, 좌표가 조금 왼쪽으로 치우치면 텍스트 필드가 focus된다. VISUALSKILL의 reference screenshot은 메뉴가 열린 정상 상태를 보여 주므로, 에이전트가 현재 화면과 비교해 “목록이 열렸는가”를 확인하고 다음 action을 고를 수 있게 해 준다. 이 장면은 좌표 기반 GUI 조작에서 작은 클릭 target이 얼마나 큰 차이를 만드는지 보여 준다.
Figure 7: Heading 1 선택 뒤 dropdown과 status bar가 적용 상태를 보여 주는 화면.
Figure 7은 action 이후 verification의 예다. style menu에서 Heading 1을 고른 뒤 top-left dropdown이 Heading 1로 바뀌고, status bar에는 Heading Numbering Level 1이 보인다. 이런 상태 단서는 언어 설명으로도 적을 수 있지만, 실제 스크린샷과 함께 저장하면 에이전트가 결과 화면을 직접 대조할 수 있다. 이는 VISUALSKILL이 단순 사용법 문서를 넘어 상태 검증 자료라는 점을 보여 준다.
6.4 Cross-model replication이 남긴 경고
| Method | Writer | Calc | Impress | Avg |
|---|---|---|---|---|
| No-skill baseline | 0.652 | 0.553 | 0.467 | 0.538 |
| Text skill | 0.696 | 0.596 | 0.466 | 0.563 |
| Multimodal skill | 0.652 | 0.532 | 0.466 | 0.529 |
논문은 Qwen3-397B 기반 agent로 OSWorld LibreOffice replication도 수행한다. 여기서는 결과가 본문 main table과 다르다. text skill은 평균 0.563으로 no-skill 0.538보다 조금 좋지만, multimodal skill은 0.529로 오히려 낮다. 이 표는 VISUALSKILL의 효과가 모든 모델과 실행 환경에서 자동으로 재현된다고 말하기 어렵게 만든다.
저자들은 main setting의 Claude Opus 4.6에서 얻은 강한 결과와 함께 이 replication을 부록에 둔다. 운영자 입장에서는 이 표가 중요하다. 멀티모달 figure를 제공해도, underlying model이 이미지와 텍스트 guide를 action planning에 안정적으로 통합하지 못하면 이득이 사라질 수 있다. 즉 VISUALSKILL은 스킬 포맷만의 문제를 넘어 모델의 multimodal grounding 능력과 결합된 시스템이다.
이 경고는 실제 배포에도 연결된다. 같은 스킬을 여러 vendor model에서 쓰려면, guide의 이미지 개수, 캡션 길이, tool result 순서, screenshot 해상도, context window 예산을 모두 다시 튜닝해야 할 수 있다. 논문이 제시한 구조는 강력한 출발점이지만, model-agnostic universal recipe로 보기에는 아직 증거가 부족하다.
Figure 8: text-only skill 조건에서 에이전트가 dialog footer의 Save 버튼 대신 title bar 쪽을 클릭한 사례.
Figure 8은 텍스트 전용 스킬이 버튼 위치를 충분히 고정하지 못할 때 생기는 실패를 보여 준다. 설명에는 저장 동작이 있어도, tall dialog의 footer에 있는 실제 Save 버튼과 창 상단 영역을 혼동하면 LibreOffice가 닫히거나 task가 이탈한다. GUI 작업에서는 버튼 이름과 dialog 내부의 상대 위치와 주변 layout이 중요하며, 이 정보는 screenshot으로 보존될 때 더 직접적으로 전달된다. 이 실패는 text guide가 정확한 명사만 제공해도 공간 단서가 빠지면 취약해질 수 있음을 드러낸다.
Figure 9: multimodal skill 조건에서 reference screenshot이 dialog footer의 올바른 Save 버튼을 가리키는 사례.
Figure 9는 같은 작업에서 멀티모달 스킬이 어떻게 실패를 줄이는지 보여 준다. topic guide가 dialog footer의 Save 버튼을 포함한 reference screenshot을 제공하면, 에이전트는 버튼 이름과 위치를 동시에 확인한다. 이 자료는 다음 클릭 좌표를 좁히는 데 쓰이고, 클릭 후 dialog가 닫혔는지 또는 설정이 저장됐는지를 확인하는 사후 상태 판단에도 연결된다. 같은 절차 설명이라도 화면 증거가 붙으면 target 선택과 verification이 모두 구체화된다.
7. 한계점 및 향후 연구 방향: 스킬 포맷보다 평가 가능한 운영 루프가 더 필요하다
7.1 모델 의존성과 멀티모달 grounding
가장 큰 한계는 결과가 특정 agent stack에 강하게 의존한다는 점이다. main result는 Claude Code CLI와 Claude Opus 4.6 기반에서 얻은 것이며, Qwen3-397B replication에서는 multimodal skill이 text skill보다 낮다. 이는 VISUALSKILL의 아이디어가 틀렸다는 뜻은 아니지만, 모든 모델이 figure를 같은 방식으로 action planning에 통합하지는 않는다는 점을 분명히 한다.
모델 의존성은 두 층에서 생긴다. 첫째, 모델이 guide 본문과 figure를 함께 읽고 현재 screenshot과 비교할 수 있어야 한다. 둘째, 그 비교 결과를 좌표 action으로 안정적으로 바꿀 수 있어야 한다. 시각 이해가 좋아도 tool coordinate mapping이 약하면 성능 이득이 작고, 반대로 action이 정확해도 image-text retrieval이 어긋나면 잘못된 topic을 참고할 수 있다.
후속 연구는 모델별로 figure 전달 방식과 retrieval granularity를 분리해 봐야 한다. 예를 들어 같은 VISUALSKILL을 두고 전체 screenshot, crop, annotated crop, bounding box 텍스트, UI tree를 조합해 넣는 조건을 비교할 수 있다. 이를 통해 어떤 모델은 원본 이미지가 좋고, 어떤 모델은 구조화된 visual annotation이 더 좋은지 알 수 있다.
7.2 스킬 생성 비용과 유지보수 비용
Stage 2는 성능을 크게 높이지만 비용도 있다. planner와 여러 worker agent를 띄워 UI region을 탐색하고, training failure trace를 다시 분석해야 한다. 애플리케이션 버전이 바뀌면 screenshot과 menu path가 낡을 수 있으므로, VISUALSKILL은 한 번 만들고 끝나는 문서보다 지속적으로 재검증해야 하는 운영 자산이 된다.
실무에서는 어떤 앱과 어떤 topic에 Stage 2를 적용할지 우선순위를 정해야 한다. 모든 메뉴를 탐색하면 비용이 커지고, 너무 적게 탐색하면 동적 dialog 병목을 놓친다. 논문은 free explorer와 trajectory-targeted explorer를 함께 쓰지만, 실제 서비스에서는 실패 로그와 user complaint를 기반으로 patch 대상을 고르는 triage가 필요하다.
또한 스킬이 커질수록 인덱스 품질이 중요해진다. when-to-use 문장이 흐리면 에이전트가 topic을 놓치거나 필요 없는 guide를 자주 불러온다. 이 문제는 기존 agent skill 운영에서 description trigger가 중요하다는 경험과 같다. VISUALSKILL이 성공하려면 이미지 품질과 topic naming, guide boundary, trigger wording을 함께 관리해야 한다.
7.3 보안과 provenance 문제
GUI 스킬은 애플리케이션 화면을 캡처하므로 보안과 provenance 이슈가 생긴다. 실험에서는 benchmark 환경의 앱을 다루지만, 실제 기업 환경에서는 screenshot 안에 문서 내용, 고객 정보, 계정 이름, 내부 경로가 들어갈 수 있다. 스킬을 파일로 저장하고 MCP tool로 반환하는 구조는 편리하지만, 어떤 화면을 저장해도 되는지 정책이 선행되어야 한다.
공식 문서에서 추출한 figure와 live UI explorer가 캡처한 screenshot은 provenance가 다르다. 전자는 공개 manual에서 온 자료이고, 후자는 특정 실행 환경에서 생성된 자료다. 후속 시스템은 guide 안의 각 figure가 어디서 왔는지, 어떤 앱 버전에서 캡처됐는지, 어떤 task 실패를 보강하기 위해 추가됐는지 metadata로 남겨야 한다.
이 provenance는 검증에도 중요하다. 에이전트가 잘못된 figure를 참고해 실패했을 때, 단순히 모델 탓으로 돌릴 수 없다. topic matching이 틀렸는지, figure가 오래됐는지, caption이 모호했는지, MCP result 순서가 좋지 않았는지 추적해야 한다. VISUALSKILL의 다음 단계는 이런 감사 가능한 스킬 운영 루프일 가능성이 크다.
7.4 벤치마크 범위와 실제 업무 적용
논문은 여러 도메인을 포함하지만 여전히 benchmark 중심이다. 실제 업무에서는 앱이 더 자주 업데이트되고, 사용자의 파일 내용과 조직별 template이 다르며, task 성공 기준도 자동 verifier로 깔끔하게 떨어지지 않는다. VISUALSKILL을 그대로 적용하려면, benchmark verifier 대신 사람 검수나 application state diff를 어떻게 결합할지 정해야 한다.
또한 일부 작업은 화면 지식보다 도메인 지식이 더 중요하다. spreadsheet 계산의 의미, GIS layer의 실제 좌표계, Tableau chart 해석처럼 UI 조작과 데이터 의미가 결합되는 경우에는 screenshot만으로 부족하다. 이때는 VISUALSKILL을 데이터 schema, domain documentation, validation script와 함께 읽는 복합 스킬로 확장해야 한다.
마지막으로 장기 작업에서는 스킬 호출 자체가 context와 시간 예산을 잡아먹는다. MCP tool이 figure를 많이 반환하면 action 품질은 좋아질 수 있지만, 매 step마다 큰 이미지를 넣으면 비용이 커진다. 따라서 후속 연구는 “언제 이미지를 가져와야 하는가”와 “어떤 이미지만 다시 가져와야 하는가”를 policy로 학습하거나 규칙화할 필요가 있다.
6.5 어떤 정보가 텍스트에서 이미지로 넘어갈 때 살아남는가
VISUALSKILL의 실험을 조금 더 분해하면, figure가 제공하는 정보는 크게 세 종류다. 첫째는 객체 식별 정보다. 버튼 이름이 같거나 아이콘만 있는 경우, 화면 이미지는 현재 task와 관련된 실제 target을 좁힌다. 둘째는 공간 배치 정보다. 같은 dialog 안에서도 title bar, content field, footer button은 전혀 다른 의미를 갖고, 상대 위치를 아는 것이 좌표 action의 성공률을 높인다. 셋째는 상태 전이 정보다. 조작 전후 화면을 비교할 수 있으면, 에이전트는 다음 단계로 넘어가도 되는지 더 안정적으로 판단한다.
텍스트 전용 스킬도 이 세 정보를 언어로 표현할 수는 있다. 그러나 GUI에서는 “오른쪽 아래”, “작은 화살표”, “두 번째 tab”, “회색으로 비활성화된 입력칸” 같은 표현이 실제 화면에서 여러 후보를 만들 수 있다. 화면 figure가 함께 제공되면 모델은 단어를 해석하는 데서 멈추지 않고, 현재 screenshot과 reference를 대조해 후보를 줄인다. 이 차이가 OpenToonz, GIMP, Tableau처럼 시각 요소가 많은 domain에서 더 크게 나타난다.
또한 figure는 instruction의 길이를 줄인다. 텍스트만으로 UI를 충분히 설명하려면 위치, 모양, 주변 요소, 상태 변화, 예외 상황을 모두 문장으로 풀어야 한다. 그렇게 만든 guide는 길어지고, 에이전트가 중요한 action cue를 놓칠 수 있다. VISUALSKILL은 설명을 짧게 유지하고, 복잡한 배치 정보는 이미지가 담당하게 한다. 이는 context 효율 관점에서도 의미가 있다.
다만 모든 figure가 같은 가치를 갖지는 않는다. 공식 manual의 정적인 screenshot은 메뉴 path를 확인하는 데 좋지만, benchmark task에서 실제로 실패한 지점을 고치는 데는 live UI capture가 더 직접적이다. 논문에서 Stage 2의 이득이 Stage 1보다 큰 것도 이 때문이다. 실무에서는 스킬 안의 figure마다 문서 기반, 탐색 기반, 실패 보정 기반 같은 출처와 목적을 metadata로 구분하는 편이 좋다.
성공적인 figure는 단지 예쁜 화면이 아니다. 에이전트가 다음 action을 선택할 때 후보를 줄여 주거나, action 이후 verifier 역할을 하거나, 비슷한 UI 요소를 구별하게 만드는 화면이어야 한다. 따라서 VISUALSKILL을 만들 때는 이미지 수를 늘리는 것보다, 각 이미지가 어떤 decision point에 연결되는지 명확히 하는 것이 더 중요하다.
이 관점에서 VISUALSKILL은 agent memory와 documentation의 중간 지점에 있다. documentation은 사람이 읽기 좋은 설명이고, memory는 과거 경험을 저장한 자료다. VISUALSKILL의 topic guide는 사람이 쓴 설명과 agent가 캡처한 화면을 합쳐, 실행 중 행동 결정을 보조하는 procedural visual memory로 작동한다.
6.6 지표를 action loop 관점에서 다시 읽기
Table 2의 Load rate와 Figures/task는 단순 사용량 통계처럼 보이지만, 실제로는 action loop 안에서 스킬이 어느 위치에 들어오는지 보여 준다. Direct Read는 스킬을 초반에 한 번 읽는 참고 문서처럼 다루고, MCP tool은 trajectory 중간마다 다시 확인하는 실행 보조 장치처럼 만든다. median last consult가 1.5에서 10.4로 이동했다는 수치는 이 차이를 잘 보여 준다.
컴퓨터 사용 task는 한 번 계획을 세우고 끝나는 문제가 아니다. 첫 화면에서 메뉴를 찾고, 메뉴를 열면 새로운 dialog가 나오며, dialog 안에서 tab을 바꾸면 다시 다른 control이 나타난다. 그래서 스킬은 task 시작점의 background knowledge에 머물면 효과가 제한된다. VISUALSKILL의 load_topic은 UI surface가 바뀔 때마다 관련 guide를 다시 불러오는 방식으로 이 문제를 다룬다.
이 설계는 실패 분석에도 유리하다. 어떤 topic을 언제 불렀는지, 어떤 figure가 반환됐는지, 그 직후 어떤 click이 나갔는지를 기록하면 스킬 품질을 고칠 단서가 생긴다. 예를 들어 figure가 있었는데도 잘못 클릭했다면 이미지 자체보다 caption이나 crop 위치가 문제일 수 있고, topic을 아예 부르지 않았다면 index의 when-to-use 문장이 약할 수 있다.
따라서 후속 benchmark는 최종 성공 점수와 skill-consult trace를 함께 공개하는 쪽으로 갈 필요가 있다. VISUALSKILL은 이 방향을 열어 둔다. 스킬이 언제 load되었는지, 이미지가 몇 장 들어갔는지, 마지막 consult가 몇 step인지 같은 지표는 agent의 내부적 의사결정과 외부 artifact 사이의 연결을 측정하는 첫 단계다.
운영 환경에서는 이 trace가 비용 제어와도 연결된다. 모든 step에서 이미지를 잔뜩 넣으면 성능은 오를 수 있지만 inference cost와 latency가 커진다. 반대로 너무 적게 넣으면 Direct Read처럼 figure가 무시된다. 적절한 지점은 domain, task length, model capability, image resolution에 따라 달라지며, VISUALSKILL은 이 trade-off를 실험할 수 있는 구조를 제공한다.
7.5 실제 도입을 위한 점검표
VISUALSKILL을 실제 조직의 GUI 자동화에 적용하려면 논문 속 pipeline을 그대로 복사하기보다 몇 가지 운영 질문을 먼저 정해야 한다. 아래 표는 논문 결과를 바탕으로 스킬을 만들고 검증할 때 봐야 할 항목을 정리한 것이다. 각 항목은 별도 연구 주제라기보다, 스킬이 오래 살아남기 위해 필요한 관리 표면에 가깝다.
| 점검 항목 | 확인할 질문 | VISUALSKILL과의 연결 |
|---|---|---|
| Topic boundary | 하나의 guide가 너무 넓거나 좁지 않은가? | skill.md 인덱스와 when-to-use 문장의 호출 정확도를 좌우한다. |
| Figure provenance | 이미지가 공식 문서, live exploration, failure patch 중 어디서 왔는가? | 오래된 screenshot과 민감 정보 노출을 구분하는 기준이 된다. |
| State verification | 조작 후 성공 상태를 확인할 reference가 있는가? | 단순 절차 설명에서 실행 검증 자료로 확장된다. |
| Model compatibility | 현재 모델이 image-text-action 연결을 잘 수행하는가? | Qwen3 replication처럼 모델별 차이가 발생할 수 있다. |
| Refresh policy | 앱 업데이트 뒤 figure를 언제 갱신하는가? | GUI 스킬은 애플리케이션 버전과 화면 theme에 민감하다. |
| Cost budget | 한 task에서 평균 몇 장의 figure를 허용할 것인가? | MCP tool의 강점과 context 비용 사이 균형을 정한다. |
첫 번째 점검 항목은 topic boundary다. topic이 너무 크면 load_topic 결과가 길어져 핵심 figure가 묻히고, 너무 작으면 에이전트가 여러 topic을 오가며 overhead를 쓴다. 논문은 공식 문서의 table of contents를 초기 topic set으로 쓰지만, 실제 운영에서는 실패 로그를 보며 topic을 쪼개거나 합치는 과정이 필요하다.
두 번째는 figure provenance다. 공식 manual에서 온 이미지는 공개성과 안정성이 높지만 실제 실행 환경과 다를 수 있다. live exploration 이미지는 현재 앱 상태를 잘 담지만 민감 정보와 환경 의존성을 가질 수 있다. failure patch 이미지는 특정 문제를 고치는 데 강하지만, 너무 많은 patch가 쌓이면 guide가 복잡해진다. 이 구분이 metadata에 남아야 장기 유지보수가 가능하다.
세 번째는 상태 검증이다. GUI 자동화에서 성공은 “버튼을 눌렀다”보다 “버튼을 누른 뒤 올바른 상태가 되었다”에 가깝다. VISUALSKILL의 figure는 pre-action target과 post-action confirmation까지 담을 수 있다. 실제 시스템은 guide마다 target identification figure와 success verification figure를 나눠 관리하는 방식으로 발전할 수 있다.
네 번째는 모델 호환성이다. Claude Opus 4.6에서는 figure 보존이 강하게 작동했지만, Qwen3 replication은 반대 신호를 냈다. 따라서 같은 VISUALSKILL을 여러 모델에 쓰려면, 모델별로 image size, crop granularity, caption density, tool result order를 조절하는 compatibility test가 필요하다.
다섯 번째는 refresh policy다. 앱 버전이 바뀌거나 toolbar layout이 달라지면 오래된 figure는 잘못된 action을 유도할 수 있다. 스킬은 문서 파일처럼 보이지만 실제로는 test fixture와 비슷하다. 주기적으로 대표 task를 돌리고, 현재 screenshot과 stored figure가 크게 달라진 topic을 stale로 표시해야 한다.
여섯 번째는 비용 예산이다. 논문에서 MCP tool은 평균 7.9개 figure를 반환하며 성능을 올렸지만, 실제 서비스에서는 latency와 토큰 비용이 중요하다. 사용자가 기다릴 수 있는 시간, task의 중요도, 실패 비용에 따라 figure budget을 다르게 설정하는 정책이 필요하다.
7.6 벤치마크 결과를 제품 환경으로 옮길 때의 주의점
CUA-World와 OSExpert-Eval은 연구용으로 잘 정리된 환경을 제공하지만, 제품 환경에는 추가 변수가 많다. 사용자는 같은 메뉴를 다른 언어 locale로 보고, 화면 배율이 다르며, 테마가 dark mode일 수 있고, 파일 내용도 매번 달라진다. VISUALSKILL의 figure가 이런 변형에도 견디려면 원본 screenshot만 저장하는 방식에서 한 단계 더 나아가야 한다.
예를 들어 guide figure와 함께 UI element의 semantic label, 가능한 alternative labels, bounding-box description을 저장하면 locale이나 theme 변화에 조금 더 강해질 수 있다. 반대로 너무 많은 annotation을 붙이면 text-only skill과 비슷하게 길어지고, 이미지의 직관성이 줄어든다. 어떤 annotation이 모델별로 효과적인지는 아직 열린 문제다.
또한 benchmark의 verifier는 task 성공을 자동으로 판정하지만, 실제 업무에서는 성공 조건이 더 흐릿하다. 사용자가 원하는 문서 스타일, 조직 내부 양식, 데이터 품질 규칙은 자동 verifier에 잘 들어가지 않는다. VISUALSKILL을 업무에 쓰려면 task-specific check와 human review 위치를 함께 설계해야 한다.
마지막으로 스킬은 agent 권한과 연결된다. GUI 에이전트가 파일을 열고 저장하고 외부 서비스에 접속할 수 있다면, 잘못된 figure나 오래된 절차가 실제 side effect로 이어질 수 있다. 따라서 스킬 로딩은 편의 기능이면서 동시에 guardrail 표면이다. 어떤 topic은 읽기 전용 작업에서만 허용하고, 저장이나 삭제가 포함된 topic은 별도 confirmation을 요구하는 식의 정책이 필요하다.
8. 내 해석: 약점 하나와 내가 먼저 붙여볼 후속 제안
나는 이 논문을 [[concepts/agent-skills]]에서 다루던 reusable workflow 포맷이 GUI 에이전트 쪽으로 확장되는 사례로 읽었다. 기존 스킬은 “언제 어떤 절차를 실행할지”를 안정화하는 데 강했고, VISUALSKILL은 여기에 “그 절차를 화면에서 어떻게 식별하고 검증할지”를 붙인다. [[concepts/computer-use-agent-reliability]] 관점에서 보면, 같은 task를 반복 실행할 때 가장 먼저 깨지는 부분이 바로 작은 UI target과 상태 확인이므로 문제 설정은 꽤 설득력 있다.
내가 가장 걸리는 약점은 cross-model 증거다. main result에서는 Claude Opus 4.6 기반 agent가 강하게 좋아지지만, Qwen3-397B replication에서는 multimodal skill이 text skill보다 낮다. 이 표가 부록에 있어도 운영 관점에서는 핵심 경고다. VISUALSKILL이 agent skill 포맷의 일반 해법이라면, 적어도 두세 종류의 multimodal model에서 figure loading 정책을 다르게 했을 때 어느 조건이 실패하는지 더 세밀하게 보여 줘야 한다.
특히 modality 차이를 주장하려면 “이미지를 넣었다”는 조건만으로는 부족하다. 모델이 image를 실제로 참조했는지, 참조했다면 현재 screenshot과 어떤 부분을 matching했는지, action이 바뀐 step이 어디인지 추적해야 한다. 논문은 load rate와 figures per task를 보고하지만, 내가 보고 싶은 것은 figure reference가 action log의 어떤 decision point를 바꿨는지에 대한 causal trace다.
내가 이 작업을 확장한다면 먼저 visual reference audit를 붙여볼 것 같다. 각 load_topic 호출에 대해 반환된 figure, 현재 screenshot crop, 최종 click coordinate, 사후 verifier 결과를 묶고, 성공 trajectory와 실패 trajectory에서 어떤 figure가 실제로 쓰였는지 사람이 확인 가능한 로그로 남긴다. 이렇게 하면 스킬이 좋아서 성공한 것인지, 모델이 운 좋게 다른 지식으로 성공한 것인지 구분하기 쉬워진다.
두 번째 후속 제안은 retrieval policy다. 지금 구조는 topic이 맞으면 그 topic의 figure를 비교적 함께 전달하는 쪽에 가깝다. 그러나 실제 장기 작업에서는 figure를 모두 넣을수록 비용이 커진다. 현재 화면과 guide figure 사이의 visual similarity, 최근 실패 유형, action type을 기준으로 “이번 step에는 crop 하나만”, “이번 step에는 full dialog screenshot까지”처럼 loading granularity를 조절하면 더 실용적인 시스템이 될 수 있다.
기존 위키의 [[concepts/multimodal-agent-memory]]와 연결하면, VISUALSKILL은 장기 기억이라기보다 실행 중 참조되는 application memory에 가깝다. 그래서 단순 저장보다 versioning과 freshness가 중요하다. 앱 버전, OS theme, 화면 해상도, locale이 바뀌면 같은 figure도 오히려 잘못된 단서가 될 수 있다. 후속 시스템은 스킬 figure를 test fixture처럼 주기적으로 재생성하고, 오래된 figure를 자동으로 표시하는 운영 루프까지 포함해야 한다.
8.1 기존 리뷰 축과의 연결: 스킬, 메모리, 신뢰성
이 논문은 이전에 정리한 agent skill 계열 논문들과 직접 이어진다. SkillCAT은 trajectory evidence와 replay validation으로 스킬을 갱신하는 쪽에 초점을 두었고, VISUALSKILL은 GUI 화면 증거를 스킬 본문에 어떻게 남길지에 초점을 둔다. 둘을 함께 보면 스킬은 더 이상 사람이 적어 둔 tips 모음 수준을 넘어, 실행 로그와 검증 자료가 계속 붙는 agent 운영 자산으로 바뀌고 있다.
또한 MemEye나 멀티모달 에이전트 메모리 논의와도 겹친다. 그쪽은 이미지와 상태 기록을 장기 기억에 넣을 때 어떤 표현이 좋은지 묻고, VISUALSKILL은 특정 애플리케이션의 절차 지식 안에 어떤 화면 자료를 넣어야 하는지 묻는다. 질문의 범위는 다르지만, caption만 남기면 pixel-level 단서를 잃고 원본 이미지만 남기면 retrieval policy가 어려워진다는 점은 같다.
Computer-use agent reliability 관점에서는 VISUALSKILL이 repeated failure를 줄이는 한 가지 방법으로 보인다. 같은 작업을 다시 수행할 때 모델이 매번 새로 추론하지 않아도, 검증된 topic guide와 reference screenshot을 재사용할 수 있기 때문이다. 특히 실패가 특정 UI surface에서 반복된다면, 해당 surface를 patch하는 방식은 reliability 개선의 가장 직접적인 intervention이 된다.
다만 이 연결은 “스킬이 많을수록 좋다”는 방향으로 읽으면 위험하다. 스킬이 많아질수록 잘못된 topic을 고르거나 오래된 figure를 불러올 가능성도 커진다. VISUALSKILL은 멀티모달 스킬의 가능성을 보여 주지만, 동시에 skill index와 freshness 관리가 agent reliability의 일부라는 사실도 드러낸다.
8.2 수치 해석: 평균 점수 뒤에 숨은 domain mix
전체 평균 0.456이라는 숫자는 인상적이지만, domain mix를 같이 봐야 한다. QGIS는 baseline부터 0.660으로 높고 Stage 2 VISUALSKILL도 0.726이다. 반면 GIMP는 baseline 0.167에서 0.333으로 두 배가 되었지만 절대 점수는 여전히 낮다. 따라서 평균 향상은 쉬운 도메인에서의 작은 개선과 어려운 도메인에서의 큰 상대 개선이 섞인 결과다.
OpenToonz도 비슷하다. Stage 2 VISUALSKILL이 text control보다 8.9점 높지만 최종 점수는 0.274다. 이는 visual figure가 실제로 도움을 주더라도, 애니메이션 도구의 장기 workflow와 도메인 특수성이 남는다는 뜻이다. 스킬이 UI 단서를 보완해도 high-level planning, undo recovery, file state management까지 한꺼번에 해결하지는 못한다.
LibreOffice 계열은 더 미묘하다. Writer, Calc, Impress는 모두 Stage 2 VISUALSKILL에서 좋아지지만 개선 양상이 다르다. Writer는 작은 UI target과 style dialog가 문제이고, Calc는 데이터 조작과 공식/범위 이해가 섞이며, Impress는 객체 선택과 layout 상태가 얽힌다. 같은 office suite 안에서도 figure가 도와주는 지점이 다르므로, domain 평균만으로 스킬 품질을 판단하면 세부 병목을 놓친다.
OSExpert-Eval의 GIMP와 Tableau 향상은 VISUALSKILL의 강점을 잘 보여 주는 동시에, 평가 데이터가 작다는 점도 고려해야 한다. GIMP는 task count가 6개이고 Tableau는 20개다. 절대 점수 차이가 크더라도 task 구성에 민감할 수 있으므로, 후속 연구에서는 더 많은 visually intensive task를 모아 confidence interval이나 bootstrap 분석을 함께 제시하는 편이 좋다.
그럼에도 이 표가 유용한 이유는 모든 domain에서 Stage 2 VISUALSKILL이 Stage 2 text보다 낮은 경우가 없다는 점이다. main setting 안에서는 이득이 특정 한두 domain에만 몰리지 않고, text control 대비 8개 domain 전체에서 유지된다. 이는 modality 보존과 MCP loading이 일반적인 GUI 작업 표면에 넓게 작동할 가능성을 보여 준다.
8.3 스킬 생성 pipeline을 데이터셋 구축 관점에서 보기
VISUALSKILL의 Stage 1과 Stage 2는 모델 성능을 높이는 기법이면서 동시에 데이터셋 구축 pipeline이다. Stage 1은 공식 문서를 topic 구조와 figure가 있는 guide로 변환하고, Stage 2는 실제 앱 실행을 통해 부족한 UI 상태를 수집한다. 이 과정을 반복하면 애플리케이션별로 사람이 읽는 문서와 agent가 쓰는 실행 자료가 분리된 형태로 축적된다.
이때 중요한 것은 수집 단위다. 일반적인 화면 캡처 데이터셋은 task screenshot과 action pair를 많이 모으지만, VISUALSKILL은 topic 단위 guide를 만든다. 즉 개별 trajectory를 그대로 저장하기보다 여러 task에서 재사용 가능한 UI 지식을 추출한다. 이 차이 때문에 스킬은 train task에만 맞춘 memo보다 test task에서도 쓰일 수 있는 abstraction을 목표로 한다.
Stage 2(b)의 trajectory-targeted explorer는 실패 데이터 활용 방식도 흥미롭다. 실패 trace를 그냥 imitation target으로 쓰지 않고, 어떤 UI region을 더 문서화해야 하는지 알려 주는 신호로 사용한다. 이는 agent failure가 새로운 training example 대신 skill repair request로 바뀌는 구조다. 운영 환경에서는 사용자 실패 신고나 support ticket도 비슷한 역할을 할 수 있다.
향후에는 이 pipeline에 품질 라벨을 붙일 수 있다. 각 guide가 어떤 task에서 호출됐는지, 호출 후 성공률이 올랐는지, figure를 추가한 뒤 어떤 failure가 줄었는지 기록하면, 스킬 자체를 평가하고 정렬하는 데이터가 된다. 그 단계에 가면 agent skill은 문서 생성물보다 지속적으로 측정되는 software artifact가 된다.
또한 VISUALSKILL은 스킬 작성자의 역할을 바꾼다. 사람이 모든 절차를 처음부터 쓰기보다, 공식 문서와 live UI를 바탕으로 생성된 guide를 검토하고, 잘못된 topic boundary나 민감한 screenshot을 고치는 curator 역할을 맡게 된다. 이는 대규모 앱 지원을 위한 현실적인 방향이다.
8.4 내가 보고 싶은 추가 실험
첫 번째 추가 실험은 figure ablation의 더 세밀한 버전이다. 현재는 text-only와 multimodal을 비교하지만, figure 종류별 효과는 분리되지 않는다. manual figure만, live idle figure만, trajectory-targeted figure만, post-action verification figure만 남기는 조건을 만들면 어떤 visual evidence가 점수를 가장 많이 올리는지 알 수 있다.
두 번째는 retrieval timing 실험이다. 같은 VISUALSKILL을 두고 task 시작 시 한 번만 load하는 조건, 매 step마다 topic matching을 허용하는 조건, 화면 변화가 감지될 때만 reload하는 조건을 비교할 수 있다. 이 실험은 비용과 성능의 균형을 정하는 데 중요하다. 특히 production agent는 매 step image loading을 감당하기 어렵기 때문이다.
세 번째는 model family별 calibration이다. Claude, Qwen, Gemini, GPT 계열이 같은 figure를 어떻게 활용하는지 비교하고, 각 모델에 맞는 caption 길이와 crop 크기를 찾을 필요가 있다. Qwen3 결과는 이 질문을 부록 수준에 남겨 두기보다 본문 핵심 실험으로 올려야 할 만큼 중요하다.
네 번째는 stale skill stress test다. 앱 버전, OS theme, language locale, window size를 바꾼 뒤 같은 VISUALSKILL이 얼마나 버티는지 측정할 수 있다. GUI 스킬은 환경 변화에 취약하므로, 실제 사용 가능성을 보려면 fresh benchmark보다 stale benchmark가 더 까다로운 평가가 된다.
다섯 번째는 human-in-the-loop repair 비용 측정이다. Stage 2 explorer가 만든 guide를 사람이 검토해 승인하는 데 얼마나 시간이 걸리는지, 사람이 고친 guide가 자동 생성 guide보다 얼마나 안정적인지 봐야 한다. 스킬이 운영 자산이라면 생성 성능과 유지보수 비용도 결과의 일부다.
9. 결론: 멀티모달 스킬은 GUI 에이전트의 절차 지식을 화면 증거와 묶는다
VISUALSKILL의 핵심 기여는 GUI 에이전트가 쓰는 스킬을 텍스트 문서에서 멀티모달 실행 보조 장치로 바꾼 데 있다. 스킬은 앱별 index와 topic guide로 구성되고, guide는 절차 텍스트와 UI figure를 함께 담는다. 에이전트는 load_topic MCP tool을 통해 필요한 topic만 불러오며, tool result는 문장과 이미지를 함께 제공한다.
실험 결과는 이 설계가 실제 benchmark 점수로 이어질 수 있음을 보여 준다. 두 CUA benchmark에서 Stage 2 VISUALSKILL은 no-skill baseline보다 15.3점 높고, 같은 source content에서 만든 Stage 2 text control보다 8.3점 높다. GIMP, Tableau, OpenToonz처럼 화면 요소가 많은 도메인에서 특히 강한 이득이 나온다.
또한 논문은 스킬 저장 형식만으로는 부족하다는 점을 강조한다. Direct Read로 같은 스킬을 읽게 하면 figure가 거의 불러와지지 않고, MCP tool로 topic 텍스트와 이미지를 함께 반환해야 figure가 행동 loop에 들어온다. 멀티모달 자료를 어떻게 검색하고 어떤 순서로 전달하는지가 성능 변수로 작동한다.
한계도 분명하다. Qwen3-397B replication에서는 multimodal skill이 더 좋지 않았고, Stage 2 exploration은 비용과 유지보수 부담이 있다. 실제 배포에서는 앱 버전, 보안, provenance, context 비용까지 함께 봐야 한다. 따라서 VISUALSKILL은 완성된 일반 해법이라기보다, GUI 에이전트용 스킬을 어떻게 설계하고 평가해야 하는지 보여 주는 강한 기준선에 가깝다.
그래도 방향성은 명확하다. 에이전트가 화면을 보며 행동한다면, 그 에이전트가 읽는 지식도 화면 증거를 포함해야 한다. 절차는 텍스트로 압축하고, 식별과 검증은 figure로 보존하며, 둘을 topic 단위 MCP 호출로 묶는 구조가 향후 computer-use agent 운영에서 중요한 설계 패턴이 될 수 있다.
9.1 운영 관점에서 남는 설계 원칙
첫째, GUI 스킬은 절차와 증거를 분리해 저장해야 한다. 절차는 어떤 메뉴를 열고 어떤 값을 넣을지 알려 주지만, 증거는 현재 화면이 그 절차를 수행할 수 있는 상태인지 확인한다. VISUALSKILL은 이 두 요소를 같은 guide 안에 두되, 문장과 이미지를 교차시키는 방식으로 에이전트가 둘을 함께 소비하게 만든다.
둘째, 스킬은 task 시작 전에 읽는 배경 문서에 머물지 않고 trajectory 중간에 다시 여는 참조물이어야 한다. UI는 action마다 바뀌고, 특히 modal dialog나 dropdown은 특정 순간에만 보인다. load_topic이 마지막 consult step을 뒤로 밀어낸다는 결과는, 스킬이 action loop 안으로 들어갈 때 비로소 화면 지식으로 작동한다는 점을 보여 준다.
셋째, figure는 많을수록 좋은 자료라는 양적 목표보다 decision point에 연결된 자료여야 한다. 어떤 이미지는 target click을 좁히고, 어떤 이미지는 사후 상태를 확인하며, 어떤 이미지는 text-only 설명의 애매함을 줄인다. guide 작성자는 각 figure가 어떤 행동 판단을 돕는지 caption과 주변 문장으로 명확히 해야 한다.
넷째, 실패 trace는 스킬을 고치는 입력이다. 에이전트가 특정 메뉴에서 반복적으로 헤매면, 그 지점을 모델에게 더 많이 훈련시키는 방법도 있지만, VISUALSKILL 관점에서는 해당 UI region을 새 guide나 figure로 보강하는 방법이 먼저 떠오른다. 이 방식은 실패를 재사용 가능한 운영 지식으로 바꾼다.
다섯째, 스킬의 성능은 모델과 독립적으로 고정되지 않는다. 같은 figure라도 모델이 현재 screenshot과 reference를 잘 맞추지 못하면 오히려 방해가 될 수 있다. 따라서 스킬 라이브러리를 운영할 때는 model upgrade나 vendor 변경 때마다 대표 task regression을 돌려야 한다.
여섯째, 멀티모달 스킬은 보안 정책을 요구한다. 화면 캡처는 UI 지식이면서 동시에 민감한 업무 흔적일 수 있다. 공식 문서 이미지는 비교적 안전하지만 live explorer screenshot은 환경별 정보를 담는다. 어떤 화면을 저장할 수 있고, 어떤 화면은 crop이나 redaction을 거쳐야 하는지 정책이 없으면 스킬이 위험한 내부 자료 저장소가 될 수 있다.
일곱째, 스킬은 freshness를 관리해야 한다. 문서 기반 지식도 앱 업데이트로 낡고, live screenshot은 테마나 창 크기 변화로 어긋난다. VISUALSKILL이 장기적으로 유용하려면 guide마다 마지막 검증 날짜, 앱 버전, 실패율 변화를 남기고 stale topic을 자동으로 다시 캡처하는 절차가 필요하다.
이 원칙들을 합치면 VISUALSKILL은 단일 논문의 기법을 넘어, GUI 에이전트 운영에서 필요한 스킬 생명주기를 제안한다. 생성, 호출, 행동, 검증, 실패 분석, 갱신이 하나의 루프로 묶여야 하며, 각 단계가 로그와 metadata로 남아야 다음 개선이 가능하다.
9.2 이 논문이 남기는 연구 질문
첫 번째 질문은 시각 증거의 최소 단위다. 전체 화면을 넣으면 맥락은 풍부하지만 비용이 크고, crop만 넣으면 target은 명확하지만 주변 상태를 잃을 수 있다. VISUALSKILL은 여러 figure를 guide에 붙이는 방식을 택했지만, 어떤 크기와 해상도가 행동 정확도와 비용의 균형점인지는 아직 체계적으로 측정되지 않았다.
두 번째 질문은 언어 캡션과 이미지의 역할 분담이다. 이미지가 있더라도 caption이 너무 약하면 모델이 무엇을 봐야 하는지 놓칠 수 있고, caption이 너무 길면 텍스트 전용 guide와 비슷해져 figure의 장점이 흐려진다. 좋은 guide는 화면을 대체하는 설명보다, 현재 action에 필요한 관찰 포인트를 짚는 짧은 해설을 가져야 한다.
세 번째 질문은 스킬 신뢰도 추정이다. 에이전트가 어떤 topic을 불렀을 때 그 guide가 현재 앱 버전과 화면 상태에 맞는지 confidence를 계산할 수 있다면, 낮은 confidence에서는 추가 screenshot을 요구하거나 사람 확인을 요청할 수 있다. 이 장치가 붙으면 VISUALSKILL은 단순 참조 자료에서 안전한 실행 제어 장치로 발전할 수 있다.
이 논문을 실제 시스템 설계로 옮길 때 핵심은 스킬을 프롬프트 부록으로 취급하지 않는 것이다. 스킬은 화면 증거, 호출 로그, 실패 분석, 갱신 정책이 함께 움직이는 실행 인프라에 가깝다.
10. 요약 정리: VISUALSKILL에서 가져갈 핵심 포인트
- VISUALSKILL은 computer-use agent가 애플리케이션별 절차 지식과 UI figure를 함께 불러오도록 만든 멀티모달 스킬 포맷이다.
- 스킬은 중앙 skill.md 인덱스와 topic별 guide로 구성되며, 각 guide는 텍스트 본문 $p_t$와 화면 figure 집합 $F_t$를 함께 가진다.
- Stage 1은 공식 문서에서 topic, 텍스트, figure를 채굴하고, Stage 2는 live UI exploration과 실패 trace 분석으로 동적 화면 상태를 보강한다.
- Claude Code CLI와 Claude Opus 4.6 기반 실험에서 Stage 2 VISUALSKILL은 전체 평균 0.456을 기록해 no-skill 0.303보다 15.3점 높았다.
- 같은 source content에서 만든 Stage 2 text-only control은 0.373에 머물러, figure 보존과 멀티모달 로딩이 8.3점의 추가 이득을 만들었다.
- MCP load_topic 도구는 텍스트와 이미지를 함께 반환해 Direct Read보다 figure 사용량을 크게 늘렸고, Writer, OpenToonz, QGIS 점수를 모두 개선했다.
- 이득은 GIMP, Tableau, OpenToonz처럼 아이콘, palette, dialog, layout 단서가 많은 도메인에서 특히 크게 나타났다.
- Qwen3-397B replication에서는 multimodal skill이 text skill보다 낮아, 효과가 모델의 image-text-action grounding 능력에 의존한다는 한계가 남는다.
- 실제 배포에서는 스킬 figure의 출처, 앱 버전, 보안, 오래된 screenshot 관리, context 비용을 함께 추적하는 운영 루프가 필요하다.