개념
우리가 통제할 수 없는 변화
모듈 7(레슨 3)에서 배운 환경 관리 원칙을 떠올려보자 — 웹은 우리가 서버·배포 시점을 통제할 수 있지만, 모바일 OS 업데이트는 애플과 구글이 결정하고, 사용자가 언제 설치할지도 우리가 통제할 수 없다. 어느 날 갑자기 사용자 기기의 OS가 업데이트되면서, 우리 앱이 아무것도 안 바꿨는데도 이상하게 동작할 수 있다.
새 OS 버전이 만드는 문제 유형
- 새 OS가 권한 요청 방식을 바꿔서, 기존 권한 처리 로직이 깨짐
- 새 OS가 특정 API를 사용 중단(Deprecated)해서, 그 기능이 동작 안 함
- 새 OS의 기본 UI 스타일이 바뀌어서, 우리 앱의 커스텀 디자인과 충돌함
- 새 OS의 보안 정책이 강화돼서, 이전에 허용되던 방식이 차단됨베타 채널로 미리 대비하기
Apple과 Google은 정식 출시 몇 달 전에 개발자용 베타 버전을 공개한다. 이 시기에 미리 우리 앱을 베타 OS에서 테스트해보면, 정식 출시 후 사용자들이 업데이트하며 겪을 문제를 미리 발견하고 고칠 시간을 벌 수 있다.
베타 없이: 정식 출시 → 사용자들이 업데이트 → 문제 발생 → 그제야 대응(이미 늦음)
베타 활용: 베타 출시 → QA가 미리 테스트 → 문제 발견 및 수정 → 정식 출시 시 대비 완료이건 모듈 4(레슨 2)에서 배운 위험기반 테스트의 사전 대응 원칙을, "우리가 통제할 수 없는 외부 변화"에 적용한 것이다.
지원 버전 정책(Version Support Policy)
모든 과거 OS 버전을 영원히 지원할 수는 없다. 조직은 "이 앱이 최소 어떤 OS 버전까지 지원하는가"를 명시적으로 정해야 한다.
- 최소 지원 버전(Minimum Supported Version) — 이보다 낮은 버전에서는
앱 설치 자체가 안 되게 막거나, 업데이트를 강제한다
- 최신 버전 대응(Latest Version Support) — 새로 나온 버전에서도
문제없이 동작하는지 확인한다이 정책을 정하는 기준은 모듈 11(레슨 3)에서 배운 ROI 계산과 비슷하다 — 아주 오래된 OS 버전을 쓰는 사용자가 극소수라면, 그들을 위한 지원 비용이 얻는 가치보다 클 수 있다.
실제 사용자 분포로 우선순위 정하기
모듈 13(레슨 8)에서 배운 "실제 사용자 데이터로 우선순위를 정한다"는 원칙이 OS 버전에도 그대로 적용된다.
사용자의 OS 버전 분포(예시):
최신 버전 60%, 최신-1 버전 30%, 그 이전 버전 10%
→ 최신·최신-1 버전은 반드시 테스트, 그 이전 버전은 핵심 흐름만 확인업데이트 이후 모니터링
정식 OS 업데이트가 배포된 직후에는, 레슨 4에서 다룰 크래시 모니터링 도구를 특히 주의 깊게 살펴야 한다 — 베타에서 못 잡은 문제가 실제 대량의 사용자 업데이트 시점에 갑자기 드러날 수 있다.
실무에서 왜 필요한가
"iOS 신규 버전 출시 다음 날부터 크래시 신고가 폭증했다"는 상황은, 베타 테스트를 소홀히 한 조직에서 반복되는 실패 패턴이다. QA가 매년 정해진 시기(OS 베타 공개 시점)에 맞춰 선제적으로 테스트 계획을 세우면, 이런 사고를 상당 부분 예방할 수 있다.