LINE DEVELOPER DAY 2021에서 화창득 님이 발표하신 Quality in Use - Meet the Needs of Users 세션 내용을 옮긴 글입니다.
안녕하세요. Fintech QA 팀의 화창득입니다. 다양한 제품이 쏟아져 나오는 요즘 시대의 사용자들은 끊임없이 서비스의 품질을 판단하며 이용 여부를 결정합니다. 사용자들의 판단 기준은 계속해서 달라지기 때문에 서비스를 제공하는 입장에선 꾸준히 사용 품질을 확보하는 것이 중요한 요소가 되었습니다. 스스로를 품질광이라 생각하는 저는 '사용자의 요구를 만족시켜라'라는 부제로 'quality in use(이후 사용 품질)'의 정의와 측정 방법, 그리고 사용 품질을 확보하기 위해 고민했던 과정과 결과를 공유하려고 합니다. 서비스 품질을 판단할 때 어떤 부분을 어떤 방식으로 수치화하는지, 그리고 수치화한 지표를 어떻게 분석해 사용 품질을 확보하고 있는지 이야기해 보겠습니다.
사용자 관점에서의 품질
공급자와 사용자는 서로 관점의 차이가 있다는 것은 여러 이론이나 논문, 책 등을 통해 널리 알려진 사실입니다. 이를 QA 측면에서 다시 이야기해 보자면, 공급자가 자신의 관점에서 제품의 품질을 높이는 데 집중하는 동안 사용자는 다른 관점에서 품질을 판단하고 있다고 말할 수 있는데요. 공급자와 사용자 사이에서 발생하는 이 차이가 서비스 품질에 영향을 주기 때문에 QA는 왜 이런 입장 차이가 발생하는지 원인을 파악하고 이해한 후 사용자 관점에서 서비스 품질을 측정하고 개선 방향을 찾을 수 있어야 합니다. 저희는 이런 관점에서 서비스 품질을 개선하는 방법을 찾아보고자 했습니다.
블랙박스 테스트는 사용자 관점인가
그에 앞서 저희가 수행하는 테스트에 관한 얘기를 잠깐 해보려고 합니다. 사용자 관점이라는 말은 UX나 UI에서 자주 사용하는 말인데요. QA에서는 사용자 관점에서 블랙박스 테스트1를 수행하고 있습니다. 저희가 진행하는 테스트 중 가장 큰 비중을 차지하는 이 테스트에서는, 사용자 관점에서 UX 및 비즈니스 플로를 분석한 후 리스크를 파악하고 테스트 시나리오를 작성, 수행합니다. 테스트 중에 사용성 개선점도 제안합니다.
하지만 블랙박스 테스트가 정말 사용자 관점이냐고 묻는다면 그렇게 생각하지 않는다고 대답할 것 같습니다. 블랙박스 테스트가 왜 사용자 관점이 아니라고 생각하는지, 왜 공급자인 우리가 사용자 관점에서 테스트를 설계하거나 수행하는 게 어려운지 설명해 보겠습니다.
공급자는 의식적으로 서비스를 만든 목적과 서비스에 대한 기대를 염두에 두고 개발하고 테스트합니다. 반면 사용자는 무의식적으로 서비스와 기능의 일부를 사용합니다. 전체 시스템을 이해하고 있는 공급자는 '이 정도면 사용자가 충분히 편리하게 사용하겠지'라고 오해하며 사용자가 우리가 기대한 대로 시스템을 사용할 것이라고 예상합니다. 하지만 전체 시스템을 이해하고 있지 않은 사용자가 공급자가 기대한 대로 서비스를 사용하기란 쉽지 않습니다.
따라서 공급자 관점에서 판단하지 말고 사용자 관점에서 서비스를 어떻게 사용할지 예측해야 하는데요. 이게 말처럼 쉽지 않습니다. 앞서 말씀드린 이유에 더해 모든 사양을 알고 있는 상태에서 여러 번 테스트하면서 생긴 관성이 서비스의 문제를 인식하기 어렵게 만들기 때문입니다.
사용자의 실제 경험을 분석해야 한다
우리는 사용자 관점이라는 모호한 말을 하는 대신 사용자의 실제 경험을 분석해야 합니다. 이를 분석하기 위해 많은 이론이 나왔는데요. 그럼에도 사용자 관점에서 서비스의 품질을 측정하는 일은 매우 어렵습니다. 기본적으로 측정 결과에는 어느 정도 주관적으로 해석될 여지가 있기 마련이고, 데이터를 수집하는 게 어려우며, 고객에 따라 사용 방법이 다르거나 서비스를 이용하는 고객이 바뀌는 등 고객 자체가 변동 요인이기 때문입니다. 그동안 다양한 방법이 제시됐지만 아직 온라인 서비스에 대한 명확한 기준이 있다고 말하기는 어렵습니다.
이에 사업적 성공 여부나 활성 사용자(AU, active users) 수와 같은 수치로 서비스의 품질을 판단하기도 하는데요. 이런 결과론적인 수치로 서비스의 품질을 판단하는 것에는 한계가 있습니다. 특히 품질에 대한 가이드를 제공해야 하는 QA 입장에서는, 결과론적인 수치로 품질을 측정하면 개선 방법을 찾기 어렵기 때문에 이런 수치에서 의미를 찾기가 어려웠습니다.
사용 품질이란
우리는 테스트를 더 의미 있게 만들기 위해서 실제로 사용자가 사용하면서 느끼는 품질을 파악해야 한다고 생각했습니다. 이를 위해 조사하는 과정에서 사용 품질(quality in use)이라는 용어를 접하게 됐고, 꽤 오래전부터 QA 영역에서 연구돼 왔다는 것을 알게 됐습니다.
사용 품질은 우리가 자주 사용하는 사용성(usability)과 혼동할 수 있는데요. 사용성이 사용 편의에 초점이 맞춰져 있다면 사용 품질은 좀 더 총체적인 관점에서의 사용 품질을 의미합니다. 아래 슬라이드와 같이 ISO/IEC 표준에서는 이미 사용 품질의 다섯 가지 특성을 정의하고 측정 방법론에 관해 설명하고 있었습니다.
이와 같이 표준이 있다는 것을 알게 된 뒤 관련 자료를 조사해 봤는데요. 참고할 만한 자료가 많이 나오지는 않았습니다. 측정 방법까지 표준화돼 있었기에 쉽게 진행할 수 있을 것이라고 생각했지만, 앞서 말씀드린 바와 같이 서비스 품질을 측정하는 것이 어려웠기 때문인지 학문 관점에서의 연구만 계속되고 있었습니다.
아래는 사용 품질 활동을 언제 수행하는지 나타낸 그림입니다. 보시는 바와 같이 사용 품질 활동은 서비스 출시 전에 측정하는 것이 아니라 서비스를 출시한 이후에 수행하는 활동입니다. 서비스 배포 후 사용자들이 느끼는 품질을 측정하고 측정 결과를 분석 및 반영해서 개선한 버전을 다음 배포로 내보내는 활동입니다.
위 그림의 마지막 단계에 물음표가 있는 이유는 이 활동의 주체가 누가 되어야 하는지를 아직 정의하지 못했기 때문입니다. QA가 품질 관점에서 측정을 주도하더라도 그 이후에 진행되는 분석 및 개선은 어떤 한 팀의 역량만으로는 수행하기 어려운 작업이기 때문에 역할을 분담해야 할 텐데요. 측정에서 개선까지의 절차를 어떻게 수립하고 어떤 부서가 어떤 역할을 맡아야 할지에 대해서는 현재까지도 계속 고민하며 만들어 나가고 있습니다.
사용 품질 측정 절차 수립
앞서 말씀드린 활동으로 이루고자 하는 목표는, 사용자 관점에서의 품질을 주기적으로 측정하고, 그 결과를 이용해 서비스를 개선해서, 결과적으로 고객을 행복하게 만드는 것입니다. 이 목표를 달성하기 위해 다음 그림과 같은 절차를 수립해서 진행해 나갔습니다.
먼저 사용 품질에 대해 연구했습니다. 연구 결과를 바탕으로 측정 방법을 정의했고, LINE Pay와 태국 뱅크 서비스를 파일럿 서비스로 지정해서 앞서 정의한 방법으로 주 단위로 품질을 측정했습니다. 그리고 측정한 결과를 바탕으로 측정 방법 및 측정 지표를 개선해 나갔습니다.
측정할 때 어려웠던 점으로는 표준에 모호한 부분이 있고 참고할 수 있는 자료와 측정하기 위한 기반 데이터가 충분하지 못하다는 점이었는데요. 모호한 표준은 그 의미를 해석해 지표를 선정해서 실제로 측정해 가며 저희 방식대로 정의하는 것으로 해결했고, 부족한 자료와 데이터는 현재 사용할 수 있는 데이터로 할 수 있는 방법을 찾는 것으로 해결했습니다.
사용 품질 측정 방법 정의
사용자 만족도 조사와 사용자의 사용 패턴을 분석하기 위한 일반적인 방법으로 설문(questionnaire)과 실제 사용자의 행위를 기록하면서 분석하는 사용자 테스트가 있습니다. 둘 다 매력적인 방법이지만 각각 하나의 학문 분야로 확립돼 연구될 정도로 난도가 높고 비용이 높은 작업이기에 짧은 주기로 반복해서 진행하기에는 매우 어려운 방법이었습니다.
이에 주기적으로 측정하고 분석할 수 있는 API 로그와, 가능하다면 Google Analytics(GA) 및 VOC 데이터를 기반으로 사용 품질을 측정해 보기로 했습니다. 하지만 로그의 목적은 운영 중 발생한 시스템 문제를 빠르게 파악하기 위해서였기 때문에 일반적인 API 로그로 사용자의 행위를 분석하기는 어려웠습니다. 그래서 아래 그림과 같이 사용자 행동의 흐름과 전체 API를 매핑했습니다.
데이터를 살펴보니 API 호출 수와 사용자 행동 흐름의 통계 데이터가 일치하지 않았습니다. 이에 사용 통계를 태스크 단위로 파악하기 위해 오랜 시간 개발 팀과 협업하면서 데이터 추출 방식을 검토했습니다.
또한 GA 데이터는 비즈니스 분석과 관련이 있는 부분에만 적용돼 있었기 때문에 사용자의 서비스 사용을 분석하기 위해서 GA 데이터도 추가했습니다. GA는 그 자체로도 꽤 쓸만한 도구이긴 한데요. 각 태스크에서 발생한 다양한 오류는 API 로그 데이터에 모이기 때문에 만약 사용자의 서비스 사용을 분석하려고 하신다면 이와 같이 API 로그 통계 데이터를 같이 보시는 것을 추천합니다.
사용 품질 측정 지표 기준 정의
위와 같이 측정 방법을 검토하고 보완해 나가면서 측정 지표들의 기준을 정의하기 시작했습니다. 아래 표는 저희 팀에서 정의한 가장 최신 버전의 측정 지표 기준입니다.
ISO/IEC 표준을 기반으로 결과만 봐서는 의미를 알기 어려운 항목이나 보여주기 식의 지표는 배제하고 가치 있다고 판단한 지표로만 좀 더 간략하게 구성했습니다. 참고로 이 표는 현재 저희가 보유한 데이터만으로 설계한 것인데요. 사용자의 정성적인 부분과 관련된 지표들은 추후 보완해 나갈 예정입니다.
그럼 각 지표의 의미와 측정 방법에 대해 간략히 말씀드리겠습니다.
Effectiveness
첫 번째는 Effectiveness로 사용자가 자신의 서비스 이용 목적을 잘 달성했는지를 측정하는 지표입니다. 아래 그림과 같이 LINE 친구 송금 버튼이 눌린 총 횟수를 100%로 보고 그중 몇 %가 최종 송금까지 완료하는지 비율을 측정합니다. 이때 각 단계마다 사용자가 송금을 포기하는 비율을 파악해서 사용자가 포기하게 된 원인을 찾습니다. 가장 기본이 되는 지표이며, 사용자의 목표 달성을 저해하는 요소를 찾아 개선하는 것이 주안점인 지표입니다.
Effectiveness는 전체 시도 횟수 대비 성공한 횟수의 비율로 표현합니다. 위 예시의 경우 태스크 완료 비율이 0.312, 즉 전체 시도 중 31%가 성공한 것으로 측정됐습니다.
이 수치는 서비스 및 태스크의 특성(예를 들어 온라인 서비스인지 오프라인 서비스인지)에 따라 목표로 삼는 품질의 기준이 달라질 수 있습니다. 참고로 오프라인 결제에서는 Effectiveness 지표가 80% 이상 나왔습니다. Effectiveness 지표를 통해 다음 세 가지를 확인할 수 있습니다.
- 각 단계별 이탈률
- 사용자가 최종 단계까지 가지 못한 각 단계별 오류 내용(API 응답 로그에서 파악 가능)
- 서비스 및 주변 상황의 변경이 사용자의 목표 달성에 끼치는 영향
Efficiency
두 번째는 Efficiency입니다. 이 지표는 사용자가 목표를 달성하는 데 걸린 시간을 측정해서 사용자가 빠르게 목표를 달성하는 데 걸림돌이 된 요인을 찾는 것이 목적입니다. 만약 사용자가 목표를 달성하는 데 예상보다 오래 걸렸다면 어느 부분에서 오래 걸렸는지 현상을 파악하고 개선할 수 있습니다. 보통 이 지표에는 서버나 프런트엔드의 성능보다는 복잡하고 비효율적인 UX나 핀테크 서비스의 특성상 사용자에게 꼭 제공해야 하는 리스크 안내 관련 내용이 더 큰 영향을 미칩니다.
이 지표는 실제 걸린 시간 대비 우리가 생각하는 이상적인 시간의 비율로 나타낼 수 있습니다. 여기서 이상적인 시간이란, 내부적으로 사용자 체감 성능이라고 설정한 프런트엔드 성능의 목표치(2초)를 서버 응답까지 갔다 오는 단계의 개수에 곱해서 계산합니다. 이상적이라고 표현한 이유는 사용자가 해당 화면을 보고 구조를 파악하며 어떤 선택을 할지 고르는 시간을 포함하지 않은, 가장 빠른 시간을 나타낸 것이기 때문입니다. 이 지표를 통해 어느 단계에서 가장 많은 시간이 걸렸는지 확인해서 그 단계에 사용자를 불편하게 만드는 요인이나 사용자를 혼란스럽게 만드는 요인이 있는지 확인하고 개선할 수 있습니다.
위 예시에서 해당 지표는 0.426으로 이상적인 시간일 때의 42% 정도인 수치가 나왔습니다. 친구를 선택하는 데 가장 많은 시간을 쓰고 있다는 것을 알 수 있는데요. 이 결과를 참고해 다양한 UX 개선점을 파악해서 이 태스크에서 소요되는 시간을 줄일 수 있습니다(이 결과를 참고해 처리한 것은 아니지만, LINE Pay에서는 이미 '대화방 송금'이라는 기능으로 친구를 쉽고 빠르게 선택할 수 있는 방법을 제공하고 있습니다). 또한 API 수행 로그가 남기 때문에 서버 성능도 확인하고 개선할 수 있으며, 변경 사항이 사용자에게 어떻게 미치는지도 꾸준히 확인할 수 있습니다.
Freedom from Risk
세 번째는 Freedom from Risk 지표로, 사용자가 리스크로부터 얼마나 자유로운지를 측정하는 지표입니다. ISO/IEC 표준에는 비즈니스 리스크 분석부터 시스템 장애까지 다양한 측정 항목이 기술돼 있는데요. 표준에 나온 기준과 방법이 다소 모호하다고 생각했기 때문에 이 지표의 측정 항목을 선정하기가 어려웠습니다. 이에 현실적으로 접근해 보기로 하고, 사용할 수 있는 데이터에 기반해서 서비스 이용을 시도한 전체 사용자 대비 한 번이라도 오류를 경험한 사용자의 비율로 지표를 구성했습니다.
사용자는 송금 버튼을 눌렀을 때 알 수 없는 오류가 발생하면 큰 불안감을 느낍니다. 이 오류에는 시스템에서 발생한 일시적인 오류는 물론 서비스에서 정의한 오류도 포함되는데요. 공급자 관점에서 정의한 오류는 예상한 오류이기 때문에 주의 깊게 모니터링하지 않는 경향이 있지만, 사용자 입장에서는 무슨 오류든 빈번하게 발생하면 서비스의 품질이 낮다고 판단할 수 있습니다.
수집된 지표를 통해 오류 메시지의 패턴을 분석하고 사용자가 어느 단계에서 오류가 발생했는지를 확인합니다. 기 정의된 오류라도 발생 빈도가 늘어난다면 UX 개선을 검토해 볼 수 있습니다. 위 예시의 결과 수치를 보면 사용자의 99.2%가 오류 없이 송금에 성공했는데요. LINE Pay는 이미 안정적이고 사용자에게 익숙한 서비스이기 때문에 사용성의 오류나 시스템 오류가 발생하는 경우가 매우 적은 편입니다.
Satisfaction
마지막으로 Satisfaction입니다. 저희가 확보한 로그로 측정하기 가장 어려웠던 지표로, 현재 사용자의 가장 적극적인 의사 표현이라고 할 수 있는 VOC(voice of customer)의 통계 데이터로 수치를 산정하고 있습니다. 이 지표는 전체 사용자 대비 VOC 개수에서 해당 태스크 사용자 대비 VOC 개수의 비율로 산출합니다. 단순히 VOC 비중으로만 산출하는 게 아니라 서비스 사용자와 작업을 시도한 사용자를 모수로 사용해서 수식을 구성합니다. 산출된 수치의 의미를 사용자가 송금 과정에서 즐거움을 느낀다거나 매우 만족하고 있다고 해석하기는 어렵지만, 불편함이나 큰 문제 없이 서비스를 사용하고 있는 사용자라고는 해석할 수 있습니다. 아래 예시의 경우에는 86%의 사용자가 불편함이나 큰 문제 없이 서비스를 사용하고 있다고 해석할 수 있습니다.
저희는 VOC로 수집한 데이터 중 특히 문의에 더 집중하기로 했습니다. 앞서 말씀드린 Effectiveness나 Efficiency 지표 산출 과정에서 문제가 있는 것으로 나타났던 부분들이 문의로 들어올 가능성이 있고, 사용자의 실제 피드백을 통해 문제의 원인을 파악해 볼 수 있기 때문이기도 합니다. 또한 VOC에서 '불만 사항'보다는 '문의'가 조금 더 적극적인 사용자의 피드백이라고 판단했습니다.
일단 현재 바로 사용할 수 있는 데이터를 이용해 측정하고 있는데요. 아직 Satisfaction이라는 지표를 제대로 측정하기에는 조금 부족하다고 생각합니다. 향후 계속 연구를 진행하면서 운영과 관련된 다양한 팀들과 상의하며 개선해 나갈 예정입니다.
현황 및 향후 계획
현재 위에서 설명한 네 가지 지표로 서비스 품질을 측정하고 있고, 태스크 별로 점수를 매겨 주 단위로 품질 개선 여부를 파악하고 있습니다. 아직 초기 단계라서 각 지표 결과의 평균으로만 계산하고 있는데요. 향후 각 지표의 신뢰도에 가중치를 두거나 각 지표 간의 연관성을 파악해 수식을 개선할 예정입니다. 여기서 지표 간의 연관성이란 한 지표가 좋아지면서 다른 지표들에게 영향을 주는 형태를 의미하며, 앞으로 데이터가 조금 더 쌓이면 그 관계가 더욱 명확하게 나타날 것이라고 생각합니다.
아래 그림을 보면 LINE Pay 친구 송금의 현재 사용 품질 점수는 64.5입니다. 이 수치가 낮다거나 높다고 판단하기는 어렵습니다. 또한 서비스나 태스크의 특성에 따라 이 수치를 유지하거나 더 높이는 것이 어려울 수도 있습니다. 하지만 저희는 계속 이 점수를 높여가는 것을 목표로 하고 있습니다.
저희는 사용 품질을 측정하고 검토하는 과정에서 각 측정 방식이나 지표를 꾸준히 개선하고 있으며, 이와 같은 활동을 실제 서비스 개선으로 연결시켜 사용 품질 분야에서 참고할 만한 사례를 만드는 것을 최종 목표로 삼고 있습니다.
- 블랙박스 테스트(Black-box testing): 소프트웨어 검사 방법 중 하나로 소프트웨어의 내부 구조나 작동 원리를 모르는 상태에서 소프트웨어의 동작을 검사하는 방법입니다. 제품의 특징, 요구 사항 등 대외적으로 공개된 사양만을 바탕으로 입출력이 올바른지와 같은 제품이 수행해야 할 역할에 초점을 맞춰 수행하는 테스트입니다. 따라서 테스트할 때 코드나 내부 구조 및 개발 노하우와 같은 정보가 필요하지 않습니다.