대규모 언어 모델 기반 스마트폰 앱 사용 자동화 기술 동향

LLM 기반 앱 사용 자동화 에이전트의 학습을 위해서는 대량의 데이터가 필요하고, 참고문헌[5]에서 공개한 AITW(Android in the Wild) 데이터셋이 널리 이용된다. AITW 데이터셋은 GOOGLEAPPS, WEBSHOPPING, INSTALL, GENERAL, SINGLE의 5개 세부 카테고리로 구성된다. 데이터셋의 구성 설명에 일반적으로 사용하는 용어는 표 2와 같다.

AITW 데이터셋은 30,378개 Instruction과 715,142개 Episode로 구성된다. 웹 검색과 같이 매번 결과가 다를 수 있는 Task는 Instruction이 같아도 Episode를 구성하는 Screen과 Action은 다를 수 있어서 한 개의 Instruction에 복수의 Episode를 생성할 수 있다. Task를 구성하는 Step(UI 변화 또는 화면의 전환이 생기는 경우)이 복수이면 Multi-Step Task이며, 그렇지 않으면 Single-Step Task로 분류한다. GOOGLEAPPS, WEBSHOPPING, INSTALL, GENERAL 카테고리는 Multi-Step Task에 해당한다.

그림 1은 AITW 데이터셋의 INSTALL 카테고리에서 Uninstall “Google News” Instruction에 해당하는 Episode의 Step3부터 Step6까지의 Screen Shot과 Predicted Action을 보여준다. “Google News” 앱을 찾기 위한 입력이 자동으로 실행되고, 검색 결과로 나온 “Google News”를 선택해서 설치 관련 화면이 나타난다.

그림 1

AITW 데이터셋 INSTALL 카테고리에서 uninstall “Google News” Instruction에 해당하는 Episode 구성과 Action Prediction 예

참고문헌[5]에서 데이터셋 평가를 위해서 사용한 자동화 에이전트는 그림 2와 같이 동작한다. PaLM 2[6] LLM을 사용하며, 현재 화면의 UI는 HTML syntax를 이용하여 표현된다. AITW 데이터셋에 UI 구성 정보가 포함되어 있기 때문에 UI 분석 과정은 실제로 일어나지는 않는다.

그림 2

LLM 기반 자동화 에이전트 동작 흐름

자동화 에이전트의 성능 평가 Metric으로 Action Accuracy와 Task Success Rate가 주로 사용된다. Multi-Step Task가 실패인 경우에도 Task를 구성하는 일부 Action은 성공일 수 있기 때문에 Action Accuracy가 Task Accuracy보다 높은 경향을 보인다. 성공 여부를 판단함에 있어서 자동화 에이전트의 Action Prediction이 Ground Truth Action과 정확히 일치하기 어렵기 때문에 일정 수준의 오차는 허용하는 metric을 이용하여 학습하고 테스트한다.

표 3은 참고문헌[5]에서 제안한 자동화 에이전트의 Action Accuracy를 나타낸다. BC(Behavioural Cloning)는 참고문헌[5]에서 제안한 Transformer 기반의 에이전트이며 LLM 기반 에이전트보다 더 좋은 성능을 보인다. 표 3에서 BC-history는 현재 Episode에서 직전 Step까지 UI와 Action 정보를 추가로 사용한 결과이다.

일반적으로 LLM은 특정 분야에 특화된 데이터가 아니고 다양한 분야의 데이터로 학습을 하고, AITW 데이터셋과 같이 앱 사용에 특화된 데이터로 LLM을 Fine-Tuning 해서 앱 사용 자동화 에이전트가 만들어진다. 이렇게 생성된 자동화 에이전트는 상식적 지식(Commonsense Knowledge)과 Fine-Tuning에 사용된 앱에 대한 지식을 갖고 있지만 학습되지 않은 앱에 적용 시 성능 저하가 나타날 수 있다.

이러한 문제를 해결하기 위하여 AutoDroid[7]는 그림 3과 같이 특정 앱에 대한 사전 탐색을 통하여 UTG(UI Transition Graph)를 생성하고, 현재 진행 중인 Task와 유사한 정보를 UTG에서 추출하여 LLM에 입력함으로써 Action Prediction 정확도를 높인다. 참고문헌[7]의 시험 결과에 따르면 사전 탐색 정보를 GPT-4에 추가로 입력 시 Action Accuracy가 2.7% 상승하고, 소형 Language Model인 Vicuna 7B[8]에 입력 시 53.4% 상승한다. 이 시험 결과에서 주목할 점은 GPT-4와 같이 일반 추론 성능이 높은 LLM을 사용하면 특정 앱에 대한 사전 지식이 없어도 높은 정확도를 보이지만, 소형 Language Model에 기반한 자동화 에이전트의 정확도를 높이기 위해서는 사전 탐색 정보의 활용이 중요한 역할을 할 수 있다는 것이다.

그림 3

앱 사전 탐색을 포함하는 AutoDroid 동작 흐름

출처 Reproduced from H. Wen et al., “AutoDroid: LLM-powered Task Automation in Android,” in Proc. Int. Conf. Mobile Comput. Netw., (Washington D.C. DC USA), Nov. 2024, pp. 543–557.

AutoDroid[7]는 자체 제작 데이터셋에 대한 시험 결과만 제공하므로 LLM 기반의 다른 방법과 직접적인 성능 비교는 어렵다. AutoDroid[7]는 사전 탐색을 통하여 특정 앱에 대한 지식 생성 방법 외에 소형 Language Model의 성능 향상을 위한 Fine-Tuning과 처리 속도 향상을 위한 Query Optimization 방법도 제안한다.

Auto-UI[12]는 그림 4와 같이 앱 UI를 텍스트로 표현하지 않고 앱 Screen Shot 이미지를 BLIP-2[15]로 Encoding 후에 Projection Layer를 거쳐서 LLM에 입력한다. LLM은 Encoder-Decoder 구조의 T5[16]를 Alpaca 데이터셋으로 Fine-Tuning한 것을 사용한다.

그림 4

Auto-UI 자동화 에이전트 동작 흐름

출처 Reproduced from Z. Zhang et al., “You Only Look at Screens: Multimodal Chain-of-Action Agents,” in Proc. Assoc. Comp. Linguistics., (Bangkok, Thailand), Aug. 2024, pp. 3132–3149.

Action history는 각 Episode에서 직전 Step까지 발생한 Action 정보를 의미한다. AITW[5]의 BC 에이전트도 Action History를 사용하기 때문에 Action History의 사용이 VLM 기반 자동화 에이전트의 고유한 특징은 아니다. Auto-UI[12]에서 사용하는 Action History는 Action Type(클릭, 텍스트 입력 등), 선택된 UI element의 좌표, Action Type이 텍스트 입력인 경우에 입력된 텍스트로 구성된다. 직전 몇 개 Step의 Action 정보를 사용할지도 성능에 영향을 주게 되며, 직전 8개 Step까지 Action 정보를 사용하면 AITW 데이터셋에 대한 Action Accuracy가 약 5% 향상하는 것으로 나타났다. Action history를 어떻게 표현하는지도 성능에 영향을 줄 수 있으며, VisionTasker[9]와 CoCo-Agent[14]는 선택된 UI element의 좌표 뿐만 아니라 선택된 Element의 설명까지 Action History로 사용하는 차이가 있다.

단, Auto-UI[12]의 공개 코드를 분석해 보면 Ground-Truth Action을 History로 사용하는 문제가 발견된다. 실생활에서 앱의 사용을 자동화하기 위해서는 Predicted Action을 History로 사용해야 하고, Prediction에 오류가 있을 수 있기 때문에 Auto-UI[12] 논문의 실험 결과와 같은 정확도 향상이 어려울 수도 있다. Predicted Action을 History로 사용하면 정확도가 향상되는지 여부는 시험을 통해 확인이 필요하다.

CogAgent[13]는 Auto-UI[12]와 비교하여 Action History를 사용하지 않고, Screen Shot 이미지 Encoding 과정을 고해상도와 저해상도 이미지 Encoding으로 세분화하는 차이가 있다. 작은 아이콘과 텍스트 정보를 활용하기 위해서는 고해상도 이미지를 사용해야 하지만 이미지Token Size를 증가시켜서 처리 속도 저하의 원인이 된다. 가령, 1,120×1,120 이미지를 14×14 patch size로 처리하면 6,400개의 Token이 생성되고, 224×224 이미지는 256개의 Token 이 생성된다. Transformer 기반의 Language Model은 입력 Token Size의 제곱에 비례하여 처리 시간이 증가하는 경향이 있으므로 이미지 해상도가 5배 증가하면 처리 시간은 625배 증가하는 것으로 단순 계산할 수 있다.

고해상도 이미지를 사용하면서 처리 속도 저하를 줄이기 위해서 약 0.3B parameter의 이미지 Encoder를 이용한다. 저해상도 이미지 Encoder는 4.4B Parameter를 가지는 것과 비교하여 매우 경량형 Encoder를 사용함을 알 수 있다. 경량 이미지 Encoder 사용으로 인한 성능 한계를 극복하기 위하여 고해상도 이미지 Encoding 결과를 저해상도 이미지를 입력으로 받는 VLM과 Cross-Attention을 이용하여 융합하는 방법을 제안한다.

CoCo-Agent[14]는 Auto-UI[12]와 비교하여 BLIP-2[15] 이미지 Encoder를 CLIP[17]으로 변경하고, UI를 설명하는 텍스트를 추가로 LLM에 입력하는 차이가 있다. CoCo-Agent[14]의 동작 흐름은 그림 5와 같다. 그리고 AITW[5] 데이터셋에서는 Touch Point와 Lift Point가 같은 Tab Action도 두 개 Point를 Prediction하도록 하지만, CoCo-Agent[14]는 한 개 Point만 Prediction해서 오류 발생 소지를 줄인다.

그림 5

CoCo-Agent 동작 흐름

출처 Reproduced from X. Ma et al., “CoCo-Agent: A Comprehensive Cognitive MLLM Agent for Smartphone GUI Automation,” in Proc. Assoc. Comp. Linguistics., (Bangkok, Thailand), Aug. 2024, pp. 9097–9110.

VLM 기반 앱 사용 자동화 에이전트의 AITW[5] 데이터셋에 대한 시험에서 표 4와 같이 CoCo-Agent[14]가 가장 높은 Action Accuracy를 보인다. CoCo-Agent[14]는 앱 Screen Shot 이미지와 UI 텍스트 표현 정보를 모두 이용하는 것이 성능 향상에 주효했을 수 있다. 하지만, 사용된 Language Model이 다르므로 에이전트별로 특별한 세부 방법이 성능에 미치는 영향을 확인하기 위해서는 동일한 Language Model을 사용하는 시험이 필요하다. 그리고, Cog Agent[13]는 AITW[5] 데이터셋으로 학습하기 전에 자체 제작한 데이터셋으로 Pre-Training을 한다. 따라서 Pre-Training 단계 없이 학습한 모델로 성능 비교를 해야 에이전트별로 강점으로 제시하는 방법의 상대적 효용성을 확인할 수 있다.

지금까지 살펴본 자동화 에이전트들의 성능 평가를 위해서 사용하는 AITW[5] 데이터셋의 WEBSHOPPING과 GENERAL 카테고리에서는 정확도가 상대적으로 낮게 나타난다. CoCo-Agent[14]의 WEBSHOPPING 카테고리에 대한 Action Accuracy는 75%이다. WEBSHOPPING 카테고리의 Task는 그림 1과 같이 검색 후 선택으로 이어지는 흐름이 유사하고, 검색어 입력창도 화면 상단의 유사한 위치에 있는 경우가 많다.

하지만, 참고문헌[3]의 통계 자료에 나타난 것처럼 고령인이 사용에 어려움을 겪는 교통/서비스 예약의 대표적인 앱인 코레일톡을 살펴보면 복잡도의 차이가 큼을 알 수 있다. 그림 6은 코레일톡 앱을 이용한 기차표 예매에서 일부 화면을 보여준다. AITW[5] 데이터셋에 대한 시험에서는 고려하지 않아도 되는 여러 가지 어려움이 파악되며, 대표적인 몇 가지를 정리하면 다음과 같다.

그림 6

코레일톡 앱을 이용한 기차표 예약에 필요한 Action 예

• 필요한 정보가 한 화면에 나타나지 않아서 화면 또는 특정 영역을 Swipe하고, 필요한 정보가 화면에 보이는 시점을 인식할 수 있어야 함

• 결제나 로그인 등을 위해서 복수의 정보를 해당 항목에 정확히 입력할 수 있어야 함. 입력할 정보가 사용자 Instruction에 명시적으로 포함되어 있지 않으면 자동 입력이 어려울 수 있음

• 사용자가 요청한 Task를 완료했는지 판단할 수 있어야 함. AITW[5] 데이터셋은 Episode의 끝까지 진행하면 완료이므로 Task 완료 여부를 판단하지 않음

자동화 에이전트의 성능 평가에 사용되는 앱과 실제 활용성이 있는 앱 간의 괴리가 크기 때문에 현실성 있는 데이터셋을 구축하고 학습 및 시험 평가를 하는 것이 중요하다.

본고에서 설명한 자동화 에이전트들은 사용자 시험을 위해서 ADB(Android Debug Bridge)를 이용한다. ADB는 안드로이드 기반의 장치와 통신하여 디버깅 등의 작업을 수행하는 Command Line Tool이며, 안드로이드 SDK에 포함되어 있다. ADB를 사용하기 위해서는 USB 또는 WiFi로 연결된 PC가 있어야 하므로 스마트폰만을 사용하는 실생활에는 적용할 수 없는 방식이다.

스마트폰이 독립적으로 동작하고 미리 정하지 않은 임의의 앱 사용을 자동화하기 위해서는 스마트폰에서 백그라운드로 동작하는 자동화 에이전트가 필요하다. 자동화 에이전트는 다음의 기능을 수행할 수 있어야 한다.

• 앱의 버튼이나 메뉴를 사람이 터치해서 실행하지 않고 해당 좌표 정보를 이용하여 터치한 것과 같은 효과를 낼 수 있어야 함. 가령, 버튼의 좌표가 (50, 50)이면 자동화 에이전트에서 click(50, 50) 함수를 호출 시 현재 화면에 보이는 앱의 (50, 50) 위치에 있는 버튼이 클릭되어야 함

• 현재 화면에 보이는 앱이 아니고 백그라운드 앱에서 스크린샷을 얻을 수 있어야 함

하지만, 복수의 안드로이드 보안 전문가 의견에 따르면 이러한 기능의 구현을 위해서 특별한 권한이 필요하다. 즉, 루팅을 하거나 제조사 권한이 필요하고, 안드로이드 OS 자체를 수정해야 할 수도 있다. 따라서, 현재 안드로이드 환경에서는 갤럭시와 같은 스마트폰에 자동화 에이전트를 탑재하는 것은 어렵다고 판단된다.

가. 처리 시간

AutoDroid[7] 논문에 따르면 Vicuna-7B Model을 스마트폰에서 실행 시 한 Step 실행에 30초 이상, 클라우드 GPT-4를 사용 시 20초 정도 소요된다. 처리 시간은 사용자 Instruction 완료에 필요한 Step의 수(즉, Episode 길이)에 비례하여 증가한다. 코레일톡 앱을 이용한 기차표 예약은 10개 이상의 Step을 거치므로 클라우드 GPT-4를 이용하더라도 3분 이상이 소요된다. 클라우드 기반 LLM은 On-Device LLM보다 빠르지만 비용이 발생할 수 있는 문제도 있다.

앱 UI가 복잡하면 UI의 텍스트 표현이 길어질 수 있고, 초기 화면에 모든 정보가 나타나지 않아서 스크롤 등을 통해서 전체 정보를 포함하는 화면을 재구성한다면 VLM에 입력되는 이미지 해상도 또한 높아져야 한다. 이와 같은 이유로 AITW[5] 데이터셋이 아니고 실사용 앱을 대상으로 시험하면 LLM에 입력되는 Token Size가 증가하여 처리 시간이 늘어날 가능성이 있다.

자동화 에이전트 사용자가 감내할 수 있는 처리 시간은 사용자 시험을 통해 확인해야 하지만 몇 분을 기다릴 수 있을 것으로 예상하기는 어렵다. 따라서, 경량 LLM을 사용하면서 정확도를 높일 수 있고, LLM에 입력되는 Token Size를 줄이는 연구가 필요하다.

나. 사용자 Instruction 입력

앱을 사용하기 전에 최종 목표와 중간 Step에서 필요한 정보까지 모두 포함하여 Instruction을 만들기는 어렵다. 고령인은 적절한 Instruction을 구성하는 데 특히 더 어려움을 겪을 것으로 예상되고, 텍스트를 타이핑해서 입력하는 자체가 진입 장벽이 될 수도 있다. 텍스트 입력뿐만 아니라 음성 입력 방식도 제공되어야 하며, 오타와 같은 오류를 자동 보정하는 기능도 필요할 것으로 예상된다.

그리고 필요한 서비스를 받기 위한 전체 과정에서 어려움을 겪기보다는 특정 Step에서만 도움이 필요할 가능성이 높다. 따라서 특정 Step에서만 자동화를 지원하는 기능도 필요하다.