브라우저가 잘못된 Favicon을 선택하나요? 개발자를 위한 진짜 해결법

favicon을 업데이트하고 새 파일을 배포한 뒤 페이지를 새로고침했는데도 브라우저가 여전히 잘못된 아이콘을 표시합니다. 6개월 전의 오래된 로고, 다른 사이트의 아이콘, 또는 아예 표시될 이유가 없는 흐릿한 일반 placeholder일 수도 있습니다.

이는 개발자들이 겪는 가장 흔한 favicon 관련 골칫거리 중 하나입니다. 파일은 서버에 존재하고 HTML 태그도 올바르게 작성되어 있습니다. 그럼에도 브라우저는 잘못된 favicon 자원을 선택하고 실제 배포된 파일은 무시합니다.

먼저 간단한 해결 방법을 제시하고, 그다음 왜 이런 문제가 발생하는지 설명하겠습니다.

2분 만에 해결하는 빠른 수정

"잘못된 favicon" 증상의 대부분은 단 하나의 근본 원인, 즉 browser precedence(브라우저 우선순위)로 귀결됩니다. 여러 아이콘 출처가 존재할 때 브라우저는 엄격한 조회 순서를 따르며, 충돌이 발생하면 그 결과가 우선 적용됩니다.

먼저 다음 체크리스트를 실행해 보세요.

사이트 루트에 있는 /favicon.ico를 모두 삭제합니다. 많은 브라우저에서 HTML 선언보다 이 파일이 우선 적용됩니다.
<head>에 적절한 sizes와 type 속성을 가진 명시적인 rel="icon" 태그를 추가합니다.
캐시 무효화용 query string(예: ?v=2)을 추가하여 브라우저가 새 파일을 다시 가져오도록 강제합니다.
Ctrl+Shift+R로 하드 리로드를 수행하거나, 잘 해결되지 않는 경우에는 favicon cache clear guide를 참고하시기 바랍니다.

이 방법으로 해결되었다면 작업을 마쳐도 됩니다. 그렇지 않다면 우선순위 충돌 때문에 브라우저가 잘못된 favicon 파일을 선택하고 있는 것이므로, 이제 보다 심층적인 진단을 시작합니다.

브라우저가 잘못된 아이콘을 선택하는 이유

브라우저는 HTML을 무조건 신뢰하지 않습니다. HTML 명세에 정의된 조회 순서를 따르며, 불일치가 발생하면 그 결과가 덮어쓰여집니다.

1. /favicon.ico 함정

사이트 루트에 기존 favicon.ico가 남아 있는 상태에서 HTML에 최신 <link rel="icon"> 태그를 함께 배포하면, 브라우저는 ico 파일을 우선적으로 선택하는 경우가 많습니다. 많은 브라우저는 다른 아이콘이 선언되어 있지 않을 때 자동으로 /favicon.ico를 요청하며, 해당 파일이 존재하면 이를 신뢰 가능한 자원으로 취급합니다.

해결 방법: 루트의 favicon.ico를 삭제하거나, 정확한 sizes 속성을 가진 link 태그를 통해 명시적으로 제공하여 브라우저가 파일의 정체를 알 수 있도록 합니다.

2. sizes 속성 누락 또는 오류

sizes 속성은 각 아이콘 파일의 해상도를 브라우저에 알려줍니다. 이 속성이 없으면 브라우저가 16x16 PNG를 32x32 크기로 업스케일하여 표시할 수 있으며, 이로 인해 모두에게 거부감을 주는 픽셀화된 결과물이 만들어집니다.

항상 다음과 같이 명시적으로 선언하시기 바랍니다.

<link rel="icon" type='image/png' sizes='32x32' href='/icons/favicon-32x32.png'>
<link rel='icon' type='image/png' sizes='16x16' href='/icons/favicon-16x16.png'>

HTML 명세는 rel="icon"을 사이트 아이콘 선언의 표준 방식으로 규정합니다. 정확한 파싱 규칙은 WHATWG HTML Living Standard를 참고하시기 바랍니다.

3. type 속성 충돌

type="image/svg+xml"으로 선언했지만 실제로 제공되는 파일이 PNG이거나, 그 반대인 경우 브라우저는 해당 파일을 완전히 건너뛰고 사용 가능한 다른 자원(캐시에 남아 있는 오래된 버전을 포함)으로 fallback할 수 있습니다.

MIME 타입이 실제와 일치하는지 확인하시기 바랍니다. 흔한 버그 중 하나는 파일 확장자와 HTML 속성은 SVG라고 명시되어 있더라도 CDN이 image/png로 응답하는 경우입니다.

4. Web App Manifest 오버라이드

사이트에 자체 icons 배열을 가진 site.webmanifest가 있으면, 특히 모바일과 "홈 화면에 추가" 흐름에서 브라우저가 HTML link 태그보다 manifest의 아이콘을 우선 적용할 수 있습니다.

/site.webmanifest를 점검하여 icons 배열이 HTML에서 선언한 파일과 동일한 파일을 가리키는지 확인하시기 바랍니다. sizes나 형식이 일치하지 않으면 플랫폼별 로직에 따라 브라우저가 잘못된 favicon 자원을 선택하게 됩니다.

5. CDN 및 엣지 캐시 지연

Cloudflare, Fastly 등 유사 CDN은 정적 자원을 적극적으로 캐시합니다. 배포 이후에도 엣지 노드에서는 수 시간 내지 수 일 동안 이전 favicon을 계속 제공할 수 있습니다.

배포 후마다 CDN의 /favicon.ico, /icons/*, /site.webmanifest 경로에 대한 캐시를 비우시기 바랍니다. 그렇지 않으면 엣지 캐시의 만료 지연 때문에 브라우저가 잘못된 favicon 파일을 선택하게 됩니다.

6. Service Worker 함정

Service worker는 브라우저의 HTTP 캐시와는 독립적으로 favicon 응답을 캐시할 수 있습니다. PWA가 첫 설치 시 아이콘을 캐시하면, service worker가 업데이트될 때까지 사용자는 계속해서 이전 버전을 보게 됩니다.

service worker 버전을 올리고, href 값에 캐시 무효화용 query string을 추가하시기 바랍니다. 파일명에 버전을 포함하는 방식이 더 안전합니다.

예방: 견고한 아이콘 스택 구축하기

즉시 발생한 문제를 해결한 후에는 향후 "잘못된 favicon" 사고를 방지하기 위해 구성을 강화하시기 바랍니다.

단일 출처(Single source of truth): 적절한 favicon 생성 워크플로를 활용하여 하나의 소스 파일에서 모든 아이콘을 생성합니다.
일관된 명명 규칙: 사이트 루트가 아닌 전용 /icons/ 디렉터리를 사용합니다.
배포 시 캐시 무효화: 빌드 파이프라인에서 파일명을 해시 처리(예: favicon-abc123.png)하여 기존 캐시에 더 이상 도달하지 못하도록 합니다.
정기적인 감사: 주요 릴리스 전에 여러 브라우저에서 간단한 감사를 수행합니다.
시크릿 창에서 테스트: 시크릿 창은 대부분의 캐시 계층을 우회하므로 실제 결과를 확인할 수 있습니다.

마무리

브라우저가 잘못된 favicon 파일을 선택할 때, 이는 거의 임의적인 결과가 아닙니다. 고려하지 못한 우선순위 규칙을 따르거나, 무효화하지 않은 캐시에서 자원을 가져오거나, 실제 제공되는 파일과 일치하지 않는 type 속성을 읽은 결과입니다.

루트의 favicon.ico를 제거하고, 올바른 sizes와 type을 가진 명시적인 link 태그를 선언하며, manifest를 동기화 상태로 유지하고, 배포마다 캐시를 비우시기 바랍니다. 이 순서대로 진행하면 대부분의 "잘못된 favicon" 사례가 해결되며, 남는 엣지 케이스는 보통 몇 분 안에 DevTools로 디버깅 가능한 CDN 또는 service worker 함정으로 귀결됩니다.