LLM을 사용하면 자연어 지시로부터 Android용 조작 플로우를 상당히 빠르게 만들 수 있습니다. 예를 들어, 앱을 열기, 특정 화면까지 이동하기, 텍스트 확인하기, 스크린샷 남기기, 조건에 따라 분기하기, 실패 시 정지하기와 같은 작업은 많은 QA 팀이나 운영 팀에게 일상적입니다. 매번 처음부터 수동으로 구성하는 것보다 프롬프트로부터 초안을 만들 수 있다면 효율은 올라갑니다.

하지만 LLM 생성 워크플로우에는 함정도 있습니다. 모델은 그럴듯한 절차를 만들 수 있지만, 실제 단말 상태, package id, 화면 크기, 이용 가능한 템플릿, OCR 대상, 로케일(Locale), 계정 조건, 로딩 시간까지는 자동으로 알지 못합니다. 그 부분을 모호하게 둔 채 실행하면 "왜 실패했는지"를 알기 어려운 블랙박스가 됩니다.

제가 Android 자동화에서 현실적이라고 생각하는 흐름은 다음과 같습니다.

• 자연어로 목적과 경계를 작성한다
• LLM에게 워크플로우 초안을 만들게 한다
• Graph View로 노드, 분기, 정지 조건, 증적을 리뷰한다
• 실기기 또는 에뮬레이터에서 작게 실행한다
• 스크린샷, OCR, 로그를 보고 조정한다

이러한 사고방식은 LaiCai의 메인 기사에서도 자세히 설명하고 있습니다: LLM Generated Android Workflows with LaiCai Flow Graph View.

나쁜 프롬프트의 예는 "로그인을 테스트해줘"입니다. 인간이라면 문맥으로 보충할 수 있지만, 자동화 플로우로서는 정보가 부족합니다. 시작 상태는 어디인지, 어떤 앱인지, 테스트 계정은 승인되었는지, 환경은 운영(Production)인지 staging인지, 성공 조건은 무엇인지, 무엇을 증적으로 남길지, 실패 시 어디서 멈출지가 불분명합니다.

더 좋은 프롬프트는 다음과 같이 경계를 포함합니다.

준비된 Android 테스트 단말에서 staging 앱을 열고, 승인된 QA 계정으로 로그인하여, 홈 화면을 대기하고, 계정 이름이 표시되어 있는지 확인하고, 스크린샷을 저장하며, 기대 텍스트를 찾지 못하면 정지하고 로그를 남긴다.

이 정도까지 작성하면, LLM은 "대충 조작하는 것"보다 리뷰하기 쉬운 워크플로우를 내놓기 쉬워집니다. 용도도 명확합니다. 이것은 QA를 위한 허가된 체크이며, 플랫폼 규약 회피, 허위 인게이지먼트(Fake Engagement), 스팸, 개인 데이터 취득, 게임 부정 조작이 아닙니다. Android 자동화에서는 이 경계를 처음에 작성하는 것이 중요합니다.

LLM이 만든 결과가 보이지 않는 스크립트만 있다면 리뷰가 어려워집니다. Graph View와 같은 시각적인 표현이 있으면, 어느 노드에서 앱을 여는지, 어디서 대기하는지, 어떤 OCR이나 UI 분석을 사용하는지, 어디서 스크린샷을 찍는지, 어떤 조건으로 분기하는지, 실패 시 어떻게 멈추는지를 확인할 수 있습니다.

Android 워크플로우를 리뷰할 때, 저는 다음 점들을 확인합니다.

• 시작 상태가 실제 단말 상태와 일치하는가
• app.open에 상당하는 처리가 추측이 아닌 확인된 package id를 사용하고 있는가
• 이미지 인식, OCR, UI tree, 템플릿, 모델이 실제로 존재하는 것인가
• 화면 전환이나 통신 뒤에 명시적인 wait 또는 상태 확인이 있는가
• 중요한 분기에서 스크린샷이나 로그가 남는가
• 기대 화면이 아닌 경우 안전하게 정지하는가

이러한 리뷰 측면이 있기 때문에 AI Android automation tool로서의 가치가 나옵니다. 중요한 것은 LLM이 항상 옳다는 이야기가 아닙니다. LLM은 초안을 빠르게 만듭니다. 인간은 Graph View로 가정을 확인합니다. 그리고 실행 결과를 증적으로 검증합니다. 이 분담이 현실적입니다.

Android UI 자동화에서는 작은 가정이 쉽게 실패로 이어집니다. staging 버전과 production 버전의 package id가 다를 수 있습니다. 버튼의 문구는 로케일에 따라 변합니다. 최초 실행 시에만 권한 다이얼로그가 나타날 수도 있습니다. 통신이 느린 단말에서는 500ms의 wait로는 부족할지도 모릅니다. 1080 x 2340 스마트폰에서 성공한 좌표 탭이 태블릿이나 에뮬레이터에서는 어긋날 수도 있습니다.

따라서 LLM에게 단말 고유 정보를 추측하게 하지 않는 것이 안전합니다. 워크플로우의 형태는 제안하게 하더라도, package id, 현재 화면, 이용 가능한 템플릿, OCR 영역, 모델, 노드 스키마는 실제 환경에서 취득하여 확인합니다. 만약 정보가 없다면 플로우 상에 "확인 필요"로 남겨야 하며, 멋대로 값을 만들어내서는 안 됩니다.

이는 LaiCai Flow guide와 같은 노드 기반 (Node-based) 사고방식과 궁합이 좋습니다. 노드별로 입력, 대기, 인식, 분기, 로그, 정지 조건을 나눔으로써, 생성된 플로우를 인간이 리뷰하기 쉬워집니다.

QA나 운영 현장에서는 자동화 결과가 pass/fail만으로는 부족합니다. 왜 성공했는지, 왜 실패했는지를 나중에 설명할 수 있어야 합니다. 스크린샷, OCR 결과, UI 상태, 분기 로그, 타임스탬프, 정지 이유가 남아 있으면 리뷰 속도가 상당히 빨라집니다.

예를 들어 로그인 확인에 실패했을 경우, 스크린샷이 있다면 네트워크 에러인지, 인증 에러인지, 권한 다이얼로그인지, 문구 변경인지 판단하기 쉬워집니다. 상품 페이지나 설정 화면 체크에서도 OCR 결과와 화면 이미지가 있다면 로케일 차이나 로딩 지연을 구분하기 쉬워집니다.

또한, 팀이 실제 기기의 화면을 보면서 조정하고 싶을 경우, 안정적인 Android 화면을 PC와 Mac에 미러링 (Mirroring) 하는 환경이 도움이 됩니다. 자동화가 보고 있는 화면과 인간이 리뷰하는 화면을 일치시킬 수 있기 때문입니다.

LLM 생성 Graph 워크플로우는 Appium, UI Automator, 단위 테스트 (Unit Test), 통합 테스트 (Integration Test), 스크린샷 테스트 (Screenshot Test), CI를 대체하는 것이 아닙니다. 이것들은 코드로 관리되는 회귀 테스트 (Regression Test)나 릴리스 게이트 (Release Gate)에 적합합니다.

Graph형 Android 워크플로우가 적합한 곳은 조금 더 운영에 가까운 영역입니다. QA의 스모크 체크 (Smoke Check), 서포트의 재현 절차, 단말기 랩의 확인, 여러 단말기에서의 가시성 체크, 아직 정식 테스트 코드로 만들기 전의 탐색적인 절차 등입니다. 플로우가 안정된 후, 그 일부를 Appium이나 UI Automator 테스트로 옮길 수도 있습니다.

현실적으로는 다음과 같이 병용하는 것이 좋다고 생각합니다.

• 단위 테스트로 로직을 보호
• Appium이나 UI Automator로 주요 UI 회귀를 보호
• 스크린샷 테스트로 레이아웃 차이를 확인
• Graph 워크플로우로 가시적인 운영 체크나 서포트 재현을 처리

이러한 분담이라면, LLM은 '자동화를 모두 맡기는 존재'가 아니라 '리뷰 가능한 초안을 만드는 존재'가 됩니다.

LLM 생성 Android 워크플로우를 실행하기 전에, 최소한 다음 사항을 확인하고 싶습니다.

• 프롬프트에 허용된 용도와 정지 경계가 작성되어 있는가
• Graph가 지원되는 노드들로만 구성되어 있는가
• 앱 실행 시 확인된 package id를 사용하고 있는가
• OCR, 템플릿, 모델, UI 분석이 실제로 존재하는가
• tap, swipe, wait의 이유를 설명할 수 있는가
• 중요한 체크포인트에서 스크린샷 또는 로그가 남는가
• 에러 분기가 안전하게 정지하는가
• 계정, 개인정보, 플랫폼 약관의 전제가 명확한가
• 우선 에뮬레이터 또는 테스트용 단말기에서 작게 시도할 수 있는가
• 실행 결과를 인간이 리뷰할 수 있는가

LLM은 Android 자동화의 초기 속도를 높여줄 수 있습니다. 다만, 단말기를 움직이기 전에 가정을 가시적인 형태로 만들 필요가 있습니다. Graph View는 이를 위한 리뷰 도구입니다. 자연어로 의도를 쓰고, LLM으로 초안을 만들고, 인간이 Graph를 확인하며, 실행 결과를 증적(Evidence)으로 확인한다. 이 흐름이라면 AI 지원 Android 워크플로우를 실제 팀 운영에 도입하기 쉬워질 것입니다.