웹폰트, 지금 당신 사이트엔 필요 없을 수도 있습니다

디자인 관련 글을 보다 보면 "웹폰트를 써야 한다"는 전제가 으레 깔려 있습니다. Pretendard를 연결하고, font-display: swap을 설정하고, 서브셋까지 처리하고… 어느 순간 이 과정이 웹 제작의 당연한 루틴처럼 굳어졌어요.

저는 그 전제를 뒤집어 보고 싶습니다.

GitHub, Medium, Bootstrap, Booking.com. 이 서비스들의 공통점이 있습니다. 전부 시스템 폰트 스택을 씁니다. 폰트를 고를 능력이 없어서가 아닙니다. 성능과 유지 관리를 따져본 뒤 의도적으로 안 쓰기로 결정한 겁니다.

웹폰트는 켜는 것보다 끄는 게 기본값이어야 할 기술입니다. 파일 크기, LCP 지연, CLS 위험, 라이선스 관리—이 네 가지 비용을 치르고도 얻는 게 더 많은 상황인지 먼저 확인해야 합니다. 이 글은 그 확인을 돕습니다.

---

웹폰트 없어도 되는 사이트 유형부터 걸러봅니다

아래 항목 중 해당하는 게 많을수록 시스템 폰트 스택이 더 나은 선택입니다. 웹폰트를 어떻게 쓸까 고민하기 전에, 진짜 필요한지부터 따져보세요.

사이트 성격

• 개인 블로그 또는 기술 블로그
• 개인 포트폴리오 사이트
• 회사 내부 인트라넷·어드민 대시보드
• 단순 랜딩페이지 (정보 전달 위주, 마케팅 페이지 아님)
• 문서 사이트·개발자 레퍼런스 페이지
• Core Web Vitals 점수 개선이 필요한 사이트

운영 상황

• 모바일 성능이 최우선인 서비스
• 느린 네트워크 환경 사용자가 많은 서비스
• 폰트 라이선스 관리가 번거롭게 느껴지는 상황
• 웹폰트 적용 후 CLS가 눈에 띄게 올라간 경우
• 빠른 프로토타입·MVP 단계여서 폰트 설정에 시간 쓰기 아까운 경우

디자인 방향

• 특정 서체 브랜딩보다 콘텐츠 가독성이 더 중요한 경우
• OS 네이티브 느낌이 오히려 신뢰감을 주는 서비스 (관리도구, SaaS 대시보드 등)
• 다국어 지원이 필요하고 무거운 폰트를 서브셋 없이 쓰고 싶지 않은 경우

5개 이상 해당한다면 웹폰트 없이 시스템 폰트 스택만으로 시작하는 걸 진지하게 고려해볼 만합니다. 브랜딩이 확립된 이후에 추가해도 늦지 않고, 오히려 그쪽이 더 깔끔한 순서입니다.

현실적으로 생각해보면, 개인 블로그나 포트폴리오처럼 콘텐츠가 주인공인 사이트에서 폰트를 바꾼다고 독자가 체감하는 경우는 드뭅니다. 반면 Lighthouse에서 LCP가 개선되는 건 숫자로 바로 보입니다. 개선 효과가 명확한 쪽을 고르는 게 합리적입니다.

---

웹폰트가 실제로 치르는 비용, 숫자로 보면 이렇습니다

체크리스트를 봤는데도 "그래도 한번 써볼까" 싶다면, 비용부터 숫자로 보세요.

한글 웹폰트는 특히 무겁습니다. 영문 폰트는 수십 KB 수준이지만, 한글은 1만 1,172자를 커버해야 하기 때문에 최적화 없이는 수백 KB에서 수 MB까지 올라갑니다. WOFF2 압축·서브셋 처리를 해도 영문보다 수배 무거운 건 구조적인 문제입니다. HTTP Archive 2024 Web Almanac 기준으로 데스크톱 페이지의 폰트 중앙값은 약 131KB로, 전체 페이지 무게(데스크톱 중앙값 약 1,895KB)의 약 7% 수준입니다. 평균치만 보면 얌전해 보이지만, 최적화 없는 한글 폰트는 그 몇 배를 훌쩍 넘기기 때문에 다릅니다.

성능 관점에서 두 가지 문제가 구체적으로 나타납니다.

LCP(Largest Contentful Paint) 지연. 폰트 파일을 받는 동안 텍스트 렌더링이 늦어집니다. 기본값(font-display: block)은 최대 3초까지 텍스트를 숨깁니다. font-display: swap을 쓰면 일단 시스템 폰트로 보여주지만, 네트워크 요청 자체는 그대로입니다.

CLS(Cumulative Layout Shift) 위험. font-display: swap을 쓸 경우, 시스템 폰트로 먼저 뜬 텍스트가 웹폰트 로드 후 교체되면서 글자 너비와 행간이 달라집니다. 레이아웃이 밀리거나 버튼 크기가 바뀌는 현상이 여기서 납니다. CLS는 Google Core Web Vitals에서 검색 순위에 직접 영향을 주는 지표입니다.

웹폰트 vs 시스템 폰트 스택 성능 비교

---

시스템 폰트 스택, 이 정도면 충분합니다

웹폰트를 안 쓰는 게 곧 포기가 아닙니다. 시스템 폰트 스택은 기기에 이미 설치된 폰트를 우선 쓰도록 CSS에 명시하는 방법입니다. 네트워크 요청이 없고, 기기에 최적화된 폰트가 바로 렌더링됩니다. macOS라면 San Francisco, Windows라면 Segoe UI, Android라면 Roboto가 뜹니다.

고해상도 디스플레이 환경에서는 시스템 폰트가 오히려 더 선명하게 보이는 경우도 있습니다. Apple의 San Francisco나 Microsoft의 Segoe UI는 Retina·HiDPI 화면에 맞춰 힌팅이 정교하게 조정된 폰트들이거든요.

가장 많이 쓰이는 현대적 스택:

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

CSS 변수로 관리하면 나중에 폰트를 바꿀 때도 한 줄만 고치면 됩니다:

:root {
  --font-sans: system-ui, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;
}
body {
  font-family: var(--font-sans);
}

코드 블록처럼 모노스페이스가 필요한 경우도 따로 웹폰트를 안 써도 됩니다:

code, pre {
  font-family: Menlo, Consolas, Monaco, "Liberation Mono", monospace;
}

개발 블로그나 기술 문서 사이트라면 이 정도면 충분합니다. -apple-system, BlinkMacSystemFont는 구형 Safari·Chrome 호환용이라 레거시 지원이 필요한 경우에만 앞에 추가하면 됩니다.

---

웹폰트가 정말 필요한 경우는 이 정도입니다

여기까지 읽고도 웹폰트가 필요하다는 결론이 나왔다면, 그 판단이 맞는 경우가 실제로 있습니다.

브랜드 정체성이 폰트에 달린 경우. 특정 서체가 브랜드 아이덴티티의 핵심이라면 시스템 폰트로는 대체가 안 됩니다. 로고 주변 텍스트, 헤드라인, 마케팅 페이지처럼 첫인상이 결정적인 영역이 여기 해당합니다.

디자인 일관성이 필수인 경우. 시스템 폰트는 macOS에서는 San Francisco, Windows에서는 Segoe UI로 다르게 뜹니다. 모든 환경에서 동일하게 보여야 하는 서비스라면 웹폰트가 필요합니다.

특수 서체가 꼭 필요한 경우. 손글씨 느낌이나 독특한 디스플레이 타이포그래피는 시스템 폰트로는 구현이 안 됩니다. 굿즈·인쇄물과 웹을 일관성 있게 맞춰야 하는 경우도 마찬가지입니다.

다국어·특수 글리프가 필요한 경우. 아랍어·히브리어·태국어처럼 시스템 폰트 커버리지가 불안정한 언어라면 Noto Sans 계열 웹폰트가 안전합니다.

쓰기로 결정했다면 성능 영향을 줄이는 방법을 함께 챙기세요. WOFF2 형식에 서브셋 처리를 조합하면 파일 크기를 크게 줄일 수 있고, font-display: optional을 적용하면 CLS를 제로로 만들 수 있습니다. 한글은 KS 완성형 기준 자주 쓰는 2,350자만 서브셋으로 추리면 수십~수백 KB 수준으로 내려옵니다. Google Fonts 한국어 옵션은 실제 페이지에 나오는 글자만 동적으로 요청하는 방식이라 자체 호스팅 시에는 직접 정적 서브셋을 만들어야 합니다.

한 가지 더. font-display: optional이라는 중간 선택지도 있습니다. 100ms 안에 폰트가 로드되면 사용하고, 그러지 못하면 그냥 시스템 폰트로 렌더링합니다. CLS도 없고 텍스트 숨김도 없습니다. 느린 모바일 환경에서는 사실상 항상 시스템 폰트가 뜨니, 성능 타협을 최소화하면서 웹폰트를 유지하고 싶다면 고려해볼 값입니다.

---

웹폰트를 쓰기로 했다면, 선택 전에 꼭 확인할 것

쓰기로 결정했다면 가장 먼저 할 일은 라이선스 확인입니다. 폰트를 CSS @font-face로 서버에서 직접 서빙하는 것, 즉 웹 임베딩은 배포·설치 허용과 별개로 명시적으로 허용돼야 합니다. 아무 폰트나 가져다 쓰다 나중에 라이선스 문제가 터지는 경우가 생각보다 많습니다.

폰트비에서 한글·영문 폰트를 검색하면 폰트별로 웹사이트 사용 가능 여부, 바로 복사해 쓸 수 있는 @font-face 코드, 공식 다운로드 페이지 링크를 한 번에 확인할 수 있습니다. 상세 페이지에서 '웹사이트 사용: 가능' 같은 사용 범위 표시와 함께 라이선스 원문까지 볼 수 있어서, 나중에 라이선스 문제가 생기는 상황을 미리 막을 수 있습니다 🔍

폰트 파일은 폰트비가 배포하는 게 아니라 각 제작사 공식 배포처에서 받는 구조입니다. 폰트비는 라이선스와 사용 범위를 한곳에서 확인하고 공식 출처로 이동하는 디렉터리 역할을 합니다.

웹폰트 도입 전에 위의 체크리스트로 정말 필요한지 먼저 확인하고, 필요하다는 결론이 나면 그때 신중하게 폰트를 고르는 게 자연스러운 순서입니다.

---

참고자료

• Optimize web fonts — web.dev
• Fixing Layout Shifts Caused by Web Fonts — DebugBear
• System Font Stack — CSS-Tricks