고령자, 모바일 사용자, 저시력, 키오스크까지 — 공공웹 접근성은 정말 '모두'를 위한가
공공 웹사이트 담당자와 대화하다 보면 이런 말을 종종 듣는다. 틀린 말이 아니다. 그 작업들이 실제로 어렵고 중요한 것도 맞다. 그런데 이 말에는 조용한 전제가 하나 숨어 있다. '접근성'이란 곧 '스크린리더 사용자를 위한 것'이라는 전제. 마우스를 못 쓰거나 시력이 전혀 없는 특정 장애 유형을 떠올리며 그 조건만 충족하

다양한 사용자 맥락에서 공공 웹사이트가 얼마나 잘 동작하는지, 우리가 진단하면서 발견한 것들
들어가며 — "장애인용 접근성 항목 다 넣었는데요"
공공 웹사이트 담당자와 대화하다 보면 이런 말을 종종 듣는다.
"저희 사이트는 접근성 인증 받았어요. alt 텍스트도 다 넣고, 키보드 이동도 되고, 명도 대비도 맞췄어요."
틀린 말이 아니다. 그 작업들이 실제로 어렵고 중요한 것도 맞다. 그런데 이 말에는 조용한 전제가 하나 숨어 있다. '접근성'이란 곧 '스크린리더 사용자를 위한 것'이라는 전제. 마우스를 못 쓰거나 시력이 전혀 없는 특정 장애 유형을 떠올리며 그 조건만 충족하면 됐다는 생각.
그런데 현실의 접근성 문제는 훨씬 넓다. 공공 사이트를 쓰는 사람들의 스펙트럼을 생각해 보면 금방 알 수 있다. 70대 어르신이 손주 대신 직접 민원 신청을 하러 들어온다. 지하철에서 한 손으로 스마트폰을 쥐고 버스 시간을 찾는다. 눈이 침침해서 글씨를 200%로 키워놓은 사람이 정책 공고문을 읽으려 한다. 휠체어를 탄 사용자가 주민센터 키오스크 앞에 선다.
이 사람들 각각이 같은 '접근성'을 경험하고 있을까.
이 편에서 우리가 다루려는 건 바로 그 질문이다. 접근성이라는 큰 주제 안에서도, 사용자 맥락에 따라 진단 포인트가 달라진다는 이야기. 그리고 ViewCheck LLM 분석이 그 다양한 맥락을 어떻게 추적하고, 어디까지 포착할 수 있는지—솔직하게—나눠보려 한다.
아직 완벽하게 다 된 건 아니다. 연구 중인 부분이 많다. 그걸 먼저 밝혀두고 시작한다.

한국 사회의 현실 — 초고령화 사회와 디지털 격차
지금 한국 사회를 하나의 키워드로 요약하자면 아마 '초고령화'일 것이다. 통계청 자료에 따르면 한국은 이미 65세 이상 인구 비율이 전체의 18%를 넘어 고령사회에 진입했고, 2025년을 기점으로 20%를 넘겨 초고령사회 진입이 임박하다는 전망이 나온다.
이 변화가 디지털 서비스에 어떤 의미를 갖는가. 과학기술정보통신부가 2025년 3월에 발표한 「2024년 디지털 정보격차 실태조사」를 보면 몇 가지 중요한 수치가 눈에 띈다.
2024년 기준으로 60대의 스마트폰 보유율은 96.9%에 달한다. 언뜻 보면 "고령자도 이제 스마트폰 다 쓰는데 뭐가 문제야?"라고 할 수도 있다. 그런데 같은 조사에서 70대 이상은 73.0%이고, 특히 80세 이상 초고령층은 절반 이상이 여전히 인터넷을 이용하지 못하는 것으로 나타났다. 보유와 활용은 전혀 다른 이야기다.
더 중요한 건 이것이다. 스마트폰은 있지만 '능숙하게 다루는 역량'에서는 일반 국민과 고령층의 격차가 여전히 크다는 점. 2024년 취약계층의 디지털 정보화 수준이 평균 77.5%로 전년 대비 0.6%p 개선됐다고는 하지만, 그 차이는 여전히 크고 줄어드는 속도는 느리다.
공공 웹사이트는 이 현실과 정면으로 마주한다. 민원을 넣으려는 어르신, 복지 혜택을 확인하려는 노인, 세금 신고를 해야 하는 고령 자영업자 — 이들이 정부24, 복지로, 국민건강보험 홈페이지에 접속한다. 그때 그 사이트가 얼마나 '그들을 위해' 설계되어 있는지가 접근성의 현실 테스트다.
그리고 솔직히 말하면, 현재 대부분의 공공 웹사이트는 그 테스트를 그다지 잘 통과하지 못한다. 접근성 인증은 받았지만, 실제로 70대 이상이 혼자 쓰기에는 너무 복잡하고, 글씨가 너무 작고, 내비게이션이 너무 어렵다.
NN/g 연구가 밝힌 것 — 65세 이상은 무조건 느린 게 아니다
Nielsen Norman Group(이하 NN/g)은 고령 사용자 UX 연구의 가장 권위 있는 기관 중 하나다. 2019년에 출간된 「UX Design for Seniors (Ages 65 and older), 3rd Edition」은 고령 사용자 대상 사용성 연구를 기반으로 87개의 구체적인 디자인 가이드라인을 제시한 보고서다.
이 연구에서 흥미로운 발견이 있다. 65세 이상 사용자는 21~55세 사용자에 비해 웹사이트를 사용하는 속도가 평균 43% 느리다. 20년 전 연구에서는 이 차이가 훨씬 더 컸는데, 최근 세대의 고령 사용자들은 디지털 기기에 오래 노출된 덕분에 상당히 적응했다. 그래도 43%는 여전히 큰 차이다.
그런데 NN/g 연구자들이 강조하는 게 있다. 이 속도 차이가 "고령자는 능력이 없어서"가 아니라는 것이다. 디자인이 고령 사용자의 인지적·신체적 특성을 고려하지 않았을 때 나타나는 수행 차이다. 달리 말하면, 디자인을 바꾸면 격차가 줄어든다.
NN/g가 정리한 고령 사용자의 주요 특성은 이렇다:
인지 변화: 새로운 인터페이스 패턴 학습에 시간이 더 걸린다. 단기 기억 용량이 젊은 층보다 작다. 한 번에 여러 정보를 처리하는 멀티태스킹 능력이 낮아진다. 따라서 메뉴 단계가 깊거나, 한 화면에 너무 많은 요소가 있거나, 이전 단계로 돌아가기 어려운 구조는 고령 사용자에게 특히 치명적이다.
시각 변화: 노안으로 인한 초점 조절 어려움, 색상 인식 변화(특히 파란색 계열), 빛에 대한 민감도 증가. 작은 글씨가 큰 장벽이 되는 건 당연하다.
운동 조절: 미세 근육 조절 능력 저하, 손 떨림 증가. 작은 버튼, 좁은 클릭 영역, 드래그 인터랙션이 어려워진다.
NN/g는 또한 새로운 연구에서 "오늘날의 고령 사용자를 20년 전의 고령 사용자 스테레오타입으로 보지 말라"고 강조한다. 지금의 65~75세는 직장에서 디지털 기기를 수십 년 써온 세대다. 이들에게 필요한 건 '단순화'가 아니라 '명확성'이다.
이 연구들이 공공 웹사이트 설계에 주는 함의는 명확하다. 고령 사용자를 위한 좋은 디자인은 곧 모든 사용자에게 좋은 디자인이다. 클리어한 내비게이션, 충분한 글씨 크기, 명확한 피드백, 단순한 인터랙션 패턴 — 이건 장애인 접근성 체크리스트가 아니라 좋은 UX의 기본이다.
행안부 7대 품질 영역 속 '접근성' — 뭘 요구하는가
행안부 「전자정부 웹사이트 품질관리 지침」(고시 제2025-46호, 2025.6.25., 이하 품질관리 지침)은 공공 웹사이트가 갖춰야 할 7대 품질 영역을 규정한다. 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성이 그것이다.
이 중 '접근성' 영역은 KWCAG(한국형 웹 콘텐츠 접근성 지침) 2.2를 준수하는 것을 기본으로 한다. KWCAG 2.2는 국제 표준인 WCAG(Web Content Accessibility Guidelines) 2.1을 기반으로, 한국의 법제도와 현황에 맞게 국가표준으로 지정된 지침이다. 「디지털포용법」에 의거하여 장애인, 고령자 등 정보접근약자가 웹사이트 이용에 불편이 없도록 설계됐다.
KWCAG 2.2가 요구하는 항목들을 고령자·저시력·모바일 관점에서 살펴보면:
인식의 용이성(Perceivable):
- 텍스트가 아닌 콘텐츠의 대체 텍스트 제공
- 색상에만 의존하지 않은 정보 전달
- 명도 대비 — 텍스트와 배경의 대비율 4.5:1 이상 (저시력 사용자에 직접적 영향)
- 콘텐츠 크기 조절 가능 — 200%까지 확대해도 내용·기능 유지
운용의 용이성(Operable):
- 키보드 완전 접근성
- 충분한 시간 제공 — 시간 제한 있는 콘텐츠 조절 가능
- 반짝임 방지 — 광과민성 발작 위험 방지
- 건너뛰기 링크 — 반복 콘텐츠 건너뛰기 기능
이해의 용이성(Understandable):
- 언어 지정 — 페이지 언어 코드 명시
- 오류 정정 — 입력 오류 시 명확한 안내
견고성(Robust):
- 마크업 오류 방지
- 보조기술 호환 — 스크린리더, 화면 확대 프로그램 등과의 호환
이게 현재 법적 최소 기준이다. 그런데 ViewCheck로 공공 사이트들을 분석해 보면, 이 최소 기준조차 충족하지 못하는 경우가 생각보다 많다.
저시력 사용자의 현실 — 200% 확대가 시작이다
저시력(low vision)은 흔히 오해받는다. "시력이 나쁜 사람"이라고 하면 안경을 쓰면 해결된다고 생각하기 쉽다. 그런데 저시력은 교정 불가능한 수준의 시각 손상을 말한다. 돋보기나 안경으로는 충분하지 않고, 화면 전체가 보이지 않거나 시야의 특정 부분이 흐릿하거나, 색 구별이 어렵거나, 빛에 과민한 상태다.
세계보건기구(WHO) 정의에 따르면 저시력은 교정 후 시력이 0.3 미만 또는 시야 20도 미만인 상태를 말한다. 이는 전 세계적으로 수억 명에 해당하는 규모다. 그리고 노화는 저시력의 가장 큰 원인 중 하나다. 황반변성, 녹내장, 당뇨망막병증 — 이런 질환들이 고령층에서 집중적으로 발생한다.
저시력 사용자가 웹사이트를 이용하는 방식을 이해하려면, WCAG가 규정하는 두 가지 핵심 기준을 알아야 한다.
WCAG 1.4.4 텍스트 크기 조절(Resize Text, AA 등급): 브라우저의 기본 기능으로 텍스트를 200%까지 확대했을 때 내용과 기능이 유지되어야 한다. 텍스트가 잘리거나, 겹치거나, 사라지거나, 기능이 동작하지 않으면 실패다. 이게 왜 어렵냐면, 많은 사이트가 고정 폭(fixed width) 레이아웃이나 픽셀 단위 폰트 크기를 쓰기 때문이다. 텍스트만 커지면 레이아웃이 깨진다.
WCAG 1.4.10 리플로우(Reflow, AA 등급): 뷰포트를 320px 너비로 줄였을 때(400% 줌과 동등) 가로 스크롤 없이 콘텐츠를 이용할 수 있어야 한다. 저시력 사용자는 종종 브라우저 확대율을 200%, 300%, 심지어 400%까지 올린다. 이때 레이아웃이 세로 방향으로만 흐르지 않으면, 한 줄을 읽을 때마다 가로 스크롤을 해야 한다. 이건 굉장히 피곤하고 혼란스러운 경험이다. W3C WAI는 이를 "사실상 콘텐츠를 사용 불가능하게 만드는 경험"이라고 표현한다.
ViewCheck가 반응형 분석에서 확인하는 항목 중 하나가 바로 이 리플로우 동작이다. 320px 뷰포트에서 가로 스크롤이 발생하는지, 콘텐츠가 잘리는지를 확인한다. 이건 단순히 "모바일에서 잘 보이냐"의 문제가 아니다. 저시력 사용자가 데스크톱에서 400% 확대해 쓰는 맥락과 직결된다.

모바일 사용자 — 이동 중, 한 손으로, 빠르게
한국의 모바일 인터넷 이용률은 세계 최상위권이다. 공공 웹사이트도 예외가 아니다. 상당수 공공 사이트 트래픽의 절반 이상이 모바일 기기에서 발생한다. 그런데 모바일 사용 맥락은 데스크톱과 근본적으로 다르다.
지하철 안, 한 손은 손잡이를 잡은 채 다른 손만으로 스마트폰을 조작한다. 엄지손가락으로만 화면을 탭하고 스크롤한다. 밖에서 햇빛이 강해 화면이 잘 안 보인다. 와이파이가 끊겨 LTE로 접속 중이다. 알림이 와서 잠깐 앱을 전환했다 다시 돌아온다.
이런 맥락에서 공공 웹사이트를 쓴다고 생각해 보자. 로그인이 필요한데 인증서 앱을 따로 켜야 한다. 민원 신청 양식을 채우다가 중간에 화면이 리셋된다. 첨부파일을 올리려는데 "지원하지 않는 기기"라는 메시지가 나온다. 이건 지금도 공공 사이트에서 실제로 벌어지는 일들이다.
W3C는 2024년 10월에 「WCAG 2.2를 모바일 애플리케이션에 적용하기 위한 지침(WCAG2Mobile)」을 공개했다. 이 문서는 WCAG 2.2의 원칙과 기준을 모바일 앱 맥락에서 어떻게 해석하고 적용할지를 안내한다. 웹 앱과 네이티브 모바일 앱 모두를 아우르며, "웹 페이지"라는 개념을 모바일의 "화면(Screen), 뷰(View), 다이얼로그" 등으로 재해석한다.
모바일 접근성에서 특히 중요한 WCAG 2.2 신규 기준이 있다. 바로 **성공 기준 2.5.8 터치 타겟 크기(최솟값, Target Size Minimum, AA 등급)**다. 이 기준은 클릭/탭 가능한 대상이 최소 24×24 CSS 픽셀 이상이어야 한다고 규정한다. 더 작은 경우에는 24px 지름 원을 그렸을 때 인접 타겟과 겹치지 않는 충분한 여백이 있어야 한다.
왜 이게 중요한가? MIT Touch Lab의 연구에 따르면 평균 성인의 손끝은 16~20mm 너비다. 작은 버튼은 누구에게나 어렵지만, 손 떨림이 있거나 정밀한 손 조절이 어려운 사람들에게는 근본적인 장벽이 된다. 운동 장애가 있는 사용자는 작은 타겟에서 오류율이 최대 75% 더 높다는 연구 결과도 있다. 그리고 여기서 다시 고령자 이야기가 나온다 — 고령층의 운동 조절 능력 변화가 터치 정확도에 직접 영향을 미치기 때문이다.
ViewCheck의 반응형 분석은 모바일(390px) 뷰포트에서 터치 타겟 크기를 점검한다. 44×44px(WCAG가 권장하는 최적 크기이자 Apple HIG/Google Material 가이드라인 기준)에 미달하는 요소를 탐지하고 위반으로 분류한다. 이건 단순한 미적 검사가 아니라 실제 사용 가능성(operability) 검사다.

공공 키오스크 — 배리어프리 의무화 원년
2026년 1월 28일. 이 날짜가 키오스크 업계에서 중요한 의미를 갖는다. 「장애인차별금지 및 권리구제 등에 관한 법률」 2021년 개정에 따라, 공공기관 및 100인 이상 사업장에 설치된 무인정보단말기(키오스크) 전체에 장애인을 위한 정당한 편의 제공 조치를 완료해야 하는 마지막 기한이다.
이 배리어프리 키오스크 의무화는 이미 여러 단계를 거쳐왔다. 공공기관은 2024년부터, 100인 이상 사업장은 2025년 1월 28일부터 적용됐고, 그 이전에 설치된 구형 키오스크까지 포함해 전면 적용되는 시점이 2026년 1월이다.
보건복지부가 2024~2025년에 걸쳐 실시한 조사에서 장애인 540명 중 161명이 키오스크 사용에 어려움을 겪는다고 응답했다. 어려움을 겪는 항목 중 자동주문기(무인 주문 키오스크)가 80.1%로 가장 높았고, 그다음이 셀프 결제기, 티켓 발매기 순이었다.
한국 정부는 2025년 5월에 92억 원 규모의 키오스크 접근성 가속화 프로젝트를 발표했다. 소규모 키오스크 개발사 50곳 이상에 기술 컨설팅을 지원하고, 배리어프리 하드웨어·소프트웨어 개선에 보조금을 지원하는 내용이다.
배리어프리 키오스크의 기본 요건은 무엇인가. 음성 안내, 점자 또는 촉각 버튼, 높이 조절 가능한 화면, 시각·이동 장애인을 위한 대체 수단 제공이 핵심이다. 그런데 서울시 스마트도시 정책에서 고령층 접근성을 더 세밀하게 다룬 지침이 나온 바 있다.
서울디지털재단이 발간한 「고령층 친화 디지털 접근성 표준(키오스크 적용가이드)」(smart.seoul.go.kr)은 3대 원칙, 8개 적용지침, 22개 적용방법으로 구성된다. 3대 원칙은 정보구조, 서비스 흐름, 대체수단이며, 각각 가독성·조작성·이해성·편의성·심미성을 반영한다.
이 가이드가 강조하는 것 중 하나가 바로 '서비스 흐름의 단순화'다. 고령 사용자가 키오스크에서 목적을 달성하지 못하고 포기하거나, 주변 직원의 도움을 구하게 되는 이유는 대부분 복잡한 단계, 불명확한 현재 위치 표시, 오류 메시지 이해 어려움에서 온다.

키오스크와 웹사이트의 연결고리 — KRDS는 어디까지 닿는가
여기서 잠깐 짚어야 할 게 있다. 이 편에서 우리가 키오스크 이야기를 꺼낸 건, ViewCheck가 키오스크를 직접 분석하기 때문이 아니다. ViewCheck는 웹사이트를 분석하는 도구다.
그런데 키오스크 접근성 이야기가 공공 웹 접근성과 맞닿는 지점이 있다. 많은 공공 기관 키오스크가 내부적으로 웹 기반 UI를 실행한다. 즉, 키오스크 화면에 표시되는 것이 실은 크롬이나 임베디드 브라우저에서 돌아가는 웹 페이지다. 이 경우 KRDS의 디자인 시스템 원칙 — 충분한 터치 타겟 크기, 명도 대비, 폰트 크기 기준 — 이 키오스크 UI에도 직접 적용된다.
KRDS가 규정하는 디자인 토큰은 색상 586개, 전체 768개다. 이 토큰들은 공공 웹사이트와 앱 전반에 걸쳐 일관된 시각적 기준을 제공하도록 설계됐다. 폰트 크기 토큰, 간격 토큰, 색상 대비 토큰 — 이것들이 고령자와 저시력 사용자에게 친화적인 수준인지가 ViewCheck DS(Design System) 분석의 핵심이다.
KRDS의 공식 사이트(krds.go.kr)는 디지털 포용 섹션에서 이를 명시한다. 고대비 모드 지원, 고령자와 장애인 모두가 동등한 노력으로 서비스를 이용할 수 있도록 하는 것이 KRDS 설계의 원칙 중 하나라고 밝히고 있다.
ViewCheck LLM 분석의 DS 카테고리 — KRDS 846규칙 중 DS(Design System) 120개 — 는 이 원칙들을 실제 사이트에 적용했을 때 어떤 결과가 나오는지를 검사한다. 색상 대비가 기준에 맞는지, 폰트 크기가 최솟값 이상인지, 간격이 터치에 적합한지. 이건 단순한 스타일 심미 검사가 아니다. 고령자와 저시력 사용자가 실제로 읽고 조작할 수 있는지의 실용적 검사다.
KRDS 846규칙으로 보는 접근성 — CP, BP, SP 카테고리의 역할
ViewCheck LLM 분석이 진단하는 KRDS 846규칙은 크게 네 카테고리로 나뉜다. DS(디자인 시스템) 120개, CP(컴포넌트) 446개, BP(기본 패턴) 108개, SP(서비스 패턴) 172개. 이 카테고리들이 접근성 관점에서 어떤 의미를 갖는지 살펴보면 훨씬 입체적으로 이해할 수 있다.
CP(Component) 446개 — 컴포넌트 레벨 접근성:
버튼, 입력 필드, 드롭다운, 모달, 탭, 아코디언 같은 개별 UI 컴포넌트들이 ARIA 속성을 올바르게 갖추고 있는지, 키보드로 접근·조작 가능한지, 충분한 크기인지를 검사한다. 고령자가 폼을 작성할 때, 저시력 사용자가 드롭다운 메뉴를 탐색할 때, 모바일 사용자가 날짜 선택기를 조작할 때 — 이 CP 규칙들이 실제 경험을 좌우한다.
예를 들어, 많은 공공 사이트 입력 폼에서 에러 메시지가 빨간색으로만 표시되고 텍스트 설명이 없는 경우가 있다. 색각이상(Color Vision Deficiency)을 가진 사용자나 고대비 모드를 쓰는 저시력 사용자에게 이 에러는 보이지 않는다. CP 규칙은 이런 케이스를 잡아낸다.
BP(Basic Pattern) 108개 — 패턴 레벨 접근성:
로그인, 회원가입, 검색, 필터링, 정렬 같은 기본 인터랙션 패턴의 접근성을 검사한다. 폼 구조가 올바른지, hover/focus 상태가 명확한지, 에러 복구 흐름이 친화적인지. 특히 focus 상태 가시성은 키보드 사용자와 저시력 사용자 모두에게 중요하다. 지금 어디에 포커스가 있는지 시각적으로 명확하게 보여야 한다.
고령자 관점에서는 타임아웃 처리도 중요한 BP 이슈다. 세션 만료 시간이 짧거나, 폼 작성 중 자동 로그아웃되거나, 이전 단계로 돌아가면 입력 내용이 사라지는 패턴은 타이핑이 느린 고령 사용자에게 큰 좌절을 준다.
SP(Service Pattern) 172개 — 서비스 흐름 레벨 접근성:
로그인 완료 후 메인으로 이동, 검색 결과 제공, 신청서 제출 완료 확인 같은 전체 서비스 흐름을 검사한다. 이 레벨은 개별 요소가 아닌 흐름 전체의 접근성이다. 고령 사용자가 민원 신청을 완료했을 때 "신청이 접수됐습니다"라는 명확한 피드백이 있는지, 다음 단계가 무엇인지 안내가 있는지 같은 것들이다.
반응형 분석과 접근성의 교차점
ViewCheck 24기능 중 하나가 '반응형 품질' 분석이다. 이건 단순히 "모바일에서 레이아웃이 망가지느냐"를 넘어 세 가지 뷰포트(Desktop 1920px, Tablet 768px, Mobile 390px)에서 각각 접근성 관련 요소들이 어떻게 동작하는지를 본다.
왜 이게 중요한가. 같은 사이트가 데스크톱에서는 접근성을 만족하더라도, 모바일에서는 전혀 다른 레이아웃으로 렌더링될 수 있기 때문이다. 데스크톱에서는 버튼이 충분히 크지만 모바일에서 작아지거나, 데스크톱에서는 텍스트가 읽기 좋지만 모바일에서 폰트 크기가 줄거나, 스크롤이 가로로 발생하거나.
ViewCheck의 다중 페이지 분석(기본 10~100페이지, 최대 1,000페이지)은 이 반응형 접근성 문제가 특정 페이지에만 있는 건지, 아니면 사이트 전체 패턴인지를 파악하게 해준다. 메인 페이지는 멀쩡한데 실제 민원 신청 페이지나 공지사항 상세 페이지에서 반응형이 깨지는 경우가 종종 있다. 메인 페이지만 보면 놓친다.
그리고 이 반응형 분석이 저시력 사용자와도 연결된다. 모바일 390px 뷰포트 테스트는 실은 데스크톱에서 400% 줌한 저시력 사용자 경험과 수치적으로 동등한 조건이다. WCAG 1.4.10 리플로우 성공 기준이 바로 이 원리로 설계됐다.
실제 진단 사례 — 고령 친화적인 척하는 사이트들
우리가 ViewCheck로 여러 공공 사이트를 분석하면서 발견한 패턴 중 하나가 있다. 공식 접근성 인증 마크는 있지만, 실제 고령 사용자 관점에서는 여전히 어려운 사이트들이 제법 있다는 것.
몇 가지 흔한 패턴을 정리해 본다. (특정 기관 지목 없이, 패턴만 서술한다.)
패턴 1 — 글씨는 키웠는데 레이아웃이 깨진다
"고령자 접근성을 위해 폰트 크기를 키웠습니다"라고 공지하는 사이트가 있다. 그런데 실제로 브라우저에서 200% 확대를 해보면 내비게이션이 겹치고, 사이드바가 콘텐츠 위에 올라가고, 텍스트가 잘린다. WCAG 1.4.4를 만족하지 못하는 상태인데도, "큰 폰트 버전을 제공했다"는 사실에 안주하는 케이스다.
패턴 2 — 색상 대비는 맞췄는데 아이콘이 색상만으로 정보를 전달한다
WCAG 색상 대비 기준(4.5:1)은 맞췄다. 그런데 경고를 표시할 때 빨간 아이콘만 사용하고 텍스트 레이블이 없다. 색각이상 사용자나 고대비 모드를 쓰는 사용자에게 이 아이콘은 의미를 전달하지 못한다. WCAG 1.4.1(색상 의존 금지) 위반이다.
패턴 3 — 모바일 버전이 따로 있는데 접근성이 데스크톱 버전보다 나쁘다
m.사이트.go.kr 형태로 모바일 버전을 별도로 운영하는 사이트들이 있다. 이런 경우 모바일 버전에 ARIA 속성이 적거나, 폼 레이블이 없거나, 키보드 접근이 안 되는 경우가 종종 있다. 데스크톱 버전에서 접근성 작업을 했지만 모바일 버전에는 반영이 안 된 상태.
패턴 4 — 팝업이 포커스 트랩이다
모달이나 팝업이 열렸을 때 키보드 포커스가 팝업 안에 갇히지 않는 사이트들이 있다. 팝업 뒤 배경 콘텐츠에 계속 접근 가능해서, 스크린리더 사용자는 배경과 팝업을 혼동하게 된다. 이건 CP 규칙의 모달 접근성 항목에서 잡힌다.
패턴 5 — 타임아웃이 짧고 경고 없이 세션이 끊긴다
민원 신청 폼을 작성하다가 30분쯤 지나면 자동 로그아웃되는 사이트들이 있다. 경고 메시지 없이. 타이핑이 느린 고령 사용자, 또는 폼을 작성하다가 필요한 서류를 찾으러 잠깐 자리를 뜬 사람에게 이건 큰 좌절이다. WCAG 2.2.1(타이밍 조절 가능) 관련 이슈다.
이런 패턴들을 ViewCheck 분석으로 전부 자동으로 잡을 수 있냐고 묻는다면 — 솔직히 아직은 아니다. 일부는 잡히고, 일부는 LLM 분석이 추론하거나, 일부는 아직 "확인 필요" 상태로 남는다.

ViewCheck LLM 분석의 24기능 — 접근성 관련 카드들
ViewCheck LLM 분석의 24개 기능 카드 중 접근성과 직결되는 것들을 정리해 보면:
접근성 KWCAG 카드: KWCAG 2.2 기반 34개 항목을 자동으로 점검하고 결과를 대화로 보여준다. 각 항목이 통과인지, 미통과인지, 해당 없음인지와 함께 근거를 제시한다. "왜 이 항목이 실패인가"를 설명하는 RAG 기반 근거가 함께 나온다.
디자인 스타일(DS) 카드: KRDS DS 120개 규칙 — 색상 대비, 폰트 크기, 간격, 레이아웃 — 을 검사한다. 고령자와 저시력 사용자에게 영향을 미치는 시각적 기준들이 여기 모여 있다.
컴포넌트(CP) 카드: KRDS CP 446개 규칙 — 버튼, 폼, 모달, 탭 등 개별 UI 요소의 접근성과 ARIA 속성. 이 카드에서 "이 사이트의 버튼에 ARIA 레이블이 없다", "입력 필드에 레이블이 연결되지 않았다" 같은 구체적 위반 항목이 목록으로 나온다.
반응형 카드: 3개 뷰포트(Desktop/Tablet/Mobile)에서의 레이아웃 품질. 터치 타겟 크기, 리플로우 이슈, 폰트 크기 변화를 추적한다.
웹 성능 카드: 저연결 환경(모바일 사용자, 농어촌 지역 사용자)에서의 접근 가능성과 직결된다. LCP, FCP, TTFB 같은 Core Web Vitals가 나쁘면 느린 기기를 쓰는 사용자, 저속 인터넷 환경의 사용자가 사실상 콘텐츠에 접근하지 못한다.
오류 리스트 카드: 모든 접근성 위반 항목이 카테고리·심각도별로 정리되어 나온다. P0(즉시 수정)부터 P3(권장사항)까지 우선순위가 매겨진다.
AI 종합 리포트 카드: 위 모든 분석을 바탕으로 "이 사이트의 접근성 개선 우선순위는 무엇인가", "고령자 사용성 관점에서 가장 시급한 이슈가 무엇인가" 같은 맥락적 질문에 대화로 답한다. 단순히 "몇 개 위반"이 아니라, "어떤 사용자에게 어떤 영향을 미치는가"를 설명한다.
LLM 분석의 Q&A 기능 — 접근성 맥락으로 대화하기
ViewCheck LLM 분석의 특징 중 하나가 단순 결과 출력이 아니라 대화가 가능하다는 점이다. 24개 카드의 결과를 바탕으로 후속 질문을 던질 수 있다.
예를 들어 이런 질문들:
"이 사이트에서 70대 이상 사용자가 사용하기 가장 어려운 부분이 뭔가요?"
"저시력 사용자가 200% 확대 시 어떤 문제가 발생하나요?"
"모바일에서 한 손 조작 시 어떤 요소가 탭하기 어려운가요?"
"접근성 위반 중 키오스크 웹 UI에 직접 영향을 줄 수 있는 항목이 있나요?"
이런 질문들에 대해 LLM 분석은 앞에서 수집된 846규칙 판정 결과, KWCAG 점검 결과, 반응형 분석 결과를 바탕으로 답한다. 근거 데이터 없이 "일반적으로..." 식의 답을 내놓는 게 아니라, 이 사이트의 이 페이지에서 발견된 이 항목을 근거로 답한다.
물론 아직 완벽하지 않다. LLM이 접근성 도메인 지식을 얼마나 정확하게 갖고 있는지, RAG 컨텍스트가 얼마나 관련성 높은 정보를 끌어오는지에 따라 답의 품질이 달라진다. 이건 솔직히 아직 개선 중인 부분이다.
KWCAG와 WCAG — 무엇이 같고 무엇이 다른가
공공 웹 담당자 중에 KWCAG(Korean Web Content Accessibility Guidelines)와 WCAG(Web Content Accessibility Guidelines)를 혼동하는 경우가 있다. 간략히 정리해 두는 게 도움이 될 것 같다.
WCAG 2.2(W3C, 2023.10.5. 권고안): W3C(World Wide Web Consortium)가 발행하는 국제 웹 접근성 표준. 인식의 용이성(Perceivable), 운용의 용이성(Operable), 이해의 용이성(Understandable), 견고성(Robust) 4개 원칙, 13개 지침, 다수의 성공 기준으로 구성. A, AA, AAA 세 등급. 한국을 포함한 전 세계 법적 기준의 토대.
WCAG 2.2에서 새로 추가된 성공 기준 9개 중 접근성 사용자 맥락과 특히 관련 깊은 것들:
- 2.4.11 포커스 표시(최소, AA): 키보드 포커스가 시각적으로 명확하게 표시되어야 함
- 2.4.12 포커스 표시(향상, AAA): 더 엄격한 포커스 가시성 요구
- 2.5.7 드래그 동작(AA): 드래그로만 달성 가능한 기능에 대안 제공 (운동 장애, 고령자)
- 2.5.8 타겟 크기 최솟값(AA): 최소 24×24px 터치 타겟
KWCAG 2.2(한국 국가표준): WCAG 2.1을 기반으로, 국내 법령(「디지털포용법」, 「장애인차별금지법」 등)과 현황에 맞게 조정된 한국형 표준. 행안부 품질관리 지침에서 준수 의무 부과. 2024년 개정된 최신 버전이 KWCAG 2.2다.
KWCAG 2.2는 총 34개 검사 항목으로 구성된다. 일부 WCAG 2.2 신규 기준이 반영되어 있고, 한국 웹 환경의 특수성(ActiveX 의존성, 공공 인증 시스템 등)을 고려한 조항들이 포함된다.
ViewCheck LLM 분석의 '접근성 KWCAG' 카드는 이 34개 항목을 자동으로 점검한다. 단, 모든 항목이 100% 자동 판정 가능한 건 아니다. 일부는 실제 사용자 테스트나 전문 인력의 판단이 필요하다. 그 한계도 함께 표시된다.
저시력과 색상 — 4.5:1 명도 대비의 의미
WCAG/KWCAG에서 명도 대비 기준으로 4.5:1을 요구한다(AA 등급, 일반 텍스트). 이게 어느 정도인지 감이 잘 안 오는 경우가 많다.
명도 대비비(contrast ratio)는 전경색과 배경색의 밝기 차이를 수치로 표현한 것이다. 최솟값인 1:1은 완전히 같은 색(보이지 않음), 최댓값인 21:1은 흰 배경에 검은 글씨(최대 대비). WCAG AA는 일반 텍스트에서 4.5:1, 대형 텍스트(18pt 이상 또는 14pt 굵게)에서 3:1을 요구한다.
4.5:1이 왜 이 숫자냐면, 중등도 저시력 사용자(교정 시력 약 0.3 정도) 기준에서 충분히 읽기 가능한 대비를 연구로 산출한 것이다. 달리 말하면, 이 기준을 충족하는 색상 조합은 저시력이 없는 사람에게는 아무 문제 없지만, 저시력 사용자에게는 읽을 수 있는 최소 조건을 의미한다.
한국 공공 웹사이트에서 흔한 위반 패턴을 보면:
- 연한 회색 텍스트(보조 정보, 날짜, 부제목 등)가 흰 배경에 올라올 때 4.5:1 미달
- 파란 하이퍼링크가 특정 배경색에서 충분한 대비를 확보하지 못할 때
- 플레이스홀더 텍스트가 너무 연해서 저시력 사용자가 입력 필드인지 인식하지 못할 때
ViewCheck DS 분석은 실제 페이지에서 렌더링된 색상 값을 추출해 대비비를 계산한다. CSS에서 선언된 값이 아니라, 브라우저가 최종적으로 렌더링한 computed 색상 기준이다. 이게 왜 중요하냐면, CSS 변수나 상속, 오버라이드에 의해 실제 렌더링 색이 달라질 수 있기 때문이다.
노인 사용자를 위한 설계 — NN/g의 87가지 교훈
NN/g가 제시한 고령 사용자 설계 가이드라인 87개 중 공공 웹에 특히 적용 가능한 것들을 추려 보면:
타이포그래피 관련:
- 본문 폰트 크기 최소 14pt(픽셀로 약 18.67px) 이상
- 줄 간격 1.5배 이상
- 좁은 폰트 사용 자제, 산세리프 폰트 선호
- 모두 대문자(ALL CAPS) 지양 — 판독성 저하
내비게이션 관련:
- 현재 위치(Breadcrumb)를 항상 표시
- 뒤로 가기 기능이 명확하고 신뢰성 있게 동작
- 메뉴 단계 최소화 (3단계 이내 권장)
- 열린 메뉴와 닫힌 메뉴 상태가 시각적으로 명확
인터랙션 관련:
- 클릭/탭 대상이 충분히 크고 간격이 충분
- 실수로 누른 경우 쉽게 취소 가능
- 진행 중인 프로세스(폼 작성 등)에서 충분한 시간 제공
- 완료 후 명확한 성공 피드백
인지 부하 관련:
- 한 화면에 집중해야 할 정보를 최소화
- 전문 용어, 관료적 표현 지양
- 에러 메시지를 구체적이고 이해하기 쉬운 언어로 작성
- 이전 입력 내용을 기억해 두고 다시 채워주는 자동완성
이 가이드라인들이 현재 ViewCheck가 완전 자동으로 검사할 수 있는 건 아니다. 일부는 KWCAG나 KRDS 규칙에 매핑되어 자동 감지되고, 일부는 LLM 분석의 추론 영역이며, 일부는 실제 사용자 테스트 없이는 확인 불가다. 이 경계를 명확히 알고 쓰는 게 중요하다.
왜 '다중 페이지 분석'이 접근성에서 특히 중요한가
ViewCheck의 다중 페이지 분석 기능(기본 10~100페이지, 최대 1,000페이지)은 접근성 진단에서 단일 페이지 분석보다 훨씬 가치 있는 정보를 제공한다.
이유는 이렇다. 많은 공공 사이트가 메인 페이지는 신경 써서 관리하지만, 하위 페이지 — 특히 실제 민원 신청 폼이 있는 페이지, 공고문 상세 페이지, 검색 결과 페이지 — 는 관리가 소홀하다. 메인 페이지만 보면 "이 사이트 접근성 괜찮네"라는 잘못된 결론이 나올 수 있다.
다중 페이지 분석에서 ViewCheck는 '가장 나쁜 페이지'를 기준으로 사이트 전체를 평가한다(OR 로직). 100페이지 중 1페이지라도 중대한 접근성 위반이 있으면 그게 사이트 전체의 위험 요소다. 고령 사용자가 그 한 페이지에 접근했을 때 좌절하고 이탈한다면, 나머지 99페이지가 완벽해도 의미가 없다.
또한 일관성(Consistency) 문제가 있다. 어떤 페이지에서는 메뉴가 키보드로 작동하는데, 다른 페이지에서는 안 된다. 어떤 페이지에서는 에러 메시지가 명확한데, 다른 페이지에서는 "오류가 발생했습니다"라는 모호한 메시지만 나온다. 이런 일관성 문제는 다중 페이지를 분석해야 보인다.

자동 진단의 한계 — 솔직하게
지금까지 ViewCheck LLM 분석이 할 수 있는 것들을 주로 이야기했다. 이제 할 수 없는 것들을 솔직하게 이야기해야 한다. 이게 더 중요하다고 생각한다.
자동으로 잡을 수 없는 접근성 문제들:
첫째, 의미 이해. 이미지에 alt 텍스트가 있는지는 확인할 수 있다. 그런데 그 alt 텍스트가 이미지를 제대로 설명하는지, 불필요하게 장황하지는 않은지, 맥락에 맞는지는 자동으로 판단하기 어렵다. 이건 인간의 판단이 필요하다.
둘째, 인지 부하. "이 콘텐츠가 고령 사용자에게 이해하기 쉬운가?"는 텍스트 분석으로 어느 정도 추론할 수 있지만, 실제 고령자가 테스트해야 확인할 수 있다.
셋째, 실제 사용 가능성. 기술적으로 키보드 접근이 가능하더라도, 실제 고령 사용자가 그 키보드 내비게이션 구조를 이해하고 사용할 수 있는지는 다른 이야기다.
넷째, 동적 콘텐츠. Playwright로 JavaScript를 실행하면서 DOM을 캡처하지만, 사용자 상호작용에 의해 동적으로 생성되는 콘텐츠 — 예를 들어, 날짜 선택기를 열었을 때 나타나는 캘린더 UI 내부 — 는 분석이 제한적이다.
다섯째, 스크린리더 실제 동작. ARIA 속성이 올바르게 설정됐는지는 확인하지만, 실제 스크린리더(Windows의 NVDA, macOS의 VoiceOver, iOS의 VoiceOver 등)에서 어떤 경험을 제공하는지는 자동 분석만으로는 완전히 파악할 수 없다.
이런 한계들을 인식하고, ViewCheck LLM 분석을 "전문 접근성 감사(Audit)의 대체재"가 아니라 "1차 자동 스크리닝 + 우선순위 도출 도구"로 쓰는 게 맞다.
공공 키오스크 접근성 의무화가 웹 담당자에게 주는 신호
키오스크 배리어프리 의무화(2026년 1월 전면 적용)는 단순히 물리적 하드웨어 변경의 문제가 아니다. 많은 공공 키오스크가 웹 기반 UI를 사용하는 만큼, 웹 접근성 기준과 직결된다.
그리고 더 큰 그림이 있다. 2026년 1월 키오스크 의무화는, 한국 사회에서 디지털 접근성에 대한 법적·사회적 기대 수준이 올라가고 있다는 신호다. 키오스크에서 시작된 이 변화는 자연스럽게 모바일 앱, 공공 웹사이트 전체로 확산될 가능성이 높다. 「장애인차별금지법」 개정의 흐름, WCAG 2.2 기반의 KWCAG 2.2 업데이트, 디지털포용법 시행 — 이 모든 것이 같은 방향을 가리킨다.
아직 공공 웹사이트는 접근성 인증만 받으면 "했다"고 여기는 분위기가 있다. 그런데 인증이 최솟값이지 최선이 아니다. 키오스크 의무화가 촉발한 고령자·장애인 디지털 접근성 논의가 공공 웹 전체로 확산될 때, 준비된 기관과 그렇지 않은 기관의 차이가 드러날 것이다.
ViewCheck LLM 분석이 이 흐름에서 할 수 있는 역할은, 현재 사이트의 접근성 현황을 빠르게 파악하고, 개선 우선순위를 도출하고, 근거 있는 개선 방향을 제시하는 것이다. 전문 접근성 컨설턴트 없이도, 담당자가 스스로 현황을 파악하고 외주 개발사와 구체적인 이야기를 나눌 수 있도록.
접근성은 특수한 배려가 아니라 기본 품질이다
이 편 전체를 관통하는 메시지를 하나로 정리하면 이렇다.
접근성은 장애인을 위한 특수한 배려 기능이 아니다. 공공 웹사이트 이용자의 상당 비율이 고령자, 저시력 사용자, 이동 중 모바일 사용자, 키오스크 이용자다. 이 사람들을 위한 접근성은 곧 모든 사람을 위한 더 나은 UX다.
NN/g의 연구가 보여주듯, 고령 사용자를 위한 명확한 내비게이션, 충분한 텍스트 크기, 명확한 피드백은 젊은 사용자에게도 더 좋은 경험을 준다. 저시력 사용자를 위한 충분한 색상 대비는 밝은 햇빛 아래서 스마트폰을 쓰는 모든 사람에게 도움이 된다. 모바일에서의 충분한 터치 타겟 크기는 겨울에 장갑을 낀 모든 사람에게 유용하다.
접근성을 "체크리스트 항목"이 아니라 "사용자 경험의 기본 품질"로 이해하는 것 — 그게 이 모든 논의의 출발점이다.
그리고 그 첫 걸음은, 지금 우리 사이트가 다양한 사용자 맥락에서 얼마나 잘 동작하는지를 실제로 확인해 보는 것에서 시작된다.
마무리 — 접근성 진단, 어디서부터 시작할까
고령자·모바일·저시력·키오스크라는 네 가지 사용자 맥락을 살펴봤다. 각각이 접근성에 요구하는 것은 조금씩 다르지만, 공통점이 있다. 명확성, 충분함, 일관성. 명확한 정보 구조, 충분한 크기와 대비, 일관된 인터랙션 패턴.
ViewCheck LLM 분석은 이 맥락들 중 일부를 자동으로 점검할 수 있다. 전부가 아니라 일부. 그 한계를 알고 쓰면, 한정된 자원으로 가장 중요한 문제부터 해결하는 데 도움이 된다.
시작이 어렵다면 이렇게 해보는 것도 방법이다. 채팅창에 URL 한 줄을 붙여 넣고 "이 사이트에서 70대 이상이 사용하기 어려운 점이 뭔가요?"라고 물어보는 것. 완벽한 접근성 감사는 아니지만, 어디서부터 시작해야 하는지를 빠르게 파악하는 데는 도움이 될 수 있다.
물론 아직 연구 중인 부분도 많다. LLM이 고령자 사용성 맥락을 얼마나 정확하게 이해하는지, 저시력 접근성 진단의 자동화 한계를 어떻게 극복할 것인지, 키오스크 웹 UI와 공공 웹사이트 진단을 어떻게 연결할 것인지 — 이것들이 우리 앞에 놓인 과제다.
다음 편에서는 또 다른 주제로 이어진다. 이 시리즈 전체가 그렇듯, "답을 드립니다"가 아니라 "이렇게 고민하고 있습니다"라는 기록이다.
참고문헌
국내
행정안전부. (2025). 「전자정부 웹사이트 품질관리 지침」(행정안전부 고시 제2025-46호, 2025.6.25.).
https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636국가법령정보센터. 「전자정부 웹사이트 품질관리 지침」 행정규칙.
https://law.go.kr/LSW/admRulInfoP.do?admRulSeq=2100000260906서울디지털재단. (2022). 「고령층 친화 디지털 접근성 표준(키오스크 적용가이드)」. 서울스마트도시 포털.
https://smart.seoul.go.kr/board/41/7241/board_view.do한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2.
https://a11ykr.github.io/kwcag22/과학기술정보통신부. (2025). 「2024년 디지털 정보격차 실태조사 결과」 발표.
https://eiec.kdi.re.kr/policy/callDownload.do?num=264828&filenum=1&dtime=20250328020727KRDS 공식 사이트. 디지털 포용 — KRDS 소개.
https://www.krds.go.kr/html/site/utility/utility_04.html보건복지부. (2025). 「장벽 없는 키오스크, 합리적 제도개선으로 장애인 정보접근권 강화」 보도자료.
https://www.mohw.go.kr/board.es?mid=a10503000000&bid=0027&list_no=1487865&act=view디지털포용뉴스. (2024). 「고령층의 꾸준한 인터넷 이용 증가, 그러나 여전히 세대 간 격차는 존재」.
https://www.dginclusion.com/news/articleView.html?idxno=1124
해외
Nielsen Norman Group. (2019). UX Design for Seniors (Ages 65 and older), 3rd Edition. — 87 design guidelines based on usability research with people 65 and older.
https://www.nngroup.com/reports/senior-citizens-on-the-web/Nielsen Norman Group. (2024). Usability for Older Adults: Challenges and Changes.
https://www.nngroup.com/articles/usability-for-senior-citizens/W3C Web Accessibility Initiative. (2023). Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation, October 5, 2023 (Updated December 12, 2024).
https://www.w3.org/TR/WCAG22/W3C Web Accessibility Initiative. (2024). Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile).
https://www.w3.org/TR/wcag2mobile-22/W3C WAI. Understanding Success Criterion 2.5.8: Target Size (Minimum).
https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.htmlW3C WAI. Understanding Success Criterion 1.4.10: Reflow.
https://www.w3.org/WAI/WCAG21/Understanding/reflow.htmlThe Korea Times. (2026). Kiosks nationwide must now meet accessibility standards.
https://www.koreatimes.co.kr/southkorea/society/20260128/kiosks-nationwide-must-now-meet-accessibility-standardsSmart City Korea. (2024). Seoul City plans to replace 5000 kiosks with digitally vulnerable friendly ones.
https://smartcity.go.kr/en/2024/06/04/

관련 글
ViewCheck LLM 분석 리포트 읽는 법 — 점수·등급·근거·우선순위 해석에서 행동까지
분석이 끝나고 화면에 숫자가 떴다. 종합 74점. KRDS 846규칙 중 289개 통과, 228개 미통과, 329개 해당없음. 접근성 68점. 보안 91점. 위반 매트릭스에는 빨간 칸과 노란 칸이 뒤섞여 있다. 그런데 막상 이 결과를 받아 든 담당자의 표정이 묘하다. 뭔가 많이 나왔는데, 무엇을 먼저 봐야 할지 모르겠다.
AI 진단, 어디까지 믿어야 하나 — ViewCheck를 활용하는 사람을 위한 정직한 가이드
2026년 어느 날, 공공기관의 웹 담당자 한 명이 AI 분석 결과를 출력해 상사에게 내밀었다고 상상해 보자. "AI가 분석했더니 우리 사이트 KRDS 준수율이 68점입니다." 상사는 고개를 끄덕이며 "그럼 개선 계획 짜세요"라고 했다. 담당자는 돌아가 개발사에 수정 목록을 전달했다. 문제는, 그 68점이 무엇을 근거로
분석 → 개선 → 재진단, 공공웹 품질을 '점수로 관리'한다는 것 — ViewCheck LLM 분석 활용
공공 웹사이트 품질 진단을 맡은 실무 담당자들과 이야기하다 보면, 어느 지점에서 공통된 표정이 나온다. "진단은 했어요. 그런데 그다음은 어떻게 해야 하죠?" 도구를 돌리면 문제 목록이 나온다. 때로는 수백 개, 때로는 수십 페이지짜리 보고서가 나온다. 그리고 거기서 멈춘다. 문제를 고쳤는지 어떻게 확인하지? 개선 후에
