프로덕션에서의 가변 폰트: 아무도 말해주지 않는 트레이드오프

가변 폰트는 마법 같은 폰트 압축이 아닙니다

가변 폰트는 웹 타이포그래피의 깔끔한 해답처럼 소개되곤 합니다. 하나의 파일, 여러 굵기, 더 적은 요청, 더 부드러운 디자인 시스템. 이 설명은 대체로 맞지만, 완전하지는 않습니다.

프로덕션에서 가변 폰트는 여섯 개의 파일을 하나로 바꾸는 일이라기보다 새로운 타이포그래피 런타임을 도입하는 일에 가깝습니다. 굵기, 너비, 기울기, 광학 크기, 때로는 커스텀 축까지 표현적으로 제어할 수 있습니다. 동시에 파일 크기, 브라우저 렌더링, 폴백 동작, 디자인 거버넌스, 성능 측정에 관한 새로운 결정도 따라옵니다.

결과는 훌륭할 수 있습니다. 하지만 기존 정적 구성보다 나빠질 수도 있습니다.

현재 사이트가 같은 패밀리의 다섯 가지 굵기를 제공한다면, 잘 서브셋한 가변 폰트는 요청 수를 줄이고 CSS를 단순화할 수 있습니다. 반대로 사이트가 regular 한 굵기와 bold 한 굵기만 제공한다면, 가변 폰트는 사용자가 실제로 체감하지 못하는 유연성을 위해 바이트를 늘릴 수 있습니다. 사람들이 자주 건너뛰는 프로덕션 트레이드오프가 바로 이것입니다.

폰트 로딩 전략의 더 넓은 기준선은 웹 폰트가 여전히 대부분의 사이트에서 가장 쉬운 성능 개선인 이유에 관한 가이드가 좋은 동반 자료가 됩니다. 가변 폰트는 기본 원칙을 바꾸지 않습니다. 더 적은 바이트를 전송하고, 렌더링 지연을 줄이며, 폴백 텍스트를 수용 가능한 수준으로 만드는 것입니다.

명확한 장점: 더 적은 파일, 더 표현력 있는 타입

전통적인 정적 폰트 구성은 보통 다음과 같습니다.

• Regular 400
• Italic 400
• Medium 500
• Semibold 600
• Bold 700
• 별도의 display face가 있을 수도 있음

각 파일은 독립적으로 다운로드되고, 캐시되고, 렌더링됩니다. 페이지가 첫 화면에서 여러 굵기를 사용한다면 요청은 빠르게 쌓입니다.

가변 폰트는 이런 굵기 여러 개를 하나의 파일로 합칠 수 있습니다. Inter-Regular.woff2, Inter-Medium.woff2, Inter-Bold.woff2를 로드하는 대신, 하나의 가변 파일을 로드하고 font-weight: 400 700으로 연속 범위를 사용합니다.

이것은 실제 이점을 제공합니다.

• 관리해야 할 폰트 파일 감소
• 굵기 사이의 더 일관된 보간
• 세밀한 반응형 타이포그래피
• 더 쉬운 테마 시스템
• 더 나은 디자인 토큰 정렬

디자인 시스템에서는 이 제어가 특히 유용합니다. 버튼 레이블은 500이나 600 중 하나로 강제되지 않고 580을 사용할 수 있습니다. 좁은 카드 제목은 폰트가 지원한다면 약간 압축된 width 축을 사용할 수 있습니다. display 헤드라인은 가능할 때 optical sizing을 사용할 수 있습니다.

하지만 이런 제어가 존재한다고 해서 모두 사용해야 한다는 뜻은 아닙니다.

첫 번째 숨은 트레이드오프: 하나의 파일이 실제로 필요한 파일들보다 클 수 있습니다

가변 폰트에는 디자인 공간을 위한 보간 데이터가 들어 있습니다. 그 디자인 공간에는 비용이 있습니다. 하나의 가변 폰트 파일이 한두 개의 정적 폰트 파일보다 클 수 있습니다.

여러 파일을 대체한다면 문제가 되지 않습니다. 하지만 절제된 스택을 대체한다면 문제가 됩니다.

두 가지 흔한 경우를 생각해 봅시다.

사례 A: 여러 굵기를 사용하는 마케팅 사이트

사이트가 페이지 전반에서 300, 400, 500, 600, 700과 이탤릭을 사용합니다. 신중하게 서브셋한 가변 폰트는 아마 도움이 될 것입니다. 요청 오버헤드를 줄이고 향후 유지보수를 단순화합니다.

사례 B: regular와 bold만 사용하는 제품 앱

인터페이스가 400과 700을 사용하고, 폴백으로 시스템 폰트를 사용합니다. 가변 폰트는 불필요한 바이트를 추가할 수 있습니다. 유연성은 Figma에서는 좋아 보이지만, 브라우저에서는 항상 유용하지 않습니다.

실수는 “하나의 가변 파일”을 “이론적으로 가능한 많은 정적 파일”과 비교하는 것입니다. 실제 페이지가 현재 사용하는 파일과 비교해야 합니다.

핵심 템플릿에서 실제로 로드되는 폰트 바이트를 측정하세요. 그런 다음 같은 문자 서브셋과 같은 preload 전략으로 가변 버전을 테스트하세요. 가변 버전이 이긴다고 가정하지 마세요.

두 번째 트레이드오프: 서브셋은 덜 중요해지는 것이 아니라 더 중요해집니다

가변 폰트에서는 서브셋의 가치가 더 커집니다. 기본 파일에 글리프, 언어 지원, OpenType 기능, 여러 축, 메타데이터 등 많은 것이 들어 있을 수 있기 때문입니다.

대부분의 프로덕션 사이트는 폰트의 모든 글리프가 필요하지 않습니다. 영어만 제공한다면 pan-European 전체 범위, 키릴 문자, 그리스 문자, 베트남어, 모든 기호 블록이 필요하지 않을 가능성이 큽니다. 여러 언어를 제공하더라도 하나의 범용 파일보다 언어별 서브셋을 원할 수 있습니다.

실용적인 접근은 보통 다음과 같습니다.

1. 대부분의 사용자를 위해 핵심 Latin 서브셋을 유지합니다.
2. 콘텐츠가 필요로 하는 경우에만 확장 서브셋을 추가합니다.
3. unicode-range를 사용해 브라우저가 올바른 파일을 선택하게 합니다.
4. 필요하다면 드문 스크립트에는 정적 폴백을 유지합니다.

이 지점에서 가변 폰트는 다소 까다로워질 수 있습니다. 어떤 폰트 파이프라인은 정적 폰트는 쉽게 서브셋하지만, 가변 축, 힌팅, 메타데이터를 잘못 처리합니다. 사용하려는 축 범위 전체에서 출력 폰트가 여전히 올바르게 동작하는지 항상 확인하세요.

깨진 서브셋은 큰 폰트보다 나쁩니다. 이상한 렌더링, 누락된 글리프, 일관되지 않은 굵기, 특정 locale에서만 나타나는 레이아웃 변화처럼 조용히 실패합니다.

세 번째 트레이드오프: CSS가 지나치게 영리해질 수 있습니다

가변 폰트는 CSS를 통해 축을 노출합니다. weight와 width 같은 표준 축은 font-weight, font-stretch 같은 속성에 깔끔하게 매핑됩니다. 커스텀 축은 종종 font-variation-settings를 사용합니다.

이 힘은 팀을 영리함의 유혹에 빠뜨립니다.

.card-title {
  font-variation-settings: "wght" 623, "wdth" 92;
}

기술적으로는 유효할 수 있지만, 좋은 디자인 시스템 인터페이스인 경우는 드뭅니다. 임의의 축 값이 CSS 곳곳에 퍼지면 검토하기 어렵고, 리팩터링하기 어렵고, 오용하기 쉽습니다.

디자인 토큰이나 이름 붙은 유틸리티를 선호하세요.

:root {
  --font-weight-body: 400;
  --font-weight-heading: 680;
  --font-width-compact: 94;
}

.card-title {
  font-weight: var(--font-weight-heading);
  font-stretch: var(--font-width-compact);
}

가능하면 표준 CSS 속성을 사용하세요. font-variation-settings는 더 높은 수준의 속성이 없는 축에 남겨두세요.

애니메이션에도 주의해야 합니다. 굵기나 너비를 애니메이션하는 것은 소량이라면 세련될 수 있지만, 리플로우, 시각적 불안정성, 저전력 기기에서의 불필요한 작업을 유발할 수도 있습니다. 폰트가 허용한다고 해서 타이포그래피가 모션 놀이터가 되어서는 안 됩니다.

네 번째 트레이드오프: 렌더링 차이는 여전히 존재합니다

가변 폰트에 대한 최신 브라우저 지원은 강력하지만, 렌더링이 어디서나 동일한 것은 아닙니다. 운영체제의 텍스트 래스터라이저, 브라우저 엔진, 안티앨리어싱, 폰트 힌팅이 모두 결과에 영향을 줍니다.

가변 폰트의 500 굵기가 같은 패밀리의 정적 500 파일과 정확히 같아 보이지 않을 수 있습니다. 어떤 패밀리에서는 정적 인스턴스가 수동으로 조정되는 반면, 보간된 가변 인스턴스는 수학적으로 생성됩니다. 작은 크기에서는 이 차이가 중요할 수 있습니다.

이는 본문 텍스트, 내비게이션, 조밀한 표, UI 레이블에서 특히 관련이 큽니다. 인터페이스에 텍스트가 많을수록 hero typography만 볼 것이 아니라 실제 읽기 조건에서 테스트해야 합니다.

가변 폰트로 이동하면서 타입 시스템을 다시 검토하고 있다면, 새로움보다 가독성에서 출발하세요. 현대 웹에서 읽기 쉬운 타입을 위한 실용 가이드는 줄 길이, 크기, 대비, 간격처럼 1,000개의 사용 가능한 폰트 굵기보다 대개 더 중요한 수수한 선택들을 다룹니다.

다섯 번째 트레이드오프: 캐싱은 양날의 검입니다

하나의 가변 폰트 파일은 한 번 캐시되어 여러 페이지에서 재사용될 수 있습니다. 이는 좋습니다.

하지만 파일이 크고 렌더링을 차단한다면, 첫 방문은 전체 비용을 선불로 치릅니다. 정적 폰트는 때로 더 선택적으로 로드할 수 있습니다. 본문 텍스트용 regular를 먼저, bold는 나중에, display는 필요한 페이지에서만 로드하는 식입니다.

보편적인 답은 없습니다. 올바른 구성은 트래픽 패턴에 달려 있습니다.

• 사용자가 한 세션에 여러 페이지를 방문하나요? 공유 가변 파일이 이득일 수 있습니다.
• 사용자가 한 글에 도착해 읽고 떠나나요? 더 작은 정적 파일이 나을 수 있습니다.
• 홈페이지에 굵기 하나만 필요하나요? 미래 페이지를 위해 큰 디자인 공간을 preload하지 마세요.
• 앱이 로그인 뒤에 있고 재방문이 잦나요? 캐시 재사용의 가치가 더 커집니다.

preload에도 절제가 필요합니다. 가능한 모든 폰트가 아니라, 첫 화면 텍스트에 필요한 폰트를 preload하세요. preload는 우선순위 주장입니다. 우선순위 주장이 너무 많으면 소음이 됩니다.

여섯 번째 트레이드오프: Lighthouse가 전체 이야기를 설명해 주지는 않습니다

성능 도구는 사용되지 않은 폰트 바이트, 렌더링 차단 요청, 레이아웃 시프트, 네트워크 비용을 보여줄 수 있습니다. 하지만 시각적 유연성이 페이로드만큼 가치 있는지는 말해주지 못합니다.

가변 폰트 마이그레이션은 여러 신호로 판단해야 합니다.

• 첫 화면에서 전송된 총 폰트 바이트
• 폰트 요청 수
• Largest Contentful Paint 영향
• 폰트 교체로 인한 Cumulative Layout Shift
• 재방문 캐싱 동작
• 승인된 디자인과의 시각적 일치
• 일반적인 크기에서의 가독성

폰트 마이그레이션 후 리포트가 빨갛게 변해도 당황하지 마세요. 문제는 가변 폰트 자체가 아니라 preload 순서, 폴백 메트릭, 서브셋 불일치일 수 있습니다. 당황하지 않고 Lighthouse 리포트를 읽는 법에 관한 가이드가 여기에도 관련됩니다. 실험실 점수를 판결이 아니라 진단 단서로 다루세요.

실용적인 프로덕션 체크리스트

가변 폰트를 배포하기 전에 다음 질문에 답하세요.

1. 어떤 정적 파일을 대체하나요?

디자인 시스템이 이론적으로 지원하는 것이 아니라, 프로덕션에서 실제로 사용되는 파일을 나열하세요. 굵기, 스타일, 문자 집합, 페이지 템플릿을 포함하세요.

2. 어떤 축을 노출할 것인가요?

대부분의 팀은 weight를 노출하고, 어쩌면 width를 노출하며, 그 이상은 드물어야 합니다. 폰트가 잘 지원한다면 optical size가 유용할 수 있지만, 테스트해야 합니다. 커스텀 축에는 명확한 제품 목적이 있어야 합니다.

3. 안전하게 서브셋할 수 있나요?

서브셋 후 시각적 회귀 검사를 실행하세요. 악센트 문자, 구두점, 통화 기호, 포함된 경우 아이콘, 그리고 지원하는 모든 언어를 테스트하세요.

4. 폴백 메트릭이 구성되어 있나요?

적절한 경우 size-adjust, ascent-override, descent-override, line-gap-override 같은 최신 CSS 도구를 사용하세요. 좋은 폴백 메트릭은 폰트 로딩 중 레이아웃 시프트를 줄입니다.

5. font-display가 의도적으로 설정되어 있나요?

font-display: swap은 흔하지만, 항상 완벽하지는 않습니다. 텍스트 가시성을 높이지만 폴백 메트릭이 좋지 않으면 눈에 띄는 교체를 만들 수 있습니다. optional은 중단을 피하는 것이 브랜드 타이포그래피 보장보다 더 중요한 비핵심 폰트에 적합할 수 있습니다.

6. 저사양 기기에서 테스트했나요?

개발자 노트북에서 괜찮게 느껴지는 폰트가 보급형 Android 하드웨어에서는 느리게 렌더링될 수 있습니다. 적어도 하나의 저전력 기기나 throttled profile에서 테스트하세요.

7. 롤백 계획이 있나요?

폰트 변경은 모든 페이지에 영향을 줍니다. 렌더링, 현지화, 성능 문제가 나타날 경우 빠르게 되돌릴 수 있도록 기존 정적 구성을 충분한 기간 동안 유지하세요.

가변 폰트가 좋은 프로덕션 선택인 경우

가변 폰트는 보통 다음과 같은 경우 고려할 만합니다.

• 같은 패밀리에서 세 가지 이상의 굵기를 사용합니다.
• 여러 템플릿에 걸친 디자인 시스템을 유지합니다.
• width 또는 optical-size 제어가 있는 반응형 타이포그래피가 필요합니다.
• 사용자가 한 세션에 여러 페이지를 탐색하는 일이 흔합니다.
• 폰트 파이프라인을 제대로 서브셋하고 테스트할 수 있습니다.

다음과 같은 경우에는 설득력이 떨어집니다.

• regular와 bold만 필요합니다.
• 가변 파일이 현재 구성보다 훨씬 큽니다.
• 폰트가 텍스트 크기에서 보간 품질이 좋지 않습니다.
• 팀이 CSS 곳곳에 임의의 축 값을 흩뿌릴 것입니다.
• 현지화와 폴백 동작을 테스트할 수 없습니다.

냉정하게 보면 이렇습니다. 가변 폰트는 기본적으로 최적화가 아니라 역량입니다. 이미 폰트를 신중하게 관리하는 팀에게 보상합니다. 타이포그래피를 장식으로, 폰트 로딩을 사후 고려 사항으로 대하는 팀에는 벌을 줍니다.

<!-- tool-cta:start -->

💡 이것을 시도해 보세요: 프로덕션용 가변 글꼴을 서브셋화하고 패키징할 때 Webfont Generator는 일치하는 CSS가 포함된 WOFF2 출력을 생성합니다.

<!-- tool-cta:end -->

프로덕션 경험칙

복잡성을 줄이거나 명확한 디자인 결과를 가능하게 할 때 가변 폰트를 사용하세요. “하나의 파일”이 더 깔끔하게 들린다는 이유로 사용하지 마세요.

가장 좋은 프로덕션 구현은 대체로 지루합니다. 신중하게 서브셋한 하나의 가변 폰트, 승인된 소수의 축 값, 합리적인 폴백, 절제된 preload, 실제 기기 테스트. 이는 무한한 타이포그래피 가능성만큼 흥미롭지는 않습니다. 하지만 사이트를 더 좋게 만들 가능성은 훨씬 큽니다.