개념
모바일 성능은 웹과 다른 축을 갖는다
모듈 16에서 배운 성능 테스트(부하·응답 시간)는 주로 서버 관점이었다. 모바일 앱은 여기에 기기 자체의 자원이라는 새로운 축이 더해진다.
웹 성능(모듈 16): 서버 응답 시간, 렌더링 속도
모바일 성능(이 레슨): 배터리 소모량, 메모리 사용량, 발열, 앱 실행 속도배터리 소모(Battery Drain)
앱이 백그라운드에서도 계속 위치 정보를 갱신하거나, 불필요하게 네트워크 요청을 반복하면 배터리를 과도하게 소모한다. 사용자 입장에서 "이 앱을 쓰면 배터리가 빨리 닳는다"는 인식은, 기능이 아무리 훌륭해도 앱을 삭제하게 만드는 흔한 이유다.
확인 방법: 앱을 일정 시간 사용(또는 백그라운드 방치)한 뒤,
OS의 배터리 사용량 통계에서 이 앱이 차지하는 비중을 확인메모리 사용량과 OOM(Out of Memory)
모듈 9(레슨 4)에서 배운 메모리 누수 개념이 모바일에서는 더 치명적이다 — 모바일 기기는 데스크톱보다 메모리가 훨씬 제한적이라서, 메모리를 과도하게 쓰는 앱은 OS가 강제로 종료시킨다(OOM Kill). 레슨 1에서 배운 "백그라운드에 오래 있다가 돌아왔을 때 강제 종료됐을 수 있다"는 상황이, 바로 이 메모리 관리와 직결된다.
크래시(Crash)와 크래시 리포트 도구
앱이 예기치 않게 완전히 종료되는 것을 크래시라 한다. 크래시는 개발 환경에서는 안 보이다가, 실제 사용자의 다양한 기기·OS 조합·데이터 상태에서만 발생하는 경우가 많다 — 모듈 7(레슨 3)에서 배운 환경 패리티 문제가 모바일에서 극대화된 형태다.
Firebase Crashlytics 같은 크래시 리포트 도구는, 실제 사용자 기기에서 크래시가 발생하면 어느 코드에서, 어떤 기기·OS 조합에서 발생했는지를 자동으로 수집해 보고한다.
크래시 리포트가 알려주는 것:
- 어떤 화면/기능에서 크래시가 발생했는가
- 몇 명의 사용자, 몇 번의 세션에서 발생했는가
- 특정 기기 모델이나 OS 버전에 몰려있는가크래시 우선순위 정하기
크래시 리포트에는 온갖 크래시가 쌓인다. 모듈 6(레슨 1)에서 배운 심각도·우선순위 판단을 여기에 적용한다.
우선순위가 높은 크래시: 많은 사용자에게 반복적으로 발생, 핵심 기능(결제 등)에서 발생
우선순위가 낮은 크래시: 극소수 기기에서 한 번만 발생, 부가 기능에서 발생QA가 크래시 모니터링에서 하는 역할
QA가 크래시 리포트 도구를 직접 개발하지는 않지만, 릴리스 직후 크래시 발생률을 지속적으로 관찰하는 것은 QA의 중요한 역할이다. 이건 모듈 8(레슨 4)에서 배운 모니터링·통제 원칙을, 배포 이후까지 확장한 것이다 — 테스트는 배포 순간에 끝나지 않는다.
실무에서 왜 필요한가
"기능 테스트는 다 통과했는데, 배포 후 특정 기종에서만 크래시가 폭증한다"는 상황은, 개발·테스트 환경이 실제 사용자 기기 다양성을 다 커버하지 못해서 생긴다. 크래시 리포트 도구를 배포 후에도 꾸준히 살피는 습관은, 이런 사각지대를 빠르게 발견하고 대응하는 안전망이 된다.