Expo Maestro 테스트 개선: 모바일 E2E는 이제 “실패 화면”이 아니라 운영 지표다

모바일 E2E 테스트는 늘 “해야 하는데 미루는 일”이었다. 로컬에서는 통과했는데 CI 디바이스에서는 실패하고, 실패 로그는 길고, 스크린샷은 원인을 설명하지 못하고, 재실행 버튼은 전체 파이프라인 시간을 다시 태운다. Expo가 2026년 6월 24일 공개한 Maestro testing improvements는 이 문제를 단순히 “테스트 러너가 좋아졌다”로 볼 소식이 아니다. Expo/React Native 팀이 E2E를 릴리즈 게이트가 아니라 운영 지표로 다룰 수 있게 만드는 변화다.

이번 변경의 핵심은 세 가지다. 첫째, EAS Insights에서 Maestro 테스트 실행을 대시보드와 추세로 볼 수 있다. 둘째, 실패 원인을 특정 단계와 flaky 테스트까지 좁혀 볼 수 있다. 셋째, 실패한 테스트만 다시 실행하고 JUnit 리포트를 받을 수 있어 기존 CI 품질 게이트와 연결하기 쉬워졌다. 작은 팀에게 중요한 것은 “더 많은 테스트를 쓰자”가 아니라 “실패했을 때 어디를 고치고, 언제 릴리즈를 멈추고, 무엇을 다시 실행할지”를 정할 수 있게 됐다는 점이다.

무슨 일이 있었나

Expo의 공식 변경로그에 따르면 EAS는 Maestro 테스트를 위한 새 대시보드, 실행 추세, flaky 테스트 식별, 실패 단계 분석, 실패한 테스트만 다시 실행하는 기능, JUnit XML 출력 형식을 추가했다. EAS Workflows는 `.eas/workflows` 아래 YAML 파일로 빌드와 테스트 작업을 정의하고, E2E 예제 문서는 Expo 앱에서 Maestro 플로우를 실행하는 구성을 안내한다.

EAS Insights의 Maestro 문서는 테스트 상태를 passed, failed, retried, flaky, stopped, queued, canceled로 분류하고, 테스트 실행 횟수, 통과/실패/재시도/불안정 비율, 전체 테스트 시간, P90 실행 시간을 볼 수 있다고 설명한다. 이 지표들은 단일 실패 화면보다 팀 운영에 더 유용하다. “오늘 실패했다”가 아니라 “최근 어떤 플로우가 계속 느려지고 실패율이 올라가는가”를 볼 수 있기 때문이다.

Maestro 자체는 React Native 지원을 공식 문서로 안내하고 있으며, Expo는 이 러너를 EAS Workflows와 Insights의 일부로 묶고 있다. 즉 개발자는 별도 대시보드를 조립하지 않아도 모바일 빌드, 테스트 실행, 결과 분석을 한 운영 흐름 안에서 다룰 수 있다.

왜 중요한가

웹 E2E와 달리 모바일 E2E는 실패 비용이 높다. 시뮬레이터/에뮬레이터 상태, 네이티브 빌드 시간, 권한 팝업, 네트워크 지연, 테스트 디바이스 선택이 모두 실패 원인이 될 수 있다. 실패가 한 번 날 때마다 팀은 “제품 버그인가, 테스트 버그인가, 기기 상태인가”를 구분해야 한다. 그 구분이 느리면 테스트는 릴리즈 안전망이 아니라 배포 지연 요인이 된다.

이번 개선은 그 구분 비용을 낮춘다. 실패 단계 분석은 어느 화면 전환이나 액션에서 깨졌는지 찾는 시간을 줄이고, flaky 식별은 안정성 없는 테스트를 제품 품질 신호와 분리하게 해준다. 실패한 테스트만 재실행하는 기능은 전체 E2E 묶음을 다시 돌리는 낭비를 줄인다. JUnit 출력은 GitHub Actions, GitLab CI, Jenkins, 내부 리포팅처럼 이미 JUnit을 읽는 시스템과 연결할 수 있는 표준 접점을 제공한다.

실무 관점에서는 “테스트 자동화 도입”보다 “테스트 운영 모델”이 더 중요해진다. 어떤 플로우를 릴리즈 차단 조건으로 둘지, flaky 테스트가 몇 번 반복되면 소유자를 지정할지, P90 실행 시간이 어느 선을 넘으면 테스트를 나눌지 같은 규칙이 필요하다.

커뮤니티 신호

React Native와 Expo 커뮤니티에서는 E2E 도구 선택, 비용, 디바이스 지정, CI 재현성에 대한 질문이 반복된다. 이런 글들은 Expo 기능 사실의 근거가 아니라, 개발자들이 실제로 어디서 막히는지 보여주는 신호다. 특히 “어떤 E2E 도구를 써야 하느냐”보다 “CI에서 같은 디바이스와 같은 조건으로 재현할 수 있느냐”가 반복되는 고민이다.

이 신호를 반영하면 이번 Expo 변경의 가치는 명확하다. 도구 하나를 더 추가한 것이 아니라, 모바일 E2E 실패를 팀이 회고하고 개선할 수 있는 관측 가능한 데이터로 바꿨다.

개발·운영 영향

Expo/React Native 팀은 이제 테스트 피라미드의 상단을 조금 더 실용적으로 운영할 수 있다. 모든 화면을 E2E로 덮겠다는 목표보다 온보딩, 로그인, 결제, 푸시 권한, 핵심 작성/저장 플로우처럼 릴리즈 리스크가 큰 경로를 먼저 고르는 편이 낫다.

CI 운영자는 실패한 테스트만 재실행하는 정책을 명확히 해야 한다. 재실행은 비용을 줄이지만, 무제한 재시도는 flaky 테스트를 숨긴다. 따라서 “최대 1회 재시도 후 실패”, “flaky로 분류되면 릴리즈 차단 대신 소유자 알림”, “같은 플로우가 3일 연속 flaky면 차단”처럼 팀에 맞는 기준을 정해야 한다.

품질 담당자와 릴리즈 매니저에게는 JUnit 출력이 중요하다. 기존 리포트와 결합하면 모바일 E2E를 별도 대시보드가 아니라 전체 릴리즈 품질 지표 안에 넣을 수 있다. 웹, API, 모바일 테스트를 같은 릴리즈 체크리스트에서 비교할 수 있게 되는 것이다.

주의할 점

첫 번째 위험은 “대시보드가 생겼으니 품질이 좋아질 것”이라는 착각이다. 대시보드는 문제를 보여줄 뿐 테스트 전략을 대신 세워주지 않는다. 지나치게 많은 E2E 테스트는 여전히 느리고 비싸며, 작은 UI 변경에도 깨질 수 있다.

두 번째 위험은 flaky를 정상화하는 것이다. 재시도 기능은 릴리즈 속도를 지키기 위한 완충 장치이지 실패를 무시하는 장치가 아니다. 같은 테스트가 반복해서 flaky로 잡히면 제품 코드, 테스트 selector, 기기 상태, 네트워크 의존성 중 하나를 반드시 줄여야 한다.

세 번째 위험은 Expo/EAS에 너무 많은 운영 지식을 묶는 것이다. 팀이 다른 CI나 네이티브 빌드 시스템으로 이동할 가능성이 있다면 JUnit, YAML, Maestro flow 파일처럼 이식 가능한 경계를 유지해야 한다.

결론

이번 Expo Maestro 개선은 모바일 E2E를 “마지막에 한 번 돌려보는 자동화”에서 “릴리즈 운영 지표”로 끌어올리는 변화다. 좋은 테스트는 실패하지 않는 테스트가 아니라, 실패했을 때 팀이 다음 행동을 빠르게 결정하게 해주는 테스트다.

Expo 앱을 운영한다면 오늘 당장 모든 플로우를 자동화할 필요는 없다. 대신 가장 비싼 장애를 일으키는 5개 사용자 경로를 고르고, EAS Workflows와 Maestro Insights로 실패 단계, flaky 비율, 재실행 정책을 연결하는 것부터 시작하는 편이 현실적이다.

출처

• Expo Changelog: Maestro testing improvements
• Expo Docs: Maestro tests with EAS Insights
• Expo Docs: End-to-end tests in EAS Workflows
• Expo Docs: EAS Workflows syntax
• Maestro Docs: React Native support
• Community signal: E2E testing tools for Expo apps
• Community signal: selecting a device for EAS Maestro tests