개념
앱의 세 가지 유형
모바일 자동화를 이해하려면 먼저 앱이 어떻게 만들어졌는지 구분해야 한다.
| 유형 | 설명 |
|---|---|
| 네이티브(Native) | iOS(Swift)나 Android(Kotlin) 언어로 직접 만든 앱. 그 플랫폼 고유의 UI 컴포넌트를 쓴다 |
| 하이브리드(Hybrid) | 앱 껍데기 안에 웹 화면(모듈 9 레슨 2의 HTML/CSS)을 넣은 형태 |
| 모바일 웹(Mobile Web) | 앱이 아니라 모바일 브라우저에서 열리는 웹사이트 |
이 구분이 중요한 이유는, 테스트 방식이 완전히 달라지기 때문이다. 모바일 웹은 레슨 2에서 배운 Playwright로도 테스트할 수 있지만, 네이티브 앱은 전혀 다른 도구가 필요하다.
Appium이란
Appium은 iOS·Android 네이티브 앱을 자동화하는 도구다. 흥미로운 점은, Appium이 Selenium/WebDriver라는 웹 자동화 표준 프로토콜을 그대로 재사용해서 만들어졌다는 것이다 — 그래서 레슨 2~6에서 배운 개념(로케이터, 대기 전략, POM)의 상당 부분이 Appium에도 그대로 적용된다.
// 개념적으로 Playwright와 유사한 구조
await driver.$("~구매하기").click() // 접근성 라벨로 요소 찾기
await driver.$("~구매하기").waitForDisplayed() // 조건 기반 대기로케이터가 다시 등장한다 — 하지만 대상이 다르다
레슨 3에서 배운 "역할·라벨 기반이 가장 안정적"이라는 원칙은 모바일에서도 그대로 유효하다. 다만 웹의 HTML 대신, 네이티브 앱은 플랫폼별 접근성 속성(iOS의 Accessibility ID, Android의 content-description 등)을 쓴다.
웹: getByRole("button", { name: "구매하기" })
모바일: 접근성 라벨(Accessibility ID) "구매하기"로 요소 찾기두 플랫폼(iOS/Android) 모두에서 잘 작동하는 로케이터를 만들려면, 개발자가 처음부터 접근성 속성을 잘 붙여둬야 한다 — 이건 레슨 3에서 배운 "접근성이 잘 지켜진 화면일수록 로케이터도 안정적"이라는 원칙이 모바일에서도 그대로 적용되는 지점이다.
웹과 다른 모바일 특유의 고려사항
- 제스처(Gesture) — 스와이프, 핀치 줌, 길게 누르기 같은 터치 동작은 웹의 클릭과는 다른 별도의 API가 필요하다
- 권한 팝업 — 위치 정보, 카메라, 알림 같은 OS 수준 권한 요청 팝업은 앱 화면이 아니라 OS가 그리는 화면이라 다르게 다뤄야 한다
- 실기기 vs 에뮬레이터/시뮬레이터 — 에뮬레이터에서는 통과하는 테스트가 실제 기기에서는 다르게 동작할 수 있다(모듈 7 레슨 3의 환경 패리티 문제가 여기서도 나타난다)
- OS 버전·기기 종류의 다양성 — 웹은 브라우저 몇 종류지만, 모바일은 화면 크기·OS 버전 조합이 훨씬 다양하다(레슨 8에서 크로스 디바이스 전략을 다룬다)
하이브리드 앱은 두 세계를 오간다
하이브리드 앱을 테스트할 때는, 지금 다루는 화면이 네이티브 영역인지 웹뷰(WebView) 영역인지 구분해야 한다 — Appium은 이 전환(Context Switching)을 지원하지만, "지금 어느 영역에 있는지"를 QA가 알고 있어야 올바른 방식으로 요소를 찾을 수 있다.
실무에서 왜 필요한가
"Playwright 할 줄 아니까 모바일도 금방 하겠지"라고 생각하고 Appium을 시작하면, 제스처나 OS 권한 팝업 같은 모바일 특유의 요소에서 당황하기 쉽다. 반대로 로케이터·대기 전략의 원칙이 그대로 이어진다는 것을 알면, 새로운 것을 배운다기보다 이미 아는 원칙을 새로운 플랫폼에 적용하는 감각으로 훨씬 빠르게 적응할 수 있다.
실습 과제
과제 1 — 앱 유형 판단하기 (10분)
다음 세 앱이 네이티브/하이브리드/모바일 웹 중 무엇에 가까울지 어떤 단서로 판단할 수 있을지 적는다.
- 카메라·생체인증 같은 기기 고유 기능을 깊게 활용하는 은행 앱
- 스마트폰과 데스크톱에서 URL만 다르게 접속하는 쇼핑몰
- 특정 화면만 유독 로딩이 느리고 스크롤 방식이 다른 앱 안의 게시판 화면
과제 2 — 웹과 모바일 원칙 대응시키기 (10분)
레슨 3(로케이터)과 레슨 5(대기 전략)에서 배운 원칙이 모바일 자동화에서 각각 어떻게 이어지는지, 한두 문장으로 정리한다.
자가 체크리스트
- 네이티브·하이브리드·모바일 웹 앱의 차이를 설명할 수 있다
- Appium이 웹 자동화 표준을 재사용한다는 것을 설명할 수 있다
- 웹과 다른 모바일 특유의 고려사항(제스처, 권한 팝업, 기기 다양성)을 나열할 수 있다
- 하이브리드 앱에서 네이티브·웹뷰 영역을 구분해야 하는 이유를 설명할 수 있다
흔한 실수
- 모든 앱을 같은 방식으로 테스트하려 한다. 네이티브·하이브리드· 모바일 웹은 테스트 접근 자체가 다르다.
- 에뮬레이터에서 통과했으니 실기기에서도 문제없다고 가정한다. 모듈 7(레슨 3)의 환경 패리티 문제가 모바일에서 특히 두드러진다.
- 웹 자동화 지식이 전혀 도움이 안 된다고 생각하고 처음부터 새로 배우려 한다. 로케이터·대기 전략의 원칙은 그대로 이어진다.
참고 자료
- Appium 공식 문서 — Appium의 공식 아키텍처와 시작 가이드
- W3C WebDriver 표준 — Appium이 재사용하는 웹 자동화 표준 프로토콜