이전에 회사에서 근무할 때 소프트웨어를 릴리즈하면 테스트 팀에서 버그를 찾아 버그관리 시스템에 등록했었다. 버그관리 시스템에 등록할 때 테스터는 문제의 재현 경로, 심각도, 발생빈도등을 기술해 올리는데 프로젝트 관리자는 이러한 정보를 바탕으로 적절한 인력에게 문제를 할당하고 개발자는 이렇게 할당된 문제를 꼼꼼히 검토하고 실제로 코드를 수정한 후 역시 시스템을 통해 문제해결책을 기술하면 다음번 릴리즈때 테스터가 이를 다시 검토하는 식으로 최종 출시때까지 반복했다.
나름 상당히 선진적인 시스템이라고 할 수 있지만 가장 큰 문제는 테스터의 버그 리포팅이 순수하게 사람에 의해 진행된다는 점이었다. 우선은 테스터의 질에 따라 질좋은(?) 버그의 발견 확률이 크게 달라지고, 버그가 발견되었다 하더라도 문제가 발생한 순간의 스택 덤프라던가, 실제 프로그램의 내부 상태를 알 수 있는 방법이 없었기에 테스터는 단순히 발견 경로에 대한 정보를 손으로 기술할 수 밖에 없었다. 더 큰 문제는, 많은 경우 문제의 재현이 쉽지 않다는 데에 있다. (재현이 어려운 문제와 관해서는 이전의 글에서 기술한 바 있다). 그래도 여기까지는 어쨌든 전문적인 테스터에 의해 진행되므로 사정은 좀 낫다.
우여곡절끝에 버그 추적 시스템에 등록된 모든 문제를 해결하고 나서 출시를 하면 과연 문제가 없을까? 당연히 그렇지 않다. 엄청나게 많은 소비자의 손에 들어가면 잘 드러나지 않았던 오만가지 문제들이 줄줄이 드러나게 마련이다. 출시 후에 고객에 의해 발견된 문제는 인터넷 게시판이나 고객센터등을 통해 수집된다. 이렇게 수집된 정보는 당연히 전문 테스터가 아니므로 그 형식이나 내용 기술이 불충분한 경우가 대부분이다. 이 빈약한 정보를 바탕으로 테스터와 개발자는 필사적으로 문제를 재현하고 문제를 해결한 소프트웨어를 릴리즈한다. 잘 팔리는 제품일수록 버그에 대한 소비자의 불평불만은 그에 비례해서 늘어난다. 여기에 몇번 데이다 보면, 개발자나 PM은 차라리 고과를 잘 못받을 지언정, 안팔리는 모델을 진행하면 좋겠다는 푸념을 하기에 이른다. 사용하는 사람이 적으면 문제가 잘 발견되지 않기 때문이다.
자 그럼 세계에서 가장 많은 사람들이 사용하는 소프트웨어를 만드는 마이크로소프트의 개발자나 PM들은 이러한 문제에 어떻게 대응할까? 물론 그들도 고충이 오죽하겠냐마는 그 고충을 어떻게든 줄여보고자 똑똑한 마이크로소프트는 참 많은 재미난 것들[1,2,3]을 한다. 그중에 하나가 이 글에서 이야기하고자 하는 WER(Window Error Reporting)이라는 시스템이다.
이하 아래의 모든 내용은 [1]의 논문을 참조했음을 먼저 밝힌다.
누구나 윈도우를 사용하다가 프로그램이 이상 동작을 해서 죽어버리는 경험을 해 봤을 것이다. 그럴 때 나타나는 화면이 바로 아래의 화면이다.
보통 별 생각없이 ok를 하거나, 뭔가를 마이크로소프트에 보낸다는게 께림직한 사람들은 cancel을 눌렀을 터이다. 이 화면에서 ok를 하면 마이크로소프트는 경우에 따라 간단한 프로그램,모듈 이름등의 정보부터 스택덤프등의 상세정보까지 "자동"으로 마이크로소프트내의 WER 서버에 전송한다. 결코 사용자에게 프로그램 버젼이 무언지, 어떻게 하다가 죽었는지 물어보지 않는다. 모든 것은 자동으로 일어난다. 엄청나게 많은 사용자가 엄청나게 다양한 환경에서 프로그램을 사용하다 보니, 당연히 엄청나게 많은수의 버그들이 있을거다. 1999년에 최초로 이 시스템이 도입된 이후로 얼마나 많은 버그들이 이 WER 시스템을 통해 보고되었는지 구체적인 숫자는 나와 있지 않지만, 현재의 WER 시스템은 하루에 1억개의 버그 리포트를 수용할 수 있도록 업그레이드 되었다고 하니 대충 그 규모를 짐작해 볼 수 있다.
이렇게 서버에 전송된 정보는 다시 프로그램에 의해 자동으로 분류되고 가공되어 개발자에게 제공된다. 이미 해결책이 알려진 버그는 자동으로 사용자에게 버그 수정 패치가 있는 웹사이트의 주소를 넘겨주는 식으로 처리된다. 이렇게 이미 해결책이 있는 버그에 대한 리포트가 전체 리포트의 90%를 상회한다고 한다. 이 단계에서 걸러지지 않은, 그러니까 아직 해결책이 알려지지 않은 버그에 대해서는 라벨을 붙에 시스템에 저장한다. 이때 WER 시스템은 클라이언트로부터 좀더 많은 정보 (stack dump등)의 정보를 요청할 수 있으며 추가적으로 개발자가 해당 버그에 대해 더 알고 싶어하는 추가 정보 (레지스트리 값, 특정 파일 내용)를 설정할 수 있도록 설계되어 있다.
워낙에 수가 많기 때문에 어찌보면 자연스런 결과일 수 있지만, 정보 전송, 분류등의 모든 과정은 자동으로 일어난다. 또한가지 중요한 특징은 워낙에 수가 많다보니 통계적인 추이를 통해 문제의 중요도, 해결책의 유효성 여부등을 확인 가능하다는 점이다. 통계를 배운 사람이라면 파레토 분포에 대해 들어보았을 것이다. 흥미롭게도 버그의 분포는 (어찌보면 당연하게도) 소수의 문제가 전체 불량의 대다수를 차지하는 전형적인 파레토 분포를 따른다고 한다. 논문에 의하면 이와같이 자동으로 수집 분류되고 통계적으로 가공된 정보를 이용해서 버그를 수정하는 것과, 사람에 의해 보고된 버그를 수정하는 것을 비교했을 때 WER을 통한 버그가 4~5배 정도 더 수정될 확률이 높았다고 한다. 왜냐면 사람에 의해 보고된 버그는 외부에 나타나는 현상만을 기술하지만, WER은 시스템의 상세한 내부 정보를 알 수 있고 방대하게 축적된 각종 통계자료를 통해 문제의 원인에 대한 다양한 유추 해석이 가능하기 때문이라고 한다.
문제없는 소프트웨어를 만드는 것은 참 힘든 일이다. 또 발견된 문제의 원인을 찾아 해결하는 것도 어려운 일이다. 하지만 이는 누구에게나 마찬가지다. 같은 문제라도, 머리를 쓰고 조금 더 잘 해볼려고 노력하면 훨씬 효과적으로 덜 마음고생하면서 할 수 있다. 회사에서 늘 같은 괴로움을 접하면서도, 조금 더 머리를 써서 잘 해볼 생각을 하지 못한 혹은 안한 걸 반성해 본다.
Reference
[1] Kirk Glerum et al, Debugging in the (Very) Large: Ten Years of Implementation and Experience, SOSP09'
[2] CHESS project homepage, http://research.microsoft.com/en-us/projects/chess/
[3] SLAM project homepage, http://research.microsoft.com/en-us/projects/slam/
[출처] 통계적 디버깅 @ 마이크로소프트|작성자 덤덤2
댓글 없음:
댓글 쓰기