지난 몇 주간의 두 가지 수치가 컴퓨터 사용 에이전트 (computer-use agents)가 실제로 어느 단계에 와 있는지를 모두 말해줍니다.

첫 번째는 Microsoft의 Build 2026 기조연설에서 나온 것으로, 이 회사는 PC 자체를 "에이전트형 운영체제 (agentic operating system)"로 재정의하고, 에이전트가 Windows에서 네이티브로 실행될 수 있도록 Microsoft Agent Framework를 오픈 소스로 공개했습니다. 두 번째는 Stanford의 최신 AI Index에서 나온 것으로, OSWorld에서의 에이전트 작업 성공률이 약 1년 만에 12%에서 66%로 급증했습니다. 이는 사람이 하는 것처럼 클릭하고, 타이핑하고, 스크롤하고, 메뉴를 탐색하며 실제 데스크톱을 구동하는 소프트웨어로서 진정으로 놀라운 발전 속도입니다.

하지만 두 번째 숫자를 뒤집어 보십시오. 66%의 성공률은 일반적인 데스크톱 작업 벤치마크에서 최고의 에이전트들조차 여전히 대략 3번 중 1번은 실패한다는 것을 의미합니다. 그리고 이것들은 특이한 작업들이 아닙니다. OSWorld는 Chrome, Thunderbird, LibreOffice 제품군, VS Code, GIMP, VLC, 그리고 기본적인 OS 작업에 걸친 일상적인 업무를 바탕으로 구축되었습니다. 당신의 여행을 예약하거나 스프레드시트를 대조하는 에이전트가 너무 자주 틀린다면, 당신은 눈을 뗄 수 없을 것입니다.

만약 당신이 컴퓨터 사용 에이전트 기반으로 무언가를 구축하고 있다면, 흥미로운 엔지니어링 질문은 "모델이 언제쯤 충분히 좋아질 것인가"가 아닙니다. 그것은 "그 34%에서 구체적으로 무엇이 고장 나고 있는가, 그리고 그것이 모델 문제인가 아니면 데이터 문제인가?"입니다. 많은 에이전트 트레이스 (agent traces)를 면밀히 살펴본 결과, 제 대답은 대부분이 데이터 문제라는 것이며, 이는 사실 좋은 소식입니다. 데이터 문제는 해결 가능하기 때문입니다.

34%가 실제로 어디로 가는지

벤치마크 헤드라인 수치를 읽는 것을 멈추고 개별 궤적 (trajectories)을 읽기 시작하면, 실패 사례들은 몇 가지 인식 가능한 형태들로 군집을 이룹니다.

그라운딩 실패 (Grounding failures). 에이전트는 자신이 무엇을 하고 싶은지는 알지만, 그 의도를 정확한 픽셀(pixel)로 신뢰성 있게 변환하지 못합니다. 예를 들어, "내보내기 (Export)"를 클릭하려다가 "템플릿으로 내보내기 (Export as template)"를 클릭하는 식입니다. 혹은 예상했던 위치에서 3픽셀 정도 벗어나 스크롤된 버튼을 목표로 삼기도 합니다. GUI 그라운딩 (GUI grounding) — 설명된 UI 요소를 화면상의 실제 좌표 및 상태와 매핑하는 것 — 은 여전히 단일 단계 오류 (single-step errors)의 상당 부분이 발생하는 지점이며, 베이스 모델 (base models)이 학습 과정에서 거의 보지 못한 복잡한 엔터프라이즈 소프트웨어에서는 이 문제가 더욱 악화됩니다.

실패로 이어지는 누적된 비효율성 (Inefficiency that compounds into failure). 올해 발표된 주목할 만한 논문인 OSWorld-Human은 각 OSWorld 작업에 대한 최적의 인간 궤적 (human trajectory)을 수동으로 주석 처리(hand-annotated)한 뒤, 에이전트가 실제로 몇 단계를 거치는지 측정했습니다. 결과는 다음과 같습니다. 가장 뛰어난 에이전트조차 필요한 단계보다 1.4배에서 2.7배 더 많은 단계를 사용합니다. 추가적인 단계는 단순히 속도가 느린 문제에 그치지 않습니다. 모든 불필요한 동작은 경로를 이탈하거나, 컨텍스트 윈도우 (context window)를 소진하거나, 되돌릴 수 없는 부작용 (side effect)을 유발할 또 다른 기회가 됩니다. 장기적인 데스크톱 작업 (Long-horizon desktop work)은 방황하는 행위에 대해 엄격한 대가를 치르게 합니다.

"완료" 또는 "오류"에 대한 감각 부재 (No sense of "done" or "wrong"). 에이전트는 작업을 완료했다고 선언하며 승리를 알리지만, 실제로는 단순히 착각한 경우가 빈번합니다. 파일이 잘못된 폴더에 저장되었거나, 오래된 값 (stale value)이 포함된 채 양식이 제출되는 식입니다. 혹은 에러 대화 상자가 나타났음에도 이를 성공으로 간주하기도 합니다. 모델은 행동할 (act) 능력은 충분히 갖추고 있지만, 그 행동이 목표를 달성했는지에 대한 보정된 신호 (calibrated signal)는 거의 가지고 있지 않습니다.

이 세 가지 실패 모드 (failure modes)의 공통점을 주목하십시오. 이 중 어느 것도 근본적으로 추론 능력의 결핍 (reasoning deficit) 때문이 아닙니다. 이는 _모델이 학습한 데이터_와 _자신의 행동에 대해 받는 신호_의 결핍입니다. 이 차이가 모든 것을 결정합니다.

이것이 모델의 문제가 아니라 데이터의 문제인 이유

컴퓨터 사용 에이전트 (Computer-use agent)를 훈련시키는 것은 내부적으로 보면, 주로 조작 궤적 (operation trajectories) — 즉, (화면 상태, 행동) 쌍의 시퀀스 — 에 대한 지도 미세 조정 (supervised fine-tuning) 후에 강화 학습 스타일의 정교화 (reinforcement-style refinement) 과정을 거치는 것입니다. 현재 지배적인 오픈 궤적 코퍼스 (open trajectory corpora)는 규모가 작고 편향되어 있습니다. OpenCUA 스타일의 오픈 궤적 데이터가 훈련 혼합물 (training mix)의 약 30%를 차지할 때, 당신은 소프트웨어가 사용되는 방식 중 매우 좁고, 주로 서구적이며, 주로 소비자 중심적인 부분에 과도하게 의존하게 됩니다. 모델은 Gmail 메시지를 작성하는 수천 가지 방법은 보았지만, 당신의 병원 예약 시스템, 은행의 내부 콘솔, 또는 베트남어 기반 ERP의 사례는 거의 보지 못했습니다.

프롬프트 (prompt)만으로는 분포 차이 (distribution gap)를 해결할 수 없습니다. 클릭 실패로부터 복구하는 방법, 저장 여부를 확인하는 방법, 또는 특화된 업무용 애플리케이션 (line-of-business app)을 조작하는 방법을 에이전트에게 가르치는 궤적이 데이터에 단순히 존재하지 않는다면, 오케스트레이션 계층 (orchestration layer)이 아무리 영리하더라도 에이전트는 해당 작업들을 안정적으로 수행하지 못할 것입니다. 이것이 바로 이 분야가 궤적 구축 (trajectory construction) — 역태스크 합성 (reverse task synthesis), 라벨이 없는 화면 녹화 영상으로부터의 사전 학습 (pretraining), 그리고 인간이 주석을 단 최적 경로 (human-annotated optimal paths) — 에 막대한 투자를 하고 있는 이유입니다. 병목 현상의 중심이 아키텍처 (architecture)에서 연료 (fuel)로 이동했습니다.

34%의 격차를 가장 많이 줄여줄 수 있는 데이터 작업에는 세 가지 범주가 있으며, 이는 신뢰할 수 있는 에이전트가 필요로 하는 요소들과 명확하게 일치합니다.

1. 단순한 궤적 수집(trajectory collection)이 아닌 궤적 교정(trajectory correction). 사람들이 소프트웨어를 사용하는 원본 녹화 데이터는 노이즈가 많습니다. 막다른 길, 잘못된 클릭(fat-fingered clicks), 의미 없는 스크롤 등이 포함됩니다. 에이전트에게 효율성을 가르치는 것은 바로 교정된 궤적(corrected trajectory)입니다. 즉, 불필요한 단계는 제거하고, 실수로부터의 복구를 복구 작업으로 주석(annotation)을 달며, 최적의 경로를 명시적으로 만드는 작업입니다. 이는 전문가가 개입하는(expert-in-the-loop) 고된 작업이며, 14단계 동안 방황하는 에이전트와 6단계 만에 작업을 완료하는 에이전트를 가르는 바로 그 추론 및 인간 피드백 데이터(reasoning and human-feedback data)입니다. 도구 사용 검증(Tool-use validation) 또한 여기에 해당합니다. 에이전트가 액션이나 API를 호출할 때 올바른 인자(arguments)와 함께 올바른 것을 선택했는지 확인하고, 그렇지 않은 사례에 라벨을 붙이는 작업입니다.

2. 실제로 중요한 소프트웨어에 대한 그라운딩 주석(Grounding annotation). 그라운딩 격차(grounding gap)를 줄인다는 것은 실제 애플리케이션의 롱테일(long tail)에서 추출된 라벨링된 화면 데이터를 의미합니다. 즉, 요소의 경계(element boundaries), 상태(states), 활성화된 컨트롤과 비활성화된 컨트롤의 차이, 그리고 사용자가 실제로 작업하는 언어로 된 현지화된 UI 등이 포함됩니다. 범용 웹 데이터셋만으로는 귀하의 도메인을 커버할 수 없습니다. 이는 멀티모달 주석(multimodal annotation) 작업 중 가장 화려하지는 않지만 가장 가치 있는 작업이며, 에이전트가 다섯 번째 시도가 아닌 첫 번째 시도에 낯선 인터페이스를 작동할 수 있게 만드는 밑바탕이 되는 작업입니다.

3. 적대적 테스트 (Adversarial)를 포함한 정직한 평가. 일반적인 작업에서 66%의 벤치마크 점수를 기록했다는 사실은, 에이전트가 당신의 워크플로우(workflows)에서 어떻게 행동하는지, 혹은 UI가 변경되었을 때 어떻게 실패하는지에 대해 거의 아무것도 알려주지 않습니다. 당신에게는 실제 소프트웨어를 기반으로 구축된 태스크 스위트(task suites), "완료되었으나 틀린" 침묵의 실패를 잡아내는 응답 점수 산정 방식, 그리고 대화창이 모호하거나, 클릭 한 번에 파괴적인 동작이 실행될 수 있거나, 읽어야 할 이메일에 프롬프트 주입 (prompt-injection) 함정이 있는 상황에서 에이전트가 어떻게 행동하는지 조사하는 레드팀 (red-teaming) 작업이 필요합니다. 이것이 바로 모델 평가 및 QA (model evaluation and QA)의 영역입니다. 즉, 에이전트가 리더보드(leaderboard)를 통과한다는 것을 아는 것과, 이를 실제 운영 시스템 (production system)에 적용해도 안전하다는 것을 아는 것 사이의 차이입니다.

이러한 에이전트를 출시하려는 경우 해야 할 일

어떤 기반 모델 (base model)을 사용하든 상관없이, 몇 가지 구체적인 시사점은 다음과 같습니다.

무엇인가를 튜닝하기 전에 트레이스 (traces)를 도구화(instrument)하십시오. 측정되지 않은 실패 분포는 수정할 수 없습니다. 전체 (상태, 행동, 결과) 튜플 (tuples)을 캡처하고, 실패를 위에서 언급한 세 가지 범주 — 접지 (grounding), 비효율성 (inefficiency), 검증 (verification) — 에 따라 분류하십시오. 이 구성 비율이 어디에 비용을 투자해야 할지를 알려줍니다.

"완료"를 가정이 아닌 학습된 기술로 취급하십시오. 명시적인 검증 단계를 구축하고, 단순히 성공 사례만이 아니라 실패를 감지하는 사례를 바탕으로 학습시키십시오. 자신이 틀렸을 때를 아는 에이전트가, 아주 조금 더 자주 정답을 맞히는 에이전트보다 더 가치 있습니다.

초기에 도메인 궤적 (domain trajectories)에 투자하십시오. 대부분의 팀이 할 수 있는 가장 영향력 있는 단 한 가지 일은, 자신들만의 소프트웨어와 자신들만의 언어로 수백 개의 고품질 궤적을 생성하고 교정하는 것입니다. 이렇게 좁고 잘 라벨링된 데이터는 당신의 사용 사례(use case)에 있어 훨씬 더 방대한 양의 일반적인 웹 트레이스 (web traces)보다 더 뛰어난 성능을 보이는 경향이 있습니다.

평가를 적대적이고 지속적으로 만드십시오. UI는 변하고, 모델은 업데이트되며, 지난달의 통과 점수는 유효하지 않습니다. 단위 테스트 (unit tests)를 포함하는 것과 마찬가지로, 레드팀 (red-teaming)과 회귀 평가 (regression evals)를 출시 프로세스에 내재화하십시오.

2026년의 컴퓨터 사용 에이전트 (computer-use agent) 이야기는 사실 능력의 한계에 관한 것이 아닙니다. 모델들은 이미 데스크톱을 매우 인상적으로 잘 제어할 수 있습니다. 66%의 데모와 99%의 프로덕션 시스템 사이의 간극은 화려하지는 않지만 도메인 특화적이고 인간 참여형 (human-in-the-loop)인 데이터 작업들로 채워져 있습니다. 즉, 교정된 궤적 (corrected trajectories), 근거가 확실한 화면 (grounded screens), 그리고 시스템이 어떻게 고장 나는지에 대해 정직하게 평가하는 평가 (evaluation) 과정들입니다. 에이전트 경쟁에서 승리할 팀은 가장 영리한 프롬프트를 가진 팀이 아닐 것입니다. 그들은 자신들의 데이터 파이프라인 (data pipeline)을 제품 그 자체로 취급하는 팀이 될 것입니다.

공개 사항: 저는 SyncSoft.AI에서 근무하고 있으며, 이곳의 베트남 소재 이중 언어 및 SME (전문가) 주도 팀들은 신뢰할 수 있는 AI 에이전트의 기반이 되는 궤적, 어노테이션 (annotation), 그리고 평가 데이터를 구축합니다. 만약 여러분이 자체 에이전트의 마지막 34% 문제를 해결하느라 고군분투하고 있다면, 언제든 의견을 나누고 싶습니다. 편하게 연락해 주세요.