폰트 로드 실패로 콘솔 404 에러 제거

Pretendard 폰트를 GitHub CDN에서 npm CDN으로 변경하는 작업을 했다. v1.3.9 버전의 GitHub CDN에 woff2 파일이 없어서 계속 브라우저 콘솔에 404 에러가 찍히던 문제를 해결한 것.

배경: 보이지 않아도 방치하면 안 되는 문제

개발자 관점에서 브라우저 콘솔 에러는 무해해 보일 수 있다. 사용자한테 보이지 않으니까. 근데 이런 에러들을 방치하면 여러 문제가 생긴다.

첫째, 개발 중 신호-대-잡음 비율이 떨어진다. 진짜 버그가 있을 때 콘솔을 열어봐도 404 에러들이 잔뜩 출력되어 있으면 중요한 에러를 찾기 어렵다. 팀원들이 디버깅할 때 첫 관찰 포인트인 콘솔 상태를 깔끔하게 유지하는 건 개발 생산성에 영향을 준다.

둘째, 의존성 관리의 습관 문제다. CDN URL이 응답하지 않는다는 건 그 버전/경로에 실제로 파일이 없다는 뜻이고, 이런 식으로 방치하면 나중에 라이브러리 업그레이드나 마이그레이션 때 "어라, 이게 왜 또 안 되지?" 하는 상황을 반복하게 된다.

셋째, 콘솔 에러는 번들 분석 도구의 노이즈가 된다. 나중에 lighthouse 같은 성능 분석이나 모니터링 데이터를 보면 "리소스 로드 실패"라는 항목이 통계에 섞인다. 작은 에러라도 정리하면 진짜 성능 문제와 구분하기 쉬워진다.

해결: CDN 전환

public/styles.css의 폰트 import 경로를 변경했다:

/* Before: GitHub CDN 사용 (실패) */
@import url('https://cdn.jsdelivr.net/gh/...');

/* After: npm CDN 사용 */
@import url('https://cdn.jsdelivr.net/npm/...');

간단해 보이지만 이 한 줄 변경으로 여러 게 나아진다. 폰트 로드 체인이 성공하고, 콘솔이 깔끔해지고, CDN 캐싱도 더 안정적이 된다.

회고: CDN 버전 관리 패턴

비슷한 상황을 여러 번 봤는데, CDN 의존성을 관리할 때 팀에서 자주 실수하는 게 몇 가지 있다:

1. 버전 고정과 추적의 불명확함
- 라이브러리 버전을 명시적으로 명시하는 게 좋다. npm/[email protected]/dist/... 같은 형태로.
- CDN URL이 버전 없이 latest 같은 경로를 사용하면 나중에 "어떤 버전이 실제로 로드되고 있지?"를 추적하기 어렵다.

2. 여러 CDN 제공자의 동작 차이
- GitHub CDN(gh)과 npm CDN은 같은 패키지여도 다르게 빌드되거나 파일이 빠질 수 있다.
- 팀에서 사용하는 폰트나 라이브러리는 한 가지 CDN 제공자로 고정하고, 정기적으로 (예: 분기마다) 실제로 로드되는지 검사하는 게 좋다.

3. 콘솔 클린 상태 유지의 팀 문화
- 이런 식의 경고/에러를 그때그때 치워두면 나중에 진짜 문제가 생겼을 때 팀원들이 빠르게 반응할 수 있다.
- 코드리뷰할 때 "콘솔에 에러 있나?" 체크를 루틴으로 삼는 것도 좋은 습관이다.

작은 fix처럼 보이지만, 개발 환경의 신호 정제, 의존성 명확화, 팀의 관찰 능력 유지 같은 여러 문제를 한 번에 푸는 변경이었다.

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

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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