Harness는 에이전트에게 무엇을 할지 알려줍니다. GUI 에이전트는 그것을 실제로 수행하게 합니다.

Harness Engineering의 부상

Harness Engineering은 이번 분기 AI 에이전트 개발 분야에서 가장 핵심적인 담론이 되었습니다. Anthropic은 "Effective Harnesses for Long-Running Agents"를 발표했습니다. OpenAI는 소프트웨어 엔지니어링 관행을 통해 에이전트의 행동을 제약하는 그들만의 방식을 공개했습니다. 논지는 명확합니다. AI 에이전트를 작업 라우팅 (task routing), 승인 게이트 (approval gates), 검증 루프 (verification loops), 회고 (retrospectives)와 같은 구조화된 제어 계층 (control layer)으로 감싸서, 장기간의 세션 동안 안정적으로 동작하게 만드는 것입니다.

이 패턴은 직관적으로 타당합니다. 제약이 없는 에이전트는 리스크(liability)가 되지만, Harness가 적용된 에이전트는 도구(tool)가 됩니다. 커뮤니티는 이에 반응하고 있습니다. 오픈 소스 Harness 프레임워크들이 등장하고 있으며, 이는 팀들에게 의사결정 수준의 신뢰성을 위한 재사용 가능한 스캐폴딩 (scaffolding)을 제공합니다.

하지만 아무도 충분히 크게 질문하지 않는 문제가 있습니다. Harness가 무엇을 할지 결정한 후, 에이전트는 실제로 그것을 어떻게 수행할까요?

Harness가 해결하는 것

Harness 프레임워크는 의사결정 계층 (decision layer)에서 작동합니다. 이는 다음 질문에 답합니다:

에이전트가 다음에 무엇을 해야 하는가?
작업이 어떤 순서로 실행되어야 하는가?
언제 인간의 검토를 위해 일시 중지해야 하는가?
다음 단계로 넘어가기 전에 결과물을 어떻게 검증할 것인가?

이를 에이전트 시스템의 전전두엽 피질 (prefrontal cortex)—계획, 순서 지정, 게이팅(gating)—이라고 생각하십시오. cow-harness와 같은 프레임워크는 이미 작업 분해 (task decomposition), 승인 워크플로 (approval workflows), 재시도 로직 (retry logic), 감사 추적 (audit trails)과 같은 패턴의 오픈 소스 구현을 제공하고 있습니다.

이것은 진정으로 가치 있는 일입니다. Harness가 없다면 에이전트는 계획을 환각 (hallucinate)하고, 단계를 건너뛰며, 오류를 누적시킵니다. Harness가 있다면 에이전트는 예측 가능하고 감사 가능해집니다.

하지만 예측 가능한 *계획 (planning)*이 신뢰할 수 있는 *실행 (execution)*과 동일한 것은 아닙니다.

실행 격차 (The Execution Gap)

실제 시나리오를 가정해 봅시다. Harness가 적용된 에이전트가 다음 행동을 결정합니다: "CRM을 열고, Acme Corp의 고객 기록으로 이동하여 계약 갱신 날짜를 6월 15일로 업데이트하십시오."

Harness는 자신의 임무를 완수했습니다. 결정은 정확합니다. 승인 게이트도 통과했습니다. 이제... 에이전트는 물리적으로 이 행동을 어떻게 수행할까요?

현재의 실행 방법들은 각각 근본적인 한계를 가지고 있습니다:

CLI 도구 (CLI tools) — 강력하지만 범위가 좁습니다. 커맨드 라인 인터페이스 (Command-line interfaces)를 노출하는 시스템에서만 작동합니다. 대부분의 엔터프라이즈 소프트웨어는 그렇지 않습니다.

API 호출 (API calls) — 사용 가능하다면 가장 표준적인 방법입니다. 하지만 많은 핵심 비즈니스 시스템—레거시 ERP, 독점 데스크톱 앱, 정부 포털 등—은 단순히 API가 없습니다. 또는 API가 GUI가 노출하는 기능의 20%만을 커버하기도 합니다.

DOM 조작 (DOM manipulation) — 웹 앱에는 작동하지만, 데스크톱에서는 작동하지 않습니다. 대상 앱의 내부 구조에 대한 지식이 필요합니다. 프론트엔드 업데이트 한 번으로 셀렉터 (Selectors)가 무효화될 수 있습니다.

RPA 스크립트 (RPA scripts) — 기업용 임시방편입니다. 매크로를 기록하고 재생합니다. 본질적으로 취약합니다. 버튼 이동, 필드 이름 변경, 새로운 모달 대화 상자(Modal dialog)와 같은 단 한 번의 UI 변경만으로도 전체 흐름이 깨집니다. 유지보수 비용은 자동화의 수에 따라 선형적으로 증가합니다.

공통점은 다음과 같습니다: 이 모든 방법은 대상 시스템에 대한 기존의 기술적 인터페이스를 필요로 한다는 점입니다. 이 방법들은 시스템이 자동화되도록 설계되었거나, 누군가가 침투할 수 있는 방법을 역공학 (Reverse-engineered) 했다고 가정합니다.

기업의 현실에서 가장 중요한 시스템들은 종종 GUI만 존재하는 블랙박스인 경우가 많습니다. API도 없고, CLI도 없으며, 안정적인 DOM도 없습니다. 그저 사람이 클릭하며 지나가는 화면만 있을 뿐입니다.

이것이 바로 실행 격차 (Execution gap)입니다. Harness 프레임워크는 이에 대해 아무런 대책을 가지고 있지 않습니다.

실행 계층으로서의 시각 기반 GUI 에이전트 (Vision-Based GUI Agents)

만약 에이전트가 인간과 동일한 방식으로—화면을 보고 클릭함으로써—소프트웨어와 상호작용할 수 있다면 어떨까요?

그것이 바로 시각 기반 GUI 에이전트가 하는 일입니다:

입력 (Input): 현재 화면 상태의 스크린샷
이해 (Understanding): 시각-언어 모델 (Vision-language model)이 UI 요소—버튼, 텍스트 필드, 메뉴, 레이블—를 식별하고, 그것들의 공간적 관계와 의미론적 의미를 파악합니다.
출력 (Output): 의도한 작업을 완수하기 위한 정확한 마우스 좌표와 키보드 동작

핵심 속성: 대상 시스템 내부 구조에 대한 의존성이 전혀 없습니다 (Zero dependency). 에이전트는 API, DOM 트리, 또는 접근성 훅 (Accessibility hooks)이 필요하지 않습니다. 에이전트는 픽셀을 보고 그에 따라 행동합니다. 이는 다음 환경 전반에서 작동합니다:

웹 애플리케이션 (Web applications)
네이티브 데스크톱 소프트웨어 (Native desktop software)
원격 데스크톱 세션 (Remote desktop sessions)
터미널 UI (Terminal UIs)
가상 머신 (Virtual machines)에서 실행되는 시스템까지

사람이 모니터를 보고 조작할 수 있다면, 비전 기반 (Vision-based) GUI 에이전트도 할 수 있습니다.

결합하기: Harness + GUI 에이전트

이 지점에서 아키텍처 (Architecture)가 완성됩니다. Harness는 무엇을 할지, 언제 멈출지, 어떻게 검증할지를 결정하는 두뇌를 제공합니다. GUI 에이전트는 어떤 시각적 인터페이스에서도 동작을 수행하는 손을 제공합니다.

Mano-P는 정확히 이 역할을 위해 구축된 오픈 소스 (Open-source) GUI 에이전트입니다. Mininglamp Technology가 Apache 2.0 라이선스 하에 개발한 Mano-P는 에이전트 시스템 (Agentic systems)의 실행 계층 (Execution layer) 역할을 하도록 설계된 시각-언어-행동 (Vision-Language-Action, VLA) 아키텍처를 구현합니다.

이 이름에는 철학이 담겨 있습니다. "Mano"는 스페인어로 "손"을 의미하며, 이는 행동하는 부분을 뜻합니다. "P"는 Private을 의미하며, 사용자의 데이터가 기기를 절대 떠나지 않음을 뜻합니다.

아키텍처: 생각-행동-검증 (Think-Act-Verify)

Mano-P는 신중한 인간 운영자가 작업하는 방식과 유사한 추론 루프 (Inference loop)를 통해 작동합니다:

Think (생각) — 현재 화면 상태를 관찰하고, 어떤 UI 요소가 있는지 추론하며, 다음 행동을 결정합니다.
Act (행동) — 정확한 마우스/키보드 조작을 실행합니다.
Verify (검증) — 결과로 나타난 화면 상태를 캡처하고, 해당 행동이 의도한 효과를 냈는지 확인합니다.

이 루프는 내장된 오류 탐지 기능을 제공합니다. 클릭이 잘못된 요소에 떨어지거나 양식이 제출되지 않으면, 검증 (Verify) 단계에서 즉시 이를 포착하여 재시도하거나 Harness 계층으로 에스컬레이션 (Escalation)할 수 있게 합니다.

온디바이스 성능 (On-Device Performance)

Mano-P는 로컬 실행 (Local execution)을 위해 설계되었습니다. 양자화된 (Quantized) 4B 모델은 일반 소비자용 하드웨어에서 실행됩니다:

최소 사양: Apple M4 칩 + 32GB RAM (Mac mini 또는 MacBook)
M5 Pro에서의 성능: 약 80 tokens/s의 디코딩 (Decode) 속도

Cider SDK는 W8A8 활성화 양자화 (Activation Quantization)를 제공하여, W8A16 베이스라인 대비 약 12.7%의 프리필 (Prefill) 가속을 제공하며, MLX 네이티브 W4A16 대비 1.4x~2.2x의 프리필 속도 향상을 실현합니다. 이는 클라우드 왕복 (Round-trip)이나 지연 시간 급증 (Latency spikes) 없이 GUI와 실시간 상호작용이 가능함을 의미합니다.

벤치마크 결과 (Benchmark Results)

실제 운영 체제 작업 전반에 걸친 GUI 에이전트 역량의 표준 평가 방식인 OSWorld 벤치마크에서, Mano-P 1.0-72B는 58.2%의 성공률을 기록하며 특화된 GUI 에이전트 모델 중 1위를 차지했습니다.

특히 웹 탐색 (Web navigation) 분야에서는 WebRetriever Protocol I이 41.7 NavEval 점수를 달성하여, 신뢰할 수 있는 다단계 웹 상호작용 능력을 입증했습니다.

Mano-AFK: 완전 자동화 루프 (The Full Automation Loop)

Harness 수준의 계획 (Planning)이 어떻게 GUI 수준의 실행 (Execution)으로 연결되는지 보여주기 위해, Mininglamp Technology는 엔드 투 엔드 (End-to-end) 자율 개발 파이프라인인 Mano-AFK를 구축했습니다.

자연어 요구사항 (Natural language requirement) → PRD 생성 → 아키텍처 설계 (Architecture design) → 코드 생성 (Code generation) → 배포 (Deployment) → E2E 테스트 (E2E testing) (Mano-P의 시각 모델이 브라우저를 구동하여 배포된 앱을 테스트) → 버그 탐지 (Bug detection) → 수정 (Fix) → 재테스트 (Retest)

이것이 Harness + GUI 에이전트 패턴의 가장 완전한 형태입니다. 계획 레이어 (Planning layer)는 모호한 요구사항을 구조화된 개발 단계로 분해합니다. GUI 에이전트는 브라우저 테스트, UI 검증, 시각적 버그 탐지와 같이 시각적 상호작용이 필요한 부분을 테스트 프레임워크에 대한 의존성 없이 처리합니다.

설계 단계부터 고려된 개인정보 보호 (Privacy by Design)

로컬 실행 모드에서는 모든 처리가 기기 내부 (On-device)에서 이루어집니다. 스크린샷은 로컬에서 캡처 및 분석되며, 모델 추론 (Model inference) 또한 로컬에서 실행됩니다. 데이터는 외부 서버로 전송되지 않습니다. 금융 기록, 의료 데이터, 기밀 문서와 같이 민감한 정보를 다루는 조직에게 이것은 단순한 기능이 아니라 필수 요구사항입니다.

솔직한 한계점 (Honest Limitations)

모든 기술이 보편적으로 최적인 것은 아닙니다. 시각 기반 (Vision-based) GUI 에이전트는 다음과 같은 실제적인 트레이드오프 (Tradeoffs)를 가집니다:

단순 웹 작업에서의 오버헤드 (Overhead on simple web tasks) — 깨끗한 API 또는 안정적인 DOM 트리(DOM trees)를 가진 잘 구조화된 웹 애플리케이션의 경우, 직접적인 API 호출이나 DOM 조작이 스크린샷 기반의 상호작용보다 항상 더 빠를 것입니다. 좋은 API가 있다면 그것을 사용하십시오.

복잡한 UI에서의 정확도 한계 (Accuracy ceiling on complex UIs) — 4B 온디바이스 (on-device) 모델은 표준 인터페이스를 잘 처리하지만, 극도로 밀집되거나 관습적이지 않은 UI 레이아웃에서는 어려움을 겪을 수 있습니다. 72B 모델은 정확도를 상당히 더 높여주지만 더 많은 연산 (compute)을 필요로 합니다.

특정 시나리오에 가장 적합함:

API가 없는 레거시 (Legacy) 기업용 시스템
웹과 데스크톱을 아우르는 크로스 플랫폼 (Cross-platform) 자동화
엄격한 로컬 실행을 요구하는 데이터 민감 워크플로우 (Data-sensitive workflows)
UI가 빈번하게 변경되는 시스템 (비전은 적응하지만, 스크립트는 깨짐)
DOM 접근이 불가능한 원격 데스크톱 환경

올바른 아키텍처는 각 대상에 맞는 적절한 도구를 사용합니다. API가 존재하는 곳에는 API 호출을 사용합니다. 안정적인 웹 앱에는 DOM 메서드를 사용합니다. 그리고 그 외의 모든 것—대부분의 기업에서 놀라울 정도로 넓은 영역을 차지하는—에는 비전 기반 (vision-based) GUI 에이전트를 사용합니다.

결론

AI 에이전트 스택은 두 개의 뚜렷한 계층으로 결정화되고 있습니다:

두뇌 (The Brain) — 에이전트의 결정을 제약, 라우팅, 검증 및 감사 (audit)하는 Harness 프레임워크입니다. 이는 활발한 오픈 소스 개발이 이루어지고 있는 해결된 문제입니다.

손 (The Hands) — 결정을 실제 시스템상의 물리적 행동으로 변환하는 실행 계층입니다. GUI에 종속된 시스템의 경우, 비전 기반 에이전트는 시스템별 통합 작업 없이 확장 가능한 유일한 접근 방식입니다.

Harness는 에이전트에게 무엇을 할지 알려줍니다. GUI 에이전트는 그것을 실제로 수행하게 합니다. 이들이 함께 자동화 루프 (automation loop)를 완성합니다.

Mano-P는 Apache 2.0 라이선스이며 GitHub에서 사용할 수 있습니다: https://github.com/Mininglamp-AI/Mano-P

피드백과 기여를 환영합니다.⭐