헤더(Header) 완전 해부 — KRDS 공식 기준

어떤 공공 사이트에 처음 들어갔을 때, 우리가 의식하지도 못한 채 가장 먼저 시선을 던지는 곳이 있습니다. 화면 맨 위, 가로로 길게 자리 잡은 그 띠. 왼쪽엔 기관 로고와 이름이 있고, 가운데나 그 아래엔 메뉴가 줄지어 있고, 오른쪽 구석엔 검색 돋보기와 "로그인" 글자, 그리고 작은 글씨로 박힌 "전체메뉴". 우리는 그걸 그냥 "사이트 위쪽"이라고 부르고 넘어갑니다. 그런데 이 띠 하나가, 사실은 그 사이트가 잘 만들어졌는지 아닌지를 가장 먼저 드러내는 자리입니다.

헤더(Header)는 모든 페이지의 맨 위에 항상 붙어 다니는 컴포넌트입니다. 본문이 아무리 잘 만들어져 있어도, 헤더에서 길을 잃으면 사용자는 본문에 닿지도 못합니다. 반대로 헤더가 명확하면, 사용자는 "여기가 어디고, 어디로 갈 수 있고, 무엇을 할 수 있는지"를 0.5초 만에 파악합니다. 그래서 헤더는 사이트의 얼굴이자 안내데스크이고, 동시에 가장 많은 사람이 거쳐 가는 길목입니다. 한 페이지에서만 보이는 게 아니라 모든 페이지에서 보이니까, 헤더의 작은 결함 하나는 사이트 전체에 수백 배로 복제됩니다.

공공 웹사이트를 수백 개 들여다보다 보면, 헤더에서 똑같은 문제가 끝없이 반복되는 걸 봅니다. 로고를 눌러도 홈으로 안 가거나, 메뉴가 키보드로는 열리지 않거나, "전체메뉴" 버튼이 화면 읽기 프로그램에는 그냥 "버튼"으로만 읽히거나, 스크롤하면 헤더가 본문을 가려 버리거나. 모양은 다들 그럴듯하게 만들어 놓는데, 정작 "누구나 쓸 수 있는가"를 따지면 빈틈이 숭숭 뚫려 있습니다.

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

헤더가 대체 뭐길래 — 정의부터 정확히

먼저 용어부터 맞추겠습니다. 우리가 "사이트 위쪽"이라고 뭉뚱그려 부르는 영역은 사실 여러 역할이 한곳에 모인 복합 컴포넌트입니다. KRDS는 이걸 명확히 구분합니다.

• 헤더(Header): 페이지 최상단의 띠 전체. 식별(로고·기관명), 탐색(메뉴), 기능(검색·로그인·전체메뉴), 보조 정보(언어 전환 등)를 한데 담는 그릇입니다.
• 메인 메뉴 / GNB(Global Navigation Bar): 헤더 안에 들어가는, 사이트 전체를 가로지르는 주요 메뉴. 헤더의 일부이지만 그 자체로도 별도의 컴포넌트로 다뤄집니다.
• 푸터(Footer): 페이지 맨 아래의 띠. 헤더와 짝을 이루지만 역할이 다릅니다(기관 정보, 약관, 관련 사이트 링크 등).
• 스킵 내비게이션(Skip Navigation): 헤더의 반복되는 메뉴를 건너뛰고 본문으로 바로 가는 숨은 링크. 헤더와 떼려야 뗄 수 없는 짝입니다.

이 구분이 왜 중요하냐면, 헤더를 "그냥 위쪽 디자인"으로만 보면 그 안에 담긴 각각의 역할이 제대로 작동하는지 따지지 않게 되기 때문입니다. 헤더는 단일 덩어리가 아니라, 여러 작은 컴포넌트가 모인 "동네"입니다. 로고도 하나의 역할, 메뉴도 하나의 역할, 검색 버튼도, 전체메뉴 버튼도 각각의 역할이 있습니다. 이 모두가 제 몫을 해야 헤더가 헤더답게 작동합니다.

KRDS 컴포넌트 문서와 킷(GitHub KRDS-uiux/krds-uiux)을 열어 보면, 헤더가 단순히 "로고와 메뉴를 얹은 박스"가 아니라, 식별·탐색·기능·접근이라는 네 가지 책무를 동시에 짊어진 구조물로 정의돼 있습니다. 그리고 이 네 책무 각각에 지켜야 할 기준이 따로 있습니다.

헤더가 담는 네 가지 책무

① 식별(Identification) — "여기가 어디인가"를 알리는 일입니다. 기관 로고와 이름이 여기 들어갑니다. 사용자가 어떤 경로로 들어왔든, 헤더만 보면 "아, 여기는 ○○ 기관 사이트구나"를 알 수 있어야 합니다. 그리고 로고는 거의 모든 사이트에서 "홈으로 가는 버튼" 역할을 겸합니다.

② 탐색(Navigation) — "어디로 갈 수 있는가"를 보여 주는 일입니다. 주요 메뉴(GNB)가 여기 들어갑니다. 사이트의 큰 줄기를 한눈에 보여 주고, 원하는 곳으로 데려다줍니다.

③ 기능(Utility) — "무엇을 할 수 있는가"입니다. 검색, 로그인/로그아웃, 회원가입, 전체메뉴, 언어 전환, 글자 크기 조절 같은 보조 기능들이 여기 모입니다. 본문 내용과 별개로 어느 페이지에서나 쓸 수 있어야 하는 기능들이죠.

④ 접근(Access) — "누구나 닿을 수 있는가"입니다. 스킵 내비게이션, 키보드 조작, 화면 읽기 프로그램 대응 같은 접근성 장치가 여기 속합니다. 앞의 세 책무가 아무리 화려해도, 이 네 번째가 빠지면 일부 사용자에게 헤더는 닫힌 문이 됩니다.

이 네 가지를 따로 떼어 보는 습관이 중요합니다. "헤더가 예쁜가"가 아니라 "이 헤더는 식별을 잘하나, 탐색을 잘하나, 기능을 잘 담았나, 누구나 접근 가능한가"를 각각 물어야, 어디가 부족한지가 보입니다.

KRDS는 헤더에 무엇을 요구하나 — 기준 완전 해부

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서를 기준으로, 헤더가 충족해야 하는 요건을 영역별로 정리하겠습니다. 미리 말해 두면, 헤더의 요건은 대부분 "보기 좋게"보다 "구조가 올바르게"에 방점이 찍혀 있습니다.

1) 시맨틱 구조 — 헤더는 코드로도 "헤더"여야 한다

가장 먼저, 헤더는 화면에서만 헤더처럼 보이는 게 아니라 코드 수준에서도 "헤더"라고 선언돼 있어야 합니다. 웹 표준으로 말하면, 페이지 최상단 영역은 <header> 요소(또는 role="banner")로 감싸야 합니다. 이렇게 하면 화면 읽기 프로그램이 "배너 영역" 또는 "헤더"라고 인식하고, 사용자가 랜드마크 단위로 빠르게 이동할 수 있습니다.

비장애인은 화면을 눈으로 훑으며 "위쪽 띠가 헤더구나"를 직관적으로 압니다. 하지만 스크린리더 사용자는 그 직관이 없습니다. 코드가 "여기는 배너 영역입니다"라고 말해 줘야, 그 사용자도 헤더를 헤더로 인식하고 건너뛰거나 탐색할 수 있습니다. <div class="header">로만 만들고 시맨틱 태그를 빼면, 모양은 헤더인데 코드상으로는 그냥 의미 없는 박스 덩어리가 됩니다.

마찬가지로 헤더 안의 주요 메뉴는 <nav> 요소(또는 role="navigation")로 감싸야 합니다. 그래야 "이건 내비게이션 영역이구나"가 코드로 전달됩니다. 헤더 안에 내비게이션이 여러 개라면(예: 주요 메뉴와 보조 메뉴), 각각에 이름(aria-label)을 붙여 구분해 주는 게 좋습니다. "주메뉴", "유틸리티 메뉴"처럼요.

2) 로고 — 식별과 홈 이동을 동시에

헤더의 로고는 두 가지 일을 합니다. 첫째, 기관을 식별합니다. 둘째, 거의 항상 "홈으로 가는 링크" 역할을 겸합니다. 그래서 로고는 단순 이미지가 아니라 링크로 감싼 이미지여야 합니다.

여기서 흔히 빠뜨리는 게 대체 텍스트(alt)입니다. 로고 이미지에는 기관명을 담은 대체 텍스트가 반드시 있어야 합니다. 화면 읽기 프로그램은 이미지를 "볼" 수 없으니, alt="○○ 기관 홈페이지" 같은 텍스트가 없으면 사용자는 그 로고가 무엇인지, 어디로 가는 링크인지 알 수 없습니다. 빈 alt로 두거나, 파일명("logo.png")이 그대로 읽히게 두는 건 모두 잘못입니다.

또 하나, 로고 링크의 목적지가 사용자의 기대와 맞아야 합니다. 사람들은 헤더 로고를 누르면 홈으로 갈 거라고 기대합니다. 이 기대를 깨고 엉뚱한 페이지로 보내거나, 아예 링크가 아니라 클릭해도 아무 일도 안 일어나면, 사용자는 길 찾기의 가장 기본적인 수단 하나를 잃습니다.

3) 주요 메뉴(GNB) — 키보드로 완전히 다룰 수 있어야 한다

헤더의 핵심인 주요 메뉴는 마우스 없이 키보드만으로 완전히 조작할 수 있어야 합니다. 이건 타협이 없는 요건입니다.

• Tab으로 메뉴 항목 사이를 순서대로 이동
• 하위 메뉴가 있는 항목은 Enter / Space / 방향키로 펼치기
• 펼쳐진 하위 메뉴 안에서 방향키로 이동
• Esc로 펼친 메뉴 닫기
• 펼침 상태가 코드로 표현(aria-expanded)돼 화면 읽기 프로그램에 전달

문제는 디자인을 위해 메뉴를 <div>와 <ul>로 직접 만들고, 마우스 호버(hover)에만 반응하게 구현할 때입니다. 마우스를 메뉴 위에 올려야 하위 메뉴가 펼쳐지는 방식은, 키보드 사용자에게는 아예 작동하지 않습니다. 호버는 키보드에 존재하지 않는 동작이니까요. 그래서 호버로만 열리는 메뉴는 키보드 사용자에게 "보이지만 닿을 수 없는" 메뉴가 됩니다. KRDS 킷이 키보드 동작과 ARIA 속성이 구현된 헤더 코드를 제공하는 이유가 정확히 이겁니다.

4) 스킵 내비게이션 — 반복을 건너뛰는 숨은 문

헤더는 모든 페이지에 똑같이 반복됩니다. 그런데 화면 읽기 프로그램이나 키보드 사용자에게는, 페이지를 이동할 때마다 헤더의 메뉴 수십 개를 처음부터 다시 훑어야 하는 부담이 생깁니다. 본문을 읽으려면 매번 메뉴를 다 지나가야 하니까요. 이 반복 부담을 없애는 장치가 스킵 내비게이션입니다.

스킵 내비게이션은 페이지 맨 처음에 숨겨져 있다가, 키보드로 Tab을 누르면 가장 먼저 나타나는 "본문 바로가기" 링크입니다. 이걸 누르면 메뉴를 전부 건너뛰고 본문으로 곧장 점프합니다. 마우스 사용자에게는 평소 보이지 않지만, 키보드 사용자에게는 필수적인 첫 관문입니다.

KRDS와 한국형 웹 접근성 지침(KWCAG)은 이 스킵 내비게이션을 강하게 요구합니다. "본문 바로가기" 한 줄이 빠지면, 키보드·스크린리더 사용자는 매 페이지마다 똑같은 메뉴를 반복해서 통과하는 고역을 치릅니다. 그리고 이 링크는 평소엔 숨어 있되, 포커스를 받으면 반드시 화면에 보이게 나타나야 합니다. 숨겨 둔 채 포커스 시에도 안 보이면, 키보드 사용자는 자기가 지금 그 링크에 있는지조차 알 수 없습니다.

5) 검색·로그인·전체메뉴 — 기능 요소의 이름표

헤더 우측에 모이는 기능 요소들 — 검색 돋보기, 로그인, 전체메뉴, 언어 전환 — 은 대개 아이콘이나 짧은 글자로 표현됩니다. 그런데 아이콘만 있고 텍스트 라벨이 없으면, 화면 읽기 프로그램은 그게 무슨 버튼인지 알 수 없습니다. 돋보기 아이콘 하나만 있는 검색 버튼은 스크린리더에게 그냥 "버튼"으로 읽힙니다.

그래서 이 기능 버튼들에는 접근 가능한 이름이 반드시 있어야 합니다. 아이콘 옆에 보이는 텍스트가 있거나, 없다면 aria-label="검색", aria-label="전체메뉴 열기" 같은 이름이 코드로 박혀 있어야 합니다. 특히 "전체메뉴" 버튼은 누르면 큰 메뉴 패널이 열리는 토글이니, 펼침 상태(aria-expanded)도 함께 알려 줘야 합니다. "전체메뉴 열기 / 닫기"가 상태에 따라 정확히 전달돼야, 화면 읽기 프로그램 사용자도 지금 메뉴가 열려 있는지 닫혀 있는지 압니다.

6) 고정 헤더(Sticky)와 모바일 대응

요즘 헤더는 스크롤해도 화면 위에 계속 붙어 있는 "고정 헤더(sticky)" 방식이 많습니다. 편리하지만 함정이 있습니다. 헤더가 너무 두꺼우면 작은 화면에서 본문을 가려 버립니다. 특히 본문 안의 링크로 점프했을 때, 고정 헤더가 그 지점을 덮어 버리는 일이 자주 생깁니다. 고정 헤더를 쓸 거라면 높이를 적절히 관리하고, 본문이 가려지지 않도록 여백을 확보해야 합니다.

모바일에서는 헤더 구조가 달라집니다. 좁은 화면에 메뉴를 다 펼칠 수 없으니, 보통 "햄버거 메뉴"(줄 세 개 아이콘)로 접어 두고, 누르면 전체 메뉴가 펼쳐지는 방식을 씁니다. 이때도 햄버거 버튼에 "메뉴 열기"라는 이름이 있어야 하고, 펼침 상태가 코드로 표현돼야 하며, 펼쳐진 메뉴를 키보드로 다룰 수 있어야 합니다. 그리고 햄버거 버튼과 펼쳐진 메뉴 항목들은 손가락으로 정확히 누를 수 있을 만큼 충분히 커야 합니다 — 한 변 44px 이상이 일반적인 기준입니다.

7) 일관성 — 모든 페이지에서 같아야 한다

헤더는 모든 페이지에 등장하므로, 페이지마다 모양과 동작이 달라지면 안 됩니다. 메인에서는 로고가 왼쪽이었는데 하위 페이지에서는 가운데로 가거나, 어떤 페이지에서는 검색이 있는데 다른 페이지에서는 없거나, 메뉴 구성이 페이지마다 들쭉날쭉하면 사용자는 매번 헤더를 다시 학습해야 합니다. KRDS가 헤더를 표준 컴포넌트로 제공하는 큰 이유가 이 일관성입니다. 한 번 익힌 헤더 사용법이 모든 페이지에서 통해야, 사용자의 인지 부담이 줄어듭니다.

정리하면, KRDS의 헤더 기준은 크게 세 축입니다. ① 구조의 정직성(시맨틱 태그·랜드마크로 코드도 헤더답게), ② 조작 가능성(키보드 완전 지원, 스킵 내비게이션, 충분한 터치 영역), ③ 전달성(로고·기능 버튼의 이름과 상태가 코드로 전달돼 스크린리더가 읽을 것). 이 세 축은 그대로 ViewCheck가 헤더를 판정하는 기준이기도 합니다.

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

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

헤더는 "모든 페이지"에 곱해진다

헤더의 결함이 특별히 무서운 건, 그것이 한 페이지의 문제로 끝나지 않기 때문입니다. 본문의 어떤 버튼이 잘못되면 그 페이지에서만 문제지만, 헤더의 메뉴가 키보드로 안 열리면 사이트의 모든 페이지에서 그 문제가 반복됩니다. 페이지가 100개면 결함도 100배로 복제되는 셈이죠. 그래서 헤더는 "가장 먼저, 가장 철저히" 점검해야 하는 컴포넌트입니다. 헤더 하나를 제대로 고치면 사이트 전체의 접근성이 한 번에 올라갑니다. 투자 대비 효과가 가장 큰 곳이 바로 헤더입니다.

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

상업 사이트는 헤더가 불편하면 사용자가 떠나면 그만입니다. 경쟁사로 가면 되니까요. 그런데 공공 서비스는 다릅니다. 주민등록 등본을 떼거나, 건강보험을 신청하거나, 세금을 내는 일은 그 사이트가 아니면 할 수 없습니다. 사용자가 "안 쓸 자유"가 없어요. 그래서 공공 웹의 헤더가 누군가에게 작동하지 않으면, 그건 단순한 불편이 아니라 행정 서비스 접근권의 박탈이 됩니다.

헤더의 메뉴가 스크린리더로 안 읽히면, 시각장애인은 그 사이트의 어떤 기능에도 닿지 못합니다. 본문으로 가는 길 자체가 막히니까요. 스킵 내비게이션이 없으면, 매 페이지마다 메뉴 수십 개를 다시 통과하느라 지쳐 떨어집니다. 로고에 대체 텍스트가 없으면, "여기가 어디 사이트인지"조차 음성으로 알 수 없습니다. 이게 KRDS가 헤더의 키보드·스크린리더 지원을 "있으면 좋은 것"이 아니라 "기본 요건"으로 두는 이유입니다.

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

비장애인은 화면을 "본다"고 생각하지만, 사실 우리는 화면을 보고 머릿속에서 의미로 번역합니다. 위쪽 띠를 보고 "아, 이게 헤더고, 저기가 메뉴구나" 하고 짐작하죠. 스크린리더 사용자에게는 이 짐작 과정이 없습니다. 코드가 알려 주는 정보가 곧 전부입니다.

그래서 헤더는 "보기에 헤더 같은 것"으로는 부족하고, "코드 수준에서 헤더라고 선언된 것"이어야 합니다. <div>에 로고와 메뉴를 얹어 헤더처럼 보이게 만들어도, 코드가 그걸 "배너 영역", "내비게이션"이라고 말해 주지 않으면 스크린리더에겐 그냥 의미 없는 글자 덩어리입니다. 이 "보이는 것 ≠ 읽히는 것" 문제가 헤더 위반의 근본 원인 대부분을 차지합니다. KRDS의 모든 컴포넌트 요건이 결국 "시각과 코드의 일치"라는 한 가지 원리로 수렴하는 셈입니다.

첫인상이 신뢰를 만든다

심리학적으로도 헤더는 특별합니다. 사용자가 사이트에 들어와 가장 먼저 보는 영역이고, 첫인상이 그 사이트의 신뢰도를 좌우합니다. 헤더가 정돈돼 있고 명확하면 "제대로 관리되는 사이트구나" 하는 안심을 주고, 헤더가 어수선하고 길을 못 찾게 만들면 "이 사이트 괜찮은 건가" 하는 불안을 줍니다. 공공 서비스의 신뢰는 곧 행정의 신뢰로 이어집니다. 잘 만든 헤더는 그래서 단순한 디자인이 아니라, 기관에 대한 신뢰를 짓는 첫 벽돌입니다.

일관성이 곧 학습 비용 절감

KRDS가 헤더의 구조와 동작을 표준화하는 또 다른 이유는 일관성입니다. 정부 사이트마다 헤더가 제각각이면, 사용자는 사이트를 옮길 때마다 "여기선 메뉴가 어디 있지? 로그인은 어디지?"를 다시 배워야 합니다. 모든 공공 서비스의 헤더가 같은 자리에 같은 방식으로 있으면, 한 번 익힌 사용법이 모든 사이트에서 통합니다. 디지털 약자에게 이 "다시 안 배워도 됨"은 생각보다 큰 배려입니다. 표준화는 디자이너의 자유를 뺏는 게 아니라, 사용자의 인지 부담을 덜어 주는 일입니다.

특히 고령 사용자나 디지털에 익숙하지 않은 분들을 떠올려 보면 이 일관성의 가치가 더 분명해집니다. 익숙한 사람에게는 헤더가 사이트마다 조금씩 달라도 금세 적응하는 사소한 차이일 뿐이지만, 디지털 약자에게는 그 작은 차이 하나하나가 새로 넘어야 할 문턱이 됩니다. "로그인이 어디 있더라", "검색은 어디서 하지", "이전 페이지로는 어떻게 돌아가지" 같은 질문이 사이트를 옮길 때마다 처음부터 반복됩니다. 모든 공공 헤더가 같은 약속을 지키면, 이 사용자는 한 번 익힌 길을 평생 다시 안 배워도 됩니다. 행정 서비스가 "누구나" 쓸 수 있어야 한다는 목표는, 바로 이런 작은 일관성들이 쌓여 이루어집니다.

한 장면 — 같은 사이트, 두 사람

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공 서비스의 메인 페이지에 막 들어선 두 사람을 따라가 보겠습니다.

먼저 마우스를 쓰는 김 주무관. 화면 위쪽 로고를 흘끗 보고 "아, 여기구나" 확인하고, 가운데 메뉴에 마우스를 올리니 하위 메뉴가 주르륵 펼쳐집니다. 원하는 항목을 클릭하고, 우측의 검색 돋보기를 눌러 키워드를 입력합니다. 10초도 안 걸렸습니다. 김 주무관에게 이 헤더는 아무 문제가 없습니다. 그래서 이 사이트를 만든 팀도 "헤더 잘 만들었다"고 믿습니다. 자기들이 테스트할 때 늘 마우스를 썼으니까요.

이번엔 시각장애가 있는 박 선생님. 스크린리더를 켜고 페이지를 엽니다. 가장 먼저 "본문 바로가기" 링크를 찾으려 Tab을 누르는데, 그런 링크가 없습니다(스킵 내비게이션 누락). 어쩔 수 없이 메뉴를 처음부터 훑어 내려갑니다. 그런데 메뉴 항목에서 Enter를 눌러도 하위 메뉴가 펼쳐지지 않습니다. 이 메뉴는 마우스 호버에만 반응하게 만들어졌거든요(키보드 미지원). 우측의 검색 버튼에 닿으니 스크린리더가 "버튼"이라고만 말합니다. 무슨 버튼인지 알 수 없습니다(아이콘만 있고 이름 없음). 로고를 지날 때는 "이미지"라고만 읽힙니다(대체 텍스트 없음). 박 선생님은 여기서 사이트 탐색을 포기하고, 결국 가족에게 대신 찾아 달라고 부탁합니다.

같은 사이트, 같은 헤더. 한 사람에겐 10초짜리 사소한 통과 구간이고, 다른 한 사람에겐 본문에 닿기도 전에 막히는 벽입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스 사용자만 떠올렸기 때문에 생긴 차이입니다. KRDS의 헤더 요건은, 이 두 사람의 경험을 같게 만들기 위한 최소한의 약속입니다. 그리고 그 약속을 지켰는지는 사람이 매번 스크린리더로 확인하기 어렵기 때문에, 자동 점검이 필요한 겁니다.

만약 이 팀이 KRDS 킷의 헤더 코드를 가져다 썼다면 어땠을까요. 박 선생님의 스크린리더는 가장 먼저 "본문 바로가기" 링크를 안내했을 거고, 메뉴를 건너뛰고 본문으로 점프했을 겁니다. 메뉴를 탐색할 때는 방향키로 하위 메뉴를 펼치고, 검색 버튼은 "검색"으로, 로고는 "○○ 기관 홈페이지"로 또렷이 읽혔겠죠. 김 주무관과 똑같이 10초면 됐을 겁니다. 차이를 만드는 건 거창한 기술이 아니라, "검증된 컴포넌트를 쓰느냐"라는 작은 선택입니다.

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

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

실수 1) 스킵 내비게이션 누락

가장 흔하고, 가장 쉽게 빠뜨리는 실수입니다. "본문 바로가기" 링크가 아예 없거나, 있어도 코드상 엉뚱한 곳을 가리켜 작동하지 않습니다.

• 나쁜 예: 스킵 링크 자체가 없음. 키보드 사용자는 매 페이지마다 헤더 메뉴 수십 개를 처음부터 다시 통과해야 함. 본문에 닿기까지 Tab을 수십 번 눌러야 함.
• 올바른 예: 페이지 최상단에 "본문 바로가기" 스킵 링크를 두고, 본문 영역의 id로 정확히 연결. 평소엔 숨어 있되 포커스를 받으면 화면에 또렷이 나타남. KRDS 킷의 헤더 구조를 그대로 쓰면 기본 포함됨.

실수 2) 시맨틱 태그 없는 헤더

<div class="header">, <div class="gnb">로만 만들고, <header>·<nav> 같은 시맨틱 태그나 랜드마크 역할을 빼먹습니다.

• 나쁜 예: 모양은 헤더인데 코드상으로는 의미 없는 박스. 화면 읽기 프로그램이 "배너 영역", "내비게이션"으로 인식하지 못해, 랜드마크 단위 이동이 불가능.
• 올바른 예: 최상단을 <header>(또는 role="banner")로, 주요 메뉴를 <nav>(또는 role="navigation")로 감싸고, 메뉴가 여러 개면 aria-label로 구분. 코드가 곧 구조가 되게.

실수 3) 키보드로 안 열리는 메뉴

디자인을 위해 메뉴를 직접 만들고 마우스 호버에만 반응하게 구현합니다.

• 나쁜 예: 하위 메뉴가 마우스를 올려야만 펼쳐짐. 키보드로 Tab·Enter·방향키를 눌러도 아무 반응 없음. 키보드 사용자에겐 "보이지만 닿을 수 없는" 메뉴.
• 올바른 예: 키보드로 펼치기·이동·닫기(Esc)가 모두 가능하고, 펼침 상태를 aria-expanded로 표현. 가능하면 KRDS 킷의 검증된 헤더 코드 사용.

실수 4) 이름 없는 아이콘 버튼

검색·전체메뉴·언어 전환 버튼을 아이콘만으로 만들고, 텍스트 라벨이나 aria-label을 빼먹습니다.

• 나쁜 예: 돋보기 아이콘만 있는 검색 버튼이 스크린리더에 "버튼"으로만 읽힘. 햄버거 아이콘도 "버튼"으로만. 무슨 기능인지 음성 사용자는 알 수 없음.
• 올바른 예: 보이는 텍스트가 없으면 aria-label="검색", aria-label="전체메뉴 열기"를 부여. 토글 버튼은 펼침 상태(aria-expanded)도 함께 알림.

실수 5) 로고 대체 텍스트 누락 / 홈 링크 부재

로고 이미지에 alt가 없거나, 로고가 링크가 아니어서 눌러도 홈으로 안 갑니다.

• 나쁜 예: 로고 이미지의 alt가 비어 있거나 "logo.png"가 그대로 읽힘. 또는 로고가 그냥 이미지라 클릭해도 아무 일 없음.
• 올바른 예: 로고를 링크로 감싸 홈으로 연결하고, alt="○○ 기관 홈페이지"처럼 기관명을 담은 대체 텍스트 부여. "여기가 어디고, 누르면 홈으로 간다"가 코드로 전달되게.

실수 6) 본문 가리는 고정 헤더

스크롤해도 따라오는 고정 헤더를 만들었는데, 높이가 너무 크거나 본문 점프 시 내용을 가립니다.

• 나쁜 예: 본문 안 링크로 점프하면 고정 헤더가 그 지점을 덮어 버려, 정작 봐야 할 내용이 헤더 뒤에 숨음. 작은 화면에선 헤더가 화면의 절반을 차지.
• 올바른 예: 고정 헤더 높이를 적정하게 관리하고, 점프 시 가려지지 않도록 여백(scroll-padding 등) 확보. 모바일에서는 헤더를 더 콤팩트하게.

실수 7) 페이지마다 다른 헤더

메인과 하위 페이지의 헤더 구성·위치·메뉴가 들쭉날쭉합니다.

• 나쁜 예: 메인은 로고 왼쪽·검색 있음, 하위 페이지는 로고 가운데·검색 없음. 사용자가 페이지마다 헤더를 다시 학습해야 함.
• 올바른 예: 모든 페이지에서 동일한 헤더 구조·위치·동작 유지. 표준 컴포넌트를 한 번 만들어 전 페이지에서 재사용.

실수 8) 너무 많은 것을 욱여넣은 헤더

메뉴, 배너, 공지, 팝업, 각종 버튼을 헤더에 다 몰아넣어 정신이 없습니다.

• 나쁜 예: 헤더에 1차 메뉴·2차 메뉴·각종 배너·공지 띠·언어·글자크기·SNS까지 전부. 정작 핵심 기능이 잡동사니에 묻힘. 모바일에선 헤더만으로 화면이 꽉 참.
• 올바른 예: 헤더에는 식별·핵심 탐색·핵심 기능만. 나머지는 적절한 위치(푸터, 별도 영역)로 분산. "헤더는 안내데스크지 창고가 아니다"라는 원칙.

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

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

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소(KRDS-uiux/krds-uiux)의 html/code 폴더에 헤더와 주요 메뉴 코드가 들어 있어, 시맨틱 구조·키보드 동작·ARIA 속성·스킵 내비게이션이 이미 구현된 상태로 시작할 수 있습니다. "접근성은 어렵다"는 말의 절반은 "직접 만들어서 어렵다"는 뜻인데, 검증된 헤더 코드를 가져다 쓰면 그 절반이 사라집니다. 특히 헤더는 모든 페이지에 공통으로 들어가는 만큼, 한 번 제대로 만들어 두면 사이트 전체에 효과가 퍼집니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 헤더와 메뉴 컴포넌트를 가져다 쓸 수 있습니다. 직접 그리지 말고 표준 컴포넌트를 배치하면, 디자인 단계에서부터 로고·메뉴·기능 버튼의 배치와 간격이 기준에 맞춰집니다. 시안 단계에서 스킵 내비게이션의 자리, 기능 버튼의 라벨, 모바일 햄버거 메뉴의 동작까지 미리 정의해 두면, 구현 단계의 누락이 크게 줄어듭니다.

기획자라면 — 화면 정의서에 "상단 영역"이라고만 적지 말고, 헤더의 네 책무(식별·탐색·기능·접근)를 각각 명시하세요. "로고(홈 링크, 대체 텍스트 포함) / 주요 메뉴(키보드 조작) / 검색·로그인·전체메뉴(각 이름표) / 스킵 내비게이션 / 모바일 햄버거 메뉴"처럼요. 그리고 "헤더는 모든 페이지에서 동일하게"라는 한 줄을 못 박아 두면, 페이지마다 헤더가 달라지는 사고를 막습니다.

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

여기까지가 KRDS의 헤더 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트 헤더는 이걸 지키고 있나?"를 확인하는 일입니다. 헤더가 시맨틱 태그로 감싸여 있는지, 스킵 내비게이션이 있는지, 메뉴가 키보드로 열리는지, 로고에 대체 텍스트가 있는지, 검색 버튼에 이름이 있는지를 사람이 일일이 손으로 점검하려면 끝이 없습니다. 게다가 헤더는 모든 페이지에 있으니, 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

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

ViewCheck가 헤더에 대해 자동으로 보는 것들:

• 시맨틱 구조: 최상단이 <header>(배너 랜드마크)로 선언돼 있는지, 주요 메뉴가 <nav>(내비게이션 랜드마크)로 감싸여 있는지
• 스킵 내비게이션: "본문 바로가기" 같은 스킵 링크가 존재하고, 본문 영역으로 올바르게 연결되는지
• 로고: 헤더 로고가 링크(홈 이동)이고, 기관명을 담은 대체 텍스트가 있는지
• 기능 버튼의 이름: 검색·전체메뉴 같은 아이콘 버튼에 접근 가능한 이름과 토글 상태(aria-expanded)가 있는지
• 메뉴 키보드 대응: 주요 메뉴가 키보드로 조작 가능한 구조인지
• 반응형 헤더: 모바일 뷰포트에서 햄버거 메뉴·터치 영역이 기준을 충족하는지(반응형 품질 분석과 연계)

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

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 헤더 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "스킵 내비게이션 누락", "검색 버튼에 접근 가능한 이름 없음"처럼 구체적으로요. 헤더는 모든 페이지에 공통으로 들어가는 만큼, 여러 페이지를 한꺼번에 분석하면 "헤더 결함이 전 페이지에 동일하게 복제돼 있다"는 사실이 한눈에 드러납니다. 반대로 "메인 헤더에는 스킵 링크가 있는데 하위 페이지 헤더에는 없다" 같은 페이지별 편차도 잡아냅니다. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "잘하자"가 아니라, "헤더의 이 부분을 이렇게 고치자"는 구체적인 작업 목록이 됩니다. 헤더는 한 번 고치면 전 페이지에 효과가 퍼지니, 가장 먼저 점검하고 가장 먼저 고치기에 딱 좋은 컴포넌트입니다.

자주 묻는 질문

현장에서 헤더를 다룰 때 반복해서 나오는 질문들을 모았습니다.

Q. 스킵 내비게이션이 정말 그렇게 중요한가요? 마우스 쓰는 사람은 평생 안 보는데요.

바로 그게 핵심입니다. 마우스 사용자에게는 평소 보이지 않지만, 키보드·스크린리더 사용자에게는 "본문에 닿는 첫 관문"입니다. 이게 없으면 그 사용자는 매 페이지마다 헤더 메뉴 전체를 처음부터 다시 통과해야 합니다. 메뉴가 30개면 본문을 읽기까지 Tab을 30번 넘게 눌러야 하죠. 페이지를 옮길 때마다요. 스킵 링크 한 줄이 이 반복 고역을 없앱니다. 한국형 웹 접근성 지침(KWCAG)에서도 강하게 요구하는 항목이라, "있으면 좋은 것"이 아니라 "있어야 하는 것"으로 봐야 합니다.

Q. 로고를 누르면 홈으로 가는 게 그렇게 당연한가요? 우리는 별도 홈 버튼을 뒀는데요.

별도 홈 버튼을 두는 것 자체는 문제없습니다. 다만 사용자 대다수가 "헤더 로고 = 홈 버튼"이라는 강한 기대를 갖고 있다는 게 중요합니다. 이 기대는 수많은 사이트가 만들어 온 사실상의 관습이라, 로고가 홈으로 안 가면 사용자는 길 찾기의 가장 직관적인 수단 하나를 잃습니다. 별도 홈 버튼이 있더라도 로고에 홈 링크를 겸하게 두는 게 안전합니다. "이미 홈 버튼 있으니까"라고 로고를 그냥 이미지로 두지 마세요.

Q. 고정 헤더(스크롤해도 따라오는)는 써도 되나요?

써도 됩니다. 다만 두 가지를 챙기세요. 첫째, 높이를 적절히 관리해 본문을 너무 많이 가리지 않게. 작은 화면에서 헤더가 화면의 절반을 먹으면 본문 읽기가 답답해집니다. 둘째, 본문 안 링크로 점프했을 때 고정 헤더가 그 지점을 덮지 않도록 여백을 확보하세요. 이 두 가지만 챙기면 고정 헤더는 편리한 선택입니다.

Q. 검색 버튼에 돋보기 아이콘만 있으면 다들 알아보지 않나요?

눈으로 보는 사람은 대부분 알아봅니다. 문제는 화면 읽기 프로그램입니다. 아이콘만 있고 텍스트 라벨이 없으면, 스크린리더는 그걸 그냥 "버튼"으로만 읽습니다. 무슨 버튼인지 음성 사용자는 알 수 없죠. 그래서 보이는 텍스트가 없는 아이콘 버튼에는 반드시 aria-label="검색" 같은 이름을 코드로 넣어야 합니다. 보기엔 아이콘 하나지만, 코드 안에는 이름표가 들어 있어야 한다는 뜻입니다.

Q. 모바일 햄버거 메뉴는 접근성에 문제가 없나요?

햄버거 메뉴 자체가 문제는 아닙니다. 다만 세 가지를 지켜야 합니다. ① 햄버거 버튼에 "메뉴 열기" 같은 이름이 있을 것, ② 펼침/접힘 상태가 코드(aria-expanded)로 표현될 것, ③ 펼쳐진 메뉴를 키보드로 다룰 수 있고 닫을 수 있을 것(Esc 등). 그리고 햄버거 버튼과 펼쳐진 항목들이 손가락으로 누를 수 있을 만큼 충분히 클 것(약 44px 이상). 이걸 다 챙기면 햄버거 메뉴는 좁은 화면에서 좋은 선택입니다.

Q. 헤더에 공지 띠나 배너를 넣고 싶은데, 괜찮을까요?

넣을 수는 있지만, 헤더의 핵심 기능(식별·탐색·핵심 기능)을 가리거나 밀어내지 않는 선에서만요. 헤더에 너무 많은 걸 욱여넣으면 정작 메뉴와 검색 같은 핵심이 잡동사니에 묻힙니다. 특히 모바일에서는 헤더 공간이 귀하니, 공지나 배너는 본문 상단이나 별도 영역으로 분산하는 게 보통 더 낫습니다. "헤더는 안내데스크지 창고가 아니다"라는 원칙을 기억하세요.

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

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "지금 헤더에 어떤 문제가 있는지"를 목록으로 만든 다음, 치명적인 것부터 차례로 고치면 됩니다. 헤더는 모든 페이지에 공통이라, 한 번 제대로 고치면 효과가 전 페이지에 퍼지는 게 큰 장점입니다. 스킵 내비게이션 추가나 시맨틱 태그 교정 같은 건 비교적 작은 작업으로 큰 효과를 냅니다. 리뉴얼 예산을 한 번에 들이지 않고도 점진적으로 점수를 끌어올릴 수 있습니다.

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

헤더 접근성은 어느 한 팀의 책임이 아니라 합작입니다. 디자이너는 로고·메뉴·기능 버튼의 배치와 라벨, 스킵 내비게이션의 자리를 시안에 명시하고, 개발자는 그걸 시맨틱 구조와 표준 코드로 구현하고, 기획자는 헤더의 네 책무와 전 페이지 일관성을 정의해야 합니다. 그래서 KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 겁니다. 세 팀이 같은 기준을 보고 일하면 "네 일/내 일" 논쟁이 줄어듭니다.

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

ViewCheck로 돌려 보면 보통 헤더 관련 문제가 한두 개로 끝나지 않습니다. 게다가 헤더는 모든 페이지에 있으니, 문제 하나가 페이지 수만큼 곱해져 "고칠 게 산더미"처럼 느껴집니다. 그래서 우선순위가 중요합니다. 헤더 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 키보드로 아예 열리지 않는 메뉴, 스킵 내비게이션 부재. 이건 특정 사용자에게 사이트 전체로 가는 길을 완전히 차단하는 문제라 1순위입니다. 본문에 닿기 전 단계에서 막히니, 본문을 아무리 잘 만들어도 소용이 없어집니다. 헤더는 모든 페이지에 있으므로, 이 문제를 고치면 효과가 가장 크게 퍼집니다.

그다음(높음) — 로고 대체 텍스트 누락, 검색·전체메뉴 등 기능 버튼의 이름 부재, 시맨틱 태그(랜드마크) 누락. 작동은 하지만 음성 사용자가 "여기가 어디고 이게 무슨 버튼인지" 알 수 없으니 실질적 장벽입니다. 시맨틱 구조가 없으면 랜드마크 단위 탐색도 불가능해집니다.

그 후(보통) — 본문 가리는 고정 헤더, 페이지별 헤더 불일치, 모바일 터치 영역 부족. 사용은 가능하지만 특정 상황·특정 사용자에게 불편을 주는 문제입니다.

여력이 되면(낮음) — 헤더에 몰린 잡동사니 정리, 메뉴 구조 다듬기 같은 사용성 개선. 접근성을 막는 건 아니지만 경험을 한 단계 끌어올리는 항목입니다.

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) → 검증된 코드로 고치는(킷) 한 바퀴가 완성됩니다.

오늘의 체크리스트 — 헤더, 이것만은

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

• ☐ 최상단을 <header>(또는 role="banner")로 감쌌다(시맨틱 구조).
• ☐ 주요 메뉴를 <nav>(또는 role="navigation")로 감쌌고, 메뉴가 여럿이면 이름으로 구분했다.
• ☐ 스킵 내비게이션("본문 바로가기")이 있고, 본문 영역으로 정확히 연결된다.
• ☐ 스킵 링크가 평소엔 숨어 있되 포커스 시 화면에 보인다.
• ☐ 로고가 링크(홈 이동)이고, 기관명을 담은 대체 텍스트가 있다.
• ☐ 주요 메뉴를 키보드만으로 펼치기·이동·닫기(Esc)할 수 있다(호버 전용이 아니다).
• ☐ 메뉴 펼침 상태가 코드(aria-expanded)로 표현된다.
• ☐ 검색·전체메뉴 등 아이콘 버튼에 접근 가능한 이름이 있다(aria-label 등).
• ☐ 전체메뉴·햄버거 같은 토글 버튼은 펼침/접힘 상태를 알린다.
• ☐ 고정 헤더를 쓴다면 본문을 가리지 않도록 높이·여백을 관리했다.
• ☐ 모든 페이지에서 헤더 구조·위치·동작이 동일하다.
• ☐ 모바일에서 햄버거 메뉴·항목의 터치 영역이 충분하다(약 44px 이상).

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

헤더는 작아 보이지만, 모든 페이지의 맨 위에서 사용자를 가장 먼저 맞이하는 얼굴입니다. 그 띠 하나가 누군가에겐 사이트의 문을 여는 열쇠이고, 또 누군가에겐 본문에 닿기도 전에 막히는 벽입니다. 우리가 무심코 넘긴 메뉴 하나, 이름 없는 검색 버튼 하나가, 누군가에게는 그 행정 서비스를 혼자 끝낼 수 있느냐 없느냐를 가릅니다.

오늘 정리한 기준이 거창해 보일 수 있지만, 핵심은 결국 단순합니다. 코드로도 헤더답게 만들고, 본문 바로가기를 두고, 키보드로 쓸 수 있게 하고, 로고와 버튼에 이름을 붙이고, 검증된 코드를 쓰는 것. 이것만 챙겨도 헤더의 위반 대부분은 사라집니다. 그리고 헤더는 모든 페이지에 곱해지니, 한 번의 수정이 사이트 전체를 끌어올립니다. 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 많이 막히는 헤더의 한 부분부터 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 많은 사람에게 열립니다. 다음 글에서는 헤더와 짝을 이루는 또 다른 구조 컴포넌트를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 헤더는 지금 몇 점일까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 바로 보입니다. 헤더는 모든 페이지에 있으니, 가장 먼저 점검하기에 가장 좋은 곳입니다.

#KRDS #헤더Header #공공웹 #디자인시스템 #웹접근성 #GNB #스킵내비게이션 #정부웹사이트 #ViewCheck #UIUX #랜드마크 #네비게이션 #헤더 #Header #KRDS기준 #디자인원칙 #표준가이드 #UI컴포넌트 #컴포넌트설계 #전자정부