디버깅 중에 20개의 탭을 열어둔 적이 있다면, 원하는 탭을 찾는 것이 얼마나 고통스러운지 아실 겁니다. GitHub는 이 문제를 아주 훌륭하게 해결합니다. 메인 대시보드에는 표준 검은 고양이 아이콘이 있지만, 알림 페이지로 넘어가면 파비콘이 파란색 수신함으로 바뀝니다. Google Workspace도 마찬가지입니다. 같은 도메인 아래에서 Docs는 파란색, Sheets는 초록색 아이콘을 사용하죠.
이러한 미묘한 시각적 단서가 바로 multiple favicons different pages (페이지별 다중 파비콘) 설정이 엄청난 UX 업그레이드인 이유입니다. 잘려나간 탭 제목을 읽지 않고도 사용자가 현재 어디에 있는지 정확히 알려줍니다.
우리는 보통 사이트 아이콘을 루트 디렉토리에 존재하는 전역 자산으로 생각합니다. 하지만 브라우저는 사실 여러분의 루트 디렉토리에는 관심이 없습니다. 브라우저가 신경 쓰는 것은 문서 헤드에 있는 <link> 태그뿐입니다. 2026년 현재, 순수 HTML을 작성하든 최신 프레임워크를 사용하든 라우트별로 다른 아이콘을 제공하는 정확한 방법을 보여드리겠습니다.
왜 라우트별로 아이콘을 다르게 해야 할까요?
아마 이렇게 생각하실 수도 있습니다. '우리 브랜드 로고는 하나인데, 왜 그걸 파편화해야 하지?'
맥락이 전부입니다. 사용자가 공개된 마케팅 사이트를 탐색할 때는 브랜드를 평가하는 중입니다. 거기서는 표준 로고가 완벽하게 작동합니다. 하지만 복잡한 SaaS 애플리케이션에 로그인하고 나면, 그들의 맥락은 '평가'에서 '생산성'으로 바뀝니다.
한 탭에는 문서를, 다른 탭에는 결제 포털을, 세 번째 탭에는 메인 앱을 열어두었다면, 단일 로고는 사용자가 탭의 작은 글씨를 읽어가며 탐색하도록 강요합니다. 페이지별로 다른 파비콘을 활용하면 시각적인 지도를 만들 수 있습니다. 관리자 패널의 로고 배경을 흰색에서 짙은 파란색으로 바꾸는 것과 같은 미묘한 색상 변화만으로도 인지 부하를 즉각적으로 줄일 수 있습니다.
페이지별로 다른 파비콘을 설정하는 방법
1단계: 에셋 폴더 정리하기
코드를 건드리기 전에, 모든 것을 public 루트에 쏟아붓는 것부터 멈추세요. 마케팅 사이트와 관리자 대시보드가 있다면 두 개의 독립적인 아이콘 세트가 필요합니다. Mzu favicondl을 사용하여 세트를 생성하고 전용 하위 디렉토리에 배치하는 것을 권장합니다.
/public
/icons
/marketing
favicon.ico
icon.svg
apple-touch-icon.png
/dashboard
favicon.ico
icon.svg
apple-touch-icon.png이렇게 하면 경로가 깔끔하게 유지되고 브랜딩을 업데이트할 때 실수로 덮어쓰는 일을 방지할 수 있습니다.
2단계: 정적 HTML 방식
정적 사이트를 구축하거나 전통적인 템플릿 엔진(Blade나 Jinja 등)을 사용하는 경우, 레이아웃 파일에서 경로만 교체하면 됩니다. 브라우저는 HTML을 위에서 아래로 파싱하고 href 속성에 지정된 것을 요청합니다.
마케팅 페이지의 경우 <head>는 다음과 같아야 합니다.
<link rel='icon' href='/icons/marketing/icon.svg' type='image/svg+xml'>
<link rel='apple-touch-icon' href='/icons/marketing/apple-touch-icon.png'>대시보드 페이지의 경우 다른 레이아웃 블록을 렌더링합니다.
<link rel='icon' href='/icons/dashboard/icon.svg' type='image/svg+xml'>
<link rel='apple-touch-icon' href='/icons/dashboard/apple-touch-icon.png'>올해 필요한 정확한 태그를 다시 확인하고 싶다면 파비콘 HTML 코드 치트 시트를 확인해 보세요.
3단계: Next.js App Router 방식
최신 프레임워크는 이 작업을 믿을 수 없을 정도로 우아하게 만듭니다. Next.js (App Router)에서 메타데이터는 라우트 세그먼트에 범위가 지정됩니다. 사용자 정의 문서 헤드를 작성하거나 태그를 수동으로 주입할 필요가 없습니다.
전역 favicon.ico 파일에 의존하는 대신, 특정 page.tsx 또는 layout.tsx 파일에서 메타데이터 객체를 내보냅니다.
// app/dashboard/layout.tsx
export const metadata = {
title: 'Admin Dashboard',
icons: {
icon: '/icons/dashboard/icon.svg',
apple: '/icons/dashboard/apple-touch-icon.png',
},
};Next.js는 루트 레이아웃에 정의된 전역 아이콘을 재정의하여 /dashboard 아래의 모든 라우트에 대해 이러한 특정 태그를 자동으로 주입합니다. 이것이 React 애플리케이션에서 페이지별 다중 파비콘을 처리하는 가장 깔끔한 방법입니다.
피해야 할 일반적인 함정
- 강력한 브라우저 캐시: 페이지별 새 아이콘을 배포했는데 Chrome이 고집스럽게 예전 전역 로고를 보여줍니다. 브라우저는 파비콘을 매우 강력하게 캐시합니다. 개발 중에 이 문제를 해결하려면 아이콘 경로에 쿼리 문자열을 추가하세요(예:
href='/icons/dashboard/icon.svg?v=2'). 그래도 해결되지 않는다면 파비콘 캐시 지우기 가이드를 읽어보세요. - 웹 앱 매니페스트 충돌:
site.webmanifest파일은 사용자가 사이트를 PWA로 설치할 때 사용되는 아이콘을 정의합니다. HTML 태그와 달리 매니페스트는 일반적으로 전역적입니다. 사용자가 대시보드를 설치하더라도 Android는 여전히 루트 매니페스트에 정의된 마케팅 아이콘을 사용할 수 있습니다. 라우트에 따라 동적 매니페스트를 제공하거나 앱 섹션에 대해 별도의<link rel='manifest' href='/dashboard.webmanifest'>태그를 사용하세요. - JavaScript로 과도하게 복잡하게 만들기: 라우트 변경 시 DOM을 조작하고 아이콘을 교체하기 위해 복잡한 React
useEffect훅을 작성하는 개발자들을 봅니다. 실시간 알림 배지를 구축하는 것이 아니라면 이렇게 하지 마세요. 정적인 라우트 기반 아이콘의 경우 프레임워크의 네이티브 메타데이터 API나 서버 렌더링 HTML에 의존하세요. 그것이 더 빠르고 안정적이며 페이지 로드 시 시각적인 깜박임을 유발하지 않습니다.
페이지별로 다른 아이콘을 설정하는 데는 약 10분의 구성 시간이 걸리지만, 앱의 수명 주기 동안 사용자가 탭을 찾느라 겪는 좌절감을 몇 시간이나 줄여줍니다. Mzu favicondl로 특정 아이콘 세트를 생성하고 폴더를 정리한 다음, 나머지는 HTML에 맡기세요.