iOS·Android 최신 OS 업데이트 대비 호환성 테스트 가이드: 출시 전 체크리스트
iOS와 Android의 새 OS 출시 전 게임 앱이 겪기 쉬운 설치·로그인·결제·푸시·그래픽·크래시 문제를 체계적으로 점검합니다. 베타 OS, 실제 기기, 스토어 심사까지 연결하는 실무형 호환성 테스트 절차와 릴리스 기준을 제공합니다.
핵심 요약
iOS와 Android의 메이저 OS 업데이트는 권한, 백그라운드 실행, 웹뷰, 그래픽 드라이버, 결제 SDK처럼 게임 코드 밖의 계약을 바꿀 수 있습니다. 새 OS 베타가 공개되는 즉시 핵심 사용자 여정과 크래시 지표를 실제 기기에서 검증하고 차단 이슈는 서버 설정·SDK 업데이트·핫픽스 중 가장 빠른 경로로 분리해 대응해야 합니다.
최신 iOS·Android OS 업데이트에서 호환성 문제가 생기는 이유
모바일 게임은 엔진 바이너리만으로 동작하지 않습니다. Unity, Unreal Engine, 자체 엔진 위에 운영체제 API, 기기 제조사 이미지, GPU 드라이버, 서드파티 SDK, 스토어 정책이 겹칩니다. OS 업데이트는 이 경계의 동작을 바꾸므로 기존 빌드가 컴파일과 설치를 통과했더라도 런타임 장애가 발생할 수 있습니다.
특히 아래 변경은 매년 우선 확인해야 합니다.
| 변경 영역 | 대표 증상 | 우선 테스트 |
|---|---|---|
| 런타임 권한 | 로그인 후 카메라·알림·저장소 기능이 작동하지 않음 | 최초 요청, 거절, 재요청, 설정 앱 복귀 |
| 백그라운드 정책 | 푸시 딥링크·다운로드·세션 복귀가 실패함 | 백그라운드 전환, 강제 종료, 절전 모드 |
| 웹뷰·인증 | 소셜 로그인과 결제 인증 창이 닫히지 않음 | 외부 브라우저 왕복, 쿠키, 딥링크 |
| 그래픽·미디어 | 특정 GPU에서 검은 화면, 셰이더 오류, 소리 끊김 | Vulkan·Metal 경로, 해상도 전환, 발열 상황 |
| 보안·네트워크 | TLS 연결, 인증서 고정, 광고 SDK 초기화 실패 | 로그인, CDN 다운로드, 광고·분석 SDK |
| 스토어 요구사항 | 업로드 또는 심사가 거절됨 | target SDK, 개인정보 고지, 결제 흐름 |
호환성 테스트는 어떤 범위로 잡아야 하는가?
지원 OS 전체를 모든 기기 조합으로 전수 테스트하기보다 위험 기반 매트릭스를 만듭니다. 새 OS 베타와 직전 정식 OS를 기준 축으로 두고 활성 이용자 비중·매출 비중·GPU·제조사 변형이 큰 기기를 우선 배치합니다.
| 우선순위 | 기기·환경 예시 | 목적 |
|---|---|---|
| P0 | 새 iOS 베타 iPhone, 새 Android 베타 Pixel | OS API와 플랫폼 정책의 조기 결함 탐지 |
| P1 | 직전 iOS, 최신 Galaxy·Xiaomi 등 주요 제조사 기기 | 제조사 커스텀과 Android 파편화 확인 |
| P2 | 저사양·구형 GPU·폴더블·태블릿 | 성능 저하와 레이아웃·입력 회귀 확인 |
| P3 | 사용 비중이 낮은 구형 OS·기기 | 지원 정책에 따른 최소 회귀 점검 |
OS 베타 공개 후 호환성 테스트는 어떻게 진행할까?
1. 변경 사항과 테스트 대상을 고정한다
먼저 Apple과 Google의 릴리스 노트, SDK 릴리스 노트, 사용하는 광고·분석·인증·결제 SDK의 지원 공지를 확인합니다. 이때 단순히 ‘최신 버전으로 업데이트’하지 말고 현재 게임 빌드의 엔진 버전, Xcode 버전, Android Gradle Plugin, compileSdk, targetSdk, Kotlin·Java 버전을 인벤토리로 남깁니다.
다음처럼 테스트 케이스에 추적 정보를 함께 기록하면 재현과 핫픽스 판단이 쉬워집니다.
게임 빌드: 2.14.0(481)
엔진: Unity 6 LTS
플랫폼: Android 신규 메이저 OS Beta 3
기기: Pixel 계열 실기기
그래픽 API: Vulkan
재현 경로: 게스트 로그인 → 튜토리얼 완료 → 결제 화면 진입
결과: 결제 SDK 초기화 후 앱 프로세스 종료
로그: Android tombstone / Crashlytics non-fatal 첨부2. 핵심 사용자 여정을 스모크 테스트한다
새 OS에서 가장 먼저 확인할 대상은 플레이 시간을 길게 만드는 기능이 아니라 유저가 게임에 들어오고 결제까지 도달하는 경로입니다. 아래 항목은 한 기기에서 연속으로 실행해 세션 경계 문제까지 확인합니다.
- 신규 설치, 업데이트 설치, 삭제 후 재설치를 각각 수행한다.
- 게스트·Apple·Google·자체 계정 로그인과 계정 전환을 검증한다.
- 리소스 패치 다운로드, 로비 진입, 전투 또는 핵심 플레이 1회, 결과 저장을 실행한다.
- 인앱 결제의 구매·취소·복원과 영수증 서버 검증을 확인한다.
- 푸시 알림, 딥링크, 외부 브라우저 인증을 실행한 뒤 게임 복귀를 확인한다.
- 홈 전환, 화면 잠금, 전화·알림 인터럽트, 저전력 모드 후 복귀를 점검한다.
flowchart TD
A[새 OS 베타 공개] --> B[SDK·정책 변경점 분류]
B --> C[P0 실기기 스모크 테스트]
C --> D{차단 이슈 발생?}
D -- 예 --> E[로그·재현 절차 확보]
E --> F[서버 설정·SDK·클라이언트 수정 경로 결정]
F --> G[수정 빌드 회귀 테스트]
D -- 아니오 --> H[확장 기기 매트릭스 테스트]
G --> H
H --> I[출시 승인 기준 검토]3. 확장 회귀와 성능·안정성을 검증한다
스모크 테스트가 통과해도 그래픽과 메모리 문제는 장시간 플레이에서 드러납니다. 최소 20~30분의 반복 전투, 씬 전환, 리소스 다운로드, 백그라운드 복귀를 포함한 소크 테스트를 운영합니다.
크래시율은 세션 수나 활성 사용자 수를 분모로 일관되게 계산해야 추세를 비교할 수 있습니다.
OS별 대시보드에는 최소한 다음 차원을 포함합니다.
- OS 버전과 빌드 번호
- 기기 모델, ABI, GPU 렌더러
- 게임 앱 버전과 배포 채널
- 크래시 예외명, ANR, 네이티브 tombstone 여부
- 로그인·결제·전투 등 발생 직전 화면 또는 이벤트
iOS와 Android에서 특히 확인할 항목은 무엇인가?
iOS 호환성 테스트 체크리스트
- Xcode 최신 안정 버전에서 아카이브와 서명, TestFlight 업로드를 확인한다.
Info.plist의 사용 목적 문자열과 알림·사진·카메라·마이크 권한 요청 시점을 검증한다.- Sign in with Apple을 사용한다면 최초 로그인, 이메일 비공개 주소, 계정 삭제 후 재가입 흐름을 점검한다.
- StoreKit 기반 결제는 구매, 보류, 취소, 복원과 서버 영수증 검증 실패 처리를 확인한다.
- Metal 렌더링에서 셰이더 컴파일, 해상도 변경, 저메모리 경고 후 복귀를 점검한다.
- ATT(App Tracking Transparency) 선택 결과가 광고 초기화와 분석 이벤트를 차단하지 않는지 확인한다.
Android 호환성 테스트 체크리스트
targetSdkVersion변경으로 영향을 받는 권한·브로드캐스트·백그라운드 제한을 별도 케이스로 만든다.- Google Play 결제 라이브러리는 현재 적용 버전의 지원 기한과 구매 확인, 보류 결제, 복원 동작을 확인한다.
- Android App Bundle(AAB) 설치 후 ABI별 네이티브 라이브러리와 Play Asset Delivery 리소스가 정상 수신되는지 점검한다.
- Vulkan과 OpenGL ES를 모두 지원한다면 기기별 그래픽 API 선택, 폴백, 셰이더 캐시를 검증한다.
- 알림 런타임 권한, 정확한 알람, 배터리 최적화, 백그라운드 제한 상태에서 푸시와 딥링크를 확인한다.
- 제조사별 절전 정책이 강한 기기에서는 장시간 백그라운드 후 복귀와 다운로드 재개를 별도 테스트한다.
크래시가 발견됐을 때 핫픽스 우선순위는 어떻게 정할까?
장애를 발견하면 ‘재현된다’는 사실만으로 핫픽스 여부를 정하지 않습니다. 영향 범위, 우회 가능성, 수정 경로, 출시 위험을 함께 평가합니다.
| 판단 기준 | 즉시 핫픽스 우선 | 다음 정기 업데이트 검토 |
|---|---|---|
| 진입 가능성 | 실행 직후 크래시, 로그인 불가 | 특정 메뉴에서만 발생 |
| 매출 영향 | 결제·광고 보상·상점 이용 불가 | 시각적 경미한 오류 |
| 영향 범위 | 새 OS 이용자 다수 또는 특정 인기 기기군 | 극히 제한된 기기 조합 |
| 우회 가능성 | 우회 경로 없음 | 재시작·설정 변경으로 회피 가능 |
| 수정 경로 | 서버 설정 또는 검증된 SDK 패치 | 엔진 업그레이드와 광범위한 회귀 필요 |
네이티브 크래시는 심볼이 없으면 원인 분석이 어려워집니다. iOS는 dSYM, Android는 ProGuard/R8 매핑 파일과 네이티브 심볼을 해당 빌드와 함께 보관해야 합니다. 크래시 분석 도구에 업로드한 심볼의 버전이 실제 배포 빌드와 일치하는지도 릴리스 체크리스트에 포함합니다.
자주 묻는 질문 (FAQ)
OS 베타에서만 재현되는 버그도 수정해야 하나요?
정식 OS 출시 전이라도 로그인 불가, 실행 직후 크래시, 결제 불가처럼 차단 수준의 문제는 수정해야 합니다. 다만 플랫폼 베타 자체 결함 가능성이 있으므로 재현 기기, OS 빌드 번호, 로그를 확보해 엔진·SDK 공급사 이슈와 분리해 판단합니다.
에뮬레이터만으로 호환성 테스트를 끝낼 수 있나요?
아닙니다. 에뮬레이터는 화면·기본 API 회귀를 빠르게 찾는 데 유용하지만 GPU 드라이버, 푸시, 결제, 제조사 절전 정책, 실제 메모리 압박은 실기기 검증이 필요합니다.
새 OS 정식 출시일에 무엇을 모니터링해야 하나요?
OS 버전별 실행 실패율, 크래시율, ANR, 로그인 성공률, 결제 성공률, 패치 다운로드 실패율을 같은 시간대의 직전 OS와 비교합니다. 급격한 차이가 확인되면 해당 OS·기기·앱 버전 조건으로 세그먼트해 재현과 완화 조치를 시작합니다.
출시 전 승인 기준을 운영 지표로 만든다
호환성 테스트의 목표는 ‘테스트 완료’ 표시가 아니라 새 OS 이용자가 기존 이용자와 같은 수준으로 게임에 진입하고 플레이하며 결제할 수 있게 만드는 것입니다. 따라서 출시 승인 기준에는 P0 사용자 여정 통과, 차단 크래시 미해결 건수 0건, 필수 SDK 호환성 확인, OS별 모니터링 대시보드 준비를 명시합니다.
새 OS 정식 배포 후에는 첫 24~72시간을 집중 관찰 기간으로 두세요. 사전 테스트에서 놓친 제조사별 문제도 이 기간의 버전·기기·스택 트레이스 데이터로 빠르게 좁힐 수 있습니다.
