[부록] 서비스 성장을 저해하는 숨은 장벽, 크래시
앱 크래시 해결을 통한 사용자 만족도 높이기
서비스가 좋은 평가를 받기 위해서는 서비스의 안정성을 지속적으로 모니터링하고, 크래시 발생을 최소화하는 것이 필수적입니다. 하지만 아무리 많은 테스트를 거쳐 서비스를 출시해도 크래시는 발생하게 마련입니다. 유저가 많아질수록 사용 환경과 조건이 다양해지기 때문이죠. 이런 관계로 발생한 크래시를 얼마나 빨리, 정밀하게 해결하는지는 고객의 평가에 있어 그 무엇보다 중요한 요소라고 할 수 있습니다. 물론 고객의 평가가 좋아지면 서비스가 성장하는 것은 당연한 이야기겠죠.
앱의 크래시 해결을 위해 중요한 2가지 관점
그런데 크래시를 제때에 파악하고, 이를 통해 앱의 안정성을 강화하기 위해서는 아래와 같은 두 가지 관점에서 문제에 접근해야 합니다.
하나. 어떤 크래시를 먼저 해결할지 우선순위를 정해야 한다.
둘. 해당 크래시를 빠르게 재현하여 문제를 파악해야 한다.
그리고 시중에 출시되어 있는 다양한 크래시 관련 애널리틱스들은 이러한 두 가지 관점에 대해 해답을 줄 수 있습니다. 우선 유형별로 구분한 크래시 리스트를 통해 각 유형의 상황을 파악하고 문제 해결의 우선순위를 정할 수 있으며, (일부 서비스의 경우) 해당 상황을 재현하는 리플레이 기능을 함께 제공하여 빠른 문제 파악이 가능하도록 하는 것이죠. 그럼 이제부터는 실제 사례를 바탕으로 크래시 이슈를 해결하는 과정을 살펴보도록 하겠습니다.
Step1. 긴급하게 처리해야 하는 이슈는 없나?
우선 크래시 트렌드의 ‘최근 24시간 발생 현황 차트’를 확인해 보겠습니다. 최근에 발생한 크래시 수를 실시간으로 파악함으로써 현재 크래시가 폭발적으로 증가하고 있지는 않는지 살펴보는 것이죠. 아래 사진을 보면 다행히 해당 앱에 최근 24시간 이내에는 크래시가 발생하지 않은 것을 확인할 수 있습니다.
Step2. 크래시에 대응해야 하는 상황인가?
크래시가 발생할 때마다 즉시, 모두 해결하는 편이 가장 좋겠지만 이는 결코 쉽지 않습니다. 현실적으로는 다른 개발 업무와 크래시 해결 업무 중에 우선순위를 정해야 하죠. 위 그림과 같이 주요 지표를 모니터링함으로써 우리는 이를 판단할 수 있습니다. 만약 크래시 비율을 사용자 기준 1% 미만으로 유지하는 것을 목표로 설정했다면, 아래 그림에서는 현재 1.7%의 수치를 보여주고 있으므로 크래시 대응의 우선 순위를 높이는 것이 좋다고 할 수 있겠죠.
Step3. 우선적으로 해결해야 할 크래시는 무엇일까?
당연한 이야기이겠지만, 가급적 빈도가 높은 유형 순으로 우선순위를 선정하여 크래시를 대응하는 것이 좋습니다. (물론 매출과 직결되는 크래시가 발생했거나, 서비스 이용에 치명적일 수 있는 크래시가 발생했다면 발생 빈도가 높지 않더라도 이를 먼저 해결하는 것이 좋겠지만 말이죠.) 예를 들면,
(1) 현재 10개의 크래시가 발생한 상황입니다.
(2) 발생 빈도 6회로 가장 높은 크래시 유형을 보면 특정 사용자나 특정 활동에 의한 것보다는 앱 전반적으로 발생하고 있습니다.
(3) 반면 1회씩 발생한 크래시들은 특정 버전에서만 발생하는 크래시임을 알 수 있습니다.
발생 빈도가 높았던 최상단의 이슈를 우선적으로 해결하기 위해 해당 유형을 클릭하여 살펴보도록 하겠습니다.
Step4. 크래시의 패턴을 찾아보자.
크래시의 원인을 찾기 위해서는 발생 패턴을 파악하는 것이 중요합니다. 이러한 패턴은 먼저 앱의 버전, OS 버전, 디바이스의 종류로 확인해 볼 수 있습니다. 특정 환경에서만 발생하는 문제라면 그 원인을 추측해야 하는 범위가 상당이 줄어들기 때문입니다. 하지만 위 이미지에서 보이는 해당 크래시 유형의 경우 앱 버전, OS 버전, 디바이스가 다양하게 나타나기 때문에 패턴을 특정하기는 어려워 보입니다. 해결을 위해 다음을 살펴보도록 하겠습니다.
Step5. 크래시 스택 트레이스를 확인해보자.
크래시의 스택 트레이스는 개발자가 가장 먼저 에러의 원인을 찾을 수 있는 방법입니다. 코드 라인과 함께 어떤 에러가 발생하는지 확인할 수 있습니다.
(1) 해당 에러는 java.io.InterruptedIOException: thread interrupted로 발생한 크래시네요.
(2) 스택 트레이스에는 에러 발생 위치(145번째 줄)를 알 수 있는 크래시 로그를 포함하고 있네요.
(3) 발생 위치에 해당하는 코드로 이동하여 크래시의 원인을 유추해 봅니다. 하지만 한 줄의 코드(emitter.onError(e); )로는 크래시의 원인을 파악하는 데에는 어려움이 있네요.
무엇이 문제인지 사용자의 크래시 발생 상황을 리플레이해 보겠습니다.
Step6. 문제 발생 패턴을 찾는 마지막 방법, 크래시 리플레이
앞서 언급한 것처럼 일부 애널리틱스에서는 크래시 발생 상황을 재현하는 '리플레이' 기능을 제공하고 있습니다. 일반적으로 크래시를 해결할 때, 특정 디바이스나 OS 등으로 나타나는 패턴, 스택 트레이스 정보 등을 바탕으로 문제를 해결하곤 합니다. 하지만 이러한 정보만으로는 문제 상황을 확인하기 어려운 크래시들이 종종 발생하게 되는데요. 이럴 때는 오직 개발자의 추측만으로 문제를 예상하고 추적할 수밖에 없어 문제 해결에 오랜 시간이 소요되는 경우가 허다하죠.
이럴 때 유용하게 사용될 수 있는 기능이 바로 '크래시 리플레이' 기능입니다. 해당 크래시 세션에 대한 리플레이 기능으로 사용자들이 앱을 어떻게 사용하다가 크래시가 발생했는지 알 수 있기 때문이죠. 가령, 위 그림을 보면 해당 크래시가 모두 앱을 백그라운드로 이동하는 상황에서 발생함을 알 수 있습니다. 그러면 이러한 상황이 쓰레드에 영향을 줄 수 있다는 것을 짐작할 수 있죠. 그렇다면 관련 코드에 크래시가 발생하는 상황에 대해서 보완을 할 수 있을 겁니다.
마무리하며
크래시 분석은 앱의 안정성뿐만 아니라, 나아가 만족스러운 사용자의 경험에 있어서도 굉장히 중요한 과정에 해당합니다. 발생한 문제에 대해 '어쩔 수 없어'라거나 '이건 다 개발자가 해결해줘야 돼'라는 접근보다는 함께 문제를 해결하고자 노력하고, 이를 통해 서비스의 보다 빠른 발전 및 사용자 만족도 증대 목표를 달성해 보시기를 바라겠습니다.
간단한 SDK 설치만으로 다양한 앱 크래시 분석을 시작해보세요!
모바일 앱 애널리틱스, 유저해빗
