바이브코딩 UI 용어 사전 2편 내비게이션: 햄버거 메뉴부터 커맨드 팔레트까지 15개

이전 글 바이브코딩 UI 용어 사전 1편 레이아웃에서는 "무엇을 어디에 둘까"에 해당하는 이름 13개를 정리했습니다. 그 글에서 "메뉴는 햄버거 버튼으로 접기"라고 한 줄로 넘어간 부분이 있는데 사실 그 한 줄 뒤에 정할 것이 꽤 많습니다.

2편은 "어디로 가게 할까"에 해당하는 내비게이션(Navigation, 화면과 화면 사이를 오가는 길) 용어를 다룹니다. 이름을 모르면 AI에게 "휴대폰에서는 메뉴 알아서"처럼 말하게 되는데 이번에도 그 "알아서"가 무엇을 정하는지가 궁금했습니다.

이번 글에서는 햄버거 메뉴부터 맨 위로 버튼까지 내비게이션 용어 15개를 가상 사이트에 직접 만들어 띄워 놓고 비교하겠습니다. 그리고 같은 숙소 예약 홈페이지를 "모바일 메뉴로 만들어줘" 한마디와, 이름과 동작을 적은 요청으로 Claude에게 시켜서 390px 화면에서 메뉴를 열고 닫고 키보드로만 움직여 보겠습니다. 요청문 5칸(이름·위치·계기·동작·예외)은 0편에서 정리한 그대로 씁니다.

(작성일 기준 2026-11-04입니다. 화면 속 Brightlane, freeform, Driftnest, neurolume은 포인트 컬러 글을 위해 지어낸 가상의 서비스이고, 색도 그 글에서 고른 조합을 그대로 썼습니다. 용어는 업계에서 흔히 쓰는 뜻을 기준으로 적었고, 디자인 도구마다 부르는 이름이 조금씩 다를 수 있습니다.)

먼저 15개를 한 표로 모았습니다. ★는 바이브코딩을 하면서 꼭 알아 두면 좋은 이름입니다.

이름마다 정의, 띄워 놓은 비교 그림, 언제 쓰는지와 헷갈리는 짝, AI에게 시키는 요청문 순서로 적었습니다. 요청문은 5칸 중 이 이름에 필요한 칸만 채웠습니다.

사이트 전체를 오가는 메뉴

메뉴는 결국 "어디로 갈 수 있는지"를 보여 주는 목록입니다. 그런데 화면 폭과 메뉴 개수에 따라 놓는 방법이 달라지고 이름도 달라집니다. 좁은 화면에서 접어 두는 것, 넓은 화면에서 크게 펼치는 것, 엄지 아래에 늘 두는 것, 옆에 세워 두는 것, 단축키로 불러내는 것까지 다섯 가지를 차례로 보겠습니다.

1. 햄버거 메뉴 (Hamburger menu)

가로줄 세 개짜리 버튼을 누르면 메뉴가 열리는 방식입니다. 줄 세 개가 빵·패티·빵처럼 보여서 붙은 이름이라고 합니다. 휴대폰처럼 좁은 화면에서 헤더 메뉴를 접어 둘 때 가장 많이 씁니다.

크게 보기

같은 Brightlane 홈페이지에서 메뉴가 열리는 모양을 세 가지로 만들었습니다. 왼쪽은 헤더 바로 아래로 펼치는 드롭다운형, 가운데는 오른쪽에서 폭 300px 패널이 밀려 나오고 뒤 화면이 어두워지는 드로어형, 오른쪽은 화면 전체를 덮고 메뉴 글자를 크게 키운 전체 화면형입니다. 셋 다 햄버거 메뉴라고 부릅니다.

그러니까 햄버거 메뉴는 여는 버튼에 붙은 이름에 가깝고 열린 뒤의 모양은 따로 말해야 합니다. 메뉴가 네다섯 개뿐이면 드롭다운형, 메뉴 아래에 로그인이나 언어 선택까지 넣는다면 드로어형, 메뉴를 크게 보여 주고 싶은 브랜드 사이트라면 전체 화면형이 어울리는 편입니다. (드로어 자체는 5편 오버레이에서 자세히 다룹니다.)

햄버거 메뉴: 767px 이하에서 헤더 메뉴를 접고 오른쪽 위에 햄버거 버튼. 누르면 오른쪽에서 폭 300px 드로어가 밀려 나오고 메뉴 5개와 주 버튼을 세로로. 닫기 버튼·Esc·바깥 클릭·메뉴 클릭으로 닫힘. 열린 동안 뒤 화면 스크롤 잠금.

이만큼 적어야 하는지, "모바일 메뉴"라고만 해도 되는지가 이번 글의 실험입니다.

2. 메가 메뉴 (Mega menu)

메뉴를 열면 헤더 폭만큼 넓은 패널이 펼쳐지고 항목을 여러 열로 묶어 보여 주는 방식입니다. 상품 종류가 많은 쇼핑몰이나 서비스가 여럿인 회사 홈페이지에서 자주 봅니다.

크게 보기

그래픽 에셋 사이트 freeform의 Assets 메뉴를 드롭다운(왼쪽)과 메가 메뉴(오른쪽)로 열었습니다. 드롭다운은 폭 226px에 항목 다섯 개를 세로로 놓아서 옆 본문이 그대로 보입니다. 메가 메뉴는 창 폭 전체(660px)를 쓰면서 3D·2D·Motion 세 묶음에 항목 12개를 넣고 추천 팩 카드까지 올렸습니다. 같은 Assets인데 한 번에 보여 주는 길이 5개와 12개로 차이 납니다.

헷갈리는 짝은 왼쪽의 드롭다운 메뉴(Dropdown menu)입니다. 기준은 항목을 묶어야 읽히는지입니다. 세로 한 줄로 충분하면 드롭다운이고 제목을 붙여 묶어야 읽히면 메가 메뉴입니다.

메가 메뉴: 헤더의 'Assets'를 누르면 헤더 바로 아래에 전체 폭 패널. 3열(3D·2D·Motion)에 묶음 제목과 항목 4개씩, 오른쪽에 추천 카드 1장. 다시 누르거나 Esc·바깥 클릭으로 닫힘. 1023px 이하에서는 메가 메뉴 대신 햄버거 메뉴 안에서 접고 펴기로.

요청문에 "누르면"이라고 쓴 이유가 있습니다. 마우스를 올리면(호버) 열리게 만들면 마우스가 없는 휴대폰 동작을 따로 정해야 하고 항목까지 마우스를 옮기다 패널 밖으로 살짝 벗어나면 메뉴가 닫혀 버릴 수 있습니다. 호버로 열고 싶다면 "마우스가 벗어나도 0.3초는 유지"처럼 닫히는 조건까지 적어 두는 편이 좋다고 생각합니다.

3. 하단 탭 바 (Tab bar)

휴대폰 화면 맨 아래에 주요 메뉴 서너 개를 늘 보이게 둔 줄입니다. 한 손으로 쥐었을 때 엄지가 닿는 자리라서 앱에서 가장 많이 오가는 길을 둡니다. 맨 위에서 제목이나 위치를 보여 주는 줄은 짝으로 상단 바(App bar)라고 부릅니다.

크게 보기

숙소 앱 Driftnest의 제주 숙소 목록입니다. 왼쪽이 평소 화면이고 맨 위가 상단 바, 맨 아래 다섯 칸이 하단 탭 바입니다. 칸 수는 3~5개가 흔하고 아이콘만 두기보다 글자를 같이 쓰는 편이 무엇인지 바로 읽힙니다.

헷갈리는 짝은 햄버거 메뉴입니다. 햄버거 메뉴는 메뉴가 몇 개든 담을 수 있지만 한 번 더 눌러야 보이고 하단 탭 바는 늘 보이는 대신 다섯 칸 안팎이 한계입니다. 그래서 자주 오가는 화면이 서너 개인 앱은 하단 탭 바에 두고 나머지는 Profile 안쪽으로 넣는 식으로 나누는 경우가 많습니다.

가운데와 오른쪽 화면은 이 바에서 생기기 쉬운 문제를 일부러 만든 것입니다. 하단 탭 바는 본문 위에 떠 있어서 본문 맨 아래에 바 높이만큼 여백을 주지 않으면 마지막 내용이 바 뒤로 들어갑니다. 가운데는 끝까지 내렸는데도 Halla Pine Cabin의 가격과 Book 버튼이 가려졌고 오른쪽은 아래 여백 98px(바 86px + 12px)을 넣어서 버튼까지 다 보입니다. 위쪽 항목들은 멀쩡하고 마지막 항목에서만 드러나는 문제라서 만든 직후에는 놓치기 쉬운 것 같습니다.

하단 탭 바: 767px 이하에서 화면 맨 아래에 고정, 5칸(Explore·Saved·Trips·Inbox·Profile), 아이콘과 글자를 같이. 현재 칸은 색과 굵기로 표시. 본문 맨 아래에 바 높이만큼 여백을 주고 아이폰 홈 표시줄과 겹치지 않게. 768px 이상에서는 바를 숨기고 헤더 메뉴로.

4. 사이드 내비 (Side navigation)

1편의 사이드바 레이아웃이 한쪽에 좁은 세로 영역을 두는 자리 이야기였다면, 사이드 내비는 그 안에 들어가는 메뉴 구조를 부르는 말입니다. 메뉴가 열 개를 넘어가는 앱이나 관리자 화면에서 주로 씁니다.

크게 보기

숙소 호스트용 화면 Driftnest Host의 왼쪽 메뉴에 번호를 붙였습니다. HOSTING처럼 묶음 위에 붙은 작은 제목(1), 지금 보는 Pricing을 배경색으로 표시한 현재 위치(2), Listings 아래로 펼친 하위 메뉴(3), Inbox 옆 숫자 배지(4), 메뉴를 아이콘만 남기는 접기 버튼(5), 맨 아래 계정 메뉴(6)입니다. 포인트 색은 맨 위 New listing 버튼 하나에만 칠했습니다.

헷갈리는 짝은 아래 10번의 목차입니다. 둘 다 옆에 세로로 붙어 있어도 사이드 내비는 페이지 사이를 옮겨 다니고 목차는 한 페이지 안에서만 움직입니다.

사이드 내비: 왼쪽 사이드바의 메뉴를 묶음 2개(Hosting·Earnings)로 나누고 현재 페이지는 배경색으로 표시. Listings를 누르면 하위 메뉴 4개가 펼쳐지고 다시 누르면 접힘. 하위 메뉴는 두 단계까지만. 현재 페이지가 하위 메뉴 안에 있으면 처음부터 펼쳐 두기.

마지막 문장은 적어 두는 걸 추천합니다. 없으면 페이지를 새로 열 때마다 메뉴가 접힌 채로 시작해서 지금 위치가 안 보일 수 있습니다.

5. 커맨드 팔레트 (Command palette, ⌘K)

단축키 하나로 화면 가운데에 입력창을 띄워서 이름을 치면 페이지 이동이나 동작까지 바로 실행하는 창입니다. Mac은 ⌘K, Windows는 Ctrl+K를 쓰는 앱이 많습니다.

크게 보기

Brightlane 앱에서 같은 글자 design을 입력했습니다. 왼쪽 헤더 검색창은 일정 3건을 찾아 주는 데까지입니다. 오른쪽 커맨드 팔레트는 GO TO(이동) 2건과 RUN(실행) 3건을 같이 보여 주고 맨 아래에 화살표로 고르고 Enter로 실행하고 Esc로 닫는다는 안내가 있습니다. New event with Design team을 고르면 메뉴를 찾아 들어가지 않고 바로 일정 만들기가 시작되는 구조입니다.

헷갈리는 짝은 왼쪽의 검색창(Search bar)입니다. 검색창은 내용을 찾고 커맨드 팔레트는 메뉴와 동작까지 찾아서 실행합니다. 메뉴 위치를 외우지 않아도 되니 기능이 많은 앱에서 쓸모가 크고 메뉴가 다섯 개인 홈페이지에는 과한 것 같습니다.

커맨드 팔레트: 어느 화면에서든 ⌘K(Windows는 Ctrl+K)로 화면 가운데에 열림. 입력하면 결과를 '이동'과 '실행' 묶음으로 보여 주고 ↑↓로 고르고 Enter로 실행, Esc로 닫으면 열기 전 자리로 포커스 복귀. 결과가 없으면 '찾는 항목이 없습니다' 문구.

화면 안의 위치 표시

메뉴로 어떤 화면에 들어온 뒤에는 "지금 무엇을 보고 있고 어디까지 왔는지"를 알려 주는 표시가 필요합니다. 이름 네 개를 세 항목으로 묶었습니다.

6. 탭·세그먼트 컨트롤 (Tabs · Segmented control)

탭은 같은 자리에서 보는 내용을 바꾸는 줄이고 세그먼트 컨트롤은 붙어 있는 버튼 중 하나를 골라 같은 내용의 보기를 바꾸는 부품입니다. 생김새가 비슷해서 정지 화면 하나로는 구분이 안 되니 누르기 전과 후를 위아래로 쌓았습니다.

크게 보기

왼쪽 탭은 프로젝트 Q4 Launch에서 Overview를 보다가 Files를 눌렀습니다. 진행률 숫자가 있던 자리에 파일 목록이 들어와서 아래 내용이 통째로 바뀌었고 주소 끝에도 /files가 붙었습니다. 오른쪽 세그먼트 컨트롤은 캘린더에서 Week를 Month로 바꿨습니다. 보는 단위만 달라졌고 Standup부터 Demo day까지 일정 다섯 개는 그대로입니다.

구분법은 간단합니다. 눌렀을 때 아래가 다른 이야기가 되면 탭, 같은 이야기를 다르게 보여 주면 세그먼트 컨트롤입니다.

탭: 프로젝트 화면에 Overview·Timeline·Files·Members 네 탭, 현재 탭은 밑줄. 누르면 아래 내용만 바뀌고 주소에 탭 이름이 남아서 새로고침해도 같은 탭. 키보드 왼쪽·오른쪽 화살표로도 이동. 세그먼트 컨트롤: 캘린더 제목 아래에 Week·Month 두 칸을 붙이고 고른 칸은 진한 배경. 일정은 그대로 두고 보는 단위만 바꿈.

"주소에 탭 이름이 남아서"는 Files 화면 링크를 동료에게 보낼 때 필요합니다. 이 한 줄이 없으면 새로고침할 때마다 첫 탭으로 돌아가는 탭이 나올 수 있습니다.

7. 브레드크럼 (Breadcrumb)

지금 페이지까지 사이트 구조를 따라 내려온 길을 한 줄로 보여 주는 표시입니다. 이름의 유래는 0편에 적었습니다.

크게 보기

Driftnest 숙소 상세 화면입니다. Home / South Korea / Jeju / Aewol / Cliffside House 다섯 단계 중 앞의 네 개는 링크이고 마지막은 지금 보는 페이지라서 글자만 둡니다. 휴대폰에서는 다섯 단계가 한 줄에 들어가지 않아 바로 위 단계 하나만 ‹ Aewol로 남겼습니다.

헷갈리는 짝은 브라우저의 뒤로 가기입니다. 뒤로 가기는 내가 지나온 기록을 되감고 브레드크럼은 사이트 구조에서 한 단계 위로 올라갑니다. 검색에서 이 숙소로 바로 들어온 사람은 뒤로 가기를 누르면 검색 결과로 나가지만 Aewol을 누르면 애월 숙소 목록으로 갑니다. 두 단계뿐인 얕은 사이트라면 없어도 괜찮습니다.

브레드크럼: 제목 위에 Home / South Korea / Jeju / Aewol / Cliffside House. 앞 단계는 링크, 마지막 현재 페이지는 글자만. 767px 이하에서는 바로 위 단계만 '‹ Aewol'로 줄이기.

8. 스테퍼 (Stepper)

결제나 가입처럼 순서가 있는 일을 단계로 나눠서 전체 단계와 지금 단계를 같이 보여 주는 표시입니다.

크게 보기

같은 예약 결제 화면의 윗부분만 바꿨습니다. 왼쪽 스테퍼는 Dates·Guests가 체크로 끝났고 3번 Payment가 지금 단계이고 4번 Confirm이 남았다는 걸 이름으로 보여 줍니다. 오른쪽 프로그레스 바(Progress bar)는 75%까지 찬 막대라서 얼마나 왔는지는 보이지만 다음에 무엇을 하는지는 보이지 않습니다.

그래서 사람이 단계마다 입력하는 일에는 스테퍼, 파일 업로드처럼 기다리기만 하는 일에는 프로그레스 바가 어울립니다.

스테퍼: 예약을 4단계(Dates·Guests·Payment·Confirm)로 나눠 맨 위에 표시. 끝낸 단계는 체크 표시에 눌러서 돌아갈 수 있고 아직 안 간 단계는 눌리지 않음. 돌아가도 입력한 값은 유지. 767px 이하에서는 'Step 3 of 4 · Payment' 한 줄로.

긴 내용 안에서 움직이기

내용이 길어지면 화면 사이를 옮기는 것보다 한 화면 안에서 움직이는 게 문제가 됩니다. 목록이 길 때, 글이 길 때, 그리고 끝까지 내려간 뒤에 쓰는 이름들입니다.

9. 페이지네이션·더 보기·무한 스크롤 (Pagination · Load more · Infinite scroll)

셋 다 긴 목록을 조금씩 보여 주는 방법입니다. 페이지네이션은 쪽 번호로 나누고, 더 보기는 버튼을 누를 때마다 아래에 이어 붙이고, 무한 스크롤은 바닥에 닿으면 저절로 이어 붙입니다.

크게 보기

freeform에서 3d shapes를 검색한 결과 2,400개를 세 방식으로 만들어 끝까지 내렸습니다. 왼쪽 페이지네이션은 주소에 page=2가 남고 쪽 번호 아래로 푸터가 보입니다. 가운데 더 보기는 48개까지 본 상태에서 Load 24 more 버튼 아래로 푸터가 보입니다. 오른쪽 무한 스크롤은 78개째를 지나도 빈 카드가 계속 붙어서 푸터가 나오지 않습니다.

고르는 기준은 다음과 같습니다.

• 같은 자리로 돌아오거나 주소를 공유해야 하면(검색 결과, 게시판) 페이지네이션
• 구경하다가 더 보고 싶을 때(상품 목록, 갤러리) 더 보기
• 끝없이 흘려 보는 피드는 무한 스크롤

무한 스크롤은 편한 대신 맨 아래 회사 정보나 이용약관에 닿기 어렵습니다. 상세 화면에 갔다가 돌아왔을 때 불러온 항목이 사라지면 맨 위부터 다시 내려야 하는 것도 불편한 지점입니다. 그래서 푸터가 있는 사이트라면 더 보기를 먼저 고려해 볼 만한 것 같습니다.

페이지네이션: 검색 결과를 24개씩, 아래에 이전·다음·쪽 번호, 현재 쪽은 진한 배경. 주소에 ?page=2를 남겨 새로고침과 뒤로 가기에도 같은 쪽. 더 보기: 처음 24개, 'Load 24 more'를 누르면 아래에 이어 붙이고 몇 개 중 몇 개를 봤는지 표시. 끝까지 보면 버튼 숨김. 무한 스크롤: 바닥에 닿기 전에 다음 24개를 불러오고 불러오는 동안 빈 카드 표시. 끝나면 '마지막 결과입니다' 문구 뒤에 푸터 표시. 상세 화면에 갔다가 뒤로 오면 보던 자리로.

10. 목차·스크롤 스파이 (Table of contents · Scroll spy)

긴 글이나 문서 옆에 그 페이지의 제목들을 모아 둔 것이 목차이고 스크롤에 따라 지금 읽는 제목을 목차에 표시해 주는 동작이 스크롤 스파이입니다.

크게 보기

freeform의 Licensing 문서를 끝까지 내렸다가 돌아왔습니다. 오른쪽 목차의 강조 표시가 Free license부터 Refunds & updates까지 따라 내려오고 마지막에 Commercial use를 누르면 그 제목이 스티키 헤더 바로 아래로 올라옵니다. 왼쪽의 Getting started·Licensing 같은 줄은 위 4번 사이드 내비라서 페이지 사이를 옮기고 오른쪽 목차는 이 페이지 안에서만 움직입니다.

이 그림을 만들면서 실제로 걸린 곳이 하나 있습니다. 보통은 제목이 화면 위쪽 기준선(그림의 점선)을 지나면 지금 읽는 제목으로 표시합니다. 그런데 마지막 제목 Refunds & updates는 페이지가 먼저 끝나서 스크롤을 끝까지 내려도 기준선까지 올라오지 못했습니다. 끝까지 읽었는데 목차는 한 칸 위에 머무는 겁니다. 그래서 "맨 끝에 닿으면 마지막 항목을 표시"한다는 규칙을 따로 넣어야 했습니다.

목차: 문서 오른쪽에 제목 5개를 붙여 두고(스크롤해도 제자리), 누르면 그 제목으로 이동하되 스티키 헤더에 가리지 않게. 스크롤 스파이: 지금 읽는 제목을 목차에서 굵게 표시, 페이지 맨 끝에서는 마지막 항목 표시. 1023px 이하에서는 목차를 본문 맨 위로 옮기기.

11. 맨 위로 버튼 (Back to top)

아주 긴 페이지를 내려간 뒤 누르면 맨 위로 돌아오는 버튼입니다. 오른쪽 아래에 동그랗게 떠 있는 모양이 흔합니다.

크게 보기

웰니스 서비스 neurolume의 같은 긴 글을 두 휴대폰에 띄워 끝까지(2,313px) 내렸습니다. 왼쪽은 손으로 여러 번 쓸어 올려야 하고 오른쪽은 버튼 한 번에 맨 위로 갑니다. (장면 속 속도는 보여 주기 위한 연출이고 잰 값은 아닙니다.) 오른쪽 버튼은 스크롤 600px을 넘어야 나타나고 맨 위로 돌아오면 사라집니다.

처음부터 떠 있으면 내용만 가리니 "내려간 뒤에만 나타남"이 이 버튼의 핵심입니다. 위 3번의 하단 탭 바가 있는 화면이라면 같은 자리를 두고 겹치기 쉬우니 바 위로 띄워 달라고 적어 두는 게 안전합니다.

맨 위로 버튼: 스크롤 600px을 넘으면 오른쪽 아래에 나타나고 맨 위에서는 숨김. 누르면 맨 위로 부드럽게 이동, 모션 줄이기 설정이면 바로 이동. 하단 탭 바가 있으면 바 위로 16px 띄우기.

"모바일 메뉴" 한마디와 동작 지정

용어를 정리하다 보니 1편 때와 같은 궁금증이 생겼습니다. 지금 AI는 "모바일 메뉴"라고만 해도 햄버거 버튼을 만들어 줍니다. 그럼 이름과 동작을 적어 주면 어디가 달라질까요?

같은 Driftnest 홈페이지를 두 가지로 Claude Code에 시켰습니다. Claude Code 2.1.318을 화면 없이 실행하는 모드(claude -p)로, 모델은 따로 지정하지 않았고(두 번 모두 Claude Opus 5.5로 돌았습니다) 두 요청을 각각 새 세션에서 같은 시각에 한 번씩 돌렸습니다.

두 요청 앞부분은 글자까지 똑같습니다.

숙소 예약 서비스 'Driftnest'의 홈페이지를 HTML 파일 하나로 만들어줘. 색은 바탕 #FCFFFF, 보조 #0593C6, 포인트 #D1318F 세 가지와 흰색·회색만 쓰고 포인트는 '숙소 찾기' 버튼에만. (중략)

1. 스티키 헤더: 로고, 메뉴 5개(Stays·Experiences·Hosts·Journal·Help), 'Sign in' 버튼. 메뉴를 누르면 해당 섹션으로 이동
2. 히어로: 제목·설명·'숙소 찾기' 버튼
3. Stays: 숙소 카드 6개(사진·이름·지역·1박 가격) (중략: Experiences, Hosts, Journal, Help 섹션과 푸터)

A는 그 뒤에 한 줄만 붙였습니다.

(A) 휴대폰에서는 모바일 메뉴로 만들어줘.

B는 이름과 동작을 적었습니다.

(B) 휴대폰(767px 이하)에서는 헤더 메뉴를 햄버거 메뉴로 접어줘.

• 헤더 오른쪽 햄버거 버튼을 누르면 화면 오른쪽에서 폭 300px 드로어가 밀려 나오고, 안에 메뉴 5개와 Sign in 버튼을 세로로 놓기.
• 닫기(X) 버튼, Esc, 드로어 바깥 클릭, 메뉴 항목 클릭으로 닫힘.
• 열리면 포커스는 첫 메뉴로, 닫히면 햄버거 버튼으로 돌아감. 열린 동안 Tab은 드로어 안에서만 돌고, 닫혀 있을 때는 드로어 안 링크로 Tab이 들어가지 않게.
• 열린 동안 뒤 화면 스크롤은 잠금. 창이 768px 이상으로 넓어지면 드로어는 닫히고 스크롤 잠금도 풀림.
• 기기에서 모션 줄이기를 켠 사용자에게는 애니메이션을 끔.

여기서 포커스(Focus)는 키보드 입력이 지금 어디에 가 있는지를 뜻합니다. Tab 키로 다음 칸으로 옮기고 Enter로 누릅니다. 마우스를 쓰기 어렵거나 화면을 읽어 주는 프로그램을 쓰는 사람에게는 이 순서가 곧 메뉴라서 이번에는 키보드 조작까지 재 봤습니다.

만들어진 HTML은 손대지 않고 Chromium에서 390×844 창으로 열었습니다. 버튼 클릭, Esc, Tab, 마우스 휠 같은 동작은 Playwright(브라우저를 코드로 조작하는 도구) 스크립트로 실제로 해 보고 값은 스크린샷과 코드에 하나씩 맞춰 봤습니다.

크게 보기

결과부터 말하면 A도 꽤 잘 만들었습니다. A는 헤더 아래로 펼치는 드롭다운형을 골랐고 B는 적은 대로 오른쪽 드로어입니다. 동작을 재 보니 A는 시키지 않았는데도 Enter와 Space로 열리고, Esc로 닫으면 버튼으로 포커스가 돌아오고, 바깥을 누르면 닫히고, 메뉴를 누르면 닫히면서 이동합니다. 닫혀 있을 때 안 보이는 메뉴로 Tab이 들어가지도 않았고 창을 넓히면 저절로 닫혔고 모션 줄이기 설정까지 지켰습니다. 메뉴를 열고 고르고 닫는 것만 해 보면 모양 말고는 A와 B의 차이가 없습니다.

차이는 세 군데에서 났습니다. 첫 번째는 메뉴가 열린 동안의 뒤 화면입니다.

크게 보기

메뉴를 연 채 마우스 휠을 1,000px만큼 돌렸습니다. A는 메뉴가 열려 있는데 패널 아래로 뒤 화면이 계속 내려갑니다. B는 뒤 화면이 잠겨서 움직이지 않습니다. A의 메뉴는 화면 일부만 덮는 모양이라 틀렸다고 보긴 어렵습니다. 다만 메뉴를 닫았을 때 보던 자리가 달라져 있을 수 있습니다.

바깥을 눌렀을 때도 같은 이유로 갈렸습니다. A는 뒤 화면을 가리는 막이 없어서 메뉴 바깥의 FAQ 첫 줄을 누르면 메뉴가 닫히면서 그 FAQ까지 같이 열렸습니다. B는 어두운 막이 클릭을 받아서 드로어만 닫히고 FAQ는 그대로였습니다.

두 번째는 키보드입니다. Enter로 메뉴를 열고 Tab을 일곱 번 눌렀습니다.

크게 보기

A는 Sign in 다음에 메뉴가 열린 채로 뒤 화면으로 빠져나갔습니다. 일곱 번째 포커스는 패널 뒤에 가린 '숙소 찾기' 버튼에 가 있어서 왼쪽 화면 어디에도 포커스 테두리가 보이지 않습니다. 키보드로 쓰는 사람에게는 지금 어디에 있는지 보이지 않는 상태입니다. B는 닫기 버튼 다음에 Stays로 돌아옵니다. 적은 대로 드로어 안 일곱 곳만 돕니다.

세 번째는 제 요청문이 틀린 곳입니다. 이번에는 키보드로 메뉴에서 Journal을 고른 뒤 Tab을 한 번 눌렀습니다.

크게 보기

A는 Journal로 내려간 뒤 Tab을 누르면 다음 순서인 FAQ 첫 줄로 이어집니다. 그런데 B는 6,616px에 있던 화면이 맨 위(0px)로 튕겼습니다.

원인은 제가 쓴 "닫히면 햄버거 버튼으로 돌아감"입니다. Esc나 닫기 버튼으로 닫을 때는 맞는 말인데 메뉴 항목을 골라 다른 곳으로 이동할 때도 포커스가 헤더의 버튼으로 돌아갔습니다. 화면은 Journal에 있는데 포커스만 맨 위에 남은 것입니다. 그래서 다음 Tab이 헤더 바로 다음 순서인 히어로의 버튼으로 가면서 화면이 끌려 올라갑니다. 기록을 열어 보니 B 세션은 자기 점검에서 이 항목이 한 번 실패하자 링크의 기본 이동을 막고 직접 스크롤하게 고쳐서 제 문장을 지켰습니다. AI는 시킨 대로 했고 시킨 문장이 틀렸습니다.

확인한 항목을 표로 정리했습니다.

몇 가지를 더 적어 두겠습니다.

• 두 세션 기록을 열어 보니 스스로 확인한 범위가 크게 달랐습니다. A는 메뉴를 클릭하고 Esc와 바깥 클릭을 해 봤지만 Tab은 한 번도 누르지 않았습니다. B는 색 규칙부터 드로어 동작까지 47개 항목의 점검 스크립트를 스스로 써서 Tab, Shift+Tab, 휠, 모션 줄이기까지 돌렸고 첫 실행에서 46개 통과, 1개 실패가 나오자 고쳤습니다. 동작을 적으면 그 문장이 AI의 점검표가 되는 것 같습니다. A에서 Tab이 패널 뒤로 샌 게 이 때문인지는 한 번씩 돌린 것으로는 알 수 없습니다.
• 햄버거로 바뀌는 폭이 달라서 768px 태블릿 폭에서는 A는 햄버거, B는 메뉴가 펼쳐진 화면이었습니다. 1편의 결론대로 폭을 적은 쪽만 적은 자리에서 바뀌었습니다.
• 숫자 지어내기는 이번에도 나왔습니다. A는 "숙소 2,400곳, 평균 평점 4.9, 평균 응답 시간 3분", B는 "숙소 1,200여 곳, 호스트 840+, 수수료 3%"를 넣었습니다. 같은 서비스인데 숙소 수가 두 배 차이 납니다.

내비게이션 요청문 모음

위에서 용어마다 적은 요청문을 메뉴부터 긴 목록까지 순서대로 이어 붙였습니다. 2번은 실험에서 틀린 문장을 고쳐서 닫는 경로마다 포커스를 나눠 적었습니다. 숫자는 예시라서 본인 화면에 맞게 바꿔 쓰시면 되고 결과가 어떻게 나와도 괜찮은 줄은 지워도 됩니다.

1. 메뉴 구성: 데스크톱은 헤더에 메뉴 5개, 항목이 많으면 메가 메뉴. 앱이면 767px 이하에서 하단 탭 바 5칸.
2. 햄버거 메뉴: 767px 이하에서 오른쪽 위 버튼, 폭 300px 드로어. 닫기 버튼·Esc·바깥 클릭으로 닫으면 포커스는 햄버거 버튼으로, 메뉴 항목을 골라 이동하면 포커스는 이동한 섹션으로. 열린 동안 Tab은 드로어 안에서만, 뒤 화면 스크롤 잠금, 바깥 클릭이 뒤 화면을 누르지 않게.
3. 현재 위치: 지금 페이지는 메뉴에서 표시. 3단계 이상 깊으면 브레드크럼, 767px 이하에서는 바로 위 단계만.
4. 같은 화면에서 바꾸기: 내용이 바뀌면 탭(주소에 탭 이름 남기기), 보기만 바뀌면 세그먼트 컨트롤.
5. 순서가 있는 일: 스테퍼로 단계 이름 표시, 끝낸 단계로 돌아가도 입력값 유지.
6. 긴 목록: 페이지네이션(주소에 쪽 번호) 또는 더 보기, 푸터가 있으면 무한 스크롤은 피하기.
7. 긴 글: 목차를 옆에 붙이고 스크롤 스파이로 지금 제목 표시, 맨 끝에서는 마지막 항목 표시. 이동한 제목이 스티키 헤더에 가리지 않게. 스크롤 600px부터 맨 위로 버튼.
8. 다 만든 뒤 Tab과 Esc만으로 메뉴를 열고 고르고 닫아 보고, 포커스가 안 보이거나 화면이 튀는 곳을 고쳐 줘.
9. 숫자·후기·고객사 이름은 지어내지 말고 자리만 비워 두기.

개인적인 생각 & 한계점

이번 실험 전에는 "모바일 메뉴"라고만 쓰면 키보드로는 쓸 수 없는 메뉴가 나올 거라고 생각했습니다. 막상 해 보니 Esc와 포커스 복귀까지 알아서 넣었고 가장 눈에 띄는 문제는 오히려 제 문장에서 나왔습니다. 그래서 내비게이션 이름의 쓸모를 상황별로 나눠 봤습니다.

1. 혼자 쓰거나 가볍게 만드는 경우 - "모바일 메뉴" 한마디로도 충분할 수 있다고 생각합니다. 열고 고르고 닫는 것까지는 A와 B가 같았습니다.

2. 여러 사람이 쓰는 서비스인 경우 - 드로어라는 이름과 동작 줄을 적는 걸 추천합니다. 뒤 화면 스크롤 잠금과 Tab 순서처럼 메뉴를 한 번 열어 보는 것으로는 드러나지 않는 곳에서 차이가 났고 적어 두면 AI가 그걸 자기 점검 항목으로 씁니다. 요청 끝에 "Tab과 Esc만으로 써 보고 고쳐 줘"를 붙이는 것만으로도 비슷한 효과가 날 것 같습니다(이 문장만 따로 시험해 보진 않았습니다).

3. 동작 문장을 직접 쓰는 경우 - 개인적으로 이번에 가장 크게 배운 부분입니다. 0편의 결론이 "비운 칸은 AI가 채운다"였는데 여기에 "적은 칸은 틀려도 그대로 지킨다"가 더해졌습니다. "닫히면"처럼 여러 경우를 한 단어로 묶으면 AI는 전부에 똑같이 적용합니다. 닫는 경로가 여럿이면 경로마다 나눠 적는 편이 안전합니다.

한계도 적어 두겠습니다.

• 실험은 A·B 각 1회입니다. "모바일 메뉴"라고 하면 항상 드롭다운이 나오거나 Tab이 샌다는 뜻은 아닙니다. 같은 요청도 돌릴 때마다 결과가 달라집니다.
• B 세션은 A보다 훨씬 많이 스스로 점검했습니다. 결과 차이가 요청 내용 때문인지 이 점검 때문인지는 이번 실험으로 나눌 수 없습니다.
• 측정은 Chromium의 390px 창에서 마우스 휠과 키보드로 했습니다. 실제 휴대폰의 터치 스크롤이나 화면을 읽어 주는 프로그램으로는 확인하지 않았습니다.
• 스크립트가 처음에 틀린 곳이 있었습니다. 두 페이지 모두 부드러운 스크롤을 쓰고 있어서 Tab 직후에 재니 포커스가 화면 밖에 있다고 A 28곳, B 33곳을 잘못 짚었습니다. 스크롤이 멈춘 뒤 재고 스크린샷과 맞춰서 바로잡았습니다. A의 세 줄 버튼을 닫기 버튼으로 따로 센 것도 코드를 보고 고쳤습니다.
• 용어별 그림은 이 글을 위해 직접 만든 가상의 화면이고 치수는 흔히 쓰는 예시일 뿐 정답 값은 아닙니다.
• 용어는 디자인 도구마다 부르는 이름이 조금씩 다릅니다. 하단 탭 바를 Bottom navigation, 세그먼트 컨트롤을 Button group, 스테퍼를 Wizard라고 부르는 곳도 있어서 쓰는 도구가 있다면 그 도구의 이름을 따르는 게 안전합니다.

이 글을 마치며

다음 글에서는 3편 콘텐츠 표시를 다루겠습니다. 카드 구조부터 아코디언, 캐러셀, 데이터 테이블, 요금표까지 "정보를 무엇에 담을까"에 해당하는 이름들입니다. 상품 카드에 긴 제목과 빈 이미지를 넣어서 깨지는지 보는 실험도 같이 해 볼 생각입니다.

같이 보면 좋은 글은 다음과 같습니다.

• 바이브코딩 UI 용어 사전 1편 레이아웃 : 스티키 헤더와 사이드바처럼 이 글의 메뉴가 놓이는 자리를 먼저 정리했습니다. 반응형 구간을 나누는 법도 여기 있습니다.
• 바이브코딩 UI 용어 사전 0편 : 화면 세 장의 이름표, 요청문 5칸, 시리즈 9편의 순서가 있습니다. 이 글의 요청문도 그 5칸을 따랐습니다.
• 포인트 컬러 고르는 법 : 이 글의 가상 브랜드와 색이 모두 여기서 나왔습니다. 포인트 색을 CTA 버튼에만 칠한 이유도 여기 있습니다.

긴 글 읽어주셔서 감사합니다 :)