가변 폰트, 지금 전환하지 않아도 괜찮은 이유

결론부터 말하면, 대부분의 프로젝트는 지금 전환하지 않아도 됩니다.

가변 폰트를 권하는 글은 많습니다. 파일 하나로 수십 굵기를 쓸 수 있다, HTTP 요청이 줄어든다, 반응형 타이포그래피가 가능해진다 — 전부 맞는 말이지만, 그 이점이 실제로 발생하는 조건이 따로 있습니다. 조건이 맞지 않으면 전환은 번거로움만 늘립니다.

아래는 "전환하지 않는 게 더 나은" 세 가지 상황입니다. 해당하는 게 하나라도 있으면, 지금 정적 폰트로 두는 편이 낫습니다.

굵기 두 개 이하로 쓰고 있다면

수치부터 보면 이렇습니다.

Inter Regular WOFF2 하나만 쓴다면 약 90KB. Inter Variable WOFF2는 같은 라틴 서브셋 기준 약 260KB. 거의 세 배 차이가 납니다. 가변 폰트는 축별 굵기 보간 데이터를 전부 파일 안에 담아야 해서, 파일 자체는 단일 굵기 정적 파일보다 항상 더 무겁습니다.

교차점은 대략 두세 개 굵기입니다. Regular 하나로 돌아가는 구조에서는 가변 파일이 더 무겁고, 네트워크 요청도 어차피 한 번이라 이득이 없습니다. Regular + Bold 두 가지만 써도 정적 두 파일의 합이 가변 파일과 비슷하거나 오히려 가벼운 경우가 있습니다. 세 개 이상의 굵기를 동시에 로드할 때부터 가변 쪽이 전송량과 요청 수 양쪽에서 앞서기 시작합니다.

본문 Regular 하나만, 혹은 제목 Bold를 더해 두 굵기로만 쓰는 구조라면 지금 정적 파일로도 충분합니다. "나중에 굵기를 늘릴 수도 있으니까"라는 이유로 미리 전환하는 건, 실제로 늘리지 않는 한 전송 비용만 미리 지불하는 셈입니다.

인쇄나 PDF가 최종 결과물이라면

가변 폰트는 PDF 언어 사양에서 직접 지원되지 않습니다. PDF 포맷 자체가 굵기 보간 데이터를 처리하는 구조가 아닙니다.

Adobe InDesign 2024에서 가변 폰트 관련 렌더링 오류와 PDF 내보내기 이상이 실제로 보고됐습니다. 글리프가 잘못된 굵기로 표시되거나, 이전 버전 파일을 열면 폰트가 누락으로 인식되는 문제였습니다. Adobe가 임시 해결책으로 안내한 게 "정적 폰트로 전환"이었을 정도입니다. 이후 패치가 나왔지만 일부 문제는 남아 있다는 보고가 이어졌습니다.

전단지·보고서·카탈로그·출판물처럼 인쇄나 PDF 납품이 목적인 작업에서는 굳이 불안 요소를 감수할 필요가 없습니다. 이 환경에서는 정적 폰트가 훨씬 안정적입니다.

원하는 한국어 서체의 가변 버전이 없다면

가변 폰트의 이점은 "원하는 서체의 가변 버전이 실제로 있을 때"만 쓸 수 있습니다.

영문은 Google Fonts에서만 수백 종의 가변 폰트를 고를 수 있는데, 한국어는 상황이 다릅니다. 한국어 완성형 글리프는 최대 11,172자로 영문 기본 라틴보다 수십 배 많습니다. 파일이 근본적으로 무거운 구조인 데다, 가변 버전까지 만들려면 제작 비용과 최적화 작업이 훨씬 늘어납니다. 현실적으로 공개 사용이 가능한 한국어 가변 폰트는 Pretendard Variable, Noto Sans KR 가변 버전, Hahmlet 정도입니다.

원하는 서체 방향에 맞는 가변 버전이 없어서 결국 정적 폰트를 쓰게 된다면, 영문 자원만 가변으로 혼용하는 복잡한 구조를 만들 필요가 없습니다. 쓰려는 폰트의 가변 버전이 실제로 있는지부터 확인하는 게 순서입니다. 폰트비에서 폰트를 검색하면 사용 범위와 라이선스 정보를 한 곳에서 확인할 수 있습니다.

전환을 고려할 때 놓치기 쉬운 CSS 복잡도

위 세 조건을 모두 넘어서 전환을 결정했다면, CSS 관리 비용도 미리 계산에 넣어야 합니다.

가변 폰트를 쓴다는 건 font-variation-settings 속성을 직접 관리한다는 뜻이기도 합니다. 이 속성에는 한 축의 값만 바꾸고 싶어도 나머지 축의 값을 모두 함께 선언해야 하는 특성이 있습니다. 자식 요소에서 굵기(wght)만 바꾸면 자폭(wdth)이 기본값으로 초기화됩니다. MDN 문서도 이 상속 문제를 명시하며 CSS 커스텀 프로퍼티로 우회하도록 권장합니다.

예를 들어 헤딩에만 굵기를 따로 지정하는 구조라면, --font-wght 같은 커스텀 프로퍼티를 루트에 선언하고 모든 요소에서 참조하는 방식으로 풀어야 합니다. 팀 프로젝트라면 이 규칙을 문서화해두지 않으면 나중에 합류한 사람이 한 축만 건드렸다가 다른 축이 초기화되는 걸 보고 버그라고 착각하는 상황이 생깁니다. 실제로 겪어보면 꽤 헷갈리거든요.

반응형 굵기나 자폭 제어를 실제로 쓸 계획이 없다면 이 복잡도는 관리 부담으로만 남습니다. font-size만 반응형으로 바꾸는 수준이라면 정적 폰트로도 충분하고, CSS도 훨씬 단순하게 유지됩니다. 가변 폰트는 특정 요구를 해결하는 기술이지, 최신이라는 이유만으로 채택해야 하는 건 아닙니다. 세 굵기 이상을 동시에 로드하고, 반응형 타이포그래피가 실제로 필요하고, 원하는 서체의 가변 버전도 있어야 한다 — 이 조건이 실제로 겹칠 때 전환을 검토하면 됩니다. 그 전까지는 지금 돌아가는 정적 폰트를 바꿀 이유가 없습니다. 기술 선택은 "더 좋아서"가 아니라 "이 구조에서 실제로 이득이 있어서"여야 하니까요. 폰트 선택도 그 기준에서 예외가 아닙니다.