iOS·Android OS 버전 업데이트 대비 게임 호환성 테스트 체크리스트
iOS와 Android OS 업데이트 전후에 게임 앱이 실행·로그인·결제·푸시·그래픽·크래시 측면에서 안전한지 검증하는 실무형 호환성 테스트 체크리스트와 패치 운영 절차를 정리합니다.
OS 버전 업데이트는 새 기능을 추가하는 이벤트가 아니라 기존 게임의 실행 경로를 다시 검증해야 하는 호환성 리스크다. iOS와 Android 베타 OS에서 핵심 사용자 흐름, 권한, 외부 SDK, 렌더링, 크래시 지표를 분리해 확인하고 출시 전 대응 기준을 수치로 정하면 긴급 패치 범위를 크게 줄일 수 있다.
iOS·Android OS 업데이트에서 게임 호환성 문제가 발생하는 이유
모바일 OS는 매년 API, 권한 정책, 백그라운드 실행 조건, WebView 동작, 그래픽 드라이버, 스토어 검증 규칙을 바꾼다. 게임 클라이언트 코드가 바뀌지 않아도 Unity, Unreal Engine, 네이티브 플러그인, 광고·분석·결제 SDK가 새 OS와 충돌할 수 있다.
특히 다음 변경은 라이브 게임에 직접 영향을 준다.
| 변경 영역 | iOS에서 확인할 항목 | Android에서 확인할 항목 | 게임 영향 |
|---|---|---|---|
| 빌드 도구 | Xcode, iOS SDK, Privacy Manifest | Android Gradle Plugin, targetSdkVersion, R8 | 빌드 실패, 스토어 심사·등록 차단 |
| 권한 | 사진, 카메라, 추적 허용, 알림 | 알림, 미디어, 위치, 블루투스 | 로그인 보상, 공유, 푸시 기능 실패 |
| 외부 연동 | Sign in with Apple, StoreKit, APNs | Google Play Billing, Google Sign-In, FCM | 로그인·결제·푸시 장애 |
| 렌더링 | Metal, 화면 회전, Safe Area | Vulkan/OpenGL ES, 제조사 GPU 드라이버 | 검은 화면, UI 잘림, 발열·프레임 저하 |
| 앱 생명주기 | 백그라운드 복귀, 인터럽트 | 프로세스 종료, 백그라운드 제한 | 세션 유실, 무한 로딩, 결제 결과 미반영 |
OS 베타가 나오면 무엇부터 테스트해야 할까?
우선 모든 콘텐츠를 동일한 깊이로 검사하지 말고 매출·접속·데이터 손실에 영향을 주는 경로부터 점검한다. 테스트 기기는 최신 OS 베타, 직전 정식 OS, 최소 지원 OS를 각각 포함한다.
1. 테스트 매트릭스를 고정한다
OS별 문제를 재현하려면 테스트 환경을 기록 가능한 표로 관리해야 한다. 최소한 다음 열을 둔다.
| 구분 | 필수 기록 값 |
|---|---|
| 기기 | 제조사, 모델명, SoC, RAM 용량 |
| OS | OS 이름, 정확한 버전, 베타 빌드 번호 |
| 앱 | 앱 버전, 빌드 번호, 배포 채널 |
| 엔진 | Unity 또는 Unreal Engine 버전 |
| 그래픽 | Metal, Vulkan, OpenGL ES 및 Graphics API 설정 |
| 재현 조건 | 계정 상태, 네트워크, 언어, 권한 허용 여부 |
| 결과 | 통과·실패·보류, 로그 ID, 화면 녹화 링크 |
권장 우선순위는 다음과 같다.
- 최신 OS 베타의 최신 플래그십 기기에서 스모크 테스트를 수행한다.
- 직전 정식 OS와 최소 지원 OS에서 회귀 테스트를 수행한다.
- Android는 점유율이 높은 제조사와 GPU 조합을 추가해 그래픽·백그라운드 동작을 확인한다.
2. 접속과 결제처럼 중단할 수 없는 흐름을 검증한다
아래 항목은 OS 베타가 배포된 직후 가장 먼저 확인할 스모크 테스트다.
- 앱 설치, 업데이트, 최초 실행, 강제 종료 후 재실행
- 게스트 로그인, 플랫폼 로그인, 계정 연동, 로그아웃 후 재로그인
- 신규 튜토리얼 진입과 저장 데이터 복원
- 인앱 결제 시작, 취소, 성공, 실패, 구매 복원
- 보상형 광고 로드·시청 완료·보상 지급
- 푸시 수신, 푸시 탭으로 앱 진입, 딥링크 처리
- 게임 중 전화·알림·화면 잠금 뒤 복귀
- Wi-Fi와 LTE/5G 전환 중 매치, 다운로드, 결제
- 언어 변경, 다크 모드, 글자 크기 변경, 화면 회전
결제는 클라이언트 화면만 확인해서는 부족하다. 구매 요청부터 영수증 검증, 서버 지급, 재접속 후 인벤토리 반영까지 하나의 트랜잭션으로 검증한다. 중복 지급과 미지급은 서로 다른 장애이므로 각각의 테스트 케이스가 필요하다.
iOS 호환성 테스트 체크리스트는 어떻게 구성할까?
빌드·심사 정책 확인
- 현재 Xcode가 목표 iOS SDK와 호환되는지 확인한다.
Info.plist의 권한 사용 문구가 실제 기능과 일치하는지 확인한다.- Privacy Manifest와 Required Reason API 선언이 사용하는 서드파티 SDK의 요구사항과 맞는지 검토한다.
- App Tracking Transparency를 사용하는 경우, 추적 허용 전후에 광고·분석 초기화가 안전한지 확인한다.
- StoreKit 2 또는 기존 StoreKit 연동에서 구매 복원과 미완료 트랜잭션 처리가 정상인지 확인한다.
iOS 런타임·그래픽 확인
- 앱이 백그라운드로 전환된 뒤 복귀할 때 BGM, 네트워크 소켓, 입력, 타이머가 중복 실행되지 않는지 확인한다.
- 노치와 Dynamic Island가 있는 기기에서
Safe Area기준 UI가 잘리지 않는지 확인한다. - Metal 렌더링에서 첫 진입 검은 화면, 셰이더 컴파일 멈춤, 텍스처 깨짐이 없는지 확인한다.
- 저전력 모드와 발열 상황에서 프레임 저하가 플레이 불가 수준으로 악화되지 않는지 확인한다.
- APNs 토큰 갱신 뒤 푸시 토큰이 서버에 정상 등록되는지 확인한다.
iOS 크래시 로그 수집 기준
Xcode Organizer, TestFlight, Firebase Crashlytics 등 사용 중인 수집 도구에서 OS 버전별 크래시를 분리한다. 특히 EXC_BAD_ACCESS, 메모리 압박 종료, Metal 관련 스택, 네이티브 플러그인 스택을 우선 분류한다.
Android OS 업데이트 호환성 테스트에서 놓치기 쉬운 항목은?
Android는 OS 버전뿐 아니라 제조사 커스텀, GPU 드라이버, 화면 비율, 백그라운드 정책의 편차가 크다. 따라서 Google Pixel 에뮬레이터만 통과했다고 실제 호환성을 보장할 수 없다.
targetSdkVersion과 권한 변경 확인
targetSdkVersion상향 시 바뀌는 런타임 권한과 백그라운드 실행 제한을 릴리스 노트 기준으로 확인한다.- 알림 권한이 거부된 상태에서도 게임의 필수 진행이 막히지 않는지 확인한다.
- 사진·영상 업로드 기능은 광범위한 저장소 권한 대신 시스템 사진 선택기를 사용할 수 있는지 검토한다.
- Google Play Billing Library 버전과 결제 승인·보류·취소·복원 흐름을 검증한다.
- Android App Bundle 배포 후 Play Console의 기기 카탈로그에서 새 OS 기기가 제외되지 않는지 확인한다.
제조사·그래픽·성능 확인
- Adreno, Mali, PowerVR 계열 GPU에서 Vulkan과 OpenGL ES 설정별로 타이틀 화면과 실전 콘텐츠를 실행한다.
- 폴더블 기기, 태블릿, 고주사율 기기에서 해상도 전환과 UI 앵커가 정상인지 확인한다.
- 화면 분할, PiP, 멀티 윈도우를 지원하지 않는 게임이라면 의도한 제한이나 일시 정지가 적용되는지 확인한다.
- 배터리 최적화가 강한 제조사 기기에서 백그라운드 복귀 후 로그인 세션과 다운로드 작업이 유지되는지 확인한다.
- ABI 필터와 네이티브
.so라이브러리가 지원 기기에 모두 포함되는지 확인한다.
크래시와 ANR은 어떤 기준으로 출시를 막아야 할까?
단일 크래시 보고서만으로 출시를 중단할 필요는 없지만 결제·로그인·첫 실행처럼 핵심 경로에 재현 가능한 치명적 문제는 발생 비율과 무관하게 차단 사유가 된다. 판단 기준은 전체 수치와 핵심 흐름의 심각도를 함께 사용해야 한다.
| 구분 | 출시 차단 판단 예시 | 대응 |
|---|---|---|
| 첫 실행 크래시 | 새 OS에서 재현 가능 | 즉시 핫픽스 또는 배포 보류 |
| 로그인 실패 | 특정 플랫폼 인증 전체 실패 | 서버·SDK·클라이언트 공동 점검 |
| 결제 오류 | 결제 성공 후 지급 누락 또는 중복 지급 | 판매 제한과 복구 정책 검토 |
| ANR | 로딩, 광고 복귀, 백그라운드 복귀에서 반복 | 메인 스레드 블로킹 분석 |
| 그래픽 오류 | 특정 GPU에서 전투 진행 불가 | Graphics API 우회 또는 품질 설정 조정 |
| 경미한 UI 오류 | 우회 가능하고 데이터 손실 없음 | 알려진 이슈 등록 후 다음 패치 반영 |
크래시율은 세션 수보다 영향을 받은 사용자 비율과 함께 본다. 예를 들어 다음처럼 계산할 수 있다.
다만 새 OS 초기에는 표본 수가 작다. 따라서 지표가 좋아 보여도 첫 실행, 로그인, 결제, 전투 진입의 수동 재현 결과를 우선한다.
OS 업데이트 호환성 테스트를 운영 절차로 만드는 3단계
1. 베타 공개 직후: 탐색 테스트와 위험 목록 작성
OS 개발자 베타가 배포되면 엔진, 광고, 분석, 인증, 결제 SDK의 지원 현황을 확인한다. 이어서 최신 베타 OS 기기에서 30~60분 분량의 핵심 흐름 탐색 테스트를 수행하고 실패 항목을 재현 가능 여부와 사용자 영향도로 분류한다.
2. 출시 후보 시점: 회귀 테스트와 패치 결정
릴리스 후보 버전에서는 고정된 테스트 매트릭스로 전체 회귀 테스트를 진행한다. 장애마다 담당자, 임시 우회책, 수정 목표 버전, 출시 차단 여부를 기록하고 서버 설정만으로 완화할 수 있는 문제와 앱 업데이트가 필요한 문제를 구분한다.
3. 정식 배포 후: 관찰·점진 배포·롤백 준비
정식 OS 출시 후에는 분석 도구의 OS 버전 필터를 새 버전으로 고정해 크래시, ANR, 로그인 실패, 결제 실패, 튜토리얼 이탈을 관찰한다. 앱 업데이트가 필요하면 단계적 배포 비율을 올리고 이상 징후가 발생했을 때 중단할 기준과 스토어 롤백 또는 서버 기능 비활성화 절차를 미리 정한다.
자주 묻는 질문 (FAQ)
iOS와 Android 최신 베타 OS만 테스트하면 충분한가?
아니다. 최신 베타 OS 외에 현재 이용자가 많은 직전 정식 OS와 게임의 최소 지원 OS도 함께 테스트해야 한다. 실제 장애는 새 OS보다 오래된 OS와 새 앱 빌드의 조합에서 발생하기도 한다.
Unity나 Unreal Engine을 최신 버전으로 올리면 호환성 문제가 자동으로 해결되는가?
아니다. 엔진 업그레이드는 OS 호환성 개선에 도움이 될 수 있지만 네이티브 플러그인, 광고 SDK, 결제 SDK, 셰이더, 빌드 설정까지 함께 검증해야 한다. 엔진 업그레이드 자체가 새로운 회귀 위험이 될 수도 있다.
새 OS에서만 발생하는 문제는 정식 OS 출시 뒤에 고쳐도 되는가?
핵심 흐름을 막는 문제라면 안 된다. 베타 단계에서 재현됐다면 정식 출시 전 수정하거나 최소한 영향을 받는 기능을 서버 설정으로 안전하게 제한할 수 있어야 한다.
마무리
OS 업데이트 대응의 핵심은 기기 수를 무작정 늘리는 것이 아니라 위험도가 높은 사용자 흐름을 먼저 검증하고 OS·기기·앱 빌드·SDK 조합을 기록하는 데 있다. 매년 반복되는 점검을 체크리스트와 출시 기준으로 표준화하면 긴급 대응은 줄고 패치 판단은 더 빨라진다.
