VM, 샌드박스 또는 커서 가로채기 없이 실제 데스크톱 제어하기

모든 '컴퓨터 사용' 에이전트 데모는 브라우저 탭에서 작동합니다. 어려운 점은 사용자의 라이브 세션 뒤에 있는 실제 Windows 머신에서, 커서를 탈취하거나 자동화하는 것을 망가뜨리지 않으면서 이를 수행하는 것입니다.

대부분의 에이전트 프레임워크는 브라우저에서 멈춥니다. 헤드리스 페이지나 컨테이너화된 데스크톱을 구동하고 이를 '컴퓨터 사용'이라고 부릅니다. 이것은 작업이 사용자의 실제 기기상의 실제 애플리케이션(네이티브 창, 파일 선택기, 사용자 프로필에만 존재하는 로그인, OS 대화 상자 등)에 닿을 때까지 작동합니다. 그때 헤드리스 브라우저는 할 말이 없습니다.

OpenAmer는 오픈 소스 데스크톱 에이전트(Apache-2.0, Windows 우선)로, 그 목적 자체가 정반대입니다. 즉, 사람이 기기를 계속 사용하는 동안 백그라운드에서 실제 데스크톱을 작동시키는 것입니다. 이 게시물은 그것을 가능하게 만든 네 가지 설계 결정과 각각이 남긴 흔적에 관한 내용입니다.

1. 장악하지 말고, 데스크톱 제어하기

GUI를 자동화하는 순진한 방법은 실제 마우스를 움직이고 실제 키보드로 타이핑하는 것입니다 (SendInput, pyautogui와 같은 계열). 이것은 작동하지만, 실행되는 동안 기기를 사용할 수 없게 만듭니다. 커서가 점프하고, 당신의 타이핑이 에이전트의 포커스 안에 들어가며, 병렬로 아무것도 할 수 없습니다.

대신 우리가 사용하는 경로는 **백그라운드 제어 경로(background control path)**입니다: 대상 창의 상태를 캡처하고 물리적 포인터를 놓고 경쟁하지 않으면서 여기에 합성 입력을 전달하는 것입니다. 사용자의 세션은 자체 커서와 포커스를 유지하며, 에이전트는 자신만의 현실 시각으로 작동합니다. 어려운 부분들은 화려하지 않고 구체적입니다:

• 좌표 공간(Coordinate space). 화면 픽셀 대 창 상대 좌표 대 모니터별 DPI 스케일링—한 공간에서 계산된 클릭이 다른 공간에서 전달되면 약 100px 정도 벗어납니다. 우리는 이 문제를 반복적으로 겪었고, 결국 DPI가 사후 고려 사항이 아닌 모든 좌표의 일급 시민(first-class part)이 되었습니다.
• 포커스(Focus). 일부 네이티브 컨트롤은 포커스를 가지고 있다고 인식할 때만 입력을 받기 때문에, '백그라운드'라는 것은 아예 하지 않는 것이 아니라 잠시 동안 투명하게 빌려오는 것을 의미하기도 합니다.
• 타이밍(Timing). 네이티브 대화 상자는 비동기적으로 나타나므로, 에이전트는 고정된 sleep에 의존하는 것이 아니라 상태(state)(이 창이 아직 존재하는가?)를 기다려야 합니다.

2. VM도, 컨테이너도, 클라우드도 아님

스크린샷 기반 에이전트는 보통 일회용 가상 머신(VM)에서 실행됩니다: 안전하고 격리되어 있으며 사용자의 실제 파일, 로그인 정보 및 앱과 완전히 분리되어 있습니다. 이는 '개인적인' 에이전트의 목적에 위배됩니다. 이 에이전트의 모든 가치는 사용자의 실제 받은 편지함, 실제 리포지토리, 실제 브라우저 프로필을 건드릴 수 있다는 점입니다.

따라서 이것은 호스트에서 프로세스로 실행되며, 사용자 자신의 세션 내에서, 사용자의 자체 자격 증명으로 작동합니다—VM 이미지도, 원격 추론(remote inference)도 없습니다. 이는 보안상의 트레이드오프이며 우리는 이를 그렇게 취급합니다: 기능(capabilities)은 명시적이고 제한적입니다(권한 부여가 없는 기능은 단순히 실행되지 않습니다). 경계를 넘는 동작은 조용히 수행되기보다는 노출되며, 모든 동작은 성공/실패 여부가 기록되는 결과 원장(outcome ledger)에 작성되어 에이전트의 주장 자체가 나중에 검증 가능합니다.

3. 일회성 프로필이 아닌 실제 브라우저 프로필 구동하기

'데스크톱' 작업의 절반은 웹 작업이며, 웹 작업에는 '사용자의 로그인 정보'가 필요합니다. 신선한 헤드리스 Chromium에는 그러한 것이 없습니다. 따라서 에이전트는 DevTools Protocol (CDP)을 통해 지속적인 프로필에 연결된 실제 Chrome을 제어하여, 사용자가 이미 가지고 있는 세션—GitHub, 대시보드, 내부 도구—을 상속받고 로그인 장벽이나 캡차를 극복하려고 시도하지 않습니다.

트레이드오프는 현실적입니다. 해당 프로필은 실시간으로 인증된 신원이기 때문에, 브라우저 작업은 로그인 세션에 접근하는 다른 모든 것과 동일한 주의를 기울여 실행됩니다. 우리는 작업을 수행하기 전에 로그인 상태를 확인하고, 가정하는 대신 실제 페이지와 비교하여 결과를 검증합니다.

4. 모델의 자체 보고가 아닌 '세상'을 기준으로 검증하기

데스크톱 에이전트에서 가장 유용한 원칙은 모델 스스로가 제시하는 "완료(done)"라는 결과에 의존하지 않는 것입니다. 만약 "성공했는지?"라고 질문받는 모델은 자신감 있게, 하지만 종종 잘못된 답변을 내놓습니다. 따라서 검증 가능한 단위는 모델의 문장이 아니라, 결정론적 레이어(deterministic layer)가 작성한 결과 원장(outcome ledger)의 한 행이며, 중요할 때는 실제 세계를 재확인하는 과정(파일이 존재하는지? 프로필이 변경되었는지? 페이지의 텍스트는 무엇인지?)을 포함해야 합니다.

"게시했습니다"라는 말은 아무 가치가 없습니다. "여기에 익명으로 가져온 URL과 HTTP 200 상태 코드, 예상 바이트 크기입니다"가 가치가 있습니다. 이러한 변화—산문(prose)에서 증거(evidence)로의 전환—가 나머지 시스템을 사람이 감시하지 않아도 안전하게 실행할 수 있게 만드는 핵심 요소입니다.

구현 시 고려 사항

백그라운드 데스크톱 제어는 단순한 데모 문제가 아니라 통합 문제입니다. DPI, 포커스(focus), 비동기 다이얼로그(async dialogs), 인증된 프로필, 그리고 모델의 말만 믿지 않는 검증 계층이 필요합니다. 이 네 가지를 제대로 구현하면, 사용자가 계속 사용하는 동안 실제 기기에서 실질적인 작업을 수행하는 시스템을 얻게 됩니다.

코드 및 문서: https://github.com/openamer/openamer (Apache-2.0, Windows 우선, 로컬 실행 가능).

만약 실제 데스크톱 환경을 자동화해 본 경험이 있다면, 가장 먼저 해결해야 했던 문제는 DPI였나요, 포커스였나요, 아니면 비동기 다이얼로그였나요? 서로의 어려움을 비교해 보고 싶습니다.