소프트웨어 스토리

요즈음 소프트웨어에 자동 crash 리포트 시스템을 장착하여 crash가 발생할때마다 자동으로 crash정보 (stack trace) 를 서버로 보내고 이를 디버깅에 이용하는 경우가 많아 졌습니다. 대표적으로 MS의 Dr. Watson  그리고 Mozilla 가 사용하는 Breakpad 등이 그 시스템입니다.

문제는 crash가 너무 많고, 따라서 그 자동 리포트가 너무 많다는 것이죠. 하루에 수백, 수천, 심지어 수만만개 이상의 crash report가 나오기 때문에 각 crash를 그때 그때 처리할수 없어, 이를 모아 두었다가 일정양이 나오면 (예를 들어 200만개이상의 crash) 이를 우선 fix하려고 노력합니다.

그러기 위해서는 crash가 200만개 발생하기를 기다려야 겠죠. 기다리는 동안 사용자를 생각해보세요. 은행관련 중요한 업무를 처리를 하다가 FF가 crash될수도 있고, 며칠 밤을 세워 작업한 논문작업이 복구도 되지 않는 이상한 word crash를 만나서 날려 버릴수도 있습니다.

이렇게 사용자를 고생시키지 말고 crash가 한두개, 또는 한 10개 정도 있으면 이를 가지고 이 crash는 앞으로 크게 될것인지 (200만개 이상), 아니면 그리 중요하지 않은 crash인지를 알수 있다면, 개발자는 크게될 가능성이 있는 crash를 우선 적으로 fix하고 patch를 업데이트 할수 있습니다. 그러면 그만큼 해당 crash로 고생할 사용자들을 줄이고 전반적으로 더 안정된 프로그램을 사용자들이 사용할수 있을 것입니다.

이러한 연구가 한국의 김동선 박사과정학생의 주로도 진행되었고 그 결과인

 “Which Crashes Should I Fix First?: Predicting Top Crashes at an Early Stage to Prioritize Debugging Efforts”
 by Dongsun Kim, Xinming Wang, Sunghun Kim, Andreas Zeller, S.C. Cheung and Sooyong Park.

논문이 소프트웨어 공학중 가장 좋은 저널인 Transactions on Software Engineering (TSE) 에 실릴 예정입니다. (한국 SE박사과정중 TSE에 논문을 발표하는 것이 흔하지 않은데 첫 저자인 김동선학생, 축하합니다.)

이 연구는 아래 그림에서 보듯이 이전의 crash들의 정보를 이용한 학습을 통해 크게 될 crash인지 아닌지를 판단하는 모델입니다.




예측 모델을 위해 다음의 3가지를 가정하고 그 가정에 따라 feature를 뽑아 냅니다.

1. History Features — “Methods (included in stack traces) in top crashes may appear in other top crashes again.”
2. Complexity Metrics Features — “Complex methods may crash often.”
3. Social Network Analysis Features — “Well-connected methods will be executed often and thus may crash often.”

이렇게 만들어진 feature를 이용하여 예측 모델을 만들게 되면, 많은 crash가 있어날 top crash를 약 75~82%의 정확도 (F-measure기준)로 예측이 가능하게 됩니다. 이 정보를 기반으로 개발자들은 top crash들을 우선 fix할수 있게 됩니다.

Crash가 많고 또 그 리포트의 양이 많기 때문에 이를 효과적으로 처리하는 이러한 방식의 연구는 앞으로도 계속 될 것입니다.

여러분들은 소프트웨어의 crash를 어떻게 관리하고 계시나요?