🔍 피그마 변수로 폰트 접근성 테스트? 디자이너라면 지금 바로 해야 하는 이유

 

 

사용자 4명 중 1명이 내 디자인을 다르게 보고 있다

앱이나 웹 서비스를 만들다 보면 자연스럽게 놓치는 게 있어요. 바로 "이 글자 크기, 다른 사람들은 어떻게 보고 있을까?"라는 질문이에요.

2026년 기준 APPT 통계에 따르면, 안드로이드와 iOS 모바일 기기 사용자의 26%가 기본 폰트 크기를 확대해서 쓰고 있다고 해요. 4명 중 1명이라는 숫자, 생각보다 꽤 크죠? 우리가 기본값으로 디자인한 그 화면을, 정작 사용자 넷 중 하나는 전혀 다른 크기로 보고 있다는 뜻입니다.

더 충격적인 건, 이게 특수한 소수의 이야기가 아니라는 점이에요. 고령자, 약시가 있는 사람, 스마트폰 글씨가 작아서 불편한 사람까지 합치면 이 숫자는 더 올라갑니다. 그리고 그분들이 폰트를 키웠을 때 텍스트가 겹치고, 버튼이 잘리고, 레이아웃이 무너진다면? 그냥 불편한 게 아니라 서비스 자체를 쓰지 못하는 상황이 돼버리는 거죠.

왜 이게 접근성 문제인가요?

폰트 크기 확대 테스트는 단순히 UX의 문제가 아닙니다. 국제 웹 콘텐츠 접근성 지침인 WCAG의 성공 기준 1.4.4 '텍스트 크기 조정'을 보면, 보조 기술 없이도 텍스트를 최대 200%까지 확대할 수 있어야 하고, 이 과정에서 콘텐츠나 기능이 손상되면 안 된다고 명시하고 있어요.

한국도 예외가 아닙니다. 장애인차별금지법 개정에 따라 2023년부터 모바일 앱에 대한 접근성 의무가 단계적으로 적용되기 시작했고, 2025년 1월부터는 상시 100인 미만 사업주에게까지 확대됐어요. 과기정통부가 2026년 3월에 발표한 2025년 웹 접근성 실태조사를 보면, 여전히 많은 서비스가 접근성 기준을 제대로 충족하지 못하고 있다는 결과가 나왔습니다.

접근성을 어기면 어떻게 될까요? 국가인권위원회에 진정이 접수되면 시정 권고를 받고, 이를 무시하면 3천만 원 이하의 과태료, 악의적인 경우에는 3년 이하의 징역까지 선고될 수 있어요. 법적 리스크가 현실이 된 시대입니다.

그런데도 왜 대부분의 팀이 이 테스트를 빠뜨릴까

솔직하게 얘기해 볼게요. 접근성이 중요하다는 건 다들 알아요. 근데 현실에서는 후순위로 계속 밀립니다.

특히 폰트 크기 확대 테스트는 "그거 개발하면서 체크하면 되지 않나요?"라는 말을 참 많이 듣는 항목이에요. 디자이너 입장에서는 프로토타입을 따로 만들어야 하나 싶고, 개발자 입장에서는 디자인 스펙대로 구현했는데 왜 문제냐고 하고, 결국 아무도 챙기지 않는 상황이 반복됩니다.

이게 개발 이후에 발견되면 어떻게 될까요? 레이아웃 전체를 다시 건드려야 하는 경우가 생겨요. 컴포넌트 설계가 잘못된 경우에는 수정 비용이 처음 만들 때보다 몇 배 더 들기도 합니다. 미리 잡는 버그가 나중에 잡는 버그보다 훨씬 저렴하다는 건 개발자분들은 직감적으로 아실 거예요. 접근성 테스트도 똑같아요.

피그마 Variables가 이 문제를 해결한다

여기서 피그마의 변수 기능이 진짜 빛을 발해요. 변수(Variables)는 색상, 크기, 간격 같은 디자인 요소 값을 하나의 변수로 묶어 관리하는 기능인데요. 다크모드와 라이트모드 전환에 많이 써봤다면 바로 감이 오실 거예요.

핵심 아이디어는 간단합니다. 폰트 크기와 줄 간격 값을 숫자형 변수로 정의해두고, 100% 기본 모드와 125%, 150%, 200% 확대 모드를 별도로 만들어두는 거예요. 다크모드 전환하듯이 클릭 한 번으로 "폰트 100% 모드" → "폰트 200% 모드"로 전환하며 레이아웃이 어떻게 무너지는지 디자인 단계에서 바로 확인할 수 있습니다.

별도의 복사본을 만들 필요도 없어요. 실제 화면 흐름 안에서 실시간으로 테스트할 수 있다는 게 이 방법의 진짜 강점입니다.

이 방법을 쓰려면 무엇이 갖춰져 있어야 할까

이 테스트가 제대로 동작하려면 세 가지 전제가 있어요. 피그마의 텍스트 스타일, 오토 레이아웃, 그리고 변수 기능을 제대로 쓰고 있어야 한다는 점입니다.

텍스트 스타일 없이 폰트를 요소마다 개별 설정해뒀다면, 변수를 아무리 잘 만들어도 일괄 적용이 안 됩니다. 오토 레이아웃 없이 고정 크기로 레이아웃을 짜뒀다면, 폰트가 커졌을 때 컨테이너가 버텨주지 못해요.

그래서 오히려 역으로 생각하면 좋아요. 폰트 접근성 테스트를 준비하는 과정이 곧 디자인 시스템을 정비하는 기회가 됩니다. 접근성을 핑계로 내부 구조를 한 번 깔끔하게 정리할 수 있는 거죠.

실제로 어떻게 적용하나요?

구체적인 흐름을 정리해드릴게요.

먼저 현재 사용 중인 텍스트 스타일 목록을 피그마에서 정리합니다. 본문, 제목, 캡션, 라벨 등 각 스타일별로 font-size와 line-height를 숫자형 변수로 지정해요. 이게 기본 모드입니다. 그 다음, 동일한 변수들을 125%, 150%, 200% 확대 버전으로 새 모드를 추가해요.

이때 중요한 포인트가 있어요. 모든 텍스트를 동일 비율로 키울 필요는 없다는 겁니다. 본문 텍스트는 200%까지 키워도 괜찮지만, 캡션이나 라벨은 다른 비율을 적용하는 게 적절할 수 있어요. 그 판단을 디자이너가 미리 해두는 게 이 방법의 핵심이에요.

세팅을 마치면 모드를 전환하는 것만으로 화면 전체가 어떻게 반응하는지 바로 확인할 수 있어요. 레이아웃이 깨지는 지점, 어떤 컴포넌트가 취약한지, 개발에 넘기기 전에 디자인 단계에서 찾아낼 수 있습니다.

"디자인 시스템이 창의성을 제한한다"는 오해

가끔 이런 말을 하는 분들이 있어요. 변수나 디자인 시스템을 쓰면 규칙에 묶여서 창의적인 디자인이 어렵다고요.

근데 이건 생각해보면 반대입니다. 반복적이고 기계적인 부분을 자동화해두면, 디자이너가 정말 중요한 판단에 집중할 수 있거든요. 폰트 변수를 한 번 잘 설정해두면, 접근성 테스트는 클릭 몇 번으로 끝나요. 그 시간에 사용자 흐름의 디테일을 더 깊이 생각할 수 있는 거죠.

다크모드 대응을 위해 이미 변수 시스템을 갖춘 팀이라면, 그 구조를 그대로 폰트 스케일 테스트에 활용할 수 있어요. 완전히 새로 만드는 게 아닙니다. 이미 있는 자산을 확장하는 것뿐이에요.

접근성은 결국 팀 문화의 문제다

이게 핵심이에요. 접근성은 "중요하다"는 구호에서 멈추면 아무것도 안 돼요.

특정 사람이 접근성 체크리스트를 따로 들고 다니는 방식은 지속되지 않아요. 결국 그 한두 사람의 부담이 되고, 사람이 바뀌면 사라지는 구조거든요. 반면 피그마 변수처럼 설계 과정 자체에 녹아들어 있는 방법은 누구나 자연스럽게 확인하게 됩니다.

한 번 잘 만들어두면 팀 전체가 쓸 수 있고, 신규 디자이너가 온보딩할 때도 이게 기본 프로세스가 돼요. 작은 변화처럼 보이지만, 팀의 접근성 문화를 만드는 첫걸음이 됩니다. 접근성은 특별한 프로젝트가 아니라 평범한 일상 속에 있어야 해요.

지금 한국 상황에서 왜 더 중요해졌나

2025년, 우리나라는 공식적으로 초고령사회에 진입했어요. 국가인권위원회도 디지털 격차로 인한 노인 인권 침해 문제를 지속적으로 권고 사항으로 다루고 있습니다.

고령화가 빠르게 진행될수록 폰트를 키워서 쓰는 사용자는 더 늘어날 수밖에 없어요. 지금 내가 만드는 서비스를 10년 후 부모님이 쓸 수도 있다고 생각해보세요. 그리고 그 서비스가 글씨를 키웠을 때 제대로 동작하지 않는다면?

접근성은 "착한 서비스"를 위한 옵션이 아니에요. 더 많은 사람이 쓸 수 있는 서비스를 만들기 위한 기본 요건입니다. 그리고 이제는 법적 의무이기도 해요.

마무리

사용자 4명 중 1명이 폰트를 키워서 쓰고 있다는 사실, 이제 무시하기 어렵습니다. 피그마 변수를 활용한 폰트 스케일 테스트는 복잡한 추가 작업 없이, 이미 익숙한 도구 안에서 접근성을 챙길 수 있는 가장 현실적인 방법이에요.

텍스트 스타일, 오토 레이아웃, 변수 세 가지를 갖춘 팀이라면 오늘부터 바로 시작할 수 있어요. 접근성은 완벽한 준비가 필요한 게 아니라, 지금 당장 한 걸음을 내딛는 것에서 시작됩니다.