KnowAct-GUIClaw: 경험 기반 메모리와 자체 진화 스킬을 갖춘 크로스플랫폼 GUI 개인비서 프레임워크

GUI 중심 작업은 스크린 상태의 불완전성과 앱 간 값 전달 문제 때문에 일반 API 기반 자동화 방법으로는 안정적 수행이 어렵다. KnowAct-GUIClaw는 실행 궤적을 구조화된 메모리와 파라미터화된 스킬로 전환해 동일한 실수를 반복하는 비용을 줄이고 재사용 가능한 동작을 확보함으로써 실전형 개인비서의 장기 신뢰성을 개선했다. 이 접근은 모바일, 데스크톱, HarmonyOS 등 이기종 환경에서의 교차 플랫폼 적응과 경험 전이가 가능하다는 점에서 실무적 의미가 있다.

GUI 자동화 문제는 내부 장치 상태를 직접 관찰할 수 없고 스크린샷이나 접근성 트리 같은 단편적 관찰만 얻을 수 있다는 점에서 부분 관찰 POMDP 특성이 있다. 이 때문에 단일 실행에서 얻은 화면 로그만으로는 장기 과제를 안정적으로 수행하기 어렵고, 앱 간 중간값을 잃지 않기 위한 명시적 데이터 전달과 체크포인트가 필요하다.

KnowAct-GUIClaw은 문제를 두 계층으로 분리해 해결한다. 상위의 호스트는 대화 상태, 사용자 프로필, 라우팅 메모리와 같은 장기 문맥을 유지하며 요청을 서브태스크로 분해하고 각 서브태스크에 필요한 입력·출력 계약을 선언한다. 하위의 GUI 실행기는 시각적 관찰을 기반으로 정규화된 액션(탭·입력·스와이프 등)과 검증된 스킬·딥링크를 실행하며 각 스킬 단계에 대해 상태 계약을 체크해 안전한 재사용을 보장한다.

실행 궤적을 그대로 저장하는 대신, 반영 단계에서 궤적을 요약하고 반복 가능한 절차를 추출해 스킬 라이브러리로 변환한다. 이 스킬은 플랫폼·앱 범위를 포함한 메타정보와 상태 검증을 갖추고 있어 이후 실행에서 빠른 프리픽스로 쓰일 수 있으며 실패하면 수리 과정을 통해 점진적으로 개선된다. 이 방식은 동일 모델이나 다른 모델로의 지식 전이를 가능하게 하고, 불필요한 시각 관찰 비용을 줄여 성공률과 효율성을 동시에 개선한다.

전체 접근은 Know, Route, Act, Reflect 네 단계로 구성된 폐쇄형 루프이다. Know 단계에서는 과거 실행에서 유도된 경험 메모리와 정책 메모리를 능동적으로 회수해 호스트의 라우팅·가정·앱 후보 선택에 advisory 컨텍스트로 제공하며, 필요할 때만 GUI 태스크를 발행해 불필요한 GUI 호출을 줄였다.

Route 단계에서는 입력 명세와 출력 명세를 포함한 서브태스크 튜플 (g_i, h_i, I_i, O_i)을 생성하고, 블랙보드에 타입화된 값만 기록하도록 하였다. 이 계약 기반 라우팅은 교차 앱 비교·수집 작업에서 중간값 누락과 추론 기반 가짜 값을 방지하고, 서브태스크별로 관련 메모리와 스킬을 재검색하게 하여 컨텍스트 오염을 줄인다.

Act 단계는 하이브리드 동작 공간 A = A_gui ∪ A_skill ∪ A_shortcut ∪ A_ask 위에서 observe–reason–act 루프를 반복 실행한다. 스킬은 재사용 가능한 행동 프리픽스로 저장되고 각 단계는 결정적 상태 계약이나 시각 검증을 통해 적용 여부를 판단한다. 딥링크와 인텐트는 검증된 경우에만 하나의 스텝으로 취급해 긴 네비게이션을 우회할 수 있게 설계했다.

Reflect 단계에서는 궤적 요약, 성공·실패 유도, 스킬 추출과 수리 정책을 적용한다. 재사용 스킬 실패 시에는 해당 스킬을 우선적으로 수리하고, 충분히 성공적인 새로운 프리픽스가 발견되면 이를 클러스터링해 우선순위와 신뢰도 카운터를 기록해 retrieval 우선순위로 활용한다. 또한 단기 블랙보드의 타입화 기록과 장기 경험 메모리는 라우팅과 실행 시 모두 advisory로 쓰인다.

MobileWorld GUI-Only 벤치마크에서 Kimi-K2.6 기반의 KnowAct-GUIClaw는 호스트·메모리·스킬 조합으로 단일 실행 성공률 64.1%를 기록해 표에 제시된 공개 베이스라인과 비교 시 최상위 성능을 보였다. 동일한 프레임워크를 Qwen3.5-35B-A3B에 적용하면 베이스 24.8%에서 호스트·메모리 적용으로 34.5%, 스킬까지 활성화하면 37.9%로 증가했고, Kimi에서 추출한 경험·스킬을 전이하면 41.0%에 도달해 모델 간 전이 이득을 확인했다.

효율성 측정에서 호스트와 메모리 도입은 GUI 호출 횟수와 토큰 총량을 크게 증가시키지 않으면서 성공률을 끌어올렸고, 스킬 활성화는 평균 GUI 단계와 총 토큰을 각각 약 3단계, 5~6% 절감시키며 실행 비용 대비 성공률을 개선했다. 반복 시도 상한(pass@3)에서도 호스트·스킬 조합은 안정적으로 향상된 성능을 보였고 Kimi 기반 설정이 특히 강한 성능을 보였다.

AndroidDaily와 크로스플랫폼 실험에서 본 시스템은 분해·검증·외부 도구 결합이 요구되는 복잡·분석형 작업에서 상대적으로 큰 성능 향상을 보였고 HarmonyOS와 Windows에서도 각각 76.2%와 70.0%의 사례별 성공률을 달성했으나 일부 시스템-UI·타이밍·기하학적 제어에서 여전히 실패 사례가 존재했다.

전체 아키텍처는 호스트, 라우터(blackboard 포함), GUI 실행기, 경험·스킬 저장소로 구성된다. 호스트는 세션 문맥·사용자 프로필·정책 메모리를 유지하고 라우터는 서브태스크 튜플(g_i,h_i,I_i,O_i)을 생성해 블랙보드 계약을 강제한다. GUI 실행기는 스크린샷·접근성 트리·앱 ID·행동 이력을 관찰하여 정규화된 액션을 생성하고 실행 결과를 기록한다.

수학적 표기에서 GUI 실행은 부분 관찰 POMDP로 모델링되며 각 서브태스크의 실행은 G(g_i,h_i,B_{i-1}[I_i]) → τ_i 형태로 궤적 τ_i를 생성하고 증거 추출기 E(τ_i,O_i)로부터 선언된 출력이 블랙보드에 기록된다. 선언된 입력·출력이 누락되면 워크플로우는 실패 폐쇄 규칙에 따라 중단되어 이후 태스크의 잘못된 추론을 막는다.

스킬 레코드는 식별자, 플랫폼·앱 범위, 파라미터 자리표시자, 단계별 상태 계약과 성공·실패 카운터를 포함하며 실행 전 applicability 프롬프트로 후보 Top-5를 평가해 적용한다. 스킬 수리는 실패 로그·스크린샷·오류를 인자로 evolution prompt를 호출해 설명·옵션 핸들링·타깃 갱신 등으로 보수하는 절차로 구현되어 있다.

성능 실험은 MobileWorld의 117 GUI-Only 태스크와 AndroidDaily를 사용했고 주평가 지표는 단일 실행 성공률(SR, pass@1)이다. 효율성 지표로는 GUI 단계 수, GUI 태스크 호출 횟수, 실행된 GUI-트레이스 토큰 총량과 호스트 토큰 총량을 측정해 비용-효율 균형을 분석했다.

논문에서 보고된 한계로서 첫째, 일부 플랫폼 특유의 UI 컨트롤(예: 관성 휠 피커, 특정 퀵 세팅 제스처)은 현재 GUI 원시 동작 집합으로 안정적으로 제어하기 어렵다고 명시되어 있다. 둘째, 딥링크·인텐트 후보는 매니페스트 기반으로 발견되지만 런타임 검증이 필요하며 검증 실패 또는 UI 다양성으로 인한 오용 위험이 존재한다고 기술되어 있다. 셋째, 데스크톱 환경에서는 타이밍 민감 알림, 이모지 선택과 같은 시각적-의미적 매핑 및 지속적 기하학 제어 한계로 인한 실패 모드가 남아 있다고 보고되었다.