[접근성연구·모바일] 햄버거 뒤에 숨은 길

모바일 내비게이션 연구

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

들어가며

데스크탑에서 웹사이트의 메뉴는 보통 상단에 펼쳐져 있다. 어디로 갈 수 있는지가 한눈에 보인다. 그런데 같은 사이트를 휴대폰으로 열면, 그 메뉴가 사라진다. 대신 상단 모서리에 가로줄 세 개가 쌓인 작은 아이콘 하나가 놓인다. 흔히 '햄버거 메뉴'라 불리는 이 아이콘을 눌러야, 접혀 있던 메뉴가 옆에서 미끄러져 나온다.

이것은 좁은 화면에 많은 메뉴를 담기 위한 합리적 타협이다. 화면이 좁으니 메뉴를 평소엔 숨겨두고, 필요할 때 펼치게 한 것이다. 그런데 이 타협에는 대가가 따른다. 메뉴가 '보이는 것'에서 '찾아서 열어야 하는 것'으로 바뀌면서, 길을 찾는 일이 한 단계 더 복잡해진다. 어디로 갈 수 있는지가 더 이상 한눈에 보이지 않는다.

이번 편은 '모바일 내비게이션', 그중에서도 햄버거 메뉴로 대표되는 '접힌 메뉴'를 기준 연구의 관점에서 다룬다. 메뉴를 숨기는 것이 어떤 문제를 낳는지, 무엇이 보존되어야 하는지, 표준은 무엇을 말하는지를 정리한다.

1. 메뉴를 숨긴다는 것의 의미

내비게이션은 사용자가 '어디에 무엇이 있는지'를 알고 그곳으로 이동하게 돕는 길잡이다. 데스크탑의 펼쳐진 메뉴는 이 길잡이를 늘 보이게 둔다. 사용자는 메뉴 항목들을 훑어보며 사이트의 전체 구조를 짐작하고, 가고 싶은 곳을 고른다. 메뉴 자체가 사이트의 '지도' 역할을 한다.

햄버거 메뉴는 이 지도를 접어 서랍 안에 넣는다. 서랍을 열기 전까지 사용자는 어디로 갈 수 있는지 알 수 없다. 이 변화에는 두 가지 비용이 따른다. 첫째는 '발견 비용'이다. 사용자가 메뉴가 거기 숨어 있다는 것을 알아채고, 아이콘을 찾아 눌러야 한다. 둘째는 '조망 비용'이다. 서랍을 열어도 한 번에 보이는 항목 수가 제한되어, 데스크탑처럼 전체 구조를 한눈에 조망하기 어렵다.

이 비용들은 익숙한 사용자에게는 거의 0에 가깝다. 햄버거 아이콘이 메뉴라는 것을 이미 알기 때문이다. 그러나 모든 사용자가 익숙한 것은 아니다. 디지털에 덜 익숙한 사람, 처음 그 사이트를 쓰는 사람에게는 이 비용이 실제 장벽이 된다.

두 비용을 데스크탑의 펼친 메뉴와 견주면 차이가 선명해진다.

단계	데스크탑(펼친 메뉴)	모바일(접은 메뉴)	익숙한 사용자	관습 바깥 사용자
메뉴 존재 인지	항상 보임 — 비용 0	아이콘을 메뉴로 알아채야 함	거의 0	높음(아이콘 의미 모름)
발견(열기)	불필요	아이콘을 찾아 눌러야 함	낮음	높음(위치·정체 불확실)
조망(전체 구조)	한눈에 훑음	서랍 안에서 다시 스크롤	낮음	높음(구조 파악 지연)
목표 항목 도달	바로 클릭	열기→스크롤→선택	낮음	높음(중간 이탈 가능)

(관점) 표의 오른쪽 두 열은 '같은 메뉴'가 사용자에 따라 다른 비용으로 다가옴을 보여준다. 점검에서 보는 것은 왼쪽 두 칸의 합이 아니라, 가장 비용이 큰 칸이 누구에게 어디서 생기는가다.

1-1. '관습'에 기댄 약속의 한계

햄버거 아이콘이 메뉴를 뜻한다는 것은 명문화된 규칙이 아니라 널리 퍼진 관습이다. 관습은 익숙한 사람에게는 효율적이지만, 그 관습을 모르는 사람에게는 아무 단서가 되지 못한다. 가로줄 세 개가 왜 메뉴인지는 직관적으로 자명하지 않다. 그래서 아이콘 옆에 '메뉴'라는 글자를 함께 두거나, 아이콘이 메뉴임을 보조 기술(화면 낭독기 등)이 읽을 수 있게 이름을 붙이는 것이 권장된다. 관습에만 기대면, 관습 바깥의 사용자를 배제하게 된다.

2. 무엇이 보존되어야 하나 — 접어도 잃지 말아야 할 것

메뉴를 접는 것 자체는 문제가 아니다. 좁은 화면에서는 합리적 선택이다. 핵심은 '접으면서 무엇을 잃지 않는가'다. 기준 연구의 관점에서 보존되어야 할 것들을 정리하면 다음과 같다.

항목의 완전성. 데스크탑 메뉴에 있던 항목이 모바일 메뉴(햄버거 서랍 안)에도 모두 있어야 한다. 접는 과정에서 일부 항목이 빠지면, 모바일 사용자는 데스크탑 사용자가 갈 수 있는 곳에 갈 수 없게 된다. 같은 사이트인데 화면에 따라 갈 수 있는 곳이 달라진다.

열고 닫음의 명확성. 사용자가 메뉴를 열 수 있고, 또 닫을 수 있어야 한다. 열린 메뉴를 닫는 방법(닫기 버튼, 바깥 영역 누르기 등)이 분명해야, 사용자가 메뉴에 갇히지 않는다.

조작 가능성. 메뉴를 마우스뿐 아니라 키보드로도 열고, 항목 사이를 이동하고, 선택할 수 있어야 한다. 보조 기술 사용자에게도 메뉴가 '메뉴'로 인식되고 조작 가능해야 한다.

현재 위치의 단서. 가능하다면 사용자가 지금 어느 항목에 있는지(현재 페이지 표시)가 메뉴에 드러나면, 길을 잃을 가능성이 줄어든다.

이 네 가지를 '접으면서 잃기 쉬운 것'과 짝지으면, 무엇을 점검해야 할지가 분명해진다.

보존할 것	잃었을 때의 증상	누가 먼저 막히나	점검 단서
항목의 완전성	데스크탑에 있던 메뉴가 모바일 서랍에 없음	모든 모바일 사용자	양쪽 메뉴 항목 수 대조
열고 닫음의 명확성	메뉴를 닫지 못해 화면이 갇힘	처음 쓰는 사용자	닫기 버튼·바깥 누름 작동
조작 가능성	키보드·보조 기술로 못 열거나 못 넘어감	키보드·낭독기 사용자	키보드만으로 열기→이동→닫기
현재 위치 단서	지금 어디인지 알 수 없어 반복 이동	길 찾기 약한 사용자	현재 항목 강조 표시 유무

(관점) '메뉴를 접었는가'는 점검 항목이 아니다. 점검 항목은 '접은 뒤에도 이 네 가지가 살아 있는가'다. 네 줄 중 하나라도 무너지면, 접힘은 타협이 아니라 손실이 된다.

2-1. '보이지 않음'과 '없음'의 경계

햄버거 메뉴의 근본 긴장은 '보이지 않는 것'과 '없는 것'이 사용자에게 비슷하게 느껴진다는 데 있다. 메뉴가 서랍 안에 있어도, 그것을 찾지 못한 사용자에게는 메뉴가 없는 것과 같다. 그래서 메뉴를 접을 때는 '여기에 메뉴가 있다'는 신호를 충분히 주는 것이 중요하다. 아이콘의 위치, 크기, 레이블이 그 신호다. 신호가 약하면 보이지 않는 메뉴는 없는 메뉴가 된다.

3. 표준은 무엇을 말하나 — 인식·조작·일관성

모바일 내비게이션과 맞닿는 접근성 기준은 여러 항목에 걸쳐 있다. 웹 콘텐츠 접근성 지침(WCAG)과 한국형 웹 콘텐츠 접근성 지침(KWCAG)이 가리키는 방향을 모으면 대략 세 갈래다.

첫째, 메뉴를 여는 아이콘 같은 컨트롤은 그것이 무엇인지 인식될 수 있어야 한다. 아이콘만 있고 이름이 없으면, 화면 낭독기를 쓰는 사용자는 그것이 메뉴 버튼인지 알 수 없다. 이름(레이블)을 부여하는 것이 권장되는 이유다. 둘째, 메뉴는 마우스뿐 아니라 키보드로도 조작 가능해야 한다. 열고, 이동하고, 선택하고, 닫는 모든 동작이 키보드로 가능해야 한다. 셋째, 같은 사이트 안에서 내비게이션의 위치와 방식이 일관되어야, 사용자가 페이지마다 길 찾는 법을 새로 배우지 않아도 된다.

이 항목들의 정확한 번호·등급은 지침 원문과 공공 디자인 기준(KRDS)의 내비게이션 관련 문서에서 확인하는 것이 안전하다. 이 글은 특정 항목의 충족 여부를 단정하기보다, 표준이 공통으로 가리키는 '인식·조작·일관성'의 방향을 정리하는 데 목적이 있다.

세 갈래를 표준 항목과 느슨하게 잇고, 햄버거 메뉴에 적용하면 다음과 같다.

방향	표준이 가리키는 항목(참고)	햄버거 메뉴에서의 의미	어긋날 때
인식	Name, Role, Value(4.1.2)	아이콘에 '메뉴'라는 이름이 붙어 있음	낭독기가 "버튼"으로만 읽어 정체 불명
조작	Keyboard(2.1.1)	키보드로 열기·이동·선택·닫기 가능	키보드 사용자가 서랍에 진입 불가
일관성	Consistent Navigation(3.2.3)	모든 페이지에서 같은 위치·방식	페이지마다 메뉴 위치가 달라 재학습

(인용) 위 항목 번호는 WCAG 2.1 기준의 참고 표기이며, 정확한 등급·충족 조건은 원문과 KWCAG·KRDS 문서에서 확인해야 한다. 이 표는 '단정'이 아니라 '방향의 지도'다.

3-1. 키보드와 보조 기술 관점의 중요성

햄버거 메뉴는 시각적으로만 보면 '아이콘을 누르면 서랍이 열리는' 단순한 구조다. 그러나 키보드만 쓰는 사용자나 화면 낭독기를 쓰는 사용자의 관점에서는 그렇지 않다. 아이콘에 이름이 없으면 무엇인지 알 수 없고, 키보드로 열 수 없으면 메뉴에 들어갈 수 없으며, 열린 메뉴의 항목 사이를 키보드로 이동할 수 없으면 그 안에서 길을 잃는다. 모바일 내비게이션 연구에서 이 관점을 빠뜨리면, 시각적으로만 '괜찮은' 메뉴가 실제로는 일부 사용자에게 닫혀 있을 수 있다.

4. 관찰 — 접힌 메뉴의 장면들

공공 영역의 여러 화면을 모바일에서 열어 내비게이션을 살펴본 관찰을, 익명으로 정리한다.

한 장면에서는 데스크탑 상단에 펼쳐져 있던 여러 안내 메뉴가 모바일에서 햄버거 서랍 안으로 들어갔는데, 데스크탑에 있던 일부 항목이 서랍 안에서 보이지 않았다. 접는 과정에서 누락된 것으로 보였고, 그 항목으로 가는 길이 모바일에서는 막혀 있었다. 다른 장면에서는 서랍을 열었더니 항목이 매우 많아 한 화면에 다 들어오지 않았고, 그 안을 다시 스크롤해야 원하는 항목에 닿았다. 메뉴를 열고도 길 찾기가 끝나지 않았다.

또 다른 장면에서는 메뉴를 여는 아이콘이 화면 구석에 작게 놓여, 처음 쓰는 사용자가 그것이 메뉴라는 것을 알아채기 어려워 보였다. 아이콘 옆에 '메뉴'라는 글자가 함께 있었다면 발견이 쉬웠을 것이다. 이 장면들의 공통점은 '메뉴가 있긴 있다'는 것이다. 다만 그 메뉴에 닿는 길이 누락되었거나, 길어졌거나, 잘 보이지 않았다.

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

관찰된 장면	데스크탑	모바일	닿지 못한 결과
항목 누락	상단에 안내 메뉴 여러 개	서랍 안에 일부 항목 없음	그 페이지로 가는 길 차단
과다 항목	한눈에 훑던 메뉴	서랍이 길어 다시 스크롤	열고도 길 찾기 미완
약한 신호	메뉴가 늘 보임	작은 아이콘만, 레이블 없음	처음 쓰는 사용자가 못 찾음

(관찰) 위 장면들은 특정 기관을 지목하지 않은 익명 관찰이며, 같은 사이트라도 점검 시점·기기·해상도에 따라 다르게 나타날 수 있다. 공통점은 '메뉴가 없지 않은데, 그 메뉴에 닿는 길이 가늘어졌다'는 것이다.

4-1. 길을 못 찾으면 '없는 기능'이 된다

내비게이션의 문제는 결국 '닿지 못함'으로 귀결된다. 어떤 페이지에 좋은 기능이 있어도, 그곳으로 가는 메뉴 항목을 사용자가 찾지 못하면 그 기능은 없는 것과 같다. 데스크탑에서는 메뉴가 펼쳐져 있어 쉽게 찾던 항목이, 모바일에서 서랍 안 깊숙이 들어가거나 아예 누락되면, 모바일 사용자에게 그 길은 사라진다. 모바일 내비게이션 연구가 '메뉴의 모양'이 아니라 '길의 보존'에 초점을 두는 이유다.

5. 점검의 관점 — 길이 보존되었는가

모바일 내비게이션을 점검 관점으로 옮기면 다음 질문들로 정리된다.

데스크탑 메뉴에 있던 항목이 모바일 메뉴에도 모두 있는가. 메뉴를 여는 아이콘을 처음 쓰는 사용자도 쉽게 찾을 수 있는가(레이블·위치·크기). 메뉴를 마우스뿐 아니라 키보드로도 열고, 이동하고, 선택하고, 닫을 수 있는가. 열린 메뉴를 닫는 방법이 분명한가. 같은 사이트 안에서 내비게이션 방식이 페이지마다 일관되는가. 화면 낭독기가 그 아이콘을 '메뉴'로 읽고, 메뉴의 항목들을 읽어주는가.

이 질문들은 모두 '데스크탑에서 닿던 길이 모바일에서도 보존되는가'라는 하나의 기준에서 갈라져 나온다. 메뉴가 접혔다는 사실 자체가 아니라, 접힌 뒤에도 길이 끝까지 살아 있는가를 본다.

질문들을 점검 항목으로 정리하면 다음과 같다.

점검 질문	보는 것	막혔을 때 신호
항목이 모두 옮겨졌는가	데스크탑↔모바일 메뉴 항목 대조	모바일에서만 사라진 항목
아이콘을 쉽게 찾는가	레이블·위치·크기	작고 이름 없는 아이콘
키보드로 전 과정 가능한가	열기→이동→선택→닫기	서랍 진입·이탈 불가
닫는 법이 분명한가	닫기 버튼·바깥 누름	메뉴에 갇힘
페이지마다 일관되는가	위치·방식 동일성	페이지별 재학습 강요
낭독기가 '메뉴'로 읽는가	역할·이름 노출	"버튼"으로만 읽힘

(관점) 표의 어느 행도 '햄버거를 쓰지 말라'고 말하지 않는다. 모두 '접은 뒤의 길'을 본다. 점검은 디자인 취향이 아니라 길의 생존을 검사한다.

5-1. '익숙한 나'를 넘어선 점검

점검할 때 익숙한 사용자의 손으로만 하면, 햄버거 메뉴의 문제는 거의 드러나지 않는다. 이미 아이콘이 메뉴인 줄 알고, 어디를 눌러 닫는지 알기 때문이다. 그래서 '이 아이콘이 메뉴인 줄 모르는 사람', '키보드만 쓰는 사람', '화면 낭독기로 듣는 사람'의 관점을 의식적으로 빌려와야 한다. 모바일 내비게이션의 장벽은 가장 익숙한 사용자가 아니라, 그 관습과 도구 바깥의 사용자에게서 드러난다.

5-2. 반론과 한계

이 관점에는 반론과 스스로 인정할 한계가 있다.

반론·한계	내용	이 글의 입장
"햄버거는 이미 보편 관습"	대다수가 아이콘=메뉴를 안다	다수가 안다고 소수의 막힘이 사라지진 않음 — 레이블은 비용이 낮다
"좁은 화면엔 접기 외 대안이 없다"	공간 제약은 현실	접기는 인정. 다만 접은 뒤 길 보존이 조건
정적 점검의 한계	열고 닫는 동작은 실제 조작해야 보임	키보드·낭독기 실사용 점검을 자동 점검이 대체 못 함
항목 누락 판정의 어려움	'의도된 생략'과 '실수 누락'의 구분	양쪽 메뉴 대조는 가능하나 의도 판단은 사람 몫

(관점) 한계를 적는 이유는 이 연구가 '정답표'가 아니라 '관점'임을 분명히 하기 위해서다. 햄버거 메뉴 자체를 단죄하지 않는다. 보는 것은 접힌 뒤의 길이다.

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

내비게이션 점검은 자동 도구가 보는 영역과 사람이 보는 영역이 갈린다.

점검 항목	자동 점검이 보는 것	사람이 봐야 하는 것
아이콘 레이블	이름(접근 가능한 이름) 존재 여부	그 이름이 '메뉴'로 자연스럽게 읽히는지
키보드 조작	포커스 이동 가능 여부 신호	실제 열기→이동→닫기 흐름의 매끄러움
항목 완전성	데스크탑·모바일 메뉴 항목 수 대조	빠진 항목이 의도인지 누락인지
일관성	페이지 간 메뉴 구조 동일성	사용자가 길을 재학습하지 않는지
현재 위치 단서	현재 항목 표시 속성 유무	그 표시가 사용자에게 실제로 읽히는지

(관점) 자동 점검은 '신호의 유무'를 빠르게 훑고, 사람은 '그 신호가 길로 이어지는가'를 본다. ViewCheck는 둘을 합쳐, 접힌 메뉴 뒤에 길이 끝까지 살아 있는지를 확인하는 관점에 선다.

6. 한 장 요약

구분	핵심
햄버거 메뉴	좁은 화면을 위해 메뉴를 접은 합리적 타협
따르는 비용	발견 비용(찾아 눌러야)·조망 비용(전체 구조 안 보임)
관습의 한계	가로줄 세 개=메뉴는 관습일 뿐, 모르는 사람에겐 단서 없음
보존할 것	항목 완전성·열고 닫음·키보드 조작·현재 위치 단서
표준 방향	인식(레이블)·조작(키보드)·일관성 (항목·등급은 원문 확인)
핵심 위험	'보이지 않음'이 '없음'이 되는 것
점검 핵심	데스크탑의 길이 모바일에 보존되는가, 관습 바깥 사용자 관점

맺으며

햄버거 메뉴는 좁은 화면을 위한 합리적 선택이지만, 메뉴를 '보이는 것'에서 '찾아 열어야 하는 것'으로 바꾸면서 길 찾기에 비용을 더한다. 그 비용은 익숙한 사용자에게는 거의 없지만, 관습 바깥의 사용자, 키보드·보조 기술 사용자에게는 실제 장벽이 된다. 그래서 핵심은 메뉴를 접는가가 아니라, 접은 뒤에도 데스크탑에서 닿던 길이 끝까지 보존되는가다.

우리는 모바일 내비게이션을 '메뉴의 디자인'이 아니라 '길의 보존'으로 본다. 항목이 빠지지 않고, 누구나 메뉴를 찾아 열 수 있고, 키보드와 보조 기술로도 조작되며, 사이트 전체에서 일관될 때, 접힌 메뉴는 길을 숨기는 것이 아니라 효율적으로 담아두는 것이 된다. 다음 편에서는 이 길 찾기가 실패하는 순간, 즉 '메뉴를 못 찾는 순간'을 점검의 시선으로 더 좁혀 다룬다.

다음 편 예고 (026): 〈메뉴를 못 찾는 순간 / 모바일 탐색 점검 관점〉 — 사용자가 모바일에서 길을 잃는 구체적 순간들을 모아, 점검에서 그 막힘을 어떻게 재현하고 찾아낼지 다룬다.

---

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

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