사이드 메뉴(Side navigation) 완전 해부 — KRDS 공식 기준

공공 서비스의 어느 부서 안내 페이지에 들어갔다고 해봅시다. 본문은 화면 가운데에 펼쳐져 있고, 왼쪽에는 세로로 길게 늘어선 메뉴가 있습니다. "조직 안내 / 주요 업무 / 자료실 / 공지사항…" 우리는 이 왼쪽 기둥을 따라 눈을 내려가며 원하는 항목을 찾습니다. 그러다 한 항목을 누르면 그 아래로 하위 메뉴가 주르륵 펼쳐지고, 또 그 안에서 더 깊은 페이지로 들어갑니다. 이게 우리가 매일 무심코 쓰는 "사이드 메뉴(Side navigation)"입니다.

사이드 메뉴는 공공 웹사이트에서 가장 자주 보지만 가장 적게 의식되는 컴포넌트입니다. 사람들은 보통 "본문이 어디 있나"에만 집중하지, 왼쪽 메뉴가 어떻게 만들어졌는지는 신경 쓰지 않습니다. 그런데 사실 공공 사이트에서 사용자가 길을 잃느냐 마느냐는 이 사이드 메뉴 하나에 크게 달려 있습니다. 정부 사이트는 메뉴가 깊습니다. 부서가 많고, 업무가 많고, 자료가 많으니까요. 그 수십·수백 개의 페이지를 사용자가 헤매지 않고 찾아가게 해주는 길잡이가 바로 사이드 메뉴입니다. 이게 잘못 만들어지면, 사용자는 분명히 어딘가에 있는 정보를 끝내 못 찾고 돌아갑니다.

현업에서 보면, 사이드 메뉴는 "한 번 만들어 놓고 다시는 안 보는" 컴포넌트 취급을 받습니다. 사이트 초기에 정보 구조(IA)를 짤 때 한 번 정해지고, 그다음부터는 메뉴 항목만 늘었다 줄었다 할 뿐, "이게 키보드로 다 펼쳐지나", "스크린리더가 메뉴 구조를 읽나", "지금 어느 메뉴에 있는지 표시되나" 같은 건 거의 점검되지 않습니다. 그 결과가 우리가 자주 마주치는, 펼쳐지긴 하는데 어딘가 어색한 왼쪽 메뉴들입니다.

이 글에서는 KRDS(대한민국 정부 디자인 시스템)가 사이드 메뉴를 어떻게 정의하고 무엇을 요구하는지를, 공식 가이드라인과 컴포넌트 킷을 기준으로 하나하나 뜯어보겠습니다. "이렇게 하면 보기 좋다"가 아니라 "정부 표준은 이걸 요구한다"는 사실 기준으로요. 그리고 그 기준을 우리 사이트가 실제로 지키고 있는지 어떻게 확인하는지까지 이어가겠습니다. 다 읽고 나면, 앞으로 어떤 공공 사이트에서든 왼쪽 메뉴를 볼 때마다 "이건 잘 만든 사이드 메뉴, 저건 위험한 사이드 메뉴"가 눈에 들어오실 겁니다.

사이드 메뉴가 대체 뭘 하는 컴포넌트인가 — 정의부터 정확히

먼저 용어를 맞추겠습니다. 우리가 화면에서 보는 "메뉴"는 사실 종류가 여럿입니다. KRDS는 이 탐색(navigation) 컴포넌트들을 역할에 따라 구분합니다.

• 메인 메뉴(상단 GNB): 사이트 전체의 큰 분류. 보통 화면 맨 위 가로로 펼쳐집니다. "사이트 전체를 어디로 갈지" 정하는 1차 길잡이입니다.
• 사이드 메뉴(Side navigation): 특정 영역(부서, 카테고리, 서비스) 안에서 하위 페이지를 탐색하는 세로 메뉴. 보통 본문 옆(주로 왼쪽)에 기둥처럼 섭니다. "지금 이 동네 안에서 어느 골목으로 갈지" 정하는 2차 길잡이입니다.
• 콘텐츠 내 탐색(In-page navigation): 한 페이지 안의 긴 내용을 목차처럼 건너뛰는 탐색. 사이드 메뉴와 모양이 비슷해 보여도 역할이 다릅니다.
• 브레드크럼(Breadcrumb): "홈 > 조직 > 총무과"처럼 현재 위치의 경로를 알려주는 띠.

이 구분이 왜 중요하냐면, 모양이 비슷하다고 아무거나 같은 코드로 만들면 사용자가 "이게 사이트 전체 메뉴인지, 이 영역 안의 메뉴인지"를 헷갈리기 때문입니다. 사이드 메뉴의 핵심 정체성은 딱 하나입니다. "지금 사용자가 들어와 있는 영역의, 형제·하위 페이지들을 보여주는 것." 그래서 사이드 메뉴는 늘 "지금 내가 어디에 있고, 같은 묶음 안에 또 어떤 페이지가 있는지"를 알려주는 역할을 합니다. 이 정체성을 잃으면, 그냥 링크가 세로로 늘어선 덩어리일 뿐 길잡이 기능을 못 합니다.

KRDS 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux)을 열어 보면 탐색 계열 컴포넌트들이 역할별로 나뉘어 제공됩니다. 사이드 메뉴는 그중에서도 "본문 옆에서 영역 내부를 탐색하는" 패턴으로 정리돼 있습니다. KRDS가 이걸 메인 메뉴와 별도 컴포넌트로 둔다는 사실 자체가 메시지입니다 — "상단 메뉴와 사이드 메뉴는 역할이 다르니, 따로 설계하라"는 것.

사이드 메뉴가 가진 세 가지 일

사이드 메뉴는 겉보기엔 단순히 링크 목록 같지만, 실제로는 동시에 세 가지 일을 합니다. 이 세 가지가 다 돼야 "제대로 된 사이드 메뉴"입니다.

① 구조 보여주기 — 이 영역 안에 어떤 페이지들이 있는지, 그것들이 어떻게 묶여 있는지(상위-하위 관계)를 한눈에 보여줍니다. 사용자는 메뉴를 슥 훑는 것만으로 "아, 이 부서는 이런 일들을 하는구나"를 짐작합니다. 사이드 메뉴는 그 자체로 영역의 지도입니다.

② 현재 위치 알려주기 — 지금 보고 있는 페이지가 메뉴의 어느 항목인지 강조해서 표시합니다. 이게 없으면 사용자는 "내가 지금 어디 있지?"를 늘 헷갈립니다. 깊은 메뉴일수록 이 "현재 위치" 표시가 생명입니다.

③ 이동시키기 — 다른 형제·하위 페이지로 빠르게 건너뛰게 합니다. 본문을 끝까지 읽고 다시 위로 올라가 상단 메뉴를 찾을 필요 없이, 옆 기둥에서 바로 다음 페이지로 갈 수 있죠.

이 세 가지를 머릿속에 넣어 두면, 뒤에서 볼 KRDS 요건들이 왜 필요한지 자연스럽게 이해됩니다. 요건 대부분이 결국 "이 세 가지 일을 모든 사용자에게 똑같이 해주려면 무엇이 필요한가"에서 나오거든요.

KRDS는 사이드 메뉴에 무엇을 요구하나 — 기준 완전 해부

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서를 기준으로, 사이드 메뉴가 충족해야 하는 요건을 영역별로 정리하겠습니다.

1) 의미 있는 마크업 — "링크 묶음"이 아니라 "탐색 영역"이어야 한다

가장 기본이자 가장 많이 빠뜨리는 요건입니다. 사이드 메뉴는 단순히 <div> 안에 링크를 잔뜩 넣은 게 아니라, 코드 수준에서 "이건 탐색 영역"이라고 선언돼 있어야 합니다.

웹 표준으로 말하면, 사이드 메뉴는 <nav> 요소로 감싸고, 그 안의 항목들은 목록(<ul><li>) 구조로 짜는 게 원칙입니다. 그래야 스크린리더 사용자가 "탐색, 목록, 항목 8개"처럼 구조를 통째로 파악하고, 메뉴 영역을 한 번에 건너뛰거나 들어갈 수 있습니다. <div>에 링크만 줄줄이 박아 두면, 스크린리더에는 그냥 링크가 흩어져 있는 것으로만 들려서 "이게 메뉴구나"라는 맥락 자체가 사라집니다.

여기서 한 가지 더. 한 페이지에 탐색 영역이 여러 개(상단 메뉴, 사이드 메뉴, 푸터 메뉴)일 때는, 각 <nav>에 이름을 붙여 구분해주는 게 좋습니다(aria-label="주메뉴", aria-label="○○과 하위 메뉴" 등). 안 그러면 스크린리더 사용자가 "탐색, 탐색, 탐색" 하고 똑같은 안내만 듣고 어느 게 어느 메뉴인지 구분하지 못합니다. 사이드 메뉴는 특히 "이 영역 안의 메뉴"라는 정체성이 분명하므로, 그 영역 이름을 붙여 주면 사용자가 훨씬 명확하게 인지합니다.

2) 현재 위치 표시 — 지금 어디 있는지 보여야 한다

사이드 메뉴의 존재 이유 절반이 여기 걸려 있습니다. 사용자가 지금 보고 있는 페이지가 메뉴의 어느 항목인지, 시각적으로도 코드로도 분명히 표시돼야 합니다.

• 시각적으로: 현재 항목을 색·굵기·배경·표식 등으로 강조합니다. 단, 색 하나에만 의존하면 색 구분이 어려운 사용자는 못 알아채니, 굵기나 표식을 함께 쓰는 게 안전합니다.
• 코드로: 현재 페이지에 해당하는 링크에 aria-current="page"를 부여합니다. 이게 있어야 스크린리더가 "현재 페이지, 조직 안내"처럼 읽어 줍니다. 시각적 강조만 하고 aria-current를 빠뜨리면, 눈으로 보는 사람만 현재 위치를 알 수 있습니다.

이 "현재 위치 표시"가 빠지면 어떤 일이 벌어지냐면, 사용자가 메뉴를 누르고 페이지가 바뀌었는데도 "내가 그걸 누른 게 맞나? 페이지가 바뀐 건가?"를 확신하지 못합니다. 특히 메뉴 항목 이름이 비슷비슷한 정부 사이트(예: "민원 안내 / 민원 신청 / 민원 처리")에서는, 현재 위치 표시가 없으면 사용자가 같은 자리를 빙빙 돌게 됩니다.

3) 펼침·접힘(아코디언) 구조 — 깊은 메뉴를 다루는 법

사이드 메뉴는 하위 메뉴를 품는 경우가 많습니다. 상위 항목을 누르면 그 아래 하위 항목들이 펼쳐지는 아코디언 형태죠. 이 펼침·접힘에도 지켜야 할 기준이 있습니다.

• 펼침 상태를 코드로 알리기: 펼칠 수 있는 상위 항목에는 aria-expanded(펼침=true / 접힘=false)를 부여해, 지금 펼쳐졌는지 접혔는지 스크린리더가 알 수 있게 합니다. 화살표 아이콘이 위를 보든 아래를 보든, 그건 눈으로 보는 사람만 아는 정보입니다.
• 펼침 버튼과 하위 목록 연결: 어떤 버튼이 어떤 하위 목록을 펼치는지 aria-controls 등으로 연결해주면 더 명확합니다.
• 현재 페이지가 속한 가지는 펼친 채로: 사용자가 깊은 페이지에 들어와 있다면, 그 페이지가 속한 상위 메뉴는 펼쳐진 상태로 시작해야 합니다. 다 접힌 채로 보여주면, 사용자는 자기가 어느 가지 안에 있는지 알 수 없습니다.

펼침·접힘을 "그냥 클릭하면 슬라이드 되는 애니메이션"으로만 생각하면 이 요건들을 다 빠뜨리게 됩니다. 마우스로는 잘 작동하는데 키보드·스크린리더로는 "이게 펼쳐지는 건지 그냥 링크인지" 알 수 없는 메뉴가 그렇게 만들어집니다.

4) 키보드 조작 — 마우스 없이 완전히 쓸 수 있어야 한다

타협이 없는 요건입니다. 사이드 메뉴는 키보드만으로 다음이 전부 가능해야 합니다.

• Tab으로 메뉴 항목 간 초점(focus) 이동
• 펼칠 수 있는 항목에서 Enter / Space로 하위 메뉴 펼치기·접기
• 펼쳐진 하위 항목으로 자연스럽게 초점 이동
• 모든 링크가 키보드로 활성화 가능

브라우저 기본 링크(<a>)와 버튼(<button>)을 제대로 쓰면 이 동작 상당수가 따라옵니다. 문제는 디자인을 위해 <div>나 <span>에 클릭 이벤트만 붙여 "가짜 메뉴 항목"을 만들 때입니다. 그 순간 키보드로는 도달조차 안 되는 메뉴가 됩니다. 마우스 사용자에겐 멀쩡한 메뉴가, 키보드 사용자에겐 통째로 사라지는 거죠. 그래서 KRDS 컴포넌트 킷은 키보드 동작과 ARIA 속성이 이미 구현된 사이드 메뉴 코드를 제공합니다 — 직접 만들다 빠뜨리지 말고 검증된 걸 쓰라는 겁니다.

5) 초점 표시(Focus) — 지금 어느 항목에 있는지 보여야 한다

키보드로 메뉴를 훑을 때, 지금 초점이 어느 항목에 와 있는지 시각적으로 또렷이 보여야 합니다. 테두리가 강조되거나 외곽선(focus ring)이 분명히 나타나야 하죠. 이 표시를 "디자인이 지저분해 보인다"는 이유로 CSS outline: none으로 지워 버리는 경우가 정말 많습니다. 그러면 키보드 사용자는 긴 메뉴 목록에서 자기가 몇 번째 항목에 있는지 전혀 알 수 없게 됩니다. 사이드 메뉴는 항목이 많고 세로로 길기 때문에, 초점 표시가 없으면 더 심각하게 길을 잃습니다. 포커스 표시는 지우는 게 아니라, 디자인과 어울리게 다듬는 것이 정답입니다.

6) 터치 영역과 크기 — 모바일과 손가락을 위한 배려

모바일에서 사이드 메뉴는 보통 햄버거 버튼을 눌러 펼치는 형태로 바뀝니다. 이때 각 메뉴 항목은 손가락으로 정확히 누를 수 있을 만큼 충분히 커야 합니다. 한국형 웹 접근성 지침(KWCAG)과 국제 표준 모두 터치 대상의 최소 크기를 권장하는데, 보통 한 변 44px 이상을 기준으로 봅니다. 메뉴 항목이 다닥다닥 붙어 있으면, 손가락이 큰 사용자나 손 떨림이 있는 사용자는 옆 항목을 잘못 누르기 쉽습니다. 항목 높이와 항목 사이 간격을 여유 있게 잡아야 합니다.

7) 모바일 변환 — 햄버거로 접힐 때의 규칙

데스크톱에서 옆에 늘 보이던 사이드 메뉴는, 화면이 좁은 모바일에선 자리를 차지할 수 없어 보통 햄버거 버튼 뒤로 숨습니다. 이 변환에도 기준이 있습니다.

• 햄버거 버튼에 이름 붙이기: 줄 세 개 아이콘만 있는 버튼에는 aria-label="메뉴 열기" 같은 이름이 반드시 필요합니다(아이콘 전용 버튼의 기본 요건).
• 펼침 상태 알리기: 메뉴가 열렸는지 닫혔는지 aria-expanded로 전달합니다.
• 열린 메뉴 안에 초점 가두기(선택): 메뉴가 화면을 덮는 형태(오버레이)라면, 메뉴가 열린 동안 초점이 뒤쪽 본문으로 새어 나가지 않게 관리하면 더 좋습니다.
• 닫는 방법 제공: Esc 키나 명시적 닫기 버튼으로 메뉴를 닫을 수 있어야 합니다.

데스크톱만 보고 만든 사이드 메뉴가 모바일에서 무너지는 경우가 정말 흔합니다. "PC에선 멀쩡한데 폰에선 메뉴가 안 열려요" 같은 민원이 여기서 나옵니다.

8) 일관성 — 모든 영역에서 같은 방식으로

사이드 메뉴는 한 사이트 안에서도 부서마다, 영역마다 반복해서 등장합니다. 이때 영역마다 메뉴 모양과 동작이 제각각이면, 사용자는 영역을 옮길 때마다 "여기선 메뉴가 어떻게 작동하지?"를 다시 배워야 합니다. KRDS가 사이드 메뉴를 표준 컴포넌트로 제공하는 핵심 이유가 이 일관성입니다. 같은 모양, 같은 위치, 같은 동작 — 이게 사용자의 학습 비용을 0으로 만듭니다.

정리하면, KRDS의 사이드 메뉴 기준은 크게 세 축입니다. ① 명료성(의미 있는 마크업, 현재 위치 표시, 펼침 상태 표현), ② 조작 가능성(키보드 완전 지원, 충분한 터치 영역, 모바일 변환), ③ 일관성(모든 영역에서 같은 방식). 이 세 축은 그대로 ViewCheck가 사이드 메뉴를 판정하는 기준이기도 합니다.

왜 이렇게까지 따지나 — 원리와 배경

여기까지 읽고 "왼쪽 메뉴 하나에 뭐 이리 따지나" 싶으실 수 있습니다. 그런데 이 요건들은 누가 괜히 만든 규칙이 아니라, 실제 사용자가 막히는 지점에서 역으로 도출된 것들입니다.

사이드 메뉴는 "공공 사이트의 골격"이다

상업 사이트는 화면 한가운데에 화려한 상품 비주얼과 큰 버튼을 둡니다. 사용자를 한 방향(구매)으로 몰아가는 게 목적이니까요. 그런데 공공 사이트는 다릅니다. 사용자가 찾는 정보가 제각각입니다. 어떤 이는 조직도를, 어떤 이는 채용 공고를, 어떤 이는 특정 양식을 찾습니다. 이 무수히 다른 목적지를 연결하는 골격이 바로 탐색 구조이고, 그중에서도 영역 내부를 책임지는 게 사이드 메뉴입니다.

그래서 사이드 메뉴가 무너지면, 정보가 분명히 사이트 안에 있는데도 사용자가 못 찾습니다. "분명히 어딘가 있을 텐데" 하고 한참 헤매다 결국 전화로 문의하거나 포기합니다. 이건 단순한 불편이 아니라 행정 서비스 접근의 실패입니다. 그 정보를 찾으려고 들어온 국민이 빈손으로 나가는 거니까요.

보이는 구조와 읽히는 구조의 분리

비장애인은 사이드 메뉴를 "본다"고 생각하지만, 사실 우리는 메뉴의 들여쓰기·굵기·색을 보고 머릿속에서 "아, 이게 상위, 이게 하위구나" 하고 구조를 짐작합니다. 화살표가 펼쳐진 모양을 보고 "지금 이 가지가 열려 있구나"를 압니다. 스크린리더 사용자에게는 이 짐작 과정이 없습니다. 코드가 알려주는 정보가 곧 전부입니다.

그래서 사이드 메뉴는 "보기에 메뉴 같은 것"으로는 부족하고, "코드 수준에서 탐색 구조라고 선언된 것"이어야 합니다. <div>에 링크를 들여쓰기로만 배치해 시각적으로 계층을 표현해도, 코드가 그 계층 관계와 펼침 상태를 말해주지 않으면 스크린리더에겐 그냥 평평하게 나열된 링크 덩어리입니다. 이 "보이는 구조 ≠ 읽히는 구조" 문제가 사이드 메뉴 위반의 근본 원인 대부분을 차지합니다.

깊은 메뉴일수록 길 잃기 쉽다

공공 사이트는 메뉴가 깊습니다. 3단계, 4단계까지 내려가는 경우도 흔하죠. 깊을수록 "내가 지금 어디 있는지", "여기서 어디로 갈 수 있는지"를 알려주는 장치가 더 중요해집니다. 사이드 메뉴의 현재 위치 표시와 펼침 상태 표현은, 이 깊은 미로에서 사용자가 자기 위치를 잃지 않게 하는 나침반입니다. 나침반이 고장 나면, 미로는 더 이상 길이 아니라 함정이 됩니다.

작은 컴포넌트가 아니라 "큰 책임"

아이콘이나 셀렉트는 "작아서 방치되기 쉽다"고 했지만, 사이드 메뉴는 반대입니다. 크고 눈에 잘 띄는데도 방치됩니다. 왜냐하면 "한 번 만들면 끝"이라고 여겨지기 때문입니다. 사이트를 만들 때 정보 구조를 한 번 짜 넣고 나면, 그 안의 접근성·키보드·현재 위치 표시 같은 세부는 "당연히 잘 되겠지" 하고 넘어갑니다. 그런데 사이드 메뉴는 사이트의 모든 깊은 페이지에 반복해서 등장하는 골격입니다. 여기에 결함이 있으면, 그 결함이 사이트 전체 수백 페이지에 그대로 복제됩니다. 작은 컴포넌트의 실수는 그 자리에서 끝나지만, 사이드 메뉴의 실수는 사이트 전체로 번집니다.

일관성이 곧 학습 비용 절감

KRDS가 사이드 메뉴를 표준화하는 또 다른 이유는 일관성입니다. 정부 사이트마다 사이드 메뉴가 제각각이면, 사용자는 사이트를 옮길 때마다 "여기선 메뉴가 어떻게 펼쳐지지?"를 다시 익혀야 합니다. 모든 공공 서비스의 사이드 메뉴가 같은 위치에서 같은 방식으로 작동하면, 한 번 익힌 사용법이 모든 사이트에서 통합니다. 디지털 약자에게 이 "다시 안 배워도 됨"은 생각보다 큰 배려입니다.

한 장면 — 같은 부서 페이지, 두 사람

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공기관의 "주요 업무" 페이지, 왼쪽에 부서 하위 메뉴가 세로로 서 있다고 합시다. 메뉴는 "부서 소개 / 주요 업무 / 사업 안내 / 자료실 / 문의" 5개 항목이고, 그중 "사업 안내"는 누르면 하위 3개가 펼쳐지는 구조입니다.

먼저 마우스를 쓰는 김 주무관. 왼쪽 메뉴에서 "사업 안내"를 클릭하니 화살표가 아래로 돌면서 하위 3개가 펼쳐지고, "청년 지원 사업"을 누릅니다. 페이지가 바뀌고, 왼쪽 메뉴의 "청년 지원 사업"이 파란 글씨로 강조됩니다. 김 주무관은 자기가 지금 어디 있는지, 같은 묶음에 또 뭐가 있는지 한눈에 압니다. 30초도 안 걸렸습니다. 이 화면을 만든 팀도 "잘 작동한다"고 믿습니다. 자기들이 테스트할 때 늘 마우스를 썼으니까요.

이번엔 시각장애가 있는 박 선생님. 스크린리더를 켜고 페이지를 훑어 내려갑니다. 그런데 왼쪽 메뉴 자리에서 스크린리더가 "링크, 부서 소개. 링크, 주요 업무. 링크, 사업 안내…" 하고 링크만 나열합니다. 이게 메뉴인지, 본문 속 링크들인지 알 수 없습니다(<nav> 미사용). "사업 안내"를 눌러 하위를 펼치려 했지만, 그건 <div>에 클릭만 걸린 가짜 항목이라 키보드로는 반응이 없습니다(키보드 미지원, aria-expanded 없음). 설령 페이지를 옮겼다 해도, 현재 위치가 코드로 표시돼 있지 않아(aria-current 없음) "내가 지금 어느 페이지에 있는지"조차 알 수 없습니다. 박 선생님은 결국 이 부서의 사업 정보를 혼자 찾는 걸 포기합니다.

같은 페이지, 같은 메뉴. 한 사람에겐 30초짜리 직관적인 길잡이고, 다른 한 사람에겐 출구 없는 미로입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스 사용자만 떠올렸기 때문에 생긴 차이입니다. KRDS의 사이드 메뉴 요건은, 이 두 사람의 경험을 같게 만들기 위한 최소한의 약속입니다.

만약 이 팀이 KRDS 킷의 사이드 메뉴 코드를 가져다 썼다면 어땠을까요. 박 선생님의 스크린리더는 "○○과 하위 메뉴, 탐색, 목록 항목 5개"라고 영역을 먼저 알리고, "사업 안내, 접힘"이라고 펼침 상태까지 읽어 줬을 겁니다. Enter로 펼치니 "펼침"으로 바뀌고, 하위 항목으로 내려가 "청년 지원 사업"을 골랐겠죠. 페이지가 바뀐 뒤엔 "현재 페이지, 청년 지원 사업"이라고 위치까지 확인해 줬을 겁니다. 김 주무관과 똑같이 길을 찾았겠죠. 차이를 만드는 건 거창한 기술이 아니라, "검증된 컴포넌트를 쓰느냐"라는 작은 선택입니다.

공공 사이트가 자주 틀리는 지점 — 그리고 올바른 예

이제 현업에서 실제로 반복되는 사이드 메뉴 실수들을 보겠습니다. 모두 익명화한 일반적 사례입니다(특정 기관을 지목하지 않습니다).

실수 1) `<nav>` 없이 `<div>`로 만든 "메뉴 같지 않은 메뉴"

가장 근본적인 실수입니다. 사이드 메뉴를 그냥 <div> 안에 링크를 세로로 배치해 만듭니다. 모양은 완벽한 메뉴인데, 코드는 메뉴가 아닙니다.

• 나쁜 예: <div class="side-menu"> 안에 <a>만 줄줄이. <nav>도 목록 구조도 없음. 스크린리더는 링크들이 흩어져 있다고만 인식, "여기가 메뉴 영역"이라는 맥락이 없음.
• 올바른 예: <nav aria-label="○○과 하위 메뉴"> 안에 <ul><li> 목록 구조. 스크린리더가 "탐색, 목록, 항목 N개"로 영역과 구조를 통째로 파악. 메뉴를 건너뛰거나 들어가는 게 가능.

실수 2) 현재 위치 표시 누락(또는 시각만)

지금 보고 있는 페이지가 메뉴에서 강조되지 않거나, 강조는 되는데 코드로는 표시가 없습니다.

• 나쁜 예: 모든 메뉴 항목이 똑같이 보임. 또는 현재 항목만 파랗게 칠했지만 aria-current가 없어 스크린리더는 모름. 색약 사용자도 못 알아챔.
• 올바른 예: 현재 항목을 색·굵기·표식으로 강조하고, 해당 링크에 aria-current="page" 부여. 눈으로 보든 음성으로 듣든 "현재 페이지"를 인지.

실수 3) 펼침 상태를 코드로 안 알리는 아코디언

하위 메뉴가 펼쳐지긴 하는데, 펼쳐졌는지 접혔는지가 화살표 모양으로만 표현됩니다.

• 나쁜 예: 화살표 아이콘만 위아래로 바뀔 뿐, aria-expanded가 없음. 스크린리더 사용자는 "이게 펼칠 수 있는 항목인지, 펼쳐졌는지" 모름.
• 올바른 예: 펼침 버튼에 aria-expanded(true/false)와 aria-controls로 하위 목록 연결. "사업 안내, 접힘 → 사업 안내, 펼침"처럼 상태 변화가 읽힘.

실수 4) 키보드로 안 펼쳐지는 메뉴

상위 항목을 <div>나 <span>으로 만들고 클릭 이벤트만 걸어, 마우스로만 펼쳐집니다.

• 나쁜 예: 키보드 Tab으로 도달조차 안 되거나, 도달해도 Enter로 펼쳐지지 않음. 키보드 사용자에게 하위 메뉴는 존재하지 않는 셈.
• 올바른 예: 펼침 토글은 <button>으로, 링크는 <a>로. 키보드로 도달·활성화 가능. KRDS 킷 코드는 이게 이미 구현돼 있음.

실수 5) 깊은 페이지인데 메뉴가 다 접혀 있음

사용자가 3단계 깊은 페이지에 들어왔는데, 사이드 메뉴는 최상위만 보이고 다 접힌 상태로 시작합니다.

• 나쁜 예: 현재 페이지가 어느 가지에 속하는지 메뉴만 봐서는 알 수 없음. 사용자가 직접 일일이 펼쳐 찾아야 함.
• 올바른 예: 현재 페이지가 속한 상위 가지는 펼친 채로 시작. 현재 항목 강조와 결합해 "내가 여기 있고, 이 묶음 안이구나"를 즉시 인지.

실수 6) 초점 표시 제거

디자인 통일을 위해 outline: none으로 포커스 링을 지웁니다.

• 나쁜 예: 키보드로 긴 메뉴를 훑어도 지금 몇 번째 항목인지 안 보임. 세로로 긴 메뉴라 더 심각.
• 올바른 예: 포커스 시 또렷한 테두리·배경 강조 유지. 메뉴 항목마다 초점 위치가 분명히 보임.

실수 7) 모바일에서 안 열리거나 이름 없는 햄버거

데스크톱 기준으로만 만들고 모바일을 점검하지 않아, 좁은 화면에서 메뉴가 무너집니다.

• 나쁜 예: 햄버거 버튼에 라벨 없음(aria-label 없음), 펼침 상태(aria-expanded) 없음, 또는 아예 메뉴가 안 열림.
• 올바른 예: 햄버거 버튼에 "메뉴 열기" 이름, 펼침 상태 표시, Esc·닫기 버튼으로 닫기 가능, 항목 터치 영역 충분히.

실수 8) 메뉴 항목이 너무 빽빽하거나 작음

데스크톱 화면 기준으로 항목 높이를 작게 잡아, 모바일에서 손가락에 비해 너무 촘촘합니다.

• 나쁜 예: 항목 높이가 손가락보다 작아 옆 항목을 잘못 누름. 고령·손떨림 사용자에게 특히 고역.
• 올바른 예: 항목 높이와 간격을 충분히(약 44px 이상) 확보해 정확히 누를 수 있게.

실수 9) 영역마다 제각각인 메뉴

부서마다, 영역마다 사이드 메뉴 위치·모양·동작이 다 다릅니다.

• 나쁜 예: A 영역은 왼쪽, B 영역은 오른쪽, 펼침 방식도 제각각. 사용자가 영역 옮길 때마다 다시 학습.
• 올바른 예: KRDS 표준 사이드 메뉴를 전 영역에 일관 적용. 한 번 익히면 어디서나 통함.

실수 10) 메뉴와 본문 콘텐츠의 순서 문제

시각적으로는 메뉴가 왼쪽이지만, 코드 순서나 건너뛰기 장치가 없어 스크린리더 사용자가 매 페이지 긴 메뉴를 처음부터 다 들어야 합니다.

• 나쁜 예: 본문을 들으려면 매번 메뉴 항목을 끝까지 통과해야 함. 페이지마다 반복돼 피로가 누적.
• 올바른 예: 메뉴를 <nav>로 묶어 건너뛸 수 있게 하거나, "본문 바로가기" 링크를 제공. 메뉴를 한 번에 지나칠 수 있게.

직접 적용하기 — 개발자·디자이너·기획자 가이드

KRDS의 좋은 점은, 위 요건들을 "알아서 잘 만드세요"로 끝내지 않고 바로 쓸 수 있는 자산으로 제공한다는 것입니다.

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소의 html/code 폴더에 사이드 메뉴(영역 내부 탐색) 컴포넌트 코드가 들어 있어, <nav> 마크업, 목록 구조, 펼침·접힘 토글, 키보드 동작, aria-expanded·aria-current 같은 속성이 이미 구현된 상태로 시작할 수 있습니다. 핵심 습관은 세 가지입니다. ① 메뉴 영역은 <nav aria-label="..."> + <ul><li>로, ② 펼침 토글은 <button aria-expanded>로, ③ 현재 페이지 링크에는 aria-current="page". 이 세 가지만 지켜도 사이드 메뉴 접근성의 대부분이 해결됩니다. "접근성은 어렵다"는 말의 절반은 "직접 만들어서 어렵다"는 뜻인데, 검증된 코드를 가져다 쓰면 그 절반이 사라집니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 사이드 메뉴 컴포넌트와 그 상태(기본·현재·펼침·접힘·포커스)를 가져다 쓸 수 있습니다. 직접 그리지 말고 표준 컴포넌트를 배치하면, 디자인 단계에서부터 현재 위치 표시·펼침 표식·항목 간격이 기준에 맞춰집니다. 특히 "현재 페이지를 어떻게 강조할지"와 "펼침/접힘을 어떤 표식으로 보여줄지"를 시안에 분명히 명시해야, 개발 단계에서 aria-current·aria-expanded가 빠지지 않습니다.

기획자라면 — 화면 정의서에 "왼쪽 메뉴"라고만 적지 말고, "사이드 메뉴(영역: ○○과 하위, 3단계, 현재 위치 표시, 모바일 햄버거 변환)"처럼 영역 범위·깊이·현재 위치·모바일 동작을 함께 명시하세요. 그리고 정보 구조(IA)를 짤 때 메뉴 깊이가 너무 깊어지지 않게(가능하면 3단계 이내) 설계하는 것도 기획의 몫입니다. 메뉴가 깊을수록 사용자도, 개발도, 접근성도 다 어려워집니다.

그래서 우리 사이트는? — ViewCheck로 점검

여기까지가 KRDS의 사이드 메뉴 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트의 사이드 메뉴는 이걸 지키고 있나?"를 확인하는 일입니다. 페이지마다 사이드 메뉴가 <nav>로 돼 있는지, 현재 위치가 코드로 표시되는지, 펼침 상태가 알려지는지, 키보드로 다 펼쳐지는지를 사람이 일일이 손으로 점검하려면 끝이 없습니다. 사이드 메뉴는 사이트의 거의 모든 깊은 페이지에 반복 등장하니, 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

ViewCheck(krds.viewcheck.co.kr)는 이 점검을 자동화합니다. URL만 넣으면 페이지를 실제로 크롤링해서, 사이드 메뉴를 포함한 컴포넌트들이 KRDS 기준을 지키는지 판정합니다. 사이드 메뉴는 KRDS 846규칙 중 컴포넌트(CP) 규칙군 446개에 속하고, 분석 결과의 컴포넌트(Components) 탭에서 확인할 수 있습니다.

ViewCheck가 사이드 메뉴에 대해 자동으로 보는 것들:

• 탐색 마크업 여부: 메뉴 영역이 <nav>와 목록 구조로 의미 있게 마크업됐는지, 여러 탐색 영역이 이름으로 구분되는지
• 현재 위치 표시: 현재 페이지 항목이 시각·코드(aria-current)로 표시되는지
• 펼침·접힘 표현: 펼칠 수 있는 항목에 aria-expanded가 있는지, 하위 목록과 연결돼 있는지
• 키보드·초점: 메뉴 항목이 키보드로 도달·활성화 가능한지, 포커스 표시가 유지되는지
• 터치 영역: 모바일 뷰포트에서 메뉴 항목이 최소 권장 크기를 충족하는지(반응형 품질 분석과 연계)

DOM만으로 판단하기 어려운 시각적 부분(예: 커스텀으로 만든 펼침 애니메이션, 현재 위치 강조의 실제 대비)은 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 "코드엔 메뉴 같은 게 명확하지 않은데 화면엔 분명히 사이드 메뉴가 있는" 비표준 구현도 놓치지 않습니다. 이 점이 단순 코드 검사 도구와 다른 부분입니다 — 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회해 만든 UI도 잡아냅니다.

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 사이드 메뉴 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "○○과 페이지의 사이드 메뉴가 <nav> 미사용 + 현재 위치(aria-current) 누락"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인 영역 메뉴는 멀쩡한데 특정 부서 영역 메뉴만 펼침 상태 표현이 빠졌다" 같은 영역별 편차도 한눈에 드러납니다. 사이드 메뉴는 영역마다 다른 템플릿을 쓰는 경우가 많아서, 이 "영역별 편차"가 특히 잘 나타납니다. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

무료 진단으로 우리 사이트의 깊은 페이지(부서 안내, 자료실 등) 몇 개를 돌려 보면, 손으로는 몇 시간 걸릴 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "메뉴 잘 만들자"가 아니라, "이 영역의 이 사이드 메뉴를 이렇게 고치자"는 구체적인 작업 목록이 됩니다.

자주 묻는 질문

현장에서 사이드 메뉴를 다룰 때 반복해서 나오는 질문들을 모았습니다.

Q. 사이드 메뉴와 상단 메인 메뉴(GNB), 둘 다 있어야 하나요?

역할이 다르니 보통 둘 다 둡니다. 상단 메뉴는 "사이트 전체를 어디로 갈지"를 정하는 1차 길잡이, 사이드 메뉴는 "지금 들어온 영역 안에서 어느 페이지로 갈지"를 정하는 2차 길잡이입니다. 깊이가 얕은 작은 사이트라면 상단 메뉴만으로 충분할 수 있지만, 부서·업무·자료가 많은 공공 사이트에서는 사이드 메뉴가 있어야 깊은 페이지들을 헤매지 않고 탐색할 수 있습니다. 핵심은 둘의 역할을 분명히 나누는 것 — 사이드 메뉴가 상단 메뉴를 그대로 복제하면 의미가 없습니다.

Q. 메뉴를 왼쪽에 둬야 하나요, 오른쪽도 되나요?

관습적으로 사이드 메뉴는 왼쪽에 두는 경우가 많습니다. 사용자가 본문을 읽기 전에 메뉴를 먼저 만나는 게 자연스럽고, 시선 흐름(좌→우)에도 맞기 때문입니다. 다만 절대 규칙은 아닙니다. 더 중요한 건 위치의 일관성입니다. 사이트 안에서 영역마다 메뉴 위치가 왔다 갔다 하면, 그게 왼쪽이냐 오른쪽이냐보다 더 큰 혼란을 줍니다. 한 번 정한 위치를 전 영역에 일관되게 적용하세요.

Q. 현재 페이지 강조를 색으로만 하면 안 되나요?

색만으로는 부족합니다. 색 구분이 어려운 사용자(색각 이상)는 현재 위치를 못 알아챕니다. 색에 더해 굵기·배경·표식(예: 왼쪽 강조선) 중 하나를 함께 쓰고, 코드로는 반드시 aria-current="page"를 부여하세요. 시각·코드 양쪽으로 현재 위치를 알려야 모든 사용자가 똑같이 인지합니다. "색 하나에 의존하지 않기"는 사이드 메뉴뿐 아니라 모든 상태 표현의 공통 원칙입니다.

Q. 메뉴가 너무 깊습니다(4~5단계). 어떻게 하죠?

먼저 정보 구조 자체를 다시 보는 게 우선입니다. 메뉴가 4~5단계까지 깊다는 건, 분류가 지나치게 잘게 쪼개졌거나 같은 정보가 여러 갈래에 흩어져 있다는 신호일 수 있습니다. 가능하면 3단계 이내로 평탄화하는 걸 검토하세요. 구조상 깊이가 불가피하다면, 현재 페이지가 속한 가지를 펼친 채로 보여주고, 브레드크럼(경로 표시)을 함께 두어 사용자가 자기 위치를 잃지 않게 해야 합니다. 깊이를 줄이는 게 1순위, 깊이를 잘 안내하는 게 2순위입니다.

Q. 모바일에서 사이드 메뉴를 어떻게 처리하나요?

좁은 화면에선 보통 햄버거 버튼 뒤로 접습니다. 이때 ① 햄버거 버튼에 "메뉴 열기" 같은 이름(aria-label)을 붙이고, ② 펼침 상태(aria-expanded)를 알리고, ③ Esc나 닫기 버튼으로 닫을 수 있게 하고, ④ 펼친 항목들의 터치 영역을 충분히(약 44px) 확보하세요. 데스크톱에선 멀쩡한데 모바일에서 메뉴가 안 열리거나 항목이 너무 작은 경우가 흔하니, 반드시 실제 모바일에서 점검해야 합니다.

Q. 사이드 메뉴를 `<select>` 드롭다운으로 만들어도 되나요?

모바일에서 공간을 아끼려고 사이드 메뉴를 셀렉트(드롭다운)로 바꾸는 경우가 있습니다. 가능은 하지만 신중해야 합니다. 셀렉트는 "값을 고르는" 폼 요소이지 "페이지를 이동하는" 탐색 요소가 아니라서, 사용자가 "고른 뒤 별도 버튼을 눌러야 하나, 고르면 바로 이동하나"를 헷갈릴 수 있습니다. 또 셀렉트로 바꾸면 현재 위치 표시나 계층 구조가 사라지기 쉽습니다. 쓴다면 현재 항목을 기본 선택값으로 보여주고, 선택 시 이동이 명확히 전달되게 설계하세요. 가급적이면 탐색은 탐색 컴포넌트(<nav> 기반)로 두는 게 원칙입니다.

Q. 메뉴 항목이 수십 개라 너무 깁니다. 다 보여줘야 하나요?

한 영역의 형제 페이지가 수십 개라면, 그것 역시 정보 구조를 다시 볼 신호입니다. 의미별로 묶어 중간 단계를 만들거나(그룹화), 펼침·접힘으로 평소엔 접어 두고 필요할 때 펼치게 하세요. 다만 펼침·접힘을 쓰면 앞서 본 aria-expanded·키보드 요건이 따라옵니다. "다 펼쳐서 길게"와 "다 접어서 안 보이게" 사이에서, 현재 가지는 펼치고 나머지는 접는 균형이 보통 가장 무난합니다.

Q. 이미 운영 중인 사이트인데, 사이드 메뉴를 전부 다시 만들어야 하나요?

전부 갈아엎을 필요는 없습니다. 사이드 메뉴는 보통 영역별 템플릿으로 만들어지기 때문에, 템플릿 하나만 제대로 고치면 그 영역의 모든 페이지가 한꺼번에 개선되는 장점이 있습니다. 먼저 ViewCheck로 "어느 영역의 사이드 메뉴가, 무슨 문제를 일으키는지"를 목록으로 만든 다음, 사용 빈도가 높은 핵심 영역(주요 부서, 자주 찾는 자료실 등)의 템플릿부터 차례로 고치세요. 적은 작업으로 가장 많은 페이지를 한 번에 구제할 수 있습니다.

Q. 디자인팀과 개발팀이 서로 "그건 너희 일"이라고 합니다.

사이드 메뉴는 정보 구조(기획)·시각 표현(디자인)·접근성 구현(개발)이 모두 얽힌, 대표적인 합작 컴포넌트입니다. 기획자는 영역 범위와 메뉴 깊이를 정의하고, 디자이너는 현재 위치 강조와 펼침 표식을 시안에 명시하고, 개발자는 그걸 <nav>·aria-current·aria-expanded가 포함된 표준 코드로 구현해야 합니다. 그래서 KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 겁니다. 세 팀이 같은 기준을 보고 일하면 "네 일/내 일" 논쟁이 줄어듭니다.

점검했다면, 무엇부터 고칠까 — 우선순위

ViewCheck로 돌려 보면 보통 사이드 메뉴 관련 문제가 한두 개로 끝나지 않습니다. 게다가 사이드 메뉴는 여러 페이지에 반복되니, "고칠 게 많다"는 압박감이 더 큽니다. 그래서 우선순위가 중요합니다. 사이드 메뉴 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 키보드로 아예 펼쳐지지 않거나 도달조차 안 되는 가짜 메뉴 항목, 그리고 스크린리더가 메뉴 구조를 전혀 인식하지 못하는(<nav>·목록 구조 없는) 사이드 메뉴. 이건 특정 사용자에게 탐색 기능 자체를 완전히 차단하는 문제라 1순위입니다. 정보가 사이트에 분명히 있는데도 못 찾게 만드는 셈이니까요.

그다음(높음) — 현재 위치 표시 누락(특히 aria-current 없음)과 펼침 상태 미표현(aria-expanded 없음). 작동은 하지만 사용자가 "내가 어디 있는지", "이게 펼쳐지는지"를 알 수 없어 깊은 메뉴에서 길을 잃습니다. 깊은 페이지인데 메뉴가 다 접혀 시작하는 것도 여기 포함됩니다.

그 후(보통) — 현재 위치를 색으로만 표시, 포커스 표시 제거, 모바일 햄버거 라벨 누락, 터치 영역 부족. 사용은 가능하지만 특정 상황·특정 사용자에게 불편을 주는 문제입니다.

여력이 되면(낮음) — 영역마다 제각각인 메뉴를 표준으로 통일, 메뉴 건너뛰기 장치 추가, 너무 깊은 구조의 평탄화 같은 사용성 개선. 접근성을 막는 건 아니지만 경험을 한 단계 끌어올리는 항목입니다.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주기 때문에, "일단 눈에 띄는 것부터"가 아니라 "사용자를 가장 많이 막는 것부터" 순서대로 처리할 수 있습니다. 사이드 메뉴는 한 템플릿 수정이 여러 페이지에 동시에 반영되는 특성이 있어서, 우선순위만 잘 잡으면 적은 작업으로 큰 개선을 얻을 수 있습니다.

더 깊이 확인하려면 — 공식 자료 안내

이 글은 KRDS의 사이드 메뉴 기준을 실무 관점에서 풀어 쓴 것입니다. 정확한 원문 기준과 코드·디자인 자산은 아래 공식 자료에서 직접 확인하실 수 있습니다.

• KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 컴포넌트별 정의와 사용 원칙의 1차 원천.
• KRDS 컴포넌트 문서(웹) — 사이드 메뉴의 변형·예시를 화면으로 확인.
• KRDS 컴포넌트 킷(GitHub) — 사이드 메뉴 코드를 그대로 가져다 사용(npm install krds-uiux 또는 CDN krds.min.css / krds.min.js).
• KRDS 공식 Figma(@krds) — 디자이너용 사이드 메뉴 컴포넌트와 상태.

공식 자료는 "정답지"이고, ViewCheck는 "내 답안을 채점해 주는 도구"라고 생각하시면 됩니다. 둘을 함께 쓰면, 기준을 이해하고(가이드라인) → 내 사이트가 그 기준에 맞는지 확인하고(ViewCheck) → 검증된 코드로 고치는(킷) 한 바퀴가 완성됩니다.

오늘의 체크리스트 — 사이드 메뉴, 이것만은

마지막으로, 디자이너·개발자·기획자가 사이드 메뉴를 만들거나 검수할 때 바로 쓸 수 있는 체크리스트로 정리합니다.

• ☐ 사이드 메뉴를 <nav> + 목록(<ul><li>) 구조로 의미 있게 마크업했다(<div> 링크 묶음이 아니다).
• ☐ 탐색 영역이 여러 개면 각 <nav>에 이름(aria-label)을 붙여 구분했다.
• ☐ 현재 페이지 항목을 시각(색+굵기/표식)과 코드(aria-current="page")로 모두 표시했다.
• ☐ 펼칠 수 있는 항목에 aria-expanded(펼침/접힘)를 부여하고 하위 목록과 연결했다.
• ☐ 깊은 페이지에 들어왔을 때, 현재 페이지가 속한 가지가 펼친 채로 시작한다.
• ☐ 키보드만으로 메뉴 항목 도달·펼침·이동이 전부 된다(펼침 토글은 <button>).
• ☐ 포커스 표시가 또렷하다(outline: none으로 지우지 않았다).
• ☐ 모바일에서 햄버거 버튼에 이름(aria-label)과 펼침 상태(aria-expanded)가 있고, Esc·닫기로 닫힌다.
• ☐ 메뉴 항목의 터치 영역이 충분하다(약 44px 이상, 항목 간 간격 여유).
• ☐ 모든 영역에서 사이드 메뉴의 위치·모양·동작이 일관된다.
• ☐ 메뉴 깊이가 과하지 않다(가능하면 3단계 이내), 깊으면 브레드크럼 등으로 위치를 보완했다.

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 쓰면 위 항목 대부분이 이미 구현된 상태로 시작할 수 있습니다. 직접 만들다 빠뜨릴 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 사이드 메뉴의 상태(기본·현재·펼침·접힘·포커스)를 그대로 가져다 쓸 수 있습니다.

사이드 메뉴는 화면에서 가장 눈에 잘 띄지만, 역설적으로 "한 번 만들면 끝"이라는 생각에 가장 자주 방치되는 컴포넌트입니다. 그런데 공공 사이트에서 사용자가 원하는 정보를 찾아가느냐 마느냐는, 바로 이 옆 기둥 하나에 달려 있습니다. 잘 만든 사이드 메뉴는 깊은 미로에 든 사용자에게 나침반이 되고, 잘못 만든 사이드 메뉴는 분명히 있는 정보를 영영 못 찾게 만드는 함정이 됩니다.

오늘 정리한 기준이 거창해 보일 수 있지만, 핵심은 결국 단순합니다. 메뉴를 <nav>로 선언하고, 지금 어디 있는지(aria-current) 알리고, 펼침 상태(aria-expanded)를 말로도 전하고, 키보드로 쓸 수 있게 하고, 검증된 코드를 쓰는 것. 이 다섯 가지만 챙겨도 사이드 메뉴의 위반 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 많이 쓰이는 영역의 사이드 메뉴 템플릿 하나부터 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 많은 사람에게 길을 열어 줍니다. 다음 글에서는 사이드 메뉴와 짝을 이루는 또 다른 탐색 요소를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 사이드 메뉴는 모든 사용자에게 길잡이가 되고 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 자주 찾는 부서 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 바로 보입니다.

#KRDS #사이드메뉴Sidenavigation #공공웹 #디자인시스템 #웹접근성 #ViewCheck #정부웹사이트 #UIUX #내비게이션 #정보구조 #탐색메뉴 #사이드메뉴 #Sidenavigation #KRDS기준 #디자인원칙 #표준가이드 #UI컴포넌트 #컴포넌트설계 #전자정부 #디지털정부