[접근성연구·모바일] 메뉴를 못 찾는 순간

모바일 탐색 점검 관점

〈디지털 접근성 연구 026〉 — 이 글은 규정이 아니라 하나의 연구 관점입니다. 인용 수치·기준은 출처와 함께, 미확정 영역은 그렇다고 밝혀 작성합니다.

들어가며

앞 편(025)에서 모바일 내비게이션의 기준, 즉 메뉴를 접어도 길이 보존되어야 한다는 관점을 다뤘다. 이번 편은 그 시선을 '실패의 순간'으로 좁힌다. 사용자가 모바일에서 메뉴를, 길을, 원하는 페이지를 '못 찾는' 구체적 순간들을 모아, 점검에서 그 막힘을 어떻게 재현하고 찾아낼지에 관한 점검 관점이다.

길을 못 찾는 일은 흔히 사용자의 탓으로 돌려진다. '익숙하지 않아서', '잘 못 봐서'. 그러나 점검의 관점에서는 그 반대다. 익숙하지 않은 사용자도, 잘 못 보는 사용자도 길을 찾을 수 있어야 잘 설계된 것이다. 누군가 길을 못 찾았다면, 그 순간은 사용자의 실수가 아니라 점검이 잡아내야 할 신호다.

이 글은 메뉴를 못 찾는 순간을 유형별로 모으고, 각 순간을 점검에서 어떻게 재현해 드러낼지를 정리한다. 특정 사이트를 지목하지 않고, '왜 못 찾는가'와 '어떻게 찾아낼 수 있게 점검하는가'에 초점을 둔다.

1. 못 찾는 순간의 유형 — 무엇이 길을 가리나

사용자가 모바일에서 길을 못 찾는 순간은 몇 가지 유형으로 정리된다.

메뉴 입구를 못 찾는 순간. 메뉴를 여는 아이콘 자체를 발견하지 못한다. 아이콘이 작거나, 구석에 있거나, 무슨 기능인지 알 수 없는 모양이면, 사용자는 '메뉴가 어디 있지?'에서 멈춘다. 메뉴는 거기 있지만, 입구를 못 찾으면 없는 것과 같다.

열고도 못 찾는 순간. 메뉴를 열었는데 항목이 너무 많거나 분류가 모호해, 원하는 항목이 어디 있는지 모른다. 메뉴 안에서 다시 길을 잃는다.

돌아가는 길을 못 찾는 순간. 한 페이지로 들어갔는데, 이전 화면이나 홈으로 돌아가는 길이 분명하지 않다. 사용자는 막다른 골목에 갇힌 느낌을 받는다.

현재 위치를 모르는 순간. 여러 단계를 거쳐 들어왔는데, 지금 사이트의 어디쯤에 있는지 알 수 없다. 위치를 모르면 다음 행동을 정하기 어렵다.

네 유형을 '어디서 멈추나'와 함께 정리하면 다음과 같다.

못 찾는 유형	멈추는 지점	사용자의 속마음	점검에서 보는 신호
입구를 못 찾음	시작 화면	"메뉴가 어디 있지?"	작은·이름 없는 아이콘
열고도 못 찾음	펼친 메뉴 안	"어느 분류 아래지?"	항목 과다·모호한 분류
돌아갈 길 없음	들어간 페이지	"어떻게 돌아가지?"	페이지 내 복귀 단서 부재
현재 위치 모름	여러 단계 진입 후	"내가 지금 어디지?"	현재 항목·경로 표시 부재

(관점) 네 유형은 모두 '메뉴가 없어서'가 아니라 '있는데 닿는 길이 흐려서' 생긴다. 점검은 메뉴의 유무가 아니라 길의 선명함을 본다.

1-1. 못 찾음은 '점진적 포기'로 이어진다

길을 못 찾는 순간은 한 번에 포기로 이어지지 않는다. 사용자는 보통 몇 번 더 시도한다. 화면 여기저기를 눌러보고, 스크롤을 오르내리고, 뒤로 가기를 누른다. 그러다 일정 횟수 시도해도 길이 안 보이면 그때 포기한다. 이 '점진적 포기'의 과정은 운영 측에 잘 드러나지 않는다. 사용자가 떠났다는 결과만 남고, 그가 몇 번을 시도하다 포기했는지는 보이지 않는다. 점검이 이 순간을 미리 재현해야 하는 이유다.

2. 점검의 기본 자세 — '처음 쓰는 사람'을 빌려오기

메뉴를 못 찾는 순간을 점검으로 잡아내려면, 점검자의 자세부터 바꿔야 한다. 익숙한 점검자는 메뉴가 어디 있는지 이미 안다. 그 손으로는 막힘이 드러나지 않는다.

그래서 점검의 핵심은 '처음 쓰는 사람의 손'을 빌려오는 것이다. 이 사이트를 처음 여는 사람이라면, 메뉴 아이콘을 한눈에 알아볼까. 가로줄 세 개를 보고 그것이 메뉴라고 짐작할까. 원하는 기능으로 가는 항목 이름을 메뉴에서 바로 찾을까. 한 페이지로 들어간 뒤 돌아오는 길을 헤매지 않을까. 이 질문들을 '익숙한 나'가 아니라 '처음인 사람'의 입장에서 물어야 한다.

가능하다면 실제로 그 사이트를 처음 쓰는 사람에게 특정 과제(예: '○○ 안내를 찾아보세요')를 주고, 어디서 멈추는지 지켜보는 것이 가장 정확하다. 점검자 혼자서는 자기 익숙함을 완전히 떼어내기 어렵기 때문이다.

2-1. '과제 기반 점검'의 힘

길 찾기 점검에서 효과적인 방법은 '과제'를 정해두고 그 과제를 끝까지 수행해 보는 것이다. '메뉴가 보이는가'라는 막연한 점검보다, '○○ 신청 페이지까지 가보라'는 구체적 과제가 막힘을 잘 드러낸다. 과제를 수행하다 멈추는 지점이 곧 사용자가 길을 못 찾는 지점이다. 막연히 둘러보면 '대충 있는 것 같다'로 끝나지만, 목적지를 정해 끝까지 가보면 도중의 막힘이 또렷이 보인다.

3. 각 순간을 점검에서 재현하는 법

못 찾는 순간의 유형별로, 점검에서 어떻게 재현해 드러낼지를 정리한다.

메뉴 입구 점검. 화면 상단을 보고, 메뉴를 여는 입구가 한눈에 보이는지 확인한다. 아이콘만 있고 '메뉴' 글자가 없다면, 그 아이콘이 메뉴임을 처음 쓰는 사람이 알 수 있을지 의심한다. 화면 낭독기를 켜고, 그 아이콘이 '메뉴'로 읽히는지도 확인한다.

열고 난 뒤 점검. 메뉴를 열어, 원하는 항목을 몇 초 안에 찾을 수 있는지 본다. 항목이 너무 많아 스크롤해야 하거나, 분류가 모호해 어디를 눌러야 할지 망설여진다면, 그 자리가 막힘이다.

돌아가는 길 점검. 한 페이지로 들어간 뒤, 이전 화면과 홈으로 돌아가는 길이 분명한지 본다. 브라우저 뒤로 가기 말고, 페이지 안에서 돌아갈 수 있는 단서(상단 링크, 경로 표시 등)가 있는지 확인한다.

현재 위치 점검. 여러 단계를 거쳐 들어간 뒤, 지금 사이트의 어디에 있는지 알 수 있는 단서가 있는지 본다. 현재 메뉴 항목 강조나 경로 표시가 그런 단서다.

각 점검을 '재현 동작'과 '막힘 판정 기준'으로 표에 모으면 다음과 같다.

점검	재현 동작	막힘으로 보는 기준
메뉴 입구	상단을 보고 입구를 찾음 + 낭독기로 읽힘 확인	처음 쓰는 사람이 입구를 못 짚음
열고 난 뒤	메뉴 열어 목표 항목을 몇 초 안에 찾음	스크롤·분류 모호로 망설임 발생
돌아가는 길	페이지 안에서 복귀 단서로 돌아감	브라우저 뒤로 가기에만 의존
현재 위치	진입 후 현재 위치 단서 확인	현재 항목·경로 표시 없음

(관점) 점검의 결론은 '됐다/안 됐다'가 아니라 '어디서 멈췄나'다. 멈춘 지점이 곧 사용자의 포기 지점이므로, 재현은 그 지점을 또렷이 만드는 작업이다.

3-1. 키보드·낭독기로도 같은 과제를

이 점검들을 손가락 터치로만 하면 절반만 본 것이다. 같은 과제를 키보드만으로, 그리고 화면 낭독기로 들으며 수행해 본다. 키보드로 메뉴를 열고 항목을 이동해 목적지에 닿을 수 있는가. 낭독기가 메뉴와 항목을 읽어주어, 보지 않고도 길을 찾을 수 있는가. 시각적으로는 멀쩡한 길이 키보드·낭독기 사용자에게는 막혀 있을 수 있으므로, 같은 과제를 다른 입력 방식으로 반복하는 것이 점검의 완성이다.

4. 관찰 — 길을 잃은 장면들

공공 영역의 여러 화면에서 길 찾기 과제를 수행하며 모은 막힘의 장면을, 익명으로 정리한다.

한 장면에서는 특정 안내를 찾으라는 과제를 두고 시작했는데, 메뉴 입구인 아이콘이 화면 구석에 작게 있어 발견까지 시간이 걸렸다. 처음 쓰는 사람이라면 더 오래 헤맸을 것이다. 다른 장면에서는 메뉴를 열었으나 항목이 많고 분류가 겹쳐, 찾던 안내가 어느 분류 아래 있는지 두 번 잘못 들어간 뒤에야 닿았다. 또 다른 장면에서는 한 안내 페이지로 들어간 뒤, 같은 메뉴의 다른 안내로 가려는데 돌아가는 길이 분명하지 않아 브라우저 뒤로 가기에 의존해야 했다.

이 장면들의 공통점은 '결국 닿기는 했다'는 것이다. 점검자는 끈기 있게 시도해 목적지에 도달했다. 그러나 그 과정의 막힘과 헤맴은, 덜 익숙하거나 덜 끈기 있는 사용자에게는 포기 지점이 되었을 것이다. 점검은 '닿았는가'에서 멈추지 않고 '얼마나 헤맸는가'까지 기록해야 한다.

관찰한 장면을 익명으로 묶으면 다음과 같다.

관찰된 장면	막힌 지점	점검자는	덜 끈기 있는 사용자는
입구 발견 지연	작은·구석 아이콘	시간 들여 발견	시작 화면에서 이탈
분류 혼동	겹친 분류 체계	두 번 잘못 든 뒤 도달	첫 오진입에서 포기
복귀 막힘	페이지 내 복귀 단서 부재	브라우저 뒤로 가기 의존	막다른 골목으로 느낌

(관찰) 위 장면은 특정 기관을 지목하지 않은 익명 관찰이며, 점검 시점·기기에 따라 다르게 나타날 수 있다. 공통점은 '점검자는 닿았지만, 그 도달이 사용자 경험을 보장하지 않는다'는 것이다.

4-1. '닿았다'와 '쉽게 닿았다'는 다르다

길 찾기 점검에서 흔한 함정은 '결국 찾았으니 됐다'고 판단하는 것이다. 점검자는 끈기와 익숙함을 가지고 있어 대개 결국은 찾아낸다. 그러나 사용자에게 중요한 것은 '찾을 수 있는가'가 아니라 '헤매지 않고 찾는가'다. 두 번 잘못 들어간 뒤 찾았다면, 그것은 두 번의 포기 기회를 지난 것이다. 점검은 도달 여부만이 아니라, 도달까지의 헤맴(잘못 든 횟수, 멈춘 지점)을 함께 봐야 실제 사용자 경험에 가까워진다.

5. 점검의 기록과 우선순위

길 찾기 점검의 발견은 '과제 / 막힌 지점 / 헤맨 정도 / 입력 방식'으로 기록하면 재현과 개선이 쉬워진다. 예를 들어 '○○ 안내 찾기 / 메뉴 입구 발견 지연 / 처음 쓰는 사람 기준 / 터치·키보드 모두'처럼 적는다.

우선순위는 '닿지 못함'을 기준으로 가른다. 길이 아예 끊겨 닿을 수 없는 경우(항목 누락, 키보드로 메뉴 못 엶)가 가장 무겁다. 그다음은 닿기는 하지만 크게 헤매는 경우(입구를 못 찾음, 분류가 모호함)다. 그다음은 닿되 약간 불편한 경우(돌아가는 길이 다소 불분명함)다. 미관상 아쉽지만 길 찾기에 지장이 없는 것은 가장 나중이다.

우선순위를 표로 정리하면 다음과 같다.

등급	상태	예	사용자에게
가장 무거움	길이 끊김(닿지 못함)	항목 누락, 키보드로 메뉴 못 엶	그 기능이 아예 없는 것과 같음
무거움	크게 헤맴	입구 못 찾음, 분류 모호	다수가 도중 포기
보통	약간 불편	복귀 길 다소 불분명	끈기 있으면 도달
가벼움	미관상 아쉬움	길 찾기엔 지장 없음	경험에 큰 영향 없음

(관점) 우선순위의 축은 '보기 좋은가'가 아니라 '닿는가'다. 가장 위 두 등급은 디자인 개선이 아니라 길 복구의 문제다.

5-1. 반복되는 막힘은 구조의 문제다

여러 과제에서 같은 유형의 막힘이 반복된다면, 그것은 특정 페이지의 문제가 아니라 사이트 전체의 내비게이션 구조 문제일 가능성이 크다. 메뉴 입구가 모든 페이지에서 발견하기 어렵다거나, 분류 체계가 전반적으로 모호하다면, 페이지 하나를 고쳐서 해결되지 않는다. 점검 기록을 모아 패턴을 보면, 개별 증상 뒤의 구조적 원인이 드러난다.

5-2. 반론과 한계

이 점검 관점에도 반론과 한계가 있다.

반론·한계	내용	이 글의 입장
"결국 다 찾는다"	끈기 있으면 도달함	도달 여부가 아니라 헤맴의 양이 경험을 좌우
점검자 주관	'쉬움'의 기준이 사람마다 다름	그래서 과제·헤맨 횟수를 수치로 기록
처음 사용자 섭외 어려움	매번 신규 사용자를 부르기 어려움	점검자가 '처음의 손'을 의식적으로 빌려옴
자동화 한계	헤맴·망설임은 동작 점검이 필요	입구 존재·레이블은 자동, 헤맴은 사람

(관점) 한계를 적는 것은 이 점검이 '완벽한 측정'이 아니라 '막힘을 드러내는 관점'임을 밝히기 위해서다. 못 찾음을 사용자 탓으로 돌리지 않는 자세가 핵심이다.

5-3. ViewCheck의 관점 — 사람과 도구의 분담

길 찾기 점검은 자동 도구가 빠르게 훑는 영역과 사람이 직접 수행해야 하는 영역이 갈린다.

점검 항목	자동 점검이 보는 것	사람이 봐야 하는 것
메뉴 입구	아이콘 레이블·역할 존재	처음 쓰는 사람이 입구를 짚는지
메뉴 항목	항목 수·구조 신호	분류가 직관적인지, 망설임 발생 여부
돌아가는 길	복귀 링크·경로 표시 유무	실제로 헤매지 않고 돌아오는지
키보드·낭독기	포커스·읽힘 가능 신호	같은 과제를 끝까지 수행하는 흐름
반복 막힘	페이지 전반의 동일 증상 집계	구조적 원인인지의 판단

(관점) 자동 점검은 '신호의 유무'를 사이트 전체에서 빠르게 모으고, 사람은 '그 신호가 길로 이어지는가'를 과제로 검증한다. ViewCheck는 둘을 합쳐, 못 찾는 순간을 사용자 탓이 아닌 점검의 신호로 본다.

6. 한 장 요약

구분	핵심
못 찾는 유형	입구 못 찾음·열고도 못 찾음·돌아갈 길 없음·현재 위치 모름
막힘의 결과	점진적 포기 — 운영 측에 잘 안 드러남
점검 자세	'처음 쓰는 사람의 손'을 빌려오기
효과적 방법	과제 기반 점검(목적지 정해 끝까지 가보기)
다른 입력	같은 과제를 키보드·화면 낭독기로 반복
기록 기준	과제/막힌 지점/헤맨 정도/입력 방식
우선순위	'닿지 못함' 기준, 반복 막힘은 구조 문제 의심

맺으며

메뉴를 못 찾는 순간은 사용자의 실수가 아니라 점검이 잡아내야 할 신호다. 입구를 못 찾고, 열고도 헤매고, 돌아갈 길을 잃고, 현재 위치를 모르는 순간들은 모두 '길이 충분히 분명하지 않다'는 증거다. 그리고 이 막힘은 익숙한 점검자의 손으로는 잘 드러나지 않으므로, '처음 쓰는 사람'의 관점을 빌려 구체적 과제를 끝까지 수행해 봐야 비로소 드러난다.

우리는 길 찾기를 '닿았는가'가 아니라 '헤매지 않고 닿는가'로 본다. 결국 찾았다는 것은 점검자의 끈기를 증명할 뿐, 사용자의 경험을 보장하지 않는다. 다음 편에서는 모바일의 또 다른 영역, 화면을 가로로 돌리거나 확대했을 때의 대응, 즉 '방향·확대 대응'으로 넘어간다.

다음 편 예고 (027): 〈가로로 돌리면 확대하면 / 방향·확대 대응 연구〉 — 화면을 가로로 돌리거나 확대했을 때 레이아웃과 기능이 어떻게 견뎌야 하는지, 방향·확대 대응의 기준을 연구 관점으로 정리한다.

참고한 공개 자료(출처):

W3C, Web Content Accessibility Guidelines (WCAG) 2.1 — Consistent Navigation(3.2.3), Multiple Ways(2.4.5), Keyboard(2.1.1), Name/Role/Value(4.1.2) 등 (정확한 항목·등급은 원문 확인 권장)
한국지능정보사회진흥원(NIA), 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.x — 탐색·일관성 관련 항목
행정안전부·디지털플랫폼정부, KRDS(공공 디자인 시스템) 내비게이션·탐색 관련 공개 문서
MDN Web Docs — Navigation patterns, Usability testing 개요