푸터(Footer) 완전 해부 — KRDS 공식 기준

공공 웹사이트를 끝까지 스크롤해 본 적이 있으신가요. 우리가 평소에 푸터(Footer)를 의식하는 순간은 사실 별로 없습니다. 본문에서 원하는 정보를 다 찾았으면 그냥 닫아 버리니까요. 그런데 어느 날 갑자기 푸터가 절실해지는 순간이 옵니다. 개인정보가 잘못 처리된 것 같아 항의할 곳을 찾을 때, 사이트에 오류가 있어 문의하고 싶을 때, 이 정보를 정말 믿어도 되는 기관이 맞나 확인하고 싶을 때. 그제서야 사람들은 화면 맨 아래로 내려가 "여기 누가 운영하는 거지", "전화는 어디로 하지", "주소가 어디지"를 찾습니다. 푸터는 평소엔 아무도 안 보다가, 정작 필요한 순간엔 모두가 찾는 곳입니다.

저는 공공 사이트를 수백 개 분석하면서 푸터를 유심히 보게 됐습니다. 처음엔 "그냥 맨 아래 회색 박스 아닌가" 싶었는데, 보면 볼수록 이게 사이트의 신뢰도를 가장 솔직하게 드러내는 영역이라는 걸 알게 됐습니다. 잘 만든 푸터는 "이 사이트는 누가, 어떤 책임으로, 어디서 운영하는지"를 군더더기 없이 보여 줍니다. 반대로 부실한 푸터는 운영기관이 누군지도 모호하고, 연락처는 대표번호 하나 덜렁 있고, 개인정보처리방침 링크는 클릭하면 엉뚱한 데로 가거나 아예 없습니다. 신기하게도 푸터가 엉성한 사이트는 본문도 대체로 엉성합니다. 푸터는 그 사이트가 "기본을 챙기는 곳인가"를 보여 주는 리트머스 시험지 같은 거죠.

그래서 KRDS(대한민국 정부 디자인 시스템)는 푸터를 "장식용 마무리"가 아니라 어엿한 컴포넌트로 정의하고, 무엇을 담아야 하는지 기준을 제시합니다. 이 글에서는 그 기준을 하나하나 뜯어보겠습니다. "이렇게 하면 보기 좋다"가 아니라 "정부 표준은 푸터에 무엇을 요구하는가"라는 사실 기준으로요. 다 읽고 나면, 앞으로 어떤 공공 사이트든 맨 아래로 스크롤할 때마다 "이 푸터는 제대로 갖췄네, 저 푸터는 비었네"가 눈에 들어오실 겁니다. 그리고 정작 중요한, 우리 사이트의 푸터는 그 기준을 지키고 있는지 확인하는 방법까지 이어가겠습니다.

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

먼저 용어를 정확히 맞추겠습니다. 우리가 "맨 아래 영역"이라고 뭉뚱그려 부르는 곳을 KRDS는 푸터(Footer)라는 이름의 컴포넌트로 다룹니다. 영문으로는 Footer. 단순히 시각적으로 페이지 하단에 위치한 띠가 아니라, 사이트 운영 주체와 책임, 그리고 사용자가 반드시 알아야 할 법적·행정적 정보를 담는 고정 영역이라는 게 핵심 정의입니다.

여기서 가장 먼저 짚을 게 있습니다. 푸터는 "본문이 끝나고 남는 자리"가 아닙니다. 많은 사람이 푸터를 페이지를 다 채우고 나서 빈 곳을 메우는 회색 박스 정도로 생각하는데, KRDS의 관점은 정반대입니다. 푸터는 사이트 전체에서 가장 일관되게 유지돼야 하는 영역 중 하나입니다. 메인이든 신청 페이지든 검색 결과든, 어느 페이지에 있든 사용자가 "이 사이트의 운영기관은 어디고, 어디로 문의하고, 정책은 어디서 보는지"를 똑같은 자리에서 똑같은 모습으로 찾을 수 있어야 합니다.

이게 헤더(Header)와 짝을 이루는 부분입니다. 헤더가 "사이트의 정체성을 위에서 알려 주고 길을 안내한다"면, 푸터는 "사이트의 책임을 아래에서 마무리하고 보증한다"고 볼 수 있습니다. 둘 다 모든 페이지에 공통으로 들어가는 전역 영역(global region)이라는 공통점이 있죠. 그래서 KRDS는 헤더·푸터를 사이트의 "골격"을 이루는 컴포넌트로 묶어서 다룹니다.

푸터에 담기는 것들 — 구성요소 개관

KRDS가 정의하는 푸터의 구성요소를 큰 덩어리로 먼저 그려 보겠습니다. 뒤에서 하나씩 자세히 뜯겠지만, 전체 그림을 먼저 잡아 두는 게 이해에 좋습니다.

운영기관 정보: 누가 이 사이트를 운영하는지. 기관명, 주소, 그리고 사이트에 따라 대표자·사업자 정보 등.
연락처: 대표 전화번호, 팩스, 이메일 등 실제로 닿을 수 있는 통로.
정책·법적 고지 링크: 개인정보처리방침, 이용약관, 저작권 정책, 웹 접근성 안내 등.
관련 사이트·바로가기: 유관 기관, 패밀리 사이트로 이동하는 링크 모음.
저작권·면책 표시: Copyright 표기와 정보 이용에 대한 안내.
로고·아이덴티티: 기관 또는 정부 상징 표시.

이 목록을 보면 한 가지 패턴이 보입니다. 푸터에 들어가는 정보는 대부분 "이 사이트의 책임과 신뢰에 관한 것"입니다. 화려한 콘텐츠나 기능이 아니라, "누가 책임지고, 어떻게 닿고, 무엇을 약속하는가"에 관한 정보죠. KRDS가 푸터를 별도 컴포넌트로 표준화한 이유가 바로 여기 있습니다. 이 정보들이 빠지거나 부정확하면, 사용자는 그 사이트를 신뢰할 근거를 잃습니다. 특히 공공 서비스에서는 이게 단순한 신뢰 문제를 넘어, 법적으로 고지해야 하는 의무와도 맞닿아 있습니다.

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

이제 본론입니다. KRDS 가이드라인(디지털 정부서비스 UI/UX 가이드라인, 2025.08판)과 컴포넌트 문서를 기준으로, 푸터가 충족해야 하는 요건을 영역별로 정리하겠습니다.

1) 운영기관 정보 — "누가 책임지는가"를 명확히

푸터의 첫 번째이자 가장 중요한 요건은 운영기관을 분명히 밝히는 것입니다. 단순히 로고 하나 박아 두는 걸로는 부족합니다. 기관명이 텍스트로 명확히 적혀 있어야 하고, 필요한 경우 주소·대표자 정보까지 포함돼야 합니다.

왜 이게 첫 번째냐면, 사용자가 푸터를 찾는 가장 흔한 이유가 "이 사이트, 진짜 그 기관이 운영하는 게 맞나"를 확인하기 위해서이기 때문입니다. 요즘은 공공기관을 사칭한 가짜 사이트도 적지 않습니다. 운영기관 정보가 명확하고 일관되게 적혀 있다는 것 자체가, 사용자에게 "여긴 진짜다"라는 신호를 줍니다. 반대로 운영기관이 모호하거나 로고만 덜렁 있는 사이트는, 그게 진짜라도 사용자에게 불안을 줍니다.

여기서 중요한 건 운영기관 정보가 이미지가 아니라 텍스트여야 한다는 점입니다. 기관명을 이미지로만 넣어 두면, 스크린리더 사용자는 그 정보를 읽을 수 없고, 검색엔진도 그 정보를 인식하지 못합니다. 로고 이미지를 쓰더라도 대체 텍스트(alt)를 반드시 제공하고, 기관명·주소 같은 핵심 정보는 별도의 텍스트로도 제공해야 합니다.

2) 연락처 — 실제로 닿을 수 있어야 한다

푸터에는 사용자가 기관에 닿을 수 있는 통로가 있어야 합니다. 대표 전화번호, 이메일, 경우에 따라 팩스나 우편 주소까지. 이건 "있으면 좋은 것"이 아니라 공공 서비스의 기본 책무에 가깝습니다. 사용자가 문제를 겪었을 때 항의하거나 문의할 곳이 없다면, 그건 책임을 회피하는 사이트가 됩니다.

연락처에서 자주 놓치는 디테일이 두 가지 있습니다. 첫째, 전화번호나 이메일을 이미지로 넣어 두는 경우. 보안상의 이유로 이메일을 이미지로 넣는 관행이 있는데, 그러면 시각장애인 사용자는 그 정보를 쓸 수 없습니다. 둘째, 전화번호를 텍스트로 넣되 모바일에서 바로 통화로 연결(tel: 링크)되게 하지 않는 경우. 모바일에서 푸터의 번호를 길게 눌러 복사해서 다시 전화 앱에 붙여넣는 건 번거롭습니다. 작은 차이지만, 급하게 문의해야 하는 사용자에겐 큰 차이입니다.

3) 개인정보처리방침 — 가장 빠뜨려선 안 되는 링크

푸터에 반드시 있어야 할 정책 링크 중에서도, 개인정보처리방침은 특별한 위치를 차지합니다. 개인정보를 다루는 서비스라면 개인정보처리방침을 명시하고 접근 가능하게 두는 것은 법적인 요구이기도 합니다. 그리고 관행적으로 이 링크가 놓이는 자리가 바로 푸터입니다. 사용자는 "정책은 맨 아래에 있겠지"라고 학습돼 있으니까요.

개인정보처리방침 링크에서 KRDS적 관점으로 봐야 할 포인트가 있습니다. 첫째, 이 링크가 다른 링크들 사이에서 시각적으로 구분되는 게 좋습니다. 개인정보처리방침은 다른 일반 링크보다 중요도가 높으므로, 굵게 표시하거나 약간 강조해서 사용자가 빨리 찾게 하는 사이트가 많습니다. 둘째, 링크 텍스트가 명확해야 합니다. "방침", "정책"처럼 모호하게 적지 말고 "개인정보처리방침"이라고 또렷하게요. 셋째, 당연하지만 클릭하면 실제로 그 문서로 가야 합니다. 깨진 링크나 "준비 중" 페이지로 가는 개인정보처리방침은 없느니만 못합니다.

4) 그 밖의 정책·법적 고지 링크

개인정보처리방침 외에도 푸터에는 여러 정책 링크가 들어갑니다. 이용약관, 저작권 정책, 웹 접근성 안내(또는 접근성 정책), 이메일무단수집거부 같은 것들이죠. 사이트의 성격에 따라 들어가는 항목은 달라지지만, 공통점은 "사용자가 사이트를 이용하면서 알아야 할 권리·의무·약속"이라는 점입니다.

이 링크들을 다룰 때 KRDS가 중시하는 건 구조화와 일관성입니다. 링크들을 아무렇게나 줄줄이 나열하지 말고, 의미 단위로 묶고 시각적으로 정돈하라는 거죠. 그리고 모든 페이지에서 같은 푸터, 같은 링크 구성이 유지돼야 합니다. 어떤 페이지에선 개인정보처리방침이 있는데 다른 페이지에선 빠져 있으면, 그건 푸터를 페이지별로 따로 관리하고 있다는 뜻이고, 곧 관리 누락이 생기기 쉽다는 뜻입니다.

5) 관련 사이트·바로가기

푸터에는 유관 기관이나 패밀리 사이트로 이동하는 링크 모음이 들어가는 경우가 많습니다. 흔히 셀렉트(드롭다운) 형태의 "관련 사이트" 선택 메뉴로 구현되죠. 이 부분은 푸터의 부가 기능이지만, 그렇다고 대충 만들어도 되는 건 아닙니다.

특히 관련 사이트가 셀렉트(드롭다운)로 구현될 때, 그 셀렉트 자체가 KRDS의 셀렉트 컴포넌트 기준을 따라야 합니다. 라벨이 연결돼 있어야 하고, 키보드로 조작 가능해야 하고, 고른 즉시 새 창으로 이동한다면 그 동작이 사용자에게 예측 가능해야 합니다. 푸터의 관련 사이트 드롭다운이 "값을 고르면 갑자기 새 창이 뜨는" 식으로 작동하면, 키보드·스크린리더 사용자에겐 혼란스럽습니다. 푸터 안의 작은 컴포넌트 하나하나도 결국 다른 컴포넌트 기준의 적용을 받는다는 게 핵심입니다.

6) 저작권 표시와 면책

7) 시맨틱 마크업과 랜드마크 — 코드 수준의 기준

여기부터가 KRDS의 기준이 단순한 "정보 목록"을 넘어서는 지점입니다. 푸터는 시각적으로 하단에 위치하는 것만으로는 부족하고, 코드 수준에서 푸터로 선언돼 있어야 합니다.

웹 표준으로 말하면, 푸터 영역은 <footer> 요소로 감싸거나 role="contentinfo"를 갖고 있어야 합니다. 이게 왜 중요하냐면, 스크린리더 사용자는 "랜드마크"라는 기능으로 페이지의 주요 영역을 건너뛰며 탐색하기 때문입니다. 푸터가 contentinfo 랜드마크로 선언돼 있으면, 사용자는 단축키 한 번으로 "사이트 정보 영역"으로 바로 점프할 수 있습니다. 운영기관 정보나 연락처를 찾으려고 본문 전체를 처음부터 끝까지 들을 필요가 없는 거죠.

반대로 푸터가 그냥 <div class="footer">로만 돼 있으면, 스크린리더 입장에선 그게 푸터인지 알 길이 없습니다. 시각적으로는 분명히 맨 아래 회색 띠지만, 코드로는 그냥 의미 없는 박스입니다. "보이는 것과 읽히는 것의 일치" — 이건 KRDS 모든 컴포넌트 기준을 관통하는 원리인데, 푸터에서도 똑같이 적용됩니다.

8) 링크 접근성 — 푸터 안 모든 링크가 읽혀야 한다

푸터는 사실상 링크 덩어리입니다. 정책 링크, 관련 사이트, 연락처까지 대부분 링크나 상호작용 요소죠. 그래서 푸터 안 링크들의 접근성이 통째로 중요합니다.

각 링크는 텍스트만으로도 어디로 가는지 알 수 있어야 합니다. "바로가기", "더보기" 같은 모호한 텍스트는 스크린리더로 들으면 "어디로 가는 바로가기인지" 알 수 없습니다. 새 창으로 열리는 링크라면 그 사실을 미리 알려야 하고요. 아이콘만으로 된 링크(예: SNS 아이콘)는 반드시 대체 텍스트나 접근 가능한 이름을 가져야 합니다. 푸터의 SNS 아이콘들이 alt 없이 이미지로만 들어가 있어서 스크린리더가 그냥 "링크, 링크, 링크"로만 읽는 경우를 정말 자주 봅니다.

9) 일관성과 반응형

앞서 강조했듯 푸터는 모든 페이지에서 동일하게 유지돼야 합니다. 그리고 모바일에서도 무너지지 않아야 합니다. 데스크톱에서 여러 열로 정돈됐던 푸터가 모바일에서 세로로 쌓일 때, 정보의 순서와 묶음이 흐트러지지 않게 설계해야 합니다. 작은 화면에서 링크가 너무 다닥다닥 붙어 손가락으로 정확히 누르기 어렵거나, 중요한 개인정보처리방침 링크가 화면 밖으로 밀려나는 일이 없어야 합니다.

10) 본문 끝과 푸터의 경계 — 시각적 구분

마지막으로 자주 간과되는 요건 하나. 푸터는 본문과 시각적으로 구분돼야 합니다. 배경색을 달리하거나 구분선을 두어, 사용자가 "여기서부터는 본문이 아니라 사이트 정보 영역"이라는 걸 인지할 수 있어야 하죠. 이 경계가 흐릿하면, 사용자는 본문 콘텐츠와 푸터 링크를 헷갈립니다. 특히 저시력 사용자나 인지적 부담이 있는 사용자에게 이 시각적 경계는 생각보다 큰 도움이 됩니다. KRDS가 푸터를 별도 영역으로 다루는 건 정보 구성뿐 아니라 이 "영역으로서의 인식"까지 포함하는 개념입니다.

다만 여기서 주의할 점은, 색만으로 경계를 만들면 색 구분이 어려운 사용자에겐 그 경계가 보이지 않는다는 것입니다. 그래서 배경색 변화와 함께 여백·구분선 같은 비색채 신호를 같이 쓰는 게 안전합니다. 이건 앞서 본 "오류를 색으로만 표시하지 말라"는 원칙과 같은 맥락입니다 — 어떤 정보든 색 하나에만 의존하지 말라는 것. 푸터의 경계 같은 사소해 보이는 디테일에도 이 원칙이 그대로 적용됩니다.

정리하면, KRDS의 푸터 기준은 크게 세 축입니다. ① 완전성(운영기관·연락처·정책 링크 같은 필수 정보를 빠짐없이), ② 신뢰성(정확하고 일관되며 실제로 작동하는 정보), ③ 접근성(시맨틱 마크업·랜드마크·링크 접근성으로 누구나 닿을 수 있게). 이 세 축은 그대로 ViewCheck가 푸터를 판정하는 기준이기도 합니다. 그리고 이 세 축이 따로 노는 게 아니라 서로 맞물려 있다는 점이 중요합니다. 정보가 완전해도 이미지로만 들어가면 접근성이 깨지고, 접근성이 좋아도 페이지마다 다르면 신뢰성이 무너집니다. 그래서 푸터는 "하나만 잘하면 되는" 영역이 아니라 "세 가지를 동시에 챙겨야 하는" 영역입니다.

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

여기까지 읽고 "맨 아래 회색 박스 하나에 뭐 이리 요구사항이 많나" 싶으실 수 있습니다. 그런데 이 기준들은 누가 괜히 만들어 낸 게 아니라, 실제로 사용자가 곤란을 겪는 지점에서 역으로 도출된 것들입니다.

푸터는 "신뢰의 마지막 관문"이다

사람들이 정보를 신뢰할지 말지 판단할 때, 의외로 푸터를 봅니다. 본문이 아무리 그럴듯해도, 맨 아래에 운영기관이 명확하지 않고 연락처도 없으면 "이거 믿어도 되나" 싶어지죠. 반대로 푸터에 기관명·주소·전화번호·정책 링크가 단정하게 정리돼 있으면, 본문 내용에 대한 신뢰도 함께 올라갑니다. 이건 사람의 자연스러운 판단 방식입니다. "끝까지 책임지는 모습을 보여 주는 곳"을 더 믿는 거죠.

공공 서비스에서는 이 신뢰가 특히 중요합니다. 공공 사이트를 사칭한 피싱이 늘어나는 상황에서, 명확한 운영기관 정보는 "이건 진짜 정부 서비스다"라는 보증이 됩니다. 푸터가 부실하면, 진짜 공공 사이트인데도 가짜처럼 의심받을 수 있습니다. 운영기관 정보를 명확히 텍스트로 두라는 KRDS의 기준은, 단순히 정보를 넣으라는 게 아니라 "사용자가 안심하게 하라"는 요구입니다.

정작 급할 때 찾는 곳

푸터의 정보가 빛을 발하는 건 평상시가 아니라 위기 상황입니다. 개인정보 유출이 의심될 때, 서비스에 심각한 오류가 있을 때, 부당한 처리를 받았다고 느낄 때 — 사용자는 화면 맨 아래로 내려가 항의하고 문의할 통로를 찾습니다. 이때 연락처가 없거나, 개인정보처리방침이 깨진 링크거나, 운영기관이 누군지 모호하면, 사용자는 자기 권리를 행사할 방법을 잃습니다.

이게 푸터가 "장식"이 아니라 "권리 보장의 인프라"인 이유입니다. 거주 지역 셀렉트가 안 읽히면 그 민원을 못 내는 것처럼, 개인정보처리방침 링크가 없으면 사용자는 자기 정보가 어떻게 다뤄지는지 알 권리를 행사할 수 없습니다. KRDS가 정책 링크와 연락처를 푸터의 핵심 요건으로 두는 건, 사용자의 이 "알 권리"와 "닿을 권리"를 지키기 위해서입니다.

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

역설적이지만, 푸터처럼 "맨 아래 흔한" 영역일수록 품질 관리에서 밀려납니다. 메인 비주얼이나 핵심 기능에는 모두가 눈을 부릅뜨지만, 푸터는 "한 번 만들어 두면 그만"이라는 생각에 방치됩니다. 사이트를 개편할 때 본문은 싹 갈아엎으면서 푸터는 옛날 코드를 그대로 복사해 오는 경우가 흔하죠. 그러다 보면 연도가 몇 년 전에 멈춰 있거나, 폐지된 정책 링크가 그대로 남아 있거나, 시맨틱 마크업 없이 옛날 방식 그대로 남습니다.

그런데 사용자가 "이 사이트를 믿을 만한가"를 판단하는 마지막 순간이 바로 이 방치된 영역입니다. 가장 덜 주목받는 곳이 사실은 신뢰를 가르는 길목인 셈입니다. KRDS가 푸터 같은 기본 영역까지 꼼꼼히 표준화해 둔 건, 바로 이 "방치되기 쉬운 곳"에서 품질이 무너지는 걸 막기 위해서입니다.

랜드마크 — 보이지 않는 배려

비장애인은 화면을 한눈에 훑어 "아, 저 아래 회색 띠가 푸터구나" 하고 짐작합니다. 스크린리더 사용자에게는 이 짐작 과정이 없습니다. 코드가 알려 주는 정보가 곧 전부죠. 푸터가 <footer>나 role="contentinfo"로 선언돼 있으면, 사용자는 랜드마크 탐색으로 단번에 그 영역으로 갈 수 있습니다. 선언돼 있지 않으면, 운영기관 정보 하나 찾으려고 페이지 전체를 처음부터 끝까지 들어야 합니다.

이 차이는 코드 한 줄에서 갈립니다. <div>로 쓰느냐 <footer>로 쓰느냐. 시각적으로는 완전히 똑같지만, 누군가에겐 "단축키 한 번"과 "전체 탐색"의 차이입니다. KRDS의 시맨틱 마크업 요구는 이렇게 보이지 않는 곳에서 누군가의 시간을 아껴 줍니다.

일관성이 곧 학습 비용 절감

KRDS가 푸터의 구성과 모습을 표준화하는 또 다른 이유는 일관성입니다. 정부 사이트마다 푸터가 제각각이면, 사용자는 사이트를 옮길 때마다 "여기선 개인정보처리방침이 어디 있지?"를 다시 찾아야 합니다. 모든 공공 서비스의 푸터가 비슷한 구성으로 같은 자리에 정보를 두면, 한 번 익힌 사용법이 모든 사이트에서 통합니다. "정책 링크는 맨 아래", "연락처는 푸터 왼쪽"처럼 학습된 패턴이 유지되면, 디지털 약자에게 특히 큰 배려가 됩니다.

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

추상적인 요건을 길게 늘어놓는 것보다, 한 장면을 그려 보는 게 빠를 것 같습니다. 어느 ○○시 산하 기관의 민원 사이트. 본문에서 어떤 신청을 마쳤는데, 며칠 뒤 자기 개인정보가 어떻게 보관되는지 궁금해졌다고 합시다.

먼저 마우스를 쓰는 김 씨. 사이트를 열고 화면 맨 아래로 스크롤합니다. 회색 띠 안에 "개인정보처리방침"이라는 굵은 링크가 보입니다. 클릭하니 방침 문서가 뜹니다. 30초도 안 걸렸습니다. 김 씨에게 이 푸터는 아무 문제가 없습니다. 그래서 이 사이트를 만든 팀도 "잘 작동한다"고 믿습니다. 자기들이 테스트할 때 늘 마우스로 스크롤해서 클릭했으니까요.

이번엔 시각장애가 있는 박 선생님. 스크린리더를 켜고 같은 정보를 찾습니다. 먼저 랜드마크 탐색으로 "사이트 정보 영역"으로 점프하려 합니다. 그런데 점프가 안 됩니다. 이 사이트의 푸터는 <div class="footer">로만 돼 있어서 랜드마크로 선언돼 있지 않거든요. 어쩔 수 없이 본문 끝까지 한 줄 한 줄 들으며 내려갑니다. 한참 만에 푸터에 도착했는데, 개인정보처리방침이 다른 일반 링크들 사이에 묻혀 있어 구분이 안 됩니다. 게다가 연락처 전화번호는 이미지로 들어가 있어 스크린리더가 아예 읽지 못합니다. 박 선생님은 결국 자기 정보가 어떻게 처리되는지 확인하는 걸 포기합니다.

같은 화면, 같은 푸터. 한 사람에겐 30초짜리 간단한 확인이고, 다른 한 사람에겐 닫힌 문입니다. 그리고 이 차이는 "예산이 부족해서"나 "기술이 어려워서" 생긴 게 아닙니다. 그냥 만들 때 마우스 사용자만 떠올렸고, 푸터를 <footer>가 아니라 <div>로 짰고, 연락처를 이미지로 넣었기 때문입니다. KRDS의 푸터 요건은, 이 두 사람의 경험을 같게 만들기 위한 최소한의 약속입니다. 그리고 그 약속을 지켰는지는 사람이 매번 스크린리더로 확인하기 어렵기 때문에, 자동 점검이 필요한 겁니다.

만약 이 팀이 KRDS 킷의 푸터 코드를 가져다 썼다면 어땠을까요. 박 선생님의 스크린리더는 랜드마크 탐색으로 단번에 "사이트 정보"로 점프했을 거고, 텍스트로 된 연락처와 또렷한 개인정보처리방침 링크를 김 씨와 똑같이 30초 만에 찾았겠죠. 차이를 만드는 건 거창한 기술이 아니라, "검증된 컴포넌트를 쓰느냐"라는 작은 선택입니다.

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

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

실수 1) `<div>`로 만든 "가짜 푸터" — 랜드마크 누락

가장 흔하고, 가장 눈에 안 띄는 실수입니다. 시각적으로는 완벽한 푸터인데, 코드는 그냥 <div class="footer">. 스크린리더에겐 푸터가 아니라 의미 없는 박스입니다.

나쁜 예: <div class="footer">에 모든 정보를 담고 끝. <footer>도 role="contentinfo"도 없음. 랜드마크 탐색 불가. 운영기관 정보 하나 찾으려면 본문 전체를 들어야 함.
올바른 예: 푸터 영역을 <footer> 요소로 감싸거나 role="contentinfo"를 부여. 스크린리더가 "사이트 정보 영역"으로 인식해 단축키로 바로 이동 가능. KRDS 킷의 푸터 코드는 이 마크업이 이미 들어가 있음.

실수 2) 운영기관 정보가 이미지뿐

기관명·로고·주소를 통째로 하나의 이미지로 넣어 둡니다. 디자인은 깔끔할지 몰라도 정보로서는 무용지물입니다.

나쁜 예: 기관명과 주소가 적힌 이미지 한 장. alt 없음. 스크린리더는 "이미지"라고만 읽거나 그냥 건너뜀. 검색엔진도 운영기관을 인식 못 함.
올바른 예: 핵심 정보(기관명, 주소)는 텍스트로 제공. 로고 이미지를 쓰더라도 의미 있는 대체 텍스트(alt)를 부여. 텍스트로 둔 정보는 복사·확대·번역도 가능.

실수 3) 개인정보처리방침 링크 부재 또는 깨짐

푸터에 개인정보처리방침이 아예 없거나, 있어도 클릭하면 "준비 중" 또는 404로 갑니다.

나쁜 예: 개인정보처리방침 링크가 없음. 또는 링크는 있는데 폐지된 URL로 연결돼 빈 페이지가 뜸.
올바른 예: 개인정보처리방침을 명확한 텍스트 링크로 두고, 실제 방침 문서로 정상 연결. 다른 정책 링크와 시각적으로 구분(굵게 등)해 빨리 찾게 함.

실수 4) 연락처를 이미지로 넣기

스팸 수집 방지를 이유로 전화번호·이메일을 이미지로 처리합니다.

나쁜 예: 이메일·전화번호가 이미지. 스크린리더 사용자는 읽지 못하고, 복사도 안 됨. 모바일에서 탭해도 통화 연결 안 됨.
올바른 예: 연락처를 텍스트로 제공. 전화번호는 모바일에서 tel: 링크로 바로 통화 연결. 스팸이 걱정되면 이미지 대신 다른 보호 방식을 검토하되, 접근성을 희생하지 않음.

실수 5) 모호한 링크 텍스트와 alt 없는 아이콘

"바로가기", "더보기" 같은 모호한 텍스트, 그리고 alt 없는 SNS 아이콘 링크들.

나쁜 예: 푸터에 "바로가기" 링크 여러 개. 스크린리더로는 어디로 가는지 구분 불가. SNS 아이콘은 alt 없이 "링크, 링크, 링크"로만 읽힘.
올바른 예: 링크 텍스트가 목적지를 명확히 설명("관련 사이트 모음 열기" 등). 아이콘 링크는 접근 가능한 이름 부여. 새 창으로 열리면 그 사실을 안내.

실수 6) 페이지마다 다른 푸터

일부 페이지엔 정상 푸터, 다른 페이지엔 축약된 푸터나 빈 푸터가 들어갑니다.

나쁜 예: 메인엔 풀 푸터가 있는데, 신청·결과 페이지엔 개인정보처리방침이 빠진 축약 푸터. 사용자가 어느 페이지에 있느냐에 따라 닿을 수 있는 정보가 달라짐.
올바른 예: 모든 페이지에 동일한 푸터를 전역 컴포넌트로 일관 적용. 한 곳만 고치면 전 페이지에 반영되는 구조.

실수 7) 모바일에서 무너지는 레이아웃

데스크톱 기준으로만 만들어 모바일에서 링크가 겹치거나 화면 밖으로 밀려납니다.

나쁜 예: 모바일에서 여러 열이 깨져 링크가 다닥다닥 붙음. 손가락으로 옆 링크를 잘못 누르기 쉬움. 중요 링크가 화면 밖으로 잘림.
올바른 예: 반응형으로 세로 정렬되며 정보 순서·묶음 유지. 링크 간 터치 영역을 충분히 확보.

실수 8) 저작권 연도 하드코딩

나쁜 예: 몇 년 전 연도가 고정돼 있어 사이트가 관리 안 되는 인상을 줌.
올바른 예: 연도를 동적으로 처리하거나, 최소한 개편 시 갱신. 작은 디테일이지만 신뢰의 일부.

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

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

개발자라면 — KRDS 컴포넌트 킷을 npm install krds-uiux로 설치하거나 CDN(krds.min.css / krds.min.js)으로 불러올 수 있습니다. GitHub 저장소(KRDS-uiux/krds-uiux)의 html/code 폴더에 푸터 코드가 들어 있어, <footer> 시맨틱 마크업과 랜드마크, 링크 접근성이 이미 반영된 상태로 시작할 수 있습니다. 푸터를 한 번 잘 만들어 전역 컴포넌트로 빼 두면, 모든 페이지에 일관되게 적용되고 한 곳만 고쳐도 전부 반영됩니다. "접근성은 어렵다"는 말의 절반은 "직접 만들어서 어렵다"는 뜻인데, 검증된 코드를 가져다 쓰면 그 절반이 사라집니다.

디자이너라면 — KRDS 공식 Figma(@krds) 라이브러리에서 푸터 컴포넌트를 가져다 쓸 수 있습니다. 직접 그리지 말고 표준 컴포넌트를 배치하면, 운영기관 정보·정책 링크·연락처의 구성과 간격이 기준에 맞춰집니다. 특히 모바일에서 푸터가 어떻게 세로로 쌓이는지를 디자인 단계에서 미리 정의해 두면, 구현 단계의 레이아웃 붕괴를 막을 수 있습니다.

기획자라면 — 화면 정의서에 "푸터"라고만 적지 말고, 들어갈 항목을 구체적으로 명시하세요. "운영기관명·주소·대표번호·이메일·개인정보처리방침·이용약관·웹접근성안내·저작권"처럼 목록으로요. 특히 개인정보처리방침처럼 법적 고지 의무가 있는 항목은 반드시 체크하고, 그 링크가 실제 문서로 연결되는지까지 확인 항목에 넣으세요. 이 한 줄이 디자인·개발 단계의 누락을 막습니다.

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

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

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

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

시맨틱 마크업 여부: 푸터 영역이 <footer> 또는 role="contentinfo"로 선언돼 랜드마크로 인식되는지
필수 정보 존재: 운영기관 정보, 연락처, 개인정보처리방침을 비롯한 정책 링크가 푸터에 있는지
링크 접근성: 푸터 안 링크들이 의미 있는 텍스트를 갖는지, 아이콘 링크에 접근 가능한 이름이 있는지
일관성: 여러 페이지를 분석했을 때 푸터 구성이 페이지마다 동일하게 유지되는지

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

리포트를 어떻게 읽나

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

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

자주 묻는 질문

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

Q. 푸터에 정보를 너무 많이 넣으면 지저분해지지 않나요?

완전성과 정돈은 충돌하는 목표가 아닙니다. 핵심은 "필요한 정보를 다 담되, 의미 단위로 묶어 정돈하는 것"입니다. 운영기관·연락처·정책 링크·관련 사이트를 각각 그룹으로 구분하고 시각적으로 정렬하면, 정보가 많아도 어수선해 보이지 않습니다. 오히려 정보가 빠진 푸터가 더 불안해 보입니다. KRDS 킷의 푸터는 이 "많지만 정돈된" 구성을 표준으로 제공합니다.

Q. 개인정보처리방침은 푸터가 아니라 별도 페이지에 둬도 되나요?

방침 문서 자체는 별도 페이지에 있는 게 정상입니다. 중요한 건 그 문서로 가는 링크가 푸터에 있어야 한다는 점입니다. 사용자는 정책 링크를 푸터에서 찾도록 학습돼 있습니다. 다른 데에만 두면 "어디 있지?" 하고 헤매게 됩니다. 푸터에 명확한 링크를 두고, 클릭하면 별도 문서로 가는 게 표준 패턴입니다.

Q. 푸터를 `<footer>`로 안 쓰고 `<div>`로 써도 보기엔 똑같은데, 정말 문제가 되나요?

보이는 사람에겐 똑같습니다. 하지만 스크린리더 사용자에겐 랜드마크 탐색이 되느냐 안 되느냐의 차이입니다. <footer>나 role="contentinfo"로 선언돼 있으면 단축키 한 번으로 사이트 정보 영역에 점프할 수 있는데, <div>면 본문 전체를 거쳐야 합니다. 코드 한 줄 차이로 누군가의 탐색 시간이 크게 달라집니다. "보이는 게 같으니 괜찮다"는 함정에 빠지기 쉬운 대표적 항목입니다.

Q. 연락처 이메일을 이미지로 넣어 스팸을 막는 관행이 있던데요?

스팸 방지는 이해하지만, 접근성을 희생하면서까지 할 일은 아닙니다. 이메일을 이미지로만 넣으면 시각장애인 사용자는 그 연락처를 전혀 쓸 수 없습니다. 스팸이 정말 걱정된다면 이미지 대신 다른 보호 방식(예: 자바스크립트로 조합, 문의 폼 제공 등)을 검토하세요. 어떤 방식이든, 핵심 연락 수단이 특정 사용자에게 막혀선 안 됩니다.

Q. 푸터가 페이지마다 조금씩 다른데, 통일하는 게 그렇게 중요한가요?

중요합니다. 첫째, 사용자 입장에서 어느 페이지에 있든 같은 자리에서 같은 정보를 찾을 수 있어야 인지 부담이 줄어듭니다. 둘째, 관리 측면에서 페이지마다 다른 푸터는 "어디는 갱신되고 어디는 안 된" 누락을 만듭니다. 개인정보처리방침이 한 페이지에서만 빠져도 그건 문제입니다. 푸터를 전역 컴포넌트로 한 번만 정의해 모든 페이지에 적용하는 게, 일관성과 관리 효율 둘 다 잡는 방법입니다.

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

전부 갈아엎을 필요는 없습니다. 먼저 ViewCheck로 현황을 확인해 "지금 푸터에 무엇이 빠졌고, 어느 페이지에서 어떤 문제가 있는지"를 목록으로 만든 다음, 우선순위대로 치명적인 것부터 고치면 됩니다. 특히 개인정보처리방침 누락이나 시맨틱 마크업 같은 핵심부터 손보면, 적은 작업으로 가장 많은 효과를 볼 수 있습니다. 리뉴얼 예산을 한 번에 들이지 않고도 점진적으로 끌어올리는 게 현실적인 전략입니다.

Q. 관련 사이트 드롭다운까지 푸터 점검 대상인가요?

네. 푸터 안에 들어가는 모든 요소는 결국 그 요소의 컴포넌트 기준을 그대로 적용받습니다. 관련 사이트 셀렉트라면 셀렉트 기준(라벨 연결·키보드 조작·예측 가능한 동작)을, SNS 아이콘 링크라면 링크·아이콘 접근성 기준을 따라야 합니다. "푸터 안이니까 대충 해도 된다"는 예외는 없습니다. 오히려 푸터는 여러 컴포넌트가 한자리에 모이는 영역이라, 점검해야 할 항목이 많은 편입니다. 그래서 ViewCheck도 푸터를 단일 규칙이 아니라 여러 CP 규칙의 묶음으로 판정합니다.

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

푸터도 합작입니다. 기획자는 푸터에 들어갈 필수 항목(운영기관·연락처·정책 링크)을 정의하고, 디자이너는 그 구성과 모바일 레이아웃을 시안에 명시하고, 개발자는 그걸 시맨틱 마크업과 접근 가능한 링크로 구현해야 합니다. KRDS가 디자인(Figma)·코드(GitHub 킷)·문서(가이드라인)를 한 세트로 제공하는 이유가 이겁니다. 세 팀이 같은 기준을 보고 일하면 "네 일/내 일" 논쟁이 줄어듭니다.

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

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.min.css / krds.min.js).
KRDS 공식 Figma(@krds) — 디자이너용 푸터 컴포넌트와 구성.

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

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

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

☐ 푸터 영역이 `<footer>` 또는 `role="contentinfo"`로 선언돼 랜드마크로 인식된다.
☐ 운영기관 정보(기관명·주소 등)가 이미지가 아니라 텍스트로 명확히 있다.
☐ 연락처(전화·이메일)가 텍스트로 있고, 모바일에서 전화번호가 tel:로 바로 연결된다.
☐ 개인정보처리방침 링크가 있고, 클릭하면 실제 문서로 정상 연결된다.
☐ 이용약관·웹 접근성 안내 등 필요한 정책 링크가 빠짐없이 있다.
☐ 푸터 안 모든 링크가 의미 있는 텍스트를 갖는다("바로가기" 같은 모호한 표현 금지).
☐ 아이콘 링크(SNS 등)에 접근 가능한 이름(alt)이 있다.
☐ 푸터가 모든 페이지에서 동일하게 유지된다(전역 컴포넌트).
☐ 모바일에서 푸터가 무너지지 않고, 링크 터치 영역이 충분하다.

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

푸터는 맨 아래 회색 박스처럼 보이지만, 사실은 사이트가 "끝까지 책임지는 곳인가"를 보여 주는 영역입니다. 평소엔 아무도 안 보다가, 누군가 정말 급할 때 — 항의할 곳을 찾을 때, 정책을 확인할 때, 이 사이트를 믿어도 되는지 판단할 때 — 모두가 찾는 곳이죠. 그 작은 영역 하나가 누군가에겐 권리를 행사하는 통로이고, 또 누군가에겐 닫힌 문입니다.

오늘 정리한 기준이 많아 보일 수 있지만, 핵심은 결국 단순합니다. 누가 운영하는지 텍스트로 밝히고, 닿을 수 있는 연락처를 두고, 개인정보처리방침을 비롯한 정책을 빠짐없이 연결하고, <footer>로 선언해 누구나 찾을 수 있게 하는 것. 이 네 가지만 챙겨도 푸터의 문제 대부분은 사라집니다. 그리고 그게 잘 됐는지는 ViewCheck로 몇 분이면 확인할 수 있습니다. 완벽을 한 번에 만들 필요는 없습니다. 가장 치명적인 누락 하나부터 고쳐 나가면, 우리 사이트는 분명히 조금씩 더 믿을 만하고, 더 많은 사람에게 열린 곳이 됩니다. 다음 글에서는 푸터와 짝을 이루는 또 다른 전역 영역을 같은 방식으로 뜯어보겠습니다.

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

#KRDS #푸터Footer #공공웹 #디자인시스템 #웹접근성 #ViewCheck #정부웹사이트 #개인정보처리방침 #UIUX #랜드마크 #푸터 #Footer #KRDS기준 #디자인원칙 #표준가이드 #UI컴포넌트 #컴포넌트설계 #전자정부 #디지털정부 #행정안전부