북마크·탭·홈 화면에서 통일된 브랜드 이미지 구현
목차
사이트 파비콘을 드디어 적용했다. 언뜻 간단해 보이는 작업이지만, 해보니 생각보다 많은 포맷과 고려사항이 있었다. 무엇보다 이 "작은" 기능이 사용자가 매일 만나는 인터페이스 곳곳에 나타난다는 게 흥미로웠다.
파비콘, 작아도 영향은 크다
파비콘의 역할을 생각해보면, 우리가 하루에도 몇십 개의 탭을 열고 닫으면서 각 사이트를 빠르게 식별하려고 한다. 그때 작은 아이콘이 "우리 사이트"를 즉시 알아볼 수 있게 한다. 또 북마크 폴더를 넘겨보거나, 스마트폰 홈 화면에 웹앱을 고정했을 때도 파비콘이 방문하기 쉽게 한다.
개발팀 입장에서는 "도메인 설정"에 불과해 보이지만, 사용자 경험 관점에서는 매번 방문할 때마다 마주치는 시각적 신호다. 로고만큼 중요한 정체성 요소인 셈이다. 그런데 왜 이런 "기본" 작업이 자주 미뤄질까? 아마도 기능이 없어도 서비스가 동작하기 때문이고, 초기 개발 단계에서 우선순위가 낮기 때문일 거다. 하지만 서비스가 어느 정도 궤도에 올라서면 이런 "마무리" 작업들이 전체 인상을 크게 바꾼다.
여러 포맷, 여러 환경을 위한 설계
파비콘 구현이 복잡한 이유는 단순하다—기기와 브라우저마다 요구하는 포맷이 다르기 때문이다. 이번 커밋에 포함된 파일들의 역할:
| 파일명 | 용도 | 특징 |
|---|---|---|
| favicon.ico | 기본 호환성 | IE, 구형 브라우저 자동 탐색 |
| favicon.svg | 모던 환경 | 벡터 포맷, 모든 해상도에 대응 |
| favicon-32x32.png | 브라우저 탭 | 표준 사이즈 PNG |
| apple-touch-icon.png | iOS 홈 고정 | Safari 웹 클립, 180×180px |
| icon.png | PWA 매니페스트 | 웹앱 런처 아이콘 |
각 파일의 선택 이유가 명확했다:
- favicon.ico: 여전히 많은 레거시 환경이 존재한다. <head>에 명시하지 않아도 브라우저가 자동으로 찾는 표준 위치.
- favicon.svg: 해상도 무관하게 깔끔하게 표시되는 벡터 포맷. 모던 브라우저의 첫 선택지.
- favicon-32x32.png: 브라우저 탭의 사실상 표준 크기. 비트맵이지만 명확한 규격.
- apple-touch-icon.png: iOS에서 웹 클립으로 고정할 때 보이는 아이콘. 180×180px가 권장 사이즈.
- icon.png: PWA 매니페스트에서 참조. 다양한 크기로 여러 기기를 지원.
이 과정에서 배운 건, "표준"이라는 게 매우 세분화되어 있다는 거다. 각 OS, 각 브라우저가 기대하는 포맷이 다르고, 그걸 모두 커버해야 사용자가 어떤 환경에서든 일관된 경험을 얻는다.
HTML 메타데이터와 호환성 체크리스트
파일만 있다고 끝이 아니다. HTML <head> 섹션에 올바른 링크와 메타데이터를 추가해야 한다:
<!-- 기본 파비콘 (우선순위: 위에서부터) -->
<link rel="icon" type="image/svg+xml" href="/favicon.svg" />
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png" />
<link rel="icon" type="image/x-icon" href="/favicon.ico" />
<!-- iOS 호환성 -->
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />
<!-- PWA 매니페스트 -->
<link rel="manifest" href="/manifest.json" />
브라우저는 이 목록을 위에서부터 읽으면서 자신이 지원하는 첫 번째 포맷을 선택한다. 따라서 순서도 중요하다—대체로 최신 포맷(SVG) → 표준 포맷(PNG) → 폴백(ICO) 순으로 나열해서 모던 환경부터 레거시까지 모두 커버하는 방식이 일반적이다.
캐싱: 아는 함정
실제 구현 후 마주친 고민이 하나 있다면, 캐싱 정책이다. 파비콘은 기본적으로 브라우저가 매우 강하게 캐시하는 리소스다. 한 번 다운로드된 후에는 거의 재요청하지 않는다. 이게 의도한 것일 때는 좋지만, 브랜드 리뉴얼이나 파비콘 변경이 필요할 땐 문제가 된다. 기존 방문자의 브라우저 캐시에 오래된 파비콘이 남아있을 수 있기 때문이다.
해결책은 몇 가지다. 첫째, 파일명에 버전을 포함하는 방식(예: favicon-v2.svg), 둘째, HTML에서 메타데이터에 타임스탬프나 해시를 붙이는 방식, 셋째, CDN이나 서버의 캐시 헤더를 직접 제어하는 방식이다. 이번 초기 적용에선 신경 쓰지 않았지만, 향후 변경이 생기면 반드시 기억해야 할 포인트다.
팀 리딩, "완성도"를 어디에서 찾을 것인가
개인적으로 이 작업을 회고하면, "작은 개선의 누적 효과"를 다시금 느꼈다. 기능적으로는 이미 서비스가 완벽하게 동작하고 있었다. 그런데 사용자가 매번 방문할 때마다 마주치는 브라우저 탭에 사이트 고유의 아이콘이 없었다. 이게 얼마나 큰 차이를 만들까? 정량화하기는 어렵지만, 누적되면 "세련됨"과 "미흡함" 사이의 간극을 만든다.
팀을 이끌 때 항상 고민하는 부분이 우선순위 결정이다. 긴급 버그, 새로운 기능 개발, 성능 최적화 같은 "눈에 띄는" 작업들에 시간이 먼저 간다. 하지만 이런 "보이지 않지만 누적되면 중요한" 개선들을 주기적으로 점검하고 처리하는 태도가 결국 서비스의 완성도를 결정한다. 그래서 스프린트 계획에서도 "기술 부채 처리", "세세한 UX 개선" 같은 항목을 의도적으로 배치하는 게 중요하다.
다음 번엔, PWA 전체 구성(manifest.json, service worker 등)을 한 번에 정리하고, 여러 기기에서 실제 렌더링을 QA 체크리스트에 추가해야겠다는 생각이 든다. 작은 것일수록 일관성 있게 관리해야 서비스가 "만들어져 있는" 느낌이 난다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.