사용성·접근성 테스트 실전 — 휴리스틱 평가·사용성 테스트·SUS·ISO 9241·WCAG 2.2·스크린 리더·A/B 테스트

학습 목표

이 모듈 한 줄 요약 — "'그건 주관이죠' 를 무력화하는 법". "이 화면 쓰기 불편하다" 는 보고는 거의 항상 그 한마디로 닫힌다. 불편은 주관이 맞다. 다만 재는 절차를 정해 두면 재현 가능한 관찰이 되고, 그러면 더 이상 취향 싸움이 아니게 된다. 접근성은 아예 법으로 기준이 정해져 있기도 하다.

기능 결함은 재현 절차와 기대 결과가 있어서 다투기 쉽지 않다. 그런데 "이 화면 쓰기 불편하다"는 보고는 거의 항상 같은 말로 닫힌다 — "그건 주관이죠." 이 모듈은 그 문장을 무력화하는 방법을 다룬다. 불편은 주관이지만, 측정 절차를 정하면 재현 가능한 관찰이 되고, 판정 기준을 정하면 결함이 된다. 휴리스틱 평가의 심각도 등급, 사용성 테스트의 과업 성공률, SUS 점수와 백분위, WCAG의 성공 기준 판정이 전부 그 장치다.

모듈 16(레슨 7·11)에서 접근성과 사용성의 개념을 한 번 훑었다. 이 모듈은 거기서 멈춘 지점 — "그래서 몇 명에게, 무슨 과업을, 어떻게 시키고, 결과를 어떤 숫자로 바꿔 리포트하는가" — 부터 시작한다. 7개 레슨은 하나의 흐름이다. 전문가 혼자 빠르게 훑는 휴리스틱 평가(레슨 1)로 시작해, 실제 사용자를 데려와 관찰하는 세션 설계(레슨 2)로 넘어가고, 관찰을 숫자로 바꾸는 SUS와 사용성 지표(레슨 3)를 익힌다. 그 숫자가 무엇을 근거로 정당한지는 ISO 9241-11과 9241-210(레슨 4)이 제공한다.

후반부는 접근성과 실험이다. WCAG 2.2의 성공 기준을 한 항목씩 판정하는 절차와 한국형 웹 콘텐츠 접근성 지침(레슨 5), NVDA·TalkBack을 직접 켜고 검증 시나리오를 도는 실습 (레슨 6), 그리고 A/B 테스트의 품질을 검증하는 법(레슨 7)이다. 마지막 레슨이 이 모듈에 있는 이유는 분명하다. 사용성 개선안은 대부분 A/B 테스트로 판정되는데, 그 실험 자체가 표본비 불일치나 다중검정으로 오염되어 있으면 QA가 잡아낸 사용성 결함이 "데이터상 효과 없음"으로 기각된다. 실험 데이터의 신뢰성도 QA의 검증 대상이다.

이 모듈을 관통하는 문장은 하나다. "불편하다"는 의견이지만 "10명 중 7명이 3분 안에 완료하지 못했다"는 결함 보고다.

완료 후 할 수 있는 것

• Nielsen의 10가지 휴리스틱을 점검표로 바꿔 혼자서도 12시간 안에 한 화면의 사용성 문제를 목록화하고, 04 심각도 등급을 근거와 함께 부여할 수 있다
• 평가자 3~5명의 결과를 중복 제거·합의 조정으로 통합하고, 발견율이 평가자 수에 따라 어떻게 변하는지 설명할 수 있다
• 사용성 테스트 세션의 과업 시나리오를 목표·성공 조건·중단 조건이 있는 형태로 설계하고, 사고발화를 유도하며 진행자가 하지 말아야 할 말을 구분할 수 있다
• SUS 10문항을 정확히 채점해 0~100 점수로 바꾸고, 평균 68과 백분위·등급 곡선을 근거로 "이 점수가 좋은 점수인가"를 판정할 수 있다
• 과업 성공률·소요 시간·오류율·이탈 지점을 정의하고, 표본이 작을 때 숫자를 어디까지 주장할 수 있는지 선을 그을 수 있다
• ISO 9241-11:2018의 사용성 정의(효과성·효율성·만족도, 사용 맥락)를 검증 기준 문장으로 옮기고, ISO 9241-210:2019의 인간 중심 설계 활동을 개발 프로세스의 어느 단계에 붙일지 정할 수 있다
• WCAG 2.2의 성공 기준을 한 항목씩 적합/부적합/해당 없음으로 판정하고, 2.1 대비 추가된 9개 기준과 제거된 4.1.1 Parsing을 구분해 설명할 수 있다
• 한국형 웹 콘텐츠 접근성 지침(KS X OT0003:2022, KWCAG 2.2)의 33개 검사항목으로 점검표를 만들고, 법적 의무 근거를 댈 수 있다
• NVDA와 TalkBack을 직접 조작해 포커스 순서·레이블·대체 텍스트·라이브 리전 결함을 재현 절차와 함께 보고할 수 있다
• A/B 테스트의 표본 크기·기간·다중검정·표본비 불일치(SRM)를 점검해 실험 결과를 믿어도 되는지 판정할 수 있다

채용시장에서의 위치

국내 채용 공고에서 이 영역은 두 갈래로 나타난다. 하나는 공공·금융·교육 도메인의 "웹 접근성 인증 대응" 이다. 장애인차별금지법 제21조와 지능정보화 기본법 제46조에 따라 웹 접근성이 법적 의무이고, 공공기관 발주 사업에는 접근성 품질인증이 산출물로 걸린다. 이 자리에서는 WCAG·KWCAG 검사항목을 항목 번호로 말할 수 있고 스크린 리더로 직접 재현할 수 있는 사람을 찾는다. 자동 도구 점수만 읽을 줄 아는 사람과, "6.1.2 초점 이동과 표시 위반, NVDA에서 모달 열린 뒤 포커스가 배경 본문으로 빠집니다"라고 쓸 수 있는 사람의 격차가 크다.

다른 하나는 플랫폼·커머스 기업의 "프로덕트 QA / UX 리서치 겸업" 이다. 공고 문구는 "사용자 관점의 품질 개선", "UT 운영 경험", "지표 기반 개선 제안"처럼 나온다. 여기서는 SUS나 과업 성공률 같은 숫자를 실제로 돌려본 경험, 그리고 A/B 테스트 결과를 그대로 믿지 않고 실험 설계를 의심해 본 경험이 차별점이 된다. 면접에서 "사용성 이슈를 어떻게 설득했나요"라는 질문에 "디자이너와 얘기해서 고쳤다"가 아니라 "5명 세션에서 4명이 환불 진입점을 못 찾았고, 같은 과업의 성공률이 20%였다. 개선 후 80%로 올랐고 SUS가 61에서 78로 올라 백분위 기준 D에서 B+가 됐다" 라고 답하면 대화의 층위가 달라진다.

자격증으로는 ISTQB Foundation Level Specialist의 Certified Tester Usability Testing(CT-UT) 이 이 영역의 공식 체계다. 국내 응시자는 많지 않지만 실러버스 자체가 사용성 위험 식별, 접근성 위반의 심각도 분류, 사용성·UX·접근성 표준 인용, 평가 결과를 비전문 이해관계자에게 설명하기 같은 항목으로 구성되어 있어 이 모듈의 학습 지도로 그대로 쓸 수 있다. 의료기기 도메인이라면 IEC 62366-1의 사용적합성 공학(모듈 40 레슨 3)이 같은 뿌리에서 갈라진 규제 버전이다 — 거기서는 사용성 문제가 "불편"이 아니라 위해(harm) 로 분류된다는 점만 다르다.