테스트가 버튼을 탭해야 할 때, 먼저 버튼을 찾아야 합니다. 이를 수행하는 데는 두 가지 방법이 있습니다. 앱에 엘리먼트 트리(element tree)를 요청하여 그 안에서 버튼을 찾는 방법이 있습니다. 또는 스크린샷을 찍어서 그것을 살펴보는 방법이 있습니다.

몇 년 전까지만 해도 첫 번째 방법만이 작동했습니다.

로케이터 기반(Locator-based) 테스트 자동화가 승리한 이유

Selenium은 2004년에 출시되었습니다. Selenium은 DOM이 곧 페이지인 웹을 위해 구축되었습니다. 즉, 버튼은 하나의 엘리먼트(element)이며, 고유한 id를 가지고 있고, 이를 찾아 클릭하는 방식입니다.

모바일 앱 테스트는 이 모델을 복제했습니다. Appium은 Selenium이 사용하는 것과 동일한 WebDriver 프로토콜 위에서 실행되므로, 모바일 테스트는 웹 테스트와 동일한 방식으로 작성되었습니다. Espresso, XCUITest, Detox 모두 내부적으로는 동일한 작업을 수행합니다. 즉, 트리에서 엘리먼트를 찾은 다음 그 엘리먼트에 동작을 수행하는 것입니다.

이렇게 구축된 데에는 타당한 이유가 있었습니다. 2004년에는 기계가 화면을 볼 수 없었습니다. 컴퓨터 비전(Computer vision)은 템플릿을 매칭하거나 OCR로 텍스트를 읽을 수는 있었지만, "Login"이라고 적힌 둥근 사각형이 탭할 수 있는 버튼이라는 사실은 알려줄 수 없었습니다. 엘리먼트 트리는 소프트웨어가 읽을 수 있는 UI에 대한 유일한 설명이었습니다.

그리고 이 방식은 잘 작동합니다. 트리 조회(tree lookup)는 1밀리초 미만이 소요되며 비용이 들지 않습니다. 매번 동일한 엘리먼트를 반환하거나, 아니면 실패합니다. 추측이 필요 없습니다. 현재 수백만 개의 이러한 테스트가 CI(지속적 통합)에서 실행되며 실제 버그를 잡아내고 있습니다. 만약 당신의 트리가 안정적이라면, 이것이 올바른 도구이며 변경할 이유가 없습니다.

로케이터가 깨지는 이유

로케이터는 불안정합니다 (Flaky)

로케이터는 앱 구조 내의 위치를 통해 엘리먼트를 식별합니다. Android의 경우 리소스 ID(resource id), iOS의 경우 접근성 식별자(accessibility identifier)가 그 예입니다. 테스트는 해당 식별자로 엘리먼트를 찾아 동작을 수행합니다. 이러한 식별자들은 앱의 코드 안에 존재하므로, 코드가 변경되면(리팩토링으로 인한 id 이름 변경, 뷰(view)의 이동 등) 앱이 정상적으로 작동하더라도 로케이터가 일치하지 않게 되어 테스트가 실패합니다. iOS와 Android는 서로 다른 구조를 노출하므로, 동일한 흐름이라도 각 플랫폼마다 별도의 로케이터 세트가 필요합니다.

모달(Modals) 또한 런타임(runtime) 중에 구조를 변경합니다. 권한 대화 상자, ATT(App Tracking Transparency) 프롬프트, 또는 리뷰 요청 팝업이 현재 화면 위에 나타나면, 테스트가 찾고 있는 요소가 해당 실행 시점에는 존재하지 않게 됩니다. 이러한 요소들은 조건부로 나타나기 때문에, 동일한 테스트가 한 번은 통과하고 다음번에는 실패할 수 있습니다. 코딩 에이전트(Coding agents)가 이제 실패한 로케이터(locator)를 자동으로 다시 작성할 수 있게 되어 수정 속도는 빨라졌지만, 실패가 발생하는 빈도 자체를 바꾸지는 못합니다.

트리(tree)가 없는 일부 화면들

모바일에서 트리(tree)는 UI 그 자체였던 적이 없습니다. 그것은 접근성 도구(accessibility tools)를 위해 화면과 함께 생성된 화면에 대한 설명입니다. 보통은 존재하지만, 때로는 존재하지 않습니다.

Unity 또는 Unreal 게임은 버튼처럼 보이는 텍스트(texture)를 그리지만, 그 뒤에는 조회할 수 있는 요소(element)가 없습니다. 캔버스(Canvas) UI도 마찬가지입니다. 그리고 앱 외부의 모든 것은 애초에 여러분의 트리에 포함되지 않았습니다: 결제 시트(payment sheet), OAuth 페이지, 시스템 키보드 등이 그렇습니다. 로그인 및 결제 흐름은 이러한 요소들을 직접 통과하며 실행됩니다. 쿼리(query)할 수 있는 것이 아무것도 없으므로, 로케이터 기반(locator-based) 도구는 이러한 화면에서 전혀 작동할 수 없습니다.

비전 기반(vision-based) 모바일 테스트의 작동 방식

LLM(대규모 언어 모델)은 기계가 읽을 수 있는 영역을 변화시켰습니다. 이제 LLM은 스크린샷을 보고 다음과 같이 말할 수 있습니다: "이것은 로그인 양식이고, 저것은 기본 버튼이며, 저것은 OS가 카메라 권한을 요청하는 것입니다." 완벽하지는 않지만, 동작을 수행하기에는 충분할 만큼 뛰어납니다.

따라서 비전 기반 테스트는 루프(loop)를 실행합니다: 스크린샷을 찍고, 다음 동작을 결정하고, 탭(tap)하거나 타이핑(type)한 뒤, 어떤 일이 일어났는지 확인하기 위해 다시 스크린샷을 찍습니다.

이를 통해 위의 문제 중 여러 가지를 한 번에 해결할 수 있습니다:

• 추가할 ID가 없음. 어떤 빌드(build)든 있는 그대로 테스트 가능합니다. 개발자가 화면을 테스트 가능하게 만들기 위해 먼저 작업할 필요가 없습니다.
• 두 플랫폼 모두에 하나의 테스트 적용. iOS와 Android 스크린샷 모두 로그인 버튼을 보여줍니다.
• 처리해야 할 팝업 없음. 화면 위의 대화 상자는 단지 다음 스크린샷에 나타나는 내용일 뿐입니다.
• 평이한 언어로 작성된 테스트 케이스. "저장된 계정으로 로그인하고 주문(Orders) 탭을 여세요." 코드가 없으므로, 수동 QA(manual QA)가 프로그래머 없이도 테스트 케이스를 작성할 수 있습니다.

수동(Manual) vs 로케이터 기반(locator-based) vs 비전 기반(vision-based)

이제 모바일 앱 테스트에는 두 가지가 아닌 세 가지 옵션이 있습니다.

수동 (Manual): 작성 비용은 저렴하지만 실행 비용이 비쌉니다. 체크리스트를 작성하는 데는 1분이면 충분하지만, 실행할 때마다 사람의 시간이 소요됩니다. 이는 확장성(Scale)이 없습니다. 20개의 흐름(Flow)을 테스트하려면 20배의 시간이 들기 때문에, 팀은 모든 흐름을 테스트하는 대신 가장 걱정되는 몇 가지 흐름만을 테스트하게 됩니다.

로케이터 기반 (Locator-based): 현재는 양쪽 모두 비용이 저렴합니다. 과거에는 유지보수(Maintenance)가 일종의 세금처럼 따랐으나, 로케이터를 다시 작성하는 에이전트(Agents)들이 이를 줄여주었습니다. 하지만 이는 안정적인 엘리먼트 트리(Element tree)가 있는 곳에서만 작동합니다. 트리가 없으면 테스트도 없습니다.

비전 기반 (Vision-based): 이 또한 양쪽 모두 비용이 저렴하며, 트리가 필요하지 않습니다. 따라서 로케이터가 도달할 수 없는 영역, 즉 게임, 캔버스(Canvas), OS 대화 상자, 그리고 두 플랫폼 모두에서 작동하는 단일 흐름에 접근할 수 있습니다. 로케이터보다 재현성(Repeatability)은 떨어지지만, 로케이터 스위트(Locator suite)를 대체하는 것이 아니라 수동 테스트 단계를 대체합니다.

모바일 테스트 접근 방식 선택하기

두 가지 자동화 접근 방식은 상호 보완적입니다. 이제 비용이 두 방식을 가르는 기준이 아니라, 커버리지(Coverage)가 기준이 됩니다. 엘리먼트 트리가 안정적인 곳에는 로케이터를 사용하고, 트리가 불안정하거나 대안이 수동 테스트뿐인 곳에는 비전을 사용하십시오.

테스트가 화면을 읽을 수 있게 되면, 이전에는 수동으로만 확인할 수 있었던 것들이 자동화 가능해집니다. 레벨 플레이하기, 사진 편집하기, 지도에서 핀 따라가기, 또는 이메일 코드, 결제창(Paywall), 권한 팝업을 거치는 엔드 투 엔드(End-to-end) 회원가입 실행 등이 그 예입니다. 과거에는 이 각각의 과정마다 릴리스 전 인력이 필요했지만, 이제는 각각이 사람의 개입 없이 실행되는 하나의 문장(Sentence)이 되었습니다.

남은 의문은 표의 마지막 행인 재현성(Reproducibility)입니다. 로케이터 조회(Lookup)는 동일한 엘리먼트를 반환하거나 실패합니다. 반면 LLM은 판단(Judgement calls)을 내리며, 다음 실행 시 다른 경로를 통해 동일한 목표에 도달할 수 있습니다. 이것이 얼마나 중요한지, 그리고 비전을 유용하게 만드는 유연성을 잃지 않으면서 어떻게 이를 제약할 수 있는지는 그 자체로 하나의 주제입니다. 이는 별도의 포스트에서 다루겠습니다.