콘텐츠 내 탐색(In-page navigation) 완전 해부 — KRDS 공식 기준

긴 안내 페이지에 들어가 본 적 있으실 겁니다. "코로나19 예방접종 안내" 같은, 화면을 한참 스크롤해도 끝이 안 보이는 페이지요. 위에서부터 차근차근 읽다가 "그래서 나는 어디서 신청하지?"가 궁금해지면, 우리는 보통 마우스 휠을 마구 굴리거나 Ctrl+F로 단어를 찾습니다. 운이 좋으면 금방 찾고, 운이 나쁘면 같은 문단을 세 번쯤 다시 지나칩니다. 그러다 결국 "에이, 그냥 전화하자"며 페이지를 닫아 버린 경험, 한 번쯤은 있으실 거예요.

그 긴 페이지의 맨 위나 옆에 "이 페이지 안에서 이동" 메뉴가 하나 있었다면 어땠을까요. "신청 대상", "신청 방법", "구비 서류", "문의처"가 목록으로 정리돼 있고, 누르면 해당 부분으로 바로 점프하는 그것. 이게 바로 오늘 다룰 콘텐츠 내 탐색(In-page navigation)입니다. 같은 페이지 안에서 원하는 곳으로 건너뛰게 해 주는, 작아 보이지만 긴 문서의 생사를 가르는 컴포넌트죠.

저는 공공 사이트를 수백 개 들여다보면서, 이 컴포넌트가 있고 없고에 따라 같은 정보가 전혀 다르게 읽힌다는 걸 거듭 확인했습니다. 똑같은 분량의 안내문인데, 콘텐츠 내 탐색이 잘 붙은 페이지는 "찾기 쉬운 자료"가 되고, 없는 페이지는 "끝까지 읽어야만 하는 숙제"가 됩니다. 그런데 막상 이걸 제대로 만든 페이지는 의외로 드뭅니다. 더 흔한 건, 모양만 갖춰 놓고 정작 클릭해도 안 움직이거나, 키보드로는 닿지도 않거나, 지금 내가 페이지 어디쯤 있는지 알려 주지 않는 "반쪽짜리" 탐색입니다.

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

콘텐츠 내 탐색이 대체 뭘까 — 정의부터 정확히

먼저 용어부터 맞추겠습니다. 우리가 "메뉴", "내비게이션"이라고 뭉뚱그려 부르는 것들은 사실 역할이 다 다릅니다. KRDS는 탐색(navigation) 관련 컴포넌트를 목적에 따라 구분하는데, 그중 콘텐츠 내 탐색은 그 이름 그대로 "한 페이지 안에서의 이동"을 담당합니다.

• 메인 메뉴(Main menu) / 글로벌 내비게이션: 사이트 전체의 큰 구조를 오가는 메뉴. "민원·정책·소식·기관소개"처럼 페이지를 옮겨 다니게 합니다.
• 브레드크럼(Breadcrumb): 지금 내가 사이트 구조의 어디에 있는지 경로를 보여 주는 것. "홈 > 민원 > 신청"처럼요.
• 콘텐츠 내 탐색(In-page navigation): 지금 보고 있는 이 페이지 안에서 원하는 구역으로 점프하는 것. 페이지를 떠나지 않습니다.
• 페이지네이션(Pagination): 목록을 여러 쪽으로 나눠 1, 2, 3쪽을 오가는 것.

이 구분이 왜 중요하냐면, 모양이 비슷하다고 아무 데나 같은 패턴을 쓰면 사용자가 "이걸 누르면 페이지를 떠나는 건가, 이 안에서 움직이는 건가"를 헷갈리기 때문입니다. 콘텐츠 내 탐색의 핵심 약속은 "눌러도 페이지를 떠나지 않는다"입니다. 같은 페이지 안에서 스크롤 위치만 바뀌죠. 이 약속이 분명해야 사용자가 안심하고 누릅니다.

쉽게 말하면, 콘텐츠 내 탐색은 긴 문서의 목차입니다. 두꺼운 책 앞에 목차가 있어서 "3장은 47쪽"을 보고 바로 펼치듯, 긴 웹페이지에서도 "신청 방법은 여기"를 보고 바로 점프하게 해 주는 것. 책 목차와 다른 점이라면, 웹에서는 페이지가 길어질수록 "내가 지금 몇 장을 읽고 있는지"가 흐려진다는 겁니다. 그래서 웹의 콘텐츠 내 탐색은 단순히 점프만 시켜 주는 게 아니라, 지금 위치도 알려 줘야 합니다. 이 "현재 위치 표시"가 책 목차에는 없는, 웹 탐색만의 핵심 요건입니다.

어떤 모습으로 나타나나

콘텐츠 내 탐색은 화면에서 몇 가지 형태로 등장합니다.

• 상단 앵커 목록형: 페이지 본문 시작 부분에 "이 페이지의 내용"이라는 작은 목차가 가로 또는 세로로 놓이고, 항목을 누르면 해당 섹션으로 내려갑니다. 정책·제도 안내 페이지에서 가장 흔한 형태입니다.
• 사이드 고정형(스티키 목차): 본문 옆에 목차가 세로로 붙어 있고, 스크롤해도 따라옵니다. 화면이 넓은 PC에서 긴 약관·매뉴얼을 읽을 때 유용합니다. 지금 읽는 섹션이 목차에서 강조됩니다.
• 탭 전환형: "개요 / 신청 / 서류 / FAQ"처럼 탭으로 묶고, 탭을 누르면 그 부분이 보이거나 그 영역으로 이동합니다. 단, 탭은 별도 컴포넌트로도 다뤄지므로 역할이 겹칠 때는 구분이 필요합니다.
• 맨 위로(Top) 버튼: 긴 페이지 끝에서 다시 맨 위로 한 번에 올라가는 버튼. 콘텐츠 내 탐색의 보조 장치입니다.

KRDS 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux)과 공식 컴포넌트 문서를 열어 보면, 콘텐츠 내 탐색은 이런 형태들을 표준 패턴으로 정리해 두었습니다. 직접 제멋대로 만들지 말고, 정해진 구조와 동작을 따르라는 것이죠.

KRDS는 콘텐츠 내 탐색에 무엇을 요구하나 — 기준 완전 해부

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서, 그리고 확립된 웹 접근성 기준(KWCAG·WCAG)을 종합해, 콘텐츠 내 탐색이 충족해야 하는 요건을 영역별로 정리하겠습니다.

1) 의미 있는 구조 — 진짜 "내비게이션"이어야 한다

첫 번째 요건은, 콘텐츠 내 탐색이 코드 수준에서 "이건 탐색 영역입니다"라고 선언돼 있어야 한다는 것입니다. 화면에 목차처럼 보이는 글자만 늘어놓는 걸로는 부족합니다.

웹 표준으로 말하면, 탐색 묶음은 <nav> 요소로 감싸거나 role="navigation"을 부여하고, 그 안의 항목들은 목록(<ul><li>)으로 구성하는 게 기본입니다. 그래야 스크린리더 사용자가 "탐색, 항목 4개"라는 식으로 구조를 파악하고, 보조기술의 "랜드마크 이동" 기능으로 이 영역을 건너뛰거나 곧장 찾아올 수 있습니다. 페이지에 탐색 영역이 여러 개라면(예: 메인 메뉴와 콘텐츠 내 탐색), 각각에 이름을 붙여(aria-label="이 페이지 내 이동" 등) 서로 구별되게 해야 합니다. 그냥 <div>에 링크만 박아 두면, 코드에는 그게 "탐색"이라는 정보가 전혀 없어서 보조기술 사용자에게는 그냥 떠다니는 링크 몇 개일 뿐입니다.

2) 각 섹션에 닻(앵커)을 정확히 걸어라

콘텐츠 내 탐색이 작동하려면, 본문의 각 섹션마다 이동 목적지가 있어야 합니다. 웹에서는 이를 앵커(anchor)라고 부르고, 보통 섹션을 감싸는 요소에 고유한 id를 부여하는 방식으로 구현합니다. 목차의 링크는 그 id를 href="#섹션id" 형태로 가리키죠.

여기서 흔히 깨지는 지점이 있습니다. 목차 링크는 만들어 놨는데 정작 본문에는 그 id를 가진 목적지가 없는 경우입니다. 그러면 눌러도 아무 일도 안 일어나거나, 엉뚱한 곳으로 점프합니다. 반대로 디자인을 바꾸면서 본문 섹션의 id만 슬쩍 바꾸고 목차는 그대로 둬서, 링크와 목적지가 어긋나는 일도 잦습니다. 콘텐츠 내 탐색은 "목차 ↔ 본문 앵커"가 1:1로 정확히 맞아야 비로소 살아 있는 탐색이 됩니다.

3) 초점(focus)까지 이동해야 한다 — 스크롤만으로는 부족

이게 콘텐츠 내 탐색에서 가장 자주, 그리고 가장 조용히 깨지는 요건입니다.

마우스 사용자에게는 목차 링크를 눌렀을 때 화면이 해당 섹션으로 스크롤되는 것만으로 충분해 보입니다. 그런데 키보드·스크린리더 사용자에게는 그것만으로는 부족합니다. 화면은 내려갔는데 초점(focus)은 여전히 위쪽 목차에 남아 있으면, 스크린리더는 계속 목차를 읽고 있고, 다음 Tab을 누르면 방금 점프해 온 섹션이 아니라 목차의 다음 항목으로 이동해 버립니다. 사용자 입장에선 "분명 신청 방법으로 갔는데, 키보드는 아직 목차에 있는" 황당한 상황이 됩니다.

그래서 KRDS와 웹 접근성 기준은, 콘텐츠 내 탐색이 단순한 스크롤이 아니라 목적지 섹션으로 초점을 함께 옮길 것을 요구합니다. 목적지 요소에 초점을 받을 수 있게 처리(예: tabindex="-1" 후 프로그래밍 방식으로 focus)하면, 점프한 순간 스크린리더가 그 섹션의 제목부터 읽어 주고, 다음 Tab은 그 섹션 안의 요소로 이어집니다. "화면이 움직였다"와 "내 위치가 움직였다"를 일치시키는 것 — 이게 콘텐츠 내 탐색의 보이지 않는 핵심입니다.

4) 현재 위치 표시 — 지금 어느 섹션을 보고 있나

긴 페이지를 스크롤하다 보면 "내가 지금 어느 부분을 읽고 있지?"가 흐려집니다. 좋은 콘텐츠 내 탐색은 스크롤에 따라 목차에서 현재 섹션을 강조해 줍니다. 흔히 스크롤 스파이(scroll spy)라고 부르는 동작이죠.

이 현재 위치 표시는 단순히 색을 칠하는 것에 그치면 안 됩니다. 색만 바꾸면 색 구분이 어려운 사용자는 어디가 현재인지 모릅니다. 그리고 코드 수준에서도 현재 항목임을 알려야 합니다 — 보통 aria-current="true"(또는 aria-current="location")를 현재 섹션에 해당하는 목차 항목에 부여합니다. 그래야 스크린리더가 "현재 위치, 신청 방법"처럼 읽어 줘서, 눈으로 보지 않는 사용자도 자기 위치를 압니다. 시각적 강조와 코드 표시, 둘 다 있어야 완성입니다.

5) 키보드만으로 완전히 쓸 수 있어야 한다

타협 없는 요건입니다. 콘텐츠 내 탐색은 키보드만으로 다음이 전부 가능해야 합니다.

• Tab으로 목차의 각 항목에 초점 이동
• Enter로 항목 선택 → 해당 섹션으로 점프(+초점 이동)
• 점프 후 이어지는 Tab이 그 섹션 내부로 자연스럽게 연결
• 사이드 고정형이라면, 목차를 건너뛰고 본문으로 바로 갈 수 있는 경로 확보

링크 기반(<a href="#...">)으로 충실히 만들면 기본 키보드 동작이 대부분 따라옵니다. 문제는 자바스크립트로 화려한 스크롤 효과를 붙이면서 기본 동작을 가로채 버릴 때입니다. e.preventDefault()로 기본 점프를 막고 부드러운 스크롤만 넣은 뒤 초점 처리를 빼먹으면, 위에서 말한 "초점이 안 따라오는" 문제가 그대로 생깁니다. 효과를 더하더라도 키보드 동작과 초점 이동은 절대 빠뜨리면 안 됩니다.

6) 초점 표시(focus indicator) — 어디 있는지 보여야 한다

키보드로 목차 항목 사이를 이동할 때, 지금 초점이 어느 항목에 있는지 시각적으로 또렷해야 합니다. 외곽선(focus ring)이 분명하게 나타나야 하죠. 이걸 디자인이 지저분하다는 이유로 outline: none으로 지워 버리는 경우가 정말 많습니다. 그러면 키보드 사용자는 자기가 목차 어디에 있는지 알 수 없게 됩니다. 불 꺼진 방에서 손전등 없이 목차를 더듬는 셈이죠. 포커스 표시는 지우는 게 아니라 디자인과 어울리게 다듬는 게 정답입니다.

7) 건너뛰기 링크(skip link)와의 관계

콘텐츠 내 탐색은 "본문 바로가기(skip to content)" 같은 건너뛰기 링크와 사촌 관계입니다. 둘 다 "긴 화면을 거치지 않고 원하는 곳으로 바로 가게 한다"는 목적을 공유하죠. 페이지 맨 위의 건너뛰기 링크가 "메뉴를 건너뛰고 본문으로"라면, 콘텐츠 내 탐색은 "본문 안에서 원하는 섹션으로"입니다. 긴 안내 페이지라면 이 둘이 함께 있을 때 키보드 사용자의 이동이 가장 매끄럽습니다. 콘텐츠 내 탐색을 설계할 때, 페이지 상단 건너뛰기 링크가 제대로 있는지도 함께 점검하면 좋습니다.

8) 반응형 — 좁은 화면에서의 처리

PC에서 옆에 세로로 붙어 있던 사이드 목차를, 모바일에서는 어떻게 다룰지도 기준의 일부입니다. 좁은 화면에서 목차가 본문을 가리거나 너무 많은 자리를 차지하면 안 되니, 보통 상단의 접이식 목록이나 "이 페이지 내용 보기" 형태로 정리합니다. 이때도 접고 펴는 동작에 aria-expanded가 붙어야 하고, 펼쳐진 목차의 각 항목은 손가락으로 누를 수 있을 만큼 충분한 터치 영역(일반적으로 한 변 44px 이상)을 가져야 합니다. 항목이 다닥다닥 붙어 있으면 옆 섹션으로 잘못 점프하기 쉽습니다.

정리하면, KRDS의 콘텐츠 내 탐색 기준은 크게 세 축입니다. ① 구조의 명확성(진짜 nav로 선언, 목차↔앵커 1:1 일치), ② 이동의 완전성(스크롤뿐 아니라 초점까지 이동, 키보드 완전 지원), ③ 위치의 전달성(현재 섹션을 시각·코드로 함께 알릴 것). 이 세 축은 그대로 ViewCheck가 콘텐츠 내 탐색을 판정하는 기준이기도 합니다.

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

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

공공 페이지는 유난히 길다

공공 서비스의 안내 페이지는 본질적으로 깁니다. 법령에 근거한 정확한 설명, 대상·요건·절차·예외·구비 서류·문의처가 빠짐없이 들어가야 하니까요. 상업 사이트처럼 "핵심만 한 화면에"가 어렵습니다. 누락하면 민원과 분쟁이 생기니, 길어도 다 담아야 합니다. 그래서 공공 페이지는 구조적으로 "스크롤이 긴 문서"가 될 수밖에 없고, 바로 그렇기 때문에 콘텐츠 내 탐색이 사치가 아니라 필수가 됩니다. 긴 문서에 목차가 없으면, 그건 색인 없는 사전과 같습니다.

"안 쓸 자유"가 없는 사람들

상업 사이트는 불편하면 사용자가 떠나면 그만입니다. 그런데 공공 서비스는 다릅니다. 지원금을 신청하거나, 제도를 확인하거나, 증명서를 떼는 일은 그 페이지가 아니면 할 수 없습니다. 사용자가 "안 쓸 자유"가 없어요. 긴 안내 페이지에서 원하는 정보를 못 찾으면, 그건 단순한 불편이 아니라 행정 정보 접근권의 사실상 박탈이 됩니다.

특히 시각장애인이 스크린리더로 긴 페이지를 들을 때를 생각해 봅시다. 콘텐츠 내 탐색이 제대로 된 페이지라면, "탐색, 항목 5개: 신청 대상, 신청 방법, 구비 서류, 처리 기간, 문의처"를 먼저 듣고 원하는 곳으로 바로 점프할 수 있습니다. 반대로 탐색이 없으면, 처음부터 끝까지 한 줄씩 들어 내려가야 합니다. 30분짜리 음성을 다 듣고서야 "문의처"에 닿는 셈이죠. 같은 페이지가 누군가에겐 1분, 누군가에겐 30분이 되는 차이 — 콘텐츠 내 탐색은 이 격차를 줄이기 위한 장치입니다.

"화면이 움직인 것"과 "내가 움직인 것"은 다르다

비장애인은 화면이 해당 섹션으로 스크롤되면 "내가 거기로 갔다"고 느낍니다. 눈이 따라가니까요. 그런데 키보드·스크린리더 사용자에게 화면 스크롤은 아무 의미가 없을 수 있습니다. 그들에게 "위치"는 화면의 스크롤 좌표가 아니라 초점(focus)이 어디 있느냐입니다. 초점이 안 따라오면, 화면이 아무리 내려가도 그 사용자는 여전히 목차에 갇혀 있는 겁니다.

이 "시각적 위치 ≠ 초점 위치"의 분리가 콘텐츠 내 탐색 위반의 근본 원인 대부분을 차지합니다. KRDS가 단순 스크롤이 아니라 초점 이동까지 요구하는 이유가 정확히 이겁니다. 결국 모든 요건이 "보이는 것과 코드(초점·역할·현재 위치)의 일치"라는 한 가지 원리로 수렴합니다.

인지적 부담을 줄이는 것도 접근성이다

콘텐츠 내 탐색은 시각장애인만을 위한 게 아닙니다. 긴 글을 끝까지 읽기 힘든 고령 사용자, 집중이 어려운 사용자, 시간에 쫓기는 모든 사람에게 "내가 필요한 부분이 여기 있다"는 지도를 줍니다. 그리고 그 지도가 현재 위치까지 표시해 주면, "내가 지금 어디까지 봤는지"를 기억하지 않아도 됩니다. 인지적 부담을 덜어 주는 것 — 이것도 엄연한 접근성이자 사용성입니다. 콘텐츠 내 탐색이 잘 된 페이지는 "누구나" 더 편하게 씁니다.

일관성이 곧 학습 비용 절감

KRDS가 콘텐츠 내 탐색의 모습과 동작을 표준화하는 또 다른 이유는 일관성입니다. 정부 사이트마다 페이지 내 목차가 제각각이면, 사용자는 사이트를 옮길 때마다 "여기선 이게 페이지 안 이동인가, 다른 페이지로 가는 건가?"를 다시 판단해야 합니다. 모든 공공 서비스의 콘텐츠 내 탐색이 같은 방식으로 보이고 같은 방식으로 작동하면, 한 번 익힌 사용법이 어디서나 통합니다. 표준화는 디자이너의 자유를 뺏는 게 아니라, 사용자의 인지 부담을 덜어 주는 일입니다.

한 장면 — 같은 안내 페이지, 두 사람

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공 서비스의 "청년 주거 지원 안내" 페이지, 화면을 다섯 번은 넘게 스크롤해야 끝이 나는 긴 페이지에 본문 시작 부분에 "이 페이지의 내용" 목차가 하나 있다고 합시다.

먼저 마우스를 쓰는 이 주무관. 목차의 "구비 서류"를 클릭하니 화면이 스르륵 내려가 해당 부분이 나타납니다. 필요한 서류 목록을 확인하고, 다시 위로 올라가 "신청 방법"을 누릅니다. 1분도 안 걸렸습니다. 이 주무관에게 이 페이지는 아무 문제가 없습니다. 그래서 이 페이지를 만든 팀도 "잘 작동한다"고 믿습니다. 자기들이 테스트할 때 늘 마우스를 썼으니까요.

이번엔 시각장애가 있는 한 선생님. 스크린리더를 켜고 페이지에 들어옵니다. 다행히 본문 앞에 "탐색, 항목 5개"가 읽혀서, "구비 서류"를 골라 Enter를 누릅니다. 그런데 스크린리더가 계속 목차의 다음 항목 "처리 기간"을 읽기 시작합니다. 화면은 분명 구비 서류로 내려갔는데, 초점은 목차에 그대로 남아 있는 겁니다(초점 미이동). 한 선생님은 "내가 잘못 눌렀나?" 싶어 다시 Enter를 누르고, 또 목차가 읽히고… 결국 점프를 포기하고 처음부터 한 줄씩 듣기 시작합니다. 구비 서류에 닿기까지 한참이 걸립니다.

같은 페이지, 같은 목차. 한 사람에겐 1분짜리 편리한 지도이고, 다른 한 사람에겐 작동하지 않는 가짜 지도입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스 사용자만 떠올렸기 때문에, 초점 이동이라는 한 줄을 빠뜨렸기 때문에 생긴 차이입니다. KRDS의 콘텐츠 내 탐색 요건은, 이 두 사람의 경험을 같게 만들기 위한 최소한의 약속입니다.

만약 이 팀이 KRDS 킷의 콘텐츠 내 탐색 패턴을 그대로 가져다 썼다면 어땠을까요. 한 선생님이 "구비 서류"를 Enter로 고른 순간, 초점이 구비 서류 섹션의 제목으로 옮겨 가고, 스크린리더는 "구비 서류"부터 또박또박 읽기 시작했을 겁니다. 이 주무관과 똑같이 1분이면 원하는 정보에 닿았겠죠. 차이를 만드는 건 거창한 기술이 아니라, "검증된 패턴을 쓰느냐"라는 작은 선택입니다.

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

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

실수 1) 목차는 있는데 목적지가 없다

가장 허무한 실수입니다. 본문 앞에 보기 좋은 목차를 만들어 놨는데, 정작 본문의 각 섹션에 앵커(id)가 없습니다.

• 나쁜 예: "이 페이지의 내용"에 "신청 대상 · 신청 방법 · 구비 서류"가 링크로 떠 있지만, 눌러도 화면이 안 움직임. 본문에 대응하는 id가 없어서 링크가 허공을 가리킴.
• 올바른 예: 본문의 각 섹션을 감싸는 요소에 고유 id(예: <section id="apply-method">)를 부여하고, 목차 링크가 그 id를 정확히 가리킴(href="#apply-method"). 목차와 본문 앵커를 1:1로 맞춤.

실수 2) 스크롤만 하고 초점은 안 옮긴다

가장 흔하고 가장 조용한 실수입니다. 부드러운 스크롤 효과는 넣었는데, 초점 이동을 빠뜨립니다.

• 나쁜 예: 자바스크립트로 preventDefault() 후 부드럽게 스크롤만. 키보드 사용자는 화면이 내려가도 초점이 목차에 남아, 다음 Tab이 엉뚱한 곳으로 감. 스크린리더는 점프해 온 섹션을 안 읽음.
• 올바른 예: 점프 후 목적지 섹션에 초점을 옮김(목적지에 tabindex="-1" 부여 후 프로그래밍 방식 focus). 또는 기본 앵커 점프(<a href="#...">)를 그대로 살려 브라우저가 초점까지 처리하게 함. "화면 위치"와 "초점 위치"를 일치시킴.

실수 3) 현재 위치를 안 알려 준다

목차는 작동하는데, 스크롤해도 지금 어느 섹션을 보고 있는지 목차에 표시가 없습니다.

• 나쁜 예: 긴 페이지를 한참 내려와도 목차의 모든 항목이 똑같은 모습. "내가 지금 어디쯤?"을 알 수 없음.
• 올바른 예: 스크롤에 따라 현재 섹션에 해당하는 목차 항목을 시각적으로 강조하고, 동시에 aria-current를 부여해 스크린리더도 "현재 위치"를 알게 함. 시각·코드 둘 다.

실수 4) `<div>`로만 만든 가짜 내비게이션

목차를 <nav>나 목록 없이 그냥 <div>에 링크 몇 개로 만듭니다.

• 나쁜 예: 코드에 "탐색 영역"이라는 정보가 없음. 스크린리더가 랜드마크로 인식 못 해, 사용자가 이 영역을 건너뛰거나 곧장 찾아올 수 없음.
• 올바른 예: 탐색 묶음을 <nav aria-label="이 페이지 내 이동">으로 감싸고 항목은 <ul><li>로 구성. 보조기술이 "탐색, 항목 N개"로 안내.

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

현재 섹션을 목차에서 강조할 때 색만 살짝 바꿉니다.

• 나쁜 예: 현재 항목만 연한 파란 글씨. 색 구분이 어려운 사용자는 어디가 현재인지 모름. 코드 표시(aria-current)도 없어 스크린리더는 전혀 모름.
• 올바른 예: 색에 더해 굵기·표시선(좌측 막대 등) 같은 모양 차이를 주고, aria-current로 코드에도 현재임을 명시. 색·모양·코드 세 겹으로 안내.

실수 6) 초점 표시 제거

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

• 나쁜 예: 키보드로 목차를 훑어도 지금 어느 항목에 있는지 안 보임.
• 올바른 예: 포커스 시 또렷한 외곽선·강조 유지. 마우스 사용자에게 거슬리지 않게 다듬되, 키보드 사용자에게는 분명히 보이게.

실수 7) 고정 헤더에 가려지는 점프 위치

상단에 고정(스티키) 헤더가 있는 페이지에서, 섹션으로 점프하면 그 섹션 제목이 고정 헤더 뒤에 숨습니다.

• 나쁜 예: "신청 방법"을 눌렀는데 점프한 위치가 고정 헤더에 가려져, 정작 제목이 안 보이고 본문 중간부터 보임. 사용자는 "맞게 간 건가?" 혼란.
• 올바른 예: 점프 목적지에 헤더 높이만큼의 여백(scroll-margin-top 등)을 줘서, 점프 후 섹션 제목이 헤더 아래에 온전히 보이게 함.

실수 8) 모바일에서 목차가 본문을 다 가린다

PC의 사이드 목차를 모바일에서 그대로 두거나, 펼친 목차가 화면을 가득 채웁니다.

• 나쁜 예: 좁은 화면에서 목차가 본문 위에 길게 깔려, 정작 내용을 보려면 한참 스크롤해야 함. 항목 터치 영역도 작아 옆 섹션으로 잘못 점프.
• 올바른 예: 좁은 화면에서는 접이식("이 페이지 내용 보기")으로 정리하고, 펼침/접힘에 aria-expanded를 붙임. 각 항목은 충분한 터치 영역(약 44px 이상) 확보.

실수 9) "맨 위로" 버튼만 있고 진짜 탐색은 없다

긴 페이지에 "맨 위로(Top)" 버튼 하나만 달아 두고, 정작 섹션별 점프 목차는 없습니다.

• 나쁜 예: 끝까지 내려갔다가 맨 위로만 갈 수 있을 뿐, 원하는 섹션으로 바로 못 감. 사용자는 매번 위에서부터 스크롤로 찾아 내려가야 함.
• 올바른 예: 섹션 목차(콘텐츠 내 탐색)를 주된 장치로 두고, "맨 위로"는 보조로. 긴 페이지일수록 둘을 함께 제공.

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

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

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소의 html/code 폴더에서 탐색 관련 컴포넌트 코드를 확인해, <nav> 구조·앵커 연결·키보드 동작이 어떻게 짜이는지 참고할 수 있습니다. 직접 구현할 때 핵심은 세 가지를 절대 빠뜨리지 않는 것입니다 — ① 본문 섹션마다 고유 id, ② 점프 시 초점 이동, ③ 스크롤에 따른 aria-current 갱신. 화려한 스크롤 효과를 넣더라도 이 셋은 반드시 살려 두세요. "접근성은 어렵다"는 말의 절반은 "직접 만들다 빠뜨려서 어렵다"는 뜻인데, 빠뜨리기 쉬운 지점이 정확히 이 셋입니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 탐색 컴포넌트의 표준 모습과 상태(기본/현재 위치/포커스)를 가져다 쓸 수 있습니다. 시안 단계에서 "현재 위치는 어떻게 강조할지", "포커스는 어떻게 보일지"를 색뿐 아니라 모양으로도 정의해 두면, 개발 단계에서 색만으로 처리하는 실수를 막을 수 있습니다. 또 고정 헤더가 있는 디자인이라면, 점프 시 섹션 제목이 가려지지 않도록 여백을 시안에 미리 표시해 두세요.

기획자라면 — 긴 안내 페이지를 기획할 때 화면 정의서에 "본문 목차(콘텐츠 내 탐색) 포함, 5개 섹션, 현재 위치 표시"처럼 명시하세요. 그냥 "긴 안내 페이지"라고만 적으면 목차가 통째로 빠지기 쉽습니다. 그리고 섹션 제목을 명확하고 짧게 정해 두면(예: "신청 대상", "구비 서류"), 목차가 그대로 길잡이가 됩니다. 모호한 제목은 좋은 목차를 만들 수 없습니다.

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

여기까지가 KRDS의 콘텐츠 내 탐색 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트의 긴 페이지들은 이걸 지키고 있나?"를 확인하는 일입니다. 페이지마다 목차가 있는지, 목차 링크가 실제 본문 앵커와 맞는지, 점프했을 때 초점이 따라가는지, 현재 위치가 코드로 표시되는지를 사람이 일일이 손으로 점검하려면 끝이 없습니다. 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

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

ViewCheck가 콘텐츠 내 탐색에 대해 자동으로 보는 것들:

• 탐색 구조 여부: 목차가 <nav>/role="navigation"으로 선언돼 있고 목록 구조를 갖췄는지, 페이지에 탐색 영역이 여럿일 때 각각 이름으로 구별되는지
• 앵커 연결: 목차 링크의 href="#..."가 가리키는 목적지(id)가 본문에 실제로 존재하는지(끊어진 앵커 탐지)
• 현재 위치 표시: 현재 섹션을 알리는 코드 표시(aria-current 등)가 있는지
• 포커스 표시·키보드 접근: 목차 항목이 키보드로 닿고, 포커스 표시가 제거되지 않았는지
• 터치 영역: 모바일 뷰포트에서 목차 항목이 최소 권장 크기를 충족하는지(반응형 품질 분석과 연계)

DOM만으로 판단하기 어려운 시각적·동적 부분(예: 점프 후 초점이 실제로 옮겨 가는지, 스크롤에 따라 현재 항목이 강조되는지)은 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 "코드엔 탐색 같은 게 안 보이는데 화면엔 분명히 페이지 내 목차가 있는" 비표준 구현도 놓치지 않습니다. 이 점이 단순 코드 검사 도구와 다른 부분입니다 — 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회해 만든 UI도 잡아냅니다.

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 콘텐츠 내 탐색 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "안내 페이지의 목차 링크 5개 중 2개가 끊어진 앵커"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "정책 안내 페이지엔 목차가 있는데 제도 소개 페이지엔 없다" 같은 페이지별 편차도 한눈에 드러납니다. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

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

자주 묻는 질문

현장에서 콘텐츠 내 탐색을 다룰 때 반복해서 나오는 질문들을 모았습니다.

Q. 페이지가 길지 않으면 콘텐츠 내 탐색은 없어도 되나요?

한 화면(혹은 한두 번 스크롤)에 다 들어오는 짧은 페이지라면 굳이 목차가 필요 없습니다. 오히려 짧은 페이지에 목차를 달면 군더더기가 됩니다. 기준은 "스크롤이 길어 사용자가 원하는 부분을 한눈에 못 찾는가"입니다. 보통 본문에 명확히 구분되는 섹션이 3~4개 이상이고 화면을 여러 번 스크롤해야 한다면, 콘텐츠 내 탐색을 두는 게 좋습니다. 안내문·약관·매뉴얼·FAQ처럼 길어지기 쉬운 페이지가 대표적 대상입니다.

Q. 콘텐츠 내 탐색과 탭(Tab) 중 뭘 써야 하나요?

둘은 비슷해 보이지만 사고방식이 다릅니다. 탭은 "여러 묶음 중 하나만 보여 주고 나머지는 숨기는" 방식이고, 콘텐츠 내 탐색은 "모든 내용이 한 페이지에 있고 그중 원하는 곳으로 점프하는" 방식입니다. 인쇄하거나 Ctrl+F로 한 번에 검색해야 하는 정보(법령 안내 등)는 모든 내용이 펼쳐져 있는 콘텐츠 내 탐색이 유리합니다. 반대로 내용이 명확히 분리되고 동시에 볼 필요가 없다면 탭이 깔끔합니다. 둘 다 키보드·스크린리더 요건은 그대로 적용됩니다.

Q. 부드러운 스크롤(smooth scroll) 효과를 넣어도 되나요?

넣어도 됩니다. 다만 효과를 넣느라 기본 동작을 가로챘다면, 초점 이동을 반드시 직접 처리해야 합니다. 부드러운 스크롤 자체가 문제가 아니라, 그것 때문에 초점이 안 따라오는 게 문제입니다. 또 일부 사용자는 화면 움직임에 민감하므로, 운영체제의 "동작 줄이기(prefers-reduced-motion)" 설정을 존중해 효과를 줄이는 배려도 더하면 좋습니다.

Q. 앵커 링크를 누르면 URL에 `#섹션id`가 붙던데, 그대로 둬도 되나요?

괜찮습니다. 오히려 장점이 있습니다. URL에 섹션 식별자가 남으면, 그 링크를 복사해 공유하면 받는 사람이 바로 그 섹션으로 갈 수 있고, 즐겨찾기로도 특정 섹션을 저장할 수 있습니다. 다만 섹션 id는 의미가 통하게(예: #required-documents) 짓는 게 좋고, 한 번 공개한 id는 함부로 바꾸지 않는 게 좋습니다. id를 바꾸면 그동안 공유된 링크가 다 깨집니다.

Q. 현재 위치 강조(스크롤 스파이)는 꼭 있어야 하나요?

"있어야 완성"에 가깝습니다. 점프 기능만 있어도 기본은 하지만, 긴 페이지에서 현재 위치 표시가 없으면 사용자는 "내가 지금 어디까지 봤지?"를 매번 가늠해야 합니다. 특히 스크린리더 사용자에게는 aria-current로 현재 섹션을 알려 주는 것이 위치 감각을 유지하는 데 큰 도움이 됩니다. 구현이 부담된다면, 최소한 점프 후 초점 이동(필수)부터 확실히 하고, 현재 위치 강조는 그다음 단계로 보강하세요.

Q. 고정 헤더 때문에 점프한 섹션 제목이 가려집니다.

흔한 문제이고 해결도 간단합니다. 점프 목적지가 되는 섹션(또는 그 제목)에 고정 헤더 높이만큼의 위쪽 여백을 주면 됩니다. CSS의 scroll-margin-top을 헤더 높이에 맞춰 지정하면, 점프 후 섹션 제목이 헤더 아래에 온전히 보입니다. 헤더 높이가 반응형으로 달라진다면 화면 크기별로 값을 맞춰 주면 됩니다.

Q. 이미 운영 중인 긴 페이지가 많은데, 전부 다시 만들어야 하나요?

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "어느 긴 페이지에 목차가 없는지, 있는 목차 중 앵커가 끊긴 건 어디인지"를 목록으로 만든 다음, 뒤에서 볼 우선순위대로 치명적인 것부터 차례로 고치면 됩니다. 특히 신청·제도 안내처럼 사용 빈도가 높고 분량이 긴 핵심 페이지부터 목차를 보강하면, 적은 작업으로 가장 많은 사용자를 도울 수 있습니다. 리뉴얼 예산을 한 번에 들이지 않고도 점진적으로 점수를 끌어올리는 게 현실적인 전략입니다.

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

콘텐츠 내 탐색은 어느 한 팀의 책임이 아니라 합작입니다. 기획자는 어떤 페이지에 목차가 필요한지와 섹션 제목을 정하고, 디자이너는 현재 위치·포커스를 색뿐 아니라 모양으로도 정의하고, 개발자는 앵커 연결·초점 이동·aria-current를 구현해야 합니다. 그래서 KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 겁니다. 세 팀이 같은 기준을 보고 일하면 "네 일/내 일" 논쟁이 줄어듭니다.

Q. 콘텐츠가 자동으로 갱신되는 페이지(공지·게시판 등)에서는 목차를 어떻게 관리하나요?

내용이 동적으로 바뀌는 페이지라면, 목차도 본문 섹션을 기준으로 자동 생성하는 방식을 권합니다. 섹션 제목(<h2> 등)을 훑어 목차를 만들면, 본문이 추가·삭제돼도 목차와 앵커가 자동으로 맞아 끊어진 앵커가 생기지 않습니다. 손으로 목차를 따로 관리하면 본문 변경 때마다 어긋나기 쉽습니다. 자동 생성을 하더라도 각 섹션의 id가 의미 있게 부여되는지, 그리고 점프 시 초점 이동·현재 위치 표시가 그대로 작동하는지는 별도로 확인해야 합니다.

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

ViewCheck로 돌려 보면 보통 콘텐츠 내 탐색 문제가 한두 개로 끝나지 않습니다. 긴 페이지가 많을수록 "고칠 게 많다"는 압박감이 듭니다. 그래서 우선순위가 중요합니다. 콘텐츠 내 탐색 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 키보드·스크린리더 사용자가 긴 페이지에서 원하는 곳으로 아예 못 가는 경우. 점프해도 초점이 안 따라오거나, 목차가 코드상 탐색으로 인식되지 않거나, 앵커가 통째로 끊겨 점프 자체가 안 되는 문제입니다. 이건 특정 사용자에게 긴 페이지를 사실상 차단하는 문제라 1순위입니다. 신청·제도 안내처럼 핵심 경로의 긴 페이지라면 더더욱 먼저 손봐야 합니다.

그다음(높음) — 현재 위치를 코드로 알려 주지 않는 경우, 그리고 일부 앵커만 끊긴 경우. 점프는 되지만 사용자가 자기 위치를 잃거나 일부 섹션에 못 닿는 실질적 장벽입니다. 긴 안내 페이지에 목차 자체가 없는 것도 여기에 가깝습니다(콘텐츠 양에 따라 치명적으로 올라갈 수 있음).

그 후(보통) — 현재 위치를 색으로만 표시, 포커스 표시 제거, 고정 헤더에 가려지는 점프, 모바일에서 목차가 본문을 가리는 문제. 사용은 가능하지만 특정 상황·특정 사용자에게 불편을 주는 항목입니다.

여력이 되면(낮음) — 섹션 id를 의미 있게 다듬기, "맨 위로" 버튼 보강, 부드러운 스크롤에 동작 줄이기 옵션 추가 같은 사용성 개선. 접근성을 막는 건 아니지만 경험을 한 단계 끌어올리는 항목입니다.

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

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

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

• KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 컴포넌트별 정의와 사용 원칙의 1차 원천.
• KRDS 컴포넌트 문서(웹) — 콘텐츠 내 탐색의 형태·예시를 화면으로 확인.
• KRDS 컴포넌트 킷(GitHub `KRDS-uiux/krds-uiux`) — 탐색 컴포넌트 코드를 그대로 가져다 사용(npm install krds-uiux 또는 CDN).
• KRDS 공식 Figma(@krds) — 디자이너용 탐색 컴포넌트와 상태(현재 위치/포커스 포함).

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

오늘의 체크리스트 — 콘텐츠 내 탐색, 이것만은

마지막으로, 디자이너·개발자·기획자가 콘텐츠 내 탐색을 만들거나 검수할 때 바로 쓸 수 있는 체크리스트로 정리합니다.

• ☐ 긴 페이지(섹션 3~4개 이상, 여러 번 스크롤)에 콘텐츠 내 탐색(목차)이 있다.
• ☐ 탐색 묶음이 <nav>/role="navigation"으로 선언되고 목록 구조(<ul><li>)를 갖췄다.
• ☐ 탐색 영역이 여럿이면 각각 이름으로 구별된다(aria-label 등).
• ☐ 본문의 각 섹션마다 고유 앵커(`id`)가 있고, 목차 링크가 정확히 일치한다(끊어진 앵커 없음).
• ☐ 항목을 누르면 화면 스크롤뿐 아니라 초점(focus)도 해당 섹션으로 이동한다.
• ☐ 스크롤에 따라 현재 섹션이 강조되고, 코드로도 표시된다(aria-current 등).
• ☐ 현재 위치를 색만이 아니라 모양(굵기·표시선 등)으로도 알린다.
• ☐ 키보드만으로 목차 이동·선택·점프 후 본문 진입이 전부 된다.
• ☐ 포커스 표시가 또렷하다(outline: none으로 지우지 않았다).
• ☐ 고정 헤더가 있어도 점프한 섹션 제목이 가려지지 않는다(scroll-margin-top 등).
• ☐ 모바일에서 목차가 본문을 가리지 않고(접이식 등), 항목 터치 영역이 충분하다(약 44px 이상).

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)과 공식 Figma 라이브러리(@krds)를 함께 쓰면 위 항목 대부분을 표준에 맞춰 시작할 수 있습니다. 직접 만들다 초점 이동·앵커 연결·현재 위치 표시를 빠뜨릴 위험을 줄이는 가장 확실한 방법이죠.

콘텐츠 내 탐색은 작아 보이지만, 공공 서비스의 긴 안내 페이지 거의 모든 곳에 필요한 길잡이입니다. 그 작은 목차 하나가 누군가에겐 30분짜리 음성을 1분으로 줄여 주는 지도이고, 또 누군가에겐 있으나 마나 한 가짜 지도입니다. 우리가 무심코 넘긴 "긴 페이지"가, 누군가에게는 끝까지 다 듣고서야 원하는 정보에 닿느냐 못 닿느냐를 가릅니다.

오늘 정리한 기준이 거창해 보일 수 있지만, 핵심은 결국 단순합니다. 진짜 탐색으로 선언하고, 목차와 본문 앵커를 정확히 맞추고, 점프할 때 초점까지 데려가고, 지금 어디인지 색이 아니라 코드로도 알리는 것. 이 네 가지만 챙겨도 콘텐츠 내 탐색의 위반 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 긴 페이지, 가장 많이 막히는 목차 하나부터 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 많은 사람에게 길을 열어 줍니다. 다음 글에서는 콘텐츠 내 탐색과 짝을 이루는 또 다른 탐색 컴포넌트를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 긴 안내 페이지는 지금 길을 잘 안내하고 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 가장 긴 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #콘텐츠내탐색Inpagenavigation #웹접근성 #ViewCheck #정부웹사이트 #UIUX #앵커링크 #페이지내비게이션 #스크린리더 #키보드접근성 #콘텐츠내탐색 #KRDS기준 #디자인원칙 #표준가이드 #UI컴포넌트 #컴포넌트설계 #전자정부 #디지털정부