MCP 이후, AI 에이전트를 위한 차세대 표준 인터페이스는 무엇인가?

Model Context Protocol (MCP)은 실질적인 문제를 해결했습니다. MCP 이전에는 모든 도구 통합에 맞춤형 글루 코드 (glue code)가 필요했습니다. MCP 이후, 에이전트는 표준 인터페이스를 통해 데이터베이스, API, 그리고 서비스와 통신할 수 있게 되었습니다. 이 프로토콜은 에이전트와 도구 간의 통신을 위한 공통 언어를 제공했으며, 생태계는 수천 개의 MCP 서버로 이에 화답했습니다.

하지만 MCP가 다루지 못하는 상호작용 범주가 있습니다. 바로 그래픽 사용자 인터페이스 (GUI)입니다. 에이전트는 API를 호출할 때 보여주는 유창함만큼 데스크톱 애플리케이션, 웹 인터페이스, 모바일 앱을 능숙하게 조작하는 데 여전히 어려움을 겪고 있습니다. 문제는 지능이 아닙니다. 에이전트가 GUI를 인지하고 조작할 수 있는 표준화된 방식이 부족하다는 점입니다.

이 간극을 메우기 위해 세 가지 접근 방식이 등장했습니다. 각 방식은 서로 다른 엔지니어링 트레이드오프 (tradeoffs)를 가지며, MCP가 경험한 수준의 채택을 달성한 방식은 아직 없습니다. 시각적 세계와 상호작용해야 하는 에이전트를 구축하고 있다면 이러한 트레이드오프를 이해하는 것이 중요합니다.

GUI 에이전트 문제

API는 구조화되어 있습니다. API는 타입이 지정된 파라미터 (typed parameters)를 수용하고, 예측 가능한 응답을 반환하며, 동작을 문서화합니다. GUI는 이 중 어느 것에도 해당하지 않습니다. 버튼의 레이블은 “제출”, “저장”, 또는 “확인”일 수 있습니다. 화면 크기에 따라 위치가 달라질 수도 있습니다. 버튼의 활성화 여부는 다른 세 개의 폼 필드 (form fields) 상태에 따라 달라질 수도 있습니다. 시각적 표현은 기저 상태 (underlying state) 위의 추상화 계층이며, 이 추상화는 기계가 아닌 인간을 위해 설계되었습니다.

GUI를 조작하는 에이전트는 세 가지를 수행해야 합니다: 현재 인터페이스 상태를 인지하고, 어떤 행동을 취할지 결정하며, 그 행동을 실행하는 것입니다. 인지 단계는 접근 방식이 갈라지는 지점입니다. 에이전트는 인터페이스를 어떻게 "보는" 것일까요?

접근 방식 1: API 통합

가장 직관적인 접근 방식은 GUI를 완전히 우회하고 API가 존재하는 경우 이를 사용하는 것입니다. 많은 데스크톱 애플리케이션은 스크립팅 인터페이스를 노출합니다. 웹 애플리케이션은 종종 REST API 또는 GraphQL 엔드포인트를 가지고 있습니다. 모바일 앱은 때때로 프로그래밍 방식으로 호출할 수 있는 URL 스킴 (URL schemes)이나 접근성 훅 (accessibility hooks)을 지원합니다.

이러한 접근 방식은 API가 사용 가능하고 문서화가 잘 되어 있을 때 효과적입니다. 에이전트는 create_document()를 호출하고, 구조화된 파라미터 (structured parameters)를 전달하며, 확인 응답을 받을 수 있습니다. 상호작용은 빠르고 신뢰할 수 있으며, 시각적 처리 (visual processing)를 필요로 하지 않습니다.

한계점은 커버리지 (coverage)입니다. 대부분의 소비자용 애플리케이션은 포괄적인 API를 노출하지 않습니다. API가 존재하더라도, GUI를 통해 사용할 수 있는 모든 기능을 다루지 못하는 경우가 많습니다. 사진 편집 앱은 기본적인 작업에 대한 API는 있을 수 있지만, 고급 필터에 대한 API는 없을 수 있습니다. 웹 애플리케이션은 데이터를 읽기 위한 공개 API는 있을 수 있지만, 여러 단계의 양식 제출 (form submissions)이 필요한 복잡한 워크플로 (workflows)를 위한 API는 없을 수 있습니다.

또한 API 통합은 레거시 시스템 (legacy systems), 독점 소프트웨어 (proprietary software), 또는 API가 폐기되었거나 아예 구축되지 않은 애플리케이션에는 도움이 되지 않습니다. 에이전트는 자신이 필요로 하는 기능을 노출해 줄 애플리케이션 개발자의 선의에 의존하게 됩니다.

일부 프레임워크는 GUI 자동화 라이브러리를 래핑 (wrapping)하여 API 커버리지를 확장하려고 시도합니다. Python의 pyautogui, Apple의 AppleScript, 그리고 Windows UI Automation은 모두 GUI 요소에 대한 프로그래밍 방식의 접근을 제공합니다. 이러한 도구들은 작동하지만, 취약합니다 (fragile). 이들은 애플리케이션 버전 간에 변경되는 요소 식별자 (element identifiers), 창 제목 (window titles), 그리고 UI 계층 구조 (UI hierarchies)에 의존합니다. 오늘 작동하는 스크립트가 소프트웨어 업데이트 후에 깨질 수 있습니다.

접근 방식 2: 접근성 트리 (Accessibility Tree)

운영 체제는 접근성 트리 (accessibility trees)를 유지합니다. 이는 스크린 리더 (screen readers) 및 보조 기술 (assistive technologies)을 위해 설계된 UI 요소의 구조화된 표현입니다. 이 트리에는 버튼, 텍스트 필드, 메뉴 및 현재 상태에 대한 정보가 포함되어 있습니다. 에이전트는 접근성 트리를 쿼리 (query)하여 어떤 요소가 존재하는지, 그리고 그 요소들이 어떤 동작을 지원하는지 이해할 수 있습니다.

이러한 접근 방식은 접근성 트리 (accessibility trees)가 운영체제 (OS) 수준에서 표준화되어 있기 때문에, 가공되지 않은 API 통합 (raw API integration)보다 더 견고합니다. macOS는 Accessibility API를 사용하고, Windows는 UI Automation을 사용하며, 웹 브라우저는 접근성 인터페이스를 통해 DOM을 노출합니다. 이러한 API를 이해하는 에이전트는 각 애플리케이션마다 별도의 맞춤형 통합을 수행하지 않고도 수많은 애플리케이션에서 작동할 수 있습니다.

Gemini 3.5 Flash Computer Use를 활용한 Google의 접근 방식은 접근성 트리에 크게 의존합니다. 이 모델은 웹 페이지나 애플리케이션의 접근성 트리를 쿼리 (query)하여 상호작용 가능한 요소를 식별하고, 이를 조작하기 위한 동작을 생성할 수 있습니다. 이는 웹 양식 (web forms), 파일 관리자, 설정 패널과 같이 구조화된 인터페이스에서 잘 작동합니다.

접근성 트리 접근 방식에는 한계가 있습니다. 모든 애플리케이션이 완전한 접근성 정보를 노출하는 것은 아닙니다. 커스텀 드로잉 인터페이스 (custom-drawn interfaces), 게임, 그리고 표준이 아닌 UI 프레임워크를 사용하는 애플리케이션은 종종 희소하거나 부정확한 접근성 트리를 가집니다. 캔버스 기반 렌더링 (Canvas-based rendering), WebGL 콘텐츠, 그리고 비디오 플레이어는 시각적 콘텐츠가 접근성 노드 (accessibility nodes)에 깔끔하게 매핑되지 않기 때문에 특히 까다로운 과제를 안겨줍니다.

또한 접근성 트리는 인간과 유사한 상호작용에 중요한 시각적 정보를 놓칩니다. 트리는 버튼이 존재하고

세 번째 접근 방식은 화면을 하나의 이미지로 취급하고 컴퓨터 비전 (Computer Vision)을 사용하여 이를 이해합니다. 에이전트는 스크린샷을 찍고, 이를 시각-언어 모델 (Vision-Language Model)을 통해 처리하며, 보이는 내용을 바탕으로 마우스 및 키보드 동작을 생성합니다. 이는 API나 접근성 트리 (Accessibility Trees)의 존재 여부와 관계없이 모든 GUI에서 작동하기 때문에 가장 범용적인 접근 방식입니다.

순수 비전 에이전트 (Pure vision agents)는 애플리케이션 특화 통합 (Application-specific integrations)에 의존하지 않습니다. 이들은 인간이 화면을 보는 방식 그대로, 즉 버튼, 텍스트, 이미지 및 레이아웃을 나타내는 패턴으로 배열된 픽셀을 봅니다. 시각-언어 모델은 버튼에 접근성 레이블 (Accessibility label)이나 API 엔드포인트 (API endpoint)가 없더라도 시각적 외형을 통해 "Submit" 버튼을 식별할 수 있습니다.

트레이드오프 (Tradeoff)는 연산 비용 (Computational cost)과 지연 시간 (Latency)입니다. 비전 모델을 통해 스크린샷을 처리하는 데는 시간이 걸립니다. 단 한 번의 추론 (Inference)에 200-500밀리초가 소요될 수 있으며, 복잡한 인터페이스는 정확하게 파싱하기 위해 여러 번의 추론 단계가 필요할 수 있습니다. 이로 인해 순수 비전 에이전트는 동작이 밀리초 단위로 실행되는 API 기반 접근 방식보다 느립니다.

메모리 및 연산 요구 사항 또한 더 높습니다. 시각-언어 모델은 고해상도 이미지를 처리해야 하며, 이는 상당한 VRAM 또는 RAM을 소비합니다. 이러한 모델을 엣지 디바이스 (Edge devices)—노트북, 데스크톱, 모바일 기기—에서 실행하려면 세심한 최적화가 필요합니다.

Mano-P는 이러한 순수 비전 접근 방식을 채택하여 엣지 배포 (Edge deployment)에 최적화했습니다. 이 모델은 소비자용 하드웨어에서 로컬로 실행되도록 설계된 GUI-VLA (Visual-Language-Action) 에이전트입니다. 72B 파라미터 버전은 OSWorld 벤치마크에서 58.2%의 성공률을 달성하여 특화된 GUI 에이전트 중 1위를 기록했습니다. 하지만 72B 모델은 주로 연구 및 벤치마킹용입니다. 사용자가 실제로 배포할 수 있는 것은 4B 양자화 (Quantized) 버전입니다. 이 버전은 피크 메모리 사용량 4.3GB로 실행되며, 32GB RAM을 탑인 Apple M4 하드웨어에서 프리필 (Prefill) 단계 동안 초당 476 토큰, 디코딩 (Decoding) 단계 동안 초당 76 토큰을 달성합니다.

이러한 성능 특성은 실제 배포(deployment) 시 매우 중요합니다. 각 스크린샷을 처리하는 데 2초가 걸리는 에이전트는 느릿한 사용자 경험을 만듭니다. 반면 스크린샷을 200밀리초(ms) 미만으로 처리하는 에이전트는 반응성이 좋게 느껴집니다. 4B 모델의 처리량(throughput)은 일반적인 하드웨어(commodity hardware)에서도 실시간 GUI 상호작용을 가능하게 하며, 이는 GUI 에이전트가 배포될 수 있는 위치를 변화시킵니다.

순수 비전(Pure vision) 방식은 다른 접근 방식들이 어려워하는 예외 상황(edge cases)도 처리할 수 있습니다. 직접 그린 인터페이스, 게임, 비디오 콘텐츠, 그리고 표준적이지 않은 UI 프레임워크를 사용하는 애플리케이션은 모두 픽셀(pixels)로 렌더링됩니다. 비전 에이전트는 별도의 통합 작업 없이도 이들을 조작할 수 있습니다.

엔지니어링 트레이드오프 (Engineering Tradeoffs)

이러한 접근 방식 중 무엇을 선택할지는 배포 환경(deployment context)에 따라 달라집니다.

API 통합(API integration)은 API가 존재할 때 가장 빠르고 신뢰할 수 있는 방법입니다. API 커버리지가 포괄적인, 잘 정의된 소프트웨어 생태계 내에서 작동하는 에이전트에게 적합한 선택입니다. 만약 Salesforce, Jira, Slack의 워크플로우를 자동화하는 에이전트를 구축하고 있다면 API 통합이 합리적입니다. 이 방식의 에이전트는 빠르고, 예측 가능하며, 디버깅(debug)하기 쉽습니다.

접근성 트리(Accessibility tree) 방식은 합리적인 성능과 함께 더 넓은 커버리지를 제공합니다. 픽셀 단위의 완벽한 시각적 이해는 필요하지 않지만, 많은 애플리케이션에 걸쳐 작동해야 하는 에이전트에게 적합합니다. 웹 자동화, 양식 채우기(form filling), 메뉴 탐색 등에 잘 맞습니다. 하지만 애플리케이션의 접근성 지원이 미비하거나, 의사결정에 시각적 맥락이 중요한 경우에는 이 방식이 한계에 부딪힙니다.

순수 비전(Pure vision)은 가장 범용적이지만 가장 비용이 많이 듭니다. 에이전트가 임의의 GUI를 조작해야 하거나, 시각적 복잡성을 처리해야 하거나, API 및 접근성 지원이 부족한 애플리케이션과 함께 작업해야 할 때 적합합니다. 역사적으로 계산 비용(computational cost) 때문에 이 방식은 클라우드 배포로 제한되어 왔으나, 모델 압축(model compression)과 에지 최적화(edge optimization)가 그 방정식을 바꾸고 있습니다.

하이브리드 접근 방식 (Hybrid approaches) 또한 실행 가능합니다. 에이전트는 구조화된 작업(structured operations)을 위해 API 통합 (API integration)을 사용하고, 표준 UI 요소에 대해서는 접근성 트리 (accessibility trees)로 전환하며, 다른 접근 방식이 실패할 때만 비전 (vision)을 사용할 수 있습니다. 이러한 계층적 전략은 성능과 커버리지 (coverage) 사이의 균형을 맞추지만, 구현 복잡성 (implementation complexity)을 증가시킵니다.

표준화 문제 (The Standardization Question)

MCP가 성공한 이유는 최소 기능 인터페이스 (minimal viable interface)를 정의했기 때문입니다. 즉, 도구(tools)는 타입이 지정된 파라미터 (typed parameters)와 함께 함수를 노출하고, 에이전트는 해당 함수를 호출하며, 결과가 다시 흘러 들어오는 방식입니다. 이 프로토콜은 빠르게 구현할 수 있을 만큼 충분히 단순하면서도, 많은 유스케이스 (use cases)를 다룰 수 있을 만큼 유연합니다.

GUI 에이전트 프로토콜은 서로 다른 관심사들을 다루어야 합니다. 에이전트가 인터페이스 상태를 인지하는 방식 (스크린샷, 접근성 트리, 또는 둘 다), 동작을 지정하는 방식 (좌표, 요소 참조, 또는 의미론적 설명), 그리고 피드백을 받는 방식 (시각적 확인, 상태 변화, 또는 에러 메시지)을 표준화해야 합니다.

아직 그러한 표준은 존재하지 않습니다. 각 GUI 에이전트 프레임워크는 자신만의 인지 및 동작 프리미티브 (perception and action primitives)를 정의합니다. Mano-P는 좌표 기반 동작과 스크린샷 기반 인지를 사용합니다. 다른 프레임워크들은 요소 ID 기반 동작과 접근성 트리 쿼리 (accessibility tree queries)를 사용합니다. 표준화의 부재는 GUI 에이전트가 프레임워크 간에 이식될 수 없음을 의미하며, 애플리케이션 개발자들에게는 최적화할 명확한 목표가 없음을 의미합니다.

Octo 워크스페이스는 이 문제에 대해 다른 접근 방식을 취합니다. GUI 상호작용 계층을 직접 표준화하는 대신, 에이전트 조정 (agent coordination)과 작업 오케스트레이션 (task orchestration)에 집중합니다. Octo 내의 개별 에이전트들은 어떤 작업에는 API 통합을, 다른 작업에는 GUI 자동화 (GUI automation)를 사용하는 등 서로 다른 상호작용 전략을 사용할 수 있으며, 워크스페이스는 이들 사이의 컨텍스트 (context), 상태 (state), 그리고 협업을 관리합니다. 이는 GUI 상호작용을 프로토콜의 관심사가 아닌 구현 세부 사항 (implementation detail)으로 취급함으로써 표준화 문제를 우회합니다.

GUI 전용 프로토콜이 등장할지는 여전히 불분명합니다. 접근 방식의 다양성은 이 문제 영역(problem space)이 아직 충분히 이해되지 않았음을 시사합니다. MCP가 탄력을 받기까지 수년이 걸렸던 것처럼, GUI 에이전트 상호작용 또한 표준이 등장하기 전까지 이와 유사한 성숙 기간이 필요할 수 있습니다.

미해결 과제 (Open Problems)

어떤 방식이 주도권을 잡든 몇 가지 기술적 과제는 여전히 해결되지 않은 상태로 남아 있습니다.

액션 전반에 걸친 상태 추적 (State tracking). GUI는 상태 유지형 (stateful)입니다. 버튼을 클릭하면 대화 상자가 열리거나, 메뉴가 변경되거나, 로딩 스피너 (loading spinner)가 트리거될 수 있습니다. 에이전트는 이러한 상태 변화를 추적하고 그에 따라 행동을 조정해야 합니다. 현재의 방식은 반복적인 인지 사이클(perception cycles)—스크린샷 촬영, 상태 변화 감지, 다음 액션 결정—을 통해 이를 처리하지만, 이는 비효율적이며 오류가 발생하기 쉽습니다.

오류 복구 (Error recovery). GUI는 예측 불가능한 방식으로 실패합니다. 대화 상자가 예기치 않게 나타날 수 있습니다. 네트워크 요청이 타임아웃되어 인터페이스를 일관되지 않은 상태 (inconsistent state)로 남겨둘 수도 있습니다. 요소가 팝업에 의해 가려질 수도 있습니다. 에이전트에게는 강력한 오류 감지 및 복구 전략이 필요하지만, GUI 문맥에서 무엇이 "오류"를 구성하는지 정의하는 것은 어렵습니다.