브라우저 탭에 사이트 로고가 나타나게 하다

뭘 했나

사이트의 고유한 파비콘(favicon)을 여러 형식으로 추가했다. favicon.ico, favicon.svg, favicon-32x32.png, apple-touch-icon.png, icon.png 등 다양한 규격의 아이콘 파일들을 public 디렉토리에 배치했다. 이제 사용자가 브라우저 탭에서 즐겨찾기를 할 때, 또는 모바일에서 홈 화면에 웹앱을 추가할 때 우리 사이트의 로고가 제대로 표시된다.

왜 이렇게 여러 형식이 필요한가

파비콘은 단순해 보이는 작업이지만 생각보다 복잡하다. 브라우저와 디바이스, OS마다 기대하는 형식이 다르기 때문이다. 예를 들어 데스크톱의 크롬은 favicon.ico를 우선으로 찾지만, 최신 브라우저들은 SVG나 WebP 같은 현대식 포맷을 더 잘 지원한다. iOS에서 홈 화면에 앱을 추가할 때는 apple-touch-icon.png가 있어야 하고, 안드로이드 PWA 환경에서는 icon.png를 참조한다.

작은 작업이지만 중요한 이유

처음에는 "그냥 로고 파일 몇 개 추가하는 건데 뭐하는 거야?" 라고 생각할 수 있다. 하지만 파비콘은 사용자가 매일 보는 곳이다. 브라우저 탭을 여러 개 열었을 때 우리 사이트를 한눈에 찾을 수 있게 하고, 즐겨찾기 폴더에서 시각적으로 구분되게 만든다. 모바일에서 홈 화면에 웹앱을 추가했을 때도 기존 네이티브 앱처럼 우리 로고가 떠있으면, 사용자 입장에서는 "이 서비스를 충분히 소중히 여기는구나" 라는 느낌을 받는다.

이건 UX에서 말하는 "작은 디테일이 쌓여서 브랜드 신뢰도를 만든다"는 원칙과 맞닿아 있다. 요청 없이 먼저 챙기는 작업이기 때문에, 그리고 사용자는 이걸 당연하게 받아들이지만 없으면 바로 느낀다. 즉 디자인팀과의 협의, 여러 디바이스에서의 테스트, 호환성 검증이 필요한 일이었다.

이런 류 작업에서 배운 점

비슷한 정적 자산(스크린샷, 로고, 메타 이미지) 추가 작업을 할 때 마다 항상 "어느 형식까지 필요한가"를 먼저 물어본다. 예를 들어 Open Graph 이미지 하나 추가할 때도 PNG와 JPG 두 가지를 제공하거나, 다크 모드 대응 로고가 필요한지 확인한다. 또한 홈 화면 구성 파일(web app manifest)을 이미 갖춘 프로젝트라면, 그 매니페스트에 정의된 icon 경로와 크기 규격을 먼저 읽는다. 그래야 일관성 있게 여러 형식을 배치할 수 있다.

이번 작업을 통해서 한 가지 더 깨달은 건, 파비콘 같은 "작아 보이는" 작업도 팀과 제때 공유해야 한다는 점이다. 디자인팀이 로고를 최근에 리뉴얼했다면, 이 파비콘 업데이트가 그 리뉴얼의 일부인지 아닌지 확인할 필요가 있다. 또는 마케팅팀이 특정 캠페인을 위해 임시 파비콘을 원한다면 스케줄링해야 한다. 작은 작업일수록 커뮤니케이션 채널을 놓치기 쉽다.

다음엔 비슷한 "정적 자산 추가" 작업이 들어올 때, 체크리스트를 준비해서 돌려야겠다. 어떤 형식이 필요한지, 각 형식의 크기는 얼마인지, 성능 최적화(WebP 변환이나 SVG 압축)가 필요한지, 캐싱 정책은 어떻게 할지 등을 미리 정하고 시작하는 방식으로.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 책상조명 쿠팡에서 보기 →

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