컴퓨터 사용 에이전트에게 “브라우저에서 주문 정보를 찾아 스프레드시트에 입력하라”고 지시하는 일은 데모 단계에서는 간단해 보인다. 그러나 운영 환경에서는 다른 문제가 먼저 나타난다. 에이전트가 어느 컴퓨터에서 실행되는지, 화면 상태가 매번 같은지, 잘못 클릭했을 때 무엇을 되돌릴 수 있는지, 결과를 누가 어떤 기준으로 확인하는지가 모델의 클릭 정확도만큼 중요하다.
Cua처럼 데스크톱 자동화, 운영체제별 드라이버, 격리된 클라우드 데스크톱, 작업 평가 도구를 함께 제공하는 플랫폼은 이 문제를 한 제품 안에서 다루려는 선택지다. 다만 도입 판단은 특정 모델이나 데모 성공 여부보다, 조직의 업무를 안전하게 반복 실행할 환경을 만들 수 있는지에 맞춰야 한다.
핵심은 다음과 같다. 컴퓨터 사용 에이전트는 API가 없는 화면 업무를 자동화할 수 있지만, 권한이 넓고 화면 상태에 민감하다. 따라서 업무 적합성, 실행 환경, 드라이버 범위, 재현성과 평가 체계를 분리해 비교해야 한다.
먼저 가려야 할 업무: 화면 자동화가 필요한가, API 연동이 가능한가
컴퓨터 사용 에이전트는 사람이 하던 화면 조작을 대신한다. 브라우저에서 정보를 조회하고, 데스크톱 앱의 값을 확인하며, 양식에 값을 넣고, 결과 화면을 검증하는 작업이 여기에 해당한다. 기존 시스템에 API가 없거나 여러 애플리케이션을 오가야 할 때 후보가 될 수 있다.
반대로 API나 데이터베이스 접근으로 처리할 수 있는 작업까지 화면 자동화로 옮길 이유는 적다. 화면은 팝업, 지연 로딩, 창 크기, 로그인 만료, 사용자별 설정에 영향을 받는다. 같은 데이터를 다루더라도 API 호출은 요청과 응답을 기록하기 쉽고, 권한 범위도 더 좁게 제한할 수 있다.
업무를 세 부류로 나누면 탐색 범위를 줄일 수 있다.
| 업무 유형 | 컴퓨터 사용 에이전트 적합성 | 먼저 확인할 조건 |
|---|---|---|
| 조회, 복사, 초안 작성 | 비교적 높음 | 읽기 전용 계정, 원본 보존, 결과 검토 |
| 정형 양식 입력, 반복 등록 | 조건부로 높음 | 입력 규칙, 오류 시 취소 방식, 승인 전송 |
| 결제, 계약, 계정 권한 변경, 대외 발송 | 낮거나 강한 통제가 필요 | 사람 승인, 최소 권한, 취소 가능성, 감사 기록 |
| API가 있는 내부 시스템 연동 | 대체로 낮음 | 화면 조작보다 API·워크플로 자동화 우선 검토 |
여기서 “정형”은 화면이 비슷하다는 뜻만이 아니다. 입력값의 출처, 필수 항목, 예외 처리, 완료 상태를 판별하는 규칙까지 문서화되어 있어야 한다. 예를 들어 “고객 정보를 보고 적절히 처리한다”는 업무는 자동화 대상이 아니라 판단 기준을 먼저 정해야 하는 업무에 가깝다.
플랫폼 비교의 중심은 실행 위치와 격리 수준이다
컴퓨터 사용 에이전트 플랫폼은 크게 로컬 PC 제어형, 원격 데스크톱 또는 가상머신형, 격리된 클라우드 샌드박스형으로 구분해 볼 수 있다. 현실에서는 이들을 섞어 쓰기도 하지만, 보안과 운영 방식은 상당히 다르다.
| 비교 축 | 로컬 PC 제어 | 원격 데스크톱·VM | 격리된 클라우드 샌드박스 |
|---|---|---|---|
| 기존 업무 앱 접근 | 높을 수 있음 | 이미지와 네트워크 설정에 따라 달라짐 | 필요한 앱을 별도 구성해야 함 |
| 사용자 업무 방해 | 포커스 이동, 마우스 충돌 가능성 | 전용 세션이면 낮아짐 | 일반적으로 낮음 |
| 자격 증명 노출 범위 | 사용자 세션까지 닿을 수 있음 | 전용 계정으로 분리 가능 | 전용 계정과 비밀 주입 설계가 필요 |
| 상태 초기화 | 수동 정리가 많음 | 스냅샷으로 관리 가능 | 매 실행 초기화에 유리 |
| 장애 재현 | 개인 설정 때문에 어려울 수 있음 | 이미지 버전으로 일부 재현 | 이미지·작업 로그가 있으면 상대적으로 수월 |
| 적합한 초기 업무 | 개인 보조, 비중요 조회 | 사내 전용 앱 검증 | 반복 테스트, 데이터 생성, 통제된 운영 |
Cua는 로컬 샌드박스와 클라우드 데스크톱 환경을 모두 다루며, 데스크톱 풀에서 실행 환경을 할당하는 방식을 제공한다. 이런 구조는 에이전트가 매번 같은 계열의 환경에서 일하도록 설계할 여지를 준다. 다만 클라우드 풀은 할당이 끝난 뒤에도 용량이 유지될 수 있으므로, 자원 삭제와 비용 정리 절차를 운영 흐름에 넣어야 한다.
격리는 “에이전트가 별도 창에서 돈다”는 수준으로 판단하면 부족하다. 다음 질문에 답할 수 있어야 한다.
- 에이전트가 접근할 수 있는 네트워크 목적지는 어디까지인가.
- 업무별로 계정, 브라우저 프로필, 파일 저장소를 분리할 수 있는가.
- 실행이 끝난 뒤 파일, 쿠키, 다운로드, 임시 자격 증명을 어떻게 폐기하는가.
- 사고 조사 때 실행 화면, 명령, 파일 변경, 최종 결과를 연결해 확인할 수 있는가.
- 에이전트가 실행 환경을 새로 만들거나 삭제할 권한까지 갖는가.
특히 생산계정의 브라우저 세션을 에이전트에 그대로 넘기는 방식은 탐색 단계에서 피하는 편이 낫다. 먼저 전용 테스트 계정과 제한된 데이터로 시작하고, 필요한 권한만 단계적으로 넓혀야 한다.
운영체제 드라이버는 지원 여부보다 제어 경계를 봐야 한다
컴퓨터 사용 플랫폼은 macOS, Windows, Linux를 지원한다고 소개하는 경우가 많다. 그러나 운영체제 이름만으로 업무 가능 여부를 판단하면 안 된다. 같은 운영체제에서도 애플리케이션 종류, 접근성 권한, 화면 잠금 정책, 보안 프로그램, 원격 세션 방식에 따라 가능한 동작이 달라진다.
Cua Driver처럼 네이티브 데스크톱 앱과 브라우저를 제어하는 드라이버는 CLI, MCP, SDK 등 여러 연결 방식을 제공할 수 있다. 일부 환경에서는 사용자 포인터나 창 포커스를 빼앗지 않고 작업을 전달하는 기능도 고려할 수 있다. 하지만 이 기능은 앱과 플랫폼 조건에 따라 지원 범위가 달라진다. “백그라운드 실행 가능”이라는 설명을 곧바로 무인 운영 가능이라는 뜻으로 해석해서는 안 된다.
드라이버 검증에서는 데모 앱 대신 실제 업무 앱으로 다음을 확인하는 편이 좋다.
- 화면 요소를 어떤 방식으로 식별하는가. 좌표, 접근성 트리, 텍스트, 이미지 중 무엇에 의존하는지 확인한다.
- 창이 가려지거나 해상도가 달라질 때 작업이 어떻게 변하는지 본다.
- 파일 선택 창, 다중 인증, 인증서, 보안 키보드, 캡차 같은 단계에서 멈추는지 확인한다.
- 클릭 전에 현재 화면과 대상 값을 다시 확인할 수 있는지 본다.
- 실패했을 때 재시도, 중단, 사람에게 넘김을 구분할 수 있는지 점검한다.
초기 경고 신호도 분명하다. 같은 작업이 실행할 때마다 다른 순서로 움직이거나, 화면 캡처만 남고 어떤 값을 입력했는지 알 수 없거나, 실패 후 다시 실행했을 때 중복 등록이 생긴다면 아직 운영 자동화 단계가 아니다.
재현 가능한 작업 정의가 모델 선택보다 앞선다
에이전트가 성공했다는 말은 너무 넓다. 화면의 버튼을 눌렀다는 성공과 업무 결과가 정확하다는 성공은 다르다. 따라서 작업을 평가할 때는 프롬프트와 최종 화면만 남기지 말고, 시작 상태와 검증 조건을 함께 고정해야 한다.
작업 정의에는 적어도 다음 항목이 들어가야 한다.
- 시작 환경: 운영체제 이미지, 앱 버전, 화면 해상도, 로그인 상태
- 입력 자료: 사용할 문서, 데이터, 계정 권한, 허용된 파일
- 허용 행동: 조회, 입력, 저장, 제출, 외부 전송 중 가능한 범위
- 금지 행동: 권한 변경, 결제, 삭제, 외부 공유처럼 사람 승인이 필요한 행위
- 완료 조건: 화면 문구가 아니라 생성된 레코드, 저장 파일, 검증 값처럼 확인 가능한 결과
- 중단 조건: 화면 불일치, 예상 밖 팝업, 데이터 누락, 권한 요청, 시간 초과
- 증적: 화면 캡처, 실행 로그, 입력값과 결과값의 대응 기록
Cua Bench와 같은 평가 도구는 시뮬레이션 작업을 만들고 검증하는 흐름을 지원한다. 이런 도구를 쓰든 자체 테스트를 만들든, 평가 데이터와 운영 데이터를 섞지 않는 원칙이 중요하다. 운영 화면을 복제하기 어렵다면 최소한 업무 규칙, 예외 화면, 실패 상태를 담은 테스트 환경을 별도로 준비해야 한다.
CUA-S1처럼 양식 입력의 제한된 판단을 겨냥한 전문 모델도 있다. 이 유형은 범용 에이전트의 장기 계획을 대체하기보다, “이 필드에 어느 값을 넣을지”, “이 요소는 건드리지 않을지”처럼 경계가 명확한 판단을 맡기는 데 더 맞는다. 모델이 작거나 전문화됐다는 이유만으로 통제 비용이 사라지지는 않는다. 누가 행동 순서를 정하고, 드라이버가 어느 지점에서 실행하며, 검증 실패를 어떻게 처리하는지가 함께 설계되어야 한다.
탐색 프로젝트는 승인 없는 실행을 목표로 삼지 않는 편이 낫다
첫 프로젝트의 목표는 사람을 완전히 빼는 것이 아니라, 안전한 작업 단위를 찾아내는 데 두는 편이 좋다. 추천할 만한 순서는 다음과 같다.
먼저 한 업무를 선택하고, 사람이 현재 어떤 화면을 거쳐 어떤 결과를 만드는지 기록한다. 그다음 읽기 전용 또는 테스트 계정에서 에이전트가 조회와 초안 작성까지만 하도록 제한한다. 결과의 정확도와 실패 유형을 확인한 뒤, 정형 입력이나 저장 단계로 범위를 넓힌다. 외부 전송, 금전 처리, 권한 변경은 별도의 승인 단계를 남겨두는 것이 바람직하다.
플랫폼 공급자나 내부 개발팀에는 다음을 질문해 볼 수 있다.
- 업무별로 전용 가상 환경과 전용 자격 증명을 분리할 수 있는가.
- macOS, Windows, Linux에서 지원하는 앱 제어 방식과 제한은 무엇인가.
- 환경 이미지, 드라이버, 모델, 프롬프트 버전을 묶어 작업을 재현할 수 있는가.
- 실행 로그에 민감한 화면 정보나 자격 증명이 남을 때 마스킹과 보존 정책을 설정할 수 있는가.
- 실패한 작업을 재시도할 때 중복 제출을 막는 장치가 있는가.
- 평가 작업과 운영 작업의 결과를 어떤 기준으로 분리해 볼 수 있는가.
컴퓨터 사용 에이전트는 화면 자동화의 빈틈을 메울 수 있다. 다만 그 잠재력은 모델 이름이 아니라, 제한된 권한의 실행 환경에서 같은 작업을 반복하고, 실패를 멈추며, 결과를 검증할 수 있을 때 비로소 업무 가치로 이어진다. 다음 회의에서는 “어떤 모델이 더 잘 클릭하는가”보다 “우리 업무 중 어느 단계까지 별도 환경에서 재현하고 검증할 수 있는가”를 먼저 정하는 편이 낫다.
