ISO 9241-11·9241-210 — 사용성 정의와 인간 중심 설계를 검증 기준 문장으로 옮기기

개념

표준이 필요한 순간

레슨 1~3을 거치면 도구는 갖춰진다. 휴리스틱 10원칙, 과업 시나리오, SUS 점수. 그런데 이 세 가지를 다 들고 가도 막히는 회의가 있다.

QA   : 교환 신청을 5명 중 4명이 완료하지 못했습니다. 이건 결함입니다.
PO   : 요구사항 어디에 "5명 중 4명이 완료해야 한다"고 적혀 있나요?
QA   : ...적혀 있지는 않습니다.
PO   : 그럼 결함이 아니고 개선 제안이죠. 다음 분기에 보겠습니다.

이 대화에서 QA가 진 이유는 데이터가 부족해서가 아니다. 판정할 기준이 문서에 없었기 때문 이다. 기능 결함은 "명세와 다르다"로 판정되는데 사용성은 명세에 아예 없어서 "주관"으로 밀린다. ISO 9241 시리즈가 메우는 구멍이 정확히 여기다. 이 표준은 무엇을 사용성으로 부를지, 무엇을 측정으로 인정할지, 그 측정을 개발 프로세스의 어디에 끼울지 를 정의한다. 표준 자체가 결함을 찾아주지는 않는다. 대신 결함이라고 부를 수 있는 근거 문장의 틀 을 준다.

ISO 9241 시리즈의 지형

ISO 9241은 "인간-시스템 상호작용의 인간공학(Ergonomics of human-system interaction)"이라는 제목의 다부작 표준이다. 번호 구간마다 성격이 다르다.

이 레슨에서 쓰는 두 부의 서지 정보는 다음과 같다(1차 출처로 확인).

ISO 9241-11:2018  Ergonomics of human-system interaction —
                  Part 11: Usability: Definitions and concepts
                  제2판, 2018-03. 1998년 판을 대체한다.
 
ISO 9241-210:2019 Ergonomics of human-system interaction —
                  Part 210: Human-centred design for interactive systems
                  제2판, 2019. 2010년 판(제1판)의 minor revision 이다.

9241-210이 2010년 판의 "minor revision" 이라는 점이 실무에서 중요하다. 2010년 판을 근거로 만든 조직 프로세스 문서가 여전히 유효하고, 절 번호(4절 원칙, 6절 활동)도 그대로다. 표준 번호만 2019로 갱신하면 되는 경우가 많다.

ISO 9241-11:2018 — 사용성의 정의

2018년 판의 정의는 다음과 같다.

사용성이란, 특정 사용자가 특정 사용 맥락에서 특정 목표를 효과성·효율성·만족도를 갖고 달성하기 위해 시스템·제품·서비스를 사용할 수 있는 정도. (extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use)

한 문장이지만 검증 기준으로 옮길 때 쓸 부품이 다섯 개 들어 있다.

2018년 판에서 특히 강조된 문장이 하나 더 있다. 사용성은 제품의 속성이 아니라 사용의 결과(outcome of use) 라는 것이다. 이 한 줄이 QA의 태도를 바꾼다.

[속성으로 보는 관점]  "이 앱은 사용성이 좋다"      → 화면만 보고 판정한다
[결과로 보는 관점]    "이 사용자가 이 맥락에서
                       이 목표를 달성했다"          → 사용을 관찰해야 판정된다

즉 누가 무엇을 어디에서 하려 했는지를 고정하지 않으면 사용성은 측정 자체가 성립하지 않는다. 레슨 2에서 과업 시나리오에 목표·성공 조건·중단 조건을 넣으라고 한 이유가 여기서 표준 근거를 얻는다.

효과성·효율성·만족도를 지표로 내리기

세 축은 추상어지만, 레슨 3에서 이미 만든 지표들이 그대로 대응된다.

여기서 자주 틀리는 것이 효과성과 효율성을 한 지표로 섞는 것 이다. "평균 소요 시간 5분"에 실패자의 중단 시간이 섞여 있으면 두 축을 다 못 잰다. "효과성: 성공 5명 중 1명 / 효율성: 성공자 1명의 소요 시간 6분 40초, 오류 4.2회"처럼 분리해 적는다. 그리고 효과성이 나쁘면 효율성은 의미가 없다 — 아무도 못 하는 과업의 소요 시간은 해석할 값이 아니다. 보고 순서도 효과성 → 효율성 → 만족도로 고정한다.

사용 맥락(context of use) — 가장 많이 빠뜨리는 부품

사용 맥락은 네 가지로 쪼개서 적는다. 이 네 칸이 비어 있으면 테스트 환경이 사실상 "테스터 본인의 책상"으로 고정된다.

[사용 맥락 명세 — 4칸]
 
사용자(users)      누구인가. 숙련도·연령·보조기술 사용·업무 역할·해당 도메인 지식
과업(tasks)        무엇을 달성하려는가. 빈도와 중요도
장비(equipment)    무슨 기기·OS·브라우저·화면 크기·입력 장치·네트워크
환경(environment)  물리(밝기·소음·이동 중·한 손)와 사회·조직(시간 압박·감독·규정)

실제로 작성하면 이런 모양이 된다.

[사용 맥락 명세 — 보험 청구 모바일 웹]
 
사용자    50~70대 가입자 본인 또는 가족. 앱 설치 경험 적음. 확대 배율 사용 다수.
          보험 용어 지식 낮음(자기부담금·비급여 구분 못 함 전제)
과업      영수증 사진 첨부해 실손 청구 1건 제출. 연 1~3회 수행. 실패 시 콜센터 유입
장비      Android 11~15 / iOS 16~18, 5.5~6.7인치, 기본 브라우저, LTE 포함
환경      병원·약국에서 서 있는 상태, 한 손 조작, 화면 반사 있음, 진료 대기 중 시간 압박

이 문서가 있으면 테스트 환경 선정이 논쟁거리가 아니라 파생물 이 된다. "왜 최신 플래그십만 쓰지 않느냐"는 질문에 "사용 맥락 명세의 장비 칸이 5.5인치와 LTE를 포함한다"로 답할 수 있다. 모듈 17(레슨 5)의 실기기·에뮬레이터 선택도 이 명세에서 근거를 얻는다.

사용성 요구사항 문장 만들기 — 판정 가능한 형태

이제 부품을 조립한다. 판정 가능한 사용성 요구사항은 여섯 칸이 채워진 한 문장이다.

[틀]
(사용자)가 (사용 맥락)에서 (과업)을 수행할 때,
(효과성 기준) / (효율성 기준) / (만족도 기준) 을 만족해야 한다.
 
[예시 — UR-USA-012]
50~70대 신규 가입자가 병원 내 LTE 환경의 6.1인치 Android 기기에서
"영수증 첨부 실손 청구 1건 제출"을 수행할 때,
- 효과성: 안내 없이 제출 성공 비율이 대상자 8명 중 6명 이상
- 효율성: 성공자의 제출 소요 시간 중앙값이 5분 이내, 입력 오류 평균 2회 이하
- 만족도: SUS 평균 68 이상
을 만족해야 한다.

이 문장이 문서에 있으면 앞의 회의가 이렇게 바뀐다.

QA : UR-USA-012 효과성 기준 "8명 중 6명"에 대해 측정 결과 8명 중 2명입니다.
     요구사항 부적합입니다.
PO : ...기준을 완화할지 개선할지 결정하겠습니다.

논점이 "주관인가"에서 "기준을 바꿀 것인가 제품을 바꿀 것인가" 로 이동했다. 이것이 표준을 쓰는 실질적 이득이다.

기준 숫자를 정할 때의 요령은 세 가지다. 첫 릴리스에서는 절대 기준보다 기준선(baseline)을 먼저 잡고("현재 값 이하로 떨어지지 않는다"), 표본을 기준 문장 안에 넣고("8명 중 6명"처럼 분모를 적으면 레슨 3에서 본 소수 표본 과대 해석이 막힌다), 효율성 기준은 평균이 아니라 중앙값으로 쓴다(한 명의 초장시간 사례가 평균을 끌어올려 기준을 무력화한다).

ISO 9241-210 — 인간 중심 설계의 여섯 원칙

9241-210은 프로세스 표준이다. 4절이 원칙, 6절이 활동이다(2010년 판·2019년 판 공통 절 구조).

오른쪽 칸이 이 표의 요점이다. 원칙은 감사(audit) 질문으로 바꿔야 쓸 수 있다. "우리는 사용자 중심으로 개발한다"는 선언은 검증 대상이 아니지만, "지난 3개 스프린트에서 사용자가 참여한 세션의 날짜와 참가자 수"는 검증 대상이다.

네 가지 활동과 붙일 자리

6절의 활동은 네 개다(6.2~6.5). 각 활동에 QA가 요구할 산출물과 붙는 시점을 짝지어 둔다.

네 활동은 순서가 아니라 반복 고리 다. 6.5의 평가 결과가 6.2의 사용 맥락 이해를 고쳐 쓰게 만드는 것이 정상이다. 실제로 UT를 돌려 보면 "우리 사용자가 이런 줄 몰랐다"가 가장 큰 수확인 경우가 흔하다.

QA의 개입 지점은 두 곳으로 요약된다.

[앞쪽 — 6.2·6.3]  "판정 기준이 없는 사용성 요구사항"을 리뷰에서 막는다
                   → 모듈 43(레슨 2)의 테스트웨어 리뷰 기준과 같은 자리다
[뒤쪽 — 6.5]      평가를 실제로 돌리고 요구사항 판정표를 만든다

앞쪽을 건너뛰면 뒤쪽이 무력해진다. 기준 없는 평가 결과는 다시 "주관"으로 돌아간다.

9241-11 · 9241-210 · WCAG의 관계

세 표준이 겹치는 것처럼 보여서 혼동이 잦다. 역할이 다르다.

ISO 9241-11   무엇을 사용성으로 부르고 어떻게 측정으로 인정할지  → 측정의 정의
ISO 9241-210  그 측정을 개발 프로세스 어디에 끼울지              → 프로세스
WCAG 2.2      개별 화면이 접근성 성공 기준에 적합한지            → 항목별 적합 판정 (레슨 5)
ISO/IEC 25010 제품 품질 특성으로서의 usability 분류              → 품질 모델 (모듈 25 레슨 2)

WCAG는 적합/부적합이 항목 단위로 결정되는 판정 기준 이고, 9241-11은 측정값에 기준선을 걸어 판정하는 틀 이다. 그래서 WCAG는 "부적합 0건"을 목표로 쓸 수 있지만 9241-11 기반 요구사항은 언제나 숫자와 표본이 붙는다. 보고서에서 두 종류를 같은 표에 섞지 않는다. 의료기기라면 IEC 62366-1(모듈 40 레슨 3)이 같은 뿌리의 규제 버전으로, 거기서는 사용성 문제가 불편이 아니라 위해(harm) 로 분류된다.

실무에서 왜 필요한가

첫째, 공공·대기업 발주 사업에서 산출물로 요구된다. 제안서나 과업지시서에 "ISO 9241-210에 따른 인간 중심 설계 적용"이 들어가면, 검수 단계에서 사용 맥락 명세와 사용자 참여 기록, 평가 결과를 내야 한다. 표준 절 번호를 알면 산출물 목록을 역으로 도출할 수 있다.

둘째, 사용성 결함의 등급 싸움이 줄어든다. 효과성 위반(아무도 목표를 못 달성한다)·효율성 위반(느리다)·만족도 위반(짜증난다)은 심각도가 다른데, 구분하지 않으면 전부 "Minor - UI 개선"으로 묶인다. 세 축으로 나눠 적으면 효과성 위반은 기능 결함과 같은 등급으로 올라간다.

셋째, 검증 범위 협상의 언어가 된다. 사용 맥락 명세의 장비 칸을 근거로 하면 "명세에 없는 기기는 범위 밖"이라는 선이 생기고, 범위를 줄일 때도 명세를 고쳐야 하므로 결정이 기록에 남는다.

실습 과제

과제 1 — 사용 맥락 명세 4칸 채우기 (20분)

담당 제품의 핵심 과업 하나를 골라 사용자·과업·장비·환경 네 칸을 채운다. 규칙은 두 가지다.

• 각 칸에 "검증 가능한 값"을 최소 두 개 넣는다. "다양한 사용자"는 값이 아니다. "50~70대", "보조기술 사용자 포함"은 값이다
• 모르는 칸은 비워 두지 말고 "미확인 — 확인 방법"을 적는다. 예: "환경: 미확인 — CS 문의 로그에서 발생 시간대·기기 분포 추출 예정"

채우고 나서 현재 테스트 환경 목록과 대조한다. 명세에는 있는데 테스트하지 않는 조합이 몇 개인지 센다. 그 숫자가 이 과제의 결과물이다.

과제 2 — 판정 가능한 사용성 요구사항 3건 쓰기 (20분)

위 명세를 근거로 UR-USA 형식의 요구사항 3건을 쓴다. 효과성·효율성·만족도 세 축을 각각 최소 한 번씩 쓴다.

[체크]
□ 사용자와 사용 맥락이 문장 안에 있는가
□ 성공 조건이 관찰 가능한 화면·상태로 적혀 있는가
□ 기준 숫자에 분모(표본)가 붙어 있는가
□ 효율성 기준이 중앙값인가
□ 첫 릴리스라면 절대 기준 대신 기준선 방식인가

다 쓴 뒤 스스로 반론을 붙인다 — "이 기준은 어떻게 정당화하는가". 근거가 "느낌"이면 기준선 방식으로 바꾼다.

과제 3 — 9241-210 원칙 감사 질문표 (15분)

4.2~4.7 여섯 원칙을 우리 팀에 대고 묻는 감사 질문으로 바꾼다. 각 원칙당 질문 하나, 그 질문의 증거 파일 위치 를 함께 적는다. 예를 들어 4.3(사용자가 전 과정에 참여한다)은 "최근 3개 스프린트에서 실제 사용자가 참여한 세션이 몇 회, 몇 명인가"가 되고, 그 아래에 실제 증거 위치를 적는다. 없으면 "없음"이라고 적는다.

"없음"이 몇 개 나오는지가 팀의 현재 성숙도다. 전부 채워지는 팀은 드물다 — 목표는 채우는 것이 아니라 비어 있다는 사실을 문서화하는 것 이다.

자가 체크리스트

• ISO 9241-11:2018의 사용성 정의를 다섯 부품(사용자·목표·효과성·효율성·만족도·사용 맥락)으로 분해할 수 있다
• 사용성이 제품 속성이 아니라 사용의 결과라는 문장이 검증 방식에 주는 차이를 설명할 수 있다
• 효과성·효율성·만족도에 레슨 3의 지표를 각각 대응시킬 수 있고, 두 축을 한 지표로 섞지 않는다
• 사용 맥락을 사용자·과업·장비·환경 네 칸으로 적고, 그것을 테스트 환경 선정 근거로 쓸 수 있다
• 판정 가능한 사용성 요구사항 문장을 여섯 칸이 채워진 형태로 쓸 수 있다
• 기준 숫자에 표본(분모)을 붙이고, 효율성은 중앙값으로 쓰는 이유를 말할 수 있다
• ISO 9241-210의 여섯 원칙(4.2~4.7)을 증거를 요구하는 감사 질문으로 바꿀 수 있다
• 네 가지 활동(6.2~6.5)에 산출물과 붙는 시점을 짝지을 수 있다
• 9241-11·9241-210·WCAG·ISO/IEC 25010의 역할 차이를 구분해 설명할 수 있다

흔한 실수

• 표준 이름만 문서에 적고 기준 숫자를 안 쓴다. "ISO 9241-11을 준수한다"는 문장은 판정 불가다. 효과성·효율성·만족도 각각에 숫자와 표본이 붙어야 요구사항이다.
• 사용 맥락을 생략한다. 가장 흔하고 가장 비싸다. 맥락이 없으면 테스트 환경이 테스터의 책상으로 고정되고, 실사용 조건에서만 나는 결함이 전부 출시 후에 발견된다.
• 효과성이 나쁜데 효율성을 보고한다. 성공률 20%인 과업의 평균 소요 시간은 해석할 값이 아니다. 효과성 → 효율성 → 만족도 순서로 보고한다.
• 만족도를 효과성의 대체물로 쓴다. SUS가 75점이어도 핵심 과업 성공률이 낮으면 통과가 아니다. 참가자가 예의상 점수를 주는 일은 흔하다.
• 9241-210을 "디자이너의 문서"로 넘긴다. 6.3(사용자 요구사항 명세)에서 판정 불가한 문장을 막는 것이 QA의 리뷰 업무다. 여기서 빠지면 6.5의 평가 결과가 근거를 잃는다.
• 여섯 원칙을 선언문으로 적고 끝낸다. 원칙은 증거를 요구하는 질문으로 바꿔야 감사가 된다. 증거 위치가 없는 원칙은 지켜지지 않는다고 봐야 한다.
• WCAG 판정과 9241 측정을 한 표에 섞는다. 앞은 항목별 적합/부적합, 뒤는 표본이 붙은 측정값이다. 섞으면 둘 다 읽히지 않는다.

참고 자료

• ISO 9241-11:2018 — Usability: Definitions and concepts — 사용성 정의·효과성·효율성·만족도·사용 맥락의 원전. 제2판 2018-03
• ISO 9241-210:2019 — Human-centred design for interactive systems — 인간 중심 설계 원칙(4절)과 활동(6절). 2010년 판의 minor revision
• NIST CSRC Glossary — Usability — ISO 9241-11 정의를 인용한 공개 용어 정의
• ISO/IEC 25010 — 제품 품질 모델의 usability 특성. 모듈 25(레슨 2)에서 다룬다
• IEC 62366-1 — 의료기기 사용적합성 공학. 모듈 40(레슨 3), 같은 뿌리의 규제 버전
• 레슨 s5-m49-l03 — 여기서 만든 지표가 이 레슨의 효과성·효율성·만족도 칸을 채운다
• 레슨 s5-m49-l05 — 항목별 적합 판정 방식의 표준(WCAG 2.2)으로 넘어간다