어렸을 적 ‘크레이지 아케이드'라는 게임을 집에서 하고 싶어 다운 받아본 기억이 있습니다. 게임을 다운로드 하기 위해서는 우리 집 컴퓨터가 다운 받을 수 있는 환경이 되는지 안 되는지를 확인해야 했는데요, 이게 어쩌면 제 일생 가장 처음 컴퓨터와 관련된 기술 문서를 읽어본 경험이라고 말할 수 있겠네요.
여러분도 비슷하게 일생에 한 번쯤은 어떤 프로그램을 다운 받기 위해 누군가의 블로그를 발견해 잘 정리된 순서를 따라 하거나 그 프로그램의 홈페이지에 들어가 관련된 정보를 찾아 헤매본 적이 있을 것입니다. 슬프게도 관련된 정보를 도저히 찾을 수 없어 몇 시간째 구글링을 할 수도 있고요. 그렇기에 헛되이 시간을 보내지 않기 위해서는 잘 정리된 문서가 꼭 필요합니다.
놀랍게도 최근 B2B 비즈니스 분야에서도 사용자(고객사)와 원활하게 의사소통하기 위해서 우리가 흔히 말하는 ‘기술 문서 (혹은 개발 문서)'의 중요성이 대두되고 있습니다. 그렇다면 질문을 하나 던져볼게요.
“기술 문서는 누구의 관점에서 작성돼야 할까요?”
Cochl도 세상의 모든 소리를 이해할 수 있는 Sound AI인 Cochl.Sense를 개발하고 있고, 사용자들은 Cloud API 혹은 Edge SDK 형태로 Cochl.Sense를 사용하고 있습니다. 사용자들이 편리하게 우리의 기술을 이용할 수 있도록 도움을 드리는 차원에서 Cochl도 기술 문서가 작성된 개발자 센터를 운영하고 있습니다. ‘좋아, Cloud API와 Edge SDK에 대한 설명도 있고, 릴리즈 노트도 업데이트 잘하고 있으니 뭐 이 정도면 사람들이 알아서 잘 쓰겠지? 이 정도면 충분할 거야.’라는 우리의 오만과 편견을 최근에야 마주하게 되었습니다.
이번 시리즈는 Cochl이 어떻게 이 문제를 포착했고, 어떠한 방식으로 풀어나가는지에 대한 그 여정을 담고 있습니다. 첫 번째 아티클에서는 우리의 오만과 편견을 직면하게 된 사용성 평가 세팅 과정을 소개합니다. 
1. 사용성 평가 참가자 모집
Cochl에게 최근 몇 년은 Cochl.Sense의 기능이 점점 더 발전하고, 어떤 기술인지 궁금해하는 분들이 늘어가고 있는 시기로 사용자 유입을 늘리고 유지할 수 있도록 Cochl.Sense를 만들어 나가는 것이 중요했습니다. 그래서 우리는 사용성 평가를 통해 Cochl.Sense를 한 번도 사용해 본 적 없는 사용자도 아주 쉽게 사용하고 원하는 정보를 개발자 센터에서 찾을 수 있는지를 파악하고 싶었습니다.
먼저 개발팀과의 논의를 통해 구체적으로 ‘어떤’ 유형의 참가자들이 사용성 평가에 필요한지를 확인하고, 해당 요건에 맞는 사람을 찾기 위해 사용성 평가 참가자 모집 양식을 만들었습니다.
사용성 평가 참가 모집 양식을 하나씩 살펴보며, 각 요소에 대해 간단하게 설명하겠습니다.
•
참여자 조건
사용성 평가의 가장 중요한 부분 중 하나는 적합한 참가자를 선별하는 것입니다. 사용하고 있는 기술 스택, 회사가 속해있는 비즈니스 분야, 과제의 종류에 따라 어떤 ‘대상'이 필요한지는 천차만별입니다. 그렇기에 애초에 이 부분을 잘 기획하는 것이 원하는 사용성 평가 목적을 달성하는 데 큰 도움이 됩니다.
가령 Cochl의 경우 기술 문서가 크게는 Cloud API 부분과 Edge SDK 부분으로 나누어져 있고, 이번 사용성 테스트에서는 Cloud API를 집중적으로 다뤄보기로 했습니다. 그렇기에 JavaScript(Node.js), Java, Python 사용이 필수적이었고 기술 문서가 영어로 작성돼 영문 개발 문서에 익숙한 분들이 필요했습니다.
•
진행 방식
사용성 평가를 진행하는 방법은 오프라인과 온라인으로 나눌 수 있습니다. 각각의 장단점은 다르지만 Cochl의 경우 오프라인으로 진행해 보았습니다. 모든 분이 동일한 시간에 참석해 주셔야 한다는 시공간적 제약 조건이 붙지만, 실시간으로 Cochl 팀원들이 어떤 부분에서 문제가 발생하는지를 확인할 수 있고, 필요하다면 개입해 도움을 드릴 수 있기 때문입니다. 또한 같은 공간에서 커뮤니케이션을 진행하기에 어떤 문제가 발생한다면 그 문제를 가공된 형태로 받아들이지 않고, 원문 그대로 이해할 수 있기 때문에 문제를 직접 확인하고 기록하는 데 큰 도움이 되었습니다.
Cochl은 일회성으로 사용성 평가가 종료되었지만, 만약 동일한 참가자에 대해 연속적으로 사용성 평가 진행을 희망하시거나, 한 번에 많은 참가 대상을 원하시는 경우에는 온라인이 더 편리한 방법이 될 수 있습니다.
•
API 연동 경험
이번 사용성 테스트는 Cochl.Sense Cloud API의 사용성을 검증하는 데 목적을 두고 있기 때문에, 기존에 API를 연동해 본 경험이 중요했습니다. 경험의 유무와 더불어 API 연동 시 어떤 부분을 가장 중점적으로 고민하는지와 공식 사이트를 어느 정도의 빈도로 참고하는지에 대한 답변을 받아봤습니다.
위 질문에 대한 응답을 토대로 어떤 과제를 참가자들에게 전달할지, 어떤 부분을 위주로 응답을 확인할지 가이드라인을 세울 수 있었습니다.
•
결과 안내
약 20명 정도 되는 인원이 참가 의사를 밝혀주셨지만, 이번 Cloud API 사용성 평가에서는 내부의 우선순위를 반영하여 Python 사용자분들을 위주로 진행하게 되었습니다. 선정 결과는 1차로 메일을 통해 안내해 드리고, 메일 확인을 요청하는 문자를 발송했습니다. 최종적으로 6명의 참가자가 확정되었습니다.
2. 사용성 평가 과제 선정
앞서 말씀드렸던 모집 양식 작성과 더불어 진행해야 하는 일이 있습니다. 바로 사용성 평가에 필요한 과제 선정인데요, 과제의 난이도를 잘못 조절하게 된다면 사용성 평가가 너무 빨리 끝나거나 혹은 제시간에 마치지 못할 수 있는 위험이 있습니다. 그리고 목적에 부합하지 않는 과제를 선정하게 되면 설령 과제가 문제없이 종료된다고 하더라도, 원하는 결과를 얻지 못할 수 있습니다.
•
사용성 평가 과제
저희의 사용성 평가 목적은 ‘Cochl.Sense를 한 번도 사용해 본 적 없는 사용자도 아주 쉽게 사용하고, 원하는 정보를 개발자 센터에서 찾을 수 있는지 확인하자'였고, 대략 20~25분 정도의 시간을 할애하기로 계획하였습니다.
첫 번째 목적인 ‘충분히 쉽게 사용할 수 있는가'를 확인하기 위해 총 3가지의 과제를 만들었습니다.
Cochl.Sense Cloud API 설치하기
프로젝트 생성 후 스트리밍으로 소리 감지 및 결괏값 확인하기
프로젝트 생성 후 파일 업로드로 소리 감지 및 결괏값 확인하기제시된 3가지 과제를 수행하기 위해서는 기술 문서 페이지 내의 Cochl.Sense API 탭을 클릭한 후 Getting started를 참고해야 합니다. 그 과정에서 프로젝트 생성을 위해 Dashboard 사이트 가입 후 프로젝트 키를 발급받아야 합니다.
이를 통해 아래 내용을 확인할 수 있습니다.
1) Getting started가 잘 작성돼 있는지
2) 가입과 다운로드, 환경 세팅, 결과 확인의 과정이 부드럽게 이어지는지
3) 현재 버전에 맞지 않은 정보가 잘못 기재되어 있지 않은지
두 번째 목적인 ‘원하는 정보를 개발자 센터에서 찾을 수 있는가?'를 확인하기 위해 총 2가지의 과제를 만들었습니다.
Post action 기능 활성화를 통한 이메일 안내 받기
Sensitivity control 조절해 보기위 2가지 과제를 수행하기 위해서는 Cochl.Sense Cloud API 탭 내의 Getting started 하단의 Advanced configuration 부분과 Post Action 탭을 확인해야 합니다.
이를 통해 아래 내용을 확인할 수 있습니다.
1) 원하는 정보들이 기재되어 있는지
2) 원하는 정보를 찾기 어려웠다면, 그 이유는 무엇인지를 확인할 수 있습니다.
이후 개발팀과 논의해 더 추가로 제공돼야 할 과제가 있는지를 확인한 다음, 최종적으로 사용성 평가에 사용될 과제를 확정했습니다.
3. 사용성 시나리오 작성
사용성 평가가 전체적으로 어떤 그림으로 진행될지를 미리 구상하는 것은 굉장히 중요합니다. 만약 이 부분을 제대로 구상하지 않는다면 매끄러운 평가 진행이 불가능할뿐더러 각 영역에서 어떤 역할을 수행해야 하는지 혼란이 올 수 있기 때문입니다. 저희는 시나리오를 크게 3가지 영역으로 나눠 각 영역별 질문 내용과 요소 별 소요 시간을 정리해 두었습니다.
•
Introduction
Introduction은 참여자들의 긴장을 완화하고, 진행되는 사용성 테스트의 목적을 한 번 더 고지하고자 준비되었습니다. 회사 소개 > 참가자 소개 > API 관련 경험 소개로 구성되어 있습니다. 해당 과정은 약 20분 정도의 시간을 잡아뒀습니다.
•
과제 관련 질문
과제와 관련하여 사람들에게 던질 수 있는 질문을 총 5가지 준비해 뒀습니다. 가장 앞서 작성된 ‘시나리오 제공'은 상황에 따라 생략해도 무방하지만, 단순히 Cochl.Sense를 다운받아서 과제를 수행하기보다는 조금 더 상황에 몰입해서 사용하실 수 있도록 하기 위한 장치로 안내드렸습니다. 위 과정은 총 20~25분으로 잡아뒀습니다.
•
경험 공유
어쩌면 가장 중요한 부분일 수도 있는데요, 참가자의 진솔한 답변을 들어볼 수 있는 질문이기 때문입니다. 위 내용의 경우 단순한 단답식으로 끝나지 않고 여러 방면에서 참여자가 대답할 수 있게끔 여러 개의 꼬리 질문으로 구성돼 있습니다. 각 과정을 UX 측면 (설치 과정, 정보 탐색 과정 등)과 기술 측면 (기능 작동 여부, 에러 메세지)로 나눠 질문을 설계해보았습니다. 이는 우리가 후에 어떤 부분에 더 강점이 있고, 어떤 부분을 더 보완해야 할지에 대한 실마리를 얻을 수 있습니다. 이 과정은 20분으로 잡았습니다.
4. 사용성 테스트 날이 밝았습니다.
이렇게 만반의 준비를 하고 나니 왠지 모를 용기와 자신감이 솟았습니다. 너무 빨리 끝나는 거 아닐지 걱정 아닌 걱정을 해봤는데요, 정말 제 걱정대로 일이 풀렸을까요? 슬프게도 현실은 달랐습니다. 사용성 평가에 참여한 팀원들은 과제를 시작한 지 10분도 채 되지 않아 ‘왜 안 되지?’를 남발했거든요.
(재구성 된 우리의 대화)
•
갑자기 멈춘 와이파이
시작이 10분 채 남지 않은 상황에서 갑작스럽게 와이파이가 끊겼습니다. 평소에는 전혀 발생하지 않았던 문제가 왜 하필 오늘 이렇게 터졌을까요? 다행히 수 분 후에 자동으로 복구가 되었지만, 만약 와이파이가 재연결되지 않았다면 어떤 일이 펼쳐졌을지 생각만 해도 아찔했습니다.
•
참가자 별 환경 차이
사실 이 부분은 미처 생각하지 못했던 점이었는데요, 컴퓨터 기종에 따라 과제 수행 가능 여부가 달라졌습니다. 참여하신 분 중 Apple M2 칩이 장착된 맥북을 사용하신 분이 두 분 있었는데, 이 중 한 분의 경우 설치 과정에서 계속 에러가 발생했기 때문에, 회사에 보유하고 있던 다른 기종의 맥북을 급하게 전달해 드려야 했습니다. 그런 와중 다른 분들보다 늦게 시작하게 되셔서 과제를 수행하는 데 조금 더 오랜 시간이 걸렸습니다.
•
갑자기 되지 않는 기능
Post Action 관련 과제를 진행할 때 모든 것을 정확하게 세팅했음에도 불구하고 Post Action 리포트를 받는 데 시간 지연이 생기는 등 분명 잘 되었던 기능들이 되지 않는 상황도 펼쳐졌습니다. 다행히도 사용성 평가 내 발생한 모든 기능 관련 이슈들은 현장에서 대응할 수 있는 정도의 레벨이었지만, 만약 엔지니어 분들이 함께 자리해주지 않았다면 어떤 일이 펼쳐졌을까요?
기타 여기 남기지 않은 모든 참가자의 피드백들은 별도 시트에 기록하고, 다 함께 분류하였습니다. 그 결과 우리의 기술 문서가 가진 근본적인 문제들을 낱낱이 확인할 수 있었습니다. 그 중 일부만 공개드립니다.
‘지금은 기술 개발이 우선이니까, 이 정도면 문서를 읽어내는 데는 문제 없을 것 같아' 등의 말로 은근슬쩍 넘겼던 일이 결국은 대공사가 되어 저희에게 돌아왔습니다. 이 문제는 어떻게 해결할 수 있을까요?
다음 아티클에서는 저희가 마주했던 문제를 어떻게 해결하게 되었는지 구체적으로 하나씩 설명해 보도록 하겠습니다. 그럼, 다음 아티클에서 뵙겠습니다.