폰트 로딩 404 에러 콘솔 노이즈 제거

한 가지 작은 외웠던 문제를 고쳤다. 콘솔에 계속 떠오던 Pretendard 폰트 로딩 404 에러를 제거했다. GitHub CDN에서 npm CDN으로 경로를 바꾼 것인데, 꽤 흥미로운 소재다. 사소한 변경 같지만 여기에는 CDN 선택의 트레이드오프, 의존성 버전 관리, 그리고 런타임 에러 추적이 엮여 있다.

문제: 왜 404가 났을까

처음에는 그냥 "폰트가 안 로드되네?"라고만 생각했다. 브라우저 DevTools를 열어보니 Pretendard 폰트 요청이 계속 실패하고 있었다. 콘솔을 확인해 보니 GitHub Pages CDN에서 404를 던지고 있었다. 당시 설정은 Pretendard v1.3.9를 GitHub 저장소의 배포 폰트로 직접 가져가도록 되어 있었는데, 정확히는 woff2 포맷이 그 경로에 없었던 것이다.

여기서 생각해볼 점이 있다. 왜 GitHub CDN을 선택했을까? 아마 초기에는 합리적인 판단이었을 거다. GitHub 레포지토리에서 직접 가져가면 외부 npm CDN에 의존할 필요가 없고, 라이센스나 버전 관리도 명시적이다. 하지만 v1.3.9 버전이 업데이트되면서 배포 구조가 바뀌었고, 우리가 사용하는 woff2 파일이 더 이상 GitHub 경로에 있지 않게 된 것이다.

해결: npm CDN으로 전환

결국 npm CDN(unpkg 또는 jsDelivr)으로 경로를 변경했다. npm 레지스트리의 Pretendard 패키지는 항상 최신 버전을 그대로 제공하고, 모든 포맷(woff2, woff)이 일관되게 관리된다. 이 변경이 미친 영향은 작지만 중요했다:

변경된 파일은 두 곳이었다 — public/styles.css와 styles.css. 경로만 바뀌면 되는 간단한 작업이었지만, 그래도 두 파일 모두 일관되게 업데이트해야 했다. 만약 한쪽만 바꿨다면 나중에 배포 환경에서 또 다른 404를 마주칠 뻔했을 것이다.

회고: 작은 fix에서 배운 것

이 작은 수정에서 몇 가지 배운 점이 있다.

첫째, 외부 CDN 의존성은 "정적"이 아니다. 우리가 외부 리소스(CDN, 라이브러리)를 쓸 때 흔히 "한 번 설정하면 계속 된다"고 가정한다. 하지만 패키지 버전이 업데이트되면 배포 구조, 디렉토리 레이아웃, 심지어 파일 포맷까지 바뀔 수 있다. 특히 GitHub CDN처럼 레포지토리 구조에 직결된 방식은 더 취약하다. 그래서 npm 같은 표준 호스팅이 더 안정적이다.

둘째, 콘솔 에러는 무시하기 쉽지만 중요하다. 개발팀 관점에서 보면, 404 에러 한두 개는 "사용자 기능에 문제 없으니까 괜찮다"고 넘어가기 십상이다. 그런데 이렇게 쌓인 에러들이 나중에 실제 버그를 찾기 어렵게 만든다. 콘솔이 깨끗하다는 것은 "정말 심각한 에러를 빨리 찾을 수 있다"는 뜻이다. 그리고 이건 코드 리뷰할 때도 자주 지적하는 지점이다.

셋째, 비슷한 상황은 반복된다. 폰트뿐만 아니라 아이콘 라이브러리, UI 프레임워크, 심지어 분석 스크립트까지 모두 외부 CDN에 의존한다. 한 번 정책을 정하면 그걸 따라가는 게 훨씬 효율적이다. "GitHub에서 가져오기", "npm 레지스트리 사용", "자체 호스팅" 같은 결정을 팀 차원에서 통일하면, 매번 이렇게 작은 문제로 일일이 손을 댈 필요가 없어진다.

마무리: 번들 크기와 성능

하나 더 확인할 만한 것은 npm CDN으로 바뀌면서 번들 크기나 로딩 시간이 실제로 달라졌는가였다. Pretendard는 이미 작은 폰트 패키지라 큰 차이는 없지만, 원칙적으로 npm CDN(jsDelivr, unpkg)은 여러 지역에 캐시되어 있어 대개 더 빠르다. GitHub Pages는 GitHub의 인프라에만 의존하기 때문이다.

결국 이 fix는 "폰트 404를 없앤다"는 당면한 목표를 넘어, CDN 선택의 근거를 다시 정리하고 팀에서 비슷한 외부 의존성을 어떻게 관리할지 생각해 보는 계기가 되었다.

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

• 기계식키보드 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

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