[접근성연구·고령] 우리 사이트는 글자 확대에 견디는가

가독성 자가점검 관점

〈디지털 접근성 연구 ③〉 — 이 글은 규정이 아니라 하나의 연구 관점입니다. 앞 두 편에서 "어디까지 키워야 하나(①)"와 "키우면 어떻게 무너지나(②)"를 다뤘다면, 이번 편은 "그래서 우리 화면이 견디는지 어떻게 직접 확인하나"를 점검의 관점에서 정리합니다. 특정 도구가 아니라 누구나 따라 할 수 있는 방법을 봅니다.

들어가며 — "괜찮겠지"는 점검이 아니다

화면을 만든 사람에게 "이 사이트 글자 확대 잘 되나요?"라고 물으면, 많은 경우 "네, 반응형이라 괜찮습니다"라는 답이 돌아옵니다. 그런데 그 자리에서 실제로 글자를 키워보면, 앞 편에서 본 무너짐이 그대로 나타나는 일이 적지 않습니다. "괜찮겠지"라는 짐작과 "괜찮다"는 확인 사이에는 생각보다 큰 간극이 있습니다.

이 간극이 위험한 이유는, 글자 크기 문제가 조용히 실패하기 때문입니다. 화면이 멈추거나 에러를 띄우면 누군가는 알아채고 고칩니다. 그러나 글자가 작아서 못 읽는 사용자는 오류 메시지를 남기지 않습니다. 그냥 창을 닫고 떠납니다. 만든 사람은 "별 문제 없다"고 믿고, 사용자는 "여기는 어렵다"고 떠나는 — 이 어긋남이 점검 없이는 영영 좁혀지지 않습니다.

이번 편은 그 간극을 메우는 이야기입니다. 우리는 거창한 장비나 전문 지식 없이도, 누구나 몇 분 안에 "우리 화면이 글자 확대에 견디는지"를 직접 확인할 수 있다고 봅니다. 핵심은 사용자가 실제로 하는 행동을 똑같이 해 보는 것입니다. 사용자가 글자를 키운다면, 점검하는 우리도 키워봐야 합니다. 만든 사람이 한 번도 키워보지 않은 화면을 사용자만 키워서 쓰는 상황 — 이것이 대부분의 문제가 발견되지 않는 진짜 이유입니다. 다시 강조하지만, 이건 규정이 아니라 우리가 권하는 관점이고, 특정 제품을 전제하지 않습니다.

1. 점검은 무엇을 확인하는 일인가 — 세 가지 축

앞서 우리는 글자 크기 대응을 세 겹으로 정리했습니다. 점검도 같은 세 축을 확인하는 일입니다.

확대 가능성 — 사용자가 글자를 키우면, 정말 커지는가?
재배치 가능성 — 키우거나 화면을 좁혀도, 가로 스크롤 없이 흐르는가?
기본 가독성 — 키우기 전에도, 충분히 읽히는가?

점검이란 결국 이 세 질문에 "그렇다/아니다"로 답을 모으는 과정입니다. 막연히 "잘 보이나?"가 아니라, 세 축으로 나눠 물으면 빠뜨리는 곳이 줄어듭니다. 각 축은 확인 방법이 다르므로 따로 봐야 합니다. 확대 가능성은 글자를 키워봐야 알고, 재배치 가능성은 화면을 좁혀봐야 알며, 기본 가독성은 아무것도 건드리지 않은 상태에서 거리를 두고 봐야 압니다. 한 가지 동작만으로는 세 축을 다 확인할 수 없습니다.

우리가 이렇게 축을 나누는 이유는, 점검이 '인상'이 아니라 '확인'이 되게 하기 위해서입니다. "그냥 봐서 괜찮다"는 점검은 사람마다 기준이 다르고 그날그날 다릅니다. 그러나 "200%로 키웠을 때 가로 스크롤이 생기는가"는 누가 봐도 같은 답이 나옵니다. 점검을 다툼 없는 사실로 만들려면, 무엇을 확인할지부터 분명해야 합니다.

2. 표준이 점검의 기준선을 준다

점검의 합격선을 우리 마음대로 정하면 자의적이 됩니다. 다행히 공개된 표준이 기준선을 제공합니다.

인용 (WCAG 2.1, 1.4.4 Resize Text, AA): 텍스트를 200%까지 확대했을 때 콘텐츠·기능 손실이 없어야 한다.

인용 (WCAG 2.1, 1.4.10 Reflow, AA): 너비 320px 상당까지 가로 스크롤 없이 재배치되어야 한다.

이 두 문장은 점검의 두 동작을 그대로 알려줍니다 — "200%로 키워볼 것", 그리고 "320px 너비로 좁혀볼 것". 우리는 이 두 동작을 점검의 기본기로 삼습니다. 합격 여부도 "예뻐 보이는가"가 아니라 표준의 표현대로 "손실이 없는가, 가로 스크롤이 없는가" 로 판단합니다.

기준이 표준에 있으면 좋은 점이 또 있습니다. 점검 결과를 두고 다툴 일이 줄어듭니다. "내 눈엔 작아 보이는데"와 "내 눈엔 괜찮은데"가 부딪히면 결론이 안 납니다. 그러나 "200% 확대 시 제출 버튼이 화면 밖으로 나간다"는 누가 봐도 사실이라 다툴 여지가 없습니다. 점검을 취향 싸움이 아니라 사실 확인으로 만드는 것 — 표준을 기준선으로 삼는 가장 큰 이유입니다.

3. 단계별 점검 방법 — 누구나 따라 할 수 있게

특별한 도구 없이도 할 수 있는 점검 방법을 단계로 정리합니다. 사실 기반의 방법 설명이므로 명확하게 적습니다.

단계 1 — 데스크톱 브라우저에서 확대해 본다

PC 브라우저에는 화면 확대 기능이 기본으로 있습니다(보통 Ctrl/Cmd와 +). 화면을 200%까지 키워 봅니다. 이때 보는 것은 단순합니다 — 글자가 커지면서 가로 스크롤이 생기는지, 버튼이나 글자가 잘리거나 겹치는지, '제출' 같은 버튼이 여전히 보이는지. 앞 편의 여섯 유형(넘침·잘림·겹침·사라짐·깨진 정렬·갇힘)을 떠올리며 보면 빠짐없이 확인할 수 있습니다.

여기서 주의할 점이 하나 있습니다. 브라우저의 '전체 확대(zoom)'와 '텍스트만 확대'는 다릅니다. 전자는 글자와 레이아웃을 함께 키우고, 후자는 글자만 키웁니다. 둘 다 확인하는 편이 좋지만, 특히 '텍스트만 확대'에서 깨지는 화면이 많습니다. 글자 단위가 px로 고정돼 있으면 텍스트 확대 자체가 안 먹기도 하니, 이 항목은 별도로 봐야 합니다. 전체 확대만 보고 "잘 커지네"라고 판단하면, 정작 사용자가 시스템에서 글꼴만 키운 상황을 놓칩니다.

단계 2 — 모바일에서 시스템 글꼴을 키워 본다

PC만으로는 부족합니다. 고령 사용자의 다수는 폰을 쓰기 때문입니다. 스마트폰의 설정에서 시스템 글꼴 크기를 최대 가까이 키운 뒤, 그 상태로 사이트를 열어봅니다. 이때 글자가 시스템 설정을 따라 커지는지(확대 가능성), 커진 글자가 화면을 깨뜨리지 않는지를 봅니다. PC 확대에서는 멀쩡했는데 모바일 글꼴 확대에서 깨지는 경우가 적지 않으므로, 이 단계는 생략하지 않는 편이 좋습니다.

여건이 되면, 점검용으로 글꼴을 키워 둔 폰을 한 대 따로 두는 것도 방법입니다. 매번 설정을 바꾸는 번거로움을 없애면, 점검이 일상 작업에 더 잘 자리 잡습니다. 점검의 가장 큰 적은 어려움이 아니라 번거로움입니다.

단계 3 — 화면을 좁혀 본다(재배치 확인)

PC 브라우저 창의 너비를 점점 좁히거나, 개발자 도구의 기기 미리보기로 **좁은 화면(약 320px)**을 만들어 봅니다. 이때 콘텐츠가 가로 스크롤 없이 위아래로 잘 흐르는지(재배치)를 봅니다. 글자 확대와 화면 좁힘은 사실상 비슷한 압력을 화면에 주므로, 둘을 함께 확인하면 약한 지점이 더 잘 드러납니다. 좁은 화면에서 가로 스크롤이 생긴다면, 그 화면은 확대에서도 거의 틀림없이 넘칩니다.

단계 4 — 기본 상태의 가독성을 본다

마지막으로, 아무것도 키우지 않은 기본 상태에서 본문이 편하게 읽히는지를 봅니다. 가능하면 점검하는 본인의 좋은 시력이 아니라, 노안이 있는 분이 팔을 뻗어 폰을 든 거리에서 본다고 상상하며 봅니다. 기본이 너그러우면 확대는 보조가 되고, 기본이 인색하면 확대가 필수가 됩니다. 우리는 기본 상태의 가독성도 점검 항목에 포함해야 한다고 봅니다. "키우면 보이니까 됐다"가 아니라, "키우기 전에도 보이는가"를 묻는 것입니다.

4. 자주 놓치는 점검 포인트

위 단계를 거쳐도 빠뜨리기 쉬운 지점들이 있습니다. 우리의 관찰에서 자주 놓치는 것들을 모았습니다.

핵심 버튼만 따로 본다. 본문은 잘 커지는데 '신청'·'제출' 버튼의 글자만 작거나, 확대 시 그 버튼만 사라지는 경우가 있습니다. 가장 중요한 곳을 따로 확인하는 습관이 필요합니다.
입력 폼을 끝까지 해 본다. 폼은 글자 확대에 특히 약합니다(입력칸 높이 고정 등). 첫 화면만 보지 말고, 실제로 값을 넣고 다음 단계까지 진행해 봐야 잘림·사라짐이 드러납니다.
표와 목록을 본다. 데이터를 담은 표는 확대 시 정렬이 깨지기 쉽습니다. 요금표·일정표·자격 기준표 같은 페이지를 점검 대상에 꼭 포함합니다.
팝업·모달을 연 상태로 확대해 본다. 팝업은 닫기 버튼이 화면 밖으로 나가 '갇힘'이 생기기 쉽습니다. 팝업이 떠 있는 상태에서 확대해, 닫기가 되는지 봅니다.
여러 페이지를 본다. 메인 한 화면만 보고 "괜찮다"고 판단하면, 정작 신청·민원처럼 사용자가 자주 가는 깊은 페이지를 놓칩니다. 사용자가 실제로 일을 해내는 경로를 따라가며 점검해야 합니다.
다른 환경에서 본다. 같은 사이트라도 운영체제·브라우저에 따라 글자 처리 방식이 조금씩 다릅니다. 가능하면 한 환경에만 의존하지 않습니다.

이 목록의 공통점은, 하나같이 "기본 상태의 첫 화면"만 보면 놓치는 것들이라는 점입니다. 점검이 실패하는 가장 흔한 이유는 어려워서가 아니라, 너무 일찍 "괜찮다"고 결론 내리기 때문입니다.

5. 자가점검의 한계와 보완 — 무엇을 사람이, 무엇을 일관되게

자가점검은 강력하지만 한계도 분명합니다. 우리는 이 한계를 솔직히 인정하는 편이, 점검을 더 잘 쓰는 길이라고 봅니다.

한계 1 — 페이지가 많으면 사람의 눈이 따라가지 못한다. 페이지가 수십·수백 개면, 모든 페이지를 사람이 일일이 확대해 보기 어렵습니다. 이때 단위가 상대 단위인지, 확대 시 가로 스크롤이 생기는지 같은 항목은 비교적 기계적으로 확인할 수 있는 영역이라, 일관된 기준으로 점검하는 편이 정확합니다. 사람의 눈대중은 페이지마다 기준이 흔들리지만, 일관된 점검은 그렇지 않습니다.

한계 2 — 기계가 답할 수 없는 질문이 있다. "이 글자 크기가 이 서비스의 사용자에게 충분한가", "이 화면에서 가장 중요한 글자가 가장 잘 보이는가" 같은 질문은 수치로 환원되지 않습니다. 이런 판단은 결국 사람이, 그것도 실제 사용자를 떠올리며 답해야 합니다. 기계는 "기준 미달"을 알려줄 수 있어도 "이 정도면 충분하다"를 판단하지는 못합니다.

한계 3 — 점검자도 사용자가 아니다. 점검하는 우리 역시 대개 디지털에 익숙한 사람이라, 고령 사용자의 실제 어려움을 온전히 느끼기 어렵습니다. 그래서 가능하면 실제 고령 사용자가 화면을 쓰는 모습을 한 번이라도 곁에서 보는 것이, 어떤 점검표보다 많은 것을 알려줍니다.

우리가 보는 결론은 이렇습니다. 자가점검은 "기계가 잡을 수 있는 것은 일관되게, 사람만 판단할 수 있는 것은 사람이"라는 분업으로 가야 한다. 모든 것을 사람의 눈에 맡기면 놓치고, 모든 것을 기계에 맡기면 핵심 판단을 잃습니다. 둘을 나눠 쓰는 것이 현실적입니다.

6. 점검 결과를 어떻게 다룰까 — '느낌'을 '기록'으로

점검에서 가장 중요한 것은 결과를 기록으로 남기는 것입니다. "대충 괜찮았다"는 며칠 뒤면 사라지지만, "○○ 페이지의 제출 버튼이 200% 확대 시 화면 밖으로 나간다"는 기록은 고칠 수 있는 일감이 됩니다. 우리는 점검을 인상이 아니라 사실의 목록으로 바꾸는 것이 핵심이라고 봅니다.

기록할 때는 세 가지를 함께 적으면 유용합니다 — 어느 페이지에서, 어떤 조건(예: 200% 확대, 320px 너비)에서, 무슨 유형의 무너짐(넘침/잘림/사라짐 등)이 일어났는가. 이 세 가지가 있으면, 고치는 사람이 같은 상황을 재현해 확인할 수 있습니다. 재현할 수 없는 결함 보고는 "어디서 봤는데 이상했다"는 막연한 말이 되어, 고치는 사람을 헤매게 합니다.

기록은 또한 우선순위를 매기는 근거가 됩니다. 앞 편에서 보았듯 무너짐의 유형마다 타격이 다릅니다. 기록이 쌓이면 "사라짐·갇힘처럼 과업을 멈추는 것부터, 그다음 잘림, 그다음…" 식으로 무엇을 먼저 고칠지 정할 수 있습니다. 점검의 목적은 "합격 도장"이 아니라 "고칠 수 있는, 순서가 매겨진 목록"을 만드는 것입니다.

7. 점검을 누가, 언제 하나 — 일상 작업에 넣기

점검이 한 번의 이벤트로 끝나면, 다음 업데이트에서 다시 무너집니다. 우리는 점검이 일상 작업의 일부가 되어야 지속된다고 봅니다. 누가 언제 하느냐에 대한 관점을 정리합니다.

만들 때 — 만든 사람이 그 자리에서. 화면을 만든 사람이 작업을 마치며 한 번 확대해 보는 것이, 가장 싸고 빠른 점검입니다. 남이 나중에 찾아내는 것보다, 만든 사람이 그 자리에서 보는 편이 고치기도 쉽습니다.

합칠 때 — 검수의 통과 조건으로. 새 화면이나 수정이 반영되기 전, "확대해서도 봤는가"를 통과 조건에 넣습니다. 이 한 줄의 조건이, 무너짐이 출시로 새어 나가는 것을 막습니다.

정기적으로 — 전체를 다시. 사이트는 시간이 지나며 조금씩 바뀌고, 그때마다 새 무너짐이 생길 수 있습니다. 분기에 한 번이든 반기에 한 번이든, 주요 경로를 다시 점검하는 주기를 두면 무너짐이 누적되지 않습니다.

이 셋의 공통점은 점검을 "특별한 행사"가 아니라 "기본 절차"로 만든다는 것입니다. 일회성 점검은 그 순간만 좋고, 절차가 된 점검은 계속 좋습니다. 우리는 후자를 권합니다.

8. 우리가 본 점검의 실제

점검이 실제로 어떻게 갈리는지, 익명의 장면으로 옮겨 봅니다.

장면 하나. ○○ 기관의 담당자는 "반응형이라 괜찮다"고 자신했지만, 그 자리에서 PC 브라우저를 200%로 키우자 신청 폼의 라벨이 입력칸과 겹쳤습니다. 본인도 처음 보는 장면이라 놀랐습니다. 만든 뒤 한 번도 확대해 본 적이 없었던 것입니다. 점검은 거창한 발견이 아니라, 사용자가 매일 보는 상태를 만든 사람이 처음 보는 일이었습니다.

장면 둘. 어느 페이지는 PC 확대에서는 멀쩡했지만, 폰의 시스템 글꼴을 키우자 본문이 전혀 커지지 않았습니다. 글자가 px로 고정돼 있었기 때문입니다. PC만 점검했다면 영영 몰랐을 문제였습니다. 두 환경을 모두 본다는 것의 중요성을 보여준 사례였습니다.

장면 셋. 한 팀은 점검 결과를 "○○ 페이지 / 200% 확대 / 제출 버튼 사라짐"처럼 기록으로 남겼습니다. 며칠 뒤 고치는 사람이 그 기록만 보고 같은 상황을 재현해 바로 확인할 수 있었습니다. 기록이 있는 점검과 없는 점검의 차이가 분명히 드러났습니다.

장면 넷. 또 다른 팀은 점검을 한 번 하고 끝냈는데, 몇 달 뒤 새 기능이 추가되며 같은 화면이 다시 무너졌습니다. 점검이 절차가 아니라 일회성 행사였던 탓입니다. 이후 그 팀은 "확대 점검"을 검수 통과 항목에 넣었고, 같은 무너짐이 반복되지 않았습니다.

장면 다섯. 한 담당자는 고령 가족에게 직접 사이트를 써 보게 했습니다. 점검표로는 통과했던 화면인데, 실제 어르신은 메뉴를 찾는 데부터 한참 헤맸습니다. 자가점검이 잡지 못한 부분을, 실제 사용자가 단번에 드러냈습니다. 점검의 마지막 보완은 결국 사람이라는 것을 보여준 장면이었습니다.

장면 여섯. 반대로 잘된 경우도 있었습니다. 어느 팀은 처음부터 점검을 작업 흐름에 넣어 두었습니다. 화면을 만들 때마다 글꼴을 키운 폰으로 한 번씩 확인했고, 새 기능을 합치기 전에는 "확대해서도 됐는가"를 통과 조건으로 두었습니다. 그 결과, 출시 후 "글자가 안 보인다", "버튼을 못 찾겠다"는 문의가 눈에 띄게 적었습니다. 특별히 뛰어난 기술을 쓴 것이 아니라, 그저 매번 한 번 더 봤을 뿐입니다. 우리는 이 장면이 점검의 핵심을 가장 잘 보여준다고 생각합니다 — 거창한 도구가 아니라, 반복되는 작은 습관이 차이를 만듭니다. 점검을 잘하는 팀과 못하는 팀의 차이는 능력이 아니라, "한 번 더 보는 습관이 절차에 박혀 있느냐"였습니다.

9. 점검을 막는 것들 — 어려움이 아니라 번거로움

점검이 좋다는 것을 모르는 사람은 거의 없습니다. 그런데도 점검이 잘 안 되는 이유는, 대개 어려워서가 아니라 번거로워서입니다. 우리는 점검을 가로막는 진짜 장벽이 기술이 아니라 마찰이라고 봅니다. 마찰을 줄이면 점검은 자연스럽게 늘어납니다.

"매번 설정을 바꾸기 귀찮다." 점검하려면 글꼴을 키우고, 화면을 좁히고, 다시 원래대로 돌려야 합니다. 이 작은 번거로움이 쌓이면 점검을 미루게 됩니다. 해법은 단순합니다 — 점검용으로 글꼴을 키워 둔 기기나 브라우저 프로필을 따로 두는 것입니다. 준비를 한 번 해 두면, 매번의 마찰이 사라집니다.

"지금은 시간이 없다." 마감에 쫓기면 점검은 가장 먼저 생략됩니다. 그래서 우리는 점검을 '여유 있을 때 하는 일'이 아니라 '작업의 일부'로 박아두는 것을 권합니다. 화면을 만든 사람이 마무리하며 30초간 확대해 보는 것은, 따로 시간을 내는 일이 아니라 작업의 마지막 동작입니다.

"괜찮겠지." 가장 조용한 장벽입니다. 별 근거 없이 "이 정도면 됐다"고 넘어가는 낙관입니다. 이 낙관을 깨는 가장 확실한 방법은, 한 번 직접 키워보고 깨지는 장면을 눈으로 확인하는 것입니다. 한 번 무너진 화면을 본 사람은 다시 "괜찮겠지"로 넘어가지 않습니다.

"누가 해야 할지 모르겠다." 책임이 분명하지 않으면 아무도 하지 않습니다. 점검을 만든 사람의 일로, 검수 통과의 조건으로 분명히 정해두면, "누군가 하겠지"가 "내가 한다"로 바뀝니다.

이 네 장벽의 공통점은 모두 마찰이라는 것입니다. 그리고 마찰은 줄일 수 있습니다. 점검을 거창한 결심이 아니라 마찰 없는 습관으로 만드는 것 — 우리는 이것이 지속되는 점검의 핵심이라고 봅니다.

10. 빠른 점검과 정밀 점검 — 두 단계로 나누기

모든 페이지를 똑같이 깊게 볼 수는 없습니다. 페이지가 많으면, 한 페이지를 끝까지 정밀하게 보는 사이에 다른 페이지들은 손도 못 댑니다. 그래서 우리는 점검을 두 단계의 깔때기로 나누는 관점을 권합니다.

1차 — 빠른 점검(넓게). 가능한 한 많은 페이지를, 가장 빠른 신호만으로 훑습니다. 핵심은 두 가지입니다 — 화면을 키웠을 때 가로 스크롤이 생기는가, 그리고 핵심 버튼이 여전히 보이는가. 이 두 가지만 봐도, 문제가 있을 가능성이 높은 페이지가 걸러집니다. 빠른 점검의 목적은 '완벽한 확인'이 아니라 '의심 페이지의 추림'입니다.

2차 — 정밀 점검(깊게). 1차에서 걸린 페이지, 그리고 사용자가 자주 가는 핵심 경로(신청·로그인·민원)를 골라, 폼을 끝까지 진행하고 팝업을 열고 표를 확대하며 깊이 봅니다. 정밀 점검은 시간이 들지만, 대상이 좁혀져 있어 감당할 수 있습니다.

이 두 단계의 이점은 자원을 가장 중요한 곳에 집중할 수 있다는 것입니다. 모든 페이지를 똑같이 깊게 보려다 아무것도 제대로 못 보는 일을 막아줍니다. 우리는 점검에서도 "넓게 한 번, 좁게 한 번"이라는 두 박자가 현실적이라고 봅니다. 한 박자만으로는 넓이와 깊이 중 하나를 포기하게 됩니다.

한 가지 덧붙이면, 1차의 '넓은 점검'은 비교적 기계적이라 일관된 기준으로 처리하기 좋은 영역이고, 2차의 '깊은 점검'은 사람의 판단이 필요한 영역입니다. 앞서 말한 분업 — 기계가 잡을 것은 일관되게, 사람만 판단할 것은 사람이 — 이 여기서도 그대로 적용됩니다.

11. 점검이 바꾸는 것 — 화면을 넘어

점검의 효과는 그 화면 하나를 고치는 데서 끝나지 않습니다. 점검이 습관이 되면, 더 넓은 것들이 함께 바뀝니다.

만드는 사람의 기본 시야가 바뀐다. 한 번 확대해 보는 습관이 들면, 다음 화면을 만들 때부터 "이게 커지면 어떻게 될까"를 미리 생각하게 됩니다. 점검은 결함을 찾는 일을 넘어, 애초에 결함을 덜 만드는 눈을 길러줍니다. 사후 점검이 사전 예방으로 이어지는 것입니다.

사용자의 신뢰가 쌓인다. 확대해도 멀쩡한 화면을 만나면, 사용자는 "여기는 나를 고려했구나"라고 느낍니다. 이 작은 신뢰가 쌓이면, 공공 서비스 전반에 대한 인상이 달라집니다. 반대로 한 번의 무너짐이 남기는 불신도 그만큼 넓습니다.

격차가 줄어든다. 점검으로 무너짐이 줄면, 디지털에 익숙하지 않은 사람도 같은 서비스를 끝까지 쓸 수 있게 됩니다. 같은 화면이 누구에게는 열리고 누구에게는 닫히던 차이가, 점검을 통해 좁혀집니다. 우리는 점검을 단순한 품질 관리가 아니라, 격차를 줄이는 작은 실천으로 봅니다.

이렇게 보면, "우리 사이트는 글자 확대에 견디는가"라는 질문은 기술적 점검을 넘어선 질문입니다. 그것은 결국 "우리 서비스는 누구까지 품고 있는가"를 묻는 일이기 때문입니다.

12. 점검 항목을 한 장으로 — 우리가 쓰는 질문들

지금까지의 점검을 한자리에 모으면, 다음의 질문 목록이 됩니다. 점검표라고 부를 수도 있지만, 우리는 '합격/불합격을 찍는 표'보다 '봐야 할 곳을 잊지 않게 돕는 질문 목록'에 가깝다고 봅니다. 각 질문 옆에 왜 그것을 보는지를 함께 적습니다. 이유를 알아야, 목록을 기계적으로 채우는 대신 제대로 보게 되기 때문입니다.

확대 가능성 — "글자가 정말 커지는가?" 브라우저 전체 확대와 텍스트만 확대, 그리고 모바일 시스템 글꼴 확대에서 각각 글자가 커지는지 봅니다. 셋 중 하나라도 안 커진다면, 글자 단위가 고정돼 있을 가능성이 큽니다. 이것을 먼저 보는 이유는, 확대 자체가 막혀 있으면 다른 점검이 무의미하기 때문입니다.

재배치 가능성 — "키우거나 좁혀도 가로 스크롤이 없는가?" 200% 확대, 그리고 320px 너비에서 콘텐츠가 옆으로 넘치지 않고 위아래로 흐르는지 봅니다. 가로 스크롤은 무너짐의 가장 빠른 신호이므로, 이 질문 하나로 의심 페이지를 빠르게 추릴 수 있습니다.

핵심 기능 — "중요한 버튼과 폼이 끝까지 작동하는가?" 확대 상태에서 '제출'·'다음' 같은 버튼이 화면 안에 있는지, 입력칸의 안내가 잘리지 않는지, 폼을 끝까지 진행할 수 있는지 봅니다. 본문이 멀쩡해도 핵심 기능이 막히면 서비스는 실패한 것이므로, 이 질문을 따로 둡니다.

구조적 요소 — "표·팝업·고정 요소가 견디는가?" 표의 정렬이 유지되는지, 팝업의 닫기가 가능한지, 화면에 고정된 바가 본문을 가리지 않는지 봅니다. 이들은 평소엔 잘 보이지 않다가 확대 상태에서만 문제를 드러내므로, 의식적으로 확인해야 합니다.

기본 가독성 — "키우기 전에도 충분히 읽히는가?" 아무것도 건드리지 않은 상태에서, 거리를 두고 봤을 때 본문이 편히 읽히는지 봅니다. 확대가 보조가 되려면 기본이 너그러워야 하므로, 이 질문을 마지막에 둡니다.

이 다섯 묶음의 질문은 외워서 쓰는 규칙이 아니라, 화면을 볼 때 자연스럽게 떠올리는 시선의 순서입니다. 익숙해지면 목록을 보지 않고도 같은 순서로 보게 됩니다. 우리는 좋은 점검표란 결국 '필요 없어지는 점검표'라고 봅니다 — 몸에 배면 목록 없이도 같은 곳을 보게 되기 때문입니다.

13. 점검에서 자주 나오는 질문들 — 오해와 답

점검을 이야기하면 현장에서 비슷한 질문을 받습니다. 우리의 관점에서 답을 정리합니다. 이 답들 역시 단정이 아니라 관점입니다.

"확대는 사용자가 알아서 하는 것 아닌가? 우리가 거기까지 봐야 하나?" — 사용자가 확대 기능을 쓰는 것은 맞습니다. 그러나 그 확대가 화면을 깨뜨린다면, 그것은 사용자의 책임이 아니라 화면의 문제입니다. 표준(WCAG 1.4.4)도 "확대 시 손실이 없어야 한다"고 화면 쪽의 책임으로 규정합니다. 사용자에게 "확대하지 말라"고 할 수는 없으니, 확대를 견디게 만드는 것은 만드는 쪽의 몫이라고 우리는 봅니다.

"점검에서 문제가 너무 많이 나오면 어떡하나?" — 처음 점검하면 문제가 많이 나오는 것이 자연스럽습니다. 그동안 보이지 않던 것이 드러나는 것뿐입니다. 중요한 것은 한 번에 다 고치는 것이 아니라, 앞 편에서 말한 우선순위 — 과업을 멈추는 것부터 — 로 순서를 매기는 것입니다. 많이 나온다는 것은 그만큼 개선의 여지가 크다는 뜻이기도 합니다.

"자동 점검 도구를 쓰면 사람이 안 봐도 되나?" — 아닙니다. 자동화는 "기준 미달"을 일관되게 잡아주지만, "이 정도면 이 사용자에게 충분한가"는 판단하지 못합니다. 우리는 둘을 분업으로 봅니다 — 기계가 잡을 수 있는 것은 일관되게 맡기고, 사람만 판단할 수 있는 것은 사람이 봅니다. 어느 한쪽에만 의존하면 빈틈이 생깁니다.

"한 번 점검하면 끝인가?" — 아닙니다. 사이트는 계속 바뀌고, 그때마다 새 무너짐이 생길 수 있습니다. 점검은 일회성 행사가 아니라 반복되는 절차여야 합니다. 만들 때·합칠 때·정기적으로 — 이 세 시점에 점검을 넣어두면, 무너짐이 누적되지 않습니다.

"점검은 개발자만의 일인가?" — 아닙니다. 확대해 보는 점검은 코드를 몰라도 할 수 있습니다. 기획자도, 디자이너도, 검수 담당자도 할 수 있고, 오히려 여러 시선이 보는 편이 더 많은 것을 잡아냅니다. 점검을 특정 역할의 전유물로 두지 않는 것이, 점검을 일상에 자리 잡게 하는 길이라고 우리는 봅니다.

14. 점검을 넘어 — 실제 사용자와 함께 보기

지금까지의 점검은 모두 '우리가 사용자의 조건을 재현해 보는' 방식이었습니다. 글꼴을 키우고, 화면을 좁히고, 폼을 끝까지 해 보는 것 — 이는 강력하지만 한계가 있습니다. 점검하는 우리는 결국 사용자가 아니기 때문입니다. 우리는 화면의 구조를 알고, 어디에 무엇이 있는지 이미 알고 있습니다. 그래서 우리에게는 쉬운 화면이, 처음 보는 고령 사용자에게는 미로일 수 있습니다.

그래서 우리는 점검의 마지막 단계로 실제 사용자와 함께 보는 것을 권합니다. 거창한 사용성 실험이 아니어도 됩니다. 고령의 가족이나 지인에게 "이 사이트에서 ○○ 신청을 한번 해 보시겠어요?"라고 부탁하고, 곁에서 조용히 지켜보는 것만으로도 많은 것이 드러납니다. 중요한 것은 돕지 않고 지켜보는 것입니다. 우리가 옆에서 "거기 누르시면 돼요"라고 거들면, 정작 그 화면이 혼자서는 안 된다는 사실이 가려집니다.

지켜보면 점검표가 잡지 못한 것들이 보입니다. 글자 크기는 통과였는데 정작 메뉴를 못 찾아 헤매기도 하고, 버튼은 잘 보이는데 그 버튼이 무엇을 하는지 몰라 누르기를 망설이기도 합니다. 어디서 머뭇거리는지, 어디서 한숨을 쉬는지, 어디서 "이게 맞나?" 하고 되묻는지 — 이런 신호는 어떤 자동 점검도 잡아내지 못합니다. 사람의 망설임은 사람만이 읽을 수 있습니다.

물론 한두 사람을 지켜본 것으로 모든 것을 일반화할 수는 없습니다. 그러나 우리는 '완벽한 표본'보다 '한 명의 진짜 사용자'가 더 많은 것을 가르쳐 줄 때가 많다고 봅니다. 통계적으로 대표성이 없더라도, 한 어르신이 특정 화면에서 멈추는 장면은 그 자체로 분명한 신호입니다. 한 명이 막혔다면, 비슷한 조건의 다른 많은 사람도 막힐 가능성이 큽니다.

이렇게 보면 점검은 세 겹입니다. 첫째, 기계적으로 일관되게 잡을 수 있는 것(단위·가로 스크롤 등). 둘째, 우리가 사용자의 조건을 재현해 보는 것(확대·좁힘·폼 진행). 셋째, 실제 사용자가 쓰는 모습을 지켜보는 것. 이 세 겹은 서로를 대체하지 않고 보완합니다. 기계는 사람의 망설임을 모르고, 재현은 진짜 낯섦을 모르며, 사용자 관찰은 모든 페이지를 다 커버하지 못합니다. 셋을 함께 쓸 때, 점검은 비로소 온전해집니다. 우리가 '자가점검'을 이야기하면서도 그 끝에서 '사용자와 함께 보기'를 권하는 이유가 여기에 있습니다.

맺으며 — 사용자가 하는 일을, 우리도 한 번은

이번 편의 결론은 단순합니다. 사용자가 글자를 키운다면, 점검하는 우리도 키워봐야 한다. 글자 확대에 견디는지를 확인하는 가장 확실한 방법은, 사용자가 실제로 하는 행동을 똑같이 해 보는 것입니다. 200%로 키우고, 320px로 좁히고, 핵심 버튼과 폼을 끝까지 해 보는 것 — 이 몇 가지 동작이 대부분의 무너짐을 드러냅니다.

그리고 그 점검은 한 번으로 끝나는 행사가 아니라, 만들 때·합칠 때·정기적으로 반복되는 절차여야 오래 갑니다. 기록으로 남기면 고칠 수 있는 목록이 되고, 사람만 판단할 수 있는 부분은 사람에게 남겨두면 됩니다.

다시 강조하지만, 이 글은 규정이 아니라 관점입니다. 점검의 단계도, 합격선도 표준을 근거로 삼되, 화면마다 사정은 다를 수 있습니다. 다만 "괜찮겠지"를 "확인했다"로 바꾸는 일은 어디서나 유효합니다. 그리고 그 확인은 거창하지 않습니다. 한 번 키워보는 것에서 시작합니다.

생각해 보면, 점검이라는 말은 무겁게 들리지만 그 본질은 가볍습니다. 그것은 결국 '내가 만든 것을, 내가 아닌 다른 조건에서 한 번 보는 일'입니다. 좋은 시력과 큰 모니터와 익숙함이라는 나의 조건을 잠시 내려놓고, 노안과 작은 폰과 낯섦이라는 사용자의 조건으로 같은 화면을 보는 것 — 그 잠깐의 시점 이동이 점검의 전부라고 해도 지나치지 않습니다. 그리고 그 시점 이동은 누구나, 지금 당장, 자기 손에 든 폰으로 할 수 있습니다. 우리가 이 편에서 어떤 전문 도구도 전제하지 않은 이유가 여기에 있습니다. 점검의 문턱은 생각보다 낮고, 그 효과는 생각보다 큽니다. 우리 사이트가 글자 확대에 견디는지를 아는 가장 빠른 길은, 지금 한 번 키워보는 것입니다.

이 편을 마치며 한 가지를 덧붙이고 싶습니다. 점검은 누군가를 탓하기 위한 일이 아닙니다. 무너짐을 찾는 것은 "누가 잘못 만들었나"를 가리려는 것이 아니라, "어디를 더 좋게 할 수 있나"를 보려는 것입니다. 만든 사람도 몰랐고, 사용자는 말하지 않았던 그 틈을 함께 메우는 일 — 점검을 그렇게 받아들일 때, 점검은 부담이 아니라 더 많은 사람에게 화면을 여는 즐거운 작업이 됩니다. 다음 편에서는 글자 크기를 넘어, 화면의 구조 자체가 어떻게 사용자를 돕거나 헤매게 하는지를 살펴보겠습니다. 잘 보이는 화면을 만드는 일과, 길을 잃지 않는 화면을 만드는 일은 결국 하나로 이어져 있기 때문입니다.

다음 편 예고 (004): [접근성연구·고령] '한 화면 한 과업'이라는 원칙 — 글자 크기를 넘어, 고령 사용자를 위한 정보구조의 관점으로 들어갑니다.

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

WCAG 2.1 성공 기준 1.4.4 Resize Text / 1.4.10 Reflow (W3C WAI)
한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2 공개 문서
디지털 정부서비스 UI/UX 가이드라인(KRDS) 소개