사이드 메뉴(Side navigation) 자가진단 — ViewCheck 5분 점검

어느 부처의 정책 안내 페이지에 들어갔다고 칩시다. 왼쪽에 메뉴가 길게 늘어서 있습니다. "사업 개요 / 지원 대상 / 신청 방법 / 자주 묻는 질문 / 관련 법령…" 우리는 그중 하나를 누르고, 또 그 안에서 하위 항목을 누릅니다. 한참을 그렇게 들어가다 문득 "내가 지금 어디 있더라?" 하고 멈칫합니다. 펼쳐졌던 메뉴가 다시 접혀 버려서, 방금 지나온 길이 보이지 않습니다. 뒤로 가기를 누르고, 다시 처음부터 메뉴를 펼쳐 내려갑니다. 별것 아닌 것 같지만, 이게 바로 "사이드 메뉴를 잘못 만들면 생기는 일"입니다.

사이드 메뉴(Side navigation)는 공공 사이트, 특히 정보량이 많은 정책·민원·통계 페이지에서 거의 빠지지 않는 컴포넌트입니다. 화면 왼쪽(가끔 오른쪽)에 세로로 늘어선 메뉴 목록. 깊은 계층 구조를 가진 정부 사이트가 "지금 이 섹션 안에서 어디로 갈 수 있는지"를 보여 주는 핵심 길잡이입니다. 그런데 이 길잡이가 사실은 사용자를 가장 자주 길 잃게 만드는 컴포넌트이기도 합니다. 지금 펼쳐진 게 어디인지 안 보이고, 키보드로는 하위 메뉴를 펼칠 수 없고, 스크린리더는 "링크, 링크, 링크"만 끝없이 읽어 댑니다.

이번 글은 "기준이 뭐다"를 길게 설명하는 글이라기보다는, 우리 사이트의 사이드 메뉴가 지금 멀쩡한지를 5분 안에 직접 점검해 보는 글입니다. 물론 점검을 하려면 "무엇을 점검해야 하는지"부터 알아야 하니, KRDS(대한민국 정부 디자인 시스템)가 사이드 메뉴에 요구하는 기준도 함께 짚습니다. 다만 무게중심은 "확인하는 법"에 둡니다. 다 읽고 나면, 마우스를 잠깐 치우고 Tab 키만으로 우리 사이트 사이드 메뉴를 훑으면서 "어, 이거 문제 있네"를 스스로 찾아낼 수 있게 되실 겁니다. 그리고 페이지가 수십·수백 개라 손으로 다 못 보는 경우엔, ViewCheck로 한 번에 점검하는 법까지요.

미리 한 가지만 말씀드리면, 사이드 메뉴는 "있으면 편한 것"이 아니라 "있는데 잘못 만들면 차라리 없느니만 못한 것"입니다. 길을 알려 주라고 세워 둔 이정표가 엉뚱한 방향을 가리키거나, 어떤 사람에겐 아예 안 보인다면, 그건 이정표가 아니라 함정이니까요. 그래서 더더욱 "잘 만들었겠지" 하고 믿지 말고, 직접 점검해 봐야 합니다.

사이드 메뉴가 대체 뭐길래 — 정의부터 정확히

먼저 용어를 맞추겠습니다. "왼쪽에 세로로 늘어선 메뉴"라고 다 같은 사이드 메뉴가 아닙니다. KRDS는 내비게이션 계열 컴포넌트를 역할별로 구분합니다.

• 사이드 메뉴(Side navigation): 특정 섹션(메뉴 그룹) 안에서, 그 하위 페이지들로 이동하는 세로형 보조 내비게이션. 보통 본문 옆에 고정되어, "지금 이 카테고리 안에서 어디로 갈 수 있는지"를 보여 줍니다.
• 메인 메뉴(주 내비게이션, GNB): 사이트 전체의 대분류를 가로로 펼치는 최상위 메뉴. 사이드 메뉴와 자주 짝을 이루지만 역할이 다릅니다(GNB는 큰 길, 사이드 메뉴는 그 안의 골목길).
• 인페이지 내비게이션(목차/콘텐츠 내 탐색): 한 페이지 안의 긴 본문을 섹션별로 점프하는 목차. 이동이 아니라 같은 페이지 내 스크롤입니다.
• 브레드크럼(이동 경로): "홈 > 정책 > 지원사업"처럼 현재 위치의 깊이를 보여 주는 경로 표시. 사이드 메뉴와 함께 쓰여 "위치 감각"을 보강합니다.

이 구분이 왜 중요하냐면, 셋을 헷갈려 만들면 사용자가 "이게 이 섹션 안 이동인지, 사이트 전체 이동인지, 같은 페이지 점프인지"를 알 수 없기 때문입니다. 예를 들어 사이드 메뉴인데 누르면 전혀 다른 대분류로 휙 날아가 버리면, 사용자는 자기가 보던 맥락을 통째로 잃습니다. KRDS가 컴포넌트를 역할별로 나눠 정의해 둔 이유가 이겁니다 — 비슷하게 생겼어도 의미가 다르면 다른 컴포넌트로 다뤄야 한다는 것.

사이드 메뉴의 핵심 특징은 계층 구조입니다. 1단계 항목 아래 2단계, 그 아래 3단계가 접히고 펼쳐집니다. 그리고 사용자가 지금 보고 있는 페이지에 해당하는 항목은 현재 위치(current)로 강조됩니다. 이 "펼침/접힘"과 "현재 위치 강조" 두 가지가, 사이드 메뉴가 길잡이 노릇을 제대로 하느냐를 가르는 결정적 요소입니다. 그리고 공교롭게도, 공공웹에서 가장 자주 깨지는 부분도 바로 이 둘입니다.

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

점검을 하려면 채점 기준표가 있어야 합니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서, 그리고 확립된 웹 접근성 기준(KWCAG)을 종합해, 사이드 메뉴가 충족해야 할 요건을 점검 항목 형태로 정리하겠습니다. 각 항목 끝에 "이렇게 확인하세요"를 붙여 두니, 그대로 따라 해 보시면 됩니다.

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

사이드 메뉴의 첫 번째 임무는 "당신은 지금 여기 있습니다"를 알려 주는 일입니다. 여러 항목 중 사용자가 지금 보고 있는 페이지에 해당하는 항목이 시각적으로 강조돼야 하고(굵게, 색 강조, 막대 표시 등), 더 중요하게는 코드 수준으로도 그 사실이 표시돼야 합니다.

웹 표준으로 말하면, 현재 페이지 항목에는 aria-current="page"가 붙어야 합니다. 이게 있어야 스크린리더가 "현재 페이지, 지원 대상, 링크"처럼 읽어 줍니다. 시각적으로 색만 바꿔 두면 눈으로 보는 사람만 자기 위치를 알 수 있고, 음성으로 듣는 사람은 메뉴 한가운데서 길을 잃습니다.

이렇게 확인하세요: 임의의 하위 페이지에 들어간 뒤, 사이드 메뉴에서 그 페이지에 해당하는 항목이 다른 항목과 다르게 보이는지 눈으로 확인합니다. 그리고 개발자도구로 그 항목을 검사해 aria-current 속성이 있는지 봅니다. 색만 다르고 aria-current가 없으면 절반만 된 겁니다.

2) 펼침/접힘 상태 — 열렸는지 닫혔는지 알아야 한다

하위 항목을 가진 메뉴는 펼치고 접을 수 있습니다. 이때 "지금 이 항목이 펼쳐져 있는지 접혀 있는지"가 분명해야 합니다. 시각적으로는 화살표(▸ / ▾) 방향이나 들여쓰기로 표현하고, 코드로는 `aria-expanded="true"/"false"`로 상태를 알려야 합니다.

이게 빠지면 스크린리더 사용자는 "이 메뉴를 누르면 펼쳐지는 건지, 다른 페이지로 가는 건지"를 알 수 없습니다. 펼침/접힘 토글인데 일반 링크처럼 읽히면, 누를지 말지 판단할 근거가 없는 거죠.

이렇게 확인하세요: 하위 항목이 있는 메뉴를 펼쳐 보고, 화살표 같은 표시가 방향을 바꾸는지 봅니다. 개발자도구로 그 토글 요소에 aria-expanded가 있고, 펼치면 true, 접으면 false로 바뀌는지 확인합니다.

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

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

• Tab으로 메뉴 항목 사이를 이동
• Enter로 링크 항목 이동, 또는 펼침/접힘 토글 작동
• 펼쳐진 하위 항목으로 초점이 자연스럽게 이어짐
• (구현에 따라) 방향키로 항목 간 이동

브라우저 기본 링크(<a>)와 버튼(<button>)을 제대로 쓰면 이 동작 상당수가 따라옵니다. 문제는 디자인을 위해 <div>와 <span>으로 "가짜 메뉴"를 만들 때입니다. 그 순간 키보드 도달·작동을 전부 직접 구현해야 하는데, 현실에서는 거의 다 빠뜨립니다. 마우스 클릭 이벤트만 붙이고 끝내는 거죠.

이렇게 확인하세요: 마우스에서 손을 떼고 Tab 키만으로 사이드 메뉴를 훑어 내려가 보세요. 모든 항목에 초점이 닿나요? 하위 메뉴가 있는 항목에서 Enter로 펼쳐지나요? 펼친 뒤 그 하위 항목들로 초점이 이어지나요? 어느 하나라도 막히면 키보드 접근성 문제입니다.

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

키보드로 이동할 때, 지금 초점이 어느 메뉴 항목에 와 있는지 또렷하게 보여야 합니다. 테두리나 외곽선(focus ring), 배경 강조 같은 표시가 분명해야 하죠. 이 표시를 디자인이 지저분해 보인다는 이유로 CSS outline: none으로 지워 버리는 경우가 정말 많습니다. 그러면 키보드 사용자는 자기가 메뉴 어디쯤에 있는지 알 수 없게 됩니다.

이렇게 확인하세요: Tab으로 항목을 이동할 때마다, 현재 항목에 테두리나 강조가 또렷이 나타나는지 봅니다. 아무 표시 없이 초점만 옮겨 다니면 포커스 표시가 지워진 겁니다.

5) 의미 있는 구조(시맨틱) — 메뉴를 메뉴라고 선언해야 한다

사이드 메뉴는 "보기에 메뉴 같은 것"으로는 부족하고, "코드 수준에서 내비게이션이라고 선언된 것"이어야 합니다. 보통 <nav> 요소로 감싸고, 항목들은 목록(<ul>/<li>)으로 구성합니다. <nav>에는 aria-label로 "사이드 메뉴"나 그 섹션 이름("정책 안내 메뉴")을 붙여, 같은 페이지의 다른 내비게이션(GNB, 푸터 메뉴 등)과 구분되게 합니다.

이게 갖춰져 있으면 스크린리더 사용자는 "내비게이션 영역, 항목 8개"처럼 한 덩어리로 인식하고, 통째로 건너뛰거나 빠르게 훑을 수 있습니다. 구조가 없으면 메뉴가 그냥 링크 더미로 흩어져, 본문과 뒤섞여 읽힙니다.

이렇게 확인하세요: 개발자도구로 사이드 메뉴를 감싸는 요소가 <nav>인지, 항목들이 <ul><li> 목록 구조인지 봅니다. <nav>에 aria-label이 있어 다른 내비게이션과 구분되는지도 확인합니다.

6) 계층의 깊이 — 너무 깊지 않게

계층은 사이드 메뉴의 힘이지만, 지나치게 깊으면(4단계, 5단계로) 사용자가 길을 잃습니다. 일반적으로 깊이는 2~3단계 정도로 절제하는 게 좋습니다. 그 이상 깊어진다면 정보 구조 자체를 재검토할 신호입니다. 또 펼친 하위 항목이 너무 많아 메뉴가 화면을 다 덮어 버리면 오히려 탐색이 어려워집니다.

이렇게 확인하세요: 가장 깊은 메뉴까지 펼쳐 보고, 몇 단계까지 내려가는지 셉니다. 4단계 이상이면 "정말 이 깊이가 필요한가"를 의심해 보세요.

7) 터치 영역과 간격 — 모바일에서 누를 수 있어야 한다

모바일에서 사이드 메뉴는 보통 햄버거 버튼을 눌러 펼치는 형태(off-canvas)로 바뀝니다. 이때 각 메뉴 항목은 손가락으로 누를 수 있을 만큼 충분히 커야 합니다. KWCAG와 국제 표준 모두 터치 대상의 최소 크기를 권장하는데, 보통 한 변 44px 이상을 기준으로 봅니다. 항목이 다닥다닥 붙어 있으면 옆 항목을 잘못 누르기 쉽습니다.

이렇게 확인하세요: 모바일(또는 브라우저 모바일 뷰)에서 사이드 메뉴를 열고, 항목을 눌러 봅니다. 옆 항목이 눌리거나 자꾸 빗나가면 터치 영역이 부족한 겁니다.

8) 모바일 펼침 메뉴의 초점 관리

모바일에서 햄버거로 펼치는 사이드 메뉴(드로어/오프캔버스)는 한 가지 요건이 더 붙습니다. 메뉴가 열리면 초점이 메뉴 안으로 들어가고, 메뉴를 닫으면 초점이 다시 햄버거 버튼으로 돌아와야 합니다. 그리고 메뉴가 열려 있는 동안엔 그 뒤의 본문으로 초점이 새어 나가지 않아야 합니다(focus trap). 이게 안 되면 키보드·스크린리더 사용자는 열린 메뉴와 가려진 본문 사이에서 헤맵니다. 또 Esc로 닫을 수 있으면 좋습니다.

이렇게 확인하세요: 모바일 뷰에서 키보드로 햄버거를 열고, 초점이 메뉴 안으로 들어가는지, Tab을 계속 눌러도 메뉴 밖 본문으로 빠지지 않는지, 닫으면 다시 버튼으로 돌아오는지 봅니다.

정리하면, KRDS의 사이드 메뉴 기준은 크게 세 축입니다. ① 위치 감각(현재 위치 표시, 펼침/접힘 상태), ② 조작 가능성(키보드 완전 지원, 초점 표시, 충분한 터치 영역), ③ 전달성(시맨틱 구조로 스크린리더가 메뉴를 메뉴로 인식). 이 세 축이 그대로 점검 기준이고, ViewCheck가 사이드 메뉴를 판정하는 기준이기도 합니다.

한 장면 — 같은 메뉴, 두 사람

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공 서비스의 "복지 사업 안내" 섹션, 왼쪽에 사이드 메뉴가 있습니다. "사업 소개 / 지원 대상 / 신청 방법 / 제출 서류 / 자주 묻는 질문". 그중 "신청 방법" 아래엔 "온라인 신청 / 방문 신청"이 하위로 접혀 있습니다.

먼저 마우스를 쓰는 김 주무관. 화살표를 클릭해 "신청 방법"을 펼치고, "온라인 신청"을 누릅니다. 페이지가 바뀌고, 사이드 메뉴에서 "온라인 신청"이 파랗게 강조됩니다. 자기가 어디 있는지 한눈에 보입니다. 30초도 안 걸렸습니다. 김 주무관에게 이 메뉴는 아무 문제가 없습니다. 그래서 이 화면을 만든 팀도 "잘 작동한다"고 믿습니다. 자기들이 테스트할 때 늘 마우스를 썼으니까요.

이번엔 시각장애가 있는 박 선생님. 스크린리더를 켜고 Tab으로 사이드 메뉴를 훑습니다. 그런데 스크린리더가 "링크, 링크, 링크"만 반복합니다. 어느 게 펼침 메뉴이고 어느 게 일반 이동인지(aria-expanded 없음), 지금 자기가 보는 페이지가 어느 항목인지(aria-current 없음) 알 수 없습니다. "신청 방법"을 펼치려고 Enter를 눌렀는데 아무 반응이 없습니다. 이 토글은 <div>로 만든 가짜라, 마우스 클릭에만 반응하거든요(키보드 미지원). 박 선생님은 결국 하위 메뉴에 닿지 못하고, 신청을 포기합니다.

같은 화면, 같은 메뉴. 한 사람에겐 30초짜리 사소한 탐색이고, 다른 한 사람에겐 닫힌 길입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스 사용자만 떠올렸기 때문에 생긴 차이입니다. 그리고 이 차이를 만든 사람들조차 그걸 모릅니다. 자기 눈엔 멀쩡하니까요. 그래서 점검이 필요합니다. "내 눈에 멀쩡한 것"과 "모두에게 멀쩡한 것"은 다르고, 그 간극은 직접 확인해 보기 전엔 보이지 않습니다.

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

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

공공 서비스는 "안 쓸 자유"가 없다

상업 사이트는 메뉴가 불편하면 사용자가 떠나면 그만입니다. 경쟁사로 가면 되니까요. 그런데 공공 서비스는 다릅니다. 복지 사업을 신청하거나, 정책 정보를 찾거나, 민원을 처리하는 일은 그 사이트가 아니면 할 수 없습니다. 사용자가 "안 쓸 자유"가 없어요. 그래서 공공 웹의 사이드 메뉴가 누군가에게 작동하지 않으면, 그건 단순한 불편이 아니라 정보 접근권의 박탈이 됩니다.

특히 사이드 메뉴는 "정보를 찾아 들어가는 길" 그 자체입니다. 이 길이 막히면, 그 안에 있는 모든 콘텐츠가 통째로 닿지 않는 곳이 됩니다. 검색 버튼 하나가 안 읽히는 것과는 차원이 다릅니다 — 사이드 메뉴는 한 섹션 전체로 들어가는 관문이니까요. 관문이 막히면 그 뒤의 수십 개 페이지가 전부 사라지는 셈입니다.

보이는 것과 읽히는 것의 분리

비장애인은 화면을 "본다"고 생각하지만, 사실 우리는 화면을 보고 머릿속에서 의미로 번역합니다. 파랗게 강조된 항목을 보고 "아, 내가 여기 있구나" 하고, 화살표 방향을 보고 "이건 펼쳐지는 메뉴구나" 하고 짐작하죠. 스크린리더 사용자에게는 이 짐작 과정이 없습니다. 코드가 알려 주는 정보가 곧 전부입니다.

그래서 사이드 메뉴는 시각적 강조(색·화살표)와 코드 정보(aria-current·aria-expanded)가 반드시 함께 가야 합니다. 색만 바꾸고 코드를 빼먹으면, 눈으로 보는 사람과 음성으로 듣는 사람의 경험이 갈라집니다. 이 "보이는 것 ≠ 읽히는 것" 문제가 사이드 메뉴 위반의 근본 원인 대부분을 차지합니다. KRDS의 모든 내비게이션 요건이 결국 "시각과 코드의 일치"라는 한 가지 원리로 수렴하는 셈입니다.

깊은 구조일수록 길잡이가 중요하다

정부 사이트는 다루는 정보가 방대하고 계층이 깊습니다. 부처 → 정책 → 사업 → 세부 안내로 몇 단계씩 내려가죠. 이렇게 깊은 구조에서 사이드 메뉴는 사용자가 "지금 어디쯤 와 있고, 여기서 어디로 갈 수 있는지"를 잡아 주는 유일한 손잡이입니다. 손잡이가 부실하면 깊이 들어갈수록 길을 잃습니다. 상업 사이트보다 공공 사이트에서 사이드 메뉴 품질이 더 중요한 이유가 여기 있습니다 — 구조가 깊기 때문에, 길잡이가 흔들리면 타격이 더 큽니다.

일관성이 곧 학습 비용 절감

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

작아 보여도 모든 탐색이 여기서 시작된다

사이드 메뉴는 메인 비주얼처럼 화려하지 않습니다. 그래서 검수 우선순위에서 밀리기 쉽습니다. 하지만 사용자가 실제로 "원하는 정보를 찾아가는" 행동은 바로 이 메뉴에서 일어납니다. 멋진 메인을 지나, 결국 사람들이 클릭하는 건 사이드 메뉴의 항목들입니다. 가장 덜 주목받는 컴포넌트가 사실은 사이트의 정보 탐색 전체를 떠받치는 골격인 셈입니다. KRDS가 사이드 메뉴를 꼼꼼히 표준화해 둔 건, 이 "방치되기 쉬운 골격"에서 품질이 무너지는 걸 막기 위해서입니다.

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

이제 현업에서 실제로 반복되는 사이드 메뉴 실수들을 보겠습니다. 모두 익명화한 일반적 사례입니다(특정 기관을 지목하지 않습니다). 점검할 때 "혹시 우리도?" 하고 대조해 보세요.

실수 1) 현재 위치를 색으로만 표시

하위 페이지에 들어갔는데, 사이드 메뉴에서 현재 항목이 파랗게 강조되긴 합니다. 그런데 코드엔 aria-current가 없습니다.

• 나쁜 예: 색만 강조. 스크린리더는 "지원 대상, 링크"라고만 읽고, 그게 "현재 페이지"라는 정보를 못 전함. 음성 사용자는 메뉴 한가운데서 자기 위치를 모름.
• 올바른 예: 현재 항목에 aria-current="page"를 붙여, 스크린리더가 "현재 페이지, 지원 대상, 링크"로 읽게. 시각 강조 + 코드 표시를 함께.

실수 2) 펼침/접힘 상태가 코드에 없음

화살표는 방향을 바꾸는데, aria-expanded가 없습니다.

• 나쁜 예: 눈엔 펼쳐진 게 보이지만, 스크린리더 사용자는 "이게 펼침 토글인지 일반 링크인지" 구분 못 함. 누를지 말지 판단 불가.
• 올바른 예: 펼침 토글에 aria-expanded="true"/"false"를 두고, 상태가 바뀔 때 값도 갱신. 화살표(시각) + aria-expanded(코드)를 함께.

실수 3) "가짜 메뉴" — 키보드로 펼칠 수 없다

디자인 자유를 위해 메뉴를 <div>와 <span>으로 만들고, 펼침은 마우스 클릭(또는 hover)에만 반응하게 합니다.

• 나쁜 예: <div class="menu-item">에 클릭 이벤트만. 키보드로는 Tab도 안 닿고 Enter도 안 먹힘. 키보드 사용자에겐 존재하지 않는 메뉴.
• 올바른 예: 이동 항목은 <a>, 펼침 토글은 <button>으로. 키보드 도달·작동이 기본으로 따라옴. 커스텀이 꼭 필요하면 role과 키보드 핸들러를 모두 구현.

실수 4) hover로만 펼쳐지는 메뉴

마우스를 올려야만 하위 메뉴가 펼쳐지고, 클릭이나 키보드로는 안 됩니다.

• 나쁜 예: 터치 기기엔 hover가 없어 모바일에서 하위 메뉴에 영영 닿지 못함. 키보드 사용자도 마찬가지.
• 올바른 예: 클릭/Enter로 펼침을 토글. hover는 보조 효과로만, 핵심 동작은 클릭·키보드로.

실수 5) 초점 표시 제거

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

• 나쁜 예: Tab으로 메뉴를 훑어도 지금 어느 항목에 있는지 안 보임. 불 꺼진 복도를 손전등 없이 걷는 셈.
• 올바른 예: 포커스 시 또렷한 테두리·배경 강조 유지. 지우지 말고 디자인과 어울리게 다듬기.

실수 6) 시맨틱 없는 링크 더미

메뉴를 <nav>나 목록 구조 없이 그냥 <a> 나열로 만듭니다.

• 나쁜 예: 스크린리더가 메뉴를 하나의 내비게이션으로 인식 못 함. 본문과 뒤섞여 끝없이 "링크"만 읽힘. 건너뛰기도 안 됨.
• 올바른 예: <nav aria-label="정책 안내 메뉴"> 안에 <ul><li> 목록으로. 스크린리더가 "내비게이션, 항목 N개"로 묶어 인식.

실수 7) 너무 깊은 계층

4단계, 5단계로 끝없이 파고듭니다.

• 나쁜 예: 펼치고 또 펼쳐도 끝이 안 보임. 사용자는 자기가 몇 층까지 내려왔는지 잊고 길을 잃음.
• 올바른 예: 깊이를 2~3단계로 절제. 그 이상이면 정보 구조 자체를 재설계 신호로 받아들이기.

실수 8) 모바일에서 초점이 새는 펼침 메뉴

햄버거로 펼친 사이드 메뉴가 열려 있는데, Tab을 누르면 가려진 본문으로 초점이 빠져나갑니다.

• 나쁜 예: 메뉴는 화면을 덮고 있는데 초점은 그 뒤 본문을 돌아다님. 키보드 사용자는 안 보이는 곳을 더듬게 됨.
• 올바른 예: 메뉴 열림 시 초점을 메뉴 안에 가두고(focus trap), 닫으면 햄버거 버튼으로 복귀. Esc로 닫기 지원.

실수 9) 모바일 터치 영역 부족

데스크톱 기준으로 만들고 모바일을 확인하지 않아, 펼친 메뉴 항목들이 손가락에 비해 작고 빽빽합니다.

• 나쁜 예: 항목 높이가 손가락보다 작아 옆 항목을 잘못 누름.
• 올바른 예: 모바일 메뉴 항목의 높이·간격을 넉넉히(약 44px 이상) 확보.

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

점검에서 문제를 발견했다면, 이제 고칠 차례입니다. KRDS의 좋은 점은 위 요건들을 "알아서 잘 만드세요"로 끝내지 않고 바로 쓸 수 있는 자산으로 제공한다는 것입니다.

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소의 html/code 폴더에 사이드 내비게이션 관련 마크업이 들어 있어, 시맨틱 구조와 ARIA 속성이 이미 반영된 상태로 시작할 수 있습니다. 핵심 습관은 세 가지입니다. ① 이동 항목은 <a>, 펼침 토글은 <button>으로(키보드 동작이 공짜로 따라옴), ② 현재 페이지엔 aria-current="page", ③ 펼침 토글엔 aria-expanded를 두고 상태를 갱신. 이 세 가지만 지켜도 사이드 메뉴 위반의 대부분이 사라집니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 사이드 내비게이션 컴포넌트와 상태(기본/현재/펼침/접힘/포커스)를 가져다 쓸 수 있습니다. 직접 그리지 말고 표준 컴포넌트를 배치하면, 디자인 단계에서부터 계층 표현·현재 위치 강조·간격이 기준에 맞춰집니다. 특히 "현재 위치를 어떻게 강조할지"와 "펼침/접힘을 어떤 아이콘으로 표현할지"를 시안에 명시해 두면, 개발 단계의 누락을 막을 수 있습니다.

기획자라면 — 화면 정의서(IA)에 "왼쪽 메뉴"라고만 적지 말고, 계층 깊이(예: 2단계), 현재 위치 표시 방식, 펼침/접힘 동작, 모바일에서의 동작(햄버거 펼침)을 함께 명시하세요. 그리고 정보 구조를 짤 때 깊이가 너무 깊어지지 않게 설계하는 것도 기획자의 몫입니다. 이 한 단계가 디자인·개발의 혼선을 크게 줄입니다.

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

여기까지가 손으로 직접 하는 점검입니다. 한 페이지라면 위의 "이렇게 확인하세요"를 따라 5분이면 됩니다. 그런데 진짜 문제는 페이지가 많을 때입니다. 정부 사이트는 섹션마다 사이드 메뉴가 다르고, 페이지가 수십·수백 개씩 됩니다. "신청 섹션의 사이드 메뉴는 멀쩡한데 통계 섹션은 aria-current가 빠졌다" 같은 편차를, 사람이 페이지마다 일일이 Tab 키로 훑어 확인하려면 끝이 없습니다.

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

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

• 내비게이션 구조 감지: 사이드 메뉴가 <nav> + 목록 구조로 의미 있게 선언됐는지, aria-label로 다른 내비게이션과 구분되는지
• 현재 위치 표시: 현재 페이지 항목에 aria-current가 적절히 부여됐는지
• 펼침/접힘 상태: 하위 메뉴 토글에 aria-expanded가 있고 상태가 표현되는지
• 키보드 접근성: 메뉴 항목이 키보드로 도달·작동 가능한 표준 요소(<a>/<button>)로 만들어졌는지, 초점 표시가 살아 있는지
• 터치 영역: 모바일 뷰포트에서 메뉴 항목이 최소 권장 크기를 충족하는지(반응형 품질 분석과 연계)

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

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 사이드 메뉴 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "통계 섹션 페이지의 사이드 메뉴에 현재 위치(aria-current) 표시 누락"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인 섹션 사이드 메뉴는 멀쩡한데 특정 섹션만 키보드로 안 펼쳐진다" 같은 페이지별 편차도 한눈에 드러납니다. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "탐색 잘하자"가 아니라, "이 섹션의 이 사이드 메뉴를 이렇게 고치자"는 구체적인 작업 목록이 됩니다.

5분 셀프 점검 — 지금 바로 따라 하기

ViewCheck를 돌리기 전에, 혹은 돌린 결과를 더 잘 이해하기 위해, 지금 당장 우리 사이트에서 직접 해볼 수 있는 점검 순서를 정리합니다. 도구 없이 브라우저만으로 됩니다.

1. 마우스를 치우고 Tab만으로 사이드 메뉴를 훑어 보세요. 모든 항목에 초점이 닿나요? 가서 또렷이 보이나요? 안 가거나 안 보이면 키보드·포커스 문제입니다(실수 3·5).

2. 하위 메뉴를 키보드로 펼쳐 보세요. Enter로 펼쳐지고, 펼친 하위 항목으로 초점이 이어지나요? 안 되면 "가짜 메뉴"이거나 hover 전용일 수 있습니다(실수 3·4).

3. 하위 페이지에 들어간 뒤 사이드 메뉴를 보세요. 현재 항목이 강조돼 있나요? 개발자도구로 그 항목에 aria-current가 있나요? 색만 있고 코드가 없으면 절반만 된 겁니다(실수 1).

4. 펼침 토글을 개발자도구로 검사해 aria-expanded가 있고, 펼치고 접을 때 값이 바뀌는지 보세요. 없으면 상태가 전달되지 않습니다(실수 2).

5. 사이드 메뉴를 감싸는 요소가 `<nav>`인지, 항목이 <ul><li> 목록인지 확인하세요. 그냥 <a> 나열이면 시맨틱 문제입니다(실수 6).

6. 모바일 뷰로 전환해 햄버거로 메뉴를 열고, 키보드로 Tab을 눌러 보세요. 초점이 메뉴 안에 머무나요, 아니면 뒤 본문으로 새나요? 닫으면 버튼으로 돌아오나요?(실수 8) 항목을 눌렀을 때 옆 항목이 눌리지 않나요?(실수 9)

7. 가장 깊은 메뉴까지 펼쳐 몇 단계인지 세어 보세요. 4단계 이상이면 구조를 의심하세요(실수 7).

이 일곱 가지만 해봐도 대부분의 사이드 메뉴 문제가 드러납니다. 다만 페이지가 많아지면 사람이 다 보기 어렵습니다 — 그때 ViewCheck로 전 페이지를 한 번에 점검하면 됩니다.

자주 묻는 질문

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

Q. 사이드 메뉴와 GNB(주 메뉴)를 둘 다 둬야 하나요?

사이트 구조에 따라 다릅니다. 정보 계층이 깊은 정부 사이트는 보통 둘을 함께 씁니다 — GNB로 큰 분류를 고르고, 사이드 메뉴로 그 분류 안에서 세부 페이지를 탐색하는 식이죠. 둘을 둘 때 중요한 건 역할이 겹치지 않게 하는 것과, 스크린리더가 둘을 구분할 수 있게 각 <nav>에 서로 다른 aria-label을 주는 것입니다. "주 메뉴"와 "정책 안내 메뉴"처럼요.

Q. 현재 위치는 `aria-current="page"`만 쓰면 되나요, 색 강조도 해야 하나요?

둘 다입니다. aria-current는 스크린리더 사용자를 위한 코드 정보이고, 색·굵기 강조는 눈으로 보는 사용자를 위한 시각 정보입니다. 어느 하나만 있으면 한쪽 사용자만 자기 위치를 압니다. 시각 강조와 코드 표시는 둘 다, 그리고 일치하게 두는 게 원칙입니다.

Q. 메뉴를 처음엔 다 펼쳐 둘까요, 다 접어 둘까요?

정답은 없지만, 보통은 "현재 보고 있는 섹션은 펼쳐 두고, 나머지는 접어 두는" 방식이 무난합니다. 사용자가 지금 있는 곳의 주변 항목은 보이게 하고, 관련 없는 섹션은 접어 화면을 정돈하는 거죠. 다만 항목이 적다면 다 펼쳐 두는 게 탐색에 더 좋을 수 있습니다. 핵심은 어느 쪽이든 펼침/접힘 상태가 시각·코드로 분명히 전달되는 것입니다.

Q. hover로 펼쳐지는 메뉴, 정말 안 되나요?

hover를 "보조"로 쓰는 건 괜찮지만, "유일한" 펼침 수단으로 쓰면 안 됩니다. 터치 기기엔 hover가 없어 모바일 사용자가 하위 메뉴에 닿을 수 없고, 키보드 사용자도 마찬가지입니다. 핵심 동작(펼치기)은 반드시 클릭·Enter로도 되게 하고, hover는 마우스 사용자를 위한 추가 편의로만 두세요.

Q. 사이드 메뉴 항목이 너무 많은데 어떻게 정리하죠?

먼저 정보 구조를 의심해 보세요. 한 섹션에 항목이 수십 개면, 그 섹션 자체를 더 작은 하위 분류로 나눌 필요가 있을 수 있습니다. 또 자주 쓰는 항목을 위로 올리고, 의미별로 묶어 그룹 제목을 붙이면 훑어보기가 쉬워집니다. 그래도 많다면 검색 기능을 함께 제공하는 것도 방법입니다. 메뉴를 길게 늘이는 것보다, 구조를 잘 나누는 게 근본 해법입니다.

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

좁은 화면에선 사이드 메뉴를 항상 펼쳐 두기 어렵습니다. 보통 햄버거 버튼을 눌러 펼치는 드로어(off-canvas) 형태로 바꿉니다. 이때 햄버거 버튼에 이름(aria-label="메뉴 열기")을 주고, 열림/닫힘 상태(aria-expanded)를 표시하고, 열렸을 때 초점을 메뉴 안에 가두고, 닫으면 버튼으로 초점을 되돌리는 처리가 필요합니다. "데스크톱만 확인하고 끝"이 가장 흔한 실수입니다.

Q. 사이드 메뉴를 직접 만들지 말고 KRDS 킷을 쓰면 정말 편한가요?

네, 특히 키보드 동작과 시맨틱 구조 측면에서요. 사이드 메뉴는 "보기엔 단순한데 접근성 요건은 많은" 대표적 컴포넌트라, 직접 만들면 aria-current, aria-expanded, 초점 관리, 시맨틱 구조 중 하나는 꼭 빠뜨리게 됩니다. KRDS 킷의 마크업을 기반으로 시작하면, 이런 누락을 처음부터 줄일 수 있습니다. 다만 킷을 쓰더라도 "현재 위치 표시"는 페이지마다 갱신해 줘야 하니, 그 부분은 점검에서 빠뜨리지 마세요.

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

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "어느 섹션의 사이드 메뉴가, 어떤 문제를 일으키는지"를 목록으로 만든 다음, 뒤에서 볼 우선순위대로 치명적인 것부터 차례로 고치면 됩니다. 특히 사용 빈도가 높은 핵심 섹션(민원·신청·자주 찾는 정보)의 사이드 메뉴부터 손보면, 적은 작업으로 가장 많은 사용자를 구제할 수 있습니다.

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

사이드 메뉴 접근성은 어느 한 팀의 책임이 아니라 합작입니다. 기획자는 정보 구조와 깊이·동작을 정의하고, 디자이너는 현재 위치 강조와 펼침/접힘 표현을 시안에 명시하고, 개발자는 그걸 시맨틱 구조와 ARIA로 구현해야 합니다. 그래서 KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 겁니다. 세 팀이 같은 기준을 보고 일하면 "네 일/내 일" 논쟁이 줄어듭니다.

Q. 사이드 메뉴를 "고정(sticky)"으로 화면에 붙여 두는 건 어떤가요?

긴 본문을 스크롤하는 동안에도 사이드 메뉴가 따라오면, 사용자가 언제든 다른 항목으로 이동할 수 있어 편리합니다. 깊은 콘텐츠가 많은 정부 사이트엔 잘 맞는 방식이죠. 다만 두 가지를 주의하세요. 첫째, 모바일처럼 화면이 좁을 땐 고정 메뉴가 본문을 가릴 수 있으니 그땐 햄버거 드로어로 전환하는 게 낫습니다. 둘째, 고정이든 아니든 키보드 초점 순서와 현재 위치 표시 같은 기본 요건은 똑같이 지켜야 합니다. "고정으로 만들었으니 편하겠지"가 접근성을 면제해 주지는 않습니다.

Q. 점검에서 문제가 많이 나왔는데, 어디까지가 "당장 고쳐야 할 법적 문제"인가요?

공공 웹사이트는 웹 접근성 준수가 사실상 의무에 가깝습니다. 그중에서도 키보드로 아예 작동하지 않는 메뉴, 스크린리더가 인식하지 못하는 메뉴처럼 "특정 사용자에게 기능을 완전히 차단"하는 항목은 가장 시급합니다. 현재 위치·펼침 상태 정보 누락도 접근성 측면에서 분명한 결함입니다. 반면 계층 정리나 그룹화 같은 사용성 개선은 법적 의무라기보다 품질 향상 영역입니다. ViewCheck 리포트의 우선순위(P0~P3)가 대체로 이 시급성과 맞물리니, P0·P1부터 처리하시면 됩니다.

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

ViewCheck로(또는 손으로) 점검해 보면 보통 사이드 메뉴 문제가 한두 개로 끝나지 않습니다. 페이지가 많을수록 "고칠 게 많다"는 압박감이 듭니다. 그래서 우선순위가 중요합니다. 사이드 메뉴 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 키보드로 아예 펼쳐지지 않는 가짜 메뉴, hover로만 펼쳐지는 메뉴, 스크린리더가 내비게이션으로 인식하지 못하는 메뉴. 이건 특정 사용자에게 그 섹션 전체로 가는 길을 완전히 차단하는 문제라 1순위입니다. 메뉴 하나가 막히면 그 안의 모든 페이지가 닿지 않게 되니, 위반의 파급이 가장 큽니다.

그다음(높음) — 현재 위치(aria-current)와 펼침/접힘 상태(aria-expanded)가 코드에 없는 경우. 작동은 하지만 음성 사용자가 "지금 어디 있고, 이게 펼침인지 이동인지"를 알 수 없으니 실질적 장벽입니다. 그리고 모바일 펼침 메뉴의 초점 관리 누락도 여기 포함됩니다.

그 후(보통) — 초점 표시 제거, 모바일 터치 영역 부족, 시맨틱은 있으나 aria-label이 없어 다른 내비게이션과 구분이 안 되는 경우. 사용은 가능하지만 특정 상황·특정 사용자에게 불편을 주는 문제입니다.

여력이 되면(낮음) — 너무 깊은 계층 정리, 항목 그룹화, 자주 쓰는 항목 상단 배치 같은 사용성 개선. 접근성을 막는 건 아니지만 경험을 한 단계 끌어올리는 항목입니다.

ViewCheck 리포트는 이 우선순위(P0~P3)를 자동으로 매겨 주기 때문에, "일단 눈에 띄는 것부터"가 아니라 "사용자를 가장 많이 막는 것부터" 순서대로 처리할 수 있습니다. 한정된 인력과 일정 안에서 가장 효과 큰 개선에 집중하는 게 핵심입니다.

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

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

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

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

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

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

• ☐ 사이드 메뉴가 <nav> + 목록(<ul><li>) 구조로 의미 있게 선언돼 있다.
• ☐ <nav>에 aria-label이 있어 GNB·푸터 등 다른 내비게이션과 구분된다.
• ☐ 현재 페이지 항목에 시각 강조 + `aria-current="page"`가 함께 있다.
• ☐ 펼침 토글에 `aria-expanded`가 있고, 펼치고 접을 때 값이 갱신된다.
• ☐ 키보드만으로 모든 항목 도달·이동·펼침/접힘이 된다(가짜 메뉴·hover 전용 아님).
• ☐ 포커스 표시가 또렷하다(outline: none으로 지우지 않았다).
• ☐ 계층 깊이가 2~3단계로 절제돼 있다.
• ☐ 모바일에서 펼친 메뉴 항목의 터치 영역이 충분하다(약 44px 이상).
• ☐ 모바일 햄버거 메뉴는 초점 관리(열림 시 가두기, 닫힘 시 버튼 복귀, Esc 닫기)가 된다.

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 쓰면 위 항목 대부분이 이미 반영된 상태로 시작할 수 있습니다. 직접 만들다 빠뜨릴 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 사이드 내비게이션의 변형과 상태를 그대로 가져다 쓸 수 있습니다.

사이드 메뉴는 화려하지 않지만, 공공 서비스에서 사용자가 "정보를 찾아 들어가는" 거의 모든 길목에 있습니다. 그 메뉴 하나가 누군가에겐 원하는 정보로 가는 손잡이이고, 또 누군가에겐 닫힌 문입니다. 우리가 무심코 넘긴 왼쪽 메뉴 하나가, 누군가에게는 그 섹션 전체를 쓸 수 있느냐 없느냐를 가릅니다.

오늘 정리한 점검 항목이 많아 보일 수 있지만, 핵심은 결국 단순합니다. 마우스를 치우고 Tab으로 훑어 보고, 현재 위치가 색과 코드로 모두 표시되는지 보고, 펼침 상태가 코드로 전달되는지 보고, 검증된 구조를 쓰는 것. 이 네 가지만 챙겨도 사이드 메뉴 위반의 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 많이 막히는 사이드 메뉴 하나부터 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 많은 사람에게 열립니다. 다음 글에서는 사이드 메뉴와 짝을 이루는 또 다른 내비게이션 요소를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 사이드 메뉴는 지금 누군가를 길 잃게 하고 있지 않을까요? krds.viewcheck.co.kr에서 URL만 넣으면, 어느 섹션의 사이드 메뉴가 무슨 문제를 일으키는지 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #사이드메뉴Sidenavigation #웹접근성 #ViewCheck #정부웹사이트 #UIUX #내비게이션 #정보구조 #aria #사이드메뉴 #Sidenavigation #자가진단 #체크리스트 #점검항목 #UI컴포넌트 #컴포넌트설계 #전자정부 #디지털정부