SUS 점수 산출과 사용성 측정 — 계산법·해석 기준·백분위, 과업 성공률·소요 시간·오류율

개념

왜 숫자로 바꾸는가

레슨 2에서 관찰과 발화를 기록했다. 그것만으로도 개선 근거는 된다. 그런데 관찰 기록에는 두 가지 한계가 있다.

첫째, 비교할 수 없다. "이번 개선이 효과가 있었나"에 답하려면 개선 전후를 같은 자로 재야 한다. 둘째, 의사결정 회의에서 한 줄로 못 쓴다. 경영진 보고서에 관찰 기록 10페이지를 넣을 수는 없다. 모듈 45(레슨 4)에서 제품 지표를 목표와 신호와 지표로 잇는 법을 배웠는데, 사용성도 같은 처리가 필요하다.

그래서 숫자를 만든다. 단, 숫자가 관찰을 대체하는 것이 아니라 관찰에 손잡이를 다는 것 이다. SUS 점수 61은 그 자체로 아무것도 설명하지 않는다. "61이고, 그 원인은 교환 진입점을 4명이 못 찾은 것"이 완성된 문장이다.

SUS — System Usability Scale

SUS는 John Brooke가 1986년에 만든 10문항 설문이다. 30년 넘게 살아남은 이유는 세 가지다. 짧고(10문항, 2분), 제품 종류를 가리지 않으며, 비교할 수 있는 기준점이 축적되어 있다.

10문항은 긍정문과 부정문이 번갈아 나온다. 각 문항은 5점 척도(1 = 전혀 동의하지 않음, 5 = 매우 동의함)다.

홀수 문항이 긍정, 짝수 문항이 부정 이라는 규칙이 채점의 전부다. 문항 순서를 바꾸거나 부정문을 긍정문으로 고쳐 쓰면 이 규칙이 깨져 점수가 틀린다. 번역은 다듬을 수 있어도 긍정·부정의 배치는 건드리지 않는다.

SUS 채점법

1) 홀수 문항(1,3,5,7,9) : 응답값 - 1
2) 짝수 문항(2,4,6,8,10): 5 - 응답값
   → 각 문항이 0~4 범위가 된다
3) 10개를 모두 더한다    → 0~40
4) 2.5를 곱한다          → 0~100

응답이 [4, 2, 5, 1, 4, 2, 5, 2, 4, 2] 인 참가자를 계산해 보자.

문항  응답  변환                     기여
 1     4    4-1                       3
 2     2    5-2                       3
 3     5    5-1                       4
 4     1    5-1                       4
 5     4    4-1                       3
 6     2    5-2                       3
 7     5    5-1                       4
 8     2    5-2                       3
 9     4    4-1                       3
10     2    5-2                       3
                              합계 = 33
                       SUS = 33 × 2.5 = 82.5

코드로 옮기면 실수가 줄어든다.

def sus_score(responses: list[int]) -> float:
    """responses: 문항 1~10의 응답값(각 1~5). 길이 10."""
    if len(responses) != 10 or not all(1 <= r <= 5 for r in responses):
        raise ValueError("문항 10개, 각 1~5 값이어야 한다")
    total = 0
    for i, r in enumerate(responses, start=1):
        total += (r - 1) if i % 2 == 1 else (5 - r)
    return total * 2.5
 
 
def sus_mean(all_responses: list[list[int]]) -> float:
    """참가자별 점수를 각각 낸 뒤 평균낸다. 문항별로 먼저 평균내면 안 된다."""
    scores = [sus_score(r) for r in all_responses]
    return sum(scores) / len(scores)
 
 
assert sus_score([4, 2, 5, 1, 4, 2, 5, 2, 4, 2]) == 82.5

sus_mean의 주석이 중요하다. 문항별 평균을 먼저 내고 그걸 채점하면 안 된다. 참가자마다 점수를 낸 뒤 평균을 낸다. 표본이 작을 때 이 둘의 차이가 눈에 띄게 벌어진다.

SUS 점수를 해석하는 법 — 68과 백분위

SUS의 가장 큰 오해는 "100점 만점의 백분율"로 읽는 것 이다. 70점이면 "70% 정도 괜찮다"로 읽히는데 틀렸다. SUS는 백분율이 아니라 미리 정해진 척도 위의 값 이다.

Jeff Sauro가 500건 이상의 연구를 모아 산출한 기준이 사실상의 해석 표준이 됐다.

여기에 백분위와 등급 곡선이 붙는다. 자주 인용되는 기준점은 다음과 같다.

70점이 50 백분위 라는 점을 기억하면 충분하다. 즉 70점은 "평균 수준"이지 "괜찮은 편"이 아니다. 이 비선형성 때문에 점수 몇 점 차이가 백분위로는 크게 벌어진다 — 68에서 74로 6점 오르면 백분위는 50에서 70 부근으로 이동한다. 리포트에는 점수와 백분위·등급을 함께 쓴다.

[나쁜 보고]  SUS 71점입니다. 나쁘지 않네요.
[좋은 보고]  SUS 71점(참가자 8명, 표준편차 12.4). 업계 평균 68을 약간 웃돌지만
             백분위로는 중간 수준(C)입니다. 개선 전 61점(D~F 구간)에서 올랐고,
             주 원인은 교환 진입점 이동입니다.

SUS를 쓸 때의 규칙

• 과업을 끝낸 직후에 받는다. 며칠 뒤 이메일로 보내면 기억이 아니라 인상을 측정하게 된다
• 10문항을 전부 받는다. 문항을 빼면 0~100 환산이 성립하지 않는다
• "시스템"이라는 단어를 대상에 맞게 바꿔도 된다 — "이 앱", "이 관리자 화면". 다만 한 연구 안에서는 통일한다
• 참가자별 SUS와 과업 성공률을 함께 본다. 과업을 다 실패했는데 SUS가 80인 참가자가 있다면, 과업을 성공한 줄 알았거나 예의상 점수를 준 것이다. 그 자체가 발견이다
• SUS 하나로 A안과 B안의 우열을 판정하지 않는다. 소수 표본에서 SUS 차이 5점은 노이즈 범위다

SUS는 사용성 전반의 인상 을 재는 도구지 특정 화면의 문제를 짚는 도구가 아니다. 어디가 문제인지는 과업 지표가 말한다.

과업 지표 네 가지

성공률은 3단계로 기록하고 2단계로 보고한다.

기록: 성공 / 도움받아 성공 / 실패
보고: 성공률 = 성공 ÷ 전체     (도움받아 성공은 성공에 넣지 않는다)
      단, "도움받아 성공 2명"을 각주로 남긴다

소요 시간은 성공한 참가자만 으로 평균을 낸다. 실패한 참가자는 중단 조건에서 잘린 시간이라 실제 소요 시간이 아니다. 대신 실패자 수를 함께 적는다.

[틀린 보고] 교환 신청 평균 소요 시간 5분 12초
            (실패한 4명의 '8분 중단' 시간이 평균에 섞여 있다)
 
[맞는 보고] 교환 신청: 성공 1/5, 성공자 소요 시간 6분 40초,
            실패 4명(중단 조건 8분 도달 3명, 본인 포기 1명)
            → 사실상 "거의 아무도 못 한다"가 결론이다

오류율을 쓰려면 무엇이 오류인지 목록을 먼저 만든다. "잘못 눌렀다"는 관찰자마다 다르게 센다.

[이 연구에서 오류로 세는 것]
E1 목표와 무관한 메뉴에 진입했다가 되돌아 나온 경우 (1회)
E2 입력 검증에 걸려 다시 입력한 경우 (1회)
E3 브라우저 뒤로 가기를 사용한 경우 (1회)
E4 같은 버튼을 반응이 없다고 판단해 2회 이상 누른 경우 (1회)
※ 스크롤, 화면 확대는 오류로 세지 않는다

표본 5명의 숫자를 어디까지 주장할 수 있나

가장 자주 사고가 나는 지점이다. 5명 중 4명이 실패하면 성공률은 20%다. 이 20%를 "우리 사용자의 20%가 성공한다"로 읽으면 틀렸다. 표본이 5명이면 참값의 범위가 아주 넓다. 실제로는 5%일 수도 50%일 수도 있다.

그래서 이렇게 말한다.

[주장해도 되는 것]
"5명 중 4명이 교환 진입점을 찾지 못했다"          — 관찰한 사실
"이 화면에 진입 경로 문제가 있다"                  — 반복 관찰에 근거한 결론
"개선 후 같은 과업에서 5명 중 4명이 성공했다"      — 전후 관찰의 대비
 
[주장하면 안 되는 것]
"성공률이 20%다"                                   — 모집단 비율로 읽힌다
"개선으로 성공률이 60%p 올랐다"                    — 표본 5명으로는 폭을 못 잰다
"통계적으로 유의하게 개선됐다"                     — 유의성 검정을 한 적이 없다

요령은 비율 대신 분수로 쓰는 것이다. "20%"가 아니라 "5명 중 1명"이라고 쓰면 읽는 사람이 표본 크기를 함께 본다. 퍼센트는 분모를 숨기기 때문에 소수 표본에서 특히 위험하다. 모집단 비율을 주장해야 하는 상황이라면 UT가 아니라 로그 데이터나 A/B 테스트(레슨 7)로 가야 한다.

사용성 지표 대시보드 한 장

여러 지표를 한 장으로 묶으면 개선 전후를 같은 자로 잴 수 있다.

                         개선 전(5명)      개선 후(5명)
과업 1 교환 신청
  성공(도움 없이)          1/5               4/5
  도움받아 성공            1                 1
  성공자 평균 소요         6분 40초          1분 55초
  오류 평균                4.2회             1.0회
  주 이탈 지점             마이페이지        (없음)
 
과업 2 쿠폰 적용
  성공(도움 없이)          4/5               5/5
  성공자 평균 소요         1분 10초          1분 05초
 
SUS 평균                   61.0 (SD 12.4)    78.5 (SD 8.1)
SUS 백분위/등급            하위권 (D~F)      약 70 백분위 (B-)

표준편차(SD)를 같이 적는 이유는 평균만으로는 갈라진 반응을 숨기기 때문 이다. 5명의 SUS가 [95, 90, 85, 25, 10]이면 평균은 61이지만 실제로는 "되는 사람은 아주 잘 되고 안 되는 사람은 전혀 안 된다"는 뜻이다. SD가 크면 참가자 집단을 쪼개서 다시 본다.

실무에서 왜 필요한가

개선 제안이 기각되는 가장 흔한 이유는 "효과를 모르겠다" 다. 사용성 개선은 매출처럼 직접 세는 숫자가 없어서, 지표가 없으면 우선순위 싸움에서 항상 진다. SUS와 과업 성공률은 그 싸움에 가져갈 수 있는 최소한의 숫자다.

또 숫자는 회귀를 잡는다. 릴리스마다 같은 과업으로 SUS를 받아 두면, 새 기능이 기존 흐름을 망가뜨렸을 때 점수가 떨어진다. 기능 회귀 테스트는 있는데 사용성 회귀 테스트는 없는 조직이 대부분이고, 그래서 화면은 릴리스마다 조금씩 복잡해진다.

실습 과제

과제 1 — SUS 채점기 만들고 검증하기 (15분)

위의 sus_score 함수를 직접 작성하고 세 가지 경계 입력으로 검증한다.

전부 최고 평가: [5,1,5,1,5,1,5,1,5,1] → 100.0 이 나와야 한다
전부 최악 평가: [1,5,1,5,1,5,1,5,1,5] → 0.0 이 나와야 한다
전부 중립(3):   [3,3,3,3,3,3,3,3,3,3] → 50.0 이 나와야 한다

세 결과가 나오지 않으면 홀수·짝수 처리가 뒤바뀐 것이다. 부정 문항에 1점(전혀 동의 안 함)을 준 것이 좋은 평가 라는 점을 확인한다.

과제 2 — 지표 정의서 쓰기 (15분)

담당 제품의 핵심 과업 하나를 고르고, 네 지표의 정의를 이 팀에서만 통하는 수준으로 못 박는다.

• 성공 조건: 관찰자가 무엇을 보면 성공으로 치는가(화면·상태·데이터)
• 시간 측정 시작·종료 시점: 정확히 언제 스톱워치를 누르고 멈추는가
• 오류 목록: E1~E5로 열거. 오류로 세지 않는 것도 명시
• 중단 조건: 시간과 참가자 의사 표현 기준

과제 3 — 잘못된 보고 문장 고치기 (10분)

다음 보고 문장에서 문제를 찾아 고친다.

"UT 결과 과업 성공률 40%, 평균 소요 시간 3분 20초, SUS 71점으로
 양호한 수준입니다. 개선 후 재측정 시 성공률이 80%로 두 배 개선되었습니다."

자가 체크리스트

• SUS 10문항의 긍정·부정 배치를 알고, 홀수·짝수 변환 규칙을 정확히 적용해 0~100 점수를 낼 수 있다
• 참가자별로 점수를 낸 뒤 평균해야 하는 이유를 설명할 수 있다
• SUS 68이 평균이고 70이 약 50 백분위라는 기준으로 점수를 해석할 수 있다
• SUS를 백분율로 읽으면 안 되는 이유를 말할 수 있다
• 과업 성공률을 3단계로 기록하고 도움받은 성공을 성공률에서 빼서 보고할 수 있다
• 소요 시간 평균에 실패자를 넣지 않고, 실패자 수를 따로 적을 수 있다
• 오류로 세는 것과 세지 않는 것의 목록을 미리 정의할 수 있다
• 표본 5명의 결과를 분수로 쓰고, 모집단 비율·유의성 주장을 하지 않는다
• 평균과 함께 표준편차를 적어 갈라진 반응을 드러낼 수 있다

흔한 실수

• 부정 문항 변환을 빠뜨린다. 전부 응답-1로 계산하면 나쁜 제품이 높은 점수를 받는다. 중립 응답이 50점이 나오는지로 즉시 검산한다.
• SUS를 백분율로 읽는다. 71점은 "71% 만족"이 아니라 "평균 근처, 약 50 백분위"다.
• 문항을 빼거나 순서를 바꾼다. 10문항·긍부정 교차가 환산식의 전제다. 번역만 다듬는다.
• 도움받아 성공한 참가자를 성공에 넣는다. 성공률이 부풀고, 개선 효과 판단이 뒤집힌다.
• 실패자의 중단 시간을 소요 시간 평균에 넣는다. 실패가 많을수록 평균이 나아 보이는 역설이 생긴다.
• 소수 표본의 결과를 퍼센트로 쓴다. 분모가 숨어 모집단 비율처럼 읽힌다. "5명 중 1명"으로 쓴다.
• 평균만 보고한다. SD가 크면 평균은 아무도 경험하지 않은 값이다.
• 숫자만 보고하고 원인을 안 쓴다. SUS 61 자체는 행동으로 이어지지 않는다. 어떤 과업의 어떤 이탈이 그 점수를 만들었는지 붙인다.

참고 자료

• MeasuringU — Measuring Usability with the System Usability Scale (SUS) — 채점 절차, 평균 68, 백분위·등급 곡선의 근거
• Usability.gov — System Usability Scale (SUS) — 10문항 원문과 채점 절차(미국 연방 정부 가이드)
• John Brooke, "SUS: A Quick and Dirty Usability Scale" (1996), in Usability Evaluation in Industry — SUS 원전. 원문 확인 권장
• Nielsen Norman Group — Success Rate: The Simplest Usability Metric — 과업 성공률의 정의와 부분 성공 처리
• 레슨 s5-m49-l02 — 세션 설계와 관찰 기록(여기서 만든 기록이 이 레슨의 입력이다)
• 레슨 s2-m45-l04 — HEART·Goals-Signals-Metrics로 품질과 제품 목표 잇기
• 레슨 s5-m49-l07 — 모집단 비율과 유의성이 필요할 때 가는 곳