Google Fonts를 사용하지 않고 폰트를 로컬에서 호스팅하는 방법

왜 Google Fonts를 자체 호스팅해야 할까요?

Google Fonts는 좋은 타이포그래피를 쉽게 만들었습니다. 스타일시트를 추가하고, 몇 가지 굵기를 선택한 뒤, 페이지를 배포하면 됩니다. 오랫동안 소규모 팀에게는 합리적인 기본값이었습니다.

그 대신 모든 방문자의 브라우저가 폰트 CSS와 폰트 파일을 가져오기 위해 서드파티 서비스에 접속합니다. 여기에는 두 가지 결과가 따릅니다.

첫째, 렌더링에 외부 의존성이 추가됩니다. 사용자의 지역이나 네트워크에서 폰트 CSS가 느리거나, 차단되거나, 사용할 수 없으면 페이지는 기다리거나 대체 폰트로 표시됩니다.

둘째, 개인정보 보호 문제가 생깁니다. 폰트 요청은 사용자의 IP 주소, user agent, referrer policy 컨텍스트, 타이밍 정보를 서드파티에 노출할 수 있습니다. Google Fonts는 Fonts API를 통해 쿠키를 설정하지 않는다고 밝히지만, “쿠키 없음”이 “개인정보 없음”과 같은 뜻은 아닙니다. GDPR에서는 IP 주소도 맥락에 따라 여전히 개인정보가 될 수 있습니다.

폰트 자체 호스팅이 모든 웹사이트에 자동으로 필요한 것은 아니며, 이 글은 법률 자문이 아닙니다. 하지만 유럽 사이트, 공공 부문 사이트, 의료, 교육, 금융, 또는 불필요한 서드파티 요청을 줄이려는 모든 팀에게는 로컬 호스팅이 대체로 더 깔끔한 선택입니다.

잘 구현하면 성능상 이점도 자주 있습니다. 핵심은 “잘 구현하면”입니다. 여섯 개의 폰트 파일을 /assets/fonts/에 복사하고 모든 페이지에서 전부 로드하는 방식은 호스팅 서비스를 사용하는 것보다 더 나쁠 수 있습니다. 더 넓은 성능 맥락이 필요하다면, 대부분의 사이트에서 웹 폰트가 여전히 가장 쉬운 성능 개선 지점인 이유를 다룬 이전 글에서 흔한 낭비 패턴을 설명합니다.

자체 호스팅하면 무엇이 달라지나요?

Google Fonts를 일반적인 방식으로 사용할 때 페이지는 다음을 수행합니다.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap" rel="stylesheet">

브라우저는 먼저 fonts.googleapis.com에서 CSS를 요청한 뒤, fonts.gstatic.com에서 폰트 파일을 다운로드합니다.

자체 호스팅하는 경우 페이지는 CSS와 폰트 파일을 모두 자체 도메인에서 요청해야 합니다.

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

이렇게 하면 서드파티 폰트 요청이 제거됩니다. 동시에 파일 형식, 캐시 헤더, 대체 폰트, 업데이트를 직접 선택할 책임도 생깁니다.

이 책임은 진지하게 다룰 가치가 있습니다. 폰트는 중요한 렌더링 경로 위에 있습니다. 잘못된 폰트 설정은 보이지 않는 텍스트, 레이아웃 이동, 느린 첫 렌더링을 유발할 수 있습니다.

Step 1: 실제로 사용하는 항목을 감사하세요

무엇이든 다운로드하기 전에 사이트에 실제로 필요한 폰트 패밀리, 굵기, 스타일, 문자 집합을 나열하세요.

일반적인 마케팅 사이트에는 다음이 필요할 수 있습니다.

• 본문 텍스트용 Regular 400
• 제목과 버튼용 Semibold 600 또는 bold 700
• 디자인이 실제로 이탤릭을 사용하는 경우에만 Italic 400
• 사이트가 더 많은 언어를 지원하지 않는다면 Latin 문자 집합만

오래된 디자인 시스템 기본값을 의심하세요. 많은 사이트가 300, 400, 500, 600, 700, 이탤릭, 여러 스크립트를 로드합니다. 누군가 폰트 선택기에서 한 번 선택했기 때문입니다.

브라우저 DevTools에서 Network 패널을 열고 “font”로 필터링한 뒤, 페이지를 다시 로드하고 어떤 파일이 요청되는지 확인하세요. 그런 다음 CSS에서 font-weight 사용을 검사하세요. CSS가 300을 전혀 사용하지 않는다면 300을 호스팅하지 마세요.

나중에 영향을 검토할 때 Lighthouse가 도움이 될 수 있지만, 점수를 전부로 보지는 마세요. 판단자가 아니라 진단 도구로 사용하세요. 폰트 개선 우선순위를 정할 때 유용한 별도 가이드인 당황하지 않고 Lighthouse 보고서를 읽는 방법도 있습니다.

Step 2: 올바른 폰트 파일을 다운로드하세요

Google Fonts는 오픈소스 폰트를 제공합니다. Google Fonts 웹사이트나 관련 폰트 프로젝트 저장소에서 다운로드할 수 있습니다. 라이선스를 확인하세요. 다만 대부분의 Google Fonts는 SIL Open Font License 또는 Apache License와 같은 오픈 라이선스로 배포됩니다.

웹에서는 WOFF2를 선호하세요. 최신 브라우저에서 폭넓게 지원되며, 보통 TTF나 OTF보다 훨씬 작습니다. 2026년에 공개 웹사이트에서 TTF를 브라우저에 직접 제공하는 것은 거의 정당화되기 어렵습니다.

합리적인 디렉터리 구조는 다음과 같습니다.

/public
  /fonts
    inter-latin-400.woff2
    inter-latin-600.woff2
    inter-latin-700.woff2

설명적인 파일 이름을 사용하세요. 6개월 뒤 font.woff2는 성가실 것입니다. inter-latin-600.woff2는 단조롭지만 유용합니다.

사이트가 빌드 시스템을 사용한다면, 원본 폰트는 명확한 위치에 보관하고 빌드 파이프라인이 최적화된 파일을 public assets 디렉터리로 복사하게 하세요.

Step 3: 적절한 경우 폰트를 서브셋하세요

서브셋은 필요하지 않은 문자를 제거하는 것을 뜻합니다. 전체 폰트에는 Latin, Cyrillic, Greek, Vietnamese, 기호, 많은 OpenType 기능이 포함될 수 있습니다. 영어 전용 랜딩 페이지에 Latin 문자만 필요하다면 서브셋은 훨씬 작아질 수 있습니다.

일반적인 접근 방식은 두 가지입니다.

1. 폰트 제공자나 저장소에서 제공하는 사전 빌드된 서브셋을 사용합니다.
2. fonttools의 pyftsubset 같은 폰트 도구로 자체 서브셋을 생성합니다.

많은 팀에게는 사전 빌드된 Latin 서브셋으로 충분합니다. 맞춤 서브셋은 제한된 텍스트만 있는 단일 캠페인 페이지나 예측 가능한 문자 범위를 가진 제품 UI처럼 매우 제한적인 페이지에서 유용합니다.

다국어 사이트에서는 주의하세요. 누락된 글리프는 대체 폰트 혼합을 일으키며, 이는 깨져 보이고 가독성을 해칠 수 있습니다. 여러 언어를 지원한다면 하나의 아주 작은 서브셋을 모든 곳에 강제하지 말고, 언어별 경로에 폰트 서브셋을 매핑하세요.

Step 4: @font-face 규칙을 작성하세요

최소한의 로컬 설정은 다음과 같습니다.

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-600.woff2") format("woff2");
  font-weight: 600;
  font-style: normal;
  font-display: swap;
}

body {
  font-family: "Inter", system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

여기에는 몇 가지 중요한 세부 사항이 있습니다.

대부분의 콘텐츠 사이트에서는 font-display: swap을 사용하세요. 이는 브라우저가 대체 텍스트를 빠르게 표시한 다음 웹 폰트가 도착하면 교체하도록 지시합니다. 이렇게 하면 FOIT, 즉 보이지 않는 텍스트가 깜박이는 최악의 상황을 피할 수 있습니다.

명시적인 대체 폰트 스택을 설정하세요. 맞춤 폰트가 실패해도 사용자는 여전히 읽을 수 있는 텍스트를 받아야 합니다. 대체 폰트는 나중에 생각할 문제가 아니라 디자인의 일부입니다. 크기, 줄 길이, 본문 텍스트 선택을 다시 살펴봐야 한다면 현대 웹에서 읽기 좋은 글꼴을 위한 실용 가이드부터 시작하세요.

굵기를 올바르게 맞추세요. CSS가 font-weight: 500을 요청하지만 400과 700만 정의했다면 브라우저가 중간 굵기를 합성할 수 있습니다. 항상 끔찍한 것은 아니지만 일관되지 않아 보일 수 있습니다.

Step 5: 외부 Google Fonts 호출을 제거하세요

로컬 폰트 CSS를 추가한 뒤에는 템플릿에서 기존 원격 호출을 제거하세요.

다음을 찾아보세요.

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?..." rel="stylesheet">

또한 다음도 확인하세요.

• CMS 플랫폼의 테마 설정
• 페이지 빌더의 타이포그래피 패널
• 서드파티 위젯
• Tag managers
• @import url('https://fonts.googleapis.com/...') 같은 오래된 CSS import

마지막 항목은 흔합니다. 폰트용 CSS @import는 보통 발견을 지연시키기 때문에 성능에 더 나쁩니다. 자체 호스팅한다면 메인 CSS나 일찍 로드되는 폰트 CSS 파일에 폰트를 직접 정의하세요.

개인정보 보호 작업은 팀이 명백한 템플릿은 고치지만 스크립트, 위젯, 레거시 임베드를 놓치기 때문에 자주 실패합니다. 같은 패턴은 동의 관리 작업에서도 나타납니다. 더 넓게 서드파티 표면적을 줄이고 있다면 2026년에 쿠키에서 무엇이 바뀌었고 무엇을 해야 하는가 가이드가 유용한 동반 자료입니다.

Step 6: 캐시 헤더를 설정하세요

폰트 파일은 정적 자산입니다. 파일 이름에 버전이 있거나 콘텐츠 해시가 포함되어 있다면 강하게 캐시해야 합니다.

좋은 프로덕션 헤더는 다음과 같습니다.

Cache-Control: public, max-age=31536000, immutable

URL이 파일 변경 시 함께 바뀌는 경우에만 장기 immutable 캐싱을 사용하세요. 예를 들면 다음과 같습니다.

inter-latin-400.a8f3c2.woff2

또는 버전이 지정된 경로입니다.

/fonts/v2/inter-latin-400.woff2

URL을 바꾸지 않고 /fonts/inter-latin-400.woff2를 덮어쓰면 일부 사용자는 오랫동안 이전 파일을 유지할 수 있습니다. 문제가 되기 전까지는 괜찮습니다. 버전 지정은 이 문제를 피하게 해줍니다.

또한 올바른 MIME type으로 폰트를 제공하세요.

Content-Type: font/woff2

대부분의 최신 호스팅 플랫폼은 이를 자동으로 처리하지만, 확인할 가치가 있습니다.

Step 7: 중요한 폰트만 preload하는 것을 고려하세요

Preload는 브라우저가 중요한 폰트를 더 일찍 발견하는 데 도움이 될 수 있습니다.

<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin>

아껴서 사용하세요. 모든 폰트 굵기가 아니라 첫 화면에 보이는 주요 텍스트 폰트를 preload하세요. 과도한 preload는 CSS, 이미지, JavaScript와 경쟁합니다.

동일 출처 폰트라 해도 폰트 preload에는 crossorigin을 포함하세요. 폰트 가져오기는 CORS 모드를 사용하며, 이를 생략하면 일부 설정에서 중복 다운로드가 발생할 수 있습니다.

확실하지 않다면 테스트하세요. 체크리스트가 그렇게 말한다고 해서 preload를 무작정 따라 하지 마세요.

Step 8: 개인정보 보호와 성능을 테스트하세요

테스트는 간단합니다.

DevTools를 열고 캐시를 비활성화한 상태로 페이지를 다시 로드한 뒤 Network 패널에서 다음을 필터링하세요.

• fonts.googleapis.com
• fonts.gstatic.com
• .woff2
• font

자체 도메인에서 제공되는 폰트 파일이 보이고 Google Fonts 요청은 없어야 합니다.

그다음 cold cache와 warm cache에서 테스트하세요. 첫 방문에서는 폰트가 한 번 다운로드되어야 합니다. 이후 방문에서는 브라우저에 따라 메모리 또는 디스크 캐시에서 제공되어야 합니다.

폰트가 교체될 때 레이아웃 이동이 있는지 확인하세요. 제목이 튄다면 대체 폰트의 메트릭이 웹 폰트와 너무 다르다는 뜻입니다. 더 가까운 대체 폰트를 선택하거나 size-adjust, ascent-override, descent-override, line-gap-override 같은 최신 CSS 폰트 메트릭 오버라이드를 사용해 눈에 보이는 이동을 줄일 수 있습니다. 이는 더 고급 기능이지만 완성도 높은 인터페이스에 유용합니다.

마지막으로 private browsing이나 콘텐츠 차단기가 활성화된 상태에서 페이지를 테스트하세요. 자체 호스팅의 장점 중 하나는 개인정보 보호 도구가 타이포그래피를 실수로 차단할 가능성이 낮다는 점입니다.

피해야 할 흔한 실수

너무 많은 굵기를 호스팅하기

가장 흔한 실패입니다. 두 가지 굵기면 충분한 경우가 많습니다. 세 가지면 대체로 충분합니다. 강한 이유가 없다면 다섯 가지는 디자인 시스템의 냄새입니다.

이탤릭을 잊기

콘텐츠가 실제 강조를 사용한다면 진짜 이탤릭 파일을 로드하세요. 합성 이탤릭은 특히 긴 형식의 편집 콘텐츠에서 품질이 낮아 보일 수 있습니다.

기존 Google CSS 링크를 유지하기

이는 목적을 무너뜨립니다. 마이그레이션 후에는 다른 컴포넌트가 주입하지 않는 한 어떤 폰트 요청도 Google로 가서는 안 됩니다.

장기 캐싱 없이 폰트 제공하기

자체 호스팅은 제어권을 줍니다. 그것을 활용하세요. 폰트는 긴 캐시 수명에 이상적인 후보입니다.

법적 문서화 작업을 무시하기

개인정보 처리방침에 이전에 Google Fonts나 서드파티 폰트 로딩이 언급되어 있었다면 마이그레이션 후 업데이트하세요. 데이터 처리 인벤토리를 유지한다면 그것도 업데이트하세요. 기술적 변경과 컴플라이언스 기록은 서로 일치해야 합니다.

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

💡 이것을 시도해 보세요: Google Fonts에서 다운로드한 TTF 파일을 Webfont Generator를 사용해 자체 호스팅 가능한 WOFF2와 CSS로 변환하세요.

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

간단한 마이그레이션 체크리스트

1. 실제로 사용하는 폰트 패밀리, 굵기, 스타일, 스크립트를 나열합니다.
2. WOFF2 파일을 다운로드하고 라이선스를 확인합니다.
3. 사이트의 언어 요구사항이 제한적이라면 폰트를 서브셋합니다.
4. font-display: swap을 포함한 로컬 @font-face 규칙을 추가합니다.
5. 모든 Google Fonts link, preconnect, @import 참조를 제거합니다.
6. 장기 캐시 헤더와 함께 자체 도메인에서 폰트를 제공합니다.
7. 테스트 결과가 뒷받침하는 경우, 첫 화면에서 가장 중요한 폰트만 preload합니다.
8. DevTools에서 Google Fonts 요청이 남아 있지 않은지 확인합니다.
9. 필요한 경우 개인정보 보호 문서를 업데이트합니다.

폰트 자체 호스팅은 화려한 작업이 아닙니다. 의존성 위험을 줄이고, 개인정보 보호 수준을 높이며, 더 예측 가능한 렌더링을 제공하는 작은 인프라 정리 작업입니다. 보통 한두 시간을 들일 가치가 있습니다.