푸터(Footer) 자가진단 — ViewCheck 5분 점검

웹사이트의 맨 아래, 스크롤을 한참 내려야 나오는 그곳. 우리는 그걸 "푸터"라고 부르고, 솔직히 평소엔 거의 신경 쓰지 않습니다. 메인 비주얼, 검색창, 신청 버튼 — 위쪽은 다들 눈에 불을 켜고 만들지만, 맨 아래 회색 띠 영역은 "주소 적고, 연락처 적고, 저작권 한 줄 넣으면 끝"이라고 생각하기 쉽죠. 그런데 막상 사용자가 "이 기관 대표번호가 뭐였지?", "개인정보처리방침은 어디 있지?", "이 사이트 운영 주체가 어디지?"를 찾을 때, 손가락은 본능적으로 화면 맨 아래로 향합니다. 푸터는 평소엔 투명인간처럼 있다가, 결정적인 순간에 사용자가 가장 먼저 찾는 곳입니다.

이 글은 "푸터를 어떻게 멋지게 디자인할까"를 다루는 글이 아닙니다. 그보다는 "지금 우리 사이트 푸터가 KRDS 기준을 지키고 있는지, 5분 만에 직접 확인하는 방법"에 관한 글입니다. 거창한 컨설팅 없이, 여러분이 지금 당장 브라우저를 열고 우리 사이트 맨 아래로 내려가서 항목 하나하나를 체크해 볼 수 있도록, 실무 체크리스트 중심으로 풀어 가겠습니다. 그리고 페이지가 수십·수백 개라 손으로 다 못 볼 때, 어떻게 자동으로 점검하는지까지 이어가겠습니다.

미리 한 가지만 말씀드리면, 공공 사이트를 수백 개 분석하다 보면 푸터에서 똑같은 빈틈이 끝없이 반복되는 걸 봅니다. 필수 정보가 빠져 있거나, 정보는 있는데 스크린리더로는 안 읽히거나, 메인 페이지엔 멀쩡한 푸터가 서브 페이지엔 통째로 사라져 있거나. 그래서 푸터 점검은 "있다/없다"를 넘어서, "모든 페이지에 일관되게, 누구나 접근할 수 있게" 들어가 있는지까지 봐야 합니다. 자, 그럼 우리 사이트 푸터부터 같이 뜯어봅시다.

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

먼저 용어부터 맞추겠습니다. 푸터(Footer)는 웹페이지의 가장 아래에 위치하는, 모든 페이지에 공통으로 들어가는 영역입니다. 헤더(머리말)가 페이지 위쪽에서 로고·내비게이션·검색을 담당한다면, 푸터(꼬리말)는 페이지 아래쪽에서 기관 정보·법적 링크·연락처·관련 사이트 같은 "보조적이지만 꼭 필요한" 정보를 담습니다.

여기서 중요한 건, 푸터가 단순한 "장식 띠"가 아니라 하나의 독립된 컴포넌트이자 페이지의 구조적 골격이라는 점입니다. KRDS(대한민국 정부 디자인 시스템)는 푸터를 헤더·내비게이션과 마찬가지로 사이트 전체의 정체성과 신뢰성을 떠받치는 핵심 컴포넌트로 봅니다. 그래서 "아무 정보나 대충 넣는 자리"가 아니라, "무엇이 들어가야 하고 어떻게 들어가야 하는지" 기준이 정해져 있습니다.

푸터에 담기는 정보를 크게 나눠 보면 이렇습니다.

• 기관 식별 정보: 기관명, 주소, 대표 전화번호, 운영 주체. "이 사이트가 어디서 운영하는 공식 사이트인가"를 알리는 정보.
• 법적·정책 링크: 개인정보처리방침, 이용약관, 저작권 표시, (해당 시) 이메일주소무단수집거부 등. 공공 사이트의 신뢰성과 직결되는 링크들.
• 보조 탐색: 사이트맵, 관련 기관 링크, 패밀리 사이트, 자주 찾는 메뉴.
• 부가 정보: SNS 채널, 만족도 조사, 저작권 정책(공공누리 등) 표시.

이 정보들이 "있느냐"도 중요하지만, 점검 관점에서는 "어떻게 구현돼 있느냐"가 더 중요합니다. 같은 전화번호라도 그냥 텍스트로만 박혀 있는 것과, 구조적으로 의미가 부여돼 스크린리더가 "대표전화"라고 읽어 주는 것은 천지 차이거든요.

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

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서를 기준으로, 푸터가 충족해야 할 요건을 영역별로 정리하겠습니다. 이 항목들이 그대로 뒤에 나올 자가진단 체크리스트의 근거가 됩니다.

1) 구조적 의미 — 푸터는 `<footer>`로 선언돼야 한다

가장 기본이면서 가장 자주 빠지는 요건입니다. 화면 맨 아래에 회색 박스를 그려 넣고 그 안에 정보를 채우면 "푸터처럼 보이는 것"은 만들 수 있습니다. 하지만 그게 코드 수준에서 푸터라고 선언돼 있지 않으면, 스크린리더 사용자나 보조기술에게는 그냥 "본문에 딸린 또 하나의 글자 덩어리"일 뿐입니다.

웹 표준으로 말하면, 푸터 영역은 <footer> 요소(또는 role="contentinfo")로 감싸야 합니다. 이렇게 하면 스크린리더 사용자가 "페이지 정보 영역으로 바로 이동" 같은 단축 탐색으로 푸터로 한 번에 점프할 수 있습니다. 매번 본문을 끝까지 훑지 않아도 되는 거죠. KRDS가 헤더(<header>)·내비게이션(<nav>)·본문(<main>)·푸터(<footer>)라는 구조적 골격을 강조하는 이유가 여기 있습니다. 화면을 못 보는 사용자에게는 이 골격이 곧 지도이기 때문입니다.

2) 필수 정보의 포함 — 공공 사이트의 신뢰성 요건

푸터는 그 사이트가 "공식적이고 신뢰할 수 있는 곳"임을 알리는 자리입니다. KRDS와 공공 웹 운영 관례를 종합하면, 공공 사이트 푸터에는 최소한 다음이 들어가야 합니다.

• 기관명과 주소, 대표 연락처: 누가 운영하는 사이트인지, 어디에 연락해야 하는지.
• 개인정보처리방침 링크: 이건 단순 권장이 아니라 사실상 필수입니다. 그리고 다른 약관과 구분되게, 보통 더 강조해서 표시합니다.
• 저작권 표시: 콘텐츠의 권리 관계와 운영 주체를 분명히 합니다.

여기서 점검 포인트 하나. 정보가 "있는지"만 보지 말고 "찾기 쉬운지"도 봐야 합니다. 개인정보처리방침이 다른 링크 열다섯 개 사이에 똑같은 크기·색으로 묻혀 있으면, 있어도 없는 거나 마찬가지입니다.

3) 푸터 내 링크 — 명확한 텍스트와 접근성

푸터에는 링크가 잔뜩 들어갑니다. 사이트맵, 관련 기관, 정책 페이지, SNS. 이 링크들이 각각 "어디로 가는지" 명확해야 합니다.

• 링크 텍스트가 그 자체로 목적지를 설명해야 합니다("바로가기", "여기" 같은 모호한 텍스트 금지).
• 새 창으로 열리는 링크(특히 외부 기관 사이트)는 새 창으로 열린다는 사실을 사용자에게 알려야 합니다.
• 아이콘만 있는 링크(SNS 아이콘 등)에는 반드시 이름(aria-label 등)이 붙어야 합니다. 안 그러면 스크린리더가 "링크"라고만 읽고 어디로 가는지 알 수 없습니다.

4) 키보드 접근과 초점 표시

푸터의 모든 링크는 키보드(Tab)만으로 도달 가능하고, 초점이 왔을 때 시각적으로 또렷하게 보여야 합니다. 푸터가 화면 맨 아래에 있다는 이유로, 또는 "어차피 보조 영역"이라는 이유로 포커스 표시를 outline: none으로 지워 버리는 경우가 의외로 많습니다. 그러면 키보드 사용자는 푸터를 훑을 때 자기가 어느 링크에 와 있는지 알 수 없게 됩니다.

5) 일관성 — 모든 페이지에 같은 푸터

이게 점검 관점에서 정말 중요합니다. 푸터는 정의상 "모든 페이지 공통" 영역입니다. 그런데 현실에서는 메인 페이지엔 풀 푸터가 있는데, 검색 결과 페이지나 일부 신청 페이지, 또는 외부 시스템으로 연결된 하위 페이지에는 푸터가 축약돼 있거나 아예 없는 경우가 흔합니다. 사용자 입장에서는 "방금 전 페이지엔 연락처가 있었는데 이 페이지엔 왜 없지?" 하고 당황하게 됩니다. KRDS가 컴포넌트를 표준화하는 핵심 이유 중 하나가 이 일관성입니다 — 어느 페이지에 가도 같은 자리에서 같은 정보를 찾을 수 있어야 한다는 것.

6) 색 대비와 가독성

푸터는 관습적으로 어두운 배경(짙은 회색·남색)에 밝은 글씨를 쓰는 경우가 많습니다. 이때 글자와 배경의 명도 대비가 충분하지 않으면, 저시력·고령 사용자에게는 푸터 정보가 흐릿하게 보입니다. "어차피 보조 정보니까 연하게 깔자"는 디자인 욕심이, 정작 그 정보를 가장 필요로 하는 사용자를 배제하는 결과로 이어집니다. 한국형 웹 접근성 지침(KWCAG)과 국제 표준 모두 텍스트의 최소 명도 대비를 권장합니다.

7) 반응형 — 모바일에서의 푸터

데스크톱에서는 푸터에 여러 열(column)로 정보를 쫙 펼쳐 두지만, 모바일에서는 화면이 좁아 그 구조가 깨지기 쉽습니다. 링크가 다닥다닥 붙어 손가락으로 정확히 누르기 어렵거나, 가로 스크롤이 생기거나, 정보 일부가 잘려 나가기도 합니다. 모바일에서도 푸터의 모든 정보가 접근 가능하고, 링크의 터치 영역(보통 한 변 44px 이상)이 충분히 확보돼야 합니다.

정리하면, KRDS의 푸터 기준은 세 축으로 요약됩니다. ① 신뢰성(필수 정보의 포함과 명확한 노출), ② 구조성(<footer>로 선언돼 보조기술이 인식할 것, 모든 페이지 일관), ③ 접근성(키보드·스크린리더·대비·터치 영역). 이 세 축이 그대로 ViewCheck가 푸터를 판정하는 기준이고, 또 여러분이 직접 점검할 항목이기도 합니다.

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

"맨 아래 회색 띠 하나에 뭘 이리 까다롭나" 싶으실 수 있습니다. 그런데 이 요건들은 누가 괜히 만든 규칙이 아니라, 실제 사용자가 막히는 지점에서 역으로 도출된 것들입니다.

푸터는 "신뢰의 마지막 확인 도장"이다

사람은 낯선 사이트에서 무언가를 하기 전에, 무의식적으로 "여기 믿을 만한 곳인가"를 확인합니다. 그리고 그 확인의 상당 부분이 푸터에서 이루어집니다. 운영 기관명이 분명히 적혀 있는가, 연락처가 있는가, 개인정보를 어떻게 다루는지 방침이 있는가, 저작권 주체가 누구인가. 이 정보들이 푸터에 깔끔하게 정리돼 있으면 사용자는 "공식 사이트구나" 하고 안심합니다. 반대로 푸터가 텅 비어 있거나 정보가 엉성하면, 아무리 위쪽 디자인이 멋져도 "이거 진짜 공공기관 사이트 맞나?" 하는 의심이 듭니다. 특히 보이스피싱·가짜 사이트가 기승을 부리는 시대에, 푸터의 공식 정보는 사용자가 진짜와 가짜를 가르는 단서가 됩니다.

결정적 순간에 가장 먼저 찾는 곳

평소엔 안 보이지만, 사용자가 정말 급할 때 푸터를 찾습니다. 민원을 처리하다 막혀서 "전화해서 물어봐야겠다" 싶을 때 대표번호를 찾고, 개인정보 동의가 찜찜할 때 처리방침을 찾고, 이 사이트의 정보를 인용해도 되는지 궁금할 때 저작권 정책을 찾습니다. 이 결정적 순간에 정보가 없거나 찾기 어려우면, 사용자의 볼일이 그 자리에서 멈춥니다. 푸터는 "평소엔 안 쓰지만 없으면 큰일 나는" 비상구 같은 존재입니다.

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

비장애인은 화면을 "본다"고 생각하지만, 사실 우리는 화면을 보고 머릿속에서 의미로 번역합니다. 맨 아래 회색 영역을 보고 "아, 여기가 푸터구나" 하고 짐작하죠. 스크린리더 사용자에게는 이 짐작 과정이 없습니다. 코드가 "여기는 페이지 정보 영역(<footer>)"이라고 말해 줘야 비로소 그곳이 푸터임을 압니다.

그래서 푸터는 "보기에 푸터 같은 것"으로는 부족하고, "코드 수준에서 푸터라고 선언된 것"이어야 합니다. <div class="footer">에 정보를 채워 넣어 시각적으론 완벽해 보여도, 코드가 그걸 "페이지 정보 영역"이라고 말해 주지 않으면 스크린리더 사용자는 푸터로 바로 점프할 수 없습니다. 본문을 끝까지 일일이 훑어 내려가야 그 정보에 닿을 수 있죠. 시각장애인에게 "본문 다 듣고 맨 끝까지 가야만 연락처를 알 수 있다"는 건 큰 불편입니다.

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

상업 사이트는 푸터가 부실해도 사용자가 떠나면 그만입니다. 그런데 공공 서비스는 다릅니다. 주민등록 등본을 떼거나, 복지를 신청하거나, 세금을 내는 일은 그 사이트가 아니면 할 수 없습니다. 사용자가 "안 쓸 자유"가 없어요. 그래서 푸터의 연락처가 누군가에게 안 읽히면, 그건 단순한 불편이 아니라 도움을 요청할 통로 자체가 막히는 일이 됩니다. 디지털에 서툰 고령층일수록 막혔을 때 "전화로 물어보자"에 의존하는데, 그 전화번호조차 찾기 어렵다면 서비스 접근권이 사실상 박탈되는 셈입니다.

일관성이 곧 학습 비용 절감

KRDS가 푸터의 구성과 위치를 표준화하는 또 다른 이유는 일관성입니다. 정부 사이트마다 푸터 구조가 제각각이면, 사용자는 사이트를 옮길 때마다 "여기선 개인정보처리방침이 어디 있지?"를 다시 찾아야 합니다. 모든 공공 서비스의 푸터가 비슷한 자리에 비슷한 정보를 두면, 한 번 익힌 사용 습관이 모든 사이트에서 통합니다. 디지털 약자에게 이 "다시 안 찾아도 됨"은 생각보다 큰 배려입니다.

작은 영역일수록 방치되기 쉽다

역설적이지만, 푸터처럼 "맨 아래에 있고 보조적인" 영역일수록 품질 관리에서 밀려납니다. 메인 비주얼이나 핵심 기능에는 모두가 눈을 부릅뜨지만, 화면 맨 끝의 회색 띠에는 아무도 깐깐하게 굴지 않거든요. 디자인 검수 회의에서 "푸터 한번 봅시다"라고 말하는 사람을 본 적이 거의 없습니다. 그러다 보니 푸터는 첫 구축 때 한 번 만들어 놓고는 몇 년째 손대지 않은 채로 남아 있는 경우가 많습니다. 기관 주소가 바뀌었는데 푸터엔 옛 주소가 그대로 박혀 있거나, 조직이 개편됐는데 푸터의 운영 주체명이 옛것인 사이트도 적지 않습니다. 그런데 사용자가 "이 기관 지금 어디 있지?", "연락처가 뭐지?"를 확인하는 곳이 바로 이 방치된 영역입니다. 가장 덜 주목받는 영역이 사실은 신뢰성과 직결되는 길목인 셈입니다. KRDS가 푸터까지 컴포넌트로 표준화해 둔 건, 바로 이 "방치되기 쉬운 곳"에서 품질이 무너지는 걸 막기 위해서입니다.

푸터는 "검색되는" 영역이기도 하다

조금 다른 각도의 이야기인데, 푸터는 검색엔진과 자동화 도구가 그 사이트의 정체를 파악하는 데도 쓰입니다. 기관명·연락처·정책 링크가 구조적으로 정리돼 있으면, 검색엔진이 "이건 ○○기관의 공식 사이트"라고 더 정확히 이해합니다. 반대로 푸터 정보가 이미지로만 박혀 있거나 구조가 없으면, 기계는 그 정보를 읽지 못합니다. 사람에게 안 읽히는 푸터는 기계에게도 안 읽히는 경우가 많습니다. 그래서 푸터를 제대로 구조화하는 일은 접근성뿐 아니라 검색 노출·개방성과도 맞닿아 있습니다. 하나를 잘하면 여러 영역이 함께 좋아지는, 효율 좋은 투자라는 뜻입니다.

우리 사이트 푸터, 지금 바로 5분 점검 — 손으로 해보기

자, 이제 실전입니다. 거창한 도구 없이도 지금 당장 우리 사이트 푸터를 직접 점검할 수 있습니다. 브라우저를 열고 우리 사이트 메인 페이지를 띄운 다음, 순서대로 따라 해보세요. 5분이면 충분합니다.

1단계 — 맨 아래로 내려가서 "필수 정보 있나" 눈으로 확인

페이지를 끝까지 스크롤해 푸터에 도착하세요. 그리고 다음을 찾아보세요.

• 기관명이 분명히 적혀 있나?
• 주소와 대표 전화번호가 있나?
• 개인정보처리방침 링크가 있나? (그리고 다른 링크보다 눈에 띄나?)
• 저작권 표시가 있나?

하나라도 없다면 그 자체가 첫 번째 개선 과제입니다. 특히 개인정보처리방침이 없으면 우선순위 최상위입니다.

2단계 — 마우스를 치우고 Tab만으로 푸터 훑기

마우스에서 손을 떼고, Tab 키만 눌러 페이지 아래로 내려가 보세요. 푸터의 링크들에 초점(focus)이 차례로 가나요? 그리고 초점이 간 링크가 테두리나 외곽선으로 또렷이 표시되나요?

• 초점이 푸터 링크를 건너뛰면 → 키보드 접근 문제.
• 초점은 가는데 어디 있는지 안 보이면 → 포커스 표시 제거 문제(outline: none).

3단계 — 이미지/아이콘을 꺼보거나 가려보기

푸터에 SNS 아이콘이나 그림으로 된 링크가 있다면, 개발자도구로 잠시 숨기거나 이미지를 꺼보세요. 그래도 그게 무슨 링크인지 알 수 있나요? 아이콘만 있고 이름(텍스트나 aria-label)이 없다면, 스크린리더 사용자에게 그 링크는 "정체불명의 링크"일 뿐입니다.

4단계 — 다른 페이지로 가서 푸터 비교

여기가 가장 자주 놓치는 단계입니다. 메인이 아니라 검색 결과 페이지, 신청 페이지, 게시판 상세 페이지 같은 하위 페이지로 가서 똑같이 맨 아래로 내려가 보세요. 푸터가 메인과 똑같이 들어가 있나요? 혹시 축약돼 있거나, 통째로 사라져 있지 않나요? "메인엔 풀 푸터, 서브엔 빈 푸터"가 공공 사이트에서 정말 흔한 함정입니다.

5단계 — 모바일로 보기

휴대폰으로(또는 브라우저 개발자도구의 모바일 모드로) 같은 푸터를 보세요. 정보가 잘리지 않고 다 보이나요? 링크가 손가락으로 누르기에 충분히 크고 떨어져 있나요? 가로 스크롤이 생기진 않나요?

이 다섯 단계만 해봐도 우리 사이트 푸터의 주요 문제 대부분이 드러납니다. 다만 한계가 있습니다 — 사람 눈으로는 "이 영역이 코드상 정말 <footer>로 선언됐는지", "보이는 텍스트와 스크린리더가 읽는 이름이 일치하는지" 같은 건 일일이 확인하기 어렵고, 무엇보다 페이지가 수십·수백 개면 손으로 다 볼 수 없습니다. 그래서 자동 점검이 필요한 겁니다(뒤에서 다룹니다).

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

이제 현업에서 실제로 반복되는 푸터 실수들을 보겠습니다. 모두 익명화한 일반적 사례입니다(특정 기관을 지목하지 않습니다). 우리 사이트에 같은 문제가 있는지 대조하며 읽어 보세요.

실수 1) 푸터가 `<footer>`로 선언되지 않음

가장 근본적인 실수입니다. 시각적으론 완벽한 푸터인데, 코드는 그냥 <div> 덩어리.

• 나쁜 예: <div class="bottom-area"> 안에 정보가 다 들어 있지만, 구조적 의미가 없음. 스크린리더 사용자는 푸터로 바로 점프할 수 없고, 본문을 끝까지 훑어야 도달.
• 올바른 예: <footer>(또는 role="contentinfo")로 영역을 명확히 선언. 보조기술이 "페이지 정보 영역"으로 인식해 단축 탐색 가능.

실수 2) 개인정보처리방침이 없거나 묻혀 있음

공공 사이트의 신뢰성 핵심인데도, 빠져 있거나 다른 링크에 묻혀 있는 경우.

• 나쁜 예: 링크 스무 개가 똑같은 크기·색으로 나열돼 개인정보처리방침이 어디 있는지 한눈에 안 보임. 또는 아예 없음.
• 올바른 예: 개인정보처리방침을 다른 약관과 시각적으로 구분(굵게·강조)하고, 누구나 찾기 쉬운 위치에 배치. 링크 텍스트도 명확하게.

실수 3) 모호한 링크 텍스트

링크는 있는데 "바로가기", "여기", "더보기"처럼 목적지를 알 수 없는 텍스트.

• 나쁜 예: "관련 사이트 바로가기"가 여러 개 나란히. 스크린리더로 링크만 모아 들으면 "바로가기, 바로가기, 바로가기"로 들려 구분 불가.
• 올바른 예: "○○부 누리집(새 창)", "민원 안내 전화 안내"처럼 목적지가 텍스트 자체로 분명. 새 창으로 열리면 그 사실도 명시.

실수 4) 아이콘 링크에 이름 없음

푸터의 SNS 아이콘(유튜브·인스타그램 등)에 텍스트 이름이 없음.

• 나쁜 예: <a><svg>...</svg></a> 끝. 스크린리더는 "링크"로만 읽음. 무슨 SNS인지 알 수 없음.
• 올바른 예: <a aria-label="공식 유튜브 채널(새 창)"><svg aria-hidden="true">...</svg></a>. 링크엔 이름을, 안의 장식 svg는 숨김.

실수 5) 서브 페이지에서 푸터 실종

메인엔 풀 푸터, 하위 페이지엔 축약 또는 누락.

• 나쁜 예: 검색 결과 페이지나 외부 연계 신청 페이지에 푸터가 없어, 사용자가 연락처·정책을 못 찾음. 일관성 붕괴.
• 올바른 예: 모든 페이지에 동일한 푸터 컴포넌트를 공통으로 적용. 한 번 만들어 전 페이지에서 재사용.

실수 6) 색 대비 부족

어두운 배경에 더 어두운 글씨, 또는 너무 연한 회색 글씨.

• 나쁜 예: 짙은 회색 배경에 약간 밝은 회색 글씨. 저시력·고령 사용자에겐 거의 안 보임.
• 올바른 예: 배경과 글자의 명도 대비를 충분히 확보. "보조 정보라 연하게"의 유혹을 절제.

실수 7) 포커스 표시 제거

푸터가 깔끔해 보이게 한다고 링크의 포커스 링을 지움.

• 나쁜 예: 키보드로 푸터를 훑어도 지금 어느 링크에 있는지 안 보임.
• 올바른 예: 포커스 시 또렷한 테두리·외곽선 유지. 본문 링크와 동일한 기준 적용.

실수 8) 모바일에서 깨지는 푸터

데스크톱 기준 다열 구조가 모바일에서 무너짐.

• 나쁜 예: 링크가 가로로 빽빽이 붙어 옆 링크를 잘못 누름. 가로 스크롤 발생. 일부 정보 잘림.
• 올바른 예: 모바일에서 세로로 자연스럽게 재배치하고, 링크 간 간격과 터치 영역(약 44px)을 충분히 확보.

실수 9) 전화번호·이메일이 그냥 텍스트

연락처가 있긴 한데 누를 수도, 구조적으로 인식되지도 않음.

• 나쁜 예: 대표번호가 단순 텍스트라 모바일에서 눌러도 전화 연결 안 됨.
• 올바른 예: 전화번호는 tel:, 이메일은 mailto: 링크로 연결해 모바일에서 바로 사용 가능하게. 레이블도 "대표전화"처럼 명확히.

실수 10) 정보가 이미지(그림)로만 박혀 있음

푸터 전체나 일부(특히 로고·주소 영역)를 이미지 한 장으로 만들어 넣음.

• 나쁜 예: 기관명·주소·연락처가 통째로 이미지라, 스크린리더는 아무것도 못 읽고 검색엔진도 인식 못 함. 확대하면 글자가 흐려짐.
• 올바른 예: 텍스트는 텍스트로. 로고만 이미지로 두되 대체 텍스트를 부여하고, 정보는 실제 텍스트로 작성.

실수 11) 낡은 정보 방치

첫 구축 후 한 번도 갱신하지 않아 옛 주소·옛 조직명·옛 연락처가 남음.

• 나쁜 예: 기관이 이전했는데 푸터엔 옛 주소. 사용자가 잘못된 곳으로 찾아가거나 통화 연결 실패.
• 올바른 예: 조직·주소·연락처 변경 시 푸터도 함께 갱신하는 점검 주기를 둠. 공통 컴포넌트면 한 곳만 고치면 전 페이지 반영.

실수 12) 푸터 안에 본문보다 더 많은 메뉴를 욱여넣기

"이것저것 다 넣자"며 푸터를 거대한 메뉴판으로 만듦.

• 나쁜 예: 수십 개 링크가 평평하게 나열돼 정작 중요한 연락처·정책이 묻힘. 키보드 사용자는 Tab을 수십 번 눌러야 통과.
• 올바른 예: 핵심 정보를 우선 노출하고, 부가 링크는 의미별 그룹으로 정돈. 양보다 "찾기 쉬움"이 우선.

한 장면 — 같은 푸터, 두 사람

추상적인 요건보다 한 장면이 빠를 것 같습니다. 어느 공공 서비스의 민원 페이지, 처리가 막혀서 두 사람이 동시에 "전화로 물어봐야겠다"고 마음먹은 상황입니다.

먼저 마우스를 쓰는 김 주무관. 화면을 쭉 내려 푸터에 도착하고, 한눈에 "대표전화 02-○○○○-○○○○"를 찾아 휴대폰으로 겁니다. 10초도 안 걸렸습니다. 그에게 이 푸터는 아무 문제가 없습니다. 그래서 이 사이트를 만든 팀도 "푸터 잘 만들었다"고 믿습니다. 자기들이 테스트할 때 늘 마우스로 봤으니까요.

이번엔 시각장애가 있는 박 선생님. 스크린리더를 켜고 "푸터로 이동" 단축키를 눌러 봅니다. 그런데 아무 일도 일어나지 않습니다. 이 사이트의 푸터는 <footer>가 아니라 그냥 <div>라, 보조기술이 그곳을 푸터로 인식하지 못하거든요. 박 선생님은 어쩔 수 없이 본문을 처음부터 끝까지 한참 훑어 내려갑니다. 겨우 연락처 영역에 도착했는데, 이번엔 전화번호가 단순 텍스트로만 박혀 있어 그게 "대표전화"인지 "팩스"인지 라벨이 없습니다. 박 선생님은 결국 도움을 청할 통로를 찾지 못하고 민원을 포기합니다.

같은 푸터, 같은 전화번호. 한 사람에겐 10초짜리 비상구이고, 다른 한 사람에겐 닫힌 문입니다. 그리고 이 차이를 메우는 비용은 놀랄 만큼 작습니다. 영역을 <footer>로 감싸고, 전화번호에 "대표전화" 라벨과 tel: 링크를 다는 것. 그러면 박 선생님의 스크린리더도 "페이지 정보 영역, 대표전화 링크"라고 읽어 주고, 김 주무관처럼 10초면 끝났을 겁니다. 차이를 만드는 건 거창한 기술이 아니라, 점검할 때 마우스 사용자만 떠올리지 않는 습관입니다.

또 다른 장면 — 같은 사이트, 다른 페이지

이번엔 한 사람이 같은 사이트 안에서 페이지를 옮겨 다니는 장면입니다. 최 사무관은 어떤 지원 사업의 신청을 하려고 합니다. 메인 페이지에 들어가니 푸터가 잘 정리돼 있습니다. 기관명, 주소, 대표번호, 개인정보처리방침까지 깔끔하게요. "여기 믿을 만하네" 하고 안심합니다.

그런데 "신청하기" 버튼을 눌러 들어간 신청 페이지. 작성하다 막혀서 도움말을 찾으려 맨 아래로 내려갔는데 — 푸터가 없습니다. 회색 띠도, 연락처도, 아무것도. 이 신청 페이지는 외부 시스템으로 연결돼 있어 메인과 다른 템플릿을 쓰고, 거기엔 푸터 컴포넌트가 적용되지 않은 거죠. 최 사무관은 "방금 전 페이지엔 분명 전화번호가 있었는데?" 하며 다시 뒤로 가서 메인 푸터에서 번호를 찾아 적어 옵니다. 한 번의 작은 불편이지만, 이런 불일치가 쌓이면 사용자는 "이 사이트 좀 엉성하네"라는 인상을 받습니다.

이게 바로 "메인은 멀쩡한데 서브가 빈 푸터"의 전형입니다. 그리고 이 문제는 메인 페이지 하나만 점검해서는 절대 안 보입니다. 여러 페이지를 함께 봐야만 드러나죠. 그래서 푸터 점검은 단일 페이지가 아니라 "사이트 전체"를 대상으로 해야 하고, 그게 사람 손으로는 가장 번거로운 부분입니다. 페이지가 100개면 100개의 맨 아래를 다 내려가 봐야 하니까요. 자동 점검이 빛을 발하는 지점이 정확히 여기입니다.

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

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

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소의 html/code 폴더(GitHub KRDS-uiux/krds-uiux)에 헤더·푸터 등 공통 컴포넌트 코드가 들어 있어, 구조적 마크업과 접근성 속성이 이미 갖춰진 상태로 시작할 수 있습니다. 핵심 습관은 단순합니다. 푸터 영역은 반드시 <footer>로 감싸고, 아이콘 링크에는 이름을 주고(aria-label), 전화번호·이메일은 tel:/mailto:로 연결하고, 포커스 표시를 지우지 않는 것. 그리고 푸터는 한 번 컴포넌트로 만들어 전 페이지에서 공통 사용하세요. 그래야 "서브 페이지 푸터 실종" 같은 일관성 문제가 원천 차단됩니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 푸터 컴포넌트를 가져다 배치할 수 있습니다. 직접 그릴 때도 색 대비 기준을 먼저 확인하세요. "보조 정보라 연하게"의 유혹을 누르고, 개인정보처리방침처럼 중요한 링크는 시각적으로 구분되게 강조하세요. 모바일 시안에서 푸터가 어떻게 재배치되는지도 처음부터 함께 설계해야 합니다.

기획자라면 — 화면 정의서에 "푸터"라고만 적지 말고, 들어갈 항목(기관명·주소·대표전화·개인정보처리방침·이용약관·저작권·관련 사이트 등)과 각 링크의 목적지, 새 창 여부까지 명시하세요. 그리고 "모든 페이지 공통 적용"을 명시적으로 적어 두면, 개발·QA 단계에서 서브 페이지 누락을 막을 수 있습니다.

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

앞에서 손으로 하는 5분 점검을 안내했지만, 솔직히 한계가 분명합니다. 페이지가 열 개만 넘어가도 일일이 맨 아래로 내려가 푸터를 비교하기 벅차고, 무엇보다 "이게 코드상 정말 <footer>인지", "보이는 텍스트와 읽히는 이름이 일치하는지" 같은 건 사람 눈으로 확인하기 어렵습니다. 공공 사이트는 페이지가 수십·수백 개인 경우가 대부분이라 더더욱요.

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

ViewCheck가 푸터에 대해 자동으로 보는 것들:

• 구조 선언 여부: 푸터 영역이 <footer>(또는 role="contentinfo")로 선언돼 보조기술이 인식할 수 있는지
• 필수 정보 존재: 개인정보처리방침·이용약관·접근성 정책 같은 핵심 링크가 있는지(개방성·신뢰성 분석과 연계)
• 링크 접근성: 푸터 링크의 텍스트가 명확한지, 아이콘 링크에 이름이 있는지
• 일관성: 여러 페이지를 한꺼번에 분석해, 서브 페이지에서 푸터가 누락·축약되지 않았는지
• 대비·터치 영역: 푸터 텍스트의 색 대비와 모바일 링크의 터치 영역이 기준을 충족하는지(반응형·대비 분석과 연계)

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

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 푸터 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "신청 페이지의 푸터가 <footer>로 선언되지 않음"이나 "푸터 SNS 아이콘 링크 3개 중 2개가 이름 미연결"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인 푸터는 멀쩡한데 검색 페이지 푸터에는 개인정보처리방침이 빠졌다" 같은 페이지별 편차가 한눈에 드러납니다. 그리고 어디부터 고쳐야 하는지 우선순위(P0~P3)가 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다.

손으로 하는 5분 점검이 "감기 자가진단"이라면, ViewCheck는 "전 페이지 정밀 건강검진"이라고 보시면 됩니다. 둘은 대체재가 아니라 짝입니다 — 손 점검으로 감을 잡고, ViewCheck로 빠짐없이 확인하는 거죠.

자주 묻는 질문

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

Q. 푸터에 정보가 다 들어 있으면, `<footer>`로 안 감싸도 상관없지 않나요?

시각적으로는 상관없어 보이지만, 접근성 관점에서는 큰 차이가 있습니다. <footer>(또는 role="contentinfo")로 선언돼 있어야 스크린리더 사용자가 "페이지 정보 영역으로 이동" 같은 단축 탐색으로 푸터에 바로 점프할 수 있습니다. 선언이 없으면 본문을 끝까지 훑어야만 연락처·정책에 닿습니다. "정보가 있느냐"와 "쉽게 닿을 수 있느냐"는 다른 문제입니다.

Q. 개인정보처리방침은 푸터에 꼭 있어야 하나요? 다른 메뉴에 있으면 안 되나요?

다른 곳에도 있을 수 있지만, 사용자가 가장 먼저 찾는 곳이 푸터이기 때문에 관례적으로 푸터에 두는 게 표준입니다. 게다가 개인정보처리방침은 공공 사이트 신뢰성의 핵심이라, 푸터에서 다른 약관과 구분되게(보통 굵게) 강조해 두는 게 좋습니다. "어딘가에 있다"보다 "예상되는 자리에서 바로 찾인다"가 사용자 경험을 가릅니다.

Q. 푸터 링크가 너무 많은데, 다 넣는 게 좋을까요?

무조건 많이 넣는 게 좋은 건 아닙니다. 핵심은 "사용자가 정말 찾는 것"(기관 정보, 연락처, 개인정보처리방침, 주요 정책)을 명확히 노출하는 것이고, 나머지 부가 링크는 의미별로 그룹화해 정돈하는 게 좋습니다. 링크가 스무 개씩 평평하게 나열되면 정작 중요한 게 묻힙니다. 그룹 제목(예: "정책 안내", "관련 기관")으로 묶으면 스크린리더 사용자도 구조를 파악하기 쉽습니다.

Q. SNS 아이콘만 있는 링크, 꼭 텍스트 이름이 필요한가요?

네. 시각적으로는 유튜브·인스타그램 아이콘이 익숙해도, 스크린리더 사용자에게는 코드상 이름이 없으면 그냥 "링크"로만 읽힙니다. aria-label="공식 유튜브 채널(새 창)"처럼 이름을 붙여야 어디로 가는 링크인지 알 수 있습니다. 그리고 안의 그림 SVG는 aria-hidden="true"로 숨겨 중복 낭독을 막으면 더 깔끔합니다.

Q. 메인 페이지 푸터만 잘 만들면, 서브 페이지는 자동으로 같아지지 않나요?

컴포넌트로 만들어 공통 적용했다면 그렇습니다. 문제는 많은 사이트가 페이지마다 푸터를 따로 붙이거나, 외부 시스템으로 연결된 일부 페이지에 푸터를 안 넣는다는 점입니다. 그래서 "메인은 멀쩡한데 서브는 빈 푸터"가 생깁니다. 푸터를 하나의 공통 컴포넌트로 만들어 모든 페이지에서 재사용하는 게 근본 해법이고, ViewCheck로 여러 페이지를 분석하면 이 누락을 자동으로 잡아냅니다.

Q. 푸터 배경을 어둡게 하고 글씨를 회색으로 했더니 차분해 보이는데, 문제 있나요?

디자인 취향으로는 괜찮지만, 글자와 배경의 명도 대비가 충분한지 꼭 확인해야 합니다. 차분해 보이려고 대비를 낮추면, 저시력·고령 사용자에게는 푸터 정보가 흐릿하게 보여 읽기 어려워집니다. 특히 푸터에는 연락처·정책처럼 중요한 정보가 들어가므로, 대비는 양보하면 안 되는 항목입니다. 색감은 유지하되 명도를 조정해 대비 기준을 맞추세요.

Q. 전화번호를 그냥 텍스트로 적으면 안 되나요?

적어도 정보 전달은 되지만, 모바일에서는 tel: 링크로 연결해 두면 바로 전화를 걸 수 있어 훨씬 편합니다. 마찬가지로 이메일은 mailto:로 연결하면 좋습니다. 그리고 "대표전화", "팩스"처럼 라벨을 분명히 해 두면, 스크린리더 사용자도 그 번호가 무엇인지 알 수 있습니다. 숫자만 덜렁 있으면 무슨 번호인지 알기 어렵습니다.

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

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "지금 어느 페이지의 푸터가, 무슨 문제를 일으키는지"를 목록으로 만든 다음, 우선순위대로 치명적인 것부터 고치면 됩니다. 특히 푸터를 공통 컴포넌트로 묶어 두면, 한 번 고친 게 전 페이지에 반영돼 효율이 큽니다. 리뉴얼 예산을 한 번에 들이지 않고도 점진적으로 개선할 수 있습니다.

Q. 손으로 하는 5분 점검과 ViewCheck, 둘 중 하나만 하면 안 되나요?

둘은 역할이 다릅니다. 손 점검은 "지금 당장 감을 잡는" 데 좋고, 디자이너·기획자가 회의 중에도 바로 해볼 수 있습니다. 하지만 페이지가 많거나 코드 수준 검증(구조 선언, 이름 일치)이 필요하면 사람 눈으로는 한계가 있습니다. ViewCheck는 그 빈틈을 메웁니다. 가장 좋은 건 손 점검으로 익숙해진 뒤, ViewCheck로 전 페이지를 빠짐없이 확인하는 조합입니다.

Q. 푸터에 사이트맵을 꼭 넣어야 하나요?

필수는 아니지만, 푸터의 사이트맵(또는 주요 메뉴 요약)은 사용자가 길을 잃었을 때 전체 구조를 한눈에 보게 해 주는 좋은 보조 장치입니다. 특히 메뉴가 많은 공공 사이트라면 푸터 사이트맵이 탐색을 크게 도와줍니다. 다만 넣을 거라면 그룹 제목으로 정돈해 스크린리더 사용자도 구조를 파악할 수 있게 하세요. 무질서하게 링크만 쏟아 놓으면 오히려 부담이 됩니다.

Q. 푸터 정보가 본문과 중복되면 스크린리더가 두 번 읽지 않나요?

푸터는 본문과 역할이 다른 보조 영역이라, <footer>로 분리돼 있으면 사용자가 본문과 푸터를 구분해 탐색할 수 있습니다. 중복이 신경 쓰인다면, 본문에 이미 있는 정보를 푸터에 또 강조하기보다 푸터에는 "어디서나 필요한 공통 정보"만 두는 식으로 역할을 나누면 됩니다. 핵심은 구조적 분리이지, 정보를 줄이는 게 아닙니다.

Q. 다국어 사이트인데 푸터도 번역해야 하나요?

네. 외국인 사용자가 영문 페이지에서 도움을 청할 때도 푸터의 연락처·정책에 닿을 수 있어야 합니다. 영문 푸터에 한글 정책 링크만 있으면 그 사용자에게는 막힌 통로입니다. 언어별로 푸터 정보를 함께 제공하되, 각 푸터도 동일하게 <footer> 구조·접근성 요건을 지켜야 합니다.

Q. 푸터 점검 결과를 보고서로 만들어 보고해야 하는데, ViewCheck가 도움이 되나요?

됩니다. ViewCheck는 분석 결과를 PDF·Excel 리포트로 정리해 주는데, 컴포넌트 탭의 푸터 관련 판정과 페이지별 편차, 우선순위(P0~P3)가 함께 담깁니다. "어느 페이지 푸터에 무슨 문제가 있고, 무엇부터 고쳐야 하는지"가 정리돼 나오니, 그대로 개선 계획 보고 자료로 쓰기 좋습니다. 막연한 "푸터 개선 필요"가 아니라 근거가 붙은 작업 목록이 되는 셈입니다.

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

손 점검이든 ViewCheck든, 한번 돌려 보면 보통 푸터 문제가 한두 개로 끝나지 않습니다. 페이지가 많을수록 "고칠 게 많다"는 압박감이 듭니다. 그래서 우선순위가 중요합니다. 푸터 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 개인정보처리방침이 아예 없는 경우, 그리고 푸터가 <footer>로 선언되지 않아 스크린리더 사용자가 핵심 정보에 닿기 어려운 경우. 전자는 신뢰성·법적 요건, 후자는 접근권의 문제라 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) → 검증된 코드로 고치는(킷) 한 바퀴가 완성됩니다.

오늘의 체크리스트 — 푸터, 이것만은

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

• ☐ 푸터 영역이 `<footer>`(또는 role="contentinfo")로 선언돼 있다.
• ☐ 기관명·주소·대표 연락처가 분명히 들어 있다.
• ☐ 개인정보처리방침 링크가 있고, 다른 링크와 구분되게 강조돼 있다.
• ☐ 저작권 표시가 있고 운영 주체가 분명하다.
• ☐ 푸터 링크의 텍스트가 목적지를 명확히 설명한다("바로가기/여기" 같은 모호한 표현 없음).
• ☐ 새 창으로 열리는 링크는 새 창 사실을 알린다.
• ☐ 아이콘 링크(SNS 등)에 이름(aria-label 등)이 있고, 장식 SVG는 숨김 처리됐다.
• ☐ 전화번호·이메일이 tel:/mailto:로 연결되고 라벨이 명확하다.
• ☐ 키보드만으로 모든 푸터 링크에 도달 가능하고, 포커스 표시가 또렷하다.
• ☐ 푸터 텍스트와 배경의 명도 대비가 충분하다.
• ☐ 모든 페이지(메인·검색·신청·상세)에 동일한 푸터가 들어가 있다.
• ☐ 모바일에서 정보가 잘리지 않고, 링크 터치 영역이 충분하다(약 44px 이상).

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

푸터는 작아 보이고 맨 아래에 있어 평소엔 눈에 안 띄지만, 사용자가 신뢰를 확인하고 도움을 청하는 결정적 순간에 가장 먼저 찾는 곳입니다. 그 회색 띠 하나가 누군가에겐 "이 사이트 믿어도 되겠다"는 안심이고, 또 누군가에겐 "전화 한 통 걸 통로"입니다. 우리가 무심코 넘긴 푸터 하나가, 누군가에게는 그 볼일을 혼자 끝낼 수 있느냐 없느냐를 가릅니다.

오늘 정리한 점검 항목이 많아 보일 수 있지만, 핵심은 결국 단순합니다. 필수 정보를 넣고, <footer>로 선언하고, 링크에 이름을 주고, 모든 페이지에 일관되게 넣고, 검증된 코드를 쓰는 것. 이 다섯 가지만 챙겨도 푸터의 위반 대부분은 사라집니다. 그리고 그게 잘 됐는지는, 오늘 안내한 5분 손 점검으로 감을 잡고 ViewCheck로 전 페이지를 확인하면 됩니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 치명적인 것 하나부터 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 많은 사람에게 열립니다. 다음 글에서는 푸터와 짝을 이루는 또 다른 공통 컴포넌트를 같은 방식으로 뜯어보겠습니다.

우리 사이트의 푸터는 지금 몇 점일까요? krds.viewcheck.co.kr에서 URL만 넣으면 무료로 확인할 수 있습니다. 메인 페이지 하나만 돌려 봐도, 위 체크리스트가 실제로 지켜지고 있는지 — 그리고 서브 페이지에서 푸터가 빠지진 않았는지 — 바로 보입니다.

#KRDS #공공웹 #디자인시스템 #푸터Footer #웹접근성 #ViewCheck #정부웹사이트 #UIUX #꼬리말 #개인정보처리방침 #자가진단 #푸터 #Footer #체크리스트 #점검항목 #UI컴포넌트 #컴포넌트설계 #전자정부 #디지털정부 #행정안전부