Can Agents Use a Computer Yet? We
Quick Summary
컴퓨터 사용 에이전트는 표준화된 반복 업무에서 실운영 단계에 진입했으며, 도입 성패는 모델 성능뿐 아니라 검증·오류 처리·캐싱과 고객별 업무 맥락을 갖춘 인프라에 달려 있다.
🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약
컴퓨터 사용 에이전트는 표준화된 반복 업무에서 실운영 단계에 진입했으며, 도입 성패는 모델 성능뿐 아니라 검증·오류 처리·캐싱과 고객별 업무 맥락을 갖춘 인프라에 달려 있다.
📌 핵심 요약
- 원문이 인용한 OSWorld-Verified 최고 점수는 약 1년 전 42%에서 85%로 상승했으며, Claude Fable 5의 85%는 동일 과제에서 인간 평가자가 기록한 약 72%를 웃돈다. 다만 과제 100개 중 15개는 실패한다는 뜻이므로 실제 업무의 신뢰성을 그대로 보장하지 않는다.
- 컴퓨터 사용 에이전트는 명확한 절차와 성공 기준이 있는 반복 업무에 강하며, 정돈된 API가 없어 사람이 직접 화면을 조작하던 기록 갱신, 포털 처리, IT 티켓 등의 업무에 활용되고 있다.
- 소비재 데이터 플랫폼은 월 약 1,500만~2,000만 회의 자동화된 포털 상호작용에서 에이전트를 스크레이퍼 복구 수단으로 활용하고 유지보수 전담 엔지니어링 인력을 절반으로 줄여 다른 업무에 재배치했다. 글로벌 시스템 통합 업체는 27개 운영 워크플로로 하루 약 1,500~2,100개의 IT 티켓을 처리하고 있다.
- 계약의 지급 조건을 잘못 읽어도 화면상 정상으로 보이거나 보험 청구 후 확인 전화가 따로 오는 사례처럼, 결과를 교차 검증하기 어렵거나 성공 여부가 뒤늦게 드러나는 업무에는 한계가 있다.
- 구매자는 모델 이름보다 대규모 실행의 신뢰성, 보안 심사, 투자 대비 효과를 중시한다. 실행 절차를 결정적 코드로 캐싱하고 고장 때만 모델을 다시 호출하는 방식이 관찰됐으며, 경쟁력의 중심은 고객별 업무 맥락, 권한, 검증, 예외 대응으로 이동하고 있다.
🧩 주요 포인트
- 벤치마크 성능 향상 → 실운영 도입의 기반은 마련됐지만, 업무 전체의 완료 여부와 검증 부담이 실제 자동화 효과를 좌우한다.
- 명확한 절차·성공 기준과 API 부재 → 표준화된 반복 업무가 우선 적용 영역이며, 지연된 성공 신호와 교차 검증의 어려움은 적용 범위를 제한한다.
- 실행 절차의 캐싱과 고객별 업무 맥락 → 반복 실행 비용과 장애 복구를 함께 다루는 인프라가 구매 판단과 차별화의 중심이 된다.
🧠 상세 정리
1. 컴퓨터 조작에서 실제 업무 수행으로
원문은 에이전트가 사람과 함께 일하고 반복 작업을 자동화한다는 설명에 대해, 실제로 컴퓨터를 사용할 수 있느냐는 질문에서 출발한다. 생산성 향상의 대상은 브라우저를 열고 양식을 작성하며 정확한 버튼을 누르는 일상적 업무이고, 이는 기존 업무 프로세스 아웃소싱이 담당하던 영역과 맞닿아 있다. 최근에는 기록 시스템 갱신, 포털 간 데이터 이동, 티켓 처리처럼 범위가 좁고 반복적인 작업에서 실운영 사례가 나타나고 있다. 다만 정해진 절차를 벗어나면 취약하고 캐싱이 어려운 일부 용도에서는 비용이 높아, 모든 업무에서 경제성이 확보된 것은 아니다. 따라서 질문의 중심은 화면을 조작할 수 있는지에서 특정 업무를 신뢰할 수 있게 수행할 수 있는지로 이동하며, 상시 가동과 수요에 따른 확장성이 그 가치를 뒷받침한다.
2. 벤치마크 향상과 실운영의 경계
원문은 실제 데스크톱 과제의 완료율을 측정하는 OSWorld-Verified를 통해 컴퓨터 사용 모델의 성능 변화를 설명한다. 인용된 2026년 6월 순위표에서 최고 점수는 약 1년 전의 42%에서 Claude Fable 5의 85%로 상승했고, 인간 평가자의 약 72%를 넘어섰다. 이 평가는 우분투, 윈도, 맥OS의 작업을 포함하며, Gemini 3.5 Flash는 기본 컴퓨터 사용 기능이 없어 비교 차트에서 제외됐다. 그러나 85%는 과제 100개 중 15개가 실패했다는 뜻이므로, 모든 단계가 완료돼야 하는 기업 업무의 신뢰성과 동일하게 해석할 수 없다. 원문은 사람이 모든 출력을 검토해야 한다면 노동 절감이 이뤄지지 않는다고 지적하며, 순위표보다 실제 프로세스의 완료와 검증 부담을 봐야 한다고 강조한다.
3. 실운영을 가능하게 하는 실행 구조
실제 구축에서는 모델 제공사가 컴퓨터 사용 기능을 API로 제공하고, 모델이 스크린샷을 받아 클릭과 키 입력을 반환하는 반복 구조를 사용한다. OpenAI의 CUA는 이용 가능한 경우 접근성 트리나 DOM 정보도 함께 활용하며, 구축 업체는 그 주변에 격리된 가상 머신 또는 브라우저와 실행 조정, 검증, 재시도 로직을 붙인다. 원문에 따르면 기업과 창업자는 소비자용 제품을 그대로 배포하기보다 원시 API를 이용해 구축하거나 이를 묶어 제공하는 공급업체를 선택하는 경우가 대부분이다. 한 창업자는 2026년 2월 Opus 4.6 이전에는 모델 자체의 성능이 실운영에 충분하지 않았다고 설명했다. 반면 월 수백만 건의 자동화 작업을 운영하는 한 사용자는 어떤 모델이 실행되는지 알 필요가 없었다고 말했으며, 이는 모델 선택보다 주변 실행 체계의 신뢰성이 중요해졌다는 논거로 제시된다.
4. 표준화된 반복 업무에서 확인된 활용
인터뷰에서 가장 잘 작동한 영역은 명확하고 정해진 경로를 따르는 표준화된 반복 업무였다. 구체적으로 고객 관계 관리 시스템의 기록 갱신, 품질 검증, 정부·보험 포털 접속, 규제 페이지의 데이터 수집, 소매 주문과 계약 처리, ServiceNow의 IT 티켓 등이 언급됐다. 한 소비재 데이터 플랫폼은 월 약 1,500만~2,000만 회의 자동화된 포털 상호작용을 처리하면서, 화면 변경으로 수작업 작성 스크레이퍼가 고장 나면 에이전트가 원인을 진단하고 자동화를 복구하도록 했다. 이 업체는 도입 후 스크레이퍼 유지보수 전담 엔지니어링 인력을 절반으로 줄이고 다른 업무로 재배치했다고 설명했다. 글로벌 시스템 통합 업체는 27개 운영 워크플로로 하루 약 1,500~2,100개의 IT 티켓을 처리하고 있었으며, 저마진 관리 서비스 계약에 투입된 인력의 20~25% 재배치를 목표로 삼았다. 또 다른 대행사는 면접 종료 후 지원자 추적 시스템에 정보를 입력하는 채용 업무를 처음부터 끝까지 자동화하면서, 필요한 기능을 충분히 수행하는 저렴한 비최첨단 모델을 사용했다.
5. 검증 불가능성과 지연된 성공 신호
원문은 화면을 조작해 작업을 수행할 수 있어도 좋은 결과의 기준이나 성공 여부를 확인할 방법이 불명확하면 자동화가 어려워진다고 설명한다. 예를 들어 계약의 지급 조건을 전사적 자원 관리 시스템에 옮길 때 60일 이내 지급을 30일 이내 지급으로 잘못 읽어도, 입력된 기록은 그럴듯해 보여 화면 검사만으로 오류를 잡기 어렵다. 보험 포털에서는 청구 제출 후 접수 완료가 표시되더라도, 이틀 뒤 담당자의 확인 전화에 대응해야 실제 처리가 진행될 수 있다. 사람은 전화를 받아 문제를 해결하지만, 에이전트의 실행 체계가 그 연락을 포착하지 못하면 청구는 조용히 멈춘다. 이런 문제는 단순히 더 똑똑한 모델을 쓰는 것으로 해결되지 않으며, 외부에서 뒤늦게 들어오는 확인과 예외까지 처음부터 처리 구조에 포함해야 한다는 것이 원문의 논점이다.
6. 구매자가 평가하는 신뢰성과 실패 대응
인터뷰에 참여한 구매자들은 현재 모델이 이미 충분한 수준에 도달했다고 보며, 특정 모델의 이름을 도입의 주된 결정 요인으로 삼지 않았다. 실제 평가 대상은 대규모로 안정적으로 실행할 수 있는지, 보안 심사를 통과할 수 있는지, 투자 대비 효과를 입증할 수 있는지였다. 따라서 실패 양상을 이해하고 복구를 설계하는 일은 부가 기능이 아니라 실운영 채택을 좌우하는 기본 조건으로 제시된다. 소매업체 포털의 화면이 갑자기 바뀌는 경우처럼 정상 경로가 깨졌을 때 검증, 상위 담당자 이관, 오류 처리가 작동해야 하기 때문이다. 원문은 인터뷰에서 더 복잡한 활용 사례를 확인하지 못했다고 밝히면서도, 어려운 과제로 넘어가기 전에 이 방식으로 자동화할 수 있는 비교적 단순한 업무가 많이 남아 있다고 평가한다.
7. 캐싱으로 반복 비용과 복구를 함께 처리
원문에서 여러 차례 관찰된 방식은 에이전트가 업무를 한 번 수행하면 그 절차를 결정적 코드로 저장하고, 이후에는 저렴하고 반복 가능한 코드로 실행하는 구조다. 모델은 매번 모든 단계를 판단하는 대신 자동화가 고장 났을 때 돌아와 원인을 진단하고 수정한 뒤 실행 절차를 다시 캐싱한다. 이 방식에서는 워크플로가 사용되는 기간에 걸쳐 실행당 비용이 낮아지며, 더 저렴한 모델을 쓰면 비용을 추가로 줄일 수 있다. 핵심은 비용뿐 아니라 불확실성을 처리하는 방식으로, 기존 코드가 멈추거나 사람이 매번 수정하던 상황에서 에이전트가 복구를 맡는다는 점이다. 다만 원문은 캐싱이 어려운 일부 용도에서는 비용 구조가 맞지 않을 수 있다고 밝혀, 이러한 경제성이 모든 컴퓨터 사용 업무에 일률적으로 적용되는 것은 아님을 명시한다.
8. 차별화의 중심이 되는 고객별 업무 맥락
원문은 초기 컴퓨터 사용 인프라가 화면 보기, 클릭, 입력, 실수 복구 같은 기본 능력을 만드는 데 집중했다면, 다음 단계는 기업 안에서 실제로 유용하게 작동하도록 만드는 것이라고 설명한다. 기본적인 화면 탐색이 모델 계층의 보편적 기능이 되면서, 지속적인 경쟁력은 고객별 업무 맥락과 권한, 프로세스 지식, 검증, 담당자 이관, 오류 처리, 캐싱으로 이동한다. 이는 특정 조직에서 업무가 실제로 어떻게 진행되는지 이해하고 전체 과정을 연결하는 능력을 뜻한다. 제공된 본문의 마지막 부분은 과거 Selenium, Playwright, Stagehand와 DOM 또는 동영상 기록을 조합해 구현하던 실행 계층이 점차 추상화되고 있다고 서술한다. Claude Code가 코딩 에이전트 주변의 구축 작업을 추상화한 것과의 비교가 제시되며, 제공된 본문은 이 설명에서 끝난다.
🧾 핵심 주장 / 시사점
- 모델 성능 향상은 도입 가능성을 높였지만, 사람의 검토 부담까지 줄일 수 있는지는 결과 검증과 실패 대응 체계에 달려 있다.
- 업무의 자동화 적합성은 화면 조작의 난도뿐 아니라 성공 기준의 명확성, 교차 검증 가능성, 후속 신호의 포착 여부로 판단해야 한다.
- 반복 실행은 캐싱된 코드가 맡고 변경과 고장은 에이전트가 복구하는 구조가 관찰됐으며, 고객별 업무 맥락을 이해하는 능력이 이 구조의 실효성을 좌우한다.
✅ 액션 아이템
- 표준화된 반복 업무 가운데 API가 없고 절차·성공 기준이 명확한 영역의 적용 가능성 검토.
- 계약의 지급 조건과 보험 청구 사례를 기준으로 교차 검증 및 지연된 성공 신호 처리 가능성 확인.
- 실행 절차의 캐싱, 오류 처리, 고객별 업무 맥락을 중심으로 신뢰성·보안 심사·투자 대비 효과 평가.
❓ 열린 질문
- OSWorld-Verified의 85% 완료율과 별개로, 실제 업무 전체의 완료 여부와 검증 부담을 어떻게 평가할 수 있는가?
- 보험 청구처럼 성공 여부가 뒤늦게 드러나는 업무에서 지연된 성공 신호를 어떻게 포착하고 처리할 수 있는가?
- 실행 절차의 캐싱이 가능한 반복 업무에서 신뢰성과 투자 대비 효과를 어떻게 입증할 수 있는가?