목록으로
디지털 접근성 연구

[접근성연구·고령] 글자 크기, 어디까지 키워야 할까

부모님이나 조부모님과 같이 스마트폰을 보다가, "글씨 좀 키워줘"라는 말을 들어본 적이 있을 겁니다. 우리는 보통 설정에 들어가 시스템 글꼴을 한두 단계 키워 드립니다. 그런데 그렇게 키운 폰으로 어떤 공공 사이트에 들어가면, 글자는 분명 커졌는데 버튼이 화면 밖으로 밀려나거나, 글자끼리 겹치거나, 메뉴가 사라지는 일이

VViewCheck Insight
·2026.07.19 5분 43
[접근성연구·고령] 글자 크기, 어디까지 키워야 할까

고령 사용자 가독성 기준에 대한 연구

〈디지털 접근성 연구 ①〉 — 이 글은 "이렇게 해야 한다"는 규정이 아니라, 공공 웹을 들여다보며 정리한 하나의 연구 관점입니다. 인용한 수치와 기준은 공개된 표준·자료를 출처와 함께 적었고, 아직 합의되지 않은 부분은 그렇다고 분명히 밝혔습니다.


들어가며 — "글씨 좀 키워줘"라는 말 뒤에

부모님이나 조부모님과 같이 스마트폰을 보다가, "글씨 좀 키워줘"라는 말을 들어본 적이 있을 겁니다. 우리는 보통 설정에 들어가 시스템 글꼴을 한두 단계 키워 드립니다. 그런데 그렇게 키운 폰으로 어떤 공공 사이트에 들어가면, 글자는 분명 커졌는데 버튼이 화면 밖으로 밀려나거나, 글자끼리 겹치거나, 메뉴가 사라지는 일이 생깁니다. 글씨를 키운 대가로 화면이 망가지는 셈입니다.

공공 웹 화면을 오래 들여다보면 이 장면이 거듭 반복됩니다. "글자 크기"는 접근성에서 가장 사소해 보이는 항목입니다. 색 대비나 스크린리더 호환성처럼 전문적으로 들리지도 않고, "글씨 크게 하면 되는 거 아니냐"는 말로 쉽게 정리되곤 합니다. 그러나 실제 사용 현장에서 글자 크기는 고령 사용자가 공공 서비스에 들어와 가장 먼저 부딪히는 벽입니다. 그것도 가장 조용히, 아무 오류 메시지 없이 사람을 돌려보내는 벽입니다. 화면은 멀쩡히 떠 있고, 시스템은 정상 작동하지만, 정작 그 앞의 사람은 무엇이 적혀 있는지 읽지 못해 그냥 창을 닫습니다.

이 조용한 실패는 통계에 잘 잡히지 않습니다. 에러 로그도 남지 않고, "글자가 안 보여서 못 했다"고 민원을 넣는 사람도 드뭅니다. 대부분은 그냥 포기하거나, 자녀에게 부탁하거나, 직접 기관을 찾아갑니다. 그래서 우리는 이 문제를 더 진지하게 봐야 한다고 생각합니다. 드러나지 않는 실패일수록 방치되기 쉽기 때문입니다.

이 글에서 우리가 답하려는 질문은 단순합니다. "공공 웹의 글자는 어디까지, 어떻게 키울 수 있어야 하는가?" 그리고 그 답을 우리는 단정이 아니라, 공개된 표준과 관찰한 데이터를 종합한 관점으로 제시하려 합니다. 정확한 숫자 하나로 못 박는 대신, "어떤 조건을 만족하는 화면이 고령 사용자에게 열려 있는가"를 함께 따져보려 합니다.

1. 왜 지금 '글자 크기'인가 — 사용자 구성이 바뀌고 있다

1-1. 고령 인구라는 거대한 흐름

먼저 사실관계부터 짚겠습니다. 한국은 이미 고령 인구 비중이 매우 높은 사회로 진입했습니다. 공개된 통계 기준으로 65세 이상 인구가 전체의 약 20%대에 이른 것으로 보고되고 있으며(이는 이른바 '초고령사회'의 기준선으로 통용되는 수치입니다), 이 비중은 앞으로 더 커질 것으로 전망됩니다. (출처: 서울시 스마트도시 자료 등에서 인용된 고령 인구 통계)

이 숫자가 공공 웹에 주는 의미는 분명합니다. 공공 서비스는 민간 앱과 달리 사용자를 고를 수 없습니다. 주민등록, 건강보험, 복지, 세금, 민원, 재난 안내 — 이 서비스들은 20대도, 80대도 똑같이 써야 합니다. 민간 서비스라면 "주 사용자층이 2030이니 그들에게 맞춘다"는 전략이 가능하지만, 공공은 그럴 수 없습니다. 오히려 디지털에 덜 익숙한 사람일수록 공공 서비스에 더 의존하는 경향이 있습니다. 은행 앱은 안 써도 건강보험 자격 확인은 해야 하는 분들이 많기 때문입니다.

그리고 80대 사용자에게 글자 크기는 "있으면 좋은 편의 기능"이 아니라, 서비스에 들어올 수 있느냐 없느냐를 가르는 입구입니다. 입구가 좁으면, 그 안에 아무리 잘 만든 기능이 있어도 닿지 못합니다. 우리는 이 지점을 이렇게 봅니다. 고령 사용자가 늘어난다는 것은 "큰 글씨 옵션을 하나 추가하자"가 아니라, "기본 설계 자체가 확대에 견뎌야 한다"는 뜻이다. 별도의 '어르신 모드'를 만드는 접근으로는 한계가 분명합니다. 그 모드를 켜는 것조차 어려운 분들이 많고, 별도 모드는 본 모드보다 늘 관리가 소홀해져 시간이 지나면 기능이 뒤처지기 때문입니다.

1-2. 노안은 특별한 상태가 아니다

또 하나 분명히 해둘 사실이 있습니다. 노안(노화에 따른 눈의 조절력 저하)은 질병이나 장애가 아니라, 거의 모든 사람이 나이가 들면 겪는 자연스러운 변화라는 점입니다. 눈은 가까운 것을 볼 때 수정체의 두께를 조절해 초점을 맞추는데, 나이가 들면 이 수정체의 유연성이 떨어집니다. 그래서 보통 40대 중반부터 가까운 거리의 작은 글씨에 초점을 맞추기가 점점 어려워지기 시작합니다. 팔을 뻗어 휴대폰을 멀리 두고 보는 행동이 그 신호입니다.

이 사실이 중요한 이유는, "큰 글씨 = 일부 노인을 위한 특별 배려"라는 통념을 흔들기 때문입니다. 글자를 키울 수 있는 화면은 70대만을 위한 것이 아닙니다. 노안이 시작된 40~50대 공무원, 햇빛 아래에서 화면을 보는 청년, 피곤한 눈으로 야근하는 직장인, 작은 화면을 멀찍이 두고 보는 거의 모든 사람이 같이 덕을 봅니다. 우리는 이것을 "접근성의 보편성" 이라고 정리합니다. 가장 취약한 사용자를 기준으로 설계하면, 그 혜택은 결국 모두에게 돌아갑니다. 경사로를 깔면 휠체어뿐 아니라 유아차·캐리어·자전거가 모두 편해지는 것과 같은 원리입니다.

1-3. 누구나 가끔은 '고령 사용자'가 된다 — 상황적 저시력

접근성 논의에서 자주 놓치는 관점이 하나 있습니다. 시각적 어려움은 '영구적'인 것만 있는 게 아니라, '상황적'으로도 발생한다는 점입니다. 평소 시력이 좋은 사람도 특정 상황에서는 사실상 저시력 사용자가 됩니다. 한낮 야외에서 화면 반사가 심할 때, 흔들리는 버스 안에서 글자가 떨려 보일 때, 액정에 금이 갔을 때, 한 손에 짐을 들고 화면을 멀리 둘 때. 이 모든 순간에 사람들은 "글씨 좀 더 컸으면" 하고 바랍니다.

우리가 이 관점을 강조하는 이유는, 글자 크기 대응이 소수를 위한 비용이 아니라 다수를 위한 품질임을 보여주기 때문입니다. 영구적으로 노안이 있는 분들, 일시적으로 눈이 불편한 분들, 그리고 그저 작은 화면을 쓰는 모든 사람 — 이들을 한 줄로 세우면, 사실상 거의 전체 사용자입니다. 글자 크기는 그래서 "예외적 사용자"가 아니라 "기본 사용자"를 위한 항목입니다.

2. 표준은 무엇을 말하는가 — 인용과 해석

여기서부터는 공개된 표준이 글자 크기에 대해 실제로 무엇을 권고하는지 정확히 인용하고, 그 위에 우리의 해석을 얹겠습니다. 표준의 문장과 우리의 관점을 섞지 않기 위해 인용은 인용으로, 해석은 해석으로 구분해 적겠습니다.

2-1. WCAG — "200%까지 확대해도 잃는 것이 없어야 한다"

웹 접근성의 국제 기준인 WCAG(Web Content Accessibility Guidelines)에는 글자 크기와 직접 관련된 성공 기준이 있습니다.

인용 (WCAG 2.1, 성공 기준 1.4.4 Resize Text, AA): 텍스트는 보조 기술 없이도 200%까지 확대할 수 있어야 하며, 그때 콘텐츠나 기능의 손실이 없어야 한다.

이 문장의 핵심은 "200%"라는 숫자가 아니라 "손실이 없어야 한다(without loss of content or functionality)" 라는 조건이라고 우리는 봅니다. 즉 글자를 두 배로 키웠을 때도 버튼이 사라지거나, 텍스트가 잘리거나, 가로 스크롤이 생기지 않아야 한다는 것입니다. 단순히 "확대 기능을 제공하라"가 아니라, 확대된 상태에서도 화면이 제 기능을 해야 한다는 요구입니다. 글자만 커지고 그 글자가 담긴 버튼은 그대로라면, 그건 손실이 발생한 것입니다.

한 가지 덧붙이면, WCAG는 '큰 텍스트'를 별도로 정의합니다. 대략 18pt(약 24px) 이상, 또는 14pt(약 18.66px) 이상의 굵은 글씨를 큰 텍스트로 보고, 이 경우 명도 대비 기준을 조금 완화합니다(뒤의 2-2, 5장에서 다룹니다). 이는 글자 크기가 단지 가독성만이 아니라 대비 요건과도 맞물려 있음을 보여줍니다. 큰 글씨는 그 자체로 읽기를 돕고, 동시에 색이 옅어도 견디게 해 줍니다.

또 하나 구분해 둘 것은 '브라우저 확대(zoom)'와 '텍스트만 확대'는 다르다는 점입니다. 브라우저 전체 확대는 글자와 레이아웃을 함께 키우고, 텍스트만 확대는 글자만 키웁니다. 둘 다에서 화면이 견뎌야 진짜로 견고한 설계입니다. 텍스트만 키웠을 때 깨지는 화면이 의외로 많은데, 이는 글자 단위를 고정값으로 두었기 때문입니다(3장에서 자세히).

2-2. WCAG — 재배치(Reflow)와 텍스트 간격

WCAG에는 시각적 표현의 적응과 관련된 더 진전된 기준들도 있습니다. 글자 크기 하나만 다루지 않고, "키운 뒤에도 화면이 어떻게 흘러야 하는가"까지 규정합니다.

인용 (WCAG 2.1, 성공 기준 1.4.10 Reflow, AA): 콘텐츠는 가로 스크롤 없이 너비 320px 상당(약 400% 확대) 까지 재배치(reflow)될 수 있어야 한다.

인용 (WCAG 2.1, 성공 기준 1.4.12 Text Spacing, AA): 사용자가 줄 간격·문단 간격·글자 간격·단어 간격을 일정 수준으로 조정해도 콘텐츠·기능 손실이 없어야 한다.

우리의 해석은 이렇습니다. 현대의 접근성 표준은 "글자를 키울 수 있는가"를 넘어, "글자를 키우고, 간격을 벌리고, 화면을 좁혀도 무너지지 않는가"로 질문을 넓혀 왔다. 다시 말해 글자 크기 대응은 점점 레이아웃의 유연성 문제로 옮겨가고 있다는 것이 우리의 관점입니다. 1.4.10이 말하는 "320px 너비에서 가로 스크롤 없이"는, 사실상 "작은 모바일 화면에서 콘텐츠가 한 줄로 잘 흘러야 한다"는 요구와 같습니다. 그래서 글자 크기·반응형·모바일은 서로 다른 항목이 아니라, 한 사용자의 한 경험에서 동시에 작동하는 한 묶음입니다.

2-3. 한국의 기준 — KWCAG와의 관계

한국에는 WCAG를 바탕으로 만들어진 한국형 웹 콘텐츠 접근성 지침(KWCAG) 이 있습니다. 공개된 자료에 따르면 현재 통용되는 버전은 KWCAG 2.2이며, 이는 W3C의 WCAG를 기초로 작성된 국가 표준 성격의 지침입니다. (출처: KWCAG 2.2 공개 문서)

여기서 우리는 조심스럽게 말하려 합니다. 한국의 법·지침 체계가 글자 크기에 대해 어떤 강제력을 갖는지는, 적용 대상과 시점에 따라 달라지는 영역입니다. 「장애인차별금지법」이 웹 접근성을 폭넓게 요구한다는 점, 전자정부 관련 지침들이 품질 기준을 제시한다는 점은 공개된 사실이지만, "글자를 정확히 몇 px 이상으로 해야 위반이 아니다"라는 식의 단정적 기준이 일률적으로 확정되어 있다고 보기는 어렵습니다. 접근성 점검에서도 글자 크기는 '고정 수치 합격선'보다는 '확대 가능성과 손실 여부'로 평가되는 경향이 있습니다.

그래서 이 시리즈는 법적 의무 여부를 단정하지 않습니다. 대신 이렇게 봅니다. 법이 요구하든 아니든, 사용자 구성과 노안이라는 사실을 고려하면 "확대에 견디는 화면"은 공공 서비스가 마땅히 지향할 방향이다. 이것이 규정의 언어가 아니라 하나의 관점인 이유입니다. 우리는 "법이라서 해야 한다"보다 "사용자가 거기 있어서 해야 한다"는 쪽이 더 단단한 이유라고 생각합니다.

2-4. KRDS — 공공의 타이포 기준이 등장했다

비교적 최근의 변화로, 정부는 디지털 정부서비스 UI/UX 가이드라인(KRDS) 을 범정부 디자인 시스템으로 정비해 공개했습니다. 공개된 정보에 따르면 KRDS는 2025년에 정식 공개·수정본 배포 과정을 거쳤고, 각 컴포넌트·패턴 페이지에 WCAG 적합성을 함께 명시하는 방식으로 접근성을 전면에 내세웠습니다. (출처: KRDS 소개 페이지 및 관련 보도)

타이포그래피 측면에서 KRDS는 공공 서비스용 본문 서체로 Pretendard GOV 계열을 제시하고, 본문·제목의 크기와 간격에 대한 기준(디자인 토큰)을 제공합니다. 우리가 KRDS의 의미를 높게 보는 이유는 단순히 "권장 서체를 정했다"가 아닙니다. 공공 웹이 제각각이던 글자 기준을 하나의 시스템으로 수렴시키려는 시도라는 점입니다. 기관마다 본문이 12px이기도 하고 16px이기도 하던 상황에서, 공통의 출발선이 생긴 것입니다.

다만 한 가지는 정확히 해두겠습니다. KRDS가 제시하는 토큰의 구체적 수치(색상·간격·크기 변수의 개수 등)를 인용할 때는 공개된 실측값을 확인하고 인용해야 합니다. 예컨대 디자인 토큰의 개수처럼 자료마다 달리 인용되는 수치는, 출처의 실제 값을 확인하지 않은 채 옮기면 안 됩니다. 이 시리즈는 그런 수치를 인용할 때 반드시 출처의 실값을 따릅니다. 표준을 인용하면서 표준을 부정확하게 옮기는 것만큼 신뢰를 해치는 일은 없기 때문입니다.

3. 'px의 함정' — 글자가 안 커지는 진짜 이유

표준이 "200% 확대"를 말해도, 실제 화면에서 글자가 안 커지는 경우가 있습니다. 공공 웹을 살피며 자주 마주친 기술적 원인을 정리하면 이렇습니다. 여기는 사실에 기반한 기술 설명이므로 단정적으로 적습니다.

3-1. 고정 단위(px)와 상대 단위(rem/em)

웹에서 글자 크기를 지정하는 단위는 크게 두 갈래입니다.

  • 고정 단위(px): 화면에 박힌 절대 크기. 16px로 지정하면, 사용자가 브라우저나 시스템에서 기본 글꼴을 키워도 그 값이 잘 반영되지 않는 경우가 있습니다.
  • 상대 단위(rem/em): 기준 글꼴 크기에 대한 배수. 1rem은 "기준 글꼴의 1배"라는 뜻이라, 사용자가 기본 글꼴을 키우면 그에 비례해 같이 커집니다.

우리의 관찰로는, 글자 확대가 잘 안 되는 화면의 상당수가 본문·버튼 글자를 px로 단단히 고정해 둔 경우였습니다. 사용자가 "글씨 키워줘"를 실행해도, px로 못 박힌 글자는 꿈쩍하지 않습니다. 그래서 우리는 이렇게 봅니다. 글자 크기 대응의 출발점은 화려한 '큰 글씨 버튼'이 아니라, 단위를 상대 단위로 바꾸는 보이지 않는 결정이다. 사용자에게는 전혀 보이지 않는 이 한 줄의 선택이, 실제로는 "이 화면이 확대에 견디는가"를 가장 크게 좌우합니다.

요즘은 clamp() 같은 기법으로 "최소 크기는 보장하되 화면에 따라 유연하게 커지는" 글자도 만들 수 있습니다. 다만 유연함을 과하게 주면 작은 화면에서 글자가 너무 작아질 수 있어, 최소 크기를 충분히 잡아두는 것이 고령 사용자에게는 더 중요하다고 우리는 봅니다. '유연하게'보다 '작아지지 않게'가 먼저입니다.

3-2. 확대하면 깨지는 레이아웃

두 번째 함정은 글자는 커지는데 그릇이 그만큼 늘어나지 않는 경우입니다. 버튼·카드·입력칸의 높이나 너비를 고정값으로 박아두면, 안의 글자가 커질 때 글자가 잘리거나, 줄바꿈이 어색해지거나, 요소끼리 겹칩니다. WCAG 1.4.4가 "확대 시 손실이 없어야 한다"고 말하는 바로 그 손실이 여기서 발생합니다.

우리의 관점에서 이 문제의 본질은 글자가 아니라 레이아웃의 경직성입니다. 글자가 커질 여지를 미리 비워두지 않은 설계, 즉 "딱 맞게" 그린 화면일수록 확대에 약합니다. 디자인 시안에서 글자 한 줄이 버튼에 꽉 차게 들어맞으면 보기에는 깔끔하지만, 그 버튼은 글자가 조금만 커져도 깨집니다. 그래서 우리는 고령 친화 설계를 "큰 글씨를 넣는 일"이 아니라 "커질 자리를 남겨두는 일" 로 다시 정의합니다. 여백은 낭비가 아니라 확대를 위한 예비 공간입니다.

3-3. 확대를 막아버린 화면

세 번째는 다소 의외의 함정입니다. 일부 화면은 모바일 메타 태그에서 사용자 확대(pinch-to-zoom)를 아예 막아두기도 합니다(user-scalable=no 같은 설정). 화면을 '앱처럼' 보이게 하려는 의도였겠지만, 결과적으로 저시력·고령 사용자가 손가락으로 화면을 키울 권리를 빼앗는 셈이 됩니다. 접근성 관점에서 사용자 확대를 차단하는 설정은 바람직하지 않다는 것이 표준과 업계의 일반적 견해이며, 우리도 같은 관점입니다. 확대를 막는 것은 거의 언제나 디자인 편의를 위한 것이고, 그 편의의 대가를 가장 약한 사용자가 치릅니다.

3-4. '반응형'과 '글자 확대'는 다른 문제다

마지막으로 자주 혼동되는 지점을 짚겠습니다. "우리 사이트는 반응형이라 괜찮다"는 말을 종종 듣습니다. 그러나 반응형(화면 너비에 따라 레이아웃이 바뀌는 것)과 글자 확대(사용자가 글자를 키우는 것)는 서로 다른 문제입니다. 반응형이 잘 되어 있어도 글자 단위가 px로 고정돼 있으면, 사용자가 글자를 키워도 안 커집니다. 반대로 글자는 잘 커지는데 그릇이 안 늘어나 깨질 수도 있습니다. 둘은 함께 가야 하지만, 하나가 다른 하나를 보장하지는 않습니다. 우리는 이 둘을 항상 따로 확인합니다.

4. 그래서 '어디까지' 키워야 하나 — 우리의 관점

이제 처음의 질문으로 돌아갑니다. "어디까지 키워야 하는가?" 우리는 단일한 숫자로 답하지 않습니다. 대신 세 겹의 기준으로 정리합니다. 앞의 둘은 표준 인용에 근거하고, 셋째는 우리의 해석입니다.

첫째, '확대 가능성' — 사용자가 키울 수 있어야 한다. WCAG 1.4.4를 근거로, 본문 텍스트는 최소 200%까지 확대 가능해야 하며 그때 손실이 없어야 합니다. 이를 위한 실무적 출발점은 글자 단위를 상대 단위로 두고, 사용자 확대를 막지 않는 것입니다. 이 둘만 지켜도 "글자가 아예 안 커지는" 가장 흔한 실패는 사라집니다.

둘째, '재배치 가능성' — 키워도 한 화면에 흘러야 한다. WCAG 1.4.10(Reflow)을 근거로, 글자를 키우거나 화면을 좁혀도 가로 스크롤 없이 콘텐츠가 세로로 재배치되어야 합니다. 글자가 커질 때 화면이 옆으로 넘치면, 고령 사용자는 좌우로 밀어가며 읽어야 하고 이는 사실상 읽기를 포기하게 만듭니다. 사람은 위아래 스크롤에는 익숙하지만, 한 문장을 읽기 위해 좌우로 미는 동작에는 금세 지칩니다.

셋째, '기본값의 너그러움' — 키우기 전에도 충분히 읽혀야 한다. (이 항목은 우리의 관점입니다.) 우리는 "확대할 수 있으니 기본은 작아도 된다"는 생각에 반대합니다. 확대 기능을 찾아 설정에 들어가는 것 자체가 어려운 분들이 많기 때문입니다. 실제로 많은 고령 사용자는 자신의 폰에 글자 크기 설정이 있다는 사실조차 모르거나, 알아도 "괜히 건드렸다가 잘못될까 봐" 손대지 않습니다. 따라서 확대하지 않은 기본 상태에서도 본문이 편하게 읽히는 크기로 출발하는 것이 바람직하다고 봅니다. 정확한 px 값을 못 박기보다는, "공공 서비스의 본문은 넉넉한 편이 낫다"는 방향을 우리는 권합니다. KRDS가 본문 크기 기준을 제시한 것도 같은 맥락으로 이해합니다.

이 셋을 한 문장으로 줄이면 이렇습니다. "키울 수 있고(①), 키워도 흐트러지지 않으며(②), 키우기 전에도 충분히 읽히는(③) 화면." 이것이 "어디까지 키워야 하는가"에 대한 우리의 답입니다. 숫자 하나가 아니라 세 개의 조건이라는 점이 중요합니다. 어느 하나만 충족해서는 고령 사용자에게 화면이 열리지 않습니다.

5. 글자 크기를 넘어서는 것들 — 가독성의 동반 요소

글자 크기만 키운다고 가독성이 완성되지는 않습니다. 고령 사용자의 읽기 경험은 크기 외에도 여러 요소가 함께 작동합니다. 우리가 글자 크기와 한 묶음으로 보는 동반 요소를 정리합니다.

  • 명도 대비: 아무리 글자가 커도, 옅은 회색 글씨를 흰 바탕에 깔면 읽히지 않습니다. WCAG 1.4.3은 일반 텍스트의 명도 대비를 4.5:1 이상으로 권고합니다(큰 텍스트는 3:1). 크기와 대비는 가독성의 양 날개입니다. 흥미롭게도 글자를 키우면 대비 요건이 완화되므로, 큰 글씨는 대비 문제까지 일부 덜어줍니다. (이 주제는 저시력 편 029~031에서 더 깊이 다룹니다.)
  • 줄 간격과 줄 길이: 줄 간격이 너무 좁거나 한 줄이 너무 길면, 다음 줄을 찾는 눈의 이동이 어려워집니다. 한 줄이 화면을 가득 채워 너무 길면, 줄 끝에서 다음 줄 머리로 시선을 옮길 때 엉뚱한 줄로 가기 쉽습니다. 고령 사용자일수록 이 부담이 큽니다. 적절한 줄 간격과 적당한 줄 길이는 큰 글씨만큼이나 읽기를 돕습니다.
  • 글꼴의 선택: 획이 지나치게 가는 서체, 장식적인 서체는 작은 크기에서 더 읽기 어렵습니다. 비슷하게 생긴 글자(예: 숫자 1과 알파벳 l, 0과 O)가 잘 구분되는 서체가 가독성에 유리합니다. KRDS가 공공용 본문 서체를 제시한 배경에는 이런 가독성 고려가 있다고 우리는 봅니다.
  • 충분한 여백: 글자와 글자, 요소와 요소 사이의 여백은 '비어 있는 공간'이 아니라 '읽기를 돕는 공간'입니다. 빽빽한 화면은 큰 글씨로도 구제되지 않습니다. 정보를 욱여넣은 화면일수록, 글자를 키우면 더 빨리 깨집니다.
  • 정보의 우선순위: 역설적으로, 한 화면에 담는 정보를 줄이는 것이 가독성을 높입니다. 모든 것을 보여주려 하면 글자를 작게 할 수밖에 없습니다. "이 화면에서 사용자가 해야 할 한 가지"를 분명히 하면, 그만큼 핵심 글자를 키울 여유가 생깁니다.

우리가 강조하고 싶은 것은, 이 요소들이 따로 노는 항목이 아니라 한 사람의 읽기 경험 안에서 동시에 작동한다는 점입니다. 그래서 가독성을 점검할 때 크기 하나만 보지 않고, 크기·대비·간격·서체·정보량을 함께 봐야 한다고 봅니다.

6. 자주 만나는 반론과 우리의 답

글자를 키우자는 이야기를 하면 현장에서 비슷한 반론을 만납니다. 우리는 이 반론들이 부당하다고 생각하지 않습니다. 다 나름의 이유가 있습니다. 다만 우리의 관점에서 어떻게 답할 수 있는지 정리합니다.

"글자를 키우면 디자인이 단조롭고 촌스러워진다." — 충분히 이해되는 우려입니다. 작고 가는 글씨는 세련돼 보입니다. 그러나 우리는 공공 서비스의 미감 기준이 민간 브랜드와 달라야 한다고 봅니다. 공공의 '좋은 디자인'은 "멋져 보이는 것"보다 "모두가 읽을 수 있는 것"에 가깝습니다. 그리고 큰 글씨도 여백·정렬·위계를 잘 다루면 충분히 단정하고 품격 있게 보일 수 있습니다. 단조로움의 원인은 글자 크기가 아니라 위계의 부재인 경우가 많습니다.

"화면이 좁아서 글자를 키울 공간이 없다." — 이때 우리가 먼저 묻는 것은 "정말 이 화면에 이 정보가 다 필요한가"입니다. 공간이 부족한 진짜 이유는 글자가 아니라 정보 과잉인 경우가 많습니다. 한 화면에 한 과업만 두면 공간이 생깁니다. 모든 것을 한 화면에 욱여넣으려 하니 글자를 줄일 수밖에 없는 것입니다.

"확대 기능이 있으니 사용자가 알아서 키우면 된다." — 4장에서 말했듯, 그 기능에 닿지 못하는 분들이 적지 않습니다. 그리고 매번 확대해야 한다는 것은 매번 불편을 감수하라는 뜻입니다. 기본이 너그러우면 확대는 보조가 되고, 기본이 인색하면 확대는 필수가 됩니다. 우리는 전자가 낫다고 봅니다.

"우리 서비스 사용자는 대부분 젊다." — 민간이라면 타당할 수 있습니다. 그러나 공공은 앞서 말했듯 사용자를 고를 수 없고, 오히려 디지털에 덜 익숙한 사람이 더 의존합니다. 더구나 '젊은' 사용자도 노안이 오고, 상황적으로 저시력이 됩니다. 오늘의 다수가 내일의 소수가 아니라, 시간이 지나면 모두가 그 입장에 섭니다.

7. 우리가 공공 웹에서 관찰한 것 — 익명의 장면들

공공 웹 화면을 살피며 반복적으로 마주친 장면을 익명으로(○○시·△△청) 정리합니다. 특정 기관을 지목하려는 것이 아니라, 어디서나 비슷하게 반복되는 패턴을 보여드리기 위함입니다.

장면 하나. ○○ 지역의 한 민원 안내 페이지는 본문 글자를 px로 고정해 두어, 시스템 글꼴을 키운 폰에서도 글자가 거의 커지지 않았습니다. 사용자가 할 수 있는 일은 손가락으로 화면 전체를 확대하는 것뿐이었는데, 그러자 이번엔 가로 스크롤이 생겨 문장을 좌우로 밀어가며 읽어야 했습니다. 확대는 됐지만 읽기는 어려워진, WCAG가 말하는 "손실"의 전형이었습니다.

장면 둘. △△ 기관의 신청 폼은 글자를 키우자 입력칸 안의 안내 문구가 잘려 "주민등록번..."처럼 보였습니다. 입력칸의 높이가 고정돼 있어 커진 글자를 담지 못한 것입니다. 글자는 분명히 커졌지만, 정작 필요한 정보는 가려졌습니다. 사용자는 무엇을 입력해야 하는지 알 수 없었습니다.

장면 셋. 한 안내 페이지는 디자인을 산뜻하게 보이려고 본문을 옅은 회색으로 처리했습니다. 큰 화면·좋은 조명에서는 세련돼 보였지만, 야외에서 폰을 보는 고령 사용자에게는 글자 크기와 무관하게 글씨 자체가 흐릿하게 사라졌습니다. 크기 대응만으로는 메울 수 없는, 대비의 문제였습니다.

장면 넷. 어느 사이트는 본문은 적당히 컸지만, 가장 중요한 '신청하기' 버튼의 글자만 유독 작고 가늘었습니다. 디자인상 버튼을 작게 빼느라 그 안의 글자도 함께 줄어든 것입니다. 사용자가 가장 정확히 눌러야 할 지점이 가장 안 보였습니다. 우리는 이런 경우를 "정작 중요한 곳이 가장 약한" 패턴이라고 부릅니다.

장면 다섯. 한 페이지는 글자 크기 자체는 괜찮았지만 줄 간격이 지나치게 좁아, 글줄이 서로 들러붙어 보였습니다. 글자가 커도 줄이 엉기면 읽기 어렵다는 것을 보여주는 사례였습니다. 크기는 가독성의 필요조건이지 충분조건이 아닙니다.

이 장면들의 공통점을 우리는 이렇게 읽습니다. 대부분의 문제는 큰 리뉴얼이 아니라 작은 설계 결정에서 갈렸다. 단위를 px로 둘지 rem으로 둘지, 입력칸 높이를 고정할지 늘어나게 할지, 본문 색을 회색으로 할지 더 진하게 할지, 버튼 글자를 줄일지 말지 — 알았다면 다르게 선택했을 작은 갈림길들이었습니다. 그래서 우리는 이 연구가 비난이 아니라 공유된 학습이 되기를 바랍니다. 누구나 모르면 같은 자리에서 넘어집니다.

8. 점검의 관점 — '느낌'을 '데이터'로

"우리 사이트는 괜찮을까?"라는 의문이 든다면, 그것이 정확한 출발점입니다. 다만 글자 크기 대응을 사람 눈으로 일일이 확인하기는 어렵습니다. 페이지가 수십·수백 개이고, 단위(px/rem)는 코드를 봐야 알 수 있으며, "200% 확대 시 손실"은 화면마다 직접 키워봐야 드러나기 때문입니다. 한두 페이지를 눈으로 보고 "괜찮네"라고 판단하면, 정작 문제가 있는 페이지를 놓치기 쉽습니다.

그래서 점검은 가능한 한 '느낌'이 아니라 '데이터'로 이뤄지는 편이 낫다고 우리는 봅니다. "작아 보인다"가 아니라 "이 영역은 확대 시 잘림이 발생한다"처럼, 무엇이 어디서 어긋나는지를 구체적으로 짚는 것입니다. 글자 단위가 상대 단위인지, 200% 확대에서 가로 스크롤이 생기는지, 본문 대비가 기준에 닿는지, 버튼 글자가 본문보다 작지는 않은지 같은 항목은 비교적 기계적으로 확인할 수 있는 영역에 속합니다. 이런 항목은 사람의 인상에 맡기기보다 일관된 기준으로 점검하는 편이 정확합니다.

물론 자동화된 점검이 사람의 판단을 완전히 대신하지는 못합니다. "이 정도 크기가 이 서비스의 사용자에게 충분한가", "이 화면에서 가장 중요한 글자가 가장 잘 보이는가" 같은 질문은 결국 사람이, 그것도 실제 사용자를 떠올리며 답해야 합니다. 우리가 점검을 바라보는 관점은 "사람을 대체한다"가 아니라, 기계가 잡을 수 있는 부분을 먼저 걸러내어 사람이 더 중요한 판단에 집중하도록 돕는다는 것입니다. 점검의 목적은 합격 도장을 받는 것이 아니라, 화면 앞의 사람이 글을 읽을 수 있게 하는 것입니다.

9. 무엇부터 고칠까 — 우선순위에 대한 관점

현실적으로 한 사이트의 모든 화면을 한 번에 다 고칠 수는 없습니다. 페이지는 수백 개고, 예산과 일정은 한정돼 있습니다. 그래서 자주 받는 질문이 "그럼 어디부터 손대야 하나요?"입니다. 정답이 정해져 있다고 말하긴 어렵지만, 우리가 권하는 우선순위의 관점은 있습니다. 기준은 단순합니다 — 가장 많은 사람이, 가장 자주 지나는 길부터. 방문량과 사용자 취약도를 곱해 생각하는 것입니다.

1순위, 확대 자체가 막혀 있는 것. 사용자 확대를 차단해 둔 설정(user-scalable=no 등)이나, 본문 글자를 px로 못 박아 시스템 글꼴 확대가 안 먹는 경우가 여기 해당합니다. 이건 특정 페이지가 아니라 사이트 전반에 깔린 공통 토대인 경우가 많아, 한 번 바로잡으면 모든 페이지가 동시에 좋아집니다. 가장 적은 노력으로 가장 넓게 효과가 퍼지는 지점입니다.

2순위, 핵심 과업 경로의 글자와 버튼. 검색·로그인·신청·민원처럼 사용자가 반드시 거치는 경로의 라벨과 제출 버튼입니다. 안내 페이지의 글자가 좀 작은 것은 불편이지만, 신청 버튼의 글자가 안 보이는 것은 서비스 자체의 실패입니다. 가장 중요한 길목의 글자가 가장 또렷해야 한다는 것이 우리의 관점입니다.

3순위, 확대 시 깨지는 '그릇'. 고정 높이로 박힌 입력칸·버튼·카드처럼, 글자가 커지면 잘리거나 겹치는 요소들입니다. 1·2순위로 글자가 잘 커지게 되면, 이제 그 커진 글자를 담을 그릇을 손볼 차례입니다.

4순위, 기본 본문 크기와 대비의 전반적 상향. 확대에 견디는 구조가 갖춰진 뒤, 기본 상태의 본문을 조금 더 넉넉하게, 대비를 조금 더 또렷하게 올리는 작업입니다. 토대가 견고해진 다음에 해야 안전합니다.

한 가지 주의할 점이 있습니다. "전체 폰트를 일괄로 2px씩 키우자"는 식의 단순 조치는, 단위 전환 없이 적용하면 오히려 레이아웃 곳곳을 깨뜨릴 수 있습니다. 글자 키우기는 거의 항상 단위 전환·그릇 정비와 함께 가야 합니다. 그래서 우리는 "한 번에 완벽하게"보다 "가장 막힌 곳을 먼저 여는 여러 번" 을 권합니다. 완벽한 리뉴얼을 기다리는 동안에도, 확대 차단 한 줄을 푸는 작은 수정이 누군가에게는 오늘 당장 서비스의 문을 열어줍니다.

맺으며 — 큰 글씨는 친절이 아니라 입구다

우리는 글자 크기를 '친절한 옵션'으로 다루는 시선에 동의하지 않습니다. 고령 인구가 늘고 노안이 보편적인 현실에서, 글자 크기는 사용자가 공공 서비스에 들어올 수 있느냐를 결정하는 입구에 가깝습니다. 입구가 좁으면, 그 안에 아무리 좋은 서비스가 있어도 닿지 못합니다. 그리고 그 입구는 거창한 기술이 아니라, 단위 선택·여백·기본 크기 같은 작은 결정들로 만들어집니다.

이 글의 결론을 다시 정리합니다. "어디까지 키워야 하는가"에 대한 우리의 답은 단일한 숫자가 아니라 세 겹의 방향입니다 — 키울 수 있고, 키워도 흐트러지지 않으며, 키우기 전에도 충분히 읽히는 화면. 그리고 이 방향은 법이 요구하기 때문이 아니라, 사용자가 거기에 있기 때문에 우리가 권하는 것입니다.

다시 강조하지만, 이 글은 규정이 아니라 관점입니다. 우리는 공개된 표준(WCAG·KWCAG)과 공공의 설계 기준(KRDS), 그리고 관찰한 데이터를 종합해 "이 방향이 옳다고 본다"고 말할 뿐입니다. 더 나은 근거가 나오면 우리의 관점도 갱신될 것입니다. 그것이 '연구'라는 말에 우리가 담은 태도입니다. 글자 크기처럼 사소해 보이는 항목을 길게 다룬 이유도 같습니다. 가장 사소해 보이는 곳에서 가장 조용한 배제가 일어나기 때문입니다.

다음 편 예고 (002): [접근성연구·고령] 확대하면 무너지는 화면들 — 글씨를 키울 때 레이아웃에 실제로 무슨 일이 벌어지는지, 관찰된 붕괴의 유형을 항목별로 정리합니다.


참고한 공개 자료(출처):

  • WCAG 2.1 성공 기준 1.4.3 Contrast / 1.4.4 Resize Text / 1.4.10 Reflow / 1.4.12 Text Spacing (W3C WAI)
  • 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2 공개 문서
  • 디지털 정부서비스 UI/UX 가이드라인(KRDS) 소개 및 타이포그래피 기준
  • 고령 인구 통계(공개 통계 인용) · 노안(presbyopia) 일반 안과 상식
#디지털접근성#고령층UX#글자크기#가독성#노안#WCAG#텍스트확대#리플로우

관련 글

디지털 접근성 연구

[접근성연구·디지털포용] 한 사람이 여러 벽을 동시에

앞 편(081)에서 디지털 포용이 여러 갈래의 사용자를 하나의 목표로 묶는다고 봤다. 그리고 끝에서 한 가지를 남겼다 — 현실의 한 사람은 여러 조건을 동시에 가질 수 있다고. 이 시리즈를 닫는 이번 편은 그 '겹침'을 정면으로 본다. 영역의 경계를 가로질러, 조건이 겹칠 때 접근성이 어떻게 더 가팔라지는지를 관찰한다.

ViewCheck Insight·2026.07.19
디지털 접근성 연구

[접근성연구·디지털포용] 디지털포용법이 말하는 '포용'

앞 편(080)에서 초고령사회라는 인구구조의 신호를 봤다. 그리고 끝에서 한 가지를 분명히 했다 — 디지털 격차는 고령에만 있는 것이 아니라고. 이번 편은 그 여러 갈래의 격차를 '디지털 포용(digital inclusion)'이라는 하나의 정책 틀에서 함께 본다. 이 시리즈는 그동안 사용자를 영역별로 나눠 다뤘다. 고령

ViewCheck Insight·2026.07.19
디지털 접근성 연구

[접근성연구·디지털포용] 초고령사회, 공공웹은 준비됐나

공공앱 세 편(077~079)으로 매체의 확장을 닫았다. 이제 시선을 한 번 더 넓힌다. 지금까지 이 시리즈는 주로 '한 사람이 화면 앞에서 겪는 어려움'을 다뤘다. 고령(001~014), 저시력(029~043), 키보드(047~049)처럼, 개별 사용자의 자리에서 벽을 봤다. 이번 묶음(080~082)은 그 시선을 거시

ViewCheck Insight·2026.07.19