공식 배너(Masthead) 자가진단 — ViewCheck 5분 점검

정부 사이트에 들어가면 화면 맨 위, 헤더보다도 더 위에 가느다란 띠가 하나 있습니다. "이 누리집은 대한민국 공식 전자정부 누리집입니다" 같은 한 줄과, 그 왼쪽에 작은 태극 문양 비슷한 마크. 대부분의 사람은 이걸 거의 의식하지 못하고 지나갑니다. 너무 위에 있고, 너무 작고, 매번 똑같으니까요. 그런데 이 작은 띠가 바로 KRDS가 말하는 공식 배너(Masthead)입니다. 그리고 이건 "장식"이 아니라 "신뢰의 표식"입니다.

왜 신뢰의 표식이냐면, 요즘 진짜 정부 사이트를 사칭하는 가짜 사이트가 너무 많기 때문입니다. 환급금을 미끼로 한 피싱, 과태료를 빙자한 사기, 정부 지원금을 가장한 개인정보 탈취. 이런 가짜들이 노리는 건 "이게 진짜 정부 사이트처럼 보이는가"입니다. 그래서 진짜 정부 사이트가 "나는 진짜다"라고 일관된 방식으로 알려 주는 장치가 필요해졌습니다. 그게 공식 배너입니다. 모든 진짜 전자정부 누리집이 똑같은 자리에 똑같은 문구와 마크로 "공식 누리집"임을 선언하면, 사용자는 그 띠가 없거나 이상한 사이트를 보고 "어, 이건 좀 수상한데"라고 의심할 수 있게 됩니다.

이 글은 "KRDS 완전해부" 시리즈 중에서도 조금 특별한 편입니다. 다른 컴포넌트들은 "어떻게 잘 만드느냐"가 주제라면, 공식 배너는 "있는가, 제대로 박혀 있는가"가 핵심이거든요. 그래서 이번 글은 자가진단 체크리스트 중심으로 갑니다. 거창한 디자인 이론보다, "우리 사이트 맨 위에 그 띠가 있나?", "있다면 KRDS 기준대로 박혀 있나?"를 5분 안에 스스로 확인하는 방법을 정리하겠습니다. 그리고 그 점검을 사람이 일일이 페이지마다 눈으로 보는 대신 ViewCheck로 한 번에 돌리는 법까지요.

미리 한 가지만 짚으면, 공식 배너는 "한 번 넣으면 끝"인 컴포넌트처럼 보이지만 실제로는 그렇지 않습니다. 사이트가 수십·수백 페이지로 늘어나는 동안 어떤 페이지에는 들어가고 어떤 페이지에는 빠지고, 리뉴얼하면서 통째로 사라지고, 모바일에서만 안 보이고, 코드상으로만 있고 화면엔 안 뜨는 등 의외로 잘 깨집니다. 그래서 "넣었다"가 아니라 "지금도 모든 페이지에 제대로 떠 있다"를 주기적으로 확인해야 하는, 생각보다 손이 가는 항목입니다.

공식 배너(Masthead)가 대체 뭔가 — 정의부터 정확히

먼저 용어부터 맞추겠습니다. "Masthead"라는 영어 단어는 원래 신문 1면 맨 위, 신문 이름과 발행 정보가 박힌 영역을 가리키는 말이었습니다. 웹으로 넘어오면서 "페이지 최상단의 식별 영역"을 뜻하게 됐고, KRDS는 이걸 전자정부 공식 누리집임을 알리는 최상단 띠로 정의합니다.

여기서 헷갈리기 쉬운 세 가지를 명확히 구분하겠습니다.

• 공식 배너(Masthead): 화면 맨 꼭대기, 헤더(GNB)보다 위에 위치하는 가느다란 띠. "공식 전자정부 누리집"임을 알리는 문구 + 식별 마크. 페이지 전체에서 가장 먼저, 가장 위에 옵니다.
• 헤더(Header): 그 아래에 오는 기관 로고 + 주 메뉴(GNB) + 검색 영역. 사이트의 "얼굴"이지만 공식 배너와는 별개 컴포넌트입니다.
• 히어로/메인 비주얼: 본문 상단의 큰 이미지나 슬로건 영역. 이건 또 다른 것입니다.

이 셋이 위에서부터 차례로 "공식 배너 → 헤더 → 본문"으로 쌓입니다. 공식 배너는 이 중 가장 위, 가장 작고, 가장 변하지 않는 요소입니다. 변하지 않아야 한다는 게 핵심입니다 — 사용자가 어느 정부 사이트에 가든 똑같은 자리에서 똑같은 띠를 봐야, "아 여기도 진짜 공식 누리집이구나"를 무의식적으로 확인할 수 있으니까요.

공식 배너가 담는 정보

KRDS의 공식 배너 패턴이 전달하는 핵심 메시지는 보통 두 갈래입니다.

1. "이 누리집은 공식 전자정부 누리집입니다" — 진위 식별. 이 사이트가 사칭이 아니라 진짜 정부가 운영하는 곳임을 선언.

2. "공식 누리집을 식별하는 방법 안내" — 사용자가 진짜와 가짜를 구분하는 법을 펼쳐 볼 수 있는 안내. 보통 띠를 클릭하거나 펼치면 "주소가 go.kr로 끝나는지 확인하세요" 같은 식별 가이드가 나옵니다.

즉 공식 배너는 단순히 "정부 사이트입니다"라고 적힌 라벨이 아니라, 사용자에게 진위 판별 능력을 쥐여 주는 작은 교육 장치이기도 합니다. 그래서 펼침/접힘 동작이 들어가는 경우가 많고, 그 동작이 키보드와 스크린리더로도 작동해야 한다는 접근성 요건이 따라붙습니다.

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

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서, 그리고 웹 접근성 기준(KWCAG)을 종합해 공식 배너가 충족해야 할 요건을 영역별로 정리하겠습니다. 구체적인 수치나 정확한 문구는 공식 자료가 최종 기준이므로, 여기서는 "무엇을 봐야 하는가"의 관점으로 풉니다.

1) 위치 — 페이지 최상단, 헤더보다 위

공식 배너의 첫 번째 요건은 위치입니다. 화면에서 가장 먼저 나오는 요소여야 합니다. 헤더(로고·메뉴)보다 위, 본문보다는 당연히 위. 코드 순서로도 보통 가장 앞에 옵니다. 이게 중요한 이유는, 사용자가 페이지를 위에서 아래로 훑을 때 "진짜인가?"라는 신뢰 확인을 가장 먼저 끝내게 하기 위해서입니다. 한참 스크롤한 다음에 푸터 근처에서 "공식 누리집입니다"가 나오면 의미가 없습니다.

스크린리더 사용자에게도 이 순서가 중요합니다. 코드 순서가 곧 읽히는 순서이기 때문에, 공식 배너가 코드상 맨 앞에 있으면 음성으로 듣는 사람도 페이지에 진입하자마자 "공식 전자정부 누리집입니다"를 먼저 듣게 됩니다.

2) 일관성 — 모든 페이지에 동일하게

공식 배너는 메인 페이지에만 있어선 안 됩니다. 사이트의 모든 페이지 최상단에 동일하게 있어야 합니다. 사용자가 외부 검색을 통해 메인이 아닌 깊숙한 내부 페이지(예: 특정 민원 신청 페이지)로 바로 들어오는 경우가 매우 많기 때문입니다. 그 사람도 진입한 페이지에서 "여기가 진짜 공식 누리집인가"를 확인할 수 있어야 합니다.

이게 실무에서 가장 자주 깨지는 지점입니다. 메인은 새 디자인 시스템으로 만들었는데 일부 하위 페이지는 옛날 템플릿을 그대로 쓰거나, 별도 시스템(예: 예약 시스템, 외부 위탁 페이지)으로 빠지면서 공식 배너가 사라집니다. 그래서 공식 배너 점검은 "메인만 보면 안 되고 사이트 전체를 봐야 한다"는 게 핵심입니다 — 바로 ViewCheck의 다중 페이지 분석이 빛을 발하는 지점이죠.

3) 식별 마크와 문구 — 표준을 따를 것

공식 배너에는 공식 누리집임을 나타내는 마크(엠블럼)와 문구가 들어갑니다. 이 마크와 문구는 사이트마다 제멋대로 바꾸는 게 아니라 정해진 표준을 따라야 합니다. 그래야 사용자가 사이트를 옮겨 다녀도 같은 표식을 인지할 수 있습니다. 기관 로고와는 별개입니다 — 기관 로고는 헤더에 들어가고, 공식 배너의 마크는 "전자정부 공식"이라는 공통 표식입니다.

문구 역시 "공식 전자정부 누리집"임을 분명히 전달하는 표준 문안을 따릅니다. 임의로 "우리 기관 홈페이지에 오신 것을 환영합니다" 같은 인사말로 바꿔 버리면 공식 배너의 기능을 잃습니다. 정확한 표준 마크 이미지와 문안은 KRDS 공식 자료(가이드라인 PDF, 컴포넌트 킷)에서 확인해야 합니다.

4) 펼침/접힘 동작 — 접근성 완비

많은 공식 배너는 평소엔 한 줄로 접혀 있다가, 클릭하면 "공식 누리집 식별 방법" 안내가 펼쳐지는 구조입니다. 이 펼침/접힘은 단순한 시각 효과가 아니라 접근성 요건이 따라붙는 인터랙션입니다.

• 펼침 버튼이 키보드로 조작 가능해야 합니다(Tab으로 초점 이동, Enter/Space로 펼치고 접기).
• 현재 펼쳐졌는지 접혔는지를 코드로 알려야 합니다(aria-expanded="true/false"). 그래야 스크린리더가 "확장됨/축소됨"을 읽어 줍니다.
• 펼침 버튼과 펼쳐지는 내용 영역이 연결(aria-controls)돼 있어야 합니다.
• 펼침/접힘 상태가 시각적으로도 구분돼야 합니다(화살표 방향 등). 그리고 그 시각 정보가 색에만 의존하지 않아야 합니다.

이건 셀렉트나 아코디언 같은 다른 펼침형 컴포넌트와 똑같은 원리입니다. "보이는 것과 읽히는 것의 일치"가 여기서도 핵심입니다.

5) 초점 표시(Focus)

공식 배너 안의 펼침 버튼이나 링크에 키보드로 초점이 왔을 때, 지금 거기에 초점이 있다는 게 또렷하게 보여야 합니다. 공식 배너는 화면 맨 위에 작게 있다 보니, 디자인 통일성을 이유로 포커스 표시를 outline: none으로 지워 버리는 경우가 흔합니다. 그러면 키보드 사용자는 페이지 진입 직후 첫 초점이 어디에 있는지 알 수 없게 됩니다.

6) 대비와 가독성

공식 배너는 작고 위에 있다 보니 연한 회색 배경에 연한 회색 글씨로 흐릿하게 처리되는 경우가 있습니다. 작다고 흐려도 된다는 뜻은 아닙니다. 문구와 배경의 명도 대비가 충분해야 저시력 사용자도 읽을 수 있습니다. "어차피 아무도 안 보는 띠"라는 생각이 이 흐릿함을 만드는데, 그 생각 자체가 공식 배너의 목적(신뢰 확인)을 부정하는 셈입니다.

7) 반응형 — 모바일에서도 유지

공식 배너는 데스크톱뿐 아니라 모바일에서도 떠 있어야 합니다. 화면이 좁다고 모바일에서만 공식 배너를 숨기는 경우가 의외로 많은데, 모바일 사용자야말로 피싱 링크를 문자나 메신저로 받아 들어오는 비중이 높습니다. 즉 진위 확인이 가장 필요한 사용자가 모바일 사용자인데, 거기서 배너를 빼는 건 본말이 전도된 겁니다. 좁은 화면에 맞게 문구를 줄이거나 레이아웃을 바꿀 순 있어도, 통째로 없애선 안 됩니다.

정리하면, KRDS의 공식 배너 기준은 세 축으로 요약됩니다. ① 존재와 일관성(모든 페이지 최상단에 표준 마크·문구로), ② 조작 가능성(펼침/접힘이 키보드·스크린리더로 작동), ③ 가독성과 신뢰성(충분한 대비, 표준 준수로 진위 식별 기능 유지). 이 세 축이 그대로 ViewCheck가 공식 배너를 점검하는 기준이 됩니다.

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

여기까지 읽고 "고작 한 줄짜리 띠에 뭐 이렇게 요건이 많나" 싶으실 수 있습니다. 그런데 이 작은 띠가 짊어진 무게를 알면 생각이 달라집니다.

신뢰는 "있을 때"가 아니라 "없을 때" 작동한다

공식 배너의 진짜 힘은 역설적이게도 그게 없을 때 드러납니다. 모든 진짜 정부 사이트에 공식 배너가 일관되게 있어야, 그게 없는 가짜 사이트가 "어색하게" 느껴지거든요. 이건 마치 지폐의 위조 방지 장치와 같습니다. 진짜 지폐에 홀로그램과 숨은 그림이 일관되게 있어야, 그게 없는 위조지폐를 사람들이 의심할 수 있습니다.

문제는 진짜 정부 사이트 중 일부라도 공식 배너를 빠뜨리면, 이 신뢰 체계 전체가 흔들린다는 점입니다. "진짜인데 배너가 없는 사이트"가 존재하면, 사용자는 "배너 없음 = 가짜"라는 판단을 더 이상 믿을 수 없게 됩니다. 그래서 공식 배너는 한 기관만의 문제가 아니라, 전체 전자정부 신뢰 시스템의 구성 요소입니다. 우리 사이트의 배너 누락이 다른 모든 정부 사이트의 신뢰까지 약하게 만드는 셈입니다.

가장 취약한 사용자가 가장 많이 노출된다

피싱과 사칭의 표적이 되는 사람들은 대개 디지털에 덜 익숙한 고령층, 그리고 정보 접근이 제한된 사용자입니다. 이들은 URL을 일일이 확인하거나 사이트 인증서를 검증할 여력이 없습니다. 그들이 기댈 수 있는 건 "익숙한 표식"입니다. 늘 보던 그 공식 배너가 있으면 안심하고, 없으면 멈칫하는 거죠.

그런데 만약 공식 배너가 스크린리더로 안 읽히면, 시각장애 사용자는 이 신뢰 확인을 아예 할 수 없습니다. 비장애인은 "공식 누리집입니다" 띠를 눈으로 보고 안심하는데, 음성으로만 쓰는 사용자는 그 안심의 근거를 못 받는 겁니다. 진위 확인이라는 가장 중요한 기능에서조차 차별이 생기는 거죠. KRDS가 공식 배너의 접근성을 까다롭게 요구하는 이유가 이겁니다.

"안 보이는 곳"이라 더 방치된다

공식 배너는 화면 맨 위 가장자리에 있어서, 디자인 검수나 QA에서 가장 늦게 보거나 아예 안 보는 영역입니다. 모두가 본문 콘텐츠와 핵심 기능에 집중하느라, 맨 위 띠는 "원래 있던 거"로 치고 넘어갑니다. 그러다 리뉴얼이나 템플릿 교체 과정에서 슬그머니 사라져도 아무도 눈치채지 못합니다. 가장 중요한 신뢰 장치가 가장 주목받지 못하는 자리에 있다는 게 공식 배너의 딜레마입니다. 그래서 사람의 눈이 아니라 자동 점검 도구가 "맨 위에 그 띠가 있는가"를 기계적으로 확인해 주는 게 효과적입니다.

일관성이 곧 학습이다

사용자가 정부 사이트 A에서 공식 배너를 한 번 인지하면, 사이트 B·C·D에서도 같은 표식을 찾습니다. 이 "한 번 배우면 어디서나 통함"이 표준화의 핵심 가치입니다. 만약 사이트마다 배너 위치·모양·문구가 제각각이면, 사용자는 매번 새로 학습해야 하고 결국 아무것도 신뢰하지 못하게 됩니다. KRDS가 공식 배너를 표준 컴포넌트로 묶어 둔 건, 디자이너의 창의성을 막으려는 게 아니라 국민의 인지 자산을 지키려는 일입니다.

왜 "공식 배너"라는 별도 컴포넌트가 따로 있나

여기서 한 발 더 들어가 보겠습니다. 생각해 보면 "공식 누리집입니다"라는 한 줄은 그냥 헤더 어딘가에 텍스트로 넣어도 됩니다. 그런데 KRDS는 이걸 굳이 별도의 컴포넌트로 정의해 두었습니다. 왜일까요.

첫째, 위치를 고정하기 위해서입니다. 그냥 텍스트면 디자이너마다 헤더 왼쪽에, 오른쪽에, 푸터에 제각각 둡니다. 별도 컴포넌트로 "최상단 띠"라고 못박아 두면, 모든 사이트에서 같은 자리에 옵니다. 사용자가 진위를 확인할 때 "어디를 봐야 하는지"가 통일되는 거죠. 신뢰 표식은 항상 같은 자리에 있어야 표식으로서 기능합니다.

둘째, 상호작용을 표준화하기 위해서입니다. 공식 배너는 단순 텍스트가 아니라 펼침/접힘이 들어가는 인터랙션 컴포넌트입니다. 펼치면 식별 안내가 나오는 그 동작을, 컴포넌트로 묶어 두면 키보드·스크린리더 지원까지 한 묶음으로 표준화됩니다. 텍스트 한 줄로 두면 이런 접근성 요건이 따라붙지 않아 누락되기 쉽습니다.

셋째, 재사용과 일괄 적용을 위해서입니다. 별도 컴포넌트라 공통 레이아웃에 한 번 꽂으면 전 페이지에 자동 적용됩니다. "모든 페이지에 일관되게"라는 요건을 기술적으로 보장하는 가장 쉬운 방법이 바로 컴포넌트화입니다. 이게 공식 배너가 독립 컴포넌트로 존재하는 실용적 이유입니다.

전자정부 신뢰 인프라의 한 조각

조금 더 큰 그림에서 보면, 공식 배너는 단독으로 존재하지 않습니다. 보안 연결(HTTPS), 공식 도메인 체계(go.kr 등), 개인정보처리방침, 인증서 — 이런 여러 신뢰 장치가 함께 작동해 "이 사이트는 믿을 만하다"를 만듭니다. 공식 배너는 그중에서 사용자 눈에 가장 먼저, 가장 직관적으로 보이는 조각입니다. 보안 인증서는 사용자가 일부러 확인하지 않으면 안 보이지만, 공식 배너는 페이지를 열자마자 눈에 들어옵니다. 그래서 디지털에 덜 익숙한 사용자에게는 이 시각적 표식이 다른 어떤 기술적 장치보다 강력한 신뢰 신호로 작동합니다. 가장 단순하지만 가장 직접적인 방어선인 셈입니다.

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

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

실수 1) 일부 페이지에서 배너가 사라진다

가장 흔한 실수입니다. 메인 페이지에는 공식 배너가 멀쩡히 있는데, 외부 시스템으로 연결되는 페이지나 옛 템플릿을 쓰는 하위 페이지에서는 배너가 빠집니다.

• 나쁜 예: 메인은 공식 배너 있음. 그런데 "온라인 예약" 페이지는 외부 위탁 시스템이라 배너 없음. 검색으로 예약 페이지에 바로 들어온 사용자는 진위 확인을 못 함.
• 올바른 예: 외부 위탁·별도 시스템 페이지에도 동일한 공식 배너를 적용. 공통 레이아웃(헤더 템플릿)에 배너를 포함시켜, 새 페이지를 만들어도 자동으로 들어가게 설계.

실수 2) 모바일에서만 배너를 숨긴다

데스크톱 디자인엔 배너를 넣었는데, 화면이 좁다는 이유로 모바일 CSS에서 display: none으로 숨깁니다.

• 나쁜 예: 반응형 분기에서 모바일일 때 공식 배너를 통째로 숨김. 정작 피싱에 가장 취약한 모바일 사용자가 진위 확인 수단을 잃음.
• 올바른 예: 모바일에서도 배너 유지. 공간이 부족하면 문구를 축약하거나 줄바꿈으로 대응하되, 존재 자체는 보존.

실수 3) 펼침 버튼에 접근성 속성이 없다

공식 배너를 클릭하면 식별 안내가 펼쳐지는데, 그 펼침 버튼이 <div>에 클릭 이벤트만 붙은 "가짜 버튼"입니다.

• 나쁜 예: 펼침 영역이 <div>. role도 aria-expanded도 없음. 키보드로 펼칠 수 없고, 스크린리더는 펼쳐졌는지 접혔는지 모름.
• 올바른 예: <button> 요소를 쓰거나, 최소한 role="button"·aria-expanded·aria-controls를 갖춤. 키보드(Enter/Space)로 펼치고 접을 수 있고, 상태가 음성으로 전달됨. 가능하면 KRDS 컴포넌트 킷 코드를 그대로 사용.

실수 4) 문구·마크를 임의로 바꾼다

표준 공식 배너 문구 대신 기관 자체 인사말이나 다른 디자인의 마크를 넣습니다.

• 나쁜 예: "○○기관 홈페이지입니다" 같은 인사말로 대체. 공식 누리집 식별 기능 상실. 다른 정부 사이트와 표식이 달라 사용자 혼란.
• 올바른 예: KRDS 표준 마크와 표준 문안을 그대로 사용. 진위 식별의 일관성 유지.

실수 5) 대비가 너무 낮아 안 보인다

배너를 "있긴 있되 거슬리지 않게" 한다고 연한 회색 배경에 연한 회색 글씨로 처리합니다.

• 나쁜 예: 흐릿한 회색 글씨. 저시력 사용자에게는 거의 보이지 않음. 사실상 없는 것과 마찬가지.
• 올바른 예: 문구와 배경의 명도 대비를 충분히 확보. 작아도 또렷하게.

실수 6) 포커스 표시를 지웠다

디자인 통일성을 위해 배너 내 버튼·링크의 포커스 링을 outline: none으로 제거합니다.

• 나쁜 예: 키보드로 페이지에 진입했을 때 첫 초점이 어디 있는지 안 보임.
• 올바른 예: 포커스 시 또렷한 외곽선 유지. 작은 영역이라도 포커스 표시는 살림.

실수 7) 코드엔 있는데 화면엔 안 뜬다

배너 마크업은 들어가 있는데, CSS 충돌이나 z-index 문제, 혹은 조건부 렌더링 오류로 실제 화면엔 안 보입니다.

• 나쁜 예: HTML 소스엔 공식 배너 코드가 있지만, 다른 요소에 가려지거나 height: 0으로 눌려 화면엔 안 보임. "코드엔 있으니 됐다"고 착각.
• 올바른 예: 실제 렌더링된 화면(스크린샷)에서 배너가 보이는지 확인. 코드 존재 ≠ 화면 표시임을 인식.

실수 8) 배너를 헤더와 뒤섞어 위치가 모호하다

공식 배너를 헤더 안에 끼워 넣거나 로고 옆에 붙여서, 어디까지가 공식 배너이고 어디부터가 헤더인지 모호해집니다.

• 나쁜 예: 공식 배너 문구가 헤더 메뉴 사이에 작게 섞여 들어가 식별이 안 됨.
• 올바른 예: 공식 배너는 헤더보다 위, 독립된 띠로 분리. 위치만 봐도 "이건 공식 식별 영역"임이 드러나게.

실수 9) 펼침 안내 내용이 비어 있거나 형식적이다

공식 배너를 펼쳤더니 정작 "공식 누리집 식별 방법" 안내가 없거나, 있어도 한 줄짜리 형식적 문구뿐인 경우입니다.

• 나쁜 예: 띠를 클릭하면 펼쳐지긴 하는데, "공식 누리집입니다"라는 같은 말만 반복. 정작 "주소가 go.kr로 끝나는지 확인하세요" 같은 실질적 식별 팁이 없음. 사용자가 진짜·가짜를 구분하는 데 아무 도움이 안 됨.
• 올바른 예: 펼침 영역에 사용자가 실제로 진위를 판별할 수 있는 구체적 안내를 담음. 공식 도메인 확인 방법, 보안 연결(자물쇠) 확인 방법 등. 공식 배너는 "선언"에서 끝나는 게 아니라 사용자에게 "판별법"을 쥐여 주는 교육 장치라는 점을 기억.

실수 10) 리뉴얼 과정에서 슬그머니 사라진다

가장 조용하고 가장 흔한 사고입니다. 사이트를 새 디자인으로 개편하면서, 새 템플릿에 공식 배너를 옮기는 걸 깜빡합니다. 아무도 맨 위 띠를 의식하지 않으니 출시 후에도 한참 모릅니다.

• 나쁜 예: 개편 전엔 있던 공식 배너가 새 템플릿엔 누락. QA에서 본문 기능만 확인하느라 발견 못 함. 몇 달간 배너 없이 운영.
• 올바른 예: 개편 체크리스트에 "공식 배너 전 페이지 적용 확인"을 못박고, 출시 직후 ViewCheck로 사이트 전체를 한 번 돌려 누락 여부를 기계적으로 검증. "사람이 안 보는 곳은 도구가 본다"는 원칙 적용.

한 장면 — 같은 링크, 두 사람

추상적인 요건보다 한 장면이 빠를 것 같습니다. 어느 날 두 사람이 같은 문자 메시지를 받습니다. "환급금 신청 마감 임박, 아래 링크에서 확인하세요." 링크를 누르니 정부 사이트처럼 생긴 화면이 뜹니다.

먼저 김 어르신. 화면이 그럴듯하니 의심 없이 주민번호를 입력하려다, 문득 평소 보던 그 띠가 없다는 걸 알아챕니다. "어, 진짜 정부 사이트면 맨 위에 '공식 누리집입니다'가 있어야 하는데?" 이 작은 위화감 덕분에 입력을 멈추고, 직접 검색해 진짜 사이트로 들어갑니다. 공식 배너가 일관되게 있었기에, 그게 없는 가짜를 의심할 수 있었던 겁니다.

이번엔 시각장애가 있는 박 선생님. 같은 가짜 사이트를 스크린리더로 듣습니다. 진짜 정부 사이트라면 진입 직후 "공식 전자정부 누리집입니다"가 가장 먼저 읽혔을 텐데, 이 가짜 사이트에선 아무 식별 안내 없이 바로 입력 폼이 읽힙니다. 박 선생님도 "어라, 공식 안내가 없네?" 하고 멈칫합니다. 단, 이게 가능하려면 진짜 사이트들이 공식 배너를 스크린리더로 읽히게 만들어 뒀어야 합니다. 만약 진짜 사이트들조차 배너를 이미지로만 박아 두고 대체 텍스트를 안 넣었다면, 박 선생님에겐 진짜든 가짜든 똑같이 "안내 없음"으로 들렸을 겁니다. 그러면 의심의 근거 자체가 사라지죠.

같은 가짜 링크, 두 사람. 둘 다 위기를 피할 수 있었던 건, 진짜 정부 사이트들이 공식 배너를 일관되게, 그리고 접근 가능하게 박아 뒀기 때문입니다. 우리 사이트의 공식 배너 하나가 누군가의 피싱 피해를 막는 마지막 방어선이 될 수 있다는 얘기입니다. 그리고 그게 제대로 박혀 있는지는, 사람이 매번 모든 페이지를 확인하기 어렵기 때문에 자동 점검이 필요합니다.

그래서 우리 사이트는? — ViewCheck로 5분 자가진단

여기까지가 KRDS의 공식 배너 기준입니다. 그런데 정작 어려운 건 "그래서 우리 사이트엔 공식 배너가 모든 페이지에 제대로 박혀 있나?"를 확인하는 일입니다. 메인만 보면 안 되고, 하위 페이지·외부 연동 페이지·모바일 뷰까지 다 봐야 하는데, 페이지가 수십·수백 개인 공공 사이트에서 이걸 사람이 손으로 점검하면 하루가 모자랍니다.

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

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

• 존재 여부: 페이지 최상단에 공식 배너 영역이 있는지. 단순히 코드에 있는지가 아니라, 실제로 렌더링되는지까지.
• 위치: 헤더보다 위에 있는지, 코드 순서상 앞에 오는지.
• 다중 페이지 일관성: 메인뿐 아니라 분석한 모든 페이지에 동일하게 있는지. "메인엔 있는데 신청 페이지엔 없다" 같은 편차를 페이지별로 짚어 줍니다.
• 펼침/접힘 접근성: 펼침 버튼이 키보드로 조작 가능한지, aria-expanded 같은 상태 속성이 있는지.
• 접근 가능한 이름: 배너의 마크·버튼에 스크린리더가 읽을 이름이 있는지.
• 반응형: 모바일 뷰포트에서 배너가 유지되는지(반응형 품질 분석과 연계).

여기서 ViewCheck의 두 가지 강점이 공식 배너 점검에 딱 맞습니다.

첫째, 다중 페이지 분석입니다. 공식 배너는 "모든 페이지에 일관되게"가 핵심 요건이라, 단일 페이지만 보는 도구로는 가장 중요한 검증(일관성)을 할 수 없습니다. ViewCheck는 여러 페이지를 한꺼번에 분석해서 "어느 페이지에서 배너가 빠졌는지"를 목록으로 보여 줍니다.

둘째, KRDScan Vision AI 보강입니다. 공식 배너는 코드엔 있는데 화면엔 안 뜨거나, 반대로 이미지로만 박혀 코드 검사로는 놓치기 쉬운 경우가 있습니다. ViewCheck는 DOM 검사만으로 끝내지 않고, 스크린샷을 실제로 "보고" 화면에 배너가 표시되는지 시각적으로 보강 판정합니다. 사람이 눈으로 확인하듯 화면을 함께 보기 때문에, "코드 존재 ≠ 화면 표시"의 함정에 빠지지 않습니다.

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 공식 배너 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "분석한 12개 페이지 중 9개에는 공식 배너가 있으나, 예약 페이지·문의 페이지·외부 연동 페이지 3개에는 없음"처럼 구체적으로요. 어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

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

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

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

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소(KRDS-uiux/krds-uiux)의 html/code 폴더에 공식 배너 마크업이 키보드 동작·ARIA 속성이 구현된 상태로 들어 있습니다. 핵심은 이 배너를 공통 레이아웃(전역 헤더 템플릿이나 레이아웃 컴포넌트)에 한 번만 넣어, 모든 페이지에 자동으로 적용되게 하는 것입니다. 페이지마다 따로 복붙하면 반드시 어딘가에서 빠집니다. "공통 레이아웃에 한 번"이 일관성을 지키는 가장 확실한 방법입니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 공식 배너 컴포넌트를 가져다 쓸 수 있습니다. 직접 그리지 말고 표준 컴포넌트를 배치하면, 표준 마크·문구·간격이 기준에 맞춰집니다. 특히 디자이너가 시안 단계에서 모든 화면 템플릿(메인/리스트/상세/폼) 상단에 공식 배너를 똑같이 배치해 두면, 개발 단계에서 빠질 위험이 줄어듭니다.

기획자라면 — 화면 정의서에서 "공통 헤더" 항목에 "공식 배너(KRDS Masthead) 포함, 전 페이지 적용"을 명시하세요. 그리고 외부 위탁 시스템이나 별도 예약·결제 페이지를 연동할 때 "해당 페이지에도 공식 배너 적용" 조건을 계약·요구사항에 넣어야 합니다. 이 한 줄이 "외부 페이지에서 배너 누락"이라는 가장 흔한 사고를 막습니다.

자주 묻는 질문

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

Q. 공식 배너랑 헤더(로고·메뉴)는 뭐가 다른가요?

위치와 역할이 다릅니다. 공식 배너는 화면 가장 꼭대기에 있는 "이건 진짜 공식 누리집입니다"라는 신뢰 표식이고, 헤더는 그 아래에 오는 기관 로고·주 메뉴·검색 영역입니다. 공식 배너의 마크는 모든 정부 사이트가 공유하는 공통 표식이고, 헤더의 로고는 각 기관 고유의 것입니다. 둘은 별개 컴포넌트라 따로따로 챙겨야 합니다. 공식 배너가 있다고 헤더가 면제되는 것도, 그 반대도 아닙니다.

Q. 메인 페이지에만 넣으면 안 되나요? 어차피 다들 메인으로 들어오잖아요.

이게 가장 위험한 착각입니다. 실제로는 검색엔진이나 외부 링크, 문자 메시지를 통해 메인이 아닌 깊숙한 내부 페이지로 바로 진입하는 사용자가 매우 많습니다. 특히 피싱 링크는 메인을 거치지 않고 곧장 입력 폼이 있는 페이지로 유도합니다. 그래서 공식 배너는 반드시 모든 페이지에 있어야 의미가 있습니다. 메인에만 있으면 정작 진위 확인이 가장 필요한 순간(내부 폼 페이지 진입)에 작동하지 않습니다.

Q. 디자인이 답답해 보여서 배너를 좀 작게, 흐리게 처리하고 싶은데요?

작게 만드는 것까지는 괜찮습니다. 하지만 "흐리게"는 곤란합니다. 공식 배너의 목적은 사용자가 진위를 확인하는 것인데, 흐려서 안 보이면 그 목적 자체가 무너집니다. 또 명도 대비가 낮으면 저시력 사용자는 아예 못 읽습니다. 작더라도 또렷하게, 라는 게 원칙입니다. "거슬리지 않게"와 "안 보이게"는 다릅니다.

Q. 우리 사이트는 외부 업체가 만든 예약 시스템을 쓰는데, 거기엔 공식 배너가 없어요.

그 외부 시스템 페이지도 사용자 눈에는 "우리 기관 서비스"입니다. 그래서 거기에도 공식 배너가 있어야 합니다. 위탁 계약 시 "공식 배너(KRDS Masthead) 적용"을 요구사항에 명시하는 게 가장 확실합니다. 이미 운영 중이라면, 외부 시스템 상단에 공통 헤더를 삽입하는 방식으로 적용할 수 있는지 업체와 협의하세요. ViewCheck로 사이트 전체를 분석하면 바로 이런 "외부 연동 페이지 배너 누락"이 목록으로 잡힙니다.

Q. 모바일에선 화면이 좁아서 배너를 숨겼는데, 문제가 되나요?

문제가 됩니다. 오히려 모바일이 더 중요합니다. 피싱·사칭 링크는 대부분 문자·메신저로 전달되고, 그걸 누르는 건 모바일입니다. 즉 진위 확인이 가장 필요한 환경이 모바일인데 거기서 배너를 빼면 본말이 전도됩니다. 공간이 부족하면 문구를 줄이거나 두 줄로 접는 식으로 대응하되, 존재 자체는 유지하세요.

Q. 코드에는 공식 배너가 분명히 있는데, ViewCheck에서 미통과로 나왔어요. 왜죠?

"코드에 있다"와 "화면에 보인다"는 다릅니다. CSS 충돌, z-index 문제, 조건부 렌더링 오류, 다른 요소에 가려짐 등으로 코드는 있지만 실제 화면엔 안 뜨는 경우가 있습니다. ViewCheck는 코드만 보는 게 아니라 KRDScan Vision AI로 실제 렌더링된 스크린샷을 함께 확인하기 때문에, "코드엔 있는데 화면엔 없는" 상태를 잡아냅니다. 미통과로 나왔다면 실제 브라우저에서 그 페이지 맨 위에 배너가 보이는지 직접 확인해 보세요. 십중팔구 안 보일 겁니다.

Q. 공식 배너의 정확한 마크 이미지와 문구는 어디서 받나요?

KRDS 공식 자료가 최종 기준입니다. 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)와 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux), 공식 Figma(@krds)에서 표준 마크와 문안, 코드를 확인할 수 있습니다. 임의로 비슷하게 만들지 말고 공식 자산을 그대로 가져다 쓰는 게 일관성과 진위 식별 기능을 지키는 길입니다.

Q. 이미 운영 중인 사이트인데, 전부 다시 손봐야 하나요?

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 사이트 전체를 분석해 "어느 페이지에 공식 배너가 빠졌는지"를 목록으로 만든 다음, 빠진 페이지부터 채우면 됩니다. 공식 배너는 보통 공통 레이아웃에 한 번 넣으면 대부분의 페이지에 일괄 적용되므로, 의외로 적은 작업으로 큰 효과를 볼 수 있습니다. 외부 연동 페이지처럼 공통 레이아웃이 안 닿는 곳만 개별 처리하면 됩니다.

Q. 공식 배너를 펼침 없이 그냥 한 줄 텍스트로만 둬도 되나요?

"공식 누리집입니다"라는 선언만 한 줄 두는 것도 안 두는 것보다는 낫습니다. 다만 KRDS 패턴이 펼침/접힘으로 식별 안내까지 담는 데에는 이유가 있습니다 — 사용자에게 "진짜·가짜를 직접 구분하는 법"을 알려 주기 위해서죠. 단순 선언은 "내가 진짜다"라고 말하는 것뿐이고(가짜도 똑같이 말할 수 있죠), 식별 안내는 "이렇게 확인해 보라"고 판별법을 주는 것입니다. 후자가 훨씬 강력합니다. 가능하면 표준 패턴대로 펼침 안내를 갖추되, 그게 어렵다면 최소한 표준 마크와 문구라도 정확히 두세요.

Q. 단일 페이지짜리 간단한 안내 사이트인데도 공식 배너가 필요한가요?

페이지가 하나든 백 개든, 그게 전자정부 누리집이라면 공식 배너는 있어야 합니다. 오히려 단순한 안내 사이트일수록 사칭 사기에 악용되기 쉽습니다(만들기 쉬우니까요). 한 페이지짜리라도 사용자는 "이게 진짜 정부 사이트인가"를 확인하고 싶어 하고, 공식 배너가 그 확인을 가능하게 합니다. 규모와 무관하게 적용하세요.

Q. ViewCheck 컴포넌트 탭에서 공식 배너만 따로 보고 싶은데요?

컴포넌트(Components) 탭은 KRDS 846규칙 중 컴포넌트(CP) 규칙군 446개의 판정 결과를 보여 줍니다. 그 안에서 공식 배너 관련 규칙을 찾아, 통과/미통과 수와 페이지별 위치를 확인할 수 있습니다. 여러 페이지를 분석했다면 "어느 페이지에서 통과하고 어느 페이지에서 미통과인지"가 함께 표시되므로, 일관성 점검이 특히 쉽습니다. 미통과 항목에는 이유와 개선 방법(howToFix), 우선순위(P0~P3)가 같이 붙어 나옵니다.

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

ViewCheck로 돌려 보면 공식 배너 관련 문제가 한 가지로 끝나지 않는 경우가 많습니다. 페이지가 많을수록 "어디부터 손대야 하나" 고민이 됩니다. 공식 배너 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 입력·신청·로그인처럼 개인정보를 다루는 핵심 경로 페이지에서 공식 배너가 아예 없는 경우. 진위 확인이 가장 필요한 곳에 신뢰 표식이 없는 것이라 1순위입니다. 외부 연동 예약·결제·민원 페이지가 여기 해당하는 경우가 많습니다.

그다음(높음) — 공식 배너는 있으나 스크린리더로 안 읽히거나 펼침 버튼이 키보드로 작동하지 않는 경우. 작동은 하는 것처럼 보여도 음성·키보드 사용자에게는 진위 확인 기능이 차단된 상태입니다. 모바일에서만 배너가 숨겨진 경우도 여기 포함됩니다(피싱 노출이 큰 환경이므로).

그 후(보통) — 배너는 있고 읽히기도 하지만, 대비가 낮아 흐릿하거나 포커스 표시가 없는 경우. 사용은 가능하지만 저시력·키보드 사용자에게 불편을 주는 문제입니다.

여력이 되면(낮음) — 위치가 헤더와 섞여 모호하거나, 펼침 안내 문구가 빈약한 경우. 신뢰 기능을 막는 건 아니지만 경험을 한 단계 끌어올리는 항목입니다.

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

5분 자가진단 실전 순서 — 지금 바로 해 보기

이 글의 앵글이 "점검"인 만큼, 도구 없이 손으로 5분 안에 끝내는 실전 순서를 정리해 둡니다. 그다음 ViewCheck로 사이트 전체를 자동 확인하면 됩니다.

1단계(30초) — 메인 페이지 맨 위 확인. 우리 사이트 메인을 열고 화면 가장 꼭대기를 봅니다. "공식 전자정부 누리집입니다" 같은 띠가 헤더(로고·메뉴)보다 위에 있나요? 없으면 여기서 이미 1순위 문제입니다.

2단계(1분) — 내부 페이지 3~4개 확인. 메인에서 신청·로그인·검색·문의 페이지로 각각 들어가 봅니다. 그리고 외부에서 들어오는 시뮬레이션으로, 그 내부 페이지 URL을 새 탭에 직접 붙여 넣어 메인을 거치지 않고 진입해 봅니다. 각 페이지 맨 위에도 공식 배너가 똑같이 있나요? 한 곳이라도 없으면 일관성 위반입니다.

3단계(1분) — 키보드 점검. 마우스를 치우고 Tab 키만으로 페이지에 진입해 봅니다. 첫 초점이 어디에 가는지 보이나요(포커스 표시)? 공식 배너에 펼침 버튼이 있다면 Enter나 Space로 펼쳐지고 접히나요? 마우스로만 되고 키보드로 안 되면 접근성 위반입니다.

4단계(1분) — 모바일 확인. 브라우저 개발자 도구의 모바일 보기로 전환하거나 실제 폰으로 같은 페이지를 엽니다. 모바일에서도 공식 배너가 보이나요? 데스크톱엔 있는데 모바일에서 사라졌다면 위반입니다.

5단계(30초) — 대비 확인. 공식 배너 문구가 또렷하게 읽히나요, 아니면 배경에 묻혀 흐릿한가요? 한 발 떨어져서 봐도 글씨가 보여야 합니다.

이 다섯 단계를 손으로 해 보면 "우리 사이트가 대략 어떤 상태인지" 감이 옵니다. 다만 손 점검의 한계는 분명합니다 — 페이지가 수십·수백 개면 전부 못 봅니다. 그래서 손으로 메인만 빠르게 확인한 뒤, 사이트 전체의 일관성은 ViewCheck로 한 번에 돌리는 게 정답입니다. 손 점검은 "감 잡기", 자동 점검은 "전수 검사"라고 생각하시면 됩니다.

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

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

• KRDS 가이드라인 PDF(디지털 정부서비스 UI/UX 가이드라인, 2025.08판) — 공식 배너의 정의와 사용 원칙의 1차 원천.
• KRDS 컴포넌트 문서(웹) — 공식 배너(Masthead)의 예시와 설명을 화면으로 확인.
• KRDS 컴포넌트 킷(GitHub `KRDS-uiux/krds-uiux`) — html/code 폴더의 공식 배너 마크업을 그대로 가져다 사용(npm install krds-uiux 또는 CDN).
• KRDS 공식 Figma(@krds) — 디자이너용 공식 배너 컴포넌트.

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

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

마지막으로, 디자이너·개발자·기획자가 공식 배너를 만들거나 검수할 때 바로 쓸 수 있는 체크리스트로 정리합니다. 이걸 그대로 들고 우리 사이트를 5분만 훑어보세요.

• ☐ 화면 맨 위, 헤더보다 위에 공식 배너가 있다.
• ☐ 메인뿐 아니라 모든 페이지(리스트/상세/신청/로그인/외부 연동)에 동일하게 있다.
• ☐ KRDS 표준 마크와 문구를 쓴다(기관 인사말로 대체하지 않았다).
• ☐ 펼침/접힘 버튼이 키보드만으로 작동한다(Enter/Space).
• ☐ 펼침 상태가 코드로 전달된다(aria-expanded), 펼침 내용과 연결(aria-controls)돼 있다.
• ☐ 배너의 마크·버튼에 스크린리더가 읽을 이름이 있다.
• ☐ 포커스 표시가 또렷하다(outline: none으로 지우지 않았다).
• ☐ 문구와 배경의 명도 대비가 충분하다(흐릿하지 않다).
• ☐ 모바일에서도 배너가 유지된다(좁다고 숨기지 않았다).
• ☐ 코드뿐 아니라 실제 화면에 배너가 보인다(렌더링 확인).
• ☐ 외부 위탁·별도 시스템 페이지에도 배너가 적용돼 있다.

KRDS 컴포넌트 킷(npm install krds-uiux 또는 CDN)을 공통 레이아웃에 한 번 넣으면 위 항목 대부분이 이미 구현된 상태로, 그리고 모든 페이지에 일괄 적용된 상태로 시작할 수 있습니다. 직접 페이지마다 넣다가 빠뜨릴 위험을 줄이는 가장 확실한 방법이죠. 공식 Figma 라이브러리(@krds)에서는 디자이너가 표준 공식 배너 컴포넌트를 그대로 가져다 쓸 수 있습니다.

공식 배너는 작아 보이지만, 공공 서비스에서 사용자가 처음 마주치는 "이건 진짜다"라는 약속입니다. 그 약속이 어떤 페이지에선 지켜지고 어떤 페이지에선 깨지면, 사용자는 더 이상 그 약속을 믿지 못하게 됩니다. 우리가 무심코 넘긴 맨 위의 띠 하나가, 누군가에게는 피싱 사기를 멈춰 세우는 마지막 신호일 수 있습니다.

오늘 정리한 기준이 많아 보일 수 있지만, 핵심은 결국 단순합니다. 모든 페이지 맨 위에, 표준 마크와 문구로, 키보드·스크린리더로도 읽히게, 모바일에서도 또렷하게 — 이 네 가지만 챙기면 공식 배너의 위반 대부분은 사라집니다. 그리고 그게 모든 페이지에서 잘 지켜지고 있는지는, 사람 눈으로는 몇 시간 걸릴 일을 ViewCheck로 5분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 배너가 빠진 페이지 하나부터 채워 나가면, 우리 사이트는 분명히 조금씩 더 믿을 수 있는 곳이 됩니다. 다음 글에서는 공식 배너 바로 아래에 오는 또 다른 핵심 영역을 같은 방식으로 뜯어보겠습니다.

우리 사이트의 공식 배너는 모든 페이지에 제대로 박혀 있을까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인뿐 아니라 여러 페이지를 한꺼번에 돌려 보면, 위 체크리스트가 실제로 지켜지고 있는지, 어느 페이지에서 배너가 빠졌는지 한눈에 보입니다.

#KRDS #공식배너Masthead #공공웹 #디자인시스템 #웹접근성 #피싱방지 #전자정부 #정부웹사이트 #ViewCheck #UIUX #신뢰성 #공식배너 #Masthead #자가진단 #체크리스트 #점검항목 #UI컴포넌트 #컴포넌트설계 #디지털정부 #행정안전부