가변폰트에 대한 통념 4가지, 지금도 맞는 말일까

"가변폰트요? 파일 무겁고 설정 복잡하다던데, 실무에선 잘 안 쓰지 않나요?"

처음 가변폰트를 알게 됐을 때 이런 말을 들었다. 반박할 말도 딱히 없어서 그냥 넘어갔는데, 나중에 Pretendard Variable 관련 자료를 파고들면서 생각이 달라졌다. 저 말들이 틀린 건 아닌데, 2019년 기준으로 맞는 말이었다는 걸 알게 됐거든요.

가변폰트를 둘러싼 통념은 생각보다 오래된 이야기에 기대고 있는 경우가 많다. 브라우저 지원도, 한글 폰트 생태계도, 실제 파일 크기 조건도 그사이 꽤 많이 바뀌었다. 네 가지 통념을 하나씩 짚어보자.

"파일이 더 무겁다"는 말, 비교 기준이 잘못됐다

가변폰트 파일 하나를 처음 열면 800KB 넘는 숫자가 나오니까 "무겁다"는 인상을 받기 쉽다. 그런데 그 비교가 공평하지 않다는 게 문제다.

실무에서 웹폰트를 쓸 때 단일 weight만 쓰는 경우는 드물다. 보통 Regular, SemiBold, Bold 최소 세 개는 함께 로드한다. 정적 폰트는 weight 수만큼 파일이 필요하고, 각각 HTTP 요청이 따로 나간다. 가변폰트는 그 전체 range가 파일 하나에 들어 있다.

Pretendard로 직접 비교하면 이렇다.

서브셋 없이 원본 그대로 쓰면 확실히 무겁다. 하지만 자주 쓰는 한글 글리프와 weight 범위만 추려서 서브셋 처리하면 273KB 수준으로 내려간다. 원본 2.0MB 대비 약 86% 감소한 셈이다. 정적 3개 파일 합산과 거의 같은 용량이면서 HTTP 요청은 세 배 줄어드는 셈이다.

서브셋 최적화란 간단히 말하면 폰트 파일에서 실제로 쓸 글자와 weight 범위만 골라 다시 패키징하는 작업이다. 11,172자 전체가 아니라 자주 쓰는 한글 2,350자 남짓과 숫자·영문 기본셋만 남기면 파일 크기가 극적으로 줄어든다. 기존 정적 폰트 방식에서는 weight별로 이 작업을 여러 번 해야 했지만, 가변폰트는 파일 하나로 끝난다는 게 차이다.

"가변폰트가 무겁다"는 말은 서브셋 최적화 없이 단순 비교했을 때 나오는 결론이다. 최적화 후 실무 조건에서 비교하면 이야기가 달라진다.

"브라우저 지원이 불안정하다"는 건 2019년 얘기다

가변폰트가 처음 등장하던 시기에 이 말은 사실이었다. 브라우저마다 지원 범위가 제각각이었고, 모바일은 더 불안정했다.

지금은 다르다. Can I Use 기준 전 세계 브라우저의 96% 이상이 가변폰트를 지원한다. Chrome, Edge, Firefox, Safari, Samsung Internet, Opera, iOS Safari까지 모두 정식 지원이다. 지원하지 않는 환경은 사실상 구형 Internet Explorer뿐이다.

실질적으로 어떤 의미냐면 — 오늘날 웹 서비스의 주류 브라우저는 전부 가변폰트를 쓸 수 있다는 얘기다. Chrome과 Firefox는 2018년, Safari는 2018년 macOS Mojave 기준, Edge는 2019년 초부터 정식 지원에 들어왔다. 이미 6~7년이 지난 얘기다.

@font-face에 format('woff2-variations')를 명시하면 지원 브라우저에선 가변폰트를, 나머지에선 일반 format('woff2')로 폴백 처리할 수 있어서 하위 호환도 깔끔하게 된다. 브라우저 지원이 걱정돼서 가변폰트를 못 쓰겠다면, 그 걱정의 근거가 언제 것인지 먼저 확인해봐야 한다.

"CSS 설정이 복잡하다"는 건 낯선 이름에 겁먹은 것이다

font-variation-settings라는 속성 이름을 처음 보면 뭔가 복잡한 게 있을 것 같다는 느낌이 드는데, 실제로 열어보면 기존 @font-face 선언에서 딱 두 줄이 달라질 뿐이다.

가장 많이 쓰이는 패턴은 이렇다.

@font-face {
  font-family: 'PretendardVariable';
  src: url('PretendardVariable.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-style: normal;
  font-display: swap;
}

body {
  font-family: 'PretendardVariable', sans-serif;
  font-weight: 400;
}

h1 {
  font-weight: 700;
}

font-weight: 100 900으로 가변 범위를 한 번 선언해두면, 이후엔 평소처럼 font-weight: 400 이런 식으로 쓰면 된다. 브라우저가 내부적으로 wght 축과 font-weight 값을 매핑해서 처리하기 때문에, 가변폰트를 쓴다고 해서 기존 CSS 작성 방식을 바꿀 필요가 없다. 이미 쓰던 font-weight 숫자를 그대로 유지하면 된다.

더 세밀하게 제어하고 싶을 때는 font-variation-settings를 쓴다. 폰트 디자이너가 정의한 변형 가능한 축인데, 대표적으로 세 가지가 자주 쓰인다. wght는 굵기 축으로 100~900 사이 어떤 값이든 정확하게 표현하고, slnt는 기울기를 이탤릭처럼 이분법이 아니라 연속값으로 조절해 미묘한 경사를 표현할 수 있다. wdth는 글자의 가로 폭 비율을 조절하는 축으로, 좁거나 넓은 변형 서체를 별도 파일 없이 구현할 수 있다.

.display-text {
  font-variation-settings: 'wght' 650, 'slnt' -5;
}

정적 폰트에서는 SemiBold(600)와 Bold(700) 사이에 값을 줄 방법이 없다. 가변폰트에서는 650 같은 중간값도 정확하게 표현된다. 이 유연함이 가변폰트를 쓰는 이유의 절반이다.

"한글 가변폰트는 아직 없다"는 통념, 실무 선택지가 이미 넷이다

"한글은 글자 수가 너무 많아서 가변폰트 만들기 어렵다"는 말 자체는 사실이다. 현대 한글 11,172자를 전부 담아 가변 처리하려면 만만치 않은 작업이 필요하다. 이 어려움이 "아직 없다"는 오해로 굳어진 것이다.

틀렸다. 실무에서 당장 쓸 수 있는 한글 가변폰트가 이미 여럿 나와 있다.

가장 먼저 손이 가는 건 역시 Pretendard Variable이다. OFL 라이선스라 상업 사용도 가능하고, GitHub 공식 저장소에서 바로 받을 수 있다. 디자인 시스템을 구축하는 팀에서 많이 선택하는 이유가 여기 있다. weight 범위(Thin 100 ~ Black 900)가 넓고 라이선스 걱정이 없으니 한 번 설정해두면 두고두고 쓸 수 있다.

Noto Sans KR Variable은 구글 폰트에서 CDN 방식으로 제공해, 별도 다운로드 없이 한 줄이면 바로 임베드할 수 있다. 사이드 프로젝트나 빠르게 세팅해야 하는 경우에 편하다. 나눔스퀘어 네오 Variable은 네이버와 산돌이 협업한 폰트로, 현대 한글 11,172자 완성형을 전부 담아 특수한 글자가 깨질 걱정이 없다는 게 강점이다. 세리프 계열이 필요하다면 구글 폰트에 올라온 한글 세리프 가변폰트 Hahmlet도 선택지다.

"없다"는 통념이 아직 도는 건, 2020년 이전 한글 가변폰트 생태계가 실제로 빈약했기 때문이다. 지금은 아니다. Pretendard Variable의 웹사이트 적용 가능 여부와 OFL 조건 상세는 폰트비에서 확인할 수 있다.

그럼 "막연한 인상"이 왜 이렇게 오래 살아남았나

네 가지 통념이 지금도 도는 데에는 공통된 패턴이 있다. 초기 사실이 맞았다는 것이다. 2018~2020년 가변폰트는 실제로 브라우저 지원이 불안정했고, 한글 가변폰트는 없다시피 했고, 서브셋 최적화 없이 쓰면 분명히 무거웠다. 그 인상이 검증 없이 굳었다.

하지만 가변폰트가 항상 유리한 건 아니라는 점은 지금도 사실이다. 사이트에서 딱 하나의 weight만 쓰고 서브셋 최적화까지 할 여력이 없다면, 서브셋 정적 woff2 파일 하나가 오히려 더 가벼울 수 있다. 통념을 깨는 게 목표가 아니라 실제 상황에 맞는 선택을 하는 게 목표다.

weight를 3개 이상 쓰거나 미세한 굵기 조절이 필요한 디자인 시스템이라면 가변폰트 쪽이 분명히 이득이다. 특히 랜딩 페이지처럼 헤딩·본문·강조 텍스트가 각자 다른 굵기를 쓰는 구조라면, 가변폰트 하나로 정리하는 게 유지보수 면에서도 편하다. 반대로 블로그처럼 본문 폰트 하나만 쓰고 서브셋 최적화에 손을 댈 여력이 없다면 정적 woff2로도 충분하다.

막연하게 "무겁고 복잡하다"는 인상으로 지나치기보다, 실제로 몇 개 weight를 로드하는지부터 세어보는 게 시작이다. Pretendard Variable이라면 @font-face 한 줄 선언해보고 실제 파일 크기를 재보는 것만으로도 감이 온다. 서브셋 최적화 여부는 그 다음에 판단해도 충분히 늦지 않다. 통념을 버리는 데 드는 비용은 그 정도면 충분하다 🙂

참고자료

• MDN Web Docs — Variable fonts guide
• Can I use — Variable fonts 브라우저 지원 현황
• Pretendard — 공식 GitHub 저장소