반응형 품질 — 데스크톱·태블릿·모바일 3환경 실측과 터치타겟 44px 연구

한 사이트를 세 화면에서 본다, ViewCheck가 뷰포트마다 무엇을 보는지

---

들어가며 — "PC에서는 잘 되는데 폰으로 들어오면 이상해요"

공공기관 홈페이지 담당자라면 한 번쯤 이런 민원을 받아봤을 것이다.

"PC로 들어오면 잘 나오는데, 폰으로 들어가면 글씨가 너무 작아요." "버튼을 누르려고 했는데 옆에 다른 버튼이 같이 눌려요." "화면이 가로로 잘려서 스크롤을 옆으로 해야 해요."

민원의 언어는 다양하지만, 진단의 언어로 옮기면 결국 같은 곳으로 수렴한다. 반응형 품질 문제다.

반응형(Responsive)이라는 단어는 이제 워낙 자주 쓰여서 오히려 당연한 것처럼 느껴진다. "요즘 사이트는 다 반응형이잖아요."라는 말도 종종 듣는다. 그런데 실제 공공 웹사이트를 분석해 보면, "반응형을 구현했다"와 "반응형 품질이 충분하다"는 전혀 다른 이야기라는 걸 계속 확인하게 된다. 반응형 CSS를 입혔다고 해서 모든 뷰포트에서 사용자 경험이 동등하게 보장되진 않는다. 터치 기반 환경에서의 상호작용, 작은 화면에서의 콘텐츠 가독성, 뷰포트 전환 시의 레이아웃 일관성 — 이 모두가 별개의 점검 항목이다.

ViewCheck는 반응형 품질을 분석할 때 세 개의 뷰포트에서 실제로 페이지를 열어 각각의 결과를 측정한다. 데스크톱(1920px), 태블릿(768px), 모바일(390px). 그리고 터치 인터랙션이 가능한 환경에서 유독 중요해지는 터치타겟 크기 — 최소 44×44 CSS 픽셀이 지켜지고 있는지 — 도 함께 들여다본다.

이 편에서 우리가 다루고 싶은 건 세 가지다. 첫째, "왜 세 뷰포트인가" — 각 뷰포트가 어떤 사용 맥락을 대표하고, 어떤 문제가 그 맥락에서 특히 불거지는지. 둘째, "터치타겟 44px가 왜 중요한가" — WCAG 2.5.8과 2.5.5가 말하는 최소 크기의 근거, 그리고 Apple HIG와 Material Design이 이 숫자를 어떻게 다루는지. 셋째, "ViewCheck는 이걸 어떻게 실측하는가" — 자동 분석의 가능성과 한계를 솔직하게.

미리 말해두고 싶은 건, 이 분야도 쉬운 정답이 없다는 점이다. "모든 버튼을 44×44px로 만들면 됩니까?"라는 질문에 "예, 그렇습니다"라고 단순 답하기 어려운 이유가 있고, 세 뷰포트를 테스트했다고 해서 모든 사용자 환경을 커버했다고 볼 수 없는 이유도 있다. 그 복잡함을 최대한 솔직하게, 그러면서도 실제 분석에서 얻은 데이터를 바탕으로 풀어보려 한다.

---

반응형이라는 말의 무게 — 구현과 품질 사이

반응형 웹 디자인(Responsive Web Design)이라는 개념을 처음 제안한 것은 에단 마르코트(Ethan Marcotte)가 2010년 A List Apart에 발표한 글이다. 핵심 아이디어는 단순했다. 하나의 HTML, 하나의 CSS 코드베이스로, 다양한 화면 크기에서 콘텐츠가 유연하게 반응하게 만들자는 것. 당시만 해도 모바일 전용 사이트를 따로 만드는(m.도메인) 방식이 주류였다. 반응형은 그 비효율을 걷어내는 접근이었다.

그로부터 15년이 지난 지금, 반응형은 거의 표준처럼 자리 잡았다. 하지만 동시에 "반응형을 구현했다"는 말이 점점 가벼워지는 경향도 보인다. 실제로 공공 웹사이트 중에는 반응형 CSS를 입혔지만, 모바일에서 콘텐츠가 세로로 스택되면서 핵심 기능이 아래로 밀려나는 경우가 있다. 태블릿 뷰포트에서 모바일처럼도, 데스크톱처럼도 최적화되지 않은 어중간한 레이아웃이 나오는 경우도 있다. 폼 요소가 작은 화면에서 너무 촘촘하게 배치되어 터치가 어려운 경우도 있다.

행정안전부 「전자정부 웹사이트 품질관리 지침」(행안부고시 제2025-46호, 2025.6.25. 개정)은 7대 품질 영역 중 호환성 항목에서 "모바일 운영체제(Android, iOS) 기본 설치 브라우저에서 PC 기능과의 차이, 화면 표시 차이를 검사"하도록 규정하고 있다(행정안전부, mois.go.kr). 즉, 공공 웹사이트가 모바일과 PC에서 동등하게 동작해야 한다는 것은 권고 수준이 아니라 공식 지침의 요구사항이다.

그렇다면 그 "동등하게 동작"의 기준을 어떻게 측정하는가? 사람이 모바일 기기를 손에 들고 직접 확인하는 방법이 가장 정확하겠지만, 수십 수백 개의 페이지를 세 가지 뷰포트로 전부 사람이 확인하는 건 불가능에 가깝다. 그래서 자동화 측정이 필요하고, 그 자동화가 어디까지 신뢰할 수 있는지가 중요해진다.

MDN Web Docs는 반응형 디자인을 이렇게 정의한다. "반응형 디자인은 CSS와 HTML을 사용해 콘텐츠를 조정·숨기거나, 크기를 변경하거나, 요소를 이동시켜 모든 화면에서 보기 좋게 만드는 접근 방식"이라고(MDN Web Docs, 'Responsive Design', developer.mozilla.org). 이 정의에서 핵심은 "조정·숨기거나·이동"이라는 적극적인 변환이다. 단순히 화면이 줄어드는 게 아니라, 화면 크기에 따라 경험이 재설계되어야 한다는 것이다.

---

세 뷰포트의 의미 — 1920, 768, 390

ViewCheck가 반응형 분석에 사용하는 세 뷰포트는 임의로 정한 게 아니다. 각각이 서로 다른 사용 맥락과 물리적 제약을 대표한다.

데스크톱 1920px — 공공 웹사이트의 주요 콘텐츠 레이아웃이 설계되는 기준 화면이다. 행정 업무 처리, 긴 문서 열람, 양식 작성 같은 '무거운' 작업은 여전히 데스크톱 환경에서 많이 이루어진다. 공공기관 담당자나 기업 사용자가 업무용으로 접근할 때는 대개 이 뷰포트다. 이 환경에서의 기준을 확인하는 것은 사이트가 "원래 의도한 대로" 동작하는지를 보는 것과 같다.

태블릿 768px — 흔히 간과되는 뷰포트다. "모바일 대응만 되면 되지 않나요?"라는 생각을 종종 만나는데, 768px 구간은 스마트폰보다 큰 화면을 가진 태블릿 기기, 또는 창 크기를 조절한 노트북 화면에 해당한다. 특히 공공 민원 서비스에서는 노인이나 시각 약자 분들이 태블릿을 편하게 사용하는 경우가 있다. 이 뷰포트에서는 데스크톱 레이아웃이 그대로 유지되기엔 좁고, 모바일 레이아웃이 적용되기엔 넓은 어중간한 구간이 생기기 쉽다. 이 '어중간한 구간'의 처리가 잘 됐는지를 확인하는 게 태블릿 뷰포트 테스트의 핵심이다.

모바일 390px — 2024년 기준 국내 사용자 비중이 높은 스마트폰 화면 크기다(아이폰 14·15 시리즈 기준 390×844px). 공공 민원 서비스를 이용하는 시민 중 상당수는 이 뷰포트에서 접근한다. 좁은 화면에서 터치 인터랙션이 주가 되고, 한 화면에 표시 가능한 콘텐츠 양이 대폭 줄어들며, 폼 요소와 버튼의 배치가 UX에 직접적인 영향을 미친다.

KRDS 공식 가이드(krds.go.kr)의 레이아웃 스타일 가이드는 xsmall(<360px)을 최적화 대상에서 제외하고 small부터 xlarge까지 4단계 브레이크포인트를 적용한다고 명시한다. 모바일 기본 그리드는 4 column이며, 화면 마진은 모바일 최소 16px, PC 최소 24px 이상을 사용하도록 규정한다(KRDS 공식, krds.go.kr/html/site/style/style_05.html). 그리고 간격 체계의 기본은 8-Point Grid — 8px의 배수, 상황에 따라 4px 배수 사용 가능이다.

이 세 수치(1920 / 768 / 390)는 "이 세 가지만 보면 충분하다"는 의미가 아니다. 실제 사용 환경은 이보다 훨씬 다양하다. 다만 세 개의 대표 구간을 체계적으로 확인하는 것이 현실적인 자동화의 출발점이다. 세 개도 충분히 많은 정보를 준다 — 그리고 동시에 세 개로 알 수 없는 것도 있다는 걸 늘 함께 기억해야 한다.

---

터치타겟 44px — 숫자 하나에 담긴 인간공학

이 편의 핵심 숫자 중 하나가 44다. 터치타겟 최소 크기로 44×44 CSS 픽셀(또는 포인트, dp)이 국제 표준들에서 반복적으로 등장한다.

왜 하필 44인가? 인간공학적 연구에서 출발한다. 성인의 손가락 끝(지문이 닿는 부분)의 평균 너비는 약 810mm라는 연구 결과가 있다. 엄지손가락은 더 넓어서 1014mm에 달한다. 이를 화면 해상도로 환산하면, 약 9mm에 해당하는 물리적 크기가 나오고, 이것이 72dpi(Apple의 오리지널 포인트 기준) 기준으로 대략 44pt에 해당한다. Material Design이 제안하는 48dp도 비슷한 인간공학 근거에서 나온 것이다(Material Design, m3.material.io).

중요한 건 이 크기가 시각적 요소의 크기가 아니라는 점이다. 아이콘이 24×24px로 보여도, 그 주위에 패딩이 붙어 터치에 반응하는 영역이 44×44px 이상이면 기준을 충족할 수 있다. 반대로 버튼이 시각적으로 크더라도, 실제 클릭/탭에 반응하는 영역이 작으면 기준을 위반한다. 이 '시각 크기 vs. 터치 반응 영역'의 구분이 실제 점검에서 중요하게 다뤄지는 이유다.

---

WCAG 2.5.8과 2.5.5 — 국제 표준이 말하는 최소 크기

W3C가 2023년 10월에 확정한 WCAG 2.2에는 터치타겟 크기와 직접 관련된 두 개의 성공 기준이 있다.

성공 기준 2.5.8 — Target Size (Minimum), 레벨 AA

WCAG 2.2에서 새롭게 추가된 이 기준은 "클릭 또는 탭 가능한 타겟의 크기는 최소 24×24 CSS 픽셀 이상이어야 한다"는 것이다. AA 수준, 즉 실질적인 의무 적합 수준의 기준이다.

W3C WAI의 공식 이해 문서는 이 기준의 목적을 이렇게 설명한다. "많은 사람들이 마우스 사용이 어렵고, 특히 운동장애가 있는 경우나 모바일 기기에서 터치로 사용하는 경우에 타겟이 작으면 활성화하기 어렵다"라고(W3C WAI, "Understanding Success Criterion 2.5.8: Target Size (Minimum)", w3.org/WAI/WCAG22). 다만 24×24px에는 예외 조건이 있다. 타겟이 24px 미만이더라도, 24px 지름의 원을 그 타겟 중심에 그렸을 때 인접한 다른 타겟과 겹치지 않는다면 허용된다. 문장 안에 포함된 링크도 적용 예외다.

성공 기준 2.5.5 — Target Size (Enhanced), 레벨 AAA

더 엄격한 기준이다. "타겟의 크기가 최소 44×44 CSS 픽셀 이상"이어야 한다(W3C WAI, "Understanding Success Criterion 2.5.5: Target Size (Enhanced)", w3.org/WAI/WCAG22). AAA 수준이므로 모든 사이트에 강제되지는 않지만, Apple HIG와 Material Design이 44pt / 48dp를 권장하는 근거와 같은 맥락에 있다.

이 두 기준 사이 — 24px (AA 최소) vs. 44px (AAA 권장) — 에는 실질적인 간격이 있다. 법적 의무로는 24px면 충족되지만, 실제 사용성 관점에서는 44px를 기준으로 보는 것이 훨씬 현실적이다. 이건 AAArdvark의 2.5.5 설명에서도 확인할 수 있다. "링크, 버튼, 폼 컨트롤 같은 인터랙티브 요소가 44×44px 이상이어야 하며, 이는 운동 능력이 제한된 사용자, 임시 장애가 있는 사용자(한 손 사용 등), 그리고 터치스크린 사용자를 위한 핵심 기준"이라고(AAArdvark, 'WCAG 2.5.5 Target Size Enhanced').

한국형 웹 콘텐츠 접근성 지침(KWCAG 2.2)도 이 기준을 반영한다. UXKM 등 국내 접근성 커뮤니티에서 정리된 KWCAG 2.2 해설에 따르면, 포인터 입력 타겟 크기는 최소 44×44 CSS 픽셀 이상이어야 한다는 기준을 포함하고 있다(UXKM, 'KWCAG 2.2 가이드'). 이웃한 콘텐츠 간에 간격을 두어 터치스크린에서 조작성을 확보하도록 명시하고 있다.

---

Apple HIG와 Material Design — 플랫폼 가이드라인의 시각

WCAG가 "최소한 이것만큼은"이라는 바닥을 제시한다면, 플랫폼 가이드라인들은 "이 정도는 해야 제대로"라는 실용적 기준을 제시한다.

Apple Human Interface Guidelines(HIG)

Apple은 오래전부터 44pt를 최소 터치 타겟 크기로 권장해 왔다. pt(포인트)는 픽셀 독립적인 단위로, 일반 해상도(72dpi)에서는 1pt = 1px이지만, 레티나 디스플레이에서는 1pt = 2px 또는 3px에 해당한다. 물리적으로는 약 9mm 크기다.

Zac Dickerson의 Medium 기사 "Size matters! Accessibility and Touch Targets"(2018)은 이 맥락을 잘 정리한다. "Apple이 자신들의 인터페이스 가이드라인에서 44×44pt를 명시했다"는 점을 지적하며, 터치 타겟이 너무 작을 때 발생하는 오터치(접근하지 않으려 했던 요소를 누르는 것)와 미스터치(목표 요소를 누르지 못하는 것)가 실제 사용성에 미치는 영향을 다루고 있다(Medium/@zacdicko).

흥미로운 점은 Apple HIG의 44pt가 시각적 요소 크기를 의미하는 게 아니라는 것이다. 작은 아이콘 주위에 보이지 않는 터치 영역을 확장하는 방식으로도 충족할 수 있다. 이 원칙은 UI에서 "작아 보이지만 누르기 쉬운" 디자인을 가능하게 하는 근거다.

Material Design 3

Google의 Material Design 3은 터치 타겟 최소 크기로 48×48dp를 권장한다(Material Design, m3.material.io/foundations/designing/structure). dp(density-independent pixel)는 160dpi 화면을 기준으로 정의된 단위다. 48dp는 물리적으로 약 9mm에 해당한다.

Material Design은 이 크기의 근거를 명확히 설명한다. "사람의 손가락 패드는 어린이 기준 810mm, 성인 기준 1014mm이며, 평균은 약 11mm"라는 인간공학 데이터를 들어 48dp가 "대부분의 사용자가 편안하게 탭할 수 있는 최소 크기"라고 명시한다. 또한 "터치 타겟은 시각적 요소를 넘어 확장된다. 예를 들어 아이콘이 24×24dp로 보여도, 그 주위의 패딩이 합쳐져 48×48dp 터치 영역을 구성한다"고 설명한다.

Material Design이 48dp를 권장하고 Apple이 44pt를 권장하는 차이는, 운영체제와 화면 밀도 기준의 차이에서 비롯된다. 물리적 크기로 환산하면 둘 다 약 9mm 수준으로 수렴한다. 숫자가 달라 보이지만 실질적 목표는 같다.

---

WCAG 1.3.4 방향과 1.4.10 리플로우 — 반응형의 두 가지 또 다른 기준

터치타겟만이 모바일 반응형 품질의 전부가 아니다. WCAG 2.1부터 2.2에 걸쳐 반응형 맥락에서 특히 중요한 두 가지 성공 기준이 있다.

WCAG 1.3.4 — Orientation (레벨 AA)

"콘텐츠는 세로 방향 또는 가로 방향으로 제한되어서는 안 된다. 단, 특정 방향이 필수적인 경우는 제외한다"는 기준이다(W3C WCAG 2.1/2.2). 사용자들은 기기를 가로로 눕혀서 사용하기도 하고, 세로로 세워서 사용하기도 한다. 이 전환이 자유로워야 하며, 특정 방향으로 고정하는 것은 많은 사용자에게 심각한 불편이 된다. 특히 모니터 스탠드를 세로로 회전해 사용하는 공공기관 직원이나, 가로 방향이 편한 특정 장애 사용자를 위해 이 기준은 중요하다.

WCAG 1.4.10 — Reflow (레벨 AA)

이 기준은 반응형 품질 전반과 가장 직접적으로 연결된다. "320 CSS 픽셀 너비에서 콘텐츠를 2차원 스크롤(가로+세로 동시 스크롤) 없이 이용할 수 있어야 한다"는 것이다(W3C WAI, w3.org/WAI/WCAG21/Understanding/reflow.html). 320px는 1280px 화면에서 400% 줌인했을 때의 유효 뷰포트 너비다.

이 기준이 왜 중요한가? 저시력 사용자들은 화면을 크게 확대해서 사용하는 경우가 많다. 400%로 확대했을 때 콘텐츠가 수평으로 잘려서 가로 스크롤 없이는 읽을 수 없다면, 그 사이트는 이 그룹의 사용자에게 실질적으로 접근 불가능하다. Silktide의 1.4.10 설명에 따르면 "반응형 디자인의 원칙을 따라 만들어진 웹페이지는 리플로우가 자동으로 이루어지지만, 그렇지 않은 경우 400% 확대 시 수평 스크롤이 발생한다"(Silktide, 'WCAG 1.4.10: Reflow'). 이건 반응형 구현 여부와 별개로, 구체적인 수치를 가지고 검증할 수 있는 기준이다.

ViewCheck의 반응형 분석에서 390px 뷰포트 테스트는 이 리플로우 기준을 실측하는 데 일부 기여한다. 물론 400% 줌인을 직접 시뮬레이션하는 것과 390px 뷰포트를 여는 것은 완전히 동일하지 않다. 그러나 좁은 뷰포트에서 레이아웃이 정상적으로 유지되는지는 리플로우 기준의 중요한 신호가 된다.

---

ViewCheck가 세 뷰포트에서 보는 것들

ViewCheck는 반응형 품질 분석을 위해 Playwright(실제 브라우저 엔진)를 세 가지 뷰포트 설정으로 각각 실행한다. 데스크톱(1920×1080), 태블릿(768×1024), 모바일(390×844). 각 환경에서 페이지를 로드하고 DOM 구조와 CSS 계산값을 수집한다.

각 뷰포트에서 확인하는 주요 항목들은 대략 이런 것들이다.

뷰포트 전환 레이아웃 일관성

같은 페이지가 세 뷰포트에서 각각 어떤 레이아웃으로 렌더링되는지를 확인한다. 데스크톱에서 가로로 나란히 있던 메뉴 항목들이 모바일에서 햄버거 메뉴로 적절히 전환되는지, 탭 UI가 작은 화면에서 선택 가능하게 남아 있는지, 이미지나 미디어 요소가 뷰포트를 초과해서 가로 스크롤을 유발하지 않는지 등이다.

터치타겟 크기 검증

각 인터랙티브 요소(버튼, 링크, 폼 컨트롤, 선택 가능한 아이콘 등)의 클릭/탭 영역 크기를 측정한다. DOM 요소의 getBoundingClientRect()를 통해 요소의 실제 렌더링 크기를 가져오고, 44×44 CSS 픽셀 기준과 비교한다. 이 기준을 충족하지 못하는 요소의 목록과 위치를 기록한다.

다만 여기서 한계를 솔직히 말해야 한다. getBoundingClientRect()로 요소의 시각적 크기는 알 수 있지만, 실제 터치 반응 영역(padding이나 pseudo-element로 확장된 영역)을 완전히 포착하기 어려운 경우가 있다. 요소가 작더라도 CSS로 ::before / ::after를 이용해 터치 영역을 확장하는 패턴이 있는데, 이런 경우는 DOM 분석만으로 완벽하게 탐지하기 어렵다. "이 버튼이 44px 미만입니다"라고 보고하더라도, 실제로는 터치 영역이 충분할 수도 있다는 뜻이다. 결과를 볼 때 이 점을 감안해야 한다.

텍스트 가독성과 콘텐츠 계층

좁은 화면에서 텍스트 크기가 과도하게 작아지거나, 중요한 CTA(행동 유도 버튼)가 스크롤 없이는 보이지 않는 위치로 밀리는 경우를 확인한다. 또한 meta viewport 태그가 올바르게 설정되어 있는지도 본다. user-scalable=no나 지나치게 제한적인 maximum-scale 설정은 사용자가 필요에 의해 화면을 확대하는 것을 막아 접근성을 저해한다.

뷰포트 오버플로

모바일 뷰포트에서 콘텐츠가 뷰포트를 가로로 초과하는 경우를 탐지한다. 이 경우 페이지에 의도하지 않은 수평 스크롤이 생기고, 이는 WCAG 1.4.10 리플로우 기준과 직접 연관된다.

---

공공웹에서 자주 보이는 반응형 문제 패턴

ViewCheck를 통해 다수의 공공 웹사이트를 분석하는 과정에서 반복적으로 등장하는 패턴들이 있다. 특정 사이트를 지목하는 게 아니라, 공공 웹 일반에서 자주 관찰되는 유형으로 정리한다.

패턴 1: 태블릿 구간의 방치

모바일과 데스크톱 두 개의 브레이크포인트만 설정하고, 태블릿 구간을 별도로 처리하지 않는 경우다. 결과적으로 768px에서 데스크톱 레이아웃이 그대로 적용되어 콘텐츠가 작게 표시되거나, 모바일 레이아웃이 너무 일찍 적용되어 화면 공간이 낭비된다. KRDS 가이드가 4단계 브레이크포인트를 제안하는 이유가 여기에 있다.

패턴 2: 터치 영역이 너무 작은 아이콘 버튼

상단 우측의 검색 아이콘, SNS 공유 아이콘, 즐겨찾기 버튼처럼 작은 아이콘 형태의 버튼들이 터치 영역 없이 배치되는 경우다. 아이콘 자체가 24×24px라면, 주변에 최소 10px 이상의 클릭 가능 영역이 추가되어야 44×44px 기준에 근접할 수 있다. 이 패딩 없이 그냥 배치하면, 터치 정밀도가 낮은 사용자(노인, 운동 장애 사용자, 이동 중 사용자)에게 실질적인 장벽이 된다.

패턴 3: 모바일에서 터치 요소가 너무 촘촘하게 배치

목록형 UI, 게시판, 필터 메뉴 등에서 항목들이 좁은 간격으로 나열되어 의도하지 않은 탭이 자주 일어나는 경우다. 특히 공지사항 목록이나 법령·고시 목록처럼 행 높이가 낮게 설정된 페이지에서 빈번하다. WCAG 2.5.8의 예외 조건(24px 원이 겹치지 않으면 허용)을 어기는 배치다.

패턴 4: 고정 너비 테이블이나 이미지의 가로 오버플로

데스크톱 기준으로 고정 너비(예: width: 900px)가 지정된 테이블이나 이미지가 모바일에서 그대로 렌더링되어 페이지 전체에 가로 스크롤이 생기는 경우다. 이는 WCAG 1.4.10 리플로우를 직접 위반한다. 공공 웹사이트에서는 데이터 테이블을 많이 사용하는 특성상 이 패턴이 특히 많이 발생한다.

패턴 5: 모바일에서 메뉴를 찾기 어려운 구조

데스크톱에서 상단 GNB(Global Navigation Bar)로 잘 보이던 메뉴가 모바일에서 햄버거 아이콘 안으로 들어가는 건 일반적이다. 그런데 그 햄버거 아이콘 자체가 너무 작거나, 열었을 때 닫기 버튼이 손가락으로 누르기 어려운 위치에 있거나, 모달처럼 화면 전체를 덮는데 배경 탭으로는 닫히지 않는 경우가 있다. 이런 패턴은 자동 분석보다 실제 인터랙션 테스트에서 더 잘 드러난다.

---

태블릿 뷰포트의 독특함 — 가로 모드와 세로 모드

태블릿 분석에서 빠뜨리기 쉬운 요소가 가로/세로 방향 전환이다. 태블릿 사용자는 기기를 세로로 들기도 하고, 가로로 눕혀서 사용하기도 한다.

WCAG 1.3.4 Orientation 기준이 바로 이 맥락에서 나온다. "콘텐츠를 특정 화면 방향(세로 또는 가로)으로만 동작하게 제한해서는 안 된다"는 것이다. 특정 서비스가 "세로 방향으로 사용하세요"라는 안내를 내보내고 가로로 기울이면 제대로 동작하지 않는다면, 이는 기준을 위반하는 것이다.

테스트 관점에서 보면, 태블릿의 768px 세로 방향과 1024px 가로 방향은 완전히 다른 레이아웃 경험을 줄 수 있다. 768px를 기준으로 적용된 CSS가 가로로 돌렸을 때의 1024px에서는 의도치 않게 데스크톱 레이아웃이 나올 수 있다. 또는 반대로, 1024px 뷰포트에서 두 열짜리 레이아웃이 뜨지 않고 단열 레이아웃이 그대로 유지되는 경우도 있다.

Rite (Technology.org, 2026)의 분석에 따르면 "사용자들은 눕거나 걸으면서 또는 멀티태스킹을 하며 기기를 가로와 세로 사이에서 자주 전환한다. 그 전환이 부드럽게 이루어지지 않으면 구조나 의미가 손상된다"(Technology.org, 'WCAG for Modern Web'). 이 관찰은 ViewCheck에서 방향 전환을 별도로 테스트하는 이유가 되고 있다.

---

NN/g의 모바일 사용성 연구가 주는 시사점

닐슨 노먼 그룹(Nielsen Norman Group)은 모바일 사용성 연구를 오랜 기간 축적해온 기관이다. Jakob Nielsen과 Raluca Budiu가 공저한 "Mobile Usability"는 터치스크린 기반 인터페이스의 사용성에 관한 주요 연구를 담고 있다(NN/g, 'Mobile Usability').

NN/g의 연구에서 반복적으로 나오는 발견 중 하나는 터치 타겟 크기와 직결된다. "작은 타겟이 진짜 문제"라는 것이다. 손가락이 크다는 게 문제가 아니라, 타겟이 너무 작아 어디를 눌러야 할지 모르게 만드는 설계가 문제라는 것. NN/g의 모바일/태블릿 연구 보고서는 터치스크린 스마트폰의 UI 개선을 위한 374가지 팁을 포함하고 있으며, 모바일 최적화 인트라넷과 모바일 웹 앱 설계의 사례 연구도 담고 있다(NN/g, 'Mobile & Tablet Usability Research Reports').

또한 NN/g는 반응형 설계의 사용성 관점에서 중요한 원칙을 제시한다. 작은 화면에서의 설계는 단순히 콘텐츠를 줄이는 것이 아니라, 우선순위를 재설계하는 것이라는 점이다. 어떤 정보가 먼저 보여야 하는지, 어떤 기능이 모바일에서 더 자주 쓰이는지를 다시 생각해야 한다. 이 사고방식은 "반응형 CSS를 입히면 끝"이라는 단순한 접근과는 다른 결을 요구한다.

---

GOV.UK Design System의 레이아웃 접근 — 비교 관점에서

KRDS와 자주 비교되는 GOV.UK Design System은 반응형 레이아웃을 어떻게 다루는가?

GOV.UK Design System의 레이아웃 문서에 따르면, 핵심 브레이크포인트는 **640px(태블릿 브레이크포인트)**이다. 640px를 경계로 "large screen" 스타일이 적용된다. 대부분의 GOV.UK 페이지는 "2/3과 1/3" 레이아웃 — 왼쪽 2/3에 본문, 오른쪽 1/3에 보조 콘텐츠 — 을 따르며, 이 그리드가 좁은 화면에서는 단열(single column)로 전환된다(GOV.UK Design System, design-system.service.gov.uk/styles/layout/).

GOV.UK의 특이점은 "단순하게, 글자 위주로"라는 철학이 반응형에도 그대로 적용된다는 점이다. 화려한 레이아웃 전환보다, 어떤 화면에서도 콘텐츠가 읽히고 기능이 작동하는 것을 우선시한다. 터치 타겟에 관해서도 GDS Blog의 초기 글 "Designing for different devices"(2012)에서 "큰 터치 타겟이 중요하다"는 원칙이 이미 언급되었다(GDS Blog, gds.blog.gov.uk).

KRDS와 비교했을 때 GOV.UK는 브레이크포인트 수가 더 적고 단순하다. KRDS가 4단계(xsmall, small, medium, large, xlarge)를 정의하는 것과 달리, GOV.UK는 mobile/tablet/desktop의 단순한 구분에 가깝다. 어느 쪽이 나은가라는 질문보다는, 다루는 콘텐츠 유형과 서비스 복잡도에 따라 적합한 접근이 다를 수 있다는 게 우리의 관찰이다.

---

자동 분석의 가능성과 한계 — ViewCheck가 할 수 있는 것과 없는 것

이 편에서 솔직하게 가장 많이 이야기하고 싶었던 부분이다. 반응형 품질 분석에서 자동화가 어디까지 갈 수 있는지, 그리고 어디서부터 반드시 사람의 손이 필요한지.

자동화가 잘 되는 영역

• 터치타겟 크기를 DOM 요소의 렌더링 크기로 측정하는 것
• 뷰포트를 초과하는 요소(가로 오버플로)를 탐지하는 것
• meta viewport 설정(user-scalable, maximum-scale)을 확인하는 것
• 세 뷰포트에서 각각 DOM을 수집해 구조 변화를 비교하는 것
• 특정 CSS 패턴(고정 너비 설정, overflow: hidden 남용 등)을 탐지하는 것

자동화가 어렵거나 불완전한 영역

• 실제 터치 인터랙션을 통한 오탭/미스탭 경험. 손가락 크기와 압력, 사용 자세에 따른 변수를 시뮬레이션하는 건 현실적으로 어렵다.
• 레이아웃의 시각적 어색함. "이 화면에서 이 배치가 이상하다"는 것은 사람의 눈으로 봐야 알 수 있는 경우가 많다.
• CSS pseudo-element나 JavaScript로 확장된 터치 영역. DOM 요소 자체의 크기 외에 실제 반응 영역을 완전히 포착하기 어렵다.
• 사용자 맥락에 따른 우선순위 평가. 모바일에서 가장 중요한 정보가 스크롤 없이 보이는지는 콘텐츠 의미를 이해해야 판단할 수 있다.

이 한계는 ViewCheck만의 한계가 아니라, DOM 기반 자동 분석 전반의 한계다. 우리는 이 한계를 숨기기보다 명시하는 쪽을 택한다. 왜냐하면 담당자가 "ViewCheck에서 통과했으니 반응형은 문제없겠다"는 식으로 결론 내리는 게 가장 위험한 상황이기 때문이다. 자동 분석은 문제 가능성을 빠르게 탐지해 주는 도구이지, 사람의 판단을 대체하는 도구가 아니다.

TestParty가 정리한 "WCAG 1.4.10 리플로우 2025 가이드"도 비슷한 결론에 도달한다. "자동화된 도구는 기본적인 리플로우 문제를 탐지하는 데 도움이 되지만, 완전한 준수 여부는 실제 테스팅이 필요하다"(TestParty.ai, 'The 2025 TestParty Guide to WCAG 1.4.10'). 이 솔직함이 반응형 분석 도구를 바라보는 적절한 기준이라고 생각한다.

---

다중 페이지에서 반응형 품질이 더 중요한 이유

반응형 문제는 모든 페이지에서 동일하게 나타나지 않는다. 오히려 특정 페이지 유형에서 훨씬 심각하게 나타나는 경향이 있다.

공공 웹사이트에서 반응형 문제가 집중되는 페이지 유형은 대략 이렇다.

신청 · 접수 페이지 — 폼 요소가 많고, 항목마다 라벨·입력 필드·도움말이 붙어 있어 레이아웃이 복잡하다. 데스크톱 기준으로 가로 배치된 라벨-입력 구조가 모바일에서 세로로 스택되면서 페이지가 매우 길어지고, 터치 타겟이 촘촘해지는 경우가 많다.

데이터 테이블 · 통계 페이지 — 고정 너비 테이블이 모바일에서 가로 오버플로를 유발하는 것이 가장 전형적인 패턴이다. 통계청, 각 부처 통계 자료, 예산 현황 같은 표 형태의 데이터는 좁은 화면에서 다루기 까다롭다.

검색 결과 · 목록 페이지 — 페이지네이션 숫자 버튼이 작게 배치되어 터치가 어렵거나, 필터 UI가 모바일에서 접힌 상태로 진입 방법이 불명확한 경우가 있다.

이미지 · 미디어 heavy 페이지 — 고해상도 이미지나 인포그래픽이 모바일에서 그대로 축소되어 가독성이 없는 상태가 되거나, 반대로 이미지가 뷰포트를 초과하는 경우가 있다.

ViewCheck가 다중 페이지 분석을 기본으로 설계한 이유 중 하나가 바로 여기에 있다. 메인 페이지의 반응형이 잘 되어 있더라도, 신청 페이지에서 터치 타겟 문제가 있다면 그게 시민들이 실제로 불편함을 겪는 지점이다. 메인만 보고 "반응형 이상 없음"이라고 보고하는 건 현실과 거리가 있다. 그래서 우리는 다양한 페이지 유형을 포함한 분석을 기본으로 한다.

---

실제 분석에서 발견한 것들 — 숫자로 말하기 어려운 부분

이 대목을 쓰면서 가장 조심스러웠다. 구체적인 수치를 제시하면 그것이 "ViewCheck가 분석한 공공웹의 NN%가 반응형 문제를 가지고 있다"는 식으로 읽힐 수 있는데, 우리는 그런 방식의 수치 제시를 매우 신중하게 생각하기 때문이다.

실측에서 확인한 것들 중 공개적으로 말할 수 있는 패턴을 몇 가지 적는다.

터치타겟 크기 미달은 생각보다 흔하다. 특히 상단 GNB 아이콘 버튼들(검색, 메뉴, SNS 공유 등)과 하단 페이지네이션 숫자 버튼에서 자주 발견된다. 이 요소들은 데스크톱에서는 마우스로 쉽게 클릭되기 때문에 크기 문제가 눈에 잘 안 띄지만, 모바일에서 손가락으로 누르면 바로 체감된다.

태블릿 구간에서 의도하지 않은 레이아웃 전환이 발생하는 경우도 많다. 769px 이상에서 데스크톱 스타일이 적용되도록 설정되어 있는데, 768px(가장 일반적인 태블릿 뷰포트)에서는 모바일 스타일이 적용되어 어색한 레이아웃이 나오는 케이스가 있다. 1px 차이지만 실제 경험에서는 큰 차이가 난다.

meta viewport의 user-scalable=no 설정은 생각보다 여전히 발견된다. 이 설정은 사용자가 화면을 핀치 줌으로 확대하지 못하게 막아, 저시력 사용자에게 심각한 접근성 장벽이 된다. WCAG 1.4.4 (Resize Text, AA)의 취지에도 반하는 설정이다.

이런 발견들을 "이 사이트가 나쁘다"는 식으로 해석하기보다, "반응형 구현 이후에도 점검이 필요한 항목들이 있다"는 신호로 읽기를 권한다. 많은 경우 이 문제들은 개발자가 모바일 뷰포트에서 실제로 테스트하지 않고 데스크톱 기준으로만 검수한 결과이거나, CSS를 오래전에 작성한 뒤 업데이트하지 않은 경우에서 비롯된다.

---

KRDS의 반응형 지침 — 8pt 그리드와 마진

KRDS 공식 레이아웃 스타일 가이드에서 반응형과 직접 관련된 지침을 살펴보면 몇 가지 중요한 원칙이 있다.

8-Point Grid 원칙

KRDS는 8px(8-Point Grid)의 배수를 기본 간격 단위로 사용한다. 상황에 따라 4px 배수도 허용한다. 이 그리드 원칙은 일관된 간격 체계를 만들어 반응형 전환 시에도 비례감을 유지하게 해준다. 뷰포트가 달라져도 요소 간 비례가 깨지지 않으려면, 처음부터 배수 관계를 가진 간격 체계를 써야 한다.

4단계 브레이크포인트

KRDS는 small(360px~), medium(768px~), large(1024px~), xlarge(1280px~) 4단계를 정의한다. 360px 미만의 xsmall 구간은 최적화 대상에서 제외한다. 이 구간 설정은 실제 국내 사용자들이 많이 쓰는 기기 화면 크기를 반영한 것으로, 360px 이상의 안드로이드 기기와 390px의 아이폰을 모두 커버한다.

마진 기준

화면 마진은 모바일 최소 16px, PC 최소 24px 이상이다. 좁은 화면에서 콘텐츠가 화면 끝에 너무 붙지 않게 하는 최소 여백이다. 이 마진이 지켜지지 않으면 터치가 어려운 영역이 생기거나, 텍스트가 화면 끝에 붙어 가독성이 떨어진다.

모바일 4 column 그리드

모바일에서는 4 column을 기본으로, 최대 6 column까지 사용할 수 있다. 이 column 체계는 좁은 화면에서 콘텐츠를 정렬하는 기준을 제공한다. column 수가 많을수록 세밀한 레이아웃 제어가 가능하지만, 좁은 화면에서 지나치게 많은 column을 쓰면 각 column이 너무 좁아진다.

이 가이드라인들이 실제 공공 웹사이트에 얼마나 반영되어 있는지는, 정직하게 말하면 "확인 중"이다. KRDS 가이드를 공표한 이후 이를 충실히 적용하는 사이트가 늘고 있지만, 오래된 사이트나 외주 개발 과정에서 이 가이드를 잘 모르고 작업한 경우도 있다. KRDS 준수율을 측정한다는 것의 의미는, 이 가이드라인이 실제로 지켜지고 있는지 숫자로 확인하는 작업이기도 하다.

---

반응형 점수를 어떻게 산출하는가

ViewCheck LLM 분석의 24개 기능 카드 중 하나인 '반응형 품질' 카드는 세 뷰포트의 측정 결과를 종합한 점수를 제시한다. 이 점수를 어떻게 산출하는지, 그 원리를 간략하게 설명한다.

기본 구조는 이렇다. 세 뷰포트(데스크톱·태블릿·모바일)에서 각각 복수의 항목을 측정하고, 항목별로 통과/미통과를 판정한다. 판정 결과를 뷰포트별로 집계한 뒤, 세 뷰포트의 점수를 합산해 전체 반응형 점수로 만든다.

항목별 가중치는 사용 빈도와 영향도를 고려해 설정한다. 예를 들어 터치타겟 미달은 모바일 사용성에 직접적인 영향을 미치므로 가중치가 높다. 반면 meta viewport 설정 같은 항목은 접근성에 중요하지만, 터치타겟만큼 많은 사용자가 직접 체감하는 항목은 아니다.

다만 이 점수도 맹신해서는 안 된다. 자동 분석이 놓치는 항목이 있고, 측정 방식의 한계로 실제보다 높게 또는 낮게 나올 수 있다. 이 점수는 "이 정도 수준"을 파악하는 시작점이지, "이 점수가 곧 품질"은 아니다. 점수보다 함께 제공되는 미통과 항목 목록과 근거가 더 실질적으로 유용한 경우가 많다.

---

접근성과 반응형의 교차점 — 뷰포트와 인지 부하

반응형과 접근성은 별개의 주제처럼 느껴질 수 있지만, 실제로는 많은 부분이 교차한다.

저시력 사용자는 화면을 확대해서 사용한다. 400%로 확대한다는 것은 실질적으로 1280px 화면이 320px 뷰포트처럼 동작하는 것과 같다. 이 상태에서 콘텐츠가 수평 스크롤 없이 읽힌다는 것은, 그 사이트가 아주 좁은 뷰포트에서도 올바른 리플로우를 한다는 의미다. 즉, 반응형이 잘 되어 있으면 저시력 접근성도 함께 확보된다.

청각 장애 사용자는 반응형과 직접 관련이 없다고 생각할 수 있다. 하지만 모바일에서 자동 재생되는 동영상이나 오디오가 있다면, 그 제어 버튼이 충분히 커야 한다는 점에서 터치타겟 기준과 연결된다.

운동 장애 사용자, 파킨슨이나 수전증이 있는 사용자에게는 터치 타겟 크기가 특히 중요하다. 이 그룹에게는 44px가 아니라 더 큰 타겟이 필요한 경우도 있다. WCAG 기준이 "최소"인 이유가 여기에 있다 — 기준을 충족한다고 해서 모든 사용자에게 충분하다는 보장은 없다.

인지 장애 사용자에게는 반응형 전환 시의 레이아웃 변화가 혼란을 줄 수 있다. 데스크톱에서는 메뉴가 상단에 가로로 있고, 모바일에서는 햄버거 안에 있다면, 일관된 정신 모델을 유지하기 어렵다. 이 관점에서 반응형 설계는 "다른 뷰포트에서도 사용자가 혼란 없이 원하는 것을 찾을 수 있는가"라는 더 넓은 질문과 연결된다.

이런 교차점들이, ViewCheck에서 반응형 품질을 단순한 레이아웃 점검이 아니라 접근성과 연계된 관점으로 바라보는 이유다.

---

W3C WCAG 2.2 모바일 가이드 — 새로운 흐름

W3C의 모바일 접근성 태스크포스(MATF)는 2024년 1월 재결성되어 WCAG 2.2의 모바일 애플리케이션 적용 지침을 작업 중이다. "Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile)"이라는 별도 문서가 작업 중이며, 이는 WCAG가 모바일 맥락에서 어떻게 해석되어야 하는지를 보다 명확히 정리하려는 시도다(W3C, 'Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile)', w3.org/TR/wcag2mobile-22/).

이 문서가 완성되면, 모바일 앱과 모바일 웹에 대한 WCAG 적용이 더 구체화될 것이다. 현재로서는 모바일 맥락에 대한 WCAG 해석이 다소 불명확한 부분이 있는데, 이 지침이 그 공백을 채울 것으로 기대된다.

ViewCheck 입장에서 이 흐름은 중요하다. WCAG2Mobile이 완성되면 모바일/반응형 관련 점검 항목이 더 명확해지고, 자동화 가능한 항목과 사람이 직접 확인해야 할 항목의 구분도 더 명확해질 것이다. 이 변화에 맞춰 분석 로직을 업데이트하는 것은 우리가 지속적으로 해야 할 작업이다.

---

반응형 점검을 어떻게 활용할 것인가 — 담당자 관점

이 편을 읽는 독자 중 상당수는 실제 공공 웹사이트를 관리하거나 발주하는 담당자일 것이다. 반응형 분석 결과를 어떻게 활용할지에 대해 실용적인 관점을 몇 가지 정리한다.

먼저, 어떤 페이지 유형을 분석했는지 확인하라

반응형 분석은 메인 페이지보다 신청·접수·검색 결과·통계 페이지에서 문제가 더 많이 나온다. ViewCheck가 다중 페이지 분석을 기본으로 하는 이유가 여기에 있지만, 분석 결과를 볼 때 어떤 페이지가 포함됐는지를 함께 확인하는 것이 중요하다.

터치타겟 미달 목록을 외주 개발사에 전달하라

자동 분석에서 터치타겟 미달로 탐지된 요소 목록은 외주 개발사에 구체적인 수정 요청의 근거로 쓸 수 있다. "WCAG 2.5.5 Enhanced 기준(44×44px)에 미달하는 요소 N개"라는 수치와 함께 요소 목록을 전달하면, 모호한 "좀 더 크게 해주세요" 요청보다 훨씬 명확한 커뮤니케이션이 된다.

meta viewport 설정은 즉시 수정 가능하다

user-scalable=no나 maximum-scale=1.0 같은 설정은 코드 한 줄을 바꾸는 수준으로 수정 가능하다. 개선 난이도가 낮으면서 접근성 영향이 큰 항목이므로 우선순위를 높여서 처리하는 게 좋다.

모바일에서 직접 확인하는 과정을 건너뛰지 마라

자동 분석 이후, 실제 스마트폰으로 핵심 서비스 페이지(신청서 작성, 검색, 로그인)를 직접 사용해 보는 과정은 건너뛸 수 없다. 자동화가 찾아준 것들을 확인하고, 자동화가 놓친 것들을 발견하는 과정이다. 이 두 과정이 함께 갈 때, 반응형 품질 점검이 실질적인 의미를 갖는다.

---

아직 풀지 못한 것들 — 솔직하게

이 편에서 다룬 내용을 돌아보면, 우리가 "이렇게 하면 됩니다"라고 말할 수 있는 것보다, "이건 아직 어렵습니다"라고 말해야 하는 것들이 더 많다는 걸 발견한다.

아직 풀지 못한 것들을 솔직하게 나열한다.

실제 터치 인터랙션 시뮬레이션 — DOM 기반으로는 터치 반응 영역을 완전히 포착하지 못한다. 실제 사용자가 손가락으로 누르는 경험을 완전히 시뮬레이션하는 것은 여전히 어렵다. Playwright에서 pointer event를 시뮬레이션할 수 있지만, 실제 물리적 손가락과 화면 간의 상호작용 전체를 재현하지는 못한다.

레이아웃의 시각적 어색함 판정 — "이 화면에서 이 배치가 어색하다"는 판단은 사람의 시각적 평가가 필요하다. CSS Pixel Inspector나 screenshot 비교로 일부 탐지할 수 있지만, "어색하다"의 기준을 자동화하기는 어렵다.

모든 기기 뷰포트 커버리지 — 1920, 768, 390이라는 세 가지 뷰포트는 대표적이지만 전체가 아니다. 240px대의 작은 기기, 다양한 노트북 해상도, 4K 디스플레이 등 실제 사용 환경은 훨씬 다양하다. 세 개의 대표 구간이 주는 인사이트는 충분히 가치 있지만, "세 개를 봤으니 다 됐다"는 결론으로 가면 안 된다.

콘텐츠 우선순위의 모바일 최적화 — 어떤 정보가 작은 화면에서 먼저 보여야 하는지는 콘텐츠의 맥락과 사용자 의도를 이해해야 판단된다. 이건 기술적 자동화보다 서비스 기획의 영역에 더 가깝다.

이 한계들이 우리가 반응형 분석을 "완성된 기능"이 아니라 "진행 중인 연구"로 부르는 이유다. 24편의 분석 기능 중 반응형 품질은 비교적 탐지 정확도가 높은 편이지만, 그래도 여전히 발전의 여지가 크다.

---

마무리 — 세 화면을 보는 것의 의미

긴 이야기를 마무리하면서, 처음으로 돌아간다.

"PC에서는 잘 되는데 폰으로 들어오면 이상해요."

이 민원이 왜 계속 들어오는가. 개발자나 담당자가 게으른 게 아니다. 사이트를 만들고 검수하는 대부분의 과정이 데스크톱 화면 앞에서 이루어지기 때문이다. 모바일에서 어떻게 보이는지, 태블릿에서 어떻게 동작하는지를 매번 꼼꼼히 확인하는 것은 — 특히 수십 개의 페이지를 가진 사이트에서는 — 현실적으로 매우 어렵다.

자동화 분석이 그 간극을 채울 수 있다. 세 뷰포트를 동시에 측정하고, 터치타겟 미달을 자동으로 탐지하고, 뷰포트 오버플로를 찾아내는 것. 이 작업을 100개 페이지에 대해 자동으로 돌리는 것이 ViewCheck의 역할이다. 빠르게, 반복적으로, 근거와 함께.

다만 이것이 "이제 사람이 확인 안 해도 된다"는 의미는 아니다. 자동화가 탐지한 문제를 사람이 보고 "이게 실제로 문제인가, 어떻게 고쳐야 하는가"를 판단하는 과정은 여전히 필요하다. 그리고 자동화가 아직 탐지하지 못하는 영역 — 시각적 어색함, 실제 터치 인터랙션, 콘텐츠 우선순위 — 에 대한 사람의 검토도 빠질 수 없다.

WCAG 2.5.8이 말하는 24px, 2.5.5가 말하는 44px, Apple HIG가 말하는 44pt, Material Design이 말하는 48dp — 이 숫자들은 수십 년의 인간공학 연구와 실제 사용자 관찰에서 나온 것들이다. 그 숫자 하나가 어떤 의미인지를 이해하고, 실제 사이트에서 지켜지고 있는지를 확인하는 것. 그것이 반응형 품질 연구의 첫 걸음이다.

우리는 그 걸음을 매일 조금씩 내딛고 있다. 다음 편에서 또 다른 측면을 이어가겠다.

---

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 검증했다. 국내 공식 기준 및 정책 자료와 국제 표준·연구를 함께 실었다.

국내 — 공식 기준 / 정책 자료

1. 행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정). 행정안전부. https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
2. 행정안전부, 「전자정부 웹사이트 품질관리 지침」. 국가법령정보센터. https://www.law.go.kr/admRulLsInfoP.do?admRulId=37565
3. KRDS(범정부 UI/UX 디자인시스템) 공식 사이트 — 레이아웃 스타일 가이드. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/html/site/style/style_05.html
4. KRDS 공식. https://www.krds.go.kr/
5. UXKM, '한국형 웹 콘텐츠 접근성 가이드라인(KWCAG) 2.2 해설'. https://uxkm.io/accessibility/a11y/04-a11yCag/02-kwcag
6. 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2. https://a11ykr.github.io/kwcag22/

해외 — 국제 표준 / 플랫폼 가이드라인 / UX 연구

7. W3C WAI, "Understanding Success Criterion 2.5.8: Target Size (Minimum)", WCAG 2.2. https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
8. W3C WAI, "Understanding Success Criterion 2.5.5: Target Size (Enhanced)", WCAG 2.2. https://www.w3.org/WAI/WCAG22/Understanding/target-size-enhanced.html
9. W3C WAI, "Understanding Success Criterion 1.4.10: Reflow", WCAG 2.1. https://www.w3.org/WAI/WCAG21/Understanding/reflow.html
10. W3C, "Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile)". https://www.w3.org/TR/wcag2mobile-22/
11. W3C, "Web Content Accessibility Guidelines (WCAG) 2.2". https://www.w3.org/TR/WCAG22/
12. Material Design 3, "Accessibility Designing — Touch Target". Google. https://m3.material.io/foundations/designing/structure
13. Material Design (M2), "Touch Target Support". Google. https://m2.material.io/develop/web/supporting/touch-target
14. GOV.UK Design System, "Layout". Government Digital Service. https://design-system.service.gov.uk/styles/layout/
15. GOV.UK Design System. https://design-system.service.gov.uk/
16. GDS Blog, "Designing for different devices", 2012. Government Digital Service. https://gds.blog.gov.uk/2012/11/02/designing-for-different-devices/
17. Nielsen Norman Group, "Mobile & Tablet Usability Research Reports". https://www.nngroup.com/reports/topic/mobile-and-tablet-design/
18. Nielsen Norman Group, "Mobile Usability 2nd Research Study". https://www.nngroup.com/articles/mobile-usability-2nd-study/
19. AAArdvark, "WCAG 2.5.5 Target Size (Enhanced) — Plain English". https://aaardvarkaccessibility.com/wcag-plain-english/2-5-5-target-size-enhanced/
20. AllAccessible, "WCAG 2.5.8 Target Size (Minimum): Complete Implementation Guide". https://www.allaccessible.org/blog/wcag-258-target-size-minimum-implementation-guide
21. Silktide, "WCAG 1.4.10: Reflow". https://silktide.com/accessibility-guide/the-wcag-standard/1-4/distinguishable/1-4-10-reflow/
22. TestParty.ai, "The 2025 TestParty Guide to WCAG 1.4.10 – Reflow (Level AA)". https://testparty.ai/blog/wcag-1-4-10-reflow-2025-guide
23. TestParty.ai, "Mobile Accessibility Testing: WCAG 2.2 Requirements for Responsive Design". https://testparty.ai/blog/mobile-accessibility-testing
24. Technology.org, "WCAG for Modern Web: Accessibility in Mobile-First, Touch Interfaces, and Responsive Design", 2026. https://www.technology.org/2026/01/29/wcag-for-modern-web-accessibility-in-mobile-first-touch-interfaces-and-responsive-design/
25. Zac Dickerson, "Size matters! Accessibility and Touch Targets", Medium, 2018. https://medium.com/@zacdicko/size-matters-accessibility-and-touch-targets-56e942adc0cc
26. MDN Web Docs, "Responsive Design". https://developer.mozilla.org/ko/docs/Learn_web_development/Core/CSS_layout/Responsive_Design
27. LogRocket Blog, "All accessible touch target sizes". https://blog.logrocket.com/ux-design/all-accessible-touch-target-sizes/

---