개념
접근성과 무엇이 다른가
레슨 7에서 배운 접근성은 "장애가 있는 사용자도 서비스를 쓸 수 있는가"를 묻는다. **사용성(Usability)**은 그보다 넓은 질문이다 — "일반 사용자가 얼마나 쉽고, 효율적으로, 만족스럽게 목표를 달성할 수 있는가." 접근성이 "쓸 수 있는가(가능 여부)"라면, 사용성은 "잘 쓸 수 있는가(품질의 정도)"에 가깝다. 둘은 겹치는 부분도 있지만(예: 명확한 라벨은 둘 다에 도움이 된다), 사용성은 장애 여부와 무관하게 모든 사용자가 겪는 문제를 다룬다.
이건 모듈 1(레슨 1)에서 배운 품질의 두 축 중 **"쓰임에 적합함"**을 가장 직접적으로 겨냥하는 비기능 테스트다. 기능 테스트가 "명세 충족" 축을 보는 동안, 사용성 테스트는 "쓰임에 적합함" 축을 전담한다고 봐도 된다.
기능은 되는데 왜 문제인가
기능 테스트 관점: 회원가입 버튼을 누르면 계정이 생성된다 → 통과
사용성 테스트 관점: 회원가입 버튼이 어디 있는지 3분을 헤맸고,
비밀번호 규칙을 4번 실패한 뒤에야 알았다 → 문제기능적으로는 완벽하게 동작해도, 사용자가 그 기능에 도달하지 못하거나 도달하는 과정에서 좌절한다면 실질적으로는 실패다. 이건 모듈 1(레슨 2)에서 배운 "검증은 통과했는데 확인은 실패하는" 상황의 가장 흔한 실제 사례이기도 하다.
사용성을 측정 가능한 숫자로 만들기
모듈 2(레슨 2)에서 "테스트 가능한 요구사항"을 배웠다 — "직관적이어야 한다"는 모호한 요구사항을 구체적 기준으로 바꾸는 법이었다. 사용성도 똑같은 방식으로 측정 가능하게 만들 수 있다.
| 측정 지표 | 구체적 기준 예시 |
|---|---|
| 완료율(Success Rate) | 처음 쓰는 사용자 10명 중 몇 명이 도움 없이 과업을 완료하는가 |
| 소요 시간(Time on Task) | 회원가입을 완료하는 데 평균 몇 분이 걸리는가 |
| 오류 횟수(Error Rate) | 결제 과정에서 사용자가 되돌아가거나 잘못 입력한 횟수 |
| 주관적 만족도 | 과업 완료 후 "이 과정이 쉬웠나요?"를 5점 척도로 물어본 평균 점수 |
"UI가 직관적이다"라는 말 대신 **"처음 쓰는 사용자 5명 중 4명이 3분 안에 도움말 없이 주문 취소를 완료한다"**처럼 쓰면, 통과와 실패를 다투는 논쟁 없이 결과로 판단할 수 있다.
실제로 어떻게 확인하는가 — 사용성 테스트 세션
가장 신뢰할 수 있는 방법은 실제 사용자에게 직접 과업을 시켜보고 관찰하는 것이다.
1. 과업 제시: "이 앱에서 지난달 주문 내역을 찾아 환불을 신청해보세요"
2. 관찰: 사용자가 어디서 멈칫하는지, 어떤 메뉴를 잘못 누르는지
말없이 지켜본다(먼저 힌트를 주지 않는다)
3. 사고 구술(Think-Aloud): "지금 무슨 생각을 하고 계신가요?"를
물어 화면을 보며 드는 생각을 소리 내어 말하게 한다
4. 기록: 완료 여부, 소요 시간, 헤맨 지점을 기록한다QA가 스스로 화면을 써보는 것과 실제 사용자를 관찰하는 것은 전혀 다르다 — QA는 이미 그 기능을 너무 잘 알아서, 사용자가 겪는 낯선 혼란을 재현하기 어렵다. 이건 모듈 5에서 배운 탐색적 테스팅의 "새로운 시각으로 보기"와 비슷한 원리이지만, 사용성 테스트는 QA가 아니라 실제 사용자의 시각을 빌린다는 점이 다르다.
알파 테스트와 베타 테스트 — 누가, 어디서 확인하는가
사용성을 포함해 제품 전반에 대한 실사용 피드백을 얻는 대표적인 두 방법이다.
| 알파 테스트(Alpha Testing) | 베타 테스트(Beta Testing) | |
|---|---|---|
| 누가 | 회사 내부 인력(다른 팀 포함) | 실제 외부 사용자(선정된 그룹) |
| 어디서 | 개발 환경 또는 테스트 환경 | 실사용 환경에 가깝게(때로는 운영 환경) |
| 시점 | 정식 출시보다 훨씬 이전 | 출시 직전 |
| 목적 | 눈에 띄는 결함·사용성 문제를 조기에 거르기 | 다양한 실사용 조건에서 예상 못 한 문제 발견 |
알파 테스트는 모듈 4에서 배운 "일찍 찾을수록 싸다"는 원칙을 사용성에도 적용한 것이고, 베타 테스트는 QA가 통제할 수 없는 진짜 다양한 사용자·기기·네트워크 환경에서 나오는 문제를 잡는다. 둘 다 이 레슨에서 배운 사용성 테스트 세션의 "확장판"이라고 볼 수 있다 — 소수를 관찰실에서 보는 대신, 더 많은 사람을 더 현실적인 조건에서 지켜보는 것이다.
실무에서 왜 필요한가
"기능은 다 되는데 왜 이탈률이 높지?"라는 질문에, 기능 테스트 결과만으로는 답할 수 없다. 사용성 테스트는 이 질문에 직접 답한다 — 실제 사용자가 어디서 헤매는지 관찰하면 원인이 구체적으로 드러난다. 전담 UX 리서처가 없는 조직에서는, QA가 소수의 사용자를 모아 간단한 사용성 세션을 진행하는 것만으로도 출시 전에 큰 이탈 지점을 미리 잡아낼 수 있다. 다만 이건 정식 UX 리서치를 대체하는 게 아니라, "명백히 헤매는 지점"을 최소한으로 거르는 안전망이라는 걸 기억해야 한다.