컴퓨터 사용 에이전트(CUA)는 화면을 보고 추론한 뒤 GUI를 조작하는 AI 모델이다. 버튼 클릭, 메뉴 선택, 텍스트 입력 같은 가상 마우스·키보드 동작으로 웹사이트와 데스크톱 앱을 자동화한다.1
이 방식의 장점은 API가 없는 시스템에도 적용할 수 있다는 점이다. 오래된 업무 시스템이나 별도 연동이 어려운 도구에서도 에이전트가 사람이 하듯 화면을 조작해 데이터 입력, 송장 처리, 정보 추출 같은 반복 업무를 수행할 수 있다.1
하지만 작업이 길고 복잡해질수록 단순히 “화면을 잘 보고 클릭하는” 능력만으로는 부족해진다. MACU(Multi-Agent Computer Use) 프레임워크가 다루는 문제는 바로 이 지점이다.
CUA의 병목은 실행보다 조율에 있다
기존 CUA는 주로 하나의 에이전트가 순서대로 작업을 진행하는 단일 직렬 구조로 배포된다.2 간단한 작업에서는 이 방식이 자연스럽다. 화면을 보고, 다음 행동을 정하고, 클릭하거나 입력하면 된다.
문제는 장기 작업이다. 복잡한 업무는 보통 여러 하위 작업으로 나뉘고, 일부는 동시에 진행할 수 있으며, 중간에 새로 발견한 정보에 따라 계획을 바꿔야 한다. 단일 에이전트가 모든 단계를 차례로 처리하면 병렬화가 어렵고, 새 정보가 생겼을 때 전체 계획을 유연하게 재구성하기도 어렵다.2
즉, CUA의 다음 병목은 개별 행동의 정확도만이 아니라 작업 분해, 병렬 실행, 재계획을 어떻게 조율하느냐에 있다.
MACU의 구조: 매니저가 DAG로 일을 나눈다
MACU는 이 문제를 멀티에이전트 구조로 푼다. 핵심은 매니저 모델이 전체 작업을 방향 비순환 그래프(DAG)로 분해한다는 점이다.2
DAG는 하위 작업의 목표와 의존 관계를 표현한다. 어떤 작업이 먼저 끝나야 다음 작업을 시작할 수 있는지, 어떤 작업은 서로 독립적으로 병렬 실행할 수 있는지를 구조화한다.2
이후 매니저는 준비된 하위 작업을 여러 CUA 서브에이전트에게 배정한다. 서브에이전트들이 작업을 수행하다가 새 정보를 발견하면, 매니저는 그 정보를 바탕으로 DAG를 수정한다. 필요하면 작업을 추가하거나, 기존 작업의 순서를 바꾸거나, 더 이상 필요 없는 작업을 제거할 수 있다.2
이 설계의 핵심은 “여러 에이전트를 많이 띄운다”가 아니다. 중요한 것은 하위 작업의 의존 관계를 명시하고, 실행 중 발견되는 정보를 계획에 다시 반영하는 조율 방식이다.
부분적으로만 보이는 환경을 다루는 방법
컴퓨터 사용 환경은 부분 관측 가능한 환경으로 볼 수 있다.2 에이전트가 한 시점에 보는 것은 전체 시스템 상태가 아니라 현재 화면과 제한된 맥락뿐이다.
이 특성은 실제 업무에서 자주 문제가 된다. 어떤 서브에이전트가 본 화면, 임시 메시지, 검색 결과, 입력값이 나중에 다시 보이지 않을 수 있다. 단일 에이전트라면 이 정보를 자체 맥락 안에서 유지해야 하지만, 작업이 길어질수록 정보가 흐려지거나 다음 단계에 제대로 전달되지 않을 수 있다.
MACU는 매니저와 DAG 구조를 통해 이런 정보를 보존하고 전달한다. 하위 에이전트가 나중에 다시 관측하지 못할 수 있는 정보를 매니저가 받아 DAG에 반영함으로써, 다음 하위 작업이 더 나은 맥락에서 실행될 수 있게 한다.2
벤치마크 결과가 말하는 것
MACU는 네 가지 CUA 벤치마크에서 성공률 개선을 기록했다. 보고된 개선 폭은 OSWorld +4.7%, Online-M2W +3.4%, WebTailBench +8.7%, Odysseys +25.5%다.2
이 숫자의 의미는 단순히 “멀티에이전트가 더 좋다”가 아니다. 더 실용적인 해석은 복잡한 컴퓨터 사용 작업에서 성능을 높이려면 개별 에이전트의 능력뿐 아니라 작업을 나누고, 병렬로 실행하고, 새 정보에 따라 계획을 고치는 구조가 필요하다는 것이다.
특히 다음 조건에 해당하는 업무라면 MACU식 접근을 검토할 만하다.
작업이 여러 하위 단계로 자연스럽게 나뉜다.
일부 단계는 서로 독립적으로 병렬 처리할 수 있다.
중간 결과를 모아 다음 판단을 내려야 한다.
화면 상태나 임시 정보가 사라지기 쉽다.
API 연동이 어려워 GUI 조작이 필요하다.
실무적으로 볼 때의 판단 기준
MACU를 이해할 때 핵심 질문은 “에이전트를 몇 개 쓸 것인가”가 아니다. 더 중요한 질문은 다음과 같다.
전체 작업을 명확한 하위 목표로 나눌 수 있는가?
하위 작업 사이의 의존 관계를 표현할 수 있는가?
새로 발견한 정보를 계획에 반영해야 하는가?
한 에이전트가 본 정보를 다른 에이전트가 활용해야 하는가?
이 질문에 “그렇다”가 많을수록 단일 직렬 CUA보다 MACU 같은 멀티에이전트 조율 구조가 유리할 가능성이 크다.
MACU의 결론은 명확하다. 컴퓨터 사용 에이전트의 발전은 더 강한 모델만의 문제가 아니다. 긴 작업을 안정적으로 끝내려면, 모델이 보는 화면과 수행하는 클릭 사이에 작업을 구조화하고 조율하는 계층이 필요하다. MACU는 그 조율 계층을 매니저와 DAG, 병렬 서브에이전트로 구현한 프레임워크다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.