이전 글에서 고객 중심의 의사 결정을 돕는 채택 보고서에 대해 설명했습니다. 이 채택 보고서에서 제공하는 다운로드 수, 채택률, 사용자 평점, 사용량에 대한 정보를 종합하면 앱의 인기도를 가늠해볼 수 있습니다. 물론 이 보고서는 유용한 도구이지만 Windows 스토어에서 제공하는 다양한 보고 도구를 감안하면 빙산의 일각에 불과합니다. 오늘 소개할 앱 품질 관련 보고서도 Windows 스토어에서 제공하는 도구 중 하나로, 앱의 품질을 측정하고 개선하는 데 유용합니다. 프로그램 관리자인 Kalyan Venkatasubramanian은 이 글을 통해 스토어에서 제공되는 품질 보고서를 소개하고 이를 활용해 앱의 품질을 개선하는 방법을 설명합니다.

- Antoine Leblond


본론으로 들어가기 전에 먼저 '품질'의 의미를 정확하게 짚고 넘어가도록 하죠. 그 이유는 사용성, 신뢰성, 보안 등 품질을 결정하는 요인이 워낙 많기 때문입니다. Windows 스토어에서 제공되는 품질 보고서의 경우, 가장 주안점을 둔 부분은 고객이 경험하는 앱의 신뢰성을 기준으로 분석 데이터를 제공하는 것이었습니다.

이 품질 보고서는 앱의 앱 통계 페이지를 통해 액세스할 수 있습니다. 해당 페이지에서 [Quality](품질) 링크를 클릭하면 [Quality](품질) 보고서 화면이 나타납니다.

품질 보고서

대시보드에 표시되는 품질 보고서의 예

이러한 보고서는 고객이 경험하는 오류의 수, 즉 앱의 실패율을 추적하여 앱 품질을 측정하는 데 도움이 됩니다. 오류란 다음 중 하나의 이유로 앱이 예기치 않게 종료되는 것을 말합니다.

  1. 크래시
  2. 앱의 응답 없음(실행 중단)
  3. 처리되지 않은 JavaScript 예외

(참고: 처리되지 않은 JavaScript 예외는 줄여서 JavaScript 예외라고 불리며, JavaScript로 작성된 앱에서만 발생합니다. )

이러한 보고서를 사용하면 다음이 가능합니다.

  1. 스토어에 게시된 여러 버전별로 앱의 품질을 파악합니다. 버전이 높아질수록 고객이 경험하는 앱의 품질이 개선되고 있는지를 알 수 있습니다.
  2. 앱의 품질을 높입니다. 스토어에 게시된 최신 버전에서 고객이 가장 자주 경험하는 오류를 파악함으로써 앱의 품질을 개선할 수 있습니다. 많이 발생하는 오류를 파악한 후 이를 수정하여 스토어에 앱의 업데이트를 게시하면 됩니다.

앱의 품질 파악

앞서 정의했듯이 앱의 품질은 실패율을 기준으로 가늠할 수 있습니다. 실패율은 크래시, 실행 중단, 처리되지 않은 JavaScript 예외(JavaScript 앱의 경우) 등 각각의 오류 유형별로 계산됩니다. 실패율을 계산하는 데 사용되는 데이터는 앱을 실행 중인 컴퓨터 중에서 품질 패널, 즉 컴퓨터 샘플을 무작위로 선정해 수집됩니다. 실패율을 계산하려면 적어도 500대 이상의 컴퓨터가 품질 패널로 수집되어야 하며, 이 기준이 적정 샘플 규모에 해당합니다. 앱의 품질 패널이 500대 미만이면 보고서에 '표시된 데이터는 통계적으로 유의미한 샘플 집합에서 수집되지 않았습니다.'(The data displayed is from a sample set that is not statistically significant.)'라는 경고가 표시됩니다. 앞으로도 최대한 신속하게 가장 정확한 정보를 제공하도록 이 기준의 타당성을 지속적으로 평가할 예정입니다.

실패율은 실질적인 사용을 시작한 후 15분 동안 컴퓨터에서 발생한 오류 개수의 평균으로 계산됩니다. PC 에코시스템의 모든 앱에서 수집된 데이터를 살펴보면 시간이 지날수록 측정되는 앱의 신뢰성이 안정화되는 것을 알 수 있습니다. 즉, 일정 수준의 사용 시간이 넘어가면 실패율에 변화가 거의 없습니다. Consumer Preview의 Metro 스타일 앱은 사용 후 15분이 지나면 이러한 안정화 현상이 나타납니다. 이렇게 일정하게 나타나는 시간상의 특성 덕분에 정확하고 빠르게 데이터를 제공할 수 있는 것입니다. 패널에서 이 기간을 늘려 설정하면 보고할 때까지 걸리는 시간이 늘어납니다. 품질 패널의 규모와 마찬가지로 이 기준도 Metro 스타일 앱 시장의 성장에 발맞춰 지속적으로 모니터링할 예정입니다. 또한 실패율을 계산할 때와 마찬가지로 결과를 왜곡시킬 수 있는 외부 요인을 없앨 계획입니다.

다음은 실패율의 예입니다.

실패율 그래프의 예

앱 품질 향상

앞서 버전이 바뀜에 따라 앱의 품질이 어떻게 변화하는지를 파악하는 방법을 알아보았습니다. 우리는 여러분이 최신 앱 버전에서 고객이 가장 많이 경험하는 오류에 대해서도 궁금해 하고 있음을 잘 알고 있습니다. 그래서 앱의 최신 버전에서 자주 발생하는 오류의 목록도 발생률 순으로 정리하여 제공하고 있습니다. 오류의 발생률은 고객의 환경에서 총 발생 횟수를 집계하여 산출합니다.

실패율은 초기의 실제 앱 사용과 관련한 엄격한 기준에 따라 품질 패널의 컴퓨터에서 계산된다고 앞서 설명했습니다. 가장 많이 발생하는 오류 목록과 관련한 데이터는 앱의 모든 고객으로부터 수집됩니다. 그런데 앱 고객 중에 오류가 발생하여 사용 요건을 충족하지 못한 고객이 다수를 차지하는 경우에는 어떻게 될까요? 이 경우에는 다음과 같이 '실패율'이 0으로 표시되지만 앱에서 가장 많이 발생하는 오류가 나열됩니다.

가장 많이 발생하는 오류를 보여 주는 보고서의 예

실패율 계산과는 별도로 고객이 가장 많이 경험하는 오류의 목록(예: 위의 그림과 같은 크래시)을 제공하고 수집하는 정보의 범위를 확대함으로써 모든 고객이 경험하는 오류를 파악하여 수정할 수 있게 지원해 드립니다. 이 정보는 앱에서 발생하는 오류를 릴리스 초반에 파악하여 대응하는 데에도 유용합니다.

크래시와 실행 중단

크래시와 실행 중단의 경우 앱의 최신 버전에서 가장 많이 발생하는 오류 5개를 보여 줍니다. 오류의 수는 앱의 모든 고객이 경험한 총 발생 횟수입니다. [Download](다운로드) 링크를 클릭하면 해당 오류의 프로세스 덤프가 포함된 .cab 파일을 다운로드할 수 있습니다.

앱에서 가장 많이 발생하는 크래시를 보여 주는 예

오류는 오류 이름을 사용하여 고유하게 식별됩니다. 실행 중단과 크래시의 경우 오류 이름의 예는 다음과 같습니다.

NULL_CLASS_PTR_READ_c0000005_mydll.dll!myfunc::DoOp

장애 이름은 다음과 같은 요소로 이루어집니다.

  • 문제 클래스(NULL_CLASS_PTR_READ)
  • 오류 코드(c0000005)
  • 기호(mydll.dll!myfunc::DoOp)

참고: 오류의 근본 원인을 찾는 방법은 여기에서 확인하세요. 이 블로그 글은 특별히 Metro 스타일 앱과 관련해서 작성된 것은 아니지만, 오류 관련 정보 수집과 처리 과정을 이해하기에 좋은 자료입니다.

앱에서 발생하는 크래시나 실행 중단의 원인은 관련 .cab 파일을 다운로드하면 확인할 수 있습니다. .cab 파일에는 앱에서 발생하는 오류 관련 프로세스 덤프가 포함되어 있습니다. 이 프로세스 덤프를 통해 오류에 대한 스택 추적과 기타 정보를 얻을 수 있습니다.

.cab 파일을 처리하고 스택 추적을 추출하기 위해 필요한 사전 조건은 다음과 같습니다.

  1. 컴퓨터에 WinDbg.exe 설치.
    WinDbg.exe는 프로세스 덤프에서 스택 추적을 하는 데 사용되는 권장 디버깅 도구입니다. 컴퓨터에 WinDbg.exe��� 설치되어 있지 않은 경우 여기에서 다운로드할 수 있습니다.
  2. 응용 프로그램의 기호.
    프로세스 덤프에서 추적 스택을 추출하려면 스토어에 게시된 앱의 현재 버전에 해당하는 기호가 필요합니다.

크래시 및 실행 중단에 대한 스택 추적

다음에서 설명하는 단계가 완전한 디버거 자습서는 아니지만 앱에서 발생하는 오류에 대한 스택 추적을 추출하는 방법으로 참고할 수 있습니다.

  1. 앱과 관련한 오류(크래시 또는 실행 중단) 이름 옆에 있는 [Download](다운로드) 링크를 클릭합니다. 설명을 위해 오류 이름을 다음과 같이 가정해 보겠습니다.
    STATUS_INTEGER_DIVIDE_BY_ZERO_c0000094_FaultoidEx.Engine.dll!?__abi_FaultoidEx_Engine___IEngineServerPublicNonVirtuals____abi_DivideByZero
  2. 원하는 위치에 .cab 파일을 저장합니다.
  3. WinDbg.exe를 실행합니다.
  4. [File](파일) > [Open Crash Dump](크래시 덤프 열기)를 클릭합니다.

    WinDbg 주 화면
  5. [Open Crash Dump](크래시 덤프 열기) 대화 상자에서 2단계에서 파일을 저장한 위치를 선택하여 엽니다.

    WinDbg에서 파일을 여는 방법의 예
  6. [File](파일) > [Symbol File Path](기호 파일 경로)를 클릭하고 스토어에 게시된 버전에 해당하는 기호의 경로를 입력합니다. [Reload](다시 로드) 확인란을 선택하고 [OK](확인)를 클릭합니다.

    WinDbg에서 기호를 지정하는 방법의 예

    Microsoft에서 제공하는 공개용 기호(앱 이외의 바이너리에 사용되는 기호)를 지정하려면 다음과 같은 기호 경로 형식을 사용해야 합니다.
    Srv*;<<여기에 기호 경로 입력>>
    기호 경로가 c:\symbols라면 위의 지침에 따른 경로는 다음과 같습니다.
    Srv*;c:\symbols
  7. 명령 창의 프롬프트에 !analyze –v를 입력하고 Enter 키를 누릅니다.

    WinDbg에서 스택 추적을 추출하는 방법의 예

    이전 스크린샷의 오류는 일부 DLL의 기호가 일치하지 않기 때문에 발생한 것입니다. 7단계에서 설명한 바와 같이 기호를 설정하면 오류 수를 줄일 수 있지만 오류가 앱의 DLL과 실행 파일에 해당할 경우에는 문제가 됩니다. 앱의 바이너리 파일과 관련하여 오류나 경고가 발생하는 이유는 디버거가 앱에 대한 올바른 기호를 찾지 못했기 때문입니다. 이 경우 기호가 저장되어 있는 위치의 올바른 경로를 확인하여 7단계의 설명에 따라 추가해야 합니다.
  8. 스택 추적은 명령 창에 다음과 같이 표시됩니다.

    WinDbg에 표시되는 스택 추적의 예


호출 스택을 보면 FaultoidEx.Engine.dll의 DivideByZero 함수에서 "0으로 나누기" 예외가 발생한 오류라는 것을 알 수 있습니다. 이는 1단계에서 사용한 오류 이름에 해당하므로 오류를 파악하고 수정 방법을 확인하는 데 도움이 됩니다.

JavaScript 예외

실패율, 그리고 가장 일반적인 JavaScript 예외는 JavaScript 기반의 앱에만 해당되는 사항입니다. JavaScript 예외의 경우 앱의 최신 버전에서 가장 많이 발생하는 15개 오류가 표시됩니다. 다른 오류보다 많은 수의 JavaScript 오류를 목록에 표시하는 이유는 원격 분석 데이터를 분석한 결과 JavaScript 예외가 다른 크래시보다 자주 발생하는 것으로 나타났기 때문입니다. 이렇게 JavaScript 예외에 해당하는 오류를 더 많이 표시하면 크래시나 실행 중단과 동일한 방식으로 앱의 품질을 높이는 데 도움이 됩니다.

자주 발생하는 JavaScript 예외를 보여 주는 보고서의 예

기본적으로 먼저 가장 많이 발생하는 JavaScript 예외에 해당하는 오류 5개의 목록을 표시합니다. [Show All](모두 표시] 단추를 클릭하면 이 목록이 확장되면서 15개 오류가 표시됩니다.

JavaScript 예외의 오류 이름에 대한 예는 다음과 같습니다.

WinRT error_8007007E_msappx://Contoso.ContosoApp8wekyb3d8bbwe/ContosoApp/program.js!scenario1Run

JavaScript 예외의 경우 오류 이름은 다음과 같이 정의됩니다.

  • ErrorTypeText(WinRT 오류)
  • ErrorNumber(8007007E)
  • Filename_FunctionName(program.js!scenario1Run)

JavaScript 예외에 대한 스택 추적

다음 단계에 따라 오류와 관련한 JavaScript 예외의 원인을 확인할 수 있습니다.

  1. 앱과 관련한 오류(JavaScript 예외) 이름 옆에 있는 [Download](다운로드) 링크를 클릭합니다.
  2. 원하는 위치에 .cab 파일을 저장합니다.
  3. 이 파일에는 이름이 ErrorInfo로 시작하는 파일(ErrorInfo 파일)이 있습니다. 이 파일을 원하는 위치에 추출하여 저장합니다.
  4. 3단계에서 선택한 위치에서 메모장을 사용하여 ErrorInfo 파일을 엽니다.
  5. 이 ErrorInfo 텍스트 파일에는 앱에서 오류와 관련한 스택 추적이 포함되어 있습니다. 다음은 이 파일의 예입니다.
    ErrorInfo 파일의 예

이 예에서는 정의되지 않은 함수 때문에 오류가 발생했습니다. 오류의 원인이 된 호출 스택도 ErrorInfo 파일에 포함되어 있습니다.

결론

품질을 파악하고 개선하는 노력은 성공적인 앱을 개발하는 데 있어 필수적인 요건입니다. 앱을 개선하는 데 필요한 유용하고 실용적인 정보를 제공하는 품질 보고서를 고안한 것도 이 때문입니다. 이러한 보고서는 개선 항목의 우선 순위를 정해 스토어에 게시된 앱의 업데이트를 신속하게 제공하는 데 도움이 될 것이라 확신합니다.

분석 포털에서 품질 보고서와 기타 보고서 사용 경험을 알려 주시기 바랍니다.

- Venkat