하나의 앱으로 쇼핑, 결제, 금융까지 모든 것을 해결하는 ‘슈퍼앱’ 시대. 기능이 많아질수록 QA가 검증해야 할 시나리오는 기하급수적으로 늘어납니다. 모든 경로를 사람이 직접 테스트하는 것은 불가능에 가깝습니다.

이에 개발 업계에서는 스크립트 기반 자동화(Appium, Selenium 등)를 도입하고는, 이내 새로운 문제에 부딪혔습니다.

깨지기 쉬운 스크립트: 버튼 하나만 바뀌어도 스크립트는 오류가 발생했고, 스크립트의 유지보수 비용이 커졌습니다.
예측 불가능한 환경: 다양한 기기, OS 버전, 네트워크 속도, 갑자기 튀어나오는 팝업 등 스크립트의 실패 원인은 너무나도 다양했습니다.

결국 스크립트 기반의 자동화 테스트는 ‘가끔 도움이 되는’ 수준에 머물러 있고, 여전히 테스트는 자동화 되지 않고, 많은 시간과 리소스가 사용되고 있었습니다.

기존 UI 테스트의 도전 과제

많은 기업과 팀이 Appium 등 기존 UI 테스트 자동화 도구를 도입했지만, 다음과 같은 문제로 인해 실제 현업에서는 자동화의 효과를 제대로 누리기 어려운 부분이 있습니다.

자주 변경되는 element ID/XPath: 앱의 구조나 UI가 자주 변경되면 기존 테스트 스크립트는 동작하지 않습니다. QA는 이를 다시 추적하고 수정을 반복해야 하며, 유지보수 비용이 계속해서 발생합니다.
OS 및 App 버전 파편화: 각 디바이스, OS 버전, 해상도, App 빌드의 차이로 인해 각각의 디바이스에서 UI 요소의 위치의 차이로 인한 테스트 실패가 발생할 수 있습니다.
타이밍 이슈 : 네트워크 지연, 애니메이션 처리, 렌더링 속도 차이로 인해 ‘정확한 시점’에서 액션을 수행할 수 없고, 테스트 실패로 이어집니다.
에러 대응의 경직성: 예상치 못한 팝업(os, app), 안내창, 실제 디바이스에서 발생하는 예외 상황에 스크립트로 대응하기 어렵습니다.

AI를 사용한 UI Test 사례

최근에는 LLM과 AI 기반 도구를 활용해 기존 방식의 한계를 넘어서는 연구 및 사례가 있습니다.¹

AutoDroid²
- 사람이 사용하는 자연어(Natural Language)로 작성된 테스트 시나리오를 이해하고, 이를 실제 모바일 UI 액션으로 변환하는 접근 방식의 대표적인 예입니다.
Fastbot³
- APK 파일 분석과 강화학습(Reinforcement Learning)을 결합하여 테스트 시나리오를 자율적으로 생성하고 탐색하는 접근 방식입니다.
Firebase Testing Agent⁴
- 앱을 자동으로 테스트할 수 있는 서비스입니다. 최근에는 AI 기반의 테스트 에이전트가 도입되어, 더 지능적인 테스트가 가능해지고 있습니다.

DeviceFarm QA 에이전트

최근 AI와 LLM의 발전은 이러한 테스트 자동화의 새로운 가능성을 열어주고 있습니다. 글로벌 IT 기업들도 AI 기반의 테스트 자동화를 시도하고 있는 가운데, 카카오는 기존에 구축해서 활용 중인 DeviceFarm⁵ 인프라를 활용하여 AI 기반 UI 테스트 자동화 프로젝트를 시작하게 되었습니다.

이 장에서는 AI 기반 UI 테스트 자동화 시스템을 개발하면서 얻은 경험과 실제 구현 사례를 공유하고자 합니다.

QA 에이전트를 통한 AI 기반 테스트 자동화

DeviceFarm QA 에이전트는 기존의 수동 테스트나 스크립트 기반 자동화의 한계를 극복하기 위해 탄생한 AI 기반 UI 테스트 자동화 솔루션입니다.

DeviceFarm은 웹 기반 원격 디바이스 테스트 환경을 제공하며, Appium 스크립트 실행과 수동 테스트를 모두 지원합니다. QA 에이전트는 이 DeviceFarm 서비스 위에서 동작하며, QA 엔지니어가 작성한 자연어 테스트케이스를 해석하여 스스로 테스트를 수행하고, 그 결과를 상세히 리포트합니다.

QA 에이전트는 LLM을 활용해 테스트케이스를 이해하고, DeviceFarm에서 제공하는 안드로이드 애플리케이션의 접근성(Accessibility) 정보와 스크린샷 API를 통해 앱의 현재 상태를 정확히 파악합니다. 이 정보를 바탕으로 다음 단계를 결정하고, 테스트가 올바르게 수행되었는지 자동으로 검증하는 과정을 반복합니다.

AI가 '사람의 말’을 이해하게 만들기

AI가 테스트를 수행하려면, 먼저 ‘무엇을’ 해야 하는지 정확히 알아들어야 합니다. QA 에이전트는 사람이 작성한 모호한 테스트 시나리오를 LLM이 명확하게 이해할 수 있는 구조화된 단계(Step)로 정제하는 것부터 시작합니다.

기존 QA 테스트케이스 (카카오맵)
- 테스트 문장: 퀵탭 > [내비] > 내 장소 영역 > [길찾기]
- 기대 결과: 선택한 목적지의 자동차 길찾기 화면으로 이동되며 도착지에 반영되어 길찾기 경로 노출되는가?
QA 에이전트를 위한 구조화된 테스트케이스
- 테스트케이스 이름: 내장소 길찾기 기능 확인
- Step 1: 로그인
  - 목표: 카카오맵 실행 후 카카오계정으로 로그인한다.
  - 성공기준: 프로필 이미지가 보이며 로그인된 상태여야 한다.
- Step 2: 길찾기 실행
  - 목표: 퀵탭의 '내비’를 누르고, 내 장소 영역의 '길찾기’를 탭한다.
  - 성공기준: 자동차 길찾기 화면으로 이동하고, 도착지가 내 장소로 설정되어야 한다.

이처럼 각 단계의 목표와 성공 기준을 명확히 정의해야만, AI는 자신이 무엇을 해야 하고, 언제 성공했는지를 판단할 수 있습니다.

핵심 동작 원리: 보고, 생각하고, 실행하기

구조화된 테스트케이스를 입력받은 QA 에이전트는 [인식 → 결정 → 실행]의 순환 구조를 반복하며 자율적으로 테스트를 수행합니다.

인식: 화면을 어떻게 ‘보는가’?

사람이 화면을 눈으로 보듯, QA 에이전트는 접근성(Accessibility) API와 스크린샷 두 가지 정보를 함께 사용해 현재 화면을 파악합니다. 각각의 정보가 필요할 때 DeviceFarm의 API를 호출해서, 필요한 정보를 얻습니다.

접근성 API를 통해 가져온 데이터를 가공을 진행합니다. 테스트 수행에 필요한 데이터 위주로 정규화를 수행하며 XML로 변환합니다.

필요 시에는 아이콘 식별 및 OCR을 사용해, XML에 아이콘 및 텍스트 정보를 추가합니다.

결정: LLM은 어떻게 ‘생각하는가’?

화면 분석이 끝나면, QA 에이전트는 이 정보를 LLM에게 넘겨 다음 행동을 결정하게 합니다. 이 과정의 핵심은 프롬프트 엔지니어링입니다. LLM에게는 테스트 목표, 이전 행동 요약, 그리고 현재 화면 분석 정보가 포함된 프롬프트가 전달됩니다.

LLM은 주어진 정보를 종합하여 다음 행동을 논리적인 명령어 형식으로 출력합니다. 예를 들어, ‘내비’ 탭을 누르라는 판단을 내리면 다음과 같은 결과를 반환합니다.

{ "action": "tap", "element_id": 12, "reason": "내비 탭을 누른다" }

실행 및 검증: 로봇은 어떻게 ‘움직이는가’?

LLM이 결정한 논리적 명령어는 QA 에이전트 시스템으로 전달되어 물리적인 실행 좌표로 변환됩니다. 예를 들어, element_id: 12 정보는 해당 UI 요소의 화면상 위치(bounds)를 기반으로 실제 탭(tap)할 좌표 (x: 1000, y: 500)로 변환됩니다.

이 좌표 기반의 명령은 DeviceFarm API를 통해 실제 디바이스에서 수행됩니다. QA 에이전트는 탭, 스와이프, 텍스트 입력 등 사용 가능한 모든 액션을 API 형태로 미리 알고 있습니다.

액션이 실행된 후, QA 에이전트는 다시 인식 단계로 돌아가 화면에 어떤 변화가 일어났는지 확인합니다. 이 과정을 반복하며 최종 성공 기준을 만족할 때까지 테스트를 진행합니다. 이러한 구조 덕분에 QA 에이전트는 UI가 일부 변경되거나 예상치 못한 팝업이 나타나더라도 목표를 기반으로 테스트를 계속 이어나가는 회복탄력성(Resilience)을 갖게 됩니다.

2-4. 테스트케이스별 결과 제공

테스트가 완료되면 성공/실패 여부, 실패 원인 분석, 단계별 스크린샷과 영상 등 상세한 결과 리포트를 제공하여 사용자가 문제를 빠르게 파악하고 수정할 수 있도록 돕습니다.

QA 에이전트의 진화

QA 에이전트는 여기서 멈추지 않고 더 지능적인 테스트 자동화를 위해 계속해서 개발을 진행하고 있습니다.

RAG 도입으로 서비스의 '의도’를 파악하는 AI

QA 테스트 케이스 기반 RAG 구축
기획, 디자인, 코드, 테스트 산출물 기반 RAG 구축
QA 에이전트가 테스트 수행 시 RAG를 쿼리하여, 더 정확한 컨텍스트와 기대 동작을 파악합니다.
자연어 테스트케이스와 RAG에서 추출한 정보를 결합해, 액션 플랜(Action Plan)을 생성합니다.

테스트 케이스 생성

궁극적으로 QA 에이전트는 테스트케이스를 생성하는것을 목표로 합니다. APK 파일을 분석해 앱의 모든 기능을 파악하는 상향식 관점과 RAG를 통해 핵심 비즈니스 시나리오를 추출하는 상향식, 하향식 관점 둘 다에서 테스트가 필요한 부분을 스스로 찾아내 검증하는 것입니다. 사람이 개입하지 않아도 서비스의 맥락에 맞는 테스트를 자동으로 생성하고 실행하여 커버리지를 극대화하는 방향으로 나아가려고 합니다.

상향식(Bottom-up) 관점
- APK 분석 기반 시나리오 생성
- APK 파일을 정적/동적으로 분석하여 앱의 화면, 상태, 전이(액션) 정보를 추출합니다.
- 상태-액션 그래프를 자동으로 구축하고, 가능한 사용자 플로우를 탐색합니다.
- RAG(Knowledge Base)에서 추출한 도메인 지식(예: 주요 기능, 정책, UI 요소 설명 등)을 활용해, 단순 탐색이 아닌 의미 있는 시나리오(예: 결제, 회원가입 등)로 테스트를 유도합니다.
- Fastbot, AutoDroid 등과 유사하게, 강화학습이나 에이전트 기반 탐색을 통해 미탐색 경로, 예외 상황 등도 자동으로 커버합니다.
하향식(Top-down) 관점
- 도메인 지식 기반 시나리오 보강
- 기획/디자인/QA 테스트케이스 등 상위 요구사항에서 추출한 시나리오(예: “로그인 후 결제까지 정상적으로 완료되어야 한다”)를 RAG에서 검색·추출합니다.
- 추출된 시나리오를 APK 분석 결과(상태-액션 그래프)와 매핑하여, 실제 앱에서 해당 플로우가 구현되어 있는지 자동으로 검증합니다.
- 만약 상위 시나리오가 구현에 누락되어 있거나, 예상과 다르게 동작한다면 이를 자동으로 리포트합니다.
- 하향식 시나리오와 상향식 탐색 결과를 결합해, 테스트 커버리지와 신뢰성을 극대화합니다.

각주

[출처] https://devocean.sk.com/blog/techBoardDetail.do?ID=166778
[출처] https://autodroid-sys.github.io/
[출처] https://mp.weixin.qq.com/s/QhzqBFZygkIS6C69__smyQ
[출처] https://firebase.blog/posts/2025/04/app-testing-agent
카카오 사내의 Appium 기반 모바일 테스트 자동화 시스템

[목차] AI Native: 실행과 확산 사례집

DeviceFarm AI를 사용한 QA 테스트 자동화