Automation Test

앱 분석에서 BDD 시나리오까지, AI가 6단계로 정리하는 법

qa2qa 2026. 4. 9. 17:28

들어가며

2편이 "테스트해봤더니 됐다"는 결과 위주의 글이었다면, 이번 글은 한 단계 앞으로 간다.

AI는 처음 보는 앱을 받았을 때, 무엇을 어떻게 분석하고, 그걸로 어떻게 테스트 시나리오를 만들까?


QA가 처음 보는 앱을 받았을 때

QA가 회사에 입사해서 처음 앱을 받았다고 생각해보자.
PM이 "이거 테스트해주세요" 한 마디 던지면, 사람은 보통 이렇게 한다.

  1. 앱을 켠다
  2. 주요 화면을 한 번씩 둘러본다
  3. "아 이런 앱이구나" 감을 잡는다
  4. 그 다음에야 테스트 케이스를 쓰기 시작한다

문제는 3번까지가 보통 하루~며칠씩 걸린다는 것이다.
화면이 많을수록, 기능이 많을수록 시간이 더 든다.

MQA의 첫 단계는 이 과정을 AI가 대신하게 만드는 것이다.
파파고는 화면 수가 적은 단순한 앱이지만, 단순할수록 분석 단계가 더 명확하게 드러난다.


1단계: 메인 화면 탐색

파파고를 켜자마자 AI가 가장 먼저 하는 건 스크린샷 + 화면 element 추출이다.

홈 화면 한 장에서 AI가 뽑아낸 정보:

  • 상단: 햄버거 메뉴, papago 로고, edu 아이콘
  • 언어 선택: 한국어 ⇄ 영어 (가운데 swap 버튼)
  • 입력창: "번역할 내용을 입력하세요"
  • 광고 배너 1개 (동적 콘텐츠)
  • 5개 진입 모드: 음성 / 대화 / 이미지 / 문서 / 학습카메라

하나의 화면에 모든 것이 모여있는 단일 화면 구조다.
이 구조 자체가 "이 앱은 무엇을 하는 앱인지" 알려준다 — 입력하면 결과가 나오는 도구다.


2단계: 부가 메뉴 둘러보기

햄버거 메뉴를 탭해서 사이드 메뉴를 연다.

 

 

메뉴 구조에서 추가로 알 수 있는 것:

  • 로그인 유도 (현재는 비로그인 상태)
  • 즐겨찾기 / 번역 기록 (사용자 데이터 영역)
  • papago+ (유료 비즈니스용 진입점)
  • Edu / 용어집 / 웹사이트 번역 / 오프라인 번역 / 글로벌 회화 / 낱말카드 / 설정 / Papago Mini

기능이 많아 보이지만 핵심은 명확하다. "입력 → 번역"이 본체이고, 나머지는 다 부가 기능이다.
이 판단이 다음 단계의 우선순위를 결정한다.


3단계: 5개 모드 진입 — 그리고 발견된 패턴

홈에 있는 5개 모드 중 텍스트 입력은 권한이 필요 없다. 나머지는?
AI는 하나씩 탭해보면서 무슨 일이 벌어지는지 본다.

음성 모드

탭하자마자 시스템 다이얼로그가 뜬다. "Papago에서 오디오를 녹음하도록 허용하시겠습니까?"

 

대화 모드

이번엔 시스템 다이얼로그가 아니라 앱 자체 다이얼로그가 뜬다. "해당 기능을 사용하려면 권한이 필요합니다."
같은 마이크 권한인데 음성 모드와 동작이 다르다. 흥미로운 발견.

 

이미지 모드

카메라 권한 요청 다이얼로그. "Papago에서 사진을 촬영하고 동영상을 녹화하도록 허용하시겠습니까?"

여기서 패턴이 보인다.

 

 

5개 입력 모드 중 4개가 첫 진입 시 권한 게이트를 가진다.
그리고 같은 권한이라도 화면마다 다이얼로그 종류가 다르다.

이건 분석 단계에서 발견하지 않으면, 나중에 BDD 시나리오를 짰을 때 "왜 자동화가 첫 진입에서 항상 막히지?"의 원인이 된다.


4단계: 앱 프로파일 자동 생성

탐색이 끝나면 AI는 전체를 한 문서로 요약한다. 실제 생성된 결과:

# App Profile: Papago

## App Category
Translation utility (single-screen app)

## Core Value
한국어 ⇄ 다국어 즉시 번역 — 텍스트, 음성, 이미지, 문서까지
멀티모달 입력 지원

## Core Flow
홈 → 입력창 탭 → 텍스트 입력 → 번역 결과 즉시 표시

## Complexity
Low (1 핵심 화면 + 5개 입력 모드 + 사이드 메뉴)

## Test Priority Areas
1. 텍스트 번역 (핵심) — 권한 게이트 없는 유일한 즉시 사용 가능 플로우
2. 언어 swap (한↔영, 한↔일, ...)
3. 입력창 UX (placeholder, 멀티라인, 지우기)
4. 권한 요청 처리 (음성/대화/이미지)
5. 번역 기록 / 즐겨찾기
6. 사이드 메뉴 진입

## Known Constraints (자동화 관점)
- 한글 입력: adb input text는 ASCII 전용. ADB broadcast는 ADBKeyboard 미설치 시 동작 안 함.
- 권한 다이얼로그: 5개 모드 중 4개가 첫 진입 시 권한 게이트.
- 광고 배너: 동적 콘텐츠로 화면 일부가 가변적.

카테고리 → 핵심 가치 → 핵심 플로우 → 복잡도 → 테스트 우선순위 → 제약사항.
이 여섯 줄이 다음 단계 (시나리오 생성)의 입력이 된다.


5단계: 화면 맵 자동 생성

화면 간 이동 가능 경로를 그래프로 정리한다.

home ──→ side-menu (햄버거 탭)
home ──→ text-input (입력창 탭)
home ──→ voice-mode ──→ [permission: mic]
home ──→ conversation-mode ──→ [permission: mic]
home ──→ image-mode ──→ [permission: camera]
home ──→ document-mode ──→ [permission: file]
home ──→ camera-learn ──→ [permission: camera]
home ──→ language-picker (한국어/영어 dropdown)
home ──→ home (swap 버튼: source ↔ target)

text-input ──→ translation-result (텍스트 입력 즉시)
text-input ──→ home (X 버튼)

side-menu ──→ login / favorites / history / papago-plus / ...

이게 왜 중요한가? "홈에서 번역 결과까지 가는 경로"가 명확해지기 때문이다.
파파고의 critical path는 단 두 단계: home → text-input → translation-result.
권한 요청이 없는 유일한 핵심 플로우다. 이 정보가 시나리오 생성 단계에서 우선순위를 결정한다.


6단계: BDD 시나리오 자동 생성

여기가 핵심이다. 위에서 만든 프로파일과 화면 맵을 입력으로, AI가 BDD 시나리오를 생성한다.

가장 우선순위가 높은 텍스트 번역 시나리오:

@core @smoke
Feature: 텍스트 번역
  사용자로서 입력한 텍스트가 즉시 다른 언어로 번역되기를 원한다.
  이 앱의 핵심 가치이며, 권한 게이트가 없는 유일한 즉시 사용 플로우다.

  Background:
    Given 파파고 앱이 실행되어 있다
    And "홈" 화면이 표시되어 있다

  @happy-path
  Scenario: 영어 텍스트를 한국어로 번역
    Given source 언어가 "영어"이고 target 언어가 "한국어"이다
    When 사용자가 "번역할 내용을 입력하세요" 입력창을 탭한다
    And 사용자가 "Hello world"를 입력한다
    Then 번역 결과 영역에 한국어 번역이 1초 이내 표시된다
    And 결과 텍스트는 빈 문자열이 아니다

  @language-swap
  Scenario: 언어 swap 후 번역
    Given source 언어가 "한국어"이고 target 언어가 "영어"이다
    When 사용자가 swap 버튼을 탭한다
    Then source 언어가 "영어"로 바뀐다
    And target 언어가 "한국어"로 바뀐다

그리고 분석 단계에서 발견한 권한 게이트 패턴을 별도 feature로 분리:

@permission @edge
Feature: 권한 게이트
  음성, 대화, 이미지 모드는 디바이스 권한이 필요하다.
  권한이 없는 상태에서 진입했을 때의 UX를 검증한다.

  Scenario: 음성 모드 진입 시 시스템 권한 요청
    When 사용자가 "음성" 버튼을 탭한다
    Then 시스템 권한 다이얼로그가 표시된다
    And 다이얼로그에 "Papago에서 오디오를 녹음하도록 허용하시겠습니까?"가 보인다

  Scenario: 대화 모드 진입 시 앱 자체 다이얼로그
    When 사용자가 "대화" 버튼을 탭한다
    Then 앱 자체 다이얼로그가 표시된다
    And 다이얼로그에 "해당 기능을 사용하려면 권한이 필요합니다"가 보인다

여기서 주목할 점은, 3단계에서 발견한 "같은 마이크 권한이지만 음성과 대화의 다이얼로그가 다르다"는 패턴이 시나리오에 그대로 반영됐다는 것이다.
이건 사람이 BDD를 짤 때도 놓치기 쉬운 부분이다. 사람은 보통 "마이크 권한 요청" 한 줄로 묶고 끝낸다. 하지만 실제 동작이 다르다면 별도 시나리오로 분리되어야 한다.


왜 이게 중요한가

이 단계의 결과물이 다음 단계의 입력이 된다.

앱 분석 → 프로파일/화면맵 → BDD 시나리오 → 자동 테스트 실행

각 단계는 이전 단계 없이는 부정확해진다.

  • 화면 탐색 없이 BDD를 짜면 → 존재하지 않는 화면이나 요소를 가리키는 시나리오가 나온다
  • 프로파일 없이 BDD를 짜면 → 핵심 플로우가 아닌 사이드 기능에 우선순위가 잘못 매겨진다
  • 권한 게이트 발견 없이 BDD를 짜면 → 첫 진입에서 항상 막히는 시나리오를 양산한다

사람도 마찬가지다. 앱을 모르고 테스트 케이스를 쓰면, 진짜 중요한 플로우는 빠지고 사이드 메뉴만 검증하는 일이 생긴다.

그래서 첫 단계가 분석이다.
"무엇을 테스트할지" 정하기 전에, "이 앱이 무엇인지" 먼저 알아야 한다.


자동화의 한계도 있다

솔직히 이 단계가 완벽하진 않다.

  • 숨겨진 화면은 못 찾는다: 특정 조건에서만 나타나는 화면(에러 케이스, 권한 거부 후 화면, 네트워크 오프라인 등)은 단순 탐색으로는 안 걸린다.
  • 비즈니스 로직은 모른다: 화면 구조는 파악해도 "왜 이 기능이 있는지", "어떤 사용자가 쓰는지"는 사람이 보충해야 한다.
  • 다이나믹 콘텐츠 의존: 광고 배너가 매번 바뀌면, AI가 광고를 핵심 요소로 잘못 분류할 수 있다.
  • 권한 상태 의존: 분석을 권한이 없는 상태에서 했기 때문에, 권한 부여 후의 화면(예: 실제 음성 인식 화면)은 못 본 상태다.

그래서 분석 단계 후에 사람이 한 번 검토하고 보완하는 단계를 둔다.
완전 자동은 아니지만, 사람이 처음부터 다 하는 것보다는 훨씬 빠르다.