자연어로 쓰는 E2E 테스트, 안드로이드 스튜디오 저니스 1주일 후기

 

지난주에 안드로이드 스튜디오 저니스(Android Studio Journeys)를 처음 열고 '로그인 후 장바구니에 담기'라고 입력했습니다. 잠시 뒤, 에뮬레이터가 혼자 움직이더라구요.

 

처음엔 진짜 놀랐어요. 코드 한 줄 안 쓰고 자연어만 던졌는데 제미나이(Gemini) AI가 앱 화면 구조를 훑고 테스트 단계를 스스로 잡아내거든요. "QA 자동화가 진짜 이걸로 되는 건가?" 하는 기대와 "분명 함정이 있겠지" 하는 의심이 동시에 올라왔습니다. 1주일 써보니, 둘 다 맞았네요.

 

저니스 작동 방식, 자연어가 어떻게 테스트 코드가 되나

저니스는 Android Studio Otter 3 Feature Drop(2025.2.3) 버전을 기준으로 Studio Labs의 실험 기능으로 들어가 있습니다. 설정에서 기능을 켜야 보이고, 프로젝트의 안드로이드 그래들 플러그인(AGP) 버전이 9.0.0 이상이어야 합니다.

 

작동 순서는 이렇습니다. 한국어로 시나리오를 입력하면 Gemini의 비전 및 추론 능력으로 화면을 보고 어느 버튼을 탭하고 어떤 텍스트를 입력해야 할지 판단합니다. 그렇게 추론한 내용을 에뮬레이터에서 실제로 실행해보면서 테스트 단계를 확정하고, 최종적으로 XML 형식의 저니 파일로 저장됩니다. Espresso Test Recorder처럼 Espresso 코드를 뽑아주는 방식이 아니라, 실행 시점에 Gemini가 직접 액션을 수행하는 구조입니다. 생성된 테스트는 Gradle 태스크로 실행돼서 CI/CD 파이프라인에 연결할 수 있는 형태로 나옵니다.

 

개인적으로 마음에 든 부분은 자연어 시나리오 자체가 팀 공통의 기능 명세처럼 쓰인다는 점이에요. 기획자가 직접 시나리오를 쓰고 개발자가 바로 검토하는 흐름이 이론상 가능해지더라구요. "실행 가능한 기획서"라는 표현이 딱 어울리는 그림입니다.

 

 

E2E 테스트 성공률, contentDescription이 결정한다

1주일 써보면서 가장 선명하게 깨달은 게 있습니다. 테스트가 제대로 돌아가느냐 마느냐는 제미나이 성능이 아니라 앱이 접근성 속성을 얼마나 잘 구현했느냐에 달려 있더라구요.

 

contentDescription 없는 버튼, 레이블이 모호한 뷰. 이런 게 하나라도 있으면 AI가 어느 요소를 눌러야 할지 판단을 못 해서 테스트 생성 자체가 실패하는 경우가 생깁니다. 비전 기술만으로는 한계가 있어서, 접근성 속성이 잘 붙은 화면일수록 안정성이 올라갑니다.

 

이게 역설적으로 괜찮은 부수 효과이기도 해요. 저니스 도입을 검토하면서 팀 전체가 접근성 속성 현황을 한 번 훑게 되거든요. 테스트 도구 하나 때문에 접근성 코드 품질이 덩달아 올라가는 셈입니다.

 

 

QA 엔지니어 역할, 사라지는 게 아니라 바뀐다

저니스가 나오면서 "QA 엔지니어 없어도 되는 거 아니야?" 하는 이야기가 나오던데요. 제가 보기엔 방향이 다른 것 같습니다.

 

제미나이는 정상 흐름에 최적화되어 있어요. "로그인 후 상품 담고 결제하기" 같은 주요 시나리오는 잘 잡아냅니다. 근데 재고 부족 상태에서 장바구니 담기를 시도하거나, 결제 도중 네트워크가 끊기는 케이스는 AI가 스스로 설계하지 않더라구요. 예외 케이스를 설계하고 결과를 검증하는 역할은 여전히 사람이 맡아야 합니다.

 

자연어 시나리오가 팀 공통 기능 명세 역할을 하는 만큼, QA의 자리는 "테스트를 직접 작성하는 사람"에서 "테스트 시나리오를 설계하고 관리하는 사람"으로 이동하는 것이라고 봅니다.

 

 

저니스가 막히는 순간, 간헐적 실패와 동적 UI

가장 골치 아팠던 문제는 간헐적 실패였어요. 같은 시나리오를 돌려도 어떨 땐 성공하고 어떨 땐 실패합니다. 원인을 파보면 앱 버그인지 AI 추론이 틀린 건지 바로 구분이 안 되는 경우가 많아서, 디버깅 시간이 생각보다 길어지더라구요.

 

스와이프 후 나타나는 동적 UI, 차트 데이터 검증, 하드웨어 연동 시나리오는 처리하기 어렵습니다. 저도 스크롤 후 나타나는 리스트 아이템을 탭하는 케이스에서 두 번 막혔고, 결국 그 부분은 에스프레소 코드를 수동으로 따로 작성했어요.

 

AI가 실행한 테스트의 결과 리포트를 봐도 "이 테스트가 왜 이 요소를 이렇게 찾는 거지?" 하는 순간이 오면 전부 뜯어봐야 하는데요, 수동으로 작성한 코드보다 의도 파악이 느린 경우가 여러 번 있었습니다.

 

도입 전에 따져봐야 할 비용·보안·구글 종속 문제

저니스는 구글(Google) 제미나이에 전적으로 의존하는 구조입니다. 구글 API 정책이나 가격이 바뀌면 그대로 영향을 받을 수밖에 없어요. Gemini API 키를 별도로 사용하여 연동하는 경우 API 호출 비용이 발생할 수 있어, 대규모 CI 파이프라인에 붙이기 전에 비용 시뮬레이션부터 해두는 게 낫습니다.

 

보안 쪽도 짚어둬야 합니다. 테스트 실행 과정에서 앱 UI 정보가 구글 서버로 전송될 수 있거든요. 금융이나 의료처럼 민감 정보가 화면에 노출되는 앱이라면, 저니스 도입 전에 보안 정책 검토가 먼저 끝나야 합니다.

 

결국 저니스가 제 역할을 하는 구간은 생각보다 좁습니다. 접근성이 잘 구현된 앱에서 주요 흐름 시나리오를 빠르게 커버하고 싶을 때, 딱 그 구간이에요. 팀에 들이기 전에 접근성 속성 점검과 보안 검토부터 마무리해두면 도입 후 뒷탈이 없을 것 같습니다.