개발 slecs

폰트 로딩 CDN 404 에러 제거로 콘솔 정리

목차

웹 서비스를 운영하다 보면 브라우저 콘솔에 남는 작은 에러들이 쌓인다. 이번엔 폰트 라이브러리의 CDN 경로 문제로 발생하는 404 에러를 정리했다.

문제: 폰트 파일이 없다?

public/styles.css에서 Pretendard 폰트를 GitHub CDN을 통해 로딩하고 있었는데, 개발자 도구 콘솔을 열어보니 woff2 파일에 대한 404 에러가 계속 떨어지고 있었다. v1.3.9 버전을 명시했지만, GitHub에 호스팅된 그 버전엔 실제로 woff2 파일이 없었던 것.

전형적인 "의존성 호스팅 선택 실패"의 사례였다. 폰트 같은 글로벌 리소스는 CDN을 통해 배포되는데, 어느 CDN을 신뢰할 것인가 하는 판단이 중요하다. GitHub의 raw.githubusercontent.com은 일관성이 보장되지 않을 수 있고, npm registry를 기반으로 하는 CDN은 버전 관리가 더 엄격하다.

해결: npm 기반 CDN으로 전환

Pretendard는 npm package로도 배포되고 있으니, GitHub 대신 npm을 기반으로 하는 CDN 경로로 바꿨다. 이렇게 하면:

  • npm registry에 등록된 패키지의 파일 구조를 신뢰할 수 있다
  • 버전 태그가 명확해서 특정 버전의 모든 파일이 일관되게 존재한다
  • 엣지 캐싱도 더 효율적이다

변경 내용은 단순했다. public/styles.css의 CDN 경로 한두 줄을 수정하는 것으로 끝.

/* Before: GitHub CDN */
@import url('https://cdn.jsdelivr.net/gh/orioncactus/[email protected]/dist/...');

/* After: npm registry 기반 */
@import url('https://cdn.jsdelivr.net/npm/[email protected]/dist/...');

콘솔 에러의 무게

한 줄의 404 에러처럼 보일 수 있지만, 이런 작은 에러들이 쌓이면:

관점 영향
개발자 경험 콘솔이 깨끗하지 않으면 실제 버그를 놓치기 쉬움
프로덕션 신뢰도 사용자의 브라우저에서도 같은 에러가 쌓이면 앱 안정성 신호 약해짐
성능 지표 실패한 네트워크 요청이 누적되면 성능 저하 가시화
사용자 경험 폰트 로딩 실패 → FOUT/FOIT (순간적 텍스트 렌더링 변화)

특히 폰트 로딩 실패는 사용자에게 보이는 문제다. 404로 폰트가 안 오면 폰트스택의 대체 폰트로 넘어가거나 시스템 폰트로 렌더링되는데, 순간적인 시각 깜빡임을 경험하게 된다. 완벽하게 막을 순 없지만, 적어도 "폰트 CDN이 깨졌구나"라는 신호를 빨리 캐치할 수 있어야 한다.

CDN 선택의 베스트 프랙티스

오픈소스 라이브러리를 CDN으로 로딩할 때는:

  • 공식 배포 채널 우선: npm은 공식 package.json 기반, GitHub raw는 사실상의 CDN이 아님
  • 버전 관리 일관성 확인: 특정 버전을 명시했을 때, 그 버전의 모든 파일이 실제로 존재하는지 한 번은 확인
  • 폴백 전략 수립: 폰트 로딩 실패 시 무조건 사용자에게 영향이 가지 않도록 font-display: swap/fallback, @supports 등으로 방어
  • CDN 신뢰성 평가: 무료 CDN도 많지만, 서비스 중요도에 따라 자체 호스팅이나 유료 CDN 고려

이번 수정은 작은 핀포인트였지만, 점진적으로 의존성 관리를 정리하는 과정의 일환이다. 팀에서도 마찬가지로 글로벌 리소스(폰트, 아이콘, 라이브러리)의 CDN 전략을 함께 검토하기로 했다. 콘솔이 깨끗한 것은 단순히 심미적인 문제가 아니라, "이 서비스가 잘 관리되고 있다"는 신호를 주는 것 같다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.