모바일 테스트 심화 — 스토어 심사·권한과 프라이버시·딥링크와 푸시·디바이스 팜·Appium

학습 목표

이 모듈 한 줄 요약 — "앱 안쪽은 다 되는데 출시가 막힐 때". 기능은 전부 동작하는데 스토어 심사에서 반려되고, 권한 안내가 규정에 안 맞고, 링크를 눌러도 앱이 안 열린다. 앱 바깥쪽에서 벌어지는 이 문제들이 실제 출시를 가장 자주 막는다.

모듈 17에서 앱 생명주기와 인터럽트, 플랫폼별 관습, 실기기와 에뮬레이터 선택을 다뤘다. 모듈 13에서는 Appium으로 네이티브 앱을 자동화하는 기초를 배웠다. 그런데 실제로 앱을 출시해 본 팀이 가장 많이 깨지는 지점은 그 둘 어디에도 없다. 앱 안쪽 기능은 다 되는데 스토어 심사에서 반려되고, 권한 팝업에서 사용자가 이탈하고, 마케팅이 뿌린 딥링크가 브라우저로 열리고, 푸시가 특정 기종에서만 안 오는 것 이다. 이 모듈은 그 경계선을 다룬다.

경계선의 공통점은 우리가 만들지 않은 코드가 판단을 내린다 는 것이다. 심사 담당자와 자동 검사기, OS의 권한 매니저, 도메인 검증 서버, 배터리 최적화 정책, 접근성 서비스가 각각 자기 규칙으로 우리 앱을 평가한다. 그래서 이 영역의 테스트는 "기능이 동작하는가"가 아니라 "플랫폼이 정한 계약을 우리가 지키고 있는가" 를 확인하는 일에 가깝다. 계약의 원문은 App Store 심사 지침, Google Play 정책 센터, 원스토어 상품 검증 가이드라인, Android/iOS 개발자 문서에 있고, QA가 그 원문을 읽고 체크리스트로 옮길 수 있어야 한다.

여섯 레슨은 출시 파이프라인 순서를 따라간다. 먼저 스토어 심사 에서 어떤 사유로 반려되고 어떻게 재심사를 받는지, 다음으로 권한과 프라이버시 선언 이 실제 앱 동작과 일치하는지 대조하는 법, 딥링크·푸시·백그라운드 작업 처럼 OS가 중간에 끼어드는 기능을 검증하는 법, 한정된 예산으로 디바이스 팜 매트릭스 를 설계하는 법, 그리고 Appium 심화 와 모바일 접근성 실무로 마무리한다.

정책 문서는 계속 바뀐다. 이 모듈이 가르치려는 것은 특정 조항 번호를 외우는 일이 아니라, 어떤 문서가 정본인지 알고 릴리스 전에 그 문서의 변경분을 확인하는 습관 이다. 레슨마다 1차 출처 링크를 달아 두었으니, 실무에서는 항상 원문을 다시 확인하고 쓴다.

완료 후 할 수 있는 것

• App Store 심사 지침·Google Play 정책·원스토어 상품 검증 가이드라인의 구조를 알고, 대표 반려 사유를 출시 전 체크리스트로 옮길 수 있다
• 반려 통지를 읽고 원인을 분류해 수정·소명·이의 제기 중 무엇을 할지 판단하고, 재심사 제출물을 준비할 수 있다
• Android 런타임 권한 흐름(요청 시점·거부·영구 거부·설정 복귀)과 iOS 권한 다이얼로그를 시나리오로 나눠 검증할 수 있다
• Play 데이터 안전 섹션과 App Privacy 라벨의 선언 내용을 실제 네트워크 트래픽·SDK 목록과 대조해 불일치를 결함으로 보고할 수 있다
• Android App Links와 iOS Universal Links의 도메인 검증 상태를 adb 와 AASA 파일로 직접 확인하고, 딥링크 라우팅 테스트 매트릭스를 만들 수 있다
• POST_NOTIFICATIONS 권한과 알림 채널, 포그라운드 서비스 타입, Doze·App Standby 제약 아래에서 푸시와 백그라운드 작업을 검증할 수 있다
• Firebase Test Lab과 BrowserStack에서 디바이스 매트릭스를 설계·실행하고, 기기 선정 근거를 사용자 통계와 위험으로 설명할 수 있다
• Appium 2/3의 드라이버 모델, 플랫폼별 로케이터 전략, 하이브리드 앱 컨텍스트 전환, W3C Actions 기반 제스처, 조건 대기를 실제 코드로 작성할 수 있다
• TalkBack·VoiceOver로 핵심 플로우를 통과시키고, 터치 대상 크기·포커스 순서·레이블 결함을 재현 절차와 함께 보고할 수 있다

채용시장에서의 위치

모바일 QA 공고를 읽어 보면 "앱 출시 경험"이라는 한 줄이 거의 빠지지 않는다. 이 문장은 테스트 케이스를 몇 개 썼는지가 아니라 스토어 심사·권한·정책 대응을 겪어 봤는가 를 묻는 것이다. 심사 반려는 릴리스 일정을 통째로 밀어 버리는 사건이라, 반려 사유를 미리 잡아내는 QA는 조직 안에서 존재감이 뚜렷하다. 면접에서도 "권한 요청 거부 시나리오를 어떻게 테스트하나요", "딥링크가 앱 대신 브라우저로 열리는 원인이 무엇일까요" 같은 질문이 실제로 나온다.

국내 시장의 특수성도 있다. 삼성 갤럭시 스토어와 원스토어가 실질적인 유통 채널이고, 통신사 제휴 앱은 원스토어 선탑재를 전제로 개발되는 경우가 있다. 구글·애플만 아는 QA보다 세 스토어의 정책 차이를 정리해 둔 QA 가 국내 앱 조직에서 더 쓸모 있다. 기기 파편화도 심해서, 제조사 커스텀 ROM의 배터리 최적화 때문에 푸시가 안 오는 문제는 한국 앱 팀이 반복해서 겪는 전형적인 이슈다.

자격증 축으로는 ISTQB Certified Tester Mobile Application Testing(CT-MAT) 이 이 모듈의 범위와 가장 가깝다. 모바일 앱 테스트의 비즈니스 맥락, 플랫폼 제약, 테스트 유형과 환경(실기기·시뮬레이터·디바이스 클라우드), 모바일 자동화 도구를 다룬다. 자격증 자체보다 그 실라버스가 요구하는 산출물 — 디바이스 커버리지 매트릭스, 권한 테스트 시나리오, 스토어 릴리스 체크리스트 — 을 포트폴리오로 갖고 있는 편이 면접에서 훨씬 강하다. 접근성은 별도의 무기가 된다. 공공기관 앱과 금융 앱은 접근성 준수가 계약 조건인 경우가 많아, TalkBack·VoiceOver로 실제 플로우를 통과시켜 본 경험이 곧바로 차별점이 된다(기준 자체는 모듈 49에서 다룬다).