모바일 앱 QA 자동화 하네스 만들기

"AI한테 앱 테스트를 시키면 어떨까?"

모바일 앱 QA를 할 때마다 반복되는 과정이 있다.
디바이스 연결하고, 화면 하나씩 눌러보고, 스크린샷 찍고, 버그 리포트 쓰고.
사람이 많으면 테스트 커버리지야 올라가지만, 혼자 하는 QA라면 한계가 명확하다.

 

Claude Code의 플러그인(하네스) 시스템을 활용해서, 자연어 한 마디로 모바일 앱을 자동 테스트하는 MQA(Mobile QA) Harness를 만들고 있다. 아직 개발 중이고 다듬어야 할 부분이 많지만, 어떤 앱이든 동일한 방식으로 테스트할 수 있는 범용 QA 프레임워크를 목표로 하고 있다. 이 글에서는 현재까지의 방향과 경험을 정리한다.

---

목표: 어떤 앱이든 테스트할 수 있는 범용 하네스

MQA를 만들면서 가장 중요하게 생각하는 건 범용성이다. 특정 앱에 맞춰진 테스트 도구가 아니라, 어떤 모바일 앱이든 연결만 하면 동작하는 프레임워크를 지향한다.

• 한국어 앱이든 영어 앱이든 일본어 앱이든 동작해야 한다
• 커머스 앱이든 소셜 앱이든 금융 앱이든 테스트 흐름이 같아야 한다
• 앱별 커스터마이징은 설정 파일 하나로 끝나야 한다

아직 이 목표를 100% 달성한 건 아니다. 하지만 구조 자체를 범용으로 설계해놓으면, 앱이 바뀌어도 하네스는 그대로 쓸 수 있다.

---

어떻게 동작하는가

MQA Harness는 Claude Code 위에서 동작하는 AI 기반 모바일 앱 QA 자동화 프레임워크다.

사용자: "이 앱 테스트해줘"
  ↓
MQA: 앱 분석 → 페르소나 생성 → 자율 탐색 → 버그 리포트

 

자연어 한 마디로 시작하면, AI가 앱을 분석하고 → 다양한 사용자 유형(페르소나)을 생성하고 → 각 페르소나의 관점에서 앱을 탐색하고 → 발견한 문제를 리포트로 정리한다.

---

듀얼 엔진

테스트 목적에 따라 두 가지 실행 엔진을 사용한다.

엔진	용도	속도
Appium	탐색적 테스트 (AI가 자유롭게 판단)	느림 (액션당 5~8초)
Maestro	시나리오 테스트 (정해진 흐름 실행)	빠름 (액션당 1~2초)

 

 처음에는 Appium 하나로 다 하려고 했다. 하지만 정해진 시나리오를 Appium으로 돌리면 매번 스크린샷을 찍고 AI한테 물어보니까 시나리오 하나에 몇 분씩 걸렸다. Maestro를 추가하니 같은 시나리오가 수십 초 만에 끝났다.

반대로, Maestro만으로는 "AI가 자유롭게 앱을 탐색하면서 문제를 발견하는" 탐색적 테스트가 불가능했다. 결국 둘 다 필요하다는 결론.

 

뭘 테스트할지 모를 때 → AI가 자유롭게 탐색 (느리지만 유연)
뭘 테스트할지 알 때   → 정해진 시나리오 빠르게 실행

---

두 가지 테스트 트랙

1. QA 테스트 (BDD 기반)

요구사항이 스펙대로 동작하는지 검증한다. BDD(Gherkin) feature 파일을 작성하면, AI가 이를 실행 가능한 형태로 변환해서 자동으로 돌린다.

2. 유저 테스트

실제 사용자 관점에서 앱을 자유롭게 탐색한다. AI가 앱의 특성에 맞는 페르소나를 생성하고, 각 페르소나의 관점에서 앱을 써보면서 해당 사용자 유형이 겪을 수 있는 문제를 발견한다.

---

삽질 기록: 만들면서 부딪힌 것들

BDD 텍스트 ≠ 실제 UI 텍스트

BDD에 "프로필 수정"이라고 썼는데, 실제 앱에는 "프로필 편집"이라고 되어 있었다. 이런 불일치가 생각보다 자주 발생한다. 자동으로 복구하는 로직을 넣고 있는데, 아직 정확도를 더 올려야 한다.

실패하면 처음부터?

기존 테스트 자동화는 중간에 실패하면 처음부터 다시 돈다. 앱 상태는 디바이스에 그대로 있는데도. 이게 너무 비효율적이라 실패 지점부터 이어서 실행하는 방식을 만들었다. 처음부터 안 돌리니까 빠르고, 앱 상태도 안 날아간다.

예상 못한 팝업

앱을 실행하면 업데이트 팝업, 권한 요청, 공지사항 등 예상치 못한 팝업이 수시로 뜬다. 이걸 자동으로 닫는 로직이 없으면 테스트가 바로 멈춘다. 다국어 팝업 패턴을 미리 정의해두고 자동 dismiss하도록 했다.

---

설계 원칙

다듬어야 할 부분이 많지만, 설계 방향은 초기부터 잡아두었다:

1. Observe before Acting — 앱을 먼저 분석한 뒤에 테스트한다.
2. Propose before Proceed — 단계 전환 시 사용자 확인을 받는다.
3. No Destructive Actions — 앱 삭제, 데이터 초기화 같은 파괴적 행위는 하지 않는다.
4. Evidence-Based Findings — 모든 버그 리포트에 스크린샷 증거가 포함된다.
5. Crash is Not Failure — 크래시는 발견이다. 캡처하고, 복구하고, 계속 진행한다.

---

기술 스택

• AI: Claude Code
• 모바일 자동화: Appium + Maestro
• 테스트 명세: Gherkin (BDD)
• 리포트: HTML

---

현재 장점과 단점

장점

• 자연어 한 마디로 시작: 복잡한 설정 스크립트 없이 "테스트해줘"로 전체 플로우가 돌아간다.
• 페르소나 기반 탐색: 사람이 직접 "어르신 입장에서 써봐야지" 하고 테스트하는 걸 AI가 대신한다.
• 듀얼 엔진: 탐색은 자유롭게, 시나리오는 빠르게. 용도에 맞는 도구를 쓸 수 있다.
• 이어서 실행: 실패해도 처음부터 다시 안 돌린다.
• 범용 설계: 앱이 바뀌어도 설정만 수정하면 같은 하네스를 쓸 수 있다.

단점

• Self-Healing 정확도: 아직 사람이 개입해야 하는 경우가 있다.
• Appium 속도: 매번 AI한테 물어보는 구조의 본질적 한계.
• iOS 지원 미흡: 현재 Android 중심.
• 다국어 실전 검증 부족: 구조는 만들었지만 충분히 검증하지 못했다.

---

앞으로의 계획

가장 기대하는 건 기존 자동화 테스트 자산과의 연동이다. 많은 팀이 이미 자동화 테스트 코드나 YAML 시나리오를 가지고 있다. 이런 기존 자산을 MQA에 연결하면, AI가 처음부터 다 만들 필요 없이 기존 코드를 실행하고 결과를 분석하는 역할에 집중할 수 있다. 속도도 훨씬 빨라질 거라고 예상한다.

그 외에 풀어야 할 과제들:

• AI 호출 횟수를 줄여서 속도 최적화
• 실패 패턴 학습으로 Self-Healing 고도화
• iOS 실기기 지원
• 다양한 카테고리 앱에서 범용성 실전 검증

---

마치며

MQA Harness는 아직 개발 중이고, 솔직히 다듬어야 할 부분이 많다.

하지만 만들면서 부딪히는 문제들 — Maestro가 한글을 못 친다든가, 스크린샷 분석이 엉뚱한 텍스트를 찾는다든가, Appium이 너무 느리다든가 — 이런 삽질의 과정 자체가 꽤 재밌다.

앞으로 이 하네스를 다듬어가는 과정을 시리즈로 연재할 예정이다. 범용 QA 하네스가 정말로 "어떤 앱이든 테스트해줘"가 가능해지는 날까지, 고군분투 기록을 남겨보려 한다.

모바일 QA 자동화에 관심 있거나, 비슷한 삽질을 하고 계신 분들이 있다면 편하게 의견 나눠주세요.