LLM 에이전트를 위한 Android 디바이스 클라우드

브라우저 에이전트(Browser agents)는 이제 명확한 인프라 모델을 가지고 있습니다.

브라우저 세션(browser session)을 생성하고, 이를 모델에 전달하며, 동작을 관찰하고, 로그를 수집한 뒤, 실행이 끝나면 세션을 해제합니다.

Android 에이전트도 동일한 것이 필요하지만, 디바이스는 더 까다롭습니다.

Android 세션은 단순히 웹페이지 하나가 아닙니다. OS, 앱, 권한(permissions), 푸시 알림(push notifications), 키보드, 보안 화면(secure screens), 패키지 상태(package state), 그리고 언어 모델(language models)을 위해 설계되지 않은 UI 트리(UI tree)를 가지고 있습니다.

신뢰할 수 있는 Android 에이전트를 원한다면, 결국 일반적인 모바일 테스트 그리드(mobile testing grid)가 아닌, 에이전트를 위해 구축된 Android 디바이스 클라우드(Android device cloud)가 필요합니다.

빠른 답변

LLM 에이전트를 위한 Android 디바이스 클라우드는 다음과 같은 기능을 제공해야 합니다:

휘발성(Ephemeral) Android 세션.
빠른 tap, fill, swipe, wait 동작.
프롬프트(prompts)를 위한 압축된 UI 관찰(UI observations).
시각적 컨텍스트(visual context)가 중요한 경우에만 스크린샷 제공.
모든 단계에 대한 로그, 스크린샷 및 UI 덤프(UI dumps).
세션 녹화 및 재생(replay).
실행 간의 격리(Isolation).
에이전트 루프(agent loops)에 충분히 간단한 Python/API 인터페이스.

디바이스는 런타임(runtime)입니다. UI 덤프는 관찰(observation)입니다. 액션 API(action API)는 액추에이터(actuator)입니다.

모바일 에이전트에게 다른 인프라가 필요한 이유

전통적인 디바이스 클라우드는 테스트 스위트(test suites)를 위해 구축되었습니다.

핵심 워크플로우는 다음과 같습니다:

앱 업로드.
테스트 시작.
Appium, Espresso 또는 XCTest와 같은 프레임워크 실행.
보고서 수집.

이 모델은 유용하지만, LLM 에이전트는 다르게 동작합니다.

에이전트는 화면을 수십 또는 수백 번 검사할 수 있습니다. 동작을 재시도하거나, 스크린샷을 요청하거나, 알림을 검사하거나, 예상치 못한 권한 대화 상자(permission dialog)로부터 복구해야 할 수도 있습니다.

인프라는 다음과 같은 긴밀한 루프(tight loop)를 지원해야 합니다:

관찰(observe) -> 결정(decide) -> 행동(act) -> 대기(wait) -> 관찰(observe)

각 루프 단계가 느리거나, 장황하거나, 디버깅하기 어렵다면 에이전트는 비용이 많이 들고 신뢰할 수 없게 됩니다.

관찰: 시각 정보보다 압축 정보 우선

대부분의 Android 에이전트 루프는 스크린샷이나 UIAutomator XML로 시작합니다.

둘 다 유용합니다. 하지만 둘 중 어느 것도 유일한 관찰 수단이 되어서는 안 됩니다.

스크린샷은 시각적 레이아웃을 확인하기에 좋지만, 용량이 큽니다. XML은 구조화되어 있지만, 많은 레이아웃 노이즈 (layout noise)를 포함하고 있습니다.

에이전트 (agent)에게 더 나은 기본 관찰 수단은 액션 테이블 (action table)입니다:

fill  EditText  "Email"     #email     540,540
fill  EditText  "Password"  #password  540,640  [password]
tap   Button    "Continue"  #continue  540,860

이것은 모델에게 무엇을 할 수 있는지 알려줍니다. 텍스트 UI만으로 충분하지 않을 때 스크린샷을 추가하세요:

hs ui
hs see --size 768 /tmp/screen.jpg

이렇게 하면 프롬프트 (prompt) 크기를 작게 유지할 수 있고 액션을 감사 (audit)하기가 더 쉬워집니다.

액션: 레이블이 픽셀보다 낫다

일반적인 디바이스 클라우드 (device cloud)는 다음과 같은 원시 탭 (raw taps) 정보를 노출할 수 있습니다:

{ "type": "tap", "x": 540, "y": 860 }

이것이 때로는 필요할 수도 있지만, 최선의 기본값은 아닙니다.

에이전트 실행 (agent runs)의 경우, 레이블 기반 액션 (label-based actions)이 이해하기 더 쉽습니다:

{ "type": "tap", "text": "Continue" }

이제 실행 기록 (run transcript)을 읽을 수 있게 됩니다. 사람은 에이전트가 무엇을 의도했는지 볼 수 있습니다. 재시도 정책 (retry policy)은 NOT_FOUND를 AMBIGUOUS나 TIMEOUT과 구분할 수 있습니다.

디버깅이 곧 제품이다

에이전트 인프라 (agent infrastructure)의 어려운 점은 단순히 디바이스를 실행하는 것만이 아닙니다. 실행이 왜 실패했는지 이해하는 것입니다.

유용한 Android 에이전트 클라우드는 타임라인 (timeline)을 유지해야 합니다:

단계	데이터
관찰 (Observation)	UI 테이블, 스크린샷, 최상위 액티비티 (top activity)
...

에이전트가 실패했을 때, 경로를 재현 (replay)할 수 있어야 합니다:

1. "Sign in"을 봄
2. "Sign in"을 탭함
3. "Email"을 입력함
...

이것이 없다면, 모든 실패는 정체를 알 수 없는 스크린샷이 되어버립니다.

격리가 중요하다

Android 세션 (sessions)은 상태 (state)를 가집니다:

설치된 앱 (Installed apps)
로그인 세션 (Login sessions)
런타임 권한 (Runtime permissions)
클립보드 (Clipboard)
알림 (Notifications)
시스템 설정 (System settings)
캐시된 데이터 (Cached data)

에이전트 클라우드는 세션을 어떻게 초기화할지 결정해야 합니다. 에뮬레이터 (Emulators)는 스냅샷 (snapshot)을 찍기 더 쉽습니다. 실제 디바이스 (Real devices)는 더 어렵지만 프로덕션 (production) 환경에 더 가깝습니다.

대부분의 에이전트 실험에는 에뮬레이터 세션으로 충분합니다. 모바일 RPA 또는 앱 스토어 실효성 검증 (reality checks)의 경우에는 실제 디바이스가 중요해집니다.

핸드셋의 역할

Handsets 그 자체만으로는 완전한 디바이스 클라우드 (device cloud)가 아닙니다.

이는 클라우드가 구축할 수 있는 제어 평면 (control plane) 역할을 합니다:

ADB를 통한 루팅되지 않은 (no-root) 디바이스 동작
컴팩트한 UI 덤프 (UI dumps)
레이블 기반 셀렉터 (label-based selectors)
스크린샷 및 로그
Python 및 서브프로세스 (subprocess) 통합
인간의 디버깅을 위한 터미널 UI

로컬 루프 (local loop)는 다음과 같은 형태를 띱니다:

hs use
hs ui
hs tap "Continue"
...

호스팅 버전은 이를 세션 관리 (session management), 인증 (auth), 과금 (billing), 격리 (isolation), 녹화 (recording) 및 재생 (replay) 기능으로 감싸게 될 것입니다.

FAQ

Android 디바이스 클라우드는 Appium 클라우드 테스트와 동일한가요?

정확히는 아닙니다. Appium 클라우드는 보통 테스트 스위트 (test suites)에 최적화되어 있습니다. Android 에이전트 클라우드는 모델 주도 실행 (model-driven runs)을 위해 더 낮은 지연 시간의 관찰 (observations), 프롬프트 친화적인 컴팩트한 UI 출력, 그리고 더 나은 단계별 재생 (step-by-step replay) 기능이 필요합니다.

LLM 에이전트에게 실제 Android 디바이스가 필요한가요?

경우에 따라 다릅니다. 많은 앱 흐름과 실험에는 에뮬레이터 (emulators)로도 충분합니다. 하지만 하드웨어 동작, OEM 스킨, 푸시 전달 (push delivery), 생체 인식 (biometrics) 또는 프로덕션과 유사한 동작이 중요한 경우에는 실제 디바이스가 중요합니다.

왜 그냥 스크린샷만 사용하지 않나요?

스크린샷은 유용하지만, 비용이 많이 들고 모호합니다. 컴팩트한 UI 테이블은 모델에게 실행 가능한 레이블 (labels)과 컨트롤 (controls)을 제공합니다. 스크린샷은 유일한 관찰 수단이 아니라 추가적인 관찰 수단으로 사용하십시오.

루팅 (root)이 필요한가요?

아니요. 유용한 Android 에이전트 런타임 (runtime)은 일반적인 UI 자동화를 위해 ADB와 쉘 사용자 (shell user)를 통해 작동할 수 있습니다. 일부 보호된 화면과 앱 전용 데이터는 여전히 보호된 상태로 유지됩니다.