공식 배너(Masthead) 완전 해부 — KRDS 공식 기준

공공 사이트에 처음 들어갔을 때, 우리가 가장 먼저(그러나 가장 무의식적으로) 확인하는 게 하나 있습니다. "여기가 진짜 정부 사이트가 맞나?" 하는 의심을 0.5초 만에 가라앉히는 무언가요. 화면 맨 위, 콘텐츠가 시작되기도 전에 가느다란 띠 하나가 "이 누리집은 대한민국 공식 전자정부 누리집입니다" 같은 문장과 함께 떠 있는 걸 본 적 있으실 겁니다. 대개는 그냥 스쳐 지나갑니다. 그런데 그 한 줄이 없는 사이트에서 주민등록 정보를 입력하거나 본인인증을 하려고 하면, 어딘가 마음 한구석이 찜찜해집니다. "이거 혹시 가짜 사이트 아니야?" 하는 의심이 스멀스멀 올라오죠.

그 가느다란 띠가 바로 오늘 이야기할 공식 배너(Masthead)입니다. 영어로는 Masthead. KRDS(대한민국 정부 디자인 시스템)가 정의하는 컴포넌트 중에서, 가장 작고 가장 위에 있고, 그래서 가장 많이 무시당하는 요소이기도 합니다. 디자이너 입장에선 "그냥 정부 안내 문구 한 줄"이고, 개발자 입장에선 "위에 div 하나 더 붙이는 일"이고, 기획자 입장에선 "어차피 다 들어가는 거니까 신경 안 써도 되는 것"입니다. 그렇게 다들 가볍게 여기다 보니, 공공 사이트를 수백 개 들여다보면 이 공식 배너에서 똑같은 실수가 끝없이 반복됩니다. 아예 없거나, 모양만 흉내 냈거나, 화면엔 떠 있는데 스크린리더로는 읽히지도 않거나.

현업에서 보면, 공식 배너는 "프로젝트 막판에 끼워 넣는 것" 취급을 받는 경우가 많습니다. 디자인 시안 어디에도 잘 안 그려져 있고, 퍼블리싱 단계에서 "아, 그거 위에 띠 하나 붙이면 되죠" 하고 급하게 추가되죠. 그 과정에서 "이게 무슨 의미를 가지는 영역인지", "스크린리더가 이걸 뭐라고 읽어야 하는지", "여러 페이지에 다 일관되게 들어가는지"를 따지는 사람은 거의 없습니다. 그 결과가 우리가 매일 마주치는, 있는 듯 없는 듯한 공식 배너들입니다.

솔직히 말하면, 공식 배너는 "잘 만들어도 티가 안 나는" 컴포넌트입니다. 제대로 만들어도 대부분의 사용자는 알아채지도 못하고 지나갑니다. 칭찬받기는 어렵고, 빠지면 욕먹기 딱 좋은 자리죠. 하지만 티가 안 난다는 건 잘 작동할 때 얘기입니다. 이게 빠지거나 잘못되면, 신뢰가 가장 필요한 순간에 사용자는 "여기 정말 믿어도 되나?" 하고 멈칫합니다. 그 멈칫거림이 본인인증 화면에서 일어나면, 그건 단순한 불편이 아니라 서비스에 대한 불신으로 번집니다.

이 글에서는 KRDS가 공식 배너를 어떻게 정의하고 무엇을 요구하는지를, 공식 가이드라인과 컴포넌트 킷을 기준으로 하나하나 뜯어보겠습니다. "이렇게 하면 멋있다"가 아니라 "정부 표준은 이걸 요구한다"는 사실 기준으로요. 그리고 그 기준을 우리 사이트가 실제로 지키고 있는지 어떻게 확인하는지까지 이어가겠습니다. 다 읽고 나면, 앞으로 어떤 공공 사이트를 보든 화면 맨 윗줄을 먼저 보게 되실 겁니다. "이건 제대로 된 공식 배너, 저건 흉내만 낸 배너"가 눈에 들어오기 시작하거든요.

공식 배너가 대체 뭐길래 — 정의부터 정확히

먼저 용어부터 맞추겠습니다. 우리가 "정부 사이트 맨 위 띠"라고 뭉뚱그려 부르는 것들은 사실 하나가 아닙니다. KRDS는 화면 최상단 영역을 목적에 따라 구분합니다.

공식 배너(Masthead): 화면 가장 위, 헤더보다도 위에 위치하는 가느다란 띠. "이 사이트가 공식 정부 기관의 것임"을 알리는 신뢰 표식. 대개 접혀 있다가 "확인하는 방법" 같은 안내를 펼쳐 볼 수 있는 형태로 제공됩니다.
헤더(Header): 기관 로고, 주메뉴(GNB), 검색, 로그인 등이 들어가는 본격적인 상단 영역. 공식 배너 바로 아래에 옵니다.
운영기관 식별자(Identifier): 사이트를 운영하는 기관이 누구인지를 밝히는 영역. 주로 푸터(맨 아래)에 들어가며, 공식 배너와는 위치도 역할도 다릅니다.

이 구분이 왜 중요하냐면, 셋을 헷갈려 섞어 버리면 각자의 역할이 흐려지기 때문입니다. 공식 배너는 "여긴 진짜 정부 사이트야"를 말하고, 헤더는 "여기서 무엇을 할 수 있어"를 보여 주고, 식별자는 "여기 운영 책임은 누구야"를 밝힙니다. KRDS가 이걸 굳이 나눠서 정의해 둔 이유가 바로 이겁니다 — 비슷한 자리에 있어도 의미가 다르면 다른 컴포넌트로 다뤄야 한다는 것.

공식 배너의 핵심 역할은 한마디로 신뢰 표식(trust mark)입니다. 은행 사이트에 자물쇠 아이콘이 있으면 "안전한 연결이구나" 하고 안심하듯, 정부 사이트 맨 위에 공식 배너가 있으면 "여긴 진짜 공공기관이 운영하는 곳이구나" 하고 안심합니다. 그리고 이 안심은 디지털 시대에 점점 더 중요해지고 있습니다. 정부 사이트를 사칭한 피싱 사이트가 워낙 많아졌거든요. 진짜 사이트와 가짜 사이트를 구분하는 시각적 약속, 그게 공식 배너의 존재 이유입니다.

공식 배너는 보통 어떻게 구성되나

KRDS 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux)을 열어 보면 공식 배너가 일정한 구조로 제공됩니다. 일반적으로 다음 요소들이 들어갑니다.

공식 안내 문구: "이 누리집은 대한민국 공식 전자정부 누리집입니다" 같은, 사이트의 공식성을 밝히는 문장.
국가 상징 또는 식별 마크: 문구 옆에 붙는 작은 시각 표식(태극 문양 등). 한눈에 "정부"임을 알리는 보조 신호.
펼침/접힘 토글: "확인하는 방법" 또는 "자세히 보기" 같은 버튼. 누르면 "공식 정부 사이트를 구별하는 방법"에 대한 추가 안내가 펼쳐집니다.
추가 안내 콘텐츠: 펼쳤을 때 나오는, 도메인 확인법·보안 접속 확인법 같은 설명.

이 구조 자체가 메시지입니다. 공식 배너는 그냥 "한 줄 띄워 놓고 끝"이 아니라, "왜 이게 공식 사이트인지 확인하는 방법까지 안내하는" 인터랙티브한 컴포넌트라는 것. 특히 펼침/접힘 토글이 들어 있다는 건, 공식 배너가 단순 장식 텍스트가 아니라 키보드·스크린리더 접근성까지 챙겨야 하는 "동작하는 컴포넌트"라는 뜻입니다. 뒤에서 자세히 보겠지만, 공공 웹에서 가장 많이 빠뜨리는 게 바로 이 "토글의 접근성"입니다.

KRDS는 공식 배너에 무엇을 요구하나 — 기준 완전 해부

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

1) 위치 — 화면 가장 위, 헤더보다도 위

공식 배너의 첫 번째 요건은 위치입니다. 이건 헤더의 일부가 아니라, 헤더보다 위, 페이지 최상단에 와야 합니다. 사용자가 화면을 보자마자 가장 먼저 마주치는 영역이 공식 배너여야 한다는 뜻이죠. 신뢰 표식이라는 역할상 당연한 위치입니다. 만약 공식 배너를 화면 중간이나 푸터에 박아 두면, 정작 신뢰가 필요한 첫 순간에는 보이지 않게 됩니다.

코드 구조로 보면, 보통 <body> 바로 안쪽 최상단에 공식 배너 영역이 오고, 그다음에 헤더가 옵니다. 이 순서는 시각적 순서일 뿐 아니라 DOM 순서이기도 해야 합니다. 스크린리더는 DOM 순서대로 읽기 때문에, 화면엔 위에 있는데 코드상으로는 한참 아래에 있으면 음성 사용자에겐 순서가 뒤죽박죽으로 전달됩니다. "보이는 순서 = 읽히는 순서"가 여기서도 핵심입니다.

2) 공식성을 밝히는 명확한 문구

두 번째 요건은 공식 배너가 전달하는 메시지의 명확성입니다. "이 누리집은 대한민국 공식 전자정부 누리집입니다" 같은 문구는, 사용자가 한 번 읽고 바로 "아, 공식 사이트구나" 하고 이해할 수 있어야 합니다. 모호하거나 장식적인 문구로는 신뢰 표식의 역할을 못 합니다.

여기서 중요한 건, 이 문구가 단순한 이미지가 아니라 실제 텍스트여야 한다는 점입니다. 공식 배너를 통째로 이미지(PNG)로 만들어 박아 두면, 화면엔 글씨가 보이지만 스크린리더는 아무것도 못 읽습니다. 이미지 안의 글자는 컴퓨터에겐 그냥 그림이거든요. 신뢰 표식이 정작 시각장애인 사용자에겐 "빈 그림"으로 다가가는 아이러니가 생깁니다. 그래서 공식 배너의 문구는 반드시 선택·복사 가능한 진짜 텍스트로 구현되어야 합니다.

3) 펼침/접힘 토글의 키보드 조작

공식 배너에 "확인하는 방법" 같은 펼침 버튼이 있다면, 이건 타협 없는 요건입니다. 그 토글은 키보드만으로 다음이 전부 가능해야 합니다.

Tab으로 토글 버튼에 초점(focus) 이동
Enter / Space로 펼치기·접기
펼쳐진 안내 콘텐츠로 초점이 자연스럽게 이어지기
다시 토글을 눌러 접기

그리고 이 토글은 단순히 클릭만 되는 게 아니라, 상태가 코드로 표현되어야 합니다. 표준적으로는 aria-expanded="false"(접힘) / aria-expanded="true"(펼침)로 현재 상태를 알립니다. 그래야 스크린리더가 "확인하는 방법, 버튼, 접힘"처럼 현재 상태까지 읽어 줍니다. 펼쳤는데 펼쳐졌다는 사실이 음성으로 전달되지 않으면, 시각장애인 사용자는 "내가 누른 게 작동한 건가?"를 알 수 없습니다.

현실에서 이게 어떻게 깨지냐면, 대부분 <div>에 클릭 이벤트만 붙여서 토글을 만들기 때문입니다. 마우스로는 잘 펼쳐지는데, 키보드 Tab으로는 아예 닿지도 않고, 스크린리더는 그게 버튼인 줄도 모릅니다. KRDS 컴포넌트 킷이 공식 배너 코드를 제공하는 이유가 정확히 이겁니다 — 토글의 키보드 동작과 ARIA 상태가 이미 구현된 검증된 코드를 가져다 쓰라는 것.

4) 초점 표시(Focus) — 토글에 초점이 왔을 때 보여야 한다

키보드로 공식 배너의 토글에 이동했을 때, 지금 초점이 거기 와 있다는 걸 시각적으로 알 수 있어야 합니다. 테두리가 강조되거나 외곽선(focus ring)이 또렷하게 나타나야 하죠. 공식 배너가 화면 맨 위라 가장 먼저 Tab이 닿는 영역인 만큼, 여기서 초점 표시가 없으면 키보드 사용자는 시작부터 "내가 지금 어디 있지?"를 잃어버립니다.

이 표시를 디자인이 지저분해 보인다는 이유로 CSS에서 outline: none으로 지워 버리는 경우가 정말 많습니다. 특히 공식 배너처럼 "가늘고 깔끔하게" 만들고 싶은 영역에서 더 그렇죠. 그러면 키보드 사용자는 자기가 화면 어디에 있는지 알 수 없게 됩니다. 포커스 표시는 지우는 게 아니라, 디자인과 어울리게 다듬는 것이 정답입니다.

5) 의미 구조(랜드마크와 제목)

공식 배너는 페이지 안에서 하나의 독립된 "영역"입니다. 그래서 그냥 <div>로 던져 놓는 것보다, 의미를 가진 구조로 표시해 주는 게 좋습니다. 적절한 영역 역할(role 또는 시맨틱 태그)을 부여하면, 스크린리더 사용자가 "여기서부터 공식 배너 영역"임을 인지하고 필요하면 건너뛸 수도 있습니다.

특히 펼쳤을 때 나오는 안내 콘텐츠에 소제목이 있다면, 그걸 적절한 제목 단계(<h2> 등)로 표시해 두면 스크린리더 사용자가 제목만 훑어 구조를 파악할 수 있습니다. "보이는 굵은 글씨"가 아니라 "코드 수준의 제목"이어야 한다는 게 핵심입니다.

6) 색에만 의존하지 않기 + 충분한 대비

공식 배너는 보통 진한 배경에 밝은 글씨, 또는 그 반대로 만들어집니다. 어느 쪽이든 글씨와 배경의 명도 대비가 충분해야 합니다. 신뢰 표식인데 정작 글씨가 흐릿해서 잘 안 보이면 의미가 없죠. 한국형 웹 접근성 지침(KWCAG)과 국제 표준은 텍스트의 최소 명도 대비 기준을 권장합니다 — 일반적으로 본문 텍스트는 4.5:1 이상을 기준으로 삼습니다.

또 공식 배너 안에 상태나 의미를 색으로만 표현하지 않아야 합니다. 예를 들어 "안전한 접속" 표시를 초록색만으로 알린다면, 색 구분이 어려운 사용자는 그 의미를 놓칩니다. 색은 보조 신호일 뿐, 텍스트나 모양이 의미를 받쳐 줘야 합니다.

7) 모바일·반응형 대응

공식 배너는 모든 화면 크기에서 제 역할을 해야 합니다. 데스크톱에선 한 줄로 깔끔하게 들어가던 문구가, 모바일에선 두세 줄로 접히거나 잘려서 의미가 깨지는 경우가 있습니다. 좁은 화면에서도 공식성을 밝히는 핵심 문구는 온전히 전달되어야 하고, 펼침 토글 같은 버튼은 손가락으로 누를 수 있을 만큼 충분한 터치 영역(일반적으로 한 변 44px 이상)을 가져야 합니다.

모바일에서 공간이 부족하다고 공식 배너를 아예 빼 버리는 경우도 있는데, 이건 좋지 않습니다. 모바일 사용자야말로 피싱 사이트에 더 취약하기 때문에(작은 화면에선 주소창 확인이 어렵죠), 신뢰 표식이 더 필요합니다.

8) 사이트 전체 일관성

공식 배너는 한 페이지에만 있어선 안 됩니다. 사용자는 메인에서만 사이트에 들어오는 게 아니라, 검색 결과나 외부 링크를 통해 내부 페이지로 바로 들어오기도 합니다. 그 사람에게 신뢰 표식을 보여 주려면, 공식 배너가 모든 페이지에 일관되게 들어가 있어야 합니다. 메인엔 있는데 신청 페이지엔 없는 식이면, 정작 민감한 정보를 입력하는 화면에서 신뢰 표식이 사라지는 셈입니다.

정리하면, KRDS의 공식 배너 기준은 크게 세 축입니다. ① 신뢰성(명확한 공식 문구, 일관된 위치, 모든 페이지 적용), ② 접근성(토글 키보드 지원, 초점 표시, 텍스트 기반 구현), ③ 전달성(시각 정보가 코드로도 전달돼 스크린리더가 읽을 수 있을 것). 이 세 축은 그대로 ViewCheck가 공식 배너를 판정하는 기준이기도 합니다.

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

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

신뢰는 0.5초 안에 결정된다

사용자가 사이트에 들어와 "여기 믿어도 되나?"를 판단하는 데 걸리는 시간은 생각보다 짧습니다. 거의 무의식적으로, 화면이 뜨자마자 결정됩니다. 이 첫인상에서 "공식 정부 사이트"라는 신호를 주는 가장 빠른 방법이 화면 맨 위의 공식 배너입니다. 이게 없으면 사용자는 그 신호를 다른 데서 찾아야 하는데(도메인 주소를 확인한다든가), 대부분은 그렇게까지 하지 않습니다. 그냥 막연한 불안을 안은 채 작업을 진행하거나, 불안해서 이탈합니다.

특히 공공 서비스는 "안 쓸 자유"가 없는 영역이 많습니다. 세금을 내거나, 민원을 신청하거나, 본인인증을 하는 일은 그 사이트가 아니면 할 수 없죠. 그래서 신뢰 표식이 빠지면, 사용자는 불안하지만 어쩔 수 없이 진행하게 됩니다. 그 불안을 덜어 주는 게 공식 배너의 존재 이유입니다.

피싱과 사칭으로부터의 방어선

공식 배너가 단순 장식이 아니라 "확인하는 방법"까지 안내하는 인터랙티브 컴포넌트인 이유가 여기 있습니다. 정부 사이트를 사칭한 피싱 사이트는 디자인을 거의 똑같이 베낍니다. 로고도, 색깔도, 레이아웃도 흉내 내죠. 하지만 공식 배너의 "공식 사이트 확인 방법"(올바른 도메인 확인, 보안 접속 확인 등)을 안내하면, 사용자가 스스로 진짜와 가짜를 구분할 단서를 갖게 됩니다. 공식 배너는 단순히 "우리는 진짜야"라고 주장하는 데서 그치지 않고, "이렇게 확인해 보세요"라며 사용자에게 판별 능력을 쥐여 주는 겁니다.

그렇기 때문에 공식 배너를 모양만 흉내 내선 안 됩니다. 펼쳤더니 안내가 없거나, 토글이 작동하지 않거나, 문구가 모호하면, 신뢰 표식이 오히려 "허울뿐인 띠"가 되어 버립니다.

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

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

그래서 공식 배너는 "보기에 공식 배너 같은 것"으로는 부족하고, "코드 수준에서 읽히는 텍스트로 된 것"이어야 합니다. 통째로 이미지로 박아 두면, 음성 사용자에겐 신뢰 표식이 통째로 사라집니다. 토글에 aria-expanded가 없으면, 펼쳤다는 사실이 전달되지 않습니다. 이 "보이는 것 ≠ 읽히는 것" 문제가 공식 배너 위반의 근본 원인 대부분을 차지합니다. KRDS의 모든 컴포넌트 요건이 결국 "시각과 코드의 일치"라는 한 가지 원리로 수렴하는 셈입니다.

작은 컴포넌트일수록 방치되기 쉽다

역설적이지만, 공식 배너처럼 "작고 늘 똑같은" 컴포넌트일수록 품질 관리에서 밀려납니다. 메인 비주얼이나 핵심 기능에는 모두가 눈을 부릅뜨지만, 화면 맨 위 가느다란 띠에는 아무도 깐깐하게 굴지 않거든요. "어차피 모든 정부 사이트에 다 있는 거니까 대충 복사하면 되겠지" 하고 넘어갑니다. 그런데 그 "대충 복사"가 접근성 빠진 코드를 그대로 베끼는 일이 되기도 합니다. 가장 표준화하기 쉬워 보이는 곳에서 오히려 검증 없이 베낀 코드가 퍼져 나가는 거죠. KRDS가 공식 배너 같은 기본 컴포넌트까지 검증된 코드로 제공하는 건, 바로 이 "방치되기 쉬운 곳"에서 품질이 무너지는 걸 막기 위해서입니다.

일관성이 곧 신뢰의 누적

KRDS가 공식 배너의 모습과 문구를 표준화하는 또 다른 이유는 일관성입니다. 모든 정부 사이트의 공식 배너가 같은 위치에서 같은 방식으로 같은 문구를 보여 주면, 사용자는 한 번 익힌 "공식 사이트의 신호"를 모든 정부 사이트에서 똑같이 인식합니다. 반대로 사이트마다 공식 배너가 제각각이면, "이게 진짜 공식 표식인지" 매번 다시 판단해야 합니다. 표준화된 신뢰 표식은 정부 서비스 전체에 대한 신뢰를 한 칸씩 쌓아 올리는 일입니다. 한 사이트의 잘 만든 공식 배너가 "정부 사이트는 믿을 만하다"는 인상을 만들고, 그 인상이 다음 사이트로 이어집니다.

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

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

실수 1) 공식 배너 자체가 없다

가장 기본적이지만 의외로 흔한 실수입니다. 신뢰 표식이 가장 필요한 신청·인증 페이지에 공식 배너가 아예 없습니다. 특히 외주로 따로 만든 하위 시스템(예: 별도 도메인의 신청 시스템)에서 자주 빠집니다.

나쁜 예: 메인 포털엔 공식 배너가 있는데, 링크를 타고 넘어간 신청 시스템엔 없음. 사용자는 "여기 진짜 정부 사이트 맞나?" 하고 불안한 채로 본인인증을 진행.
올바른 예: 메인이든 하위 시스템이든, 사용자가 들어올 수 있는 모든 진입점에 일관된 공식 배너 적용. 외주 발주 시 "공식 배너 KRDS 표준 적용"을 명시.

실수 2) 공식 배너를 통째로 이미지로 박아 둠

문구와 마크를 한 장의 이미지(PNG/JPG)로 만들어 화면 맨 위에 붙입니다. 보기엔 깔끔합니다. 그런데 그 안의 글자는 컴퓨터에겐 그림일 뿐입니다.

나쁜 예: 공식 안내 문구가 통째로 이미지. 스크린리더는 아무것도 못 읽거나, 잘해야 빈약한 대체 텍스트(alt) 하나만 읽음. 화면 확대 시 글자가 깨짐.
올바른 예: 문구는 실제 텍스트로, 마크(태극 문양 등)만 이미지/SVG로. 마크에는 의미가 중복되지 않게 적절히 처리(장식이면 aria-hidden, 의미가 있으면 대체 텍스트). 확대해도 글자가 또렷.

실수 3) 펼침 토글이 키보드로 작동하지 않음

"확인하는 방법" 버튼을 <div>에 클릭 이벤트만 붙여 만듭니다. 마우스로는 펼쳐지는데, 키보드로는 닿지도 않습니다.

나쁜 예: <div>로 만든 토글. Tab으로 초점이 가지 않고, Enter/Space에 반응하지 않으며, role도 aria-expanded도 없음. 키보드 사용자에겐 존재하지 않는 버튼.
올바른 예: <button> 요소로 만들고 aria-expanded로 펼침/접힘 상태를 표현. 펼쳐지는 콘텐츠는 aria-controls로 연결. KRDS 킷의 공식 배너 코드를 그대로 사용하면 이 부분이 이미 구현돼 있음.

실수 4) 펼친 상태가 코드로 전달되지 않음

토글이 키보드로 작동은 하는데, 펼쳐졌는지 접혔는지를 알리는 aria-expanded가 빠져 있습니다.

나쁜 예: 펼침 버튼을 눌러도 스크린리더는 "확인하는 방법, 버튼"이라고만 읽고, 그게 지금 펼쳐진 건지 접힌 건지 알려 주지 않음. 사용자는 "내가 누른 게 작동한 건가?"를 알 수 없음.
올바른 예: aria-expanded 값이 클릭에 따라 true/false로 바뀌어, 스크린리더가 "확인하는 방법, 버튼, 펼침"처럼 상태를 읽어 줌.

실수 5) 초점 표시 제거

화면 맨 위라 가장 먼저 Tab이 닿는 곳인데, 디자인 통일성을 위해 outline: none으로 포커스 링을 지웁니다.

나쁜 예: 키보드로 사이트에 들어와 첫 Tab을 눌렀는데, 초점이 어디 갔는지 안 보임. 시작부터 길을 잃음.
올바른 예: 토글에 초점이 오면 또렷한 테두리·외곽선 유지. 공식 배너가 키보드 탐색의 출발점인 만큼 더욱 신경 써야 함.

실수 6) 문구가 모호하거나 장식적

공식성을 밝혀야 하는데, 문구가 추상적이거나 멋만 부려서 무슨 사이트인지 명확히 안 와닿습니다.

나쁜 예: "함께 만드는 행복한 ○○" 같은 슬로건만 있고, 정작 "공식 정부 누리집"임을 밝히는 문구는 없음. 신뢰 표식의 역할 실패.
올바른 예: "이 누리집은 대한민국 공식 전자정부 누리집입니다"처럼, 한 번 읽고 바로 이해되는 명확한 공식 문구. 슬로건은 슬로건대로 다른 영역에.

실수 7) 모바일에서 깨지거나 사라짐

데스크톱 기준으로만 만들고 모바일을 확인하지 않아, 좁은 화면에서 문구가 잘리거나 토글이 너무 작아집니다.

나쁜 예: 모바일에서 공식 문구가 두 줄로 어색하게 잘리거나, 공간 부족을 이유로 공식 배너를 통째로 숨김. 정작 모바일 사용자가 신뢰 표식이 더 필요한데도.
올바른 예: 좁은 화면에서도 핵심 문구는 온전히 보이고, 토글 버튼은 손가락에 맞는 터치 영역(약 44px 이상) 확보. 반응형으로 자연스럽게 재배치.

실수 8) 의미 구조 없이 div만 나열

공식 배너 영역을 의미 없는 <div> 덩어리로만 만들어, 스크린리더가 "여기가 공식 배너 영역"임을 인지하지 못합니다.

나쁜 예: 영역 구분 없는 <div> 나열. 음성 사용자는 어디서부터 어디까지가 공식 배너인지 알 수 없고, 건너뛸 수도 없음.
올바른 예: 적절한 영역 역할과 제목 구조를 부여해, 스크린리더 사용자가 영역을 인지하고 필요 시 건너뛸 수 있게.

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

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공 서비스의 "본인인증" 화면, 화면 맨 위에 공식 배너가 하나 있다고 합시다.

먼저 마우스를 쓰는 김 주무관. 화면이 뜨자 맨 위 진한 띠에 "이 누리집은 대한민국 공식 전자정부 누리집입니다"라는 문구가 눈에 들어옵니다. 0.5초 만에 "아, 공식 사이트구나" 하고 안심하고, 곧장 인증 절차로 넘어갑니다. 궁금해서 "확인하는 방법"을 한 번 눌러 보니 도메인 확인법이 펼쳐집니다. 김 주무관에게 이 공식 배너는 아무 문제가 없습니다. 그래서 이 화면을 만든 팀도 "잘 작동한다"고 믿습니다. 자기들이 테스트할 때 늘 마우스를 썼으니까요.

이번엔 시각장애가 있는 박 선생님. 스크린리더를 켜고 사이트에 들어와 화면 맨 위부터 읽어 내려갑니다. 그런데 공식 배너 자리에서 스크린리더가 침묵합니다. 알고 보니 공식 안내 문구가 통째로 이미지로 박혀 있고, 대체 텍스트도 없었던 겁니다(이미지 구현). 박 선생님은 "여기가 진짜 정부 사이트인지" 확인할 신호를 받지 못한 채, 불안한 마음으로 본인인증 정보를 입력해야 할지 망설입니다. "확인하는 방법" 토글도 <div>로 만들어져 Tab으로 닿지 않아, 스스로 진짜 여부를 확인할 길도 없습니다(토글 미지원).

같은 화면, 같은 공식 배너. 한 사람에겐 0.5초 만에 안심을 주는 신뢰 표식이고, 다른 한 사람에겐 "있는지조차 모르는 빈자리"입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스 쓰는 비장애인만 떠올렸기 때문에 생긴 차이입니다. KRDS의 공식 배너 요건은, 이 두 사람이 똑같이 "여긴 믿을 만한 공식 사이트"라는 신호를 받게 하기 위한 최소한의 약속입니다. 그리고 그 약속을 지켰는지는 사람이 매번 스크린리더로 확인하기 어렵기 때문에, 자동 점검이 필요한 겁니다.

만약 이 팀이 KRDS 킷의 공식 배너 코드를 가져다 썼다면 어땠을까요. 박 선생님의 스크린리더는 "이 누리집은 대한민국 공식 전자정부 누리집입니다"라는 문구를 또박또박 읽었을 거고, "확인하는 방법, 버튼, 접힘"이라는 토글을 Enter로 펼쳐 도메인 확인법까지 들었을 겁니다. 김 주무관과 똑같이 안심하고 인증을 진행했겠죠. 차이를 만드는 건 거창한 기술이 아니라, "검증된 컴포넌트를 쓰느냐"라는 작은 선택입니다.

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

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

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소(KRDS-uiux/krds-uiux)의 html/code 폴더에 공식 배너 컴포넌트 코드가 들어 있어, 펼침 토글의 키보드 동작과 aria-expanded 같은 ARIA 상태가 이미 구현된 상태로 시작할 수 있습니다. "접근성은 어렵다"는 말의 절반은 "직접 만들어서 어렵다"는 뜻인데, 검증된 코드를 가져다 쓰면 그 절반이 사라집니다. 특히 공식 배너처럼 모든 페이지에 들어가는 공통 영역은, 한 번 제대로 만들어 공통 레이아웃으로 빼 두면 사이트 전체에 일관되게 적용됩니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 공식 배너 컴포넌트를 그대로 가져다 쓸 수 있습니다. 직접 그리지 말고 표준 컴포넌트를 배치하면, 디자인 단계에서부터 위치·문구·색 대비·펼침 구조가 기준에 맞춰집니다. 시안과 실제 구현 사이의 간극도 줄어들죠. 특히 모바일 시안에서도 공식 배너를 빼지 말고, 좁은 화면에서 어떻게 보일지 함께 설계하세요.

기획자라면 — 화면 정의서에 공식 배너를 "당연히 들어가는 것"으로 묻어 두지 말고, "공식 배너(KRDS 표준, 모든 페이지 적용, 펼침 안내 포함)"처럼 명시하세요. 특히 별도 시스템(신청·인증 시스템 등)을 외주로 발주할 때, "공식 배너 KRDS 표준 적용"을 요구사항에 못 박는 한 줄이 나중의 누락을 막습니다. 이 한 줄이 디자인·개발 단계의 "어, 그거 빠졌네"를 예방합니다.

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

여기까지가 KRDS의 공식 배너 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트 공식 배너는 이걸 지키고 있나?"를 확인하는 일입니다. 공식 배너가 모든 페이지에 일관되게 들어가 있는지, 문구가 이미지가 아니라 진짜 텍스트인지, 펼침 토글이 키보드로 작동하고 상태가 코드로 표현되는지를 사람이 일일이 손으로 점검하려면 끝이 없습니다. 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

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

ViewCheck가 공식 배너에 대해 자동으로 보는 것들:

존재 여부와 위치: 화면 최상단에 공식 배너 영역이 있는지, DOM 순서상으로도 헤더보다 위에 오는지
텍스트 기반 구현 여부: 공식 문구가 실제 텍스트인지, 통째로 이미지로 박혀 있는지
펼침 토글의 접근성: 토글이 버튼으로 구현됐는지, aria-expanded로 상태가 표현되는지, 키보드로 접근 가능한지
사이트 전체 일관성: 여러 페이지를 분석하면, 공식 배너가 메인엔 있는데 내부 페이지엔 없는 식의 누락이 페이지별로 드러남
색 대비·반응형: 문구의 명도 대비, 모바일 뷰포트에서의 표시 상태(반응형 품질 분석과 연계)

DOM만으로 판단하기 어려운 시각적 부분(예: 공식 배너가 실제로 화면 맨 위에 또렷이 보이는지, 펼침 안내가 시각적으로 잘 펼쳐지는지)은 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 "코드 구조는 애매한데 화면엔 분명히 공식 배너처럼 보이는" 비표준 구현도 놓치지 않습니다. 이 점이 단순 코드 검사 도구와 다른 부분입니다 — 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회해 만든 UI도 잡아냅니다.

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 공식 배너 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "신청 페이지에 공식 배너 없음" 또는 "공식 배너 펼침 토글에 aria-expanded 누락"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인엔 공식 배너가 있는데 신청·인증 페이지엔 없다" 같은 페이지별 편차가 한눈에 드러납니다. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "잘하자"가 아니라, "이 페이지에 공식 배너를 추가하자", "이 토글에 aria-expanded를 넣자"는 구체적인 작업 목록이 됩니다.

자주 묻는 질문

현장에서 공식 배너를 다룰 때 반복해서 나오는 질문들을 모았습니다.

Q. 공식 배너랑 헤더, 운영기관 식별자가 자꾸 헷갈립니다. 한 줄로 구분해 주세요.

위치와 역할로 외우면 쉽습니다. 공식 배너는 화면 맨 위, "여긴 진짜 정부 사이트야"를 알리는 신뢰 표식입니다. 헤더는 그 바로 아래, 로고·메뉴·검색·로그인이 들어가는 본격 상단 영역으로 "여기서 뭘 할 수 있어"를 보여 줍니다. 운영기관 식별자는 주로 푸터(맨 아래), "이 사이트 운영 책임은 누구야"를 밝힙니다. 셋 다 "기관을 드러내는" 공통점이 있지만, 공식 배너는 신뢰, 헤더는 탐색, 식별자는 책임 소재라는 점이 다릅니다.

Q. 공식 배너를 통째로 이미지로 만들면 정말 안 되나요? 그게 디자인 통일성에 좋은데요.

권장하지 않습니다. 이미지 안의 글자는 스크린리더가 못 읽고, 화면 확대 시 깨지며, 다국어 전환이나 문구 수정도 번거롭습니다. 신뢰 표식이 정작 시각장애인에겐 "빈 그림"으로 다가가는 건 본말전도죠. 디자인 통일성은 텍스트와 CSS로도 충분히 맞출 수 있습니다. 마크(문양)만 이미지/SVG로 두고, 문구는 진짜 텍스트로 구현하는 게 원칙입니다.

Q. 우리 사이트는 한 페이지(메인)에만 공식 배너가 있어도 괜찮나요?

괜찮지 않습니다. 사용자는 메인으로만 들어오지 않습니다. 검색 결과나 외부 링크를 통해 내부 페이지로 바로 들어오는 경우가 매우 많습니다. 그 사람에게 신뢰 표식을 보여 주려면 모든 페이지에 공식 배너가 있어야 합니다. 특히 본인인증·결제·신청처럼 민감한 정보를 다루는 페이지일수록 더 중요합니다. 공통 레이아웃(헤더 컴포넌트)에 한 번 넣어 두면 전 페이지에 자동 적용되니, 구현 부담도 크지 않습니다.

Q. 펼침 토글의 aria-expanded, 꼭 있어야 하나요?

네, 토글이 있다면 필수입니다. aria-expanded가 없으면 스크린리더 사용자는 그 버튼이 지금 펼쳐진 상태인지 접힌 상태인지 알 수 없습니다. "내가 누른 게 작동한 건가?"를 알 수 없는 거죠. 마우스 사용자는 화면 변화로 알지만, 음성 사용자에겐 코드가 알려 주는 상태가 전부입니다. 버튼은 <div>가 아니라 <button>으로 만들고, 펼침/접힘에 따라 aria-expanded 값을 바꿔 주는 게 기본입니다.

Q. 모바일에서 공간이 부족한데 공식 배너를 숨겨도 되나요?

가급적 숨기지 마세요. 오히려 모바일 사용자가 신뢰 표식이 더 필요합니다. 작은 화면에선 주소창 확인이 어려워 피싱에 더 취약하거든요. 공간이 부족하면 공식 배너를 압축해서 보여 주거나(핵심 문구만, 상세는 펼침으로), 폰트·여백을 조정해 한 줄로 들어가게 하는 방법을 먼저 검토하세요. 핵심 공식 문구는 어떤 화면 크기에서도 온전히 전달되어야 합니다.

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

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "공식 배너가 어느 페이지에 있고 없는지, 어떤 페이지의 토글이 접근성을 빠뜨렸는지"를 목록으로 만든 다음, 우선순위대로 치명적인 것부터 차례로 고치면 됩니다. 보통 가장 큰 효과는 "누락된 페이지에 공식 배너를 추가"하는 것과 "토글의 키보드 접근성을 보강"하는 것에서 나옵니다. 리뉴얼 예산을 한 번에 들이지 않고도, 공통 레이아웃 한 곳만 고쳐 전 페이지에 반영하는 식으로 점진적으로 개선할 수 있습니다.

Q. KRDS 킷의 공식 배너 코드를 쓰면 디자인을 우리 기관에 맞게 바꿔도 되나요?

색이나 세부 스타일은 기관 정체성에 맞게 조정할 수 있습니다. 다만 그 과정에서 접근성 요건은 건드리지 마세요. 색을 바꿀 땐 명도 대비를 다시 확인하고, 마크업 구조(버튼/aria 속성)는 그대로 유지하는 게 원칙입니다. "보이는 것"은 바꾸되 "읽히는 구조"는 보존한다고 생각하시면 됩니다. 스타일만 입히고 구조는 검증된 그대로 두는 게, 디자인 자유와 접근성을 동시에 챙기는 길입니다.

Q. 공식 배너 디자인이 너무 정부스럽고 답답한데, 좀 더 우리 기관답게 못 하나요?

공식 배너는 "개성을 드러내는 자리"가 아니라 "신뢰를 주는 자리"라는 점을 먼저 떠올리시면 좋겠습니다. 모든 정부 사이트가 비슷한 공식 배너를 쓰는 게 단점이 아니라, 바로 그 "같음"이 신뢰의 핵심입니다. 사용자는 익숙한 신호를 만났을 때 안심하거든요. 기관의 개성은 헤더의 로고, 메인 비주얼, 색상 시스템에서 충분히 드러낼 수 있습니다. 공식 배너만큼은 표준을 따르는 게, 결과적으로 우리 사이트의 신뢰도를 높이는 길입니다.

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

ViewCheck로 돌려 보면 공식 배너 관련 문제가 한두 개로 끝나지 않을 수 있습니다. 페이지가 많을수록 "고칠 게 많다"는 압박감이 듭니다. 그래서 우선순위가 중요합니다. 공식 배너 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 본인인증·결제·신청처럼 민감한 핵심 경로 페이지에 공식 배너가 아예 없는 경우, 그리고 펼침 토글이 키보드로 전혀 작동하지 않는 경우. 전자는 신뢰가 가장 필요한 순간에 표식이 없는 것이고, 후자는 특정 사용자에게 기능을 완전히 차단하는 문제라 1순위입니다.

그다음(높음) — 공식 배너가 일반 페이지엔 빠져 있거나, 문구가 통째로 이미지라 스크린리더로 안 읽히는 경우, 그리고 토글에 aria-expanded가 없어 상태가 전달되지 않는 경우. 작동은 하지만 음성 사용자에게 신뢰 표식이 닿지 않으니 실질적 장벽입니다.

그 후(보통) — 초점 표시 제거, 모바일에서 문구 잘림·터치 영역 부족, 색 대비 부족. 사용은 가능하지만 특정 상황·특정 사용자에게 불편을 주는 문제입니다.

여력이 되면(낮음) — 펼침 안내 콘텐츠의 내용 보강(도메인 확인법·보안 접속 확인법을 더 친절하게), 의미 구조(랜드마크·제목) 정교화 같은 개선. 신뢰를 막는 건 아니지만 경험을 한 단계 끌어올리는 항목입니다.

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

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

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

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

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

오늘의 체크리스트 — 공식 배너, 이것만은

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

☐ 공식 배너가 화면 가장 위(헤더보다 위)에 있고, DOM 순서도 그렇다.
☐ 공식 문구가 실제 텍스트다(통째로 이미지로 박지 않았다).
☐ 문구가 "공식 정부 누리집임"을 명확히 밝힌다(모호한 슬로건으로 대체하지 않았다).
☐ 펼침 토글이 있다면 <button>으로 만들고 키보드로 펼침·접힘이 된다.
☐ 토글에 aria-expanded로 펼침/접힘 상태가 코드로 표현된다.
☐ 토글에 초점 표시가 또렷하다(outline: none으로 지우지 않았다).
☐ 공식 배너가 모든 페이지에 일관되게 들어간다(특히 신청·인증 페이지).
☐ 문구와 배경의 명도 대비가 충분하다(약 4.5:1 이상).
☐ 모바일에서도 핵심 문구가 온전히 보이고, 토글 터치 영역이 충분하다(약 44px 이상).
☐ 공식 배너 영역이 의미 구조(영역 역할·제목)를 갖춰 스크린리더가 인지·건너뛰기 가능하다.

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

공식 배너는 작아 보이지만, 공공 서비스를 향한 신뢰가 시작되는 첫 줄입니다. 그 가느다란 띠 하나가 누군가에겐 "여기 믿어도 되겠다"는 안심이고, 그게 빠진 누군가에겐 "혹시 가짜 아닐까" 하는 불안입니다. 우리가 무심코 막판에 끼워 넣은 그 한 줄이, 사실은 사용자가 본인인증 정보를 입력할지 말지를 가르는 신뢰의 출발점인 셈입니다.

오늘 정리한 기준이 거창해 보일 수 있지만, 핵심은 결국 단순합니다. 화면 맨 위에 공식 문구를 진짜 텍스트로 두고, 모든 페이지에 일관되게 넣고, 펼침 토글을 키보드로 쓸 수 있게 하고, 검증된 코드를 쓰는 것. 이 네 가지만 챙겨도 공식 배너의 위반 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 공식 배너가 빠진 페이지 하나, 접근성을 놓친 토글 하나부터 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 믿을 만한 곳이 됩니다. 다음 글에서는 공식 배너 바로 아래 자리하는 또 다른 상단 컴포넌트를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 공식 배너는 모든 페이지에 제대로 들어가 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 바로 보입니다.

#KRDS #공식배너Masthead #공공웹 #디자인시스템 #웹접근성 #ViewCheck #정부웹사이트 #UIUX #신뢰표식 #전자정부 #공식배너 #Masthead #KRDS기준 #디자인원칙 #표준가이드 #UI컴포넌트 #컴포넌트설계 #디지털정부 #행정안전부 #공공기관