숫자는 ‘무엇’을, 사용성 테스트는 ‘왜’를 보여준다

분석 데이터는 무슨 일이 일어나는지는 정확히 보여줘요. 가입 2단계에서 60%가 이탈한다는 식으로요. 하지만 왜 그러는지는 끝내 알려주지 않죠. 사용성 테스트가 메우는 틈이 바로 여기예요. 실제 사용자가 제품을 쓰는 모습을 관찰하면, 그 ‘왜’가 비로소 보이거든요.

사용성 테스트란?

사용성 테스트는 실제 사용자를 대표하는 사람들이 제품으로 진짜 과제를 수행하는 모습을 관찰해, 제품이 어디서 도움이 되고 어디서 발목을 잡는지 알아내는 리서치 방법이에요. 핵심은 "이 디자인이 마음에 드세요?"라고 묻는 게 아니라, 실제로 써볼 때 무슨 일이 벌어지는지 지켜보는 거예요.

국제 표준 ISO 9241-11은 사용성을 "특정 사용자가 특정 목표를 얼마나 잘 달성하는가"로 정의하고, 세 가지 기준을 제시해요.

• 효과성(Effectiveness): 과제를 끝까지 완료할 수 있는가?
• 효율성(Efficiency): 얼마나 많은 노력이 드는가?
• 만족도(Satisfaction): 그 경험은 어떻게 느껴지는가?

사용성 테스트는 이 세 가지를 현미경으로 들여다보는 일이에요. 이 방법을 널리 알린 야콥 닐슨(Jakob Nielsen)은 이렇게 말했어요.

최고의 UX를 만들려면, 사용자가 말하는 것이 아니라 실제로 하는 행동에 주목하세요.

진짜 가치는 사람들이 말하는 것과 실제로 하는 것 사이의 틈에 있어요. 사용자는 어떤 화면이 "괜찮다"고 말하면서도, 눈앞에서 엉뚱한 버튼을 세 번이나 누르는 식이죠. 그 행동이 바로 데이터예요.

유저 테스트 vs 사용성 테스트, 무엇이 다를까?

여기서 용어가 헷갈리기 시작해요. "유저 테스트"는 사용자가 관여하는 거의 모든 리서치를 두루 가리키는 느슨한 표현이에요. 반면 "사용성 테스트"는 그 안에서 사용 편의성에 초점을 둔 구체적인 방법이고요.

실무에서 더 쓸모 있는 구분은, 각각이 답하는 질문이에요.

즉 "유저 테스트"에는 인터뷰, 설문, 콘셉트 테스트, 그리고 사용성 테스트가 모두 포함될 수 있어요. 누군가 "유저 테스트하자"고 하면 구체적으로 어떤 테스트를 의도한 말인지 한 번 되물어볼 필요가 있어요. 이걸 만들지 말지를 검증하려는 건가요, 아니면 이미 만든 걸 사람들이 쓸 수 있는지 확인하려는 건가요? 둘은 다른 연구예요.

왜 사용성 테스트를 해야 할까?

안 하면 결국 추측에 기대게 되니까요. 잘 설계된 사용성 테스트는 이런 걸 줘요.

• 구체적이고 고칠 수 있는 문제: "온보딩이 헷갈린다"가 아니라 "5명 중 4명이 '계속' 버튼이 비활성처럼 보여서 놓쳤다".
• 논쟁을 끝내는 근거: 누군가의 의견은 실제 사용자가 헤매는 사실과 현상 앞에서 힘을 잃어요.
• 더 싼 수정 비용: 출시 전에는 디자인 한 번 손보면 끝나는 일이, 출시 후에는 이미 익숙해진 사용자들, 쌓여 있는 데이터, 재작업까지 함께 딸려 와요.
• 오래 남는 공감: 우리가 생각한 "당연한" 기능에서 사용자가 막히는 걸 보고 나면, 팀의 사고방식이 바뀌는 계기가 돼요.

언제 하면 좋을까?

사용성 테스트는 한 번 통과하면 끝나는 관문이 아니에요. 여러 지점에 어울려요.

• 초기 프로토타입에서: 코드를 짜기 전에 종이나 클릭형 목업으로 먼저 테스트해요.
• 출시 직전에: 치명적인 문제를 아직 싸게 고칠 수 있을 때 잡아요.
• 운영 중인 제품에서: 데이터 분석 결과 설명되지 않는 이탈을 발견했을 때 그 원인을 찾아요.
• 꾸준히: 강한 팀일수록 1년에 한 번 크게가 아니라, 작게 자주 테스트해요. 이게 정말 중요한 포인트예요.

모더레이티드 vs 언모더레이티드

세션을 진행하는 방식은 크게 두 가지인데, 각각 잘하는 게 달라요.

모더레이티드는 진행자가 실시간으로 과제를 안내하면서, 참여자가 멈칫한 바로 그 순간 "방금 왜 망설이셨어요?"라고 물어볼 수 있는 방식이에요. 결과만이 아니라 이유를 이해해야 할 때 제격이죠. 언모더레이티드는 그 깊이를 속도와 맞바꿔요. 과제가 단순하고 데이터 포인트를 빠르게 많이 모으고 싶을 때 유용해요.

사용성 테스트는 어떻게 진행될까?

모더레이티드 세션은 보통 같은 흐름을 따라요.

1. 목표를 정해요. 무엇을 알고 싶은지 정해요. 가령 "신규 사용자가 도움 없이 첫 데이터 소스를 연결할 수 있는가?" 같은 거죠.
2. 과제를 써요. 목표를 현실적인 시도로 바꾸되, 지시문이 아니라 시나리오처럼 표현해요.
3. 참여자를 모집해요. 실제 사용자와 닮은 사람을 찾아요. 생각보다 적은 인원이면 충분해요(아래에서 다룰게요).
4. 세션을 진행해요. 과제를 주고, 조용히 지켜봐요. 무엇을 하는지, 어디서 망설이는지, 무슨 말을 하는지 시간 기록과 함께 노트해요.
5. 분석하고 공유해요. 관찰을 패턴으로 묶고, 문제의 우선순위를 매겨, 팀이 실제로 움직일 리포트로 만들어요.

그런데 애써 얻은 인사이트가 가장 많이 묻혀 버리는 곳이 바로 이 마지막 단계예요. 노트는 문서 여기저기 흩어지고, 녹화는 아무도 다시 보지 않고, 인사이트는 정작 고칠 사람에게 닿지 못하죠. Interbang 같은 도구는 바로 이 지점을 위해 만들어졌어요. 태그한 노트가 녹취록의 그 순간과 계속 연결되고, 성공률 같은 측정치는 자동으로 집계돼서, 관찰이 번거로운 정리 없이 곧장 행동으로 이어져요.

참여자는 몇 명이 필요할까?

대부분이 예상하는 것보다 적어요. 닐슨과 랜다우어(Nielsen & Landauer)의 잘 알려진 연구에 따르면, 약 5명만 테스트해도 한 흐름의 사용성 문제 중 대략 85%가 드러난다고 해요. 그 이상은 수확 체감 구간이라, 여섯 번째 사람을 모집하기보다 찾은 문제를 고치고 다시 테스트하는 편이 나아요. (구체적인 계산과 ‘5명으로 부족한 경우’는 참여자 수를 다룬 글에서 더 깊이 다뤄요.)

자주 묻는 질문

사용성 테스트는 A/B 테스트와 같은 건가요? 아니에요. A/B 테스트는 실제 트래픽으로 두 버전을 비교해 어느 쪽 지표가 더 좋은지 봐요. 사용성 테스트는 소수의 사람이 한 버전을 쓰는 모습을 지켜보며 왜 잘 되거나 안 되는지를 이해해요. 답하는 질문이 다르고, 함께 쓰면 잘 어울려요.

녹음이 꼭 필요한가요? 도움은 되지만 필수는 아니에요. 시간 기록을 곁들인 꼼꼼한 노트만으로도 큰 문제는 충분히 찾을 수 있어요. 녹화나 녹취록은 순간을 다시 보고 근거를 공유하게 해주는 보너스예요.

한 세션은 얼마나 걸리나요? 모더레이티드 세션은 보통 참여자 한 명당 30~60분을 추천해요. 피로가 쌓이기 전에 현실적인 과제 몇 개를 시도하기에 적당한 길이죠.

누가 진행해야 하나요? 약간의 구조만 갖추면 팀의 누구나 할 수 있어요. 많이 배우는 데 전담 리서처가 꼭 필요한 건 아니에요. 명확한 목표, 현실적인 과제, 그리고 조용히 지켜보는 절제만 있으면 돼요.