휴리스틱 평가 — Nielsen 10원칙을 점검표로, 심각도 등급, 평가자 수와 결과 통합

개념

사용자 없이 하는 사용성 평가

사용성 테스트는 실제 사용자를 데려와야 한다. 섭외하고, 일정 잡고, 세션 돌리고, 기록을 정리하면 아무리 빨라도 며칠이다. 그런데 스프린트는 2주고, 디자인은 목요일에 확정되고, 금요일에 개발이 시작된다. 사용자를 부를 시간이 없을 때 쓰는 방법 이 휴리스틱 평가(heuristic evaluation)다.

정의는 단순하다. 평가자 몇 명이 각자 독립적으로 인터페이스를 훑으면서, 미리 정한 사용성 원칙(휴리스틱) 목록에 비추어 위반 사항을 찾아 기록하는 것. 사용자 대신 원칙이 기준이 된다. Jakob Nielsen이 1994년에 제안했고, 그가 정리한 10가지 원칙이 사실상의 표준 목록이 됐다.

이 방법의 성격을 정확히 알아야 한다.

모듈 5(레슨 4)에서 배운 "주의 깊은 관찰"의 사촌이다. 탐색적 테스팅이 기능이 맞는지 를 자유롭게 탐색한다면, 휴리스틱 평가는 쓰기 편한지 를 정해진 렌즈 10개로 훑는다. 렌즈가 정해져 있다는 점에서 탐색적 테스팅보다 체계적이고, 사용자가 없다는 점에서 사용성 테스트보다 약하다.

Nielsen의 10가지 휴리스틱 — 점검 질문으로 바꾸기

원칙을 그대로 읽으면 추상적이라 화면 앞에서 쓸 수 없다. 각 원칙을 "이 화면에 대고 던질 수 있는 질문"으로 바꿔야 점검표가 된다.

10개 원칙 자체는 1994년 이후 바뀌지 않았다. NN/g가 주기적으로 설명과 예시를 갱신할 뿐이다. 바뀌지 않았다는 사실이 이 목록의 강점 이다 — 웹이든 앱이든 키오스크든 같은 질문이 통한다.

실무에서 가장 자주 걸리는 세 가지

현장에서 휴리스틱 평가를 돌리면 1번·9번·3번에서 발견이 집중된다.

1번(상태 가시성) — 버튼을 눌렀는데 아무 반응이 없어서 두 번 누르고, 주문이 두 건 생긴다. 로딩 표시가 없거나 너무 늦게 뜨는 문제다. 이건 사용성 문제인 동시에 데이터 정합성 결함의 원인 이라 우선순위를 높게 받는다.

9번(오류 복구) — "오류가 발생했습니다. 관리자에게 문의하세요"는 세 가지를 다 어긴다. 무엇이 잘못됐는지(진단) 없고, 무엇을 하면 되는지(복구) 없고, 관리자가 누군지(연락처) 없다. 모듈 6(레슨 2)에서 좋은 결함 보고서의 조건을 배웠는데, 좋은 오류 메시지의 조건도 구조가 같다.

3번(통제와 자유) — 가입 플로우 3단계에서 뒤로 가면 1단계로 튕기고 입력이 다 날아간다. 사용자는 두 번째 시도에서 이탈한다.

[나쁨]  오류가 발생했습니다. (코드: E5023)
 
[좋음]  카드 결제에 실패했습니다 — 한도 초과입니다.
        · 다른 카드로 결제하기
        · 계좌이체로 변경하기
        장바구니는 그대로 유지됩니다.

심각도는 세 축으로 판단한다

문제를 찾는 것보다 어려운 일이 "이거 언제 고쳐야 하나" 에 답하는 것이다. 심각도 없이 30개짜리 목록을 던지면 개발팀은 아무것도 고치지 않는다. Nielsen의 0~4 등급을 쓴다.

등급을 매길 때는 감이 아니라 세 축 을 본다.

모듈 4(레슨 2)의 위험 기반 테스팅에서 위험을 "발생 가능성 × 영향"으로 쪼갰던 것과 같은 구조다. 여기에 지속성 축이 하나 더 붙는 이유는, 사용성 문제 중에 "처음엔 헤매지만 익히면 괜찮은 것"과 "1년을 써도 매번 걸리는 것"이 질적으로 다르기 때문이다.

문제: 장바구니에서 수량 변경 후 "적용" 버튼을 눌러야 금액이 갱신된다
      (누르지 않으면 이전 금액으로 결제된다)
 
빈도   : 높음 — 장바구니를 쓰는 거의 모든 사용자가 수량을 바꾼다
영향   : 높음 — 잘못된 금액으로 결제가 완료되고, 사용자는 결제 후에야 안다
지속성 : 높음 — 매번 걸린다. 버튼이 화면 밖으로 밀려 안 보이는 경우도 있다
→ 심각도 4 (출시 차단)  ※ 휴리스틱 1번·5번 위반

점수만 적지 말고 세 축의 근거를 한 줄씩 남긴다. 나중에 개발팀이 "이게 왜 4예요?"라고 물을 때 답이 되는 것은 숫자가 아니라 이 세 줄이다.

평가자는 몇 명이어야 하나

한 명으로는 부족하다. 아무리 숙련된 평가자도 혼자서는 전체 문제의 일부만 찾는다. 사람마다 눈에 띄는 것이 다르고, 같은 화면을 봐도 서로 다른 휴리스틱에 걸린다. NN/g는 3~5명이 독립적으로 평가할 것 을 권한다.

핵심은 "독립적으로" 다. 모여서 같이 보면 먼저 말한 사람의 관점에 나머지가 끌려간다. 각자 혼자 1~2시간 돌고, 각자의 목록을 만든 다음에 모인다.

[권장 구성 — 5명이 이상적이지만 3명이면 대부분의 값을 얻는다]
 
평가자 A  QA          기능 흐름에 밝다. 오류·경계 상황을 잘 본다
평가자 B  디자이너     일관성·계층·시각적 우선순위를 잘 본다
평가자 C  기획자       용어·정책·도메인 맥락을 잘 본다
평가자 D  개발자       기술적 제약과 구현 비용을 안다
평가자 E  도메인 초심자 "이게 뭐예요"라고 물을 수 있는 유일한 사람

E가 특히 값지다. 나머지는 제품을 너무 잘 알아서 초심자의 막막함을 재현하지 못한다. 모듈 16(레슨 11)에서 "QA는 이미 그 기능을 너무 잘 알아서 사용자의 혼란을 재현하기 어렵다"고 했던 그 문제가 휴리스틱 평가에도 그대로 있다.

결과 통합 — 중복 제거와 합의 조정

각자의 목록이 모이면 대개 세 부류로 나뉜다.

1. 여러 명이 똑같이 찾은 것 — 합쳐서 하나로 만든다. 여러 명이 찾았다는 사실 자체가 심각도의 근거가 된다
2. 한 명만 찾은 것 — 버리지 않는다. 혼자 찾은 문제도 진짜 문제일 수 있다. 다만 설명을 듣고 나머지가 동의하는지 확인한다
3. 평가자끼리 심각도가 갈리는 것 — 여기가 회의의 본론이다

심각도가 갈릴 때는 점수를 평균 내지 말고 세 축을 다시 묻는다. "빈도가 높다고 보신 이유가 뭔가요?" 대개 서로 다른 사용자를 상상하고 있었다는 게 드러난다 — 한 명은 신규 가입자를, 한 명은 매일 쓰는 관리자를 생각했다. 그러면 대상 사용자를 먼저 정하고 다시 매긴다.

[통합 시트 — 실제로 쓰는 형태]
 
ID   화면        위반 휴리스틱    문제 요약                      A B C D E  합의 심각도
H-01 장바구니    1, 5            수량 변경 후 적용 버튼 필요     4 4 3 4 4      4
H-02 주문 상세   2               "PENDING_APPROVAL" 노출         2 3 - 2 3      3
H-03 로그인      9               "오류(E5023)"만 표시            3 3 3 - 4      3
H-04 마이페이지  8               배너 4개가 주문 내역을 밀어냄   2 - 1 - 3      2
H-05 회원가입    3               3단계에서 뒤로 가면 입력 소실   4 3 4 4 4      4

"-"는 그 평가자가 못 찾았다는 뜻이다. 이 열을 남겨 두면 어떤 문제가 놓치기 쉬운지 가 보인다. H-04처럼 두 명만 찾은 항목은 다음 평가 때 점검표에 명시적으로 넣는다.

휴리스틱 평가의 한계를 먼저 말한다

리포트 앞에 한 문단을 쓴다. 이 방법은 전문가의 예측 이지 사용자의 실제 행동이 아니다. 위양성(실제로는 문제가 아닌 것)이 섞이고, 반대로 실제 사용자만 겪는 문제 — 도메인 지식 부족, 특정 기기, 중단된 상황에서의 조작 — 는 놓친다.

그래서 실무에서는 휴리스틱 평가로 큰 것을 먼저 걷어내고, 그 다음에 사용성 테스트를 한다. 사용성 테스트는 비싸므로, 명백한 문제로 세션 시간을 낭비하지 않게 하는 것이다. 레슨 2가 그 다음 단계다.

실무에서 왜 필요한가

현실의 QA 조직에서 사용성 이슈는 보고할 통로가 없어서 사라진다. 기능 결함 티켓에는 "기대 결과"를 적는 칸이 있는데, "이 화면 헷갈립니다"에는 적을 기대 결과가 없다. 그래서 QA는 알면서도 보고하지 않고, 운영에서 문의가 폭증한 뒤에야 다시 꺼내진다.

휴리스틱 평가는 이 통로를 만든다. "휴리스틱 9번 위반, 심각도 3, 평가자 5명 중 4명이 동일 지적" 은 기능 결함과 같은 형식의 문장이다. 티켓에 적을 수 있고, 트리아지 회의에 올릴 수 있고, 우선순위를 다툴 수 있다. 통로가 생기면 그 다음부터는 데이터가 쌓인다.

비용 대비 효과도 이유다. 디자인 시안이 나온 날 오후에 3명이 한 시간씩 쓰면 그날 안에 목록이 나온다. 이 시점에 잡힌 문제는 피그마 수정으로 끝나지만, 같은 문제를 출시 후에 잡으면 API 응답 구조까지 바뀌는 일이 생긴다. 모듈 4에서 배운 "일찍 찾을수록 싸다"는 원칙이 사용성에서 특히 크게 작동한다 — 화면 흐름은 코드보다 나중에 바꾸기 어렵기 때문이다.

실습 과제

과제 1 — 10원칙을 우리 제품 점검표로 (20분)

본인이 자주 쓰는 서비스(또는 담당 제품) 화면 하나를 고른다. 위의 10가지 질문 표를 그대로 두고, 각 원칙마다 그 화면에 맞춘 구체적 점검 질문을 하나씩 더 쓴다.

예) 휴리스틱 1(상태 가시성) — 일반 질문: 지금 무슨 일이 일어나는지 알려 주는가
    우리 화면 질문: 쿠폰 적용 버튼을 누른 뒤 금액이 갱신되기까지
                   진행 표시가 보이는가? 실패하면 실패했다고 말하는가?

10개를 다 채운 뒤, 그 화면을 실제로 1~2시간 훑으며 위반을 기록한다. 최소 8개를 찾는 것이 목표다.

과제 2 — 심각도를 근거와 함께 매기기 (15분)

과제 1에서 찾은 항목 중 5개를 골라 0~4 등급을 매긴다. 반드시 빈도·영향·지속성 세 줄을 함께 적는다. 다 매긴 뒤 스스로 점검한다 — 4를 두 개 이상 줬다면 정말 출시를 막을 만한 것인지 다시 본다. 등급 4가 남발되면 다음부터 아무도 그 숫자를 믿지 않는다.

과제 3 — 통합 시트 만들기 (15분)

동료 2명에게 같은 화면을 독립적으로 평가하게 한다(각자 30분이면 충분하다). 세 사람의 결과를 위의 통합 시트 형식으로 합친다. 합친 뒤 세 가지를 확인한다.

1. 세 명이 모두 찾은 문제는 몇 개인가
2. 한 명만 찾은 문제는 몇 개이고, 나머지 두 명이 동의하는가
3. 심각도가 2 이상 갈린 항목이 있는가 — 있다면 서로 어떤 사용자를 상상했는지 확인한다

자가 체크리스트

• 휴리스틱 평가와 사용성 테스트의 차이를 참가자·소요·산출물·약점 관점에서 설명할 수 있다
• Nielsen의 10가지 휴리스틱을 각각 화면에 던지는 질문 형태로 바꿔 말할 수 있다
• 심각도 0~4의 정의를 알고, 빈도·영향·지속성 세 축의 근거와 함께 등급을 매길 수 있다
• 빈도가 낮아도 복구 불가능한 결과면 심각도를 올려야 하는 이유를 설명할 수 있다
• 평가자 3~5명이 필요한 이유와 "독립적으로" 평가해야 하는 이유를 말할 수 있다
• 여러 평가자의 결과를 중복 제거·합의 조정으로 통합하고, 한 명만 찾은 항목을 어떻게 처리할지 정할 수 있다
• 심각도가 갈릴 때 평균을 내지 않고 대상 사용자를 먼저 맞추는 절차를 안다
• 휴리스틱 평가의 한계(위양성, 실사용자 고유 문제 누락)를 리포트에 명시할 수 있다

흔한 실수

• 혼자 평가하고 끝낸다. 한 명이 찾는 문제는 전체의 일부다. 최소 3명, 각자 독립적으로 돌린 뒤 통합한다.
• 모여서 같이 화면을 본다. 먼저 말한 사람의 관점에 나머지가 끌려가 독립성이 사라진다. 개별 평가 → 통합 회의 순서를 지킨다.
• 심각도 없이 목록만 던진다. 30개짜리 목록은 우선순위가 없으면 0개 수정으로 끝난다. 등급과 세 축의 근거를 붙인다.
• 심각도 4를 남발한다. 전부 재앙이면 아무것도 재앙이 아니다. 4는 정말로 릴리스를 막을 것에만 쓴다.
• 휴리스틱 번호만 적고 사용자에게 무슨 일이 생기는지 안 쓴다. "휴리스틱 2번 위반"이 아니라 "주문 상태가 PENDING_APPROVAL로 표시돼 사용자가 취소된 줄 안다"라고 쓴다.
• 휴리스틱 평가 결과를 사용성 테스트 결과처럼 보고한다. 이건 전문가의 예측이다. "사용자가 못 한다"가 아니라 "사용자가 걸릴 가능성이 높다"로 쓰고, 검증은 레슨 2로 넘긴다.

참고 자료

• Nielsen Norman Group — 10 Usability Heuristics for User Interface Design — 1994년 최초 발표, 2024년 1월 최종 검토. 원칙 자체는 1994년 이후 변경 없음
• Nielsen Norman Group — How to Conduct a Heuristic Evaluation — 평가자 3~5명 권장, 준비·개별 평가·통합의 3단계 절차
• Nielsen Norman Group — Severity Ratings for Usability Problems — 0~4 등급 정의와 빈도·영향·지속성 세 축
• ISTQB Certified Tester Usability Testing (CT-UT) — 사용성 위험 식별과 심각도 분류를 다루는 공식 실러버스
• 레슨 s5-m16-l11 — 사용성 테스트 개념과 측정 지표 입문
• 레슨 s2-m05-l04 — 주의 깊은 관찰
• 레슨 s2-m04-l02 — 위험 기반 테스팅(발생 가능성 × 영향)