크래시 수집기를 시험하려고 앱을 일부러 죽였는데, 안 죽었다

수집기를 시험하려면 앱이 죽어야 한다

게임이 폰에서 터지면 리뷰가 달리기 전에 제가 먼저 알고 싶었습니다. 그래서 오류를 모아 주는 작은 수집기를 만들어 게임 열 개 안팎에 넣었습니다. 웹뷰 오류, 직전에 한 행동, 앱이 통째로 사라지는 네이티브 크래시까지 받습니다.

문제는 시험입니다. 수집기가 크래시를 잡는지 보려면 앱이 실제로 죽어야 합니다. 그래서 일부러 앱을 죽이는 스위치를 따로 넣었습니다. 숨겨 둔 버튼을 누르면 앱 프로세스에 SIGSEGV(메모리 접근 오류 신호)를 쏩니다.

틀린 판단 하나: 신호를 쏘면 죽을 거라고 믿었다

iPhone 11 Pro 실기기에서 스위치를 눌렀는데 앱이 죽지 않았습니다. 화면은 그대로였고, 수집기에는 아무것도 도착하지 않았습니다.

이때 가장 위험한 결론은 수집기가 크래시를 못 잡는다는 것입니다. 스위치가 죽이지 못한 것인데 수집기 탓으로 읽으면, 멀쩡한 코드를 고치고 진짜 구멍은 그대로 둡니다. 확인해 보니 원인은 스위치였습니다. 웹뷰가 이미 달아 둔 신호 처리기가 그 신호를 먼저 가로채고 있었습니다.

고친 건 한 줄입니다. 신호를 쏘기 전에 SIGSEGV를 기본 동작으로 되돌립니다. 그러자 앱이 죽었고, 다음 실행에서 웹뷰 쪽 비정상 종료 기록과 iOS가 모아 준 SIGSEGV 보고가 둘 다 도착했습니다. 시험 도구가 시험 대상보다 먼저 틀릴 수 있다는 걸 이날 배웠습니다.

틀린 판단 둘: 올린 직후 들어온 오류는 사용자 거라고 믿었다

수집기에는 심각도 기준이 있습니다. 켜고 8초 안에 나는 부팅 오류가 2판 이상이면 심각하다고 보고 바로 핫픽스를 준비합니다. 첫 주 이 기준에 두 게임이 걸렸습니다. 왁뿌타워 1.0.10과 치치 배낭 1.0.0이 Play에 올라간 직후였고, 둘 다 같은 오류였습니다. 셰이더 링크가 실패했고 유니폼 수가 261이었습니다.

저는 제 게임이 사용자 폰에서 부팅하다 죽는다고 읽었습니다. 아니었습니다. 왁뿌타워 1.0.10을 업무폰(Adreno 740)에서 켜 보니 오류는 0이었고, 261이라는 숫자는 구글의 가상 기기가 쓰는 소프트웨어 렌더러(SwiftShader)의 한도 값이었습니다. Play가 올린 직후 돌리는 사전 출시 테스트 로봇이 낸 오류를 사람 오류로 세고 있었던 것입니다.

그래서 바꾼 것

수집기가 소프트웨어 렌더러나 firebase.test.lab 기기에서 돌면 세션도 오류도 아예 보내지 않게 했습니다. 업무폰에서 표지를 켜면 로봇으로 인식하고, 끄면 사람으로 인식하는 것까지 직접 확인했습니다. 같은 가드가 빠진 사본이 생기지 않도록 동기화 점검에도 넣었습니다.

첫 주 얻은 규칙은 둘입니다. 시험용 스위치는 먼저 그 스위치가 실제로 되는지 확인한다. 새 감시 장치는 자기 잡음부터 거른다.

같은 처지라면 먼저 해 볼 것

오류 수집기를 새로 붙이는 1인 개발자라면 이 순서를 추천합니다.

• 일부러 죽이는 코드를 만들었으면, 먼저 실기기에서 앱이 정말 죽는지 확인한다.
• 죽은 뒤 다음 실행에서 보고가 도착하는지까지 본다.
• Play에 올린 직후 들어온 오류는 사전 출시 보고서의 기기 목록과 먼저 대조한다.
• 의심스러운 오류는 실제 폰 하나에서 같은 버전으로 재현해 본다.
• 새 알림 기준은 첫 주에 자기가 낸 잡음 건수부터 센다.