푸터(Footer) — 공공웹이 자주 틀리는 지점

공공 사이트에서 무언가를 찾다가 길을 잃은 적이 한 번쯤 있으실 겁니다. 메뉴를 다 뒤져도 안 나오고, 검색을 해도 엉뚱한 게 뜨고, 그러다 막막한 마음에 페이지를 끝까지 쭉 내립니다. 그 맨 아래, 화면 가장 밑바닥에 작은 글씨로 빼곡히 적힌 영역이 하나 있죠. 기관 주소, 대표 전화번호, 개인정보처리방침, 이용약관, 사업자등록번호, 그리고 정체불명의 인증 마크 몇 개. 우리는 그걸 "푸터"라고 부르고, 대부분 그냥 스쳐 지나갑니다. 그런데 정작 급할 때 — 담당 부서 전화번호가 필요할 때, 개인정보 처리 방침을 확인해야 할 때, 우리 정보가 어떻게 쓰이는지 따지고 싶을 때 — 우리가 마지막으로 손을 뻗는 곳이 바로 이 푸터입니다.

푸터는 웹사이트에서 가장 저평가된 영역입니다. 화려하지도 않고, 사용자가 매번 보지도 않고, 그래서 만드는 사람도 "대충 정보만 박아 넣으면 되는 곳"으로 취급하기 쉽습니다. 그런데 공공 웹사이트를 수백 개 분석하다 보면, 이 "대충 만든 푸터"에서 똑같은 실수가 끝없이 반복되는 걸 봅니다. 연락처가 없거나, 개인정보처리방침 링크가 깨졌거나, 화면에 보이는 글씨를 스크린리더는 못 읽거나, 모바일에서 글자가 손톱만 하게 쪼그라들어 아무도 누를 수 없거나. 이 글은 KRDS(대한민국 정부 디자인 시스템)가 정의하는 푸터(Footer)를 기준으로, 공공웹이 푸터에서 가장 많이 틀리는 지점을 익명 사례로 하나하나 뜯어보는 글입니다.

현업에서 보면, 푸터는 화면 정의서의 마지막 한 줄로 처리되는 경우가 많습니다. "하단에 기관 정보 푸터"라고만 적혀 있고, 디자인에서는 회색 배경에 글씨 몇 줄로 그려지고, 개발에서는 다른 페이지의 푸터를 복사-붙여넣기로 끝냅니다. 이 과정 어디에서도 "이 연락처가 맞나", "이 링크가 살아 있나", "스크린리더가 이걸 읽나", "모바일에서 누를 수 있나"를 따지지 않습니다. 그 결과가 우리가 매일 스쳐 지나가는, 잘못된 정보로 가득한 푸터들입니다.

한 가지 더 솔직히 말하면, 푸터는 "잘 만들어도 칭찬받지 못하는" 영역입니다. 정보를 정확하게 정리하고 링크를 다 살려 놓아도, 사용자 눈엔 그냥 평범한 하단 영역일 뿐이죠. 칭찬받기는 어렵고 욕먹기는 쉬운, 좀 억울한 자리입니다. 그래서 더 방치됩니다. "어차피 아무도 안 보는데"라는 유혹이 늘 따라붙거든요. 하지만 아무도 안 본다는 건 잘 작동할 때 얘기고, 정작 누군가 절박하게 그 정보를 찾을 때 푸터가 비어 있거나 틀려 있으면, 그건 그 사람에게 그날의 가장 큰 장벽이 됩니다. 이 글이 "푸터는 대충"이라는 습관을 한 번쯤 멈춰 세우는 계기가 되면 좋겠습니다.

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

먼저 용어부터 맞추겠습니다. 푸터(Footer)는 웹 페이지의 가장 아래에 위치하는 영역으로, 그 사이트나 그 페이지에 대한 부가 정보와 공통 정보를 담는 곳입니다. 본문이 "지금 이 페이지에서 해야 할 일"을 담는다면, 푸터는 "이 사이트 전체에 공통으로 필요한 것들"을 담습니다.

KRDS는 푸터를 단순한 장식 영역이 아니라, 정해진 역할을 가진 컴포넌트로 다룹니다. 헤더(Header)가 사이트의 머리라면, 푸터는 사이트의 발입니다. 그리고 이 발에는 보통 다음과 같은 것들이 들어갑니다.

기관 정보: 기관명, 주소, 대표 전화번호, 팩스, 사업자등록번호 등
정책·법적 링크: 개인정보처리방침, 이용약관, 저작권 정책, 이메일무단수집거부 등
보조 내비게이션: 관련 사이트, 주요 메뉴 바로가기, 사이트맵
저작권 표시(copyright): 콘텐츠의 권리 귀속 정보
인증·관련 마크: 웹 접근성 인증 마크, 관련 기관 배너 등

여기서 중요한 건, 푸터가 단순히 "정보 덩어리"가 아니라 구조를 가진 영역이라는 점입니다. 웹 표준에서 푸터는 <footer>라는 의미 있는(시맨틱) 태그로 표현되고, 보조기술은 이걸 페이지의 "콘텐츠 정보(contentinfo)" 영역으로 인식합니다. 스크린리더 사용자는 이 영역 표시 덕분에 "아, 여기가 하단 정보 영역이구나" 하고 바로 점프할 수 있습니다. 푸터가 <footer>가 아니라 그냥 <div> 덩어리면, 이 점프가 안 됩니다. 모양은 푸터인데 코드는 푸터가 아닌, "가짜 푸터"가 되는 거죠. 이 이야기는 뒤에서 자세히 다루겠습니다.

헤더의 거울상이지만, 역할은 다르다

푸터를 두고 흔히 "헤더의 짝꿍" 정도로 생각합니다. 위아래로 대칭이니까요. 하지만 역할은 분명히 다릅니다.

헤더는 사용자가 앞으로 무엇을 할지 안내합니다. 로고, 주 메뉴, 검색, 로그인. 즉 행동의 시작점이죠. 반면 푸터는 사용자가 막혔을 때, 혹은 확인이 필요할 때 손을 뻗는 곳입니다. "여기 담당이 어디지?", "이 사이트 운영 기관이 진짜 그 기관 맞나?", "내 정보를 어떻게 처리한다고 했지?" 이런 질문에 답하는 곳입니다.

그래서 푸터에서 정보가 틀리면, 헤더에서 메뉴가 틀린 것과는 다른 종류의 피해가 생깁니다. 헤더의 메뉴 오류는 "다른 길로 돌아가면" 해결되지만, 푸터의 연락처 오류는 사용자가 그 잘못된 번호로 전화를 걸어 엉뚱한 곳에 연결되고, 다시 검색하고, 결국 민원을 포기하게 만듭니다. 작아 보이는 영역이지만, 신뢰의 마지막 보루라는 점에서 무게가 다릅니다.

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

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서를 기준으로, 푸터가 충족해야 하는 요건을 영역별로 정리하겠습니다. KRDS는 푸터를 컴포넌트로 정의하고, 공식 컴포넌트 킷(GitHub KRDS-uiux/krds-uiux)에 푸터 코드를 제공합니다. "알아서 만드세요"가 아니라 "이 구조를 따르세요"라는 기준이 있다는 뜻입니다.

1) 시맨틱 구조 — 푸터는 `<footer>`여야 한다

가장 기본이면서 가장 자주 깨지는 요건입니다. 푸터는 코드 수준에서 <footer> 시맨틱 태그로 선언돼야 합니다. 이게 있어야 보조기술이 이 영역을 "콘텐츠 정보 영역"으로 인식하고, 스크린리더 사용자가 단축키로 바로 점프할 수 있습니다.

웹 표준으로 말하면, 페이지 최상위에 위치한 <footer>는 자동으로 contentinfo라는 랜드마크(landmark) 역할을 갖습니다. 랜드마크는 페이지를 큰 구역으로 나눠 주는 이정표 같은 것입니다. 시각장애인 사용자는 페이지를 처음부터 끝까지 듣는 대신, "랜드마크 목록"을 불러내 "헤더 → 주 메뉴 → 본문 → 푸터"를 한 번에 훑고 원하는 곳으로 바로 갑니다. 푸터가 <footer>가 아니라 <div class="footer">면 이 이정표가 사라지고, 사용자는 푸터에 닿기 위해 본문을 전부 통과해야 합니다.

2) 기관 정보 — 정확하고, 최신이고, 읽힐 수 있게

푸터의 핵심 콘텐츠는 기관 정보입니다. 기관명, 주소, 대표 전화번호 같은 것들이죠. KRDS는 이 정보가 단순히 "있다"가 아니라 정확하고 최신이어야 함을 전제합니다. 당연한 말 같지만, 실제로 가장 많이 깨지는 부분입니다. 기관이 이전했는데 옛 주소가 그대로거나, 부서 통폐합으로 전화번호가 바뀌었는데 옛 번호가 남아 있는 식이죠.

그리고 이 정보들은 텍스트로 제공돼야 합니다. 디자인을 깔끔하게 한답시고 주소나 연락처를 이미지로 박아 넣으면, 스크린리더가 못 읽고, 복사도 안 되고, 사용자가 확대해도 흐려집니다. 전화번호 같은 정보는 텍스트로 두어야 모바일에서 탭 한 번에 전화 걸기로 이어질 수도 있습니다.

3) 정책·법적 링크 — 빠짐없이, 살아 있게

개인정보처리방침, 이용약관, 저작권 정책 같은 법적·정책 링크는 공공 웹사이트에서 단순한 옵션이 아닙니다. 특히 개인정보처리방침은 개인정보 보호 관련 법령상 사용자가 쉽게 찾을 수 있는 위치에 두어야 하는 항목이고, 그 위치가 바로 푸터입니다.

KRDS 관점에서 이 링크들은 ① 존재해야 하고, ② 올바른 페이지로 연결돼야 하며, ③ 링크 텍스트가 명확해야 합니다. "여기를 클릭"이 아니라 "개인정보처리방침"이라고 적혀 있어야, 스크린리더 사용자가 링크 목록만 훑어도 무엇으로 가는 링크인지 압니다. 그리고 개인정보처리방침은 다른 약관들 사이에서 시각적으로도 구분되게(예: 굵게) 두는 것이 일반적인 권장 패턴입니다 — 가장 중요한 법적 고지이기 때문입니다.

4) 저작권·운영 주체 표시

페이지 콘텐츠의 권리가 누구에게 있는지(copyright), 이 사이트를 누가 운영하는지를 푸터에 명시합니다. 이건 신뢰성 문제와 직결됩니다. 사용자가 "이 사이트가 사칭이 아니라 진짜 그 기관 사이트인지"를 확인하는 마지막 단서가 푸터의 운영 주체 표시이기 때문입니다. 피싱·사칭 사이트는 종종 이 부분이 비어 있거나 어색합니다.

5) 키보드 접근성 — 모든 링크가 키보드로 닿아야 한다

푸터에는 링크가 많습니다. 그 모든 링크가 키보드의 Tab 키만으로 순서대로 닿을 수 있어야 하고, 닿았을 때 지금 어디에 초점(focus)이 있는지 시각적으로 보여야 합니다. 마우스 없이 키보드만 쓰는 사용자, 손 사용이 불편한 사용자에게 이건 타협 불가능한 요건입니다.

여기서 자주 깨지는 게 두 가지입니다. 하나는 초점 표시를 CSS outline: none으로 지워 버리는 것. 키보드 사용자는 자기가 푸터의 어느 링크에 와 있는지 알 수 없게 됩니다. 다른 하나는 화면엔 안 보이지만 코드엔 남아 있는 "유령 링크"가 Tab 순서에 끼어드는 것. 옛 메뉴를 display:none이 아니라 화면 밖으로만 밀어 놓으면, 키보드 사용자는 보이지도 않는 링크들을 하나하나 통과해야 합니다.

6) 반응형 — 모바일에서도 무너지지 않게

푸터는 데스크톱에서 여러 열(컬럼)로 정보를 늘어놓다가, 모바일에서 한 열로 접히는 경우가 많습니다. 이 과정에서 자주 사고가 납니다. 글자가 너무 작아지거나, 링크들이 다닥다닥 붙어 손가락으로 정확히 누르기 어려워지거나, 가로 스크롤이 생기거나.

한국형 웹 접근성 지침(KWCAG)과 국제 표준 모두 터치 대상의 최소 크기를 권장합니다 — 일반적으로 한 변 44px 이상을 기준으로 삼습니다. 푸터의 링크도 예외가 아닙니다. 특히 정책 링크나 SNS 아이콘처럼 작게 그려지기 쉬운 요소일수록, 누를 수 있는 영역은 충분히 확보해야 합니다.

7) 인증 마크·아이콘 — 의미가 있으면 이름을, 장식이면 숨김을

푸터에는 웹 접근성 인증 마크, 관련 기관 배너, SNS 아이콘 같은 이미지가 자주 들어갑니다. 이것들은 두 갈래로 나눠 다뤄야 합니다. 의미를 전달하는 이미지(예: 클릭하면 SNS로 가는 아이콘, 인증 정보를 담은 마크)는 대체 텍스트로 그 의미를 알려야 하고, 순수 장식은 스크린리더가 무시하도록(aria-hidden) 처리해야 합니다. 이걸 안 하면, 의미 있는 마크는 못 읽히고 장식 이미지는 "이미지, 이미지, 이미지"로 시끄럽게 읽힙니다.

정리하면, KRDS의 푸터 기준은 크게 세 축입니다. ① 정확성(기관 정보·정책 링크가 맞고 최신일 것), ② 구조성(<footer> 시맨틱으로 선언되고 랜드마크로 인식될 것), ③ 접근성(키보드·스크린리더·모바일에서 모두 쓸 수 있을 것). 이 세 축은 그대로 ViewCheck가 푸터를 판정하는 기준이기도 합니다.

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

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

공공 서비스의 푸터는 "최후의 안내소"다

상업 사이트의 푸터가 비어 있으면, 사용자는 불편하지만 경쟁사로 가면 그만입니다. 그런데 공공 서비스는 다릅니다. 주민등록 등본을 떼거나, 보조금을 신청하거나, 민원을 넣는 일은 그 사이트가 아니면 할 수 없습니다. 사용자가 본문에서 길을 잃었을 때 마지막으로 기댈 곳이 푸터의 연락처와 안내인데, 그게 틀려 있으면 사용자는 갈 곳이 없어집니다.

거주 지역 담당 부서 전화번호가 푸터에 잘못 적혀 있으면, 어르신은 그 번호로 전화를 걸어 한참 헤매다 통화에 실패합니다. 개인정보처리방침 링크가 깨져 있으면, 자기 정보가 어떻게 쓰이는지 확인하려던 사용자는 그 권리를 행사할 수 없습니다. 이게 KRDS가 푸터의 정보 정확성과 링크 유효성을 "있으면 좋은 것"이 아니라 "기본 요건"으로 두는 이유입니다.

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

비장애인은 화면을 "본다"고 생각하지만, 사실 우리는 화면을 보고 머릿속에서 의미로 번역합니다. 회색 배경에 작은 글씨가 줄지어 있으면 "아, 푸터구나" 하고 짐작하죠. 스크린리더 사용자에게는 이 짐작 과정이 없습니다. 코드가 알려 주는 정보가 곧 전부입니다.

그래서 푸터는 "보기에 푸터 같은 것"으로는 부족하고, "코드 수준에서 푸터라고 선언된 것"이어야 합니다. <div>에 회색 배경을 깔아 푸터처럼 보이게 만들어도, 코드가 그걸 "콘텐츠 정보 영역"이라고 말해 주지 않으면 스크린리더에겐 그냥 본문의 연장일 뿐입니다. 그리고 그 안의 주소가 이미지로 들어가 있으면, 시각장애인 사용자는 기관 주소를 영영 알 수 없습니다. 이 "보이는 것 ≠ 읽히는 것" 문제가 푸터 위반의 근본 원인 상당수를 차지합니다.

푸터는 사이트 전체의 신뢰 지표다

심리학적으로, 사람은 무언가를 신뢰할지 판단할 때 "디테일"을 봅니다. 명함의 모서리가 구겨져 있으면 그 사람을 살짝 의심하게 되듯, 웹사이트의 푸터가 엉성하면 사이트 전체를 의심하게 됩니다. 연락처가 비어 있고, 링크가 깨져 있고, 저작권 연도가 몇 년 전에 멈춰 있는 푸터를 보면, 사용자는 무의식적으로 "이 사이트 관리가 안 되는구나" 하고 느낍니다.

공공 서비스에서 이 신뢰는 특히 중요합니다. 사칭·피싱 사이트가 정부 사이트를 흉내 낼 때 가장 어설프게 따라 하는 게 바로 푸터이기 때문입니다. 진짜 기관 사이트는 정확한 운영 주체, 정확한 사업자 정보, 살아 있는 정책 링크를 갖춰야 사용자가 "이게 진짜다"라고 안심합니다. 푸터를 잘 갖추는 건 곧 사칭과 진짜를 구별하는 단서를 사용자에게 주는 일입니다.

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

역설적이지만, 푸터처럼 "맨 아래의 안 보이는" 영역일수록 품질 관리에서 밀려납니다. 메인 비주얼이나 핵심 기능에는 모두가 눈을 부릅뜨지만, 화면 맨 밑의 회색 영역에는 아무도 깐깐하게 굴지 않거든요. 게다가 푸터는 모든 페이지에 공통으로 들어가다 보니, 한 번 잘못 만들면 그 오류가 사이트 전체에 복제됩니다. 한 페이지의 본문 오류는 그 페이지 하나의 문제지만, 푸터 오류는 수백 페이지 전체의 문제가 됩니다. 가장 덜 주목받는 영역이 사실은 사이트 전체에 가장 광범위하게 영향을 미치는 셈입니다.

일관성이 곧 학습 비용 절감

KRDS가 푸터 구조를 표준화하는 또 다른 이유는 일관성입니다. 정부 사이트마다 푸터의 정보 배치가 제각각이면, 사용자는 사이트를 옮길 때마다 "개인정보처리방침이 어디 있지?"를 다시 찾아야 합니다. 모든 공공 서비스의 푸터가 비슷한 자리에 비슷한 정보를 두면, 한 번 익힌 위치가 모든 사이트에서 통합니다. "전화번호는 푸터 왼쪽 위, 정책 링크는 그 아래"가 일관되면, 디지털에 익숙하지 않은 사용자도 헤매지 않습니다. 표준화는 디자이너의 자유를 뺏는 게 아니라, 사용자의 인지 부담을 덜어 주는 일입니다.

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

이제 이 글의 핵심입니다. 현업에서 실제로 반복되는 푸터 실수들을 보겠습니다. 모두 익명화한 일반적 사례입니다(특정 기관을 지목하지 않습니다). 수백 개 공공 사이트를 분석하면서 가장 자주 마주친 순서대로 정리했습니다.

위반 1) "가짜 푸터" — `<div>`로 만든 푸터 모양

가장 흔하고 가장 근본적인 실수입니다. 화면엔 분명히 푸터가 있는데, 코드를 열어 보면 <footer>가 아니라 그냥 <div class="footer"> 덩어리입니다. 보기엔 똑같습니다. 그런데 스크린리더는 이걸 "콘텐츠 정보 영역"으로 인식하지 못하고, 랜드마크 점프가 안 됩니다.

나쁜 예: <div id="footer"> 안에 주소·링크·저작권을 다 넣고 끝. 시맨틱 태그 없음. 스크린리더 사용자는 푸터로 바로 가지 못하고 본문을 전부 통과해야 함.
올바른 예: 페이지 하단을 <footer> 태그로 감싸기. 필요하면 그 안의 보조 메뉴를 <nav aria-label="하단 메뉴">로 추가 구조화. KRDS 컴포넌트 킷의 푸터 코드는 이 구조가 이미 잡혀 있음.

이 실수가 무서운 건, 보기엔 완벽해서 "문제없다"고 믿게 된다는 점입니다. 마우스 사용자에겐 정말 아무 문제가 없거든요. 코드를 직접 들여다보거나 스크린리더로 확인하기 전엔 드러나지 않습니다.

위반 2) 연락처·기관 정보 누락 또는 오류

푸터에 가장 들어 있어야 할 정보가 정작 빠져 있는 경우입니다. 대표 전화번호가 없거나, 주소가 옛것이거나, 담당 부서 정보가 없습니다.

나쁜 예: 저작권 표시만 한 줄 덩그러니. "© ○○기관" 외엔 연락처도 주소도 없음. 사용자가 문의할 방법이 없음.
올바른 예: 기관명·주소·대표 전화·이메일을 텍스트로 명시하고, 정기적으로 최신 여부를 점검. 부서 개편이나 이전이 있을 때 푸터 정보도 함께 갱신하는 운영 프로세스를 둠.

특히 자주 보는 게 "기관이 이전했는데 푸터 주소는 그대로"인 경우입니다. 푸터는 모든 페이지에 복제되기 때문에, 한 번 갱신을 빠뜨리면 사이트 전체가 옛 정보를 노출하게 됩니다.

위반 3) 개인정보처리방침 링크 누락 또는 깨짐

공공 웹사이트에서 개인정보처리방침은 사용자가 쉽게 찾을 수 있어야 하는 필수 항목입니다. 그런데 이 링크가 아예 없거나, 클릭하면 404(없는 페이지)가 뜨거나, 엉뚱한 페이지로 가는 경우가 의외로 많습니다.

나쁜 예: 개인정보처리방침 링크가 없음. 또는 있지만 클릭하면 "페이지를 찾을 수 없습니다". 사용자는 자기 정보 처리 방침을 확인할 길이 없음.
올바른 예: 개인정보처리방침을 푸터에 명확한 링크 텍스트로 두고, 다른 약관과 시각적으로 구분(예: 굵게). 링크가 실제로 살아 있는지 정기 점검. 이용약관·저작권 정책 등 다른 법적 링크도 함께 유효성 확인.

링크는 "한 번 만들어 두면 영원히 작동"하지 않습니다. 페이지 구조가 바뀌면 URL이 변하고, 그 변화가 푸터 링크에 반영되지 않으면 조용히 깨집니다. 사람이 매번 모든 페이지의 모든 링크를 클릭해 확인하기는 불가능에 가깝습니다.

위반 4) 정보를 이미지로 박아 넣기

깔끔한 디자인을 위해, 또는 디자인 시안을 그대로 옮기려고 주소·연락처·인증 마크 정보를 텍스트가 아니라 이미지로 넣는 경우입니다.

나쁜 예: 기관 주소와 전화번호가 통째로 하나의 이미지. 스크린리더가 못 읽고, 복사도 안 되고, 확대하면 흐려짐. 검색 엔진도 이 정보를 못 읽음.
올바른 예: 모든 텍스트 정보는 진짜 텍스트로. 로고처럼 꼭 이미지여야 하는 것에는 의미를 담은 대체 텍스트(alt) 부여. 인증 마크 이미지에도 그것이 무엇인지 alt로 명시.

이미지 텍스트는 "보이는 것과 읽히는 것의 분리" 문제의 전형입니다. 눈으로 보는 사람에겐 멀쩡한데, 음성으로 듣는 사람에겐 존재하지 않는 정보가 됩니다.

위반 5) 정체불명의 인증 마크와 alt 누락

푸터에 늘어선 인증 마크와 배너들. 그런데 이 이미지들에 대체 텍스트가 없으면, 스크린리더는 그저 "이미지" 혹은 파일명(logo_01.png)을 읽습니다.

나쁜 예: 인증 마크 5개가 alt 없이 나열. 스크린리더 사용자는 "이미지 이미지 이미지…"만 들음. 무슨 마크인지 알 수 없음.
올바른 예: 의미 있는 마크에는 그 의미를 alt로("○○ 인증"). 단순 장식 이미지는 aria-hidden 또는 빈 alt(alt="")로 스크린리더가 건너뛰게 함. 의미와 장식을 구분해서 처리.

위반 6) 초점 표시 제거와 유령 링크

푸터에는 링크가 많은데, 키보드 접근성이 자주 깨집니다.

나쁜 예: outline: none으로 포커스 링을 지워, 키보드 사용자가 지금 어느 링크에 있는지 모름. 혹은 화면 밖으로 밀어 둔 옛 메뉴가 Tab 순서에 끼어들어, 보이지도 않는 링크를 하나하나 통과해야 함.
올바른 예: 포커스 시 또렷한 외곽선 유지. 숨길 링크는 display:none이나 적절한 방법으로 Tab 순서에서도 제외. 보이는 것과 키보드로 닿는 것을 일치시킴.

위반 7) 모바일에서 무너지는 레이아웃

데스크톱 기준으로만 만들고 모바일을 확인하지 않아, 푸터가 작은 화면에서 망가지는 경우입니다.

나쁜 예: 데스크톱의 4열 푸터가 모바일에서 글자만 작아진 채 그대로 욱여넣어짐. 링크가 다닥다닥 붙어 옆 링크를 잘못 누름. 가로 스크롤 발생.
올바른 예: 모바일에서 한 열로 자연스럽게 접히고, 링크 간 간격과 터치 영역을 충분히(약 44px 이상) 확보. 폰트 크기도 읽을 수 있게 유지.

위반 8) 링크 텍스트가 모호함

"여기", "바로가기", "더보기" 같은 모호한 링크 텍스트입니다.

나쁜 예: "자세히 보려면 여기를 클릭". 스크린리더로 링크 목록만 들으면 "여기 여기 여기"만 반복돼 어디로 가는 링크인지 알 수 없음.
올바른 예: "개인정보처리방침", "이용약관", "오시는 길"처럼 목적지가 분명한 링크 텍스트. 링크만 떼어 읽어도 의미가 통하게.

위반 9) 저작권 연도가 멈춰 있음

작아 보이지만 신뢰에 직접 타격을 주는 실수입니다.

나쁜 예: 저작권 표시가 몇 년 전 연도에서 멈춰 있음. 사용자는 "이 사이트 관리 안 되나?" 하고 느낌. 관리 부실의 신호로 읽힘.
올바른 예: 저작권 연도를 자동 갱신하거나, 사이트 점검 시 함께 확인. 작은 디테일이지만 사이트가 살아 있다는 신호가 됨.

위반 10) 페이지마다 다른 푸터

같은 사이트인데 페이지마다 푸터 내용이나 구조가 다른 경우입니다.

나쁜 예: 메인 페이지 푸터엔 정책 링크가 다 있는데, 게시판 페이지 푸터엔 일부가 빠져 있음. 또는 어떤 페이지는 <footer>, 어떤 페이지는 <div>. 사용자는 어디서 무엇을 찾을지 혼란.
올바른 예: 푸터를 공통 컴포넌트로 만들어 모든 페이지에 동일하게 적용. 한 번 고치면 전 페이지에 반영되는 구조. 페이지별 편차를 점검으로 잡아냄.

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

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 공공 서비스의 "보조금 안내" 페이지, 화면 맨 아래에 푸터가 하나 있다고 합시다.

먼저 마우스를 쓰는 김 주무관. 페이지를 끝까지 내려 푸터에서 "문의 전화"를 찾고, 번호를 보고 전화를 겁니다. 잘 연결됩니다. 김 주무관에게 이 푸터는 아무 문제가 없습니다. 그래서 이 사이트를 만든 팀도 "푸터 잘 만들었다"고 믿습니다. 자기들이 테스트할 때 늘 마우스로 보고, 눈으로 정보를 읽었으니까요.

이번엔 시각장애가 있는 박 선생님. 스크린리더를 켜고, 푸터로 바로 가려고 랜드마크 점프를 시도합니다. 그런데 점프가 안 됩니다. 이 푸터는 <div>로 만든 가짜라, 스크린리더가 "콘텐츠 정보 영역"으로 인식하지 못하거든요. 할 수 없이 본문을 처음부터 끝까지 다 듣고 나서야 푸터에 닿습니다. 거기서 연락처를 찾으려는데, 주소와 전화번호가 이미지로 들어가 있어 스크린리더가 "이미지"라고만 읽고 지나갑니다. 박 선생님은 문의 전화번호를 끝내 알아내지 못하고, 결국 가족에게 대신 알아봐 달라고 부탁합니다.

같은 화면, 같은 푸터. 한 사람에겐 1분짜리 간단한 확인이고, 다른 한 사람에겐 닫힌 문입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스 사용자만 떠올렸기 때문에, 그리고 디자인을 깔끔하게 한다고 정보를 이미지로 넣었기 때문에 생긴 차이입니다. KRDS의 푸터 요건은, 이 두 사람의 경험을 같게 만들기 위한 최소한의 약속입니다.

만약 이 팀이 KRDS 킷의 푸터 코드를 가져다 쓰고, 정보를 텍스트로 넣었다면 어땠을까요. 박 선생님은 랜드마크 점프로 푸터에 바로 가서, "대표 전화, ○○○-○○○○"를 음성으로 듣고, 김 주무관과 똑같이 1분이면 전화를 걸었을 겁니다. 차이를 만드는 건 거창한 기술이 아니라, "검증된 구조를 쓰고 정보를 텍스트로 두느냐"라는 작은 선택입니다.

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

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

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. 저장소의 html/code 폴더에 푸터 코드가 들어 있어, <footer> 시맨틱 구조와 기본 링크 배치가 이미 잡힌 상태로 시작할 수 있습니다. "접근성은 어렵다"는 말의 절반은 "직접 만들어서 어렵다"는 뜻인데, 검증된 구조를 가져다 쓰면 그 절반이 사라집니다. 그리고 푸터는 공통 컴포넌트로 만들어 모든 페이지가 한 소스를 공유하게 하세요. 그래야 한 번 고치면 전 페이지에 반영되고, 페이지별 편차가 생기지 않습니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 푸터 컴포넌트를 가져다 쓸 수 있습니다. 직접 그리지 말고 표준 컴포넌트를 배치하면, 디자인 단계에서부터 정보 배치·간격·반응형 기준이 맞춰집니다. 그리고 시안에서 주소·연락처를 이미지가 아니라 텍스트로 다루도록 명시하세요. 인증 마크에는 "이건 의미 있는 마크인가, 장식인가"를 표시해 두면 개발 단계의 alt 처리가 정확해집니다.

기획자라면 — 화면 정의서에 "하단 푸터"라고만 적지 말고, 푸터에 들어갈 항목(기관명·주소·대표 전화·이메일·개인정보처리방침·이용약관·저작권 등)을 목록으로 명시하세요. 그리고 "이 정보들은 누가, 언제 갱신하는가"라는 운영 책임까지 정의하면, 부서 개편이나 이전 때 푸터 정보가 함께 갱신되는 프로세스가 생깁니다. 한 줄의 명시가 수백 페이지의 오류를 막습니다.

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

여기까지가 KRDS의 푸터 기준과 흔한 위반들입니다. 그런데 정작 어려운 건 "그래서 우리 사이트 푸터는 이걸 지키고 있나?"를 확인하는 일입니다. 푸터가 <footer>로 선언돼 있는지, 연락처가 텍스트인지 이미지인지, 개인정보처리방침 링크가 살아 있는지, 키보드로 모든 링크에 닿는지, 모바일에서 무너지지 않는지, 그리고 이게 모든 페이지에서 일관된지를 사람이 일일이 손으로 점검하려면 끝이 없습니다. 페이지가 수십·수백 개인 공공 사이트라면 더더욱요.

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

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

시맨틱 구조 판별: 푸터가 <footer> 시맨틱 태그로 선언돼 콘텐츠 정보 랜드마크로 인식되는지, 아니면 <div>로 만든 가짜 푸터인지
핵심 정보 존재 여부: 기관 정보·연락처·정책 링크 같은 필수 항목이 푸터에 포함돼 있는지
링크 텍스트 명확성과 접근성: 링크가 모호한 텍스트("여기")가 아닌지, 키보드로 닿고 포커스 표시가 있는지
이미지 대체 텍스트: 인증 마크·아이콘 이미지에 적절한 alt가 있는지, 의미/장식 구분이 됐는지
반응형 품질: 모바일 뷰포트에서 푸터 링크가 최소 권장 터치 크기를 충족하는지(반응형 품질 분석과 연계)

DOM만으로 판단하기 어려운 시각적 부분(예: 모바일에서 실제로 무너지는 레이아웃, 이미지로 박힌 정보)은 KRDScan Vision AI가 스크린샷을 보고 보강 판정합니다. 그래서 "코드엔 깔끔해 보이는데 화면에선 푸터가 무너지는" 경우나 "텍스트인 줄 알았는데 사실 이미지인" 경우도 놓치지 않습니다. 이 점이 단순 코드 검사 도구와 다른 부분입니다 — 사람이 눈으로 보듯 화면을 함께 보기 때문에, 표준을 우회한 푸터도 잡아냅니다.

리포트를 어떻게 읽나

분석이 끝나면 컴포넌트 탭에서 푸터 관련 규칙의 통과/미통과 수와, 미통과한 항목의 위치(어느 페이지)·이유·개선 방법(howToFix)이 함께 나옵니다. 예를 들어 "게시판 페이지의 푸터가 <div>로 구현돼 랜드마크 미인식"처럼 구체적으로요. 여러 페이지를 한꺼번에 분석하면, "메인 푸터엔 정책 링크가 다 있는데 하위 페이지 푸터엔 빠졌다" 같은 페이지별 편차도 한눈에 드러납니다. 푸터처럼 모든 페이지에 복제되는 영역은 이 "다중 페이지 일관성 점검"이 특히 위력을 발휘합니다. 한 곳만 보고 "괜찮다"고 단정하면, 정작 문제 있는 다른 페이지를 놓치게 되니까요.

어디부터 고쳐야 하는지 우선순위(P0~P3)도 함께 매겨지니, 한정된 시간에 가장 중요한 것부터 손볼 수 있습니다. 무료 진단으로 우리 사이트 메인부터 한 번 돌려 보면, 손으로는 몇 시간 걸릴 점검이 몇 분 만에 끝납니다. 그리고 그 결과는 막연한 "푸터 잘 만들자"가 아니라, "이 페이지의 푸터를 이렇게 고치자"는 구체적인 작업 목록이 됩니다.

자주 묻는 질문

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

Q. 푸터에 꼭 들어가야 하는 정보는 정확히 무엇인가요?

공공 웹사이트 기준으로 보면, 최소한 기관명·주소·대표 연락처·개인정보처리방침·이용약관·저작권 표시는 들어가는 것이 일반적입니다. 여기에 운영 주체, 사업자 정보, 관련 사이트 링크, 웹 접근성 인증 마크 등이 더해질 수 있죠. 핵심은 "사용자가 막혔을 때 필요한 것"과 "법적으로 고지해야 하는 것"입니다. 특히 개인정보처리방침은 사용자가 쉽게 찾을 수 있어야 하는 항목이라 빠뜨리면 안 됩니다. 항목 목록은 기관 성격에 따라 조금씩 다를 수 있으니, 동급 기관의 모범 사례와 KRDS 푸터 컴포넌트를 함께 참고하시길 권합니다.

Q. 푸터를 `<div>`로 만들었는데, 보기엔 똑같던데 굳이 `<footer>`로 바꿔야 하나요?

네, 바꾸는 걸 권합니다. 보기엔 똑같지만, <footer>로 선언해야 스크린리더가 그 영역을 "콘텐츠 정보 영역"으로 인식하고, 시각장애인 사용자가 랜드마크 단축키로 바로 점프할 수 있습니다. <div>면 그 사용자는 푸터에 닿기 위해 본문을 전부 통과해야 하죠. 태그 하나 바꾸는 작은 수정이지만, 특정 사용자에겐 접근의 난이도가 완전히 달라집니다. 비용은 거의 없고 효과는 큰, 대표적인 "먼저 고칠 항목"입니다.

Q. 디자인이 깔끔해 보여서 주소를 이미지로 넣었는데 문제가 되나요?

문제가 됩니다. 이미지 안의 글자는 스크린리더가 못 읽고, 사용자가 복사할 수도 없고, 확대하면 흐려지고, 검색 엔진도 못 읽습니다. 시각장애인 사용자에겐 그 주소가 존재하지 않는 정보가 되는 셈이죠. 텍스트로 넣어도 CSS로 충분히 깔끔하게 디자인할 수 있습니다. "예쁘게"와 "누구나 읽을 수 있게"는 충돌하는 목표가 아닙니다. 정보는 텍스트로, 꾸밈은 CSS로 — 이게 원칙입니다.

Q. 개인정보처리방침 링크가 깨졌는지 어떻게 일일이 확인하나요?

사람이 모든 페이지의 모든 링크를 클릭해 확인하기는 현실적으로 어렵습니다. 페이지가 수백 개면 더더욱요. ViewCheck 같은 자동 진단 도구로 크롤링해서, 푸터 링크가 존재하는지·올바른 곳으로 연결되는지를 한꺼번에 점검하는 게 효율적입니다. 그리고 운영 측면에선, 사이트 구조를 개편할 때 푸터 링크도 함께 점검하는 체크리스트를 두면 링크가 조용히 깨지는 걸 막을 수 있습니다.

Q. 모든 페이지에 같은 푸터를 넣으려면 어떻게 하나요?

푸터를 하나의 공통 컴포넌트(또는 include 파일)로 만들어, 모든 페이지가 그 한 소스를 불러오게 하는 게 정답입니다. 그러면 한 번 수정할 때 전 페이지에 반영되고, 페이지마다 푸터가 달라지는 일이 없어집니다. 페이지마다 푸터 코드를 복사-붙여넣기 해 두면, 나중에 정보를 갱신할 때 일부 페이지를 빠뜨리게 되고 — 그게 "페이지별 푸터 편차"의 원인입니다. 공통 컴포넌트화는 일관성과 유지보수 두 마리 토끼를 잡는 방법입니다.

Q. 푸터에 인증 마크가 여러 개인데, alt를 어떻게 처리하나요?

간단한 판단 기준이 있습니다. "이 마크를 통째로 지워도 사용자가 같은 정보를 얻을 수 있나?" 마크가 의미(인증 정보, 클릭하면 어디로 가는 링크)를 담고 있으면 그 의미를 alt로 넣으세요("○○ 인증"). 순수 장식이라면 빈 alt(alt="")나 aria-hidden으로 스크린리더가 건너뛰게 하세요. 의미 있는 마크에 alt가 없으면 못 읽히고, 장식 이미지에 불필요한 alt가 있으면 "이미지 이미지"로 시끄러워집니다. 둘을 구분하는 게 핵심입니다.

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

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "지금 우리 푸터가 어느 페이지에서 무슨 문제를 일으키는지"를 목록으로 만든 다음, 뒤에 나오는 우선순위대로 치명적인 것부터 차례로 고치면 됩니다. 특히 푸터는 공통 컴포넌트로 묶기만 하면 한 번의 수정이 전 페이지에 반영되므로, 다른 영역보다 오히려 개선 효율이 좋은 편입니다. 리뉴얼 예산을 한 번에 들이지 않고도 점진적으로 점수를 끌어올릴 수 있습니다.

Q. 푸터가 너무 정보로 빽빽한데, 줄여도 되나요?

무조건 줄이는 게 답은 아닙니다. 법적으로 고지해야 하는 항목(개인정보처리방침 등)과 사용자가 자주 찾는 정보(연락처, 오시는 길)는 반드시 남겨야 합니다. 다만 거의 안 쓰이는 링크가 수십 개씩 나열돼 있다면, 의미별로 그룹화하거나 핵심만 남기고 정리하는 건 좋습니다. "빽빽하다"의 해법은 "지우기"가 아니라 "정리하기"입니다. 그리고 정리할 때도 정책·법적 링크는 건드리지 마세요.

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

ViewCheck로 돌려 보면 보통 푸터 관련 문제가 한두 개로 끝나지 않습니다. 게다가 푸터는 모든 페이지에 복제되니, 페이지 수만큼 문제가 곱해져 보여 압박감이 큽니다. 그래서 우선순위가 중요합니다. 푸터 문제를 심각도 순으로 정리하면 대략 이렇습니다.

가장 먼저(치명적) — 개인정보처리방침 링크 누락/깨짐, 연락처 완전 누락, 그리고 정보를 통째로 이미지로 박아 스크린리더가 못 읽는 경우. 이건 법적 요건과 직결되거나 특정 사용자에게 정보를 완전히 차단하는 문제라 1순위입니다. 신뢰성에도 직접 타격을 주죠.

그다음(높음) — <div>로 만든 가짜 푸터(랜드마크 미인식), 키보드로 닿지 않는 링크, alt 없는 의미 있는 마크. 작동은 하지만 음성·키보드 사용자에게 실질적 장벽이 됩니다. 그리고 페이지마다 푸터가 다른 일관성 문제도 여기 포함됩니다(사용자가 어디서 무엇을 찾을지 헷갈리므로).

그 후(보통) — 모바일 터치 영역 부족, 포커스 표시 제거, 모호한 링크 텍스트. 사용은 가능하지만 특정 상황·특정 사용자에게 불편을 주는 문제입니다.

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> 시맨틱 태그로 선언돼 콘텐츠 정보 랜드마크로 인식된다(<div> 가짜 푸터가 아니다).
☐ 기관명·주소·대표 연락처가 텍스트로 명시돼 있고, 최신이다(이미지로 박지 않았다).
☐ 개인정보처리방침 링크가 존재하고, 클릭하면 올바른 페이지로 연결된다(깨지지 않았다).
☐ 모든 링크 텍스트가 명확하다("여기", "더보기"가 아니라 "개인정보처리방침"처럼 목적지가 분명하다).
☐ 인증 마크·아이콘에 적절한 대체 텍스트(alt)가 있고, 의미/장식이 구분돼 있다.
☐ 푸터의 모든 링크가 키보드로 닿고, 포커스 표시가 또렷하다(outline: none으로 지우지 않았다).
☐ 화면 밖으로 밀어 둔 "유령 링크"가 Tab 순서에 끼어들지 않는다.
☐ 모바일에서 푸터가 한 열로 자연스럽게 접히고, 링크 터치 영역이 충분하다(약 44px 이상).
☐ 푸터가 모든 페이지에서 일관되다(공통 컴포넌트로 관리한다).

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

푸터는 작아 보이고 화면 맨 아래에 숨어 있지만, 공공 서비스에서 사용자가 "막혔을 때 마지막으로 손을 뻗는" 안내소입니다. 그 작은 영역 하나가 누군가에겐 필요한 정보를 찾는 열쇠이고, 또 누군가에겐 닫힌 문입니다. 우리가 무심코 복사-붙여넣기 한 푸터 하나가, 누군가에게는 그 민원을 혼자 끝낼 수 있느냐 없느냐를 가릅니다.

오늘 정리한 위반들이 많아 보일 수 있지만, 핵심은 결국 단순합니다. 푸터를 <footer>로 선언하고, 정보를 텍스트로 정확하게 넣고, 정책 링크를 살려 두고, 키보드와 모바일에서 쓸 수 있게 하고, 모든 페이지에 일관되게 적용하는 것. 이 다섯 가지만 챙겨도 푸터 위반의 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 치명적인 위반 하나부터 고쳐 나가면, 그리고 푸터를 공통 컴포넌트로 묶어 두면, 우리 사이트는 분명히 조금씩 더 많은 사람에게 열립니다. 다음 글에서는 푸터와 짝을 이루는 또 다른 공통 영역을 같은 방식으로 뜯어보겠습니다.

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

#KRDS #공공웹 #디자인시스템 #푸터Footer #웹접근성 #ViewCheck #정부웹사이트 #UIUX #콘텐츠정보 #개인정보처리방침 #랜드마크 #반응형 #푸터 #Footer #흔한실수 #개선사례 #안티패턴 #전자정부 #디지털정부 #행정안전부