[6월 TIL #8] 태블릿 사용성 테스트를 앞두고 — NN/g 126 가이드라인

요즘 쓰는 TIL은 흐름이 비슷했다. 어떤 작업을 먼저 하고, "이걸 미리 알았더라면" 하는 마음으로 회고하듯 공부한 다음, 다시 업무에 적용하는 순서였다. 그런데 이번은 반대다. 태블릿 사용성 테스트 업무가 들어왔고, 이번만큼은 들어가기 전에 미리 공부해서 놓치는 것 없이 테스트하고 싶었다.

 

 

그래서 가장 기본이 되는 문서부터

여러 자료 중 가장 기본이 되는 것을 먼저 펼쳤다. Nielsen Norman Group의 태블릿 UX 리포트(Raluca Budiu·Jakob Nielsen, 2013)다. 3년간 6개의 사용성 스터디, 67명, iPad·Android·Windows 태블릿을 관찰해서 뽑은 126개의 가이드라인이 담겨 있다.

 

리포트의 큰 주장은 한 문장이다. 태블릿은 폰보다 크지만 데스크톱은 아니다. 그래서 대부분의 웹사이트는 태블릿에서 '읽기'는 그럭저럭 되지만, 문제는 누르기, 되돌리기, 입력하기, 제스처를 이해하기에서 터진다. 리포트는 이걸 '읽기-누르기 비대칭(read–tap asymmetry)'이라 부른다. 콘텐츠를 읽기엔 충분한데, 작은 마우스 커서가 아니라 굵은 손가락으로는 누르기가 쉽지 않다는 것이다.

 

126개를 다 외울 일은 아니다. '어디서 문제가 터지나'를 보는 지도로 보면 된다. 번호 구간별로 묶으면 이렇게 나뉜다.

 

번호	영역	핵심 질문
1–5	앱이 필요한가 / 태블릿 ≠ 폰	웹으로 충분한데 앱을 만들진 않는가? 폰 UI를 그냥 확대하진 않았는가?
6–17	데스크톱 웹을 태블릿 친화적으로 + 터치 안전	글자·대비·링크 맥락은 충분한가? 타깃은 손가락만큼 큰가? 마우스 전용 기능에 기대지 않는가?
18–23	호환성 · 앱 아이콘 · 스큐어모픽	Flash·PDF처럼 흐름을 깨는 게 있는가? 실물처럼 꾸민 게 조작을 방해하진 않는가?
24–29	터치 타깃	크기·간격·라벨·탭 가능해 보이는 affordance가 충분한가?
30–46	입력 · 타이핑 · 피커	타이핑을 줄였는가? 자동완성·기본값·적절한 키보드·자동 포맷을 주는가?
47–51	폼	제출 버튼 위치, 링크/제출 구분, 쉽게 닫히는 팝오버에 폼을 넣지 않았는가?
52–64	회원가입 · 로그인 · 플로우	시작부터 로그인을 강요하지 않는가? 필드는 최소인가? 단계와 기본값은 합리적인가?
65–82	내비게이션 · Back · 피드백	핵심 기능이 보이는가? 실수했을 때 이전 상태로 돌아갈 수 있는가? 누른 결과가 보이는가?
83–89	검색 · 리스트	검색창이 보이는가? 메뉴 안에 숨기지 않았는가? 검색어·필터를 보존하는가?
90–97	분할 뷰 · 프레임 · 제스처	화면을 너무 잘게 쪼개지 않았는가? 같은 제스처가 자리마다 다른 뜻을 갖지 않는가?
98–107	튜토리얼 · 콘텐츠 · 로딩	시작부터 긴 설명을 던지지 않는가? 큰 그림을 먼저 보여주는가? 로딩 상태를 알리는가?
108–118	지도 · 미디어 · 방향 · 인앱 브라우저	자동 재생 소리를 끄는가? 가로/세로에서 인터페이스가 일관적인가?
119–123	에러	필드 표시만 말고 구체적 메시지를 주는가? 눈에 띄고, 사라지지 않고, 해결 링크가 있는가?
124–126	쇼핑	장바구니가 보이는가? 주문 완료를 명확히 알리는가? 실수 주문을 취소할 수 있는가?

번호 구간으로 묶어 본 126개 가이드라인의 지도.

 

그런데 막상 이렇게 펼쳐 보니, 상당수는 태블릿에만 해당하는 깊은 포인트라기보다 어디서나 통하는 기본 UX 원칙에 가까웠다. 그래서 전부를 외우기보다, 태블릿 관점에서 특히 더 아프게 다가오는 핵심만 골라 깊게 봤다. 웹 기반으로 태블릿을 지원하는 입장에서 먼저 잡을 것은 여섯 가지 정도로 좁혀졌다.

• hover·right-click 없이도 모든 핵심 동작이 가능할 것 (기본은 touch-safe).
• 터치 타깃은 충분히 크게, 충분히 떨어뜨려서.
• 탭 가능한 요소는 눈에 보이게. flat하게 숨기지 않기.
• 입력·키보드·화면 방향: 키보드가 입력창을 가리는지, 키보드 타입이 맞는지.
• 검색·필터·Back 상태를 보존할 것. 태블릿은 실수 터치가 많아 '되돌리기'가 핵심.
• 화면을 쪼개는 분할 뷰·프레임·팝오버·라이트박스 남발 주의.

특히 자주 문제가 되는 hover는 17번 "마우스 전용 기능을 쓰지 말라"에 바로 걸린다. 손가락 사용자는 애초에 hover에 접근할 수 없기 때문이다. 그래서 먼저 깊게 볼 10개를 추리면 이렇다.

 

No.	한 줄로
17	hover·right-click 같은 마우스 전용 기능에 기대지 않기
14	링크·버튼은 손가락 기준으로 크게 (NN/g는 1cm, 약 38px / 실무는 44–48px)
15	타깃끼리 붙이지 말고 터치 여백 주기
27	누를 수 있는 요소가 배경에 묻히지 않게
30	타이핑 최소화 (자동완성·기본값·계산으로 대체)
39	키보드가 올라와도 입력 중인 내용이 가리지 않게 (가로/세로 모두)
66	핵심 기능·검색·주요 내비는 숨기지 않고 보이게
81	누른 결과를 즉시 피드백
82	언제든 이전 상태로 되돌릴 수 있게
90	꼭 동시에 봐야 할 때만 화면 분할

"데스크톱 웹은 되는데 태블릿에서 이상한" 문제를 가장 많이 잡아주는 10개.

 

 

그런데 자료가 좀 오래됐다

문제는 이 리포트가 2013년 기준이라는 점이었다. 게다가 엔지니어링보다 원론적인 이야기가 주를 이뤘다. 인간공학·UX 원칙 자체는 지금도 유효하지만, 브라우저·입력장치·접근성 기준은 그새 꽤 바뀌었다. 그래서 이 부분은 최신 자료로 업데이트하면서 봤다. 오래된 지점과 보완 기준을 묶으면 이렇다.

 

보완 영역	왜 오래됐나	최신 보완 기준
입력 방식	"태블릿 = 손가락"에 가까웠지만 지금은 트랙패드·마우스·펜·키보드가 섞임	화면 크기 말고 hover·pointer·any-hover 같은 media feature로 입력 특성을 판단
hover	"hover 쓰지 말라"는 맞지만 일부 태블릿은 트랙패드·펜 hover가 가능	hover는 보조 경험으로만. 핵심은 tap·focus로 가능해야 함
터치 타깃 수치	1cm 기준이 개발 단위로는 애매	WCAG 2.2 최소 24×24px, 실무 44–48px hit area (Apple 44pt, Material 48dp)
이벤트 모델	touch/mouse를 따로 처리하는 사고가 강했음	Pointer Events로 통합해서 보기
스크롤·제스처 충돌	제스처 모호성은 말하지만 구현 디테일이 부족	touch-action, pointercancel 대응을 함께 보기
키보드·viewport	지금 웹앱은 fixed footer·bottom sheet·에디터·채팅 입력이 많음	VisualViewport, 필요하면 VirtualKeyboard API
실제 디버깅	데스크톱 반응형 모드만으로는 태블릿 이슈를 못 잡음	실제 iPad·Android에서 테스트 + Mac Safari Web Inspector

 

그러다 보완 자료를 따라가니 갑자기 개발 용어가 쏟아졌다. Pointer Events, pointercancel, VisualViewport, service worker 같은 것들. 그냥 넘어가기엔 찜찜해서 초심자 기준으로 따로 정리해뒀다.

 

➕ 추가로 알아본 것 — 갑자기 튀어나온 개발 용어들

용어	한 줄로
Pointer Events	마우스·손가락·펜을 하나의 이벤트로 처리. 드래그·슬라이더·그리기 같은 UI에서 중요
pointercancel	드래그하던 걸 브라우저가 스크롤·줌으로 가져가며 "취소"를 알림. 안 받으면 UI가 '드래그 중'으로 멈춤
VisualViewport	키보드·확대로 '실제 보이는 화면'이 바뀐 걸 알려주는 API. 키보드가 입력창·CTA를 가리는지 확인
VirtualKeyboard API	키보드 등장 시 레이아웃을 직접 제어(최신, 지원 제한). 우선은 VisualViewport + 실기기 QA가 먼저
service worker	웹앱과 네트워크 사이의 백그라운드 프록시(캐시·오프라인). "배포했는데 옛 화면이 계속 보이는" 문제의 단골 원인
Home Screen web app	홈 화면에 추가해 앱처럼 실행(PWA). 일반 탭과 캐시·실행 상태가 달라 따로 봐야 함

 

이 용어들의 공통점은, 데스크톱 반응형 모드로는 재현이 안 된다는 것이다. 그래서 실제 iPad에서 실행되는 웹앱을 Mac의 Safari Web Inspector로 들여다봐야(inspect) 키보드에 가린 입력창, 멈춘 드래그, 옛 캐시 화면 같은 게 비로소 보인다.

 

추가로 참고한 글: MDN Pointer events · MDN VisualViewport · MDN Service Worker

 

정리하면 역할을 나누는 게 깔끔했다. NN/g 리포트는 "태블릿에서 어디가 위험한지" 빠르게 짚어주는 사고틀로, MDN·WCAG·Apple·Material은 "지금 웹에서 어떻게 구현하고 검증할지" 보는 기준으로. 오래된 자료라고 버릴 게 아니라 쓰임을 나누면 되는 것이었다.

 

그러면서 생각이 하나 크게 바뀌었다. "태블릿 지원 = 화면폭 테스트"가 아니라는 것이다. 손가락·펜·트랙패드·키보드 같은 입력, 가로와 세로, 키보드가 올라온 상태, 홈 화면에서 앱처럼 실행된 상태, 캐시 상태까지 봐야 비로소 "태블릿에서 쓸 만한가"를 말할 수 있다. 그래서 이번 공부를 이렇게 한 장짜리 체크리스트로 묶어, 테스트에 들고 들어가려 한다.

 

✅ 테스트 때 들고 갈 체크리스트

입력 · 포인터
☐ hover·right-click 없이 모든 핵심 동작이 되나
☐ 터치 타깃이 충분히 크고(44–48px) 충분히 떨어져 있나
☐ 탭 가능한 요소가 배경에 묻히지 않고 눈에 보이나
☐ 손가락·펜·트랙패드·마우스 입력이 모두 자연스럽나

입력창 · 키보드
☐ 키보드가 올라왔을 때 입력창·CTA·푸터가 가리지 않나 (가로·세로 모두)
☐ 필드 타입에 맞는 키보드가 뜨나 (이메일·숫자 등)
☐ 타이핑을 줄일 수 있나 (자동완성·기본값)

상태 · 되돌리기
☐ 검색어·필터·스크롤·Back 상태가 보존되나
☐ 누른 결과가 즉시 피드백되나
☐ 언제든 이전 상태로 되돌릴 수 있나

레이아웃 · 방향
☐ 가로·세로에서 인터페이스와 콘텐츠가 일관적인가
☐ 화면을 분할 뷰·프레임으로 과하게 쪼개지 않았나
☐ 제스처가 자리·시점마다 다른 뜻을 갖지 않나

실기기 · 실행 환경
☐ 실제 iPad·Android에서 확인했나 (데스크톱 반응형 모드 말고)
☐ 홈 화면에서 앱처럼 실행된 상태도 봤나
☐ 캐시 때문에 옛 화면이 남아 있지 않나

 

 

결국은, 논문을 더 잘 읽게

우리 제품은 연구자가 논문을 읽는 도구다. 그래서 태블릿 버전이 정말 중요하다. 이번 공부와 테스트가 유저들이 논문을 읽는 경험을 조금이라도 낫게 만든다고 생각하면 기쁘다. 함께 만드는 팀에도 보탬이 되면 좋겠다. 예전에 학원에서 일할 때, 강의 자료를 아이패드로 공부하면서 굿노트의 사용성에 영향을 참 많이 받았다. 우리 제품이 'AI가 들어간, 논문용 굿노트'처럼 된다면 얼마나 좋을까 하는 즐거운 상상도 든다. 굿!