헤더 내비게이션에 도구 12개 전체 노출과 모바일 햄버거 메뉴 적용
목차
헤더 내비게이션을 전면 개편했다. 12개 도구 전체를 노출하면서 동시에 모바일 햄버거 메뉴와 수평 스크롤까지 한 번에 밀어넣은 작업이었음.
왜 이 시점에 헤더를 손댔나
도구 수가 늘어나면 늘어날수록 헤더는 언제나 골치다. 처음엔 "나중에 정리하지"로 미뤘다가, 12개까지 쌓이고 나서야 진짜 문제가 눈에 들어왔다. 일부 도구는 헤더에 있고 일부는 숨겨진 상태로 운영되고 있었는데, 이게 팀 안에서도 "이 도구 어디 있어요?" 같은 질문이 나오는 수준이었음. UX 문제라기보다 진입점 자체가 일관성 없는 상태였던 거다.
12개 전체를 노출하기로 결정한 건 단순한 UI 욕심이 아니라, "있는 기능을 숨기지 말자"는 원칙에 가까웠다. 메뉴에 없으면 없는 것과 다름없고, 팀이 공들여 만든 도구가 묻히는 건 낭비다.
변경 구조 — 두 파일, 세 가지 과제
| 파일 | 역할 | 이번 변경 포인트 |
|---|---|---|
Header.astro |
실제 내비게이션 마크업 / 스타일 / 인터랙션 | 12 도구 전체 링크, 햄버거 토글, 수평 스크롤 |
Layout.astro |
전체 페이지 래퍼 | 헤더 레이아웃 흐름 조정, 모바일 뷰포트 대응 |
세 가지 과제가 동시에 얽혀 있었다.
- 12개 도구 전체 노출 — 링크 목록 자체는 단순하지만, 길어지면 데스크톱에서 줄바꿈이 일어나거나 레이아웃이 깨짐
- 수평 스크롤 — 도구가 많을 때 overflow를 clip 하지 않고 스크롤로 흘리는 방식. 항목이 더 늘어도 구조를 바꾸지 않아도 됨
- 모바일 햄버거 — 작은 화면에서는 전체 목록을 처음부터 다 보여주는 게 오히려 독이 됨. 햄버거로 접어두되, 토글은 JS 최소화로 처리
수평 스크롤이냐 줄바꿈이냐는 꽤 고민했다. 줄바꿈을 허용하면 헤더 높이가 동적으로 변하는 문제가 생기고, 레이아웃 전체가 들썩인다. 수평 스크롤은 그 문제를 없애는 대신, "스크롤 가능한 헤더"라는 걸 사용자가 인지해야 한다는 UX 비용이 있음.
/* 수평 스크롤 핵심 패턴 */
.nav-list {
display: flex;
flex-wrap: nowrap;
overflow-x: auto;
-webkit-overflow-scrolling: touch;
scrollbar-width: none; /* Firefox */
}
.nav-list::-webkit-scrollbar {
display: none; /* Chrome/Safari */
}
스크롤바를 숨기는 건 약간 논쟁적인 패턴이다. "스크롤 가능하다는 단서가 사라진다"는 주장도 맞다. 다만 헤더 nav처럼 좁은 공간에서 스크롤바가 보이면 오히려 시각적으로 더 지저분해지는 경우가 많아서, 이번엔 숨기는 쪽으로 결정했음. 끝에 그라디언트 fade로 "더 있음"을 암시하는 방법도 있는데, 그건 다음 이터레이션에서.
햄버거 토글 — JS를 얼마나 쓸 것인가
Astro 환경에서 인터랙션을 넣을 때 항상 드는 고민이다. 클라이언트 사이드 JS를 최소화하는 게 Astro의 기본 철학인데, 햄버거 토글 정도는 굳이 프레임워크 컴포넌트를 안 써도 된다.
<!-- Astro 내 인라인 script 패턴 -->
<button id="hamburger" aria-expanded="false" aria-controls="mobile-nav">
☰
</button>
<nav id="mobile-nav" hidden>
<!-- 12개 링크 -->
</nav>
<script>
const btn = document.getElementById('hamburger');
const nav = document.getElementById('mobile-nav');
btn?.addEventListener('click', () => {
const expanded = btn.getAttribute('aria-expanded') === 'true';
btn.setAttribute('aria-expanded', String(!expanded));
nav?.toggleAttribute('hidden');
});
</script>
aria-expanded와 hidden 속성을 쓰는 게 포인트다. CSS display: none 토글로만 처리하면 스크린 리더가 열림/닫힘 상태를 모른다. 팀에서 코드리뷰할 때 이 부분 빠진 PR이 종종 올라오는데, "동작은 하는데 접근성이 빠진" 케이스가 의외로 많아서 체크리스트에 넣어두는 걸 권장하고 있음.
회고
솔직히 처음엔 "헤더 하나 고치는 게 얼마나 걸리겠어"였다. 막상 12개를 전부 넣으니 데스크톱 → 태블릿 → 모바일 세 단계 뷰포트를 동시에 잡아야 했고, 수평 스크롤/햄버거/접근성 세 가지가 서로 얽혀서 생각보다 손이 많이 갔다. Layout.astro까지 건드려야 했던 것도 처음엔 예상 못 했다.
헤더는 모든 페이지 위에 얹히는 컴포넌트라 영향 범위가 넓다. 작은 변경처럼 보여도 실제론 전체 레이아웃의 기준선을 바꾸는 작업이다. 도구 수가 더 늘어도 구조를 유지할 수 있도록 만들어 뒀으니, 당분간은 헤더 때문에 손 댈 일은 없을 것 같다.
끝.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.