Appium은 어떻게 동작할까? 모바일 테스트 자동화 실행 흐름 이해하기
W3C WebDriver부터 Appium Server, Driver, Android와 iOS 자동화 과정까지
· Dev- views
Appium은 어떤 도구일까?
Appium은 Android와 iOS 모바일 애플리케이션을 자동으로 테스트하도록 돕는 오픈소스 테스트 자동화 프레임워크입니다.
사용자가 직접 스마트폰을 조작하지 않아도, 코드로 화면을 터치하고 텍스트를 입력하고 버튼을 누를 수 있습니다. 화면이 정상적으로 동작하는지도 확인합니다.
로그인 기능을 테스트하는 상황을 예로 들어보겠습니다. 보통은 사람이 직접 앱을 실행하고, 로그인 화면으로 이동한 뒤, 아이디와 비밀번호를 입력하고 로그인 버튼을 누릅니다. 이후 메인 화면에 제대로 진입했는지도 확인해야 합니다.
이 과정을 Appium으로 작성하면 버튼 선택, 값 입력, 화면 전환 확인까지 코드로 실행할 수 있습니다. 테스트를 한 번 작성해 두면 같은 시나리오를 언제든 반복 실행할 수 있어 테스트 시간과 휴먼 에러를 크게 줄입니다.
Appium의 큰 장점 중 하나는 하나의 테스트 코드로 Android와 iOS를 함께 테스트할 수 있다는 점입니다. 플랫폼마다 일부 설정은 다르지만, 대부분의 테스트 로직을 공통으로 사용할 수 있어 유지보수 비용도 줄어듭니다.
특히 Appium은 실제 사용자가 앱을 조작하는 방식과 매우 비슷하게 동작합니다. 내부 코드를 직접 호출하지 않고, 화면에 표시된 UI 요소를 찾아 클릭하거나 입력하기 때문에 실제 사용 환경에 가까운 테스트가 가능합니다.
이런 이유로 Appium은 로그인, 회원가입, 상품 구매, 예약, 결제처럼 사용자의 흐름을 따라가는 시나리오, 즉 E2E 테스트를 자동화할 때 널리 쓰입니다.
Appium의 실행 흐름
Appium의 실행 흐름은 크게 테스트 코드, Appium Server, 플랫폼별 Driver, 자동화 프레임워크, 실제 기기 순서로 이어집니다.
테스트 코드는 Appium Server에 기기 조작 명령을 직접 내리지 않습니다. 먼저 W3C WebDriver Protocol 형식의 요청으로 변환되어 전달됩니다. Appium Server는 받은 요청을 분석한 뒤, 테스트 대상 플랫폼에 맞는 Driver로 명령을 넘깁니다.
Test Script
가장 먼저 Python, Java, JavaScript, C# 등의 언어로 작성한 테스트 코드가 실행됩니다.
특정 버튼을 선택하거나 텍스트를 입력하는 코드를 작성하면, Appium Client는 해당 명령을 W3C WebDriver Protocol 형식의 HTTP 요청으로 바꿉니다.
element.click()이 코드는 내부적으로 Appium Server에 특정 요소를 선택하라는 요청으로 전달됩니다.
W3C WebDriver Protocol
W3C WebDriver Protocol은 테스트 코드와 Appium Server가 통신할 때 사용하는 표준 규격입니다.
테스트 코드에 작성한 명령은 HTTP 요청 형태로 전달되고, Appium Server는 요청을 처리한 뒤 실행 결과를 응답으로 돌려줍니다.
이 구조 덕분에 Appium은 특정 프로그래밍 언어에 묶이지 않고 Python, Java, JavaScript 등 다양한 언어를 지원합니다.
Appium Server
Appium Server는 테스트 코드와 모바일 플랫폼 사이에서 요청을 중계합니다.
주요 역할은 테스트 코드에서 전달된 요청을 받고, 테스트 세션을 생성하고 관리하며, 대상 플랫폼에 맞는 Driver를 선택해 명령을 넘기는 것입니다. 실행 결과도 다시 테스트 코드로 반환합니다.
Appium Server가 화면을 직접 누르거나 텍스트를 입력하지는 않습니다. 실제 기기 제어는 플랫폼별 Driver와 자동화 프레임워크를 거쳐 이루어집니다.
Platform Driver
Appium Server는 테스트 대상 운영체제에 따라 서로 다른 Driver를 사용합니다.
Android에서는 일반적으로 UiAutomator2 Driver를 사용하고, iOS에서는 XCUITest Driver를 사용합니다.
Android 및 iOS 자동화
Driver는 각 운영체제가 제공하는 자동화 기술을 사용해 실제 명령을 수행합니다.
Android에서는 UiAutomator2를 중심으로 자동화가 이루어지고, iOS에서는 XCUITest와 WebDriverAgent를 통해 기기를 제어합니다.
Device
마지막 단계에서는 전달된 명령이 실제 기기나 가상 기기에서 실행됩니다.
Android는 실제 기기와 Emulator를 사용할 수 있고, iOS는 실제 iPhone과 Simulator를 사용할 수 있습니다.
버튼 선택, 텍스트 입력, 스크롤 같은 동작이 끝나면 결과가 역순으로 전달됩니다. 테스트 코드는 이 응답을 바탕으로 명령의 성공 여부를 확인하고 다음 테스트 단계를 실행합니다.
| 구분 | Android | iOS |
|---|---|---|
| Driver | UiAutomator2 Driver | XCUITest Driver |
| Automation | Android Automation | iOS Automation |
| Device | Android Device / Emulator | iPhone / Simulator |
Appium이 적합한 테스트 범위
Appium은 실제 사용자가 앱을 조작하는 흐름을 검증할 때 특히 유용합니다. 버튼 선택, 텍스트 입력, 화면 전환, 스크롤처럼 사용자 행동에 가까운 동작을 실제 기기나 가상 기기에서 확인할 수 있기 때문입니다.
대표적으로 로그인, 회원가입, 상품 구매, 예약, 결제처럼 여러 화면을 거치는 핵심 시나리오에 잘 맞습니다. 이런 기능은 API 응답이나 내부 로직만 확인해서는 충분하지 않습니다. 실제 화면에서 사용자가 의도한 흐름대로 이동하는지도 함께 봐야 합니다.
Android와 iOS를 모두 지원하는 서비스라면 같은 시나리오를 여러 환경에서 반복 검증할 수 있다는 점도 장점입니다. 배포 전 회귀 테스트나 주요 기능의 스모크 테스트를 자동화할 때 효과적으로 활용할 수 있습니다.
반대로 모든 테스트를 Appium으로 자동화할 필요는 없습니다. 화면 변경이 잦아 테스트 코드를 자주 수정해야 하는 기능이나, 자동화 구축 및 유지보수 비용이 매뉴얼 테스트 비용보다 큰 경우에는 오히려 비효율적일 수 있습니다. 자동화는 반복 수행 가치가 높고 유지보수가 가능한 테스트에 적용할 때 가장 큰 효과를 냅니다.
마치며
이번 글에서는 Appium이 어떤 도구인지, 테스트 코드에서 작성한 명령이 실제 모바일 기기까지 어떤 흐름으로 전달되는지 살펴봤습니다.
다음 포스팅에서는 Appium 테스트를 실행하기 위한 환경 설정 과정을 정리해보겠습니다.
