출처 : jonoalderson.com - You’re loading fonts wrong (and it’s crippling your performance) (2025.08.21)

✼✼ disclaimer ✼✼ 본 글은 AI 번역 후 직접 검수하여 작성했습니다. 효율적인 정보 전달을 위해 AI 번역을 활용하되, 부자연스러운 표현은 수정했습니다. 번역 오류가 있을 수 있으니 정확한 내용은 원문을 확인하시기 바랍니다.

폰트는 웹에서 가장 눈에 잘 띄면서도 강력한 요소입니다. 브랜드를 전달하고, 정체성을 형성하며, 모든 단어가 어떻게 느껴지는지 결정하죠. 디자인과 콘텐츠, 경험을 이어주는 연결고리입니다.

하지만 문제가 있습니다. 거의 모든 사람이 폰트를 잘못 다루고 있다는 겁니다.

참 이상한 역설입니다. 폰트는 어디에나 있습니다. 모든 웹사이트가 사용하죠. 하지만 디자이너, 개발자, 심지어 성능 최적화 담당자(performance specialist)조차도 폰트 작동법이나 효율적으로 로딩하는 방법을 제대로 아는 사람은 거의 없습니다. 그 결과 웹은 비대한 폰트 파일, 엉성한 로딩 전략, 형편없는 접근성, 엄청난 대역폭 낭비로 가득합니다.

폰트는 장식이 아닙니다. 인프라입니다. 중요 렌더링 경로에 자리 잡고 있고, LCP나 CLS 같은 성능 지표에 영향을 미치며, 라이선스와 프라이버시 문제를 안고 있습니다. 사용자가 페이지의 내용을 읽고, 참여하고, 신뢰할 수 있는지에 직접적인 영향을 줍니다. 코드를 다루듯 신중하고 체계적으로 폰트를 다루지 않으면, 사용자와 비즈니스에 해를 끼치는 겁니다.

이 글은 그 문제를 깊이 파고듭니다. 웹 표준 폰트의 역사와 구글 폰트의 등장부터, 지금도 지배적인 잘못된 통념과 나쁜 습관까지 살펴봅니다. 브라우저에서 폰트가 실제로 어떻게 작동하는지, 온라인에서 흔히 보는 기본값과 "모범 사례"가 왜 전혀 모범적이지 않은지 다룹니다.

성능의 기본 원리, 로딩 전략, 최신 CSS 기법, 그리고 여러 문자 체계와 언어로 텍스트를 제공하는 실제 글로벌 환경을 살펴볼 겁니다. 폰트 사용의 법적·윤리적 측면과 웹 타이포그래피의 미래가 어떤 모습일지도 깊이 파고들 겁니다.

글을 다 읽고 나면, 지금 쓰고 있는 폰트 설정이 왜 잘못됐는지, 어떻게 고쳐야 하는지 알게 될 겁니다.

핵심만 기억하세요: 폰트는 공짜가 아니고, 단순하지 않으며, 선택 사항도 아닙니다. 성능, 접근성, SEO에 쏟는 것과 같은 엄격함을 폰트에도 적용해야 합니다.

웹폰트의 간략한 역사

왜 이렇게 많은 사람이 여전히 폰트를 잘못 다루는지 이해하려면, 그 역사를 좀 알아야 합니다. 오늘날 웹 타이포그래피를 바라보는 방식은 여전히 지난 20년간의 타협, 편법, 그리고 불완전한 진실에 의해 형성되어 있습니다.

"웹 표준" 시대

웹 초기에는 원하는 폰트를 마음대로 쓸 수 없었습니다. 몇 가지 "웹 표준" 시스템 폰트(Arial, Times New Roman, Verdana, Georgia) 중에서 골라서, 사용자 기기에서도 똑같이 보이길 바라는 수밖에 없었죠. 다른 걸 원하면 이미지로 잘라내야 했습니다.

@font-face 이전의 편법: sIFR과 Cufón

디자이너들은 브랜드 폰트를 원했지만, 브라우저는 준비가 안 됐습니다. 그래서 이런 꼼수들이 등장했죠:

sIFR (Scalable Inman Flash Replacement): 플래시로 텍스트를 렌더링해서 런타임에 실제 HTML 위에 교체하는 방식이었습니다. 어느 정도 작동은 했지만, 무겁고, 불안정했으며, 접근성이 형편없었습니다.
Cufón: 폰트를 벡터 그래픽으로 변환해서 페이지에 삽입하는 JavaScript 기법이었습니다. Flash는 필요 없었지만, 여전히 느리고 접근성이 떨어졌습니다.

웹 표준 폰트의 한계를 깨보려는 절실한 시도였지만, 이게 오히려 "원하는 폰트를 쓰려면 언제나 불안정하고, 무겁고, 꼼수를 써야 한다"는 생각을 만들어버렸습니다.

@font-face의 등장

그러다 @font-face가 등장했습니다. 이론적으로는 원하는 서체를 CSS에 바로 삽입해서 제공할 수 있었습니다. 실제로는 난장판이었죠:

브라우저마다 다른, 때로는 독점적인 포맷이 필요했습니다: IE는 EOT(Embedded OpenType), 초기 iOS Safari는 SVG 폰트, 그 외엔 TTF/OTF.
개발자들은 "만능(bulletproof)" @font-face 스택을 만들었습니다. 모든 브라우저를 지원하기 위해 네 가지 파일 형식을 가리키는 장황한 CSS 규칙이었죠.
라이선싱이 악몽이었습니다. 많은 폰트 제작사가 웹 사용을 금지하거나 도메인/페이지뷰당 로열티를 부과했습니다.
불법 복제가 만연했고, 데스크톱 폰트를 훔쳐서 "웹폰트"로 온라인에 풀어놓는 일이 흔했죠.

상업 서비스: Typekit과 그 동료들

이런 혼란을 보고 상업 서비스들이 등장했습니다. Typekit(2009년 출시, 지금은 Adobe Fonts인데 여전히 형편없습니다)은 구독 방식으로 합법적인 라이선스에 제대로 포맷된 웹폰트를 간단한 임베드 스크립트와 함께 제공했습니다. 다른 폰트 제작사들도 자체 호스팅 서비스를 만들었죠.

Typekit은 많은 팀의 라이선싱과 호환성 골칫거리를 해결했지만, 동시에 폰트는 외부 자바스크립트 코드 조각(third-party JavaScript snippet)을 통해 로드되어야 한다는 생각을 굳혔습니다. 오늘날에도 수백만 사이트에 남아있는 패턴입니다.

호환성 편법과 우회책

@font-face와 Typekit 같은 서비스가 있어도, 웹폰트 시대는 온갖 우회책으로 가득했습니다:

같은 폰트의 여러 포맷을 호스팅해서 페이로드를 부풀림
혹시 몰라서 전체 유니코드 범위를 번들로 제공
FOUT(스타일 안 먹은 텍스트 깜빡임) vs FOIT(텍스트 자체가 안 보이는 깜빡임)를 해결하려고 애쓰다가, 종종 보기 흉한 자바스크립트 "땜질"로 마무리
빠진 glyphs와 UI 심볼을 커버하려고 아이콘 폰트에 의존

개발자 세대 전체가 폰트를 불안정하고, 비대하고, 변덕스러운 것으로 배웠습니다. 오늘날의 나쁜 관행에도 여전히 울려 퍼지는 교훈입니다.

구글 폰트와 "무료 폰트" 붐

2010년, 구글 폰트가 등장했습니다. 갑자기 오픈 라이선스 폰트가 계속 늘어나는 무료 CDN이 등장했습니다. 개발자들은 열렬히 환영했고, 디자이너들은 그럭저럭 받아들였고, 성능 담당자들은 불평하면서도 어쩔 수 없이 따라갔죠.

많은 문제를 해결했지만(라이선싱, 포맷, 호스팅, CSS 처리 포함) 새로운 문제도 만들었습니다. 모두가 기본 선택지로 삼았고, 쓰지 말아야 할 때조차 그랬습니다. 매 페이지뷰마다 외부 CDN에서 폰트를 불러오기 시작했고, 종종 느렸으며, 심지어 불법인 경우도 있었습니다. 실제로 유럽 법원이 나중에 그렇게 판결했죠.

여담: 라이선스 현실

라이선싱은 많은 폰트 사용 방식에서 간과되는 위험 요소입니다. 모든 "웹폰트 라이선스"가 이 글에서 추천하는 방법을 허용하는 건 아닙니다. 어떤 폰트 제작사는:

서브셋팅(일부만 추출)이나 WOFF2 변환을 금지합니다
페이지뷰나 월간 활성 사용자(monthly active users) 기준으로 요금을 부과합니다
특정 도메인에만 임베딩을 허용합니다

그래서 구글 폰트가 해방감을 준 겁니다. 법률 문제가 없었으니까요. 하지만 상업용 폰트는 종종 폰트를 철저히 최적화하면 법적으로 위험하게 만드는 조건을 달고 옵니다. 브랜드 폰트에 돈을 내고 있다면, 잘라내고 최적화하기 전에 계약서를 읽어보세요. 아니면 협상하세요. 어떤 폰트 회사는 페이지뷰 수나 월 사용자 수로 요금을 매기기 때문에, 적절한 라이선스 없이 폰트를 적극적으로 최적화하면 계약 위반이 될 수 있습니다.

남아있는 미신들

이런 시대를 거치며 지금까지 살아남은 미신과 나쁜 습관들이 있습니다:

커스텀 폰트는 "무료"이고 쉽다
모든 사용자, 모든 언어에 하나의 큰 폰트 파일을 보내도 된다
구글 폰트(또는 Typekit)가 항상 최선의 선택이다
폰트(타이포그래피)는 디자인적 장식이지, 성능이나 접근성 문제가 아니다

이런 생각들은 2005년이나 2010년엔 합리적이었습니다. 지금은 아니죠. 그런데도 여전히 대부분의 웹사이트가 폰트를 로드하는 방식은 이 낡은 가정에 묶여있습니다. 그게 웹 타이포그래피가 이토록 엉망인 이유입니다.

폰트 작동 원리 (기초)

잘못된 방법들을 비판하기 전에, 우선 기본적인 이해가 필요합니다. 폰트는 겉보기엔 간단히, 그냥 CSS 몇 줄로 보입니다. 하지만 내부를 들여다보면 렌더링 파이프라인의 놀랍도록 복잡한 요소입니다. 이 파이프라인을 이해하면 폰트가 왜 이렇게 자주 꼬이는지 알 수 있습니다.

포맷: TTF부터 WOFF2까지

본질적으로 폰트는 글리프(glyph - 모양), 테이블(명령어, 메트릭, 메타데이터), 때로는 부가요소(ligature - 합자, 대체 형태, 이모지 팔레트)의 컨테이너입니다. 다음 포맷 중 하나로 제공됩니다:

TTF/OTF (TrueType/OpenType): 데스크톱 지향 포맷, 무겁고 웹 전송에 최적화되지 않음
EOT: IE의 독점 포맷, 다행히 사멸
SVG 폰트: 초기 iOS Safari용 편법, 거의 사멸
WOFF: 웹용으로 TTF/OTF를 압축한 래퍼(wrapper)
WOFF2: 현대의 기본값. 더 작고, 더 빠르며, Brotli 압축 기반

오늘날 WOFF2가 아닌 걸 쓰고 있다면, 잘못하고 있는 겁니다. 거의 모든 프로젝트에 WOFF2면 됩니다. 특수한 경우(폐쇄 기업망의 IE11 같은)가 아니라면, 구식 포맷을 제공하는 건 모든 방문자에게 성능 세금을 매기는 꼴입니다. 정말 어쩔 수 없이 레거시 브라우저를 지원해야 한다면, WOFF를 조건부로만 추가하세요. 전체 방문자에게 보내지 말고요.

렌더링 파이프라인

브라우저가 "폰트를 로드"할 때, CSS에서 픽셀로 바로 가는 게 아닙니다. 여러 단계를 거치고 (그리고 CSS 선택에 따라) 텍스트가 어떻게 표시될지 결정됩니다:

등록: 브라우저가 CSS를 파싱하면서 각 @font-face 규칙을 폰트 세트에 등록합니다. 쉽게 말해 패밀리, 굵기, 스타일, 늘이기, unicode-range 목록이죠. 이 단계에선 아직 파일을 다운로드하지 않습니다.
스타일 해결: 캐스케이드(cascade)가 실행됩니다. 각 요소는 계산된 font-family, font-weight, font-style, font-stretch를 값을 갖게 되고, 브라우저는 이걸 등록된 폰트 세트와 비교해서 뭘 쓸 수 있는지 찾아봅니다.
폰트 매칭: 폰트 매칭 알고리즘이 사용 가능한 가장 가까운 페이스(face - 굵기/스타일)를 찾습니다. 요청한 굵기나 스타일이 없으면, 브라우저가 직접 만들거나(가짜 볼드/이탤릭) 일반 serif/sans/monospace로 대체(폴백)합니다.
글리프 커버리지(glyph coverage): 텍스트가 실제로 그 폰트의 글리프(글자 모양)를 필요로 할 때만 다운로드 대기열에 들어갑니다. unicode-range가 페이지의 문자를 포함하지 않으면 폰트가 아예 로드되지 않을 수도 있습니다.
요청: 필요해지면 폰트 요청이 대기열에 들어갑니다. @font-face 규칙이 늦게 로드되는 스타일시트에 묻혀있으면 렌더 사이클에서 의외로 늦게 일어날 수 있습니다. 프리로드(preload)하거나 인라인으로 넣어서 지연을 막으세요.
디스플레이 단계: 폰트가 도착하길 기다리는 동안, 브라우저가 텍스트를 어떻게 처리할지 결정합니다. 이게 font-display가 중요한 지점입니다:
- 명시적 설정 없음(오래된 기본값): 역사적으로 일관성이 없었습니다. Safari는 종종 폰트가 도착할 때까지 텍스트를 완전히 숨겼고(FOIT), Chrome은 대체(폴백) 텍스트를 바로 보여줬습니다(FOUT). 이런 불일치가 수년간의 나쁜 편법을 부추겼습니다.
- font-display: swap; 폴백 텍스트를 즉시 렌더링하고, 웹폰트가 준비되면 교체(FOUT)
- font-display: block; 최대 ~3초간 텍스트 숨김(FOIT), 아직 준비 안 됐으면 폴백 표시
- font-display: fallback; 매우 짧은 블록(~100ms), 그 다음 폴백 표시
- font-display: optional; 폴백을 즉시 표시하고 조건이 나쁘면 절대 교체 안 할 수도 있음
해독(decoding)과 처리(shaping): 다운로드되면 폰트는 압축 해제되고, 파싱되고, 셰이핑됩니다. 셰이핑 과정에서는 OpenType 기능을 적용하고, 합자를 처리하며, 문맥에 맞는 형태를 선택합니다. 그런 다음에야 글리프를 래스터화(rasterise)하고 그릴 수 있습니다. 저사양 기기에서는 이 셰이핑 단계가 체감 가능한 지연을 일으킬 수 있습니다.

이 모든 게 화면에 단 하나의 글리프가 표시되기 전에 내부에서 일어납니다. 개발자는 셰이핑 엔진이 작동하는 방식을 바꿀 수 없습니다. 하지만 그 이후에 일어나는 일엔 영향을 줄 수 있습니다. 퍼즐의 다음 조각은 메트릭입니다: 텍스트가 얼마나 높고 넓게 보이는지, 간격은 어떤지, 그리고 폰트가 교체될 때 이 치수들이 흔들리지 않게 막는 방법입니다.

메트릭(Metrics)

폰트는 글리프 모양만 정의하는 게 아닙니다. 메트릭도 정의합니다:

Ascent, descent, line gap – 줄이 얼마나 높은지, 베이스라인이 어디 있는지
x-height – 소문자가 얼마나 크게 보이는지
커닝(kerning)과 합자(ligatures) – 문자들이 어떻게 맞춰지는지

대체 시스템 폰트의 메트릭이 다르면, FOUT 중에 페이지가 한 방식으로 렌더링됐다가 커스텀 폰트가 로드될 때 "점프"합니다. 이건 단순히 보기 흉한 게 아닙니다. 수치로 잡힐 만큼의 레이아웃 시프트(layout shift)이고, 웹사이트의 성능 지표(Core Web Vitals)를 망가뜨릴 수 있습니다.

이 값들을 어떻게 조정하는지는 글 뒷부분에서 다루겠습니다.

합성 스타일

브라우저는 요청한 정확한 굵기나 스타일을 못 찾았다고 포기하지 않습니다. 대신 만들어냅니다:

가짜 볼딩: font-weight: 600을 요청했는데 400(regular)만 있으면, 대부분 브라우저가 알고리즘적으로 획을 두껍게 합니다. 결과는 종종 투박하고, 일관성 없으며, 브랜드 폰트를 망칠 수 있습니다.
가짜 이탤릭: 진짜 이탤릭 페이스 없이 font-style: italic을 요청하면, 브라우저가 단순히 일반 글리프를 기울입니다. 허접한 속임수고, 서체 측면에서 최악입니다.

이런 "배려"가 서체를 엉성해 보이게 만들 수 있고, 간격과 크기를 미묘하게 어긋나게 할 수 있습니다. 해결 방법:

실제로 제공하는 굵기/스타일만 선언하세요
font-synthesis: none;을 써서 브라우저가 볼드/이탤릭을 위조하지 못하게 하세요
실제로 필요한 굵기만 서브셋해서 제공하세요. 진짜 사용할 것들만요.

더 있습니다: 폰트를 받아왔다고 바로 쓸 수 있는 게 아닙니다. 브라우저가 해독(decoding)하고, 처리(shaping)하고, 픽셀로 만들어(rasterise)야 합니다. OpenType 데이터를 분석하고, 규칙을 적용하고(HarfBuzz, CoreText, DirectWrite), 글자를 화면 픽셀로 바꿔야 하죠. 저사양 기기에선 이 과정이 눈에 띄게 시간을 잡아먹을 수 있습니다. 폰트 선택은 파일 크기만의 문제가 아닙니다. 화면에 그릴 때 CPU를 얼마나 쓰는지도 중요합니다.

글리프 커버리지

마지막으로, 폰트는 보편적이지 않습니다. 라틴 폰트엔 악센트 문자, 키릴 글리프, 아랍 합자, 이모지가 없을 수 있습니다. 글리프가 누락되면 브라우저가 조용히 다른 폰트로 바꿔서 그 부분을 채웁니다. 그러면 렌더링이 들쭉날쭉하거나, 크기가 맞지 않거나, 심지어 네모 박스나 물음표가 나타날 수 있습니다.

이게 서브셋팅(일부만 추출)이 중요한 이유이고, 대체(폴백) 스택이 중요한 이유이며, 커버리지(적용 범위) 이해가 필수적인 이유입니다.

결론: 폰트는 "파일만 받으면 알아서 되는 것"이 아닙니다. 복잡하고, 무겁고, 브라우저가 텍스트를 렌더링하는 방식의 핵심입니다. 그래서 폰트를 인프라가 아닌 장식으로 다루는 게 그토록 잘못된 접근인 겁니다.

성능 & 전략 기본

폰트의 복잡성은 역사적 배경으로 이해할 수 있지만, 폰트가 중요한 진짜 이유는 성능에 있습니다. 폰트는 디자인 요소를 넘어 렌더링 과정의 핵심이며, 웹사이트의 성능 지표(Core Web Vitals)를 좌우합니다.

파일 크기

대부분의 웹사이트가 불필요하게 많은 폰트 데이터를 불러옵니다. 하나의 폰트 패밀리만 해도 스타일당 400-800KB에 달합니다. 볼드, 이탤릭, 여러 굵기를 포함하면 콘텐츠가 표시되기도 전에 수 메가바이트의 폰트를 다운로드하게 됩니다. 많은 사이트의 자바스크립트 용량보다 큽니다.

문제는 이 중 대부분의 글자와 굵기가 실제로는 쓰이지 않는다는 점입니다.

레이아웃 시프트(layout shift)

폰트는 렌더링을 차단할 뿐 아니라 로드 시 레이아웃을 재조정(reflow)하게 만듭니다.

대체 폰트의 메트릭(x-height, ascent, descent, line-gap)이 다르면, 웹폰트가 로드될 때 콘텐츠가 흔들립니다.
이는 누적 레이아웃 이동(CLS)으로 측정되며, 웹사이트의 성능 지표에 직접적인 영향을 줍니다.

좋은 소식은 최신 CSS로 이 모든 문제를 해결할 수 있다는 점입니다.

최신 CSS 디스크립터(폰트 속성)와 실제 작동 방식

font-display : 폰트가 로딩되는 동안 뭐가 일어날지 제어합니다.

swap: 대체 폰트를 먼저 보여주고 웹폰트가 로드되면 교체합니다 (FOUT). 권장되는 기본 설정입니다.
fallback: 짧게 차단(~100ms) 후 대체 폰트 표시, 이후 교체. 느린 네트워크에 안전합니다.
optional: 대체 폰트 표시, 교체 안 될 수도 있음. 장식 폰트에 좋습니다.
block: 텍스트를 일정 시간(≈3초) 숨김. 빠른 환경에선 깔끔하지만 느린 환경에선 최악입니다. 피하세요.

👉 이것이 첫 페인트 정책(first-paint policy)입니다. 신중히 선택하세요.

메트릭 조정 속성(metrics override descriptors) : 대체 폰트와 웹폰트의 크기 정보를 맞춥니다.

@font-face 안에 작성하며, 브라우저에게 "웹폰트를 조정해서 먼저 표시한 대체 폰트처럼 보이게 하라"고 지시합니다. 그러면 폰트 교체 시 레이아웃이 흔들리지 않습니다.

size-adjust: 웹폰트를 확대/축소해서 글자 높이(x-height)를 대체 폰트와 맞춥니다.
ascent-override / descent-override: 글자의 위아래 정렬 위치(baseline과 descender)를 조정합니다.
line-gap-override: 줄 사이 간격을 조절해 문단이 흔들리지 않게 합니다.

예시:

@font-face {
  font-family: 'Brand';
  src: url('/fonts/brand.woff2') format('woff2');
  font-display: swap;           /* 첫 페인트 정책 */
  size-adjust: 102%;            /* 폴백 x-height 매치 */
  ascent-override: 92%;         /* 베이스라인 정렬 */
  descent-override: 8%;         /* 디센더 균형 */
  line-gap-override: normal;    /* 줄 높이 안정화 */
}

실무에서는 Font Style Matcher 같은 도구로 적절한 값을 계산할 수 있습니다. 대체 폰트와 커스텀 폰트의 메트릭을 정확히 맞춰 CLS를 없앨 수 있습니다.

unicode-range : 페이지가 실제로 필요한 글리프만 제공합니다.

각 서브셋(Latin, Latin-Extended, Cyrillic 등)에 별도의 @font-face 블록을 선언합니다. 브라우저는 필요한 것만 요청합니다.

예시 :

@font-face {
  font-family: "Brand";
  src: url("/fonts/brand-latin.woff2") format("woff2");
  unicode-range: U+0000-00FF, U+0131, U+0152-0153;
  font-display: swap;
}

👉 절대 사용하지 않을 스크립트용 글리프를 안 보내서 수백 킬로바이트를 절약합니다.

font-size-adjust : 요소를 위한 속성입니다 (@font-face용 아님).

대체 폰트 크기를 조정해 글자 높이(x-height)를 원래 폰트와 맞춥니다. 대체 폰트가 너무 작거나 크게 보이는 걸 막습니다.

예시 :

html { font-size-adjust: 0.5; } /* 브랜드 폰트에 맞춘 비율 */

디스크립터에서 전략으로

이 CSS 디스크립터(폰트 속성)들은 정밀한 수술 도구입니다. CLS와 불필요한 용량을 제거합니다. 하지만 폰트 성능 최적화는 메트릭 조정만으로는 부족합니다. 처음부터 폰트를 어떻게 전달하고, 적용 범위를 정하고, 우선순위를 설정할지 전략적으로 결정해야 합니다.

언어 지원 범위(language coverage)와 글자 선별(subsetting)

중요하지만 자주 놓치는 최적화 방법이 언어 지원 범위 설정과 서브세팅(subsetting)입니다.

대부분의 사이트는 Latin이나 Latin Extended만 필요한데, 많은 곳이 절대 사용하지 않을 Cyrillic, Greek, Arabic, 또는 전체 CJK 세트를 포함한 폰트를 보냅니다. 모든 방문자에게 수백 킬로바이트, 때로는 메가바이트를 낭비하는 셈입니다.

더 똑똑한 전략:

fonttools, Glyphhanger, Subfont 같은 도구로 폰트를 서브셋하세요
스크립트별 서브셋을 선언하는데 unicode-range를 쓰세요
다국어 사이트라면 언어별(locale-specific) 번들을 만드세요 (예: fonts-en.css, fonts-ar.css)

그러면 브라우저는 필요한 경우에만 서브셋을 다운로드합니다. Cyrillic 사용자는 Cyrillic을 받고, Latin 사용자는 Latin을 받으며, 둘 다 받는 사람은 없습니다.

서브셋하지 말아야 할 때

⚠️ 비라틴 문자를 포함한 진정한 다국어 사이트의 경우, 글리프 제거가 오히려 해로울 수 있습니다. 아랍어, 히브리어, 태국어, 인도 계열 문자는 셰이핑(글자 형태 처리)과 포지셔닝 테이블(GSUB/GPOS)에 의존합니다. 이 부분은 나중에 다루겠습니다.

⚠️ 사용자 생성 콘텐츠(user-generated content)가 많은 사이트라면 신중해야 합니다. 사용자들은 예상치 못한 그리스 문자, 키릴 문자, 이모지를 사용할 겁니다. 이런 경우엔 과도하게 줄이기보다 넓은 커버리지나 안정적인 시스템 대체 폰트를 활용하세요.

중요하지 않은 폰트 지연 로딩(lazy loading)

모든 폰트가 중요 렌더링 경로의 일부일 필요는 없습니다. 헤드라인 디스플레이 폰트, 장식용 서체, 아이콘 세트(예: footer에만 나타나는 소셜 미디어 아이콘용)는 종종 첫 페인트에 필수적이지 않습니다. 이것들은 핵심 콘텐츠가 보인 후 나중에 지연되거나 단계적으로 들어올 수 있습니다.

신뢰할 수 있는 두 가지 접근법:

Font Loading API(document.fonts.load)를 사용해서 페이지가 안정된 후 요청하고 적용하세요
또는 font-display: optional을 설정하세요. 브라우저에게 대체 폰트로 충분하다고 알려줍니다. 커스텀 폰트가 늦게 로드되거나 아예 안 와도 페이지는 정상 작동합니다.

핵심 성능에 집중하는 방식입니다. 콘텐츠 우선, 디자인은 부차적입니다.

점진적 개선 요소(progressive enhancement)로서의 폰트

결국 폰트는 점진적 개선 요소로 다뤄야 합니다. 사이트는 빠르게 뜨고, 읽기 쉽게 표시되며, 웹폰트가 없어도 사용 가능해야 합니다. 잘 선택한 시스템 기본 폰트로 콘텐츠를 먼저 보여주고, 웹폰트는 로드되면 세련미와 브랜드 정체성을 더하는 역할입니다.

폰트는 중요하지만, 읽기·속도·안정성보다 우선일 수는 없습니다.

가변 폰트(variable fonts): 이상 vs 현실

서브세팅과 스마트 로딩이 실용적 해법이라면, 가변 폰트는 혁신적인 대안입니다. 파일 하나로 무한한 표현이 가능합니다. 레귤러·볼드·이탤릭·콘덴스드·와이드를 위해 수십 개 파일을 보내는 대신, 이 축들을 자유롭게 조정 가능한 가변 폰트 하나만 보내면 됩니다.

이론상으로는 다운로드 용량이 줄고, 디자인 제어는 정교해지며, 반응형이고 유연한 타이포그래피 시스템을 구축할 수 있습니다.

이상

통합: 수십 개의 정적 파일을 하나의 리소스로 합칩니다.
정밀도: 400/500/600 단계 대신 정확한 굵기(512, 537...)를 사용합니다.
반응성: 브레이크포인트마다 자연스럽게 조절되는 너비와 광학 크기 축을 활용할 수 있습니다.
일관성: 관리할 요소가 줄고, CSS가 깔끔해지며, 용량도 줄어들 수 있습니다.

현실

가변 폰트는 훌륭합니다. 하지만 만능 해결책은 아닙니다.

파일 크기 증가: 두 가지 굵기만 필요하다면, 가변 폰트가 잘 최적화된 정적 폰트 두 개보다 오히려 클 수 있습니다.
브라우저 지원 편차: 굵기 조절은 모든 브라우저가 지원하지만, 광학 크기·이탤릭·등급 같은 일부 축은 브라우저마다 지원이 불완전합니다.
이중 로딩 함정: 많은 팀이 "혹시 몰라서" 가변 폰트와 정적 파일을 함께 보내는데, 이건 장점을 상쇄시킵니다.
라이선스 문제: 일부 폰트 회사는 가변 폰트를 따로 팔거나, 용량 줄이는 작업을 금지합니다.
지원 편차: 굵기·너비·기울기·광학 크기 같은 핵심 축은 보편적으로 지원됩니다. 하지만 등급 같은 커스텀 축은 여전히 font-variation-settings가 필요하고 CSS 단축 속성이 없을 수 있습니다. 모든 축이 브라우저에서 편리하게 작동한다고 가정하지 마세요.

성능 전략

가변 폰트도 다른 자산처럼 다루세요. 검토하고, 측정하고, 서브셋하세요.

축을 신중히 고르세요: 너비, 광학 크기, 이탤릭이 정말 필요한가요?
정적 폰트처럼 문자 체계별로 서브셋하세요. 전체를 다 넣지 마세요.
용량을 비교하세요. 가변 폰트 하나가 정적 폰트 2-3개보다 실제로 가벼운지 확인하세요.

디자인 전략

의도적으로 사용하면, 가변 폰트는 정적 세트로는 얻을 수 없는 디자인 자유도를 줍니다.

반응형 타이포그래피: 뷰포트(화면) 변화에 따라 굵기나 너비를 미세하게 조절합니다.
광학 크기 조정: 작은 크기와 큰 크기에서 가독성을 위해 글자 형태를 자동 조정합니다.
브랜드 표현: 정적 폰트 세트보다 더 풍부한 개성을 위해 스타일을 자유롭게 조절합니다.

하지만 조심하세요. font-variation-settings로 애니메이션을 만들면 데모에선 멋지지만, 실제론 자주 끊깁니다.

예시: CSS에서 가변 폰트 축 사용하기

/* 가변 폰트 로드 */
@font-face {
  font-family: "Acme Variable";
  src: url("/fonts/acme-variable.woff2") format("woff2-variations");
  font-weight: 100 900;        /* 지원되는 굵기 범위 선언 */
  font-stretch: 75% 125%;      /* 지원되는 너비 범위 선언 */
  font-style: normal italic;   /* 직립과 기울어짐 선언 */
  font-display: swap;
}

/* 굵기와 너비를 일반적으로 사용 */
h1 {
  font-family: "Acme Variable", system-ui, sans-serif;
  font-weight: 700;    /* 선언된 100-900 범위 내에서 해결 */
  font-stretch: 110%;  /* 약간 더 넓게 */
}

/* font-variation-settings를 통한 비표준 축 */
.hero-text {
  font-family: "Acme Variable", system-ui, sans-serif;
  font-variation-settings: "wght" 500, "wdth" 120, "slnt" -5;
}

/* 반응형 유동 타이포그래피: 뷰포트 크기에 따라 굵기 조정 */
h2 {
  font-family: "Acme Variable", system-ui, sans-serif;
  font-weight: clamp(400, 2vw + 300, 700);
}

👉 표준 CSS 속성(font-weight, font-stretch, font-style)을 쓰는 방식과 세밀한 제어를 위한 font-variation-settings 방식을 모두 보여줍니다.

모범 사례

필요한 것부터 점검하세요: 실제로 어떤 굵기, 스타일, 스크립트를 사용하나요?
가변 폰트가 크기와 커버리지에서 유리하다면, 서브세팅과 unicode-range로 배포하세요.
정적 폰트 2-3개가 더 가볍고 간단하다면, 그쪽을 사용하세요.

가변 폰트는 하나의 도구일 뿐, 무조건 써야 하는 건 아닙니다. 중요한 건 신중하게 판단하는 겁니다. 장단점을 따져보고, 성능 예산의 다른 부분을 다루듯 동일한 원칙으로 구현하세요.

시스템 스택과 CDN

모든 프로젝트가 커스텀 폰트를 필요로 하는 건 아닙니다. 사실, 가장 강력한 성능 향상 중 하나는 단순히 폰트를 전혀 로드하지 않는 겁니다.

시스템 폰트 스택

시스템 폰트는 OS에 기본 탑재되어 있어 무료이고, 즉시 표시되며, 익숙합니다. 핵심은 플랫폼마다 자연스럽게 어울리는 시스템 폰트 스택을 구성하는 것입니다. 일반적인 현대 스택은 다음과 같습니다:

body {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
               Helvetica, Arial, sans-serif, "Apple Color Emoji",
               "Segoe UI Emoji", "Segoe UI Symbol";
}

macOS, iOS, Windows, Android, Linux 순으로 적용(cascade)되고, 웹 표준 산세리프(san-serif)로 깔끔하게 대체됩니다. 본문, 내비게이션, 실용적 UI 요소에는 시스템 스택만 한 게 없습니다.

또한 훌륭한 대체 폰트이기도 합니다. 커스텀 폰트를 로드하더라도 시스템 스택 기반으로 먼저 디자인하면 가독성과 안정성이 보장됩니다.

시스템 폰트가 이모지를 거의 항상 더 잘 처리한다는 점도 주목할 만합니다. 웹폰트에 이모지를 넣는 것보다 가볍고, 종류도 많으며, 표시도 일관적입니다. 이모지는 나중에 더 자세히 설명하겠습니다.

CDN과 서드파티 호스팅

수년간 Google Fonts가 기본 해법이었습니다. <head>에 <link> 하나만 붙이면 끝이었죠. 하지만 지금은 좋지 않은 선택입니다.

프라이버시: 구글 폰트에서 폰트를 로드하면 방문자 데이터가 구글로 유출됩니다. 규제당국(특히 유럽)이 이를 GDPR 위반으로 판단했습니다.
성능: 외부 CDN은 속도를 늦추고, DNS 조회가 필요하며, 차단될 수도 있습니다. 대부분의 경우 직접 호스팅하는 게 더 빠르고 안정적입니다.
캐싱 오해: "Google Fonts는 이미 캐시되어 있다"는 옛날 주장은 더 이상 사실이 아닙니다. 최신 브라우저는 프라이버시를 위해 사이트별로 캐시를 분리합니다. 사이트 A에서 받은 폰트를 사이트 B에서 재사용할 수 없습니다. 실제로는 각 사이트(와 사용자)가 독립적으로 비용을 부담합니다.

모범 사례는 간단합니다: 폰트를 직접 호스팅하세요. 폰트 제공업체(또는 Google Fonts)에서 다운로드해서 자체 도메인으로 제공하고, 헤더·프리로드·캐싱을 직접 관리하세요.

하지만 직접 호스팅하고 최적화해도, 사용자가 먼저 보는 건 브랜드 폰트가 아니라 대체 폰트입니다. 진짜 사용자 경험은 거기서 시작됩니다.

대체 폰트(폴백)와 매칭 폰트

로딩은 주 폰트 선택만의 문제가 아닙니다. 웹폰트가 로드되기 전과 로드될 때 디자인이 얼마나 자연스럽게 유지되는지가 중요합니다. 그래서 대체 폰트가 중요합니다.

대체 폰트를 염두에 두고 디자인하기

대체 폰트는 그냥 예비용이 아닙니다. 방문자가 실제로 보게 되는 기본 화면이며, 비록 몇 밀리초에 불과하더라도 그렇습니다. 그래서 디자인할 가치가 있습니다. 좋은 대체 폰트는:

레이아웃 시프트가 최소화되도록 기본 폰트의 x-height와 문자 너비를 충분히 가깝게 매치합니다
스타일적으로 호환이 됩니다: 브랜드 폰트가 둥근 산세리프 계열라면, Times New Roman이 아니라 시스템 산세리프를 선택하세요.
기본 폰트에 없을 수 있는 이모지, 심볼, 합자를 포함합니다

현대 CSS로 폴백 튜닝하기

섹션 4에서 font-size-adjust와 font-optical-sizing을 다뤘는데, 핵심은 여기서 어떻게 쓰느냐입니다. 대체 폰트 스택을 조정해 눈에 띄는 레이아웃 이동을 최소화할 수 있습니다.

예를 들어 대체 폰트의 x-height가 작다면, font-size-adjust로 크기를 살짝 키워서 웹폰트로 바뀔 때 글자가 더 자연스럽게 맞춰지게 할 수 있습니다.

body {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, sans-serif;
  font-size-adjust: 0.52; /* 커스텀 폰트의 x-height 비율 매치 */
}

웹폰트 로딩 완료 시 악명 높은 "튐 현상"을 방지합니다.

커스텀 폰트와 대체 폰트 매칭하기

최종 목표는 완벽함이 아니라 안정성입니다. Helvetica Neue가 Segoe UI를 완벽히 반영하게 할 수는 없지만, 다음은 할 수 있습니다:

비슷한 비율의 대체 폰트 선택
레이아웃 재조정(reflow)을 줄이도록 크기/줄 높이 조정
초기 렌더링에서 대체 폰트 모습을 더 가깝게 맞추려면 (가능한 경우) 가변 폰트 축을 사용

대체 폰트가 좋을수록 웹폰트가 적용될 때 아무도 눈치채지 못합니다.

그리고 기억하세요. 렌더링 엔진은 제각각입니다. Windows ClearType, macOS CoreText, Linux FreeType은 모두 안티앨리어싱(anti-alias : 윤곽 다듬기)과 폰트 힌팅(font hinting : 폰트 보정)을 다르게 처리합니다. 플랫폼마다 픽셀 단위로 똑같이 보이게 만들려는 건 의미 없습니다. 안정성과 가독성이 동일한 렌더링보다 중요합니다.

프리로딩(preloading)과 로딩 전략

올바른 폰트·서브셋·대체 폰트를 갖췄어도, 어떻게 전달하느냐가 사용자 경험을 결정합니다. 아무리 아름다운 폰트라도 늦게 뜨면 소용없습니다.

복잡한 로딩 결과 용어들

대부분 개발자가 FOIT와 FOUT 정도는 들어봤지만, 어떤 선택(또는 안 함)이 이를 유발하는지는 잘 모릅니다.

FOIT (Flash of Invisible Text): 웹폰트가 로드될 때까지 텍스트를 숨깁니다. 빠르면 매끄럽지만 느린 네트워크에선 재앙입니다.
FOUT (Flash of Unstyled Text): 대체 폰트를 먼저 보여주고 웹폰트 로드 시 교체합니다. 안정적이지만 거슬릴 수 있습니다.
FOFT (Flash of Faux Text): 브라우저가 굵기·이탤릭을 임시로 합성한 뒤 실제 폰트로 교체하는 지저분한 방식입니다. 산만하고 보기 흉합니다.

브라우저의 기본값과 CSS가 사용자가 보는 결과를 결정합니다.

font-display

font-display 디스크립터(설정)는 기본적인 제어 수단입니다:

swap: 대체 폰트를 즉시 표시하고 준비되면 교체합니다 (안전한 현대 기본값).
block: 텍스트를 최대 3초까지 숨긴 뒤 (FOIT) 대체 폰트를 보여줍니다. 위험합니다.
fallback: swap과 비슷하지만 웹폰트 로드 대기 시간이 짧습니다.
optional: 폰트가 빠르거나 이미 캐시된 경우에만 로드합니다. 중요하지 않은 자산에 좋습니다.

대부분의 사이트는 swap을 기본으로 설정해야 합니다. 정의하지 않은 채로 두지 마세요.

폰트 프리로딩

프리로드(preload)는 세밀한 제어 도구입니다. 다음을 추가하면:

<link rel="preload" as="font" type="font/woff2" crossorigin
      href="/fonts/brand-regular.woff2">

브라우저에게 CSS에서 @font-face 규칙을 만날 때까지 기다리지 말고 폰트를 즉시 가져오라고 지시합니다. 특히 <head>에 @font-face 선언을 인라인으로 넣는 경우 (권장 방식) 매우 유용합니다. 그렇지 않으면 레이아웃과 렌더링이 이미 시작된 후에야 폰트가 로드되는 경우가 많습니다.

⚠️ 프리로드는 선택적으로 하세요. unicode-range로 폰트를 서브셋으로 나눴다면, 초기 콘텐츠에 필요한 서브셋만 프리로드하세요. 모든 서브셋을 프리로드하면 사용하지 않더라도 전부 다운로드하게 되어 목적이 무색해집니다.

프리로드 주의할 점 (필독)

모든 것을 일치시키세요: 프리로드 URL은 @font-face src(경로, 쿼리스트링)와 정확히 일치해야 하고, 추가로 응답에 올바른 CORS 헤더(Access-Control-Allow-Origin)가 포함되어야 하며, 그와 더불어 <link>에 crossorigin이 있어야 합니다. 하나라도 맞지 않으면 프리로드가 실제 폰트 로드에서 재사용되지 않습니다. <link rel="preload" as="font" type="font/woff2" href="/fonts/brand-regular.woff2" crossorigin>
올바른 as/type 사용: as="font"와 정확한 MIME 힌트(type="font/woff2")는 우선순위 지정에 영향을 주고 브라우저의 요청 통합을 돕습니다. 잘못되거나 누락된 값은 프리로드를 무시하게 만들 수 있습니다.
모든 것을 프리로드하지 마세요: unicode-range로 나눴다면 (예: 라틴, 키릴), 첫 화면에 실제로 표시될 서브셋만 프리로드하세요. 모든 서브셋을 프리로드하면 전부 다운로드하게 되어 서브세팅이 무의미해집니다.
"늦게 사용된 프리로드(preload used late)" 경고: 브라우저는 프리로드된 리소스가 페이지 로드 직후 사용되지 않으면 경고합니다. 보통 문제가 있다는 신호입니다 (잘못된 URL, 늦게 발견된 @font-face, 중요하지 않은 폰트 프리로드).
Service Worker와의 시너지: SW를 사용한다면 설치 시 WOFF2를 사전 캐시하세요. 첫 방문은 프리로드를 사용하고, 다음부턴 SW에서 거의 즉시(~0ms) 가져옵니다.

인라인 방식 vs 외부 파일 속 @font-face

거의 아무도 활용하지 않는 쉬운 최적화 방법이 있습니다. @font-face를 외부 CSS 파일에 넣으면, 브라우저는 그 파일을 다운로드하고 파싱하고 실행하기 전까지는 폰트 존재 자체를 모릅니다. <head>에 바로 넣고 프리로드까지 걸어두면 네트워크 왕복 한 번을 통째로 없앨 수 있습니다.

다만, 주의할 점이 있습니다.

렌더 블로킹 스타일시트(render-blocking stylesheet : 브라우저가 화면을 그리기 전에 반드시 다운로드하고 처리해야 하는 스타일시트)를 이미 초반에 하나로 보내고 있다면, 굳이 인라인으로 넣어봤자 별 차이 없습니다. 브라우저는 어차피 @font-face 규칙을 금방 발견하고, 그 폰트가 필요한 텍스트가 실제로 화면에 뜰 때까지는 요청도 안 합니다. 거기다 렌더 블로킹 CSS가 혹시 폰트를 덮어쓸까봐 실행될 때까지 기다립니다. 이럴 땐 프리로드가 실질적인 효과를 냅니다.
CSS가 늦게 도착하거나 조각조각 들어오는 경우 : 크리티컬 CSS 인라인, async 또는 라우트별 스타일, CSS-in-JS, @import, SPA 하이드레이션. 이런 경우에는 인라인이 진짜 효과를 발휘합니다. 페이지가 절반쯤 렌더링될 때가 아니라 처음부터 바로 폰트를 발견하게 해주거든요. 이런 상황에서 충분히 활용되지 못하는 효과적인 방어책입니다.

결론: 인라인과 프리로드를 조합하면 깔끔한 최적화 효과를 낼 수 있습니다. 특히 요즘처럼 분산된 아키텍처에서 유용하죠. 다만 이게 사이트에 극적인 차이를 만든다면, 그건 CSS 전달 전략 자체를 재검토해야 한다는 신호이기도 합니다.

Early Hints (HTTP 103)

프리로드도 한계는 있습니다. 브라우저가 <link rel="preload">를 발견하려면 HTML을 어느 정도 파싱해야 하거든요 (또는 HTTP 응답에서 해당 헤더를 받을 때까지 기다려야 합니다). 서버나 네트워크가 느리면 꽤 오래 걸릴 수 있습니다.

Early Hints (HTTP 상태 103)를 쓰면, 서버가 본 HTML 응답을 보내기 전에 어떤 중요한 파일을 먼저 받아야 하는지 브라우저한테 미리 알려줄 수 있습니다.

즉 HTML 파싱을 기다리는 대신 첫 왕복 때부터 폰트를 전송할 수 있다는 얘기입니다.

HTTP/1.1 103 Early Hints
Link: </fonts/brand-regular.woff2>; rel=preload; as=font; type="font/woff2"; crossorigin

알아둘 점:

HTML Link 프리로드와 합치세요: 103에서 힌트를 주고 최종 200 응답에서 Link 헤더/HTML 태그로 다시 같은 폰트를 명시해도 괜찮습니다 (요즘 브라우저는 알아서 중복 제거합니다). 다만 중간 프록시를 믿지 마세요. 아직도 103을 버리는 프록시가 있거든요. HTML/200 대체용 프리로드는 꼭 남겨두세요.
힌트에 CORS 설정하세요: 103 Link에 crossorigin을 포함시켜야 초기 요청이 @font-face에서 재사용될 수 있습니다.
선택적으로 쓰세요: 스크롤 없이 보이는 첫 화면(above-the-fold)에 반드시 필요한 폰트/굵기만 힌트(hint)에 포함하세요. 너무 많이 포함하면 HTML/CSS랑 경쟁해서 오히려 TTFB가 느려집니다.

서버, CDN, 브라우저에서 지원이 점점 늘고 있습니다. 폰트 프리로드를 이미 쓰고 있다면, Early Hints 추가는 텍스트 표시 시간을 수백 밀리초 더 줄일 수 있는 직관적인 방법입니다.

⚠️ 무분별하게 쓰지 마세요: 첫 화면에 확실히 필요한 폰트만 힌트에 넣으세요. 너무 많이 넣으면 대역폭만 잡아먹고 더 중요한 파일들과 경쟁하게 됩니다.

@import 사용하지 마세요

최악의 실수 중 하나는 @import를 통해 폰트(또는 폰트를 선언하는 CSS)를 로드하는 겁니다. @import는 매번 네트워크 왕복을 추가합니다: 브라우저가 상위 CSS를 받고, 파싱하고, 다른 CSS 파일이 필요하다는 걸 알아채고, @font-face를 발견하고… 그제야 폰트를 요청합니다.

가장 느린 경로를 전부 거쳐야 텍스트를 표시할 수 있다는 뜻입니다.

해결책은 간단합니다: 폰트에 @import 쓰지 마세요. @font-face는 브라우저가 최대한 빨리 볼 수 있는 스타일시트에 선언하세요. 가장 좋은 건 프리로드와 함께 <head>에 인라인으로 넣는 겁니다.

전략적 타협점

핵심 폰트(본문, 내비게이션): 프리로드 + font-display: swap
보조 폰트(제목, 강조): 스크롤 없이 볼 수 있는 부분에 있을 때만 프리로드, 아니면 지연 로드
장식 폰트: optional 고려하거나 완전히 미루기

로딩 전략은 원칙론("무조건 swap" vs "무조건 block")이 아닙니다. 사용자에게 가장 덜 나쁜 절충안을 선택하는 문제입니다. 텍스트가 즉시 렌더링되는 것과 지연되는 것의 차이는 사용자가 머무르는지 이탈하는지의 차이입니다.

폰트 로딩 API (Font Loading API)

세밀한 제어가 필요하다면 폰트 로딩 API를 쓸 수 있습니다. 폰트가 준비됐는지 감지하고 교체 타이밍을 조율할 수 있는 프로미스(promise)를 제공합니다. 다만 실무에서는 극도로 동적이거나 JS 위주 사이트가 아니면 거의 쓸 일이 없습니다. 그래도 있다는 건 알아두세요.

파일 포맷: WOFF2, WOFF, TTF, 그리고 레거시의 짐

폰트 세계는 낡은 형식, 잘못된 정보, 맹목적인 관행으로 뒤덮여 있습니다. 많은 사이트가 아직도 2012년 방식으로 폰트를 제공합니다. 쓸데없는 형식을 여러 개 보내면서 용량만 키우고 있죠.

WOFF2: 현대의 기본값

이 섹션에서 하나만 기억하세요: WOFF2만 쓰고, 나머지는 거의 무시하세요.

가장 효율적인 웹 형식으로 WOFF나 TTF보다 압축률이 뛰어납니다.
모든 최신 브라우저에서 지원됩니다.
완전한 OpenType 테이블, 가변 폰트, 최신 기능을 모두 포함할 수 있습니다.

대부분의 프로젝트는 WOFF2만 있으면 됩니다. IE11이나 아주 오래된 안드로이드를 지원해야 할 명확한 사업적 이유가 없다면, 다른 형식을 보낼 필요가 없습니다. 레거시 호환성 때문에 모든 방문자한테 성능 부담을 떠넘길 순 없죠.

한 가지 주의할 점: 일부 CDN은 WOFF2가 이미 Brotli로 압축되어 있는데도 또다시 Brotli 압축을 시도합니다. 아무 이득 없이 CPU만 낭비하는 겁니다. WOFF2를 그냥 그대로 제공하도록 설정하세요.

WOFF: 아마 안 써도 될 대체 형식

WOFF는 TTF/OTF를 감싸는 웹 최적화 래퍼(web-optimised wrapper)로 설계되었습니다. 요즘은 매우 오래된 브라우저(기업 인트라넷의 IE11 같은)를 꼭 지원해야 할 때만 의미가 있습니다. 일반 웹에서는 그냥 불필요한 짐이죠.

TTF/OTF: 데스크톱 시대의 유물

TrueType(TTF)과 OpenType(OTF) 폰트는 디자인 프로그램이나 컴퓨터 설치용엔 좋지만, 브라우저에 바로 보내는 건 낭비입니다. 용량도 크고 파싱도 느린 데다, 공개하고 싶지 않은 메타데이터까지 드러나는 경우도 있습니다.

빌드 파이프라인이 아직도 웹용으로 .ttf를 뱉어낸다면 업데이트할 시점입니다.

SVG 폰트: 그냥... 안 돼요

옛날에는 SVG-in-font가 컬러 글리프(이모지 같은)를 브라우저에 넣기 위한 꼼수였습니다. 이제 그 시대는 지났습니다. 요즘 이모지와 컬러 폰트는 OpenType/WOFF2 안의 COLR/CPAL이나 CBDT/CBLC 테이블을 씁니다. 스택에 SVG 폰트가 보이면 당장 지우세요.

Base64 임베딩

아직도 가끔 CSS에 폰트를 base64로 때려박는 사람이 있습니다. 절대 하지 마세요. CSS 파일만 비대해지고, 캐싱도 깨지고, 병렬 로딩도 막힙니다. 폰트는 무거운 파일이라 독립적인 요청과 캐시 헤더가 있어야 합니다.

여러 형식이 필요한가요?

아니요. "IE11이랑 Android 4.x를 꼭 지원해야 하고, 시스템 기본 폰트로는 절대 안 된다"는 확실한 사업적 이유가 없다면 필요 없습니다. 나머지는:

WOFF2만
자체 호스팅
프리로드랑 캐싱 잘하기

이게 다입니다. 그리고 WOFF2를 쓴다면 제대로 하세요: 폰트 파일에 긴 캐시 기간(몇 달~1년)을 설정하고, 폰트 변경 시 버전 번호 붙은 파일명으로 캐시를 갱신하세요. 폰트는 거의 안 바뀌니까 재방문 때는 거의 항상 캐시에서 가져와야 합니다. 캐싱 관련 팁은 제 다른 글을 참고하세요.

레거시 형식은 짐입니다. 아직도 쓰고 있다면, 아무도 안 쓰는 브라우저 때문에 모든 방문자한테 대가를 떠넘기는 겁니다.

아이콘 폰트: Font Awesome과 커다란 실수

옛날에는 아이콘 폰트는 영리해 보였습니다. 글리프들을 폰트 파일에 담고 문자에 할당하면 끝. 확대 가능하고 CSS로 꾸밀 수 있는 아이콘 완성. Font Awesome, Ionicons, Bootstrap의 Glyphicon 세트… 어디든 있었죠.

하지만 이건 처음부터 임시방편이었습니다. 그리고 2025년엔 정당화할 수 없습니다.

아이콘 폰트의 근본적 문제들

접근성: 스크린 리더가 "사용자 정의(private use)" 문자를 의미 없는 소리로 읽습니다. 실제 의미 정보가 없기 때문입니다.
취약성: 폰트 로드에 실패하면, 사용자는 의미 없는 사각형이나 대체 문자를 보게 됩니다.
스타일 편법: line-height, 정렬, 크기 맞추기가 항상 불안정했습니다.
성능: 몇 개만 사용하려고 전체 폰트 파일(종종 수백 개의 미사용 아이콘 포함)을 전송하게 됩니다.

더 나은 대안들

인라인 SVG: 의미가 명확하고, 유연하며, CSS로 꾸밀 수 있습니다.
SVG 스프라이트: 캐시되고, ID로 쉽게 바꾸거나 참조할 수 있습니다.
아이콘 컴포넌트(React/Vue/등): 필요할 때만 불러오고, 트리 쉐이킹됩니다.
CSS mask-image / -webkit-mask-image: 벡터 형태를 순수 CSS 마스크로 사용하고 싶을 때 깔끔한 옵션입니다 (예: 아이콘 색상을 동적으로 변경).

"하지만 이미 Font Awesome을 쓰는데..."

아이콘 폰트에 갇혀 있다면, 급히 해야 할 두 가지가 있습니다:

서브셋으로 만드세요. 7개 쓰려고 700개를 보내면 안 됩니다.
마이그레이션 계획 세우세요. 대부분 SVG로 옮깁니다. 요즘 아이콘 세트 대부분(Font Awesome 포함)이 SVG 버전을 제공합니다.

남아있는 미신

사람들이 아이콘 폰트를 고집하는 이유는 "어디서나 그냥 작동하기" 때문입니다. 예전에는 사실이었습니다. 하지만 지금 SVG는 보편적으로 지원되고, 의미도 더 명확하며, 더 나은 도구를 갖추고 있습니다.

아이콘 폰트는 레이아웃에 테이블을 쓰는 것과 같습니다. 당시엔 영리한 편법이었지만, 아직도 반복하고 있어서는 안 되는 잘못된 선택입니다.

라틴 문자를 넘어서: 비라틴 문자, RTL 언어, 그리고 이모지

아이콘 폰트가 글리프 부족 때문에 생긴 편법이라면, 글로벌 타이포그래피는 정반대 문제입니다: 글리프가 너무 많고, 문자 체계도 너무 많고, 복잡성도 너무 큽니다.

영어만 생각한다면 폰트 최적화는 쉽습니다. 하지만 웹에는 라틴 문자만 있는 게 아니며, 많은 "모범 사례"가 다른 문자 체계로 넘어가면 무너집니다.

비라틴 문자

아랍어, 데바나가리, 태국어 등은 라틴 문자보다 훨씬 복잡합니다. 셰이핑 엔진, 합자, 문맥 형태가 필요합니다. 함부로 서브셋을 만들면 단어가 통째로 깨져서 멀쩡한 텍스트가 알아볼 수 없게 됩니다.

무작정 서브셋 만들지 마세요. 많은 문자는 제대로 표시되려면 전체 블록이 필요합니다.
OS마다 테스트하세요. 문자 체계에 따라 플랫폼별로 기본 대체 방식이 완전히 다를 수 있습니다.
폰트가 무거울 걸 각오하세요. 완전한 CJK 폰트는 최적화 전에도 쉽게 5 – 10MB가 됩니다. 이런 경우 가변 폰트나 점진적 로딩이 훨씬 더 중요합니다.

RTL 언어

아랍어와 히브리어 같은 우횡서 문자는 그냥 좌우 반전된 텍스트가 아닙니다. 이런 특징들이 있습니다:

구두점과 숫자 모양이 다릅니다.
마크업과 CSS와 상호작용하는 방향 제어(bidi)가 있습니다.
라틴 문자 기반 대체 폰트와 메트릭이 크게 다를 수 있습니다.

대체 폰트 스택은 RTL을 제대로 이해해야 합니다. 라틴 글리프를 단순히 거울상으로 렌더링하는 게 아닙니다. 반드시 실제 RTL 콘텐츠로 테스트하세요.

이모지

이모지는 특수한 경우입니다. 웹폰트에 이모지 글리프를 포함해서는 안 됩니다. 무겁고 일관성이 없으며, 유니코드 컨소시엄(Unicode consortium)이 새 이모지를 추가하면 바로 구식이 됩니다. 알맞게 사용하는 방법은 간단합니다:

시스템의 기본 이모지 폰트를 사용하세요 (Apple Color Emoji, Segoe UI Emoji, Noto Color Emoji 등).
시스템 스택에 포함하세요. 보통 주요 폰트 뒤에 배치합니다: font-family: "YourBrandFont", -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Noto Color Emoji", "Apple Color Emoji", sans-serif;
이모지가 플랫폼마다 다르게 보인다는 점을 받아들이세요. 그게 웹입니다.

글로벌 텍스트를 위한 디자인

브랜드가 전 세계에서 쓰인다면 이렇게 테스트하세요:

혼합 문자 체계 (영어 + 아랍어, 또는 중국어 + 이모지).
플랫폼 차이 (Android vs iOS vs Windows).
선택한 폰트가 해당 문자를 지원하지 않을 때 대체 처리.

글로벌 타이포그래피는 단순히 얼마나 많은 문자를 지원하느냐의 문제가 아닙니다. 얼마나 견고하냐의 문제입니다. 폰트 전략은 다양성을 전제로 세워야 하며, 다양성 앞에서 무너지면 안 됩니다.

웹폰트의 미래: 진화하는 표준과 새로운 위험

역사와 현재를 살펴봤습니다. 하지만 폰트 이야기는 여기서 끝이 아닙니다. 새로운 CSS 명세, 새로운 브라우저 동작, 새로운 앱 아키텍처가 앞으로 몇 년간 "모범 사례"가 어떻게 바뀔지 만들어가고 있습니다.

곧 나올 CSS 및 폰트 기술

기술 명세와 브라우저에서 새로운 디스크립터(descriptor)와 속성이 계속 추가되고 있습니다:

font-palette: COLR/CPAL 컬러 폰트 내부의 색상 팔레트를 전환하거나 직접 조정할 수 있습니다.
font-synthesis: 브라우저가 굵게/기울임을 임의로 만드는 걸 제어합니다 (드디어 "하지 마" 스위치가 생겼습니다).
size-adjust(font-size-adjust에서 확장): 대체 폰트 정렬을 더 세밀하게 조정합니다.
점진적 폰트 전송(IFT): 전체 파일 다운로드 대신 페이지에 필요한 글리프만 점진적으로 가져오는 방식입니다. 아직 나오는 중입니다.

아직 주류는 아니지만, 더 정밀하게 제어할 수 있는 미래를 보여줍니다.

JS 중심 웹사이트와 SPA의 위험

새로운 표준은 흥미롭지만, 실제 구현은 오늘날 사이트가 실제로 만들어지는 방식과 충돌하는 경우가 많습니다. 현실은 이렇습니다: 현대 웹은 JavaScript 중심의 프레임워크 기반 애플리케이션이 장악하고 있습니다. 이는 폰트 로딩 환경을 바꿔놓았습니다.

현대 JavaScript 프레임워크 (React, Vue, Angular, Next 등)는 폰트 로딩에 새로운 과제를 제시합니다:

폰트가 늦게 트리거됨: 라우트/컴포넌트가 CSS를 지연 로드하면, 폰트는 하이드레이션(hydration) 이후에만 요청되어 버벅임을 유발할 수 있습니다.
필수(critical) CSS 추출 문제: 자동화 도구가 때때로 @font-face 규칙을 놓쳐서 프리로드 체인을 깨뜨립니다.
클라이언트 사이드 라우팅(CSR): 뷰를 이동할 때 처음에 프리로드 안 한 새 폰트를 불러올 수 있습니다.
Font Loading API 오용: 일부 SPA는 폰트 로딩을 직접 제어하려다가 오히려 지연시킵니다.

제대로 하는 방법은 간단합니다: 폰트를 "그냥 또 하나의 스타일시트"가 아니라 애플리케이션 필수(application-critical) 자산으로 취급하세요. 선언을 초반에 프리로드하고 인라인으로 넣으며, 라우트에서 늦게 요청되는 폰트가 있는지 테스트하세요.

가변 폰트와 컬러 폰트의 시대

가변 폰트는 이제 예외가 아니라 기본이 되고 있고, 컬러/이모지 폰트도 주류가 되고 있습니다. 이는:

폰트 사용 방식으로 더 복잡한 파일과 더 많은 변형 축을 다뤄야 한다는 뜻입니다.
파일 크기가 커지니까 서브셋팅과 로딩 전략이 훨씬 더 중요해집니다.
여러 개의 고정 굵기 대신 하나의 매우 유연한 가변 폰트를 쓰는 사이트가 더 많아질 겁니다.

인식의 변화

오랫동안 폰트는 장식으로 취급받았습니다. 빌드 마지막에 덧붙이는 꾸밈 요소였죠. 미래는 정반대를 요구합니다: 타이포그래피를 인프라로 다루는 것. 성능 예산, 접근성 표준, 국제화 모두 폰트를 제대로 다루는 데 달려 있습니다.

웹폰트 생태계는 아직 발전 중입니다. 지난 10년이 폰트를 작동시키는 데 집중했다면, 다음 10년은 효율적이고 예측 가능하며 글로벌한 폰트를 만드는 데 집중할 겁니다.

하지만 희망과 이론만으론 의미가 없습니다. 폰트는 믿음이 아니라 측정이 필요합니다. 바로 여기서 도구가 등장합니다.

도구와 검증

폰트를 만지작거리는 것의 좋은 점은 선택의 결과와 성능을 측정할 수 있다는 겁니다. 설정이 효율적인지 (그리고 아름다운지, 또는 최소한 브랜드에 맞는지) 알고 싶다면, 모든 게 테스트 가능합니다. 이런 걸 쓸 수 있습니다:

DevTools: Chrome/Edge에서 "느린 3G, 빈 캐시"를 시뮬레이션해서 텍스트가 보이지 않는지, 스타일 없는지, 튀는지 확인하세요. 워터폴을 보고 폰트가 언제 다운로드 시작하는지 확인하세요.
WebPageTest / Lighthouse: 둘 다 폰트 요청 타이밍, 블로킹 리소스, 늦은 교체로 인한 CLS를 보여줍니다.
Glyphhanger / Subfont: 사이트가 실제로 사용하는 글리프를 분석하고 서브셋을 자동 생성하는 CLI 도구입니다.
Fonttools (pyftsubset): 전문적인 폰트 서브셋팅과 편집을 위한 만능 도구입니다.
CI 체크: 예산을 설정하세요 (예: 굵기 3개 이하, 압축 폰트 200 KB 이하).
Transfonter: 최적화된 폰트 파일과 CSS를 생성합니다.
Font Style Matcher: 대체 폰트 메트릭을 커스텀 폰트에 맞게 설정합니다.

황금률: 콜드 캐시(cold-cache), 느린 네트워크 환경에서 폰트를 테스트해본 적이 없다면, 사이트가 실제로 어떻게 작동하는지 모르는 겁니다.

폰트를 제대로 다루기 위한 선언문

웹폰트는 장식이 아닙니다. 사용성, 성능, 접근성, 심지어 법적 문제까지 좌우합니다. 그런데도 대부분의 웹은 여전히 폰트를 뒷전으로 미룹니다. 늦게 덧붙이고, 낡은 유물로 비대하게 만들고, 텍스트만큼 기본적인 것 때문에 사용자 경험을 망가뜨립니다.

이럴 필요 없습니다. 폰트를 JavaScript, 캐싱, 분석 도구만큼 진지하게 다루면 제대로 처리하는 건 간단합니다.

원칙:

시스템 우선: 견고한 시스템 스택으로 시작하세요. 커스텀 폰트는 점진적 개선이지 의존 수단이 아닙니다.
공격적으로(하지만 지능적으로) 서브셋하세요: 사용자에게 필요한 것만 보내고, 지원하는 언어로 테스트하세요.
프리로드하고 인라인하세요: 핵심 @font-face 규칙을 묻어두거나 요청을 지연시키지 마세요.
WOFF2만(99%의 경우): 레거시 형식이라는 짐을 버리세요.
아이콘은 SVG: 아이콘 폰트는 과거에 남겨두세요.
가치를 더할 때 가변 폰트: 유연한 파일 하나가 여러 정적 굵기를 이깁니다.
대체 폰트를 설계하세요: 시스템 스택이 레이아웃을 망가뜨리지 않도록 메트릭을 조정하세요.
글로벌 문자를 존중하세요: 아랍어, CJK, RTL, 이모지를 다르게 최적화하세요.
진지하게 테스트하세요: 다양한 기기, 다양한 네트워크, 다양한 지역에서.

이건 순수함을 쫓거나 모호한 미세 최적화(micro-optimisations)를 하자는 게 아닙니다. 빠르게 렌더링되고, 보기 좋고, 어디서나 작동하는 웹을 만들자는 겁니다.

폰트는 콘텐츠입니다. 폰트는 브랜드입니다. 폰트는 사용자 경험입니다. 아직도 "그냥 또 하나의 에셋"으로 다루고 있다면, 잘못 로드하고 있는 겁니다.

[FE/optimization] 당신은 폰트를 잘못 로딩하고 있다 (그리고 그게 성능을 망치고 있다)