웹사이트를 만들 때 파비콘은 늘 사소해 보입니다. 하지만 제대로 챙기려면 favicon.ico, apple-touch-icon.png, PWA용 manifest.webmanifest, 192px/512px PNG, maskable icon처럼 생각보다 많은 파일과 링크 태그가 필요합니다.
먼저 결론부터 말하면, 파비콘 생성은 온라인 생성기를 매번 찾아갈 일이 아니라 프로젝트 안의 작은 CLI 작업으로 남겨둘 만합니다. 긱뉴스에 올라온 make-favicon.zsh ↗는 이 반복 작업을 ImageMagick 기반 스크립트로 정리한 좋은 예입니다.
이 글에서 다루는 내용:
- 파비콘 생성이 왜 생각보다 귀찮은 작업인지
make-favicon.zsh가 어떤 파일을 만들어주는지- 이런 작은 자동화를 프로젝트에 넣을 때 얻는 이점
왜 필요한가?
파비콘은 브라우저 탭에 보이는 작은 이미지 하나처럼 느껴집니다. 하지만 실제 배포에서는 브라우저, 모바일 홈 화면, PWA 설치 화면처럼 여러 환경이 서로 다른 아이콘 자산을 기대합니다.
Evil Martians의 favicon 가이드 ↗는 현대적인 최소 구성을 favicon.ico, icon.svg, apple-touch-icon.png, manifest.webmanifest, icon-192.png, icon-mask.png, icon-512.png 중심으로 정리합니다. 이 기준만 봐도 파비콘은 단일 이미지가 아니라 작은 배포 패키지에 가깝습니다.
그래서 새 프로젝트를 만들 때마다 비슷한 흐름이 반복됩니다. 파비콘 생성 웹사이트를 찾고, 이미지를 업로드하고, 결과 zip을 받고, 압축을 풀고, public 디렉터리에 복사한 뒤, <head>에 들어갈 링크 태그를 다시 붙입니다.
make-favicon.zsh가 하는 일
긱뉴스에 공유된 make-favicon.zsh Gist ↗는 입력 이미지 하나를 받아 파비콘 자산을 한 번에 생성합니다. 스크립트의 사용법에는 출력 디렉터리, 사이트 이름, 배경색, URL prefix, SVG render density 옵션이 포함되어 있습니다.
./make-favicon.zsh logo.svg -o ./favicon-output -n "My Website" -p /assets/favicon/스크립트가 생성하는 주요 결과물은 다음과 같습니다. 모두 Gist의 Output 설명과 생성 로직에 들어 있는 파일명입니다.
| 파일 | 역할 |
|---|---|
favicon.ico | legacy/root-path 조회를 위한 ICO |
apple-touch-icon.png | iOS 홈 화면용 180x180 PNG |
icon-192.png | Web app manifest용 192x192 PNG |
icon-512.png | Web app manifest용 512x512 PNG |
icon-mask.png | maskable icon용 512x512 PNG |
manifest.webmanifest | PWA 아이콘 정보를 담는 manifest |
favicon.html | <head>에 붙일 링크 태그 snippet |
icon.svg | 입력이 SVG일 때만 복사되는 원본 SVG |
흐름으로 보면 이렇게 단순해집니다.
flowchart LR
A[원본 로고 이미지] --> B[make-favicon.zsh]
B --> C[PNG / ICO / SVG 자산]
B --> D[manifest.webmanifest]
B --> E[favicon.html]
C --> F[public root 또는 지정 URL prefix에 배포]
D --> F
E --> G[HTML head에 붙여넣기]중요한 점은 이미지 변환에서 끝나지 않는다는 것입니다. manifest.webmanifest와 favicon.html까지 같이 만들기 때문에, 파일 생성과 HTML 연결 사이의 애매한 작업이 줄어듭니다.
작은데 꽤 실용적인 디테일
이 스크립트는 ImageMagick 7의 magick 명령이 PATH에 있어야 한다고 명시합니다. 실제 변환은 -resize, -extent, -background, -strip 같은 ImageMagick 옵션을 조합해 정사각형 PNG를 만들고, 512px PNG에서 favicon.ico를 다시 생성하는 흐름입니다.
SVG 입력을 다루는 방식도 현실적입니다. Gist의 주석은 SVG 입력에서 density를 input path보다 먼저 둬야 낮은 해상도 래스터화를 피할 수 있다고 설명합니다.
또 하나 좋은 점은 icon.svg를 억지로 만들지 않는다는 것입니다. 스크립트는 입력 확장자가 svg일 때만 원본을 icon.svg로 복사합니다. 래스터 이미지를 SVG 껍데기로 감싸는 가짜 벡터 파일을 만들지 않습니다.
저장소 안에 둘 만한 이유
온라인 favicon generator는 한 번 쓰기에는 편합니다. 하지만 프로젝트가 여러 개이거나 브랜드 자산을 자주 바꾸는 팀이라면, 생성 규칙을 저장소 안에 남기는 편이 더 낫습니다.
스크립트로 남겨두면 다음 질문에 대한 답이 코드에 남습니다.
- 어떤 크기의 아이콘을 만들 것인가?
- SVG 입력은 어떤 density로 래스터화할 것인가?
- maskable icon은 어느 정도 여백을 둘 것인가?
- manifest와 HTML snippet은 어떤 URL prefix를 기준으로 만들 것인가?
이런 결정은 한 번 정하면 팀 안에서 반복해서 재사용됩니다. 파비콘은 작지만, 배포 품질을 드러내는 자산이기 때문입니다.
마무리
파비콘은 사용자가 오래 들여다보는 UI는 아닙니다. 하지만 브라우저 탭, 북마크, 모바일 홈 화면, 검색 결과, PWA 설치 화면처럼 서비스가 바깥 환경과 만나는 지점마다 등장합니다.
그래서 파비콘이 빠져 있거나 깨져 있으면 서비스 전체가 덜 마감된 것처럼 보입니다. 반대로 잘 정리된 파비콘 세트는 작은 부분까지 배포 품질을 챙긴다는 신호가 됩니다.
make-favicon.zsh는 거창한 도구는 아닙니다. 하지만 새 프로젝트를 시작할 때마다 반복되는 작은 마찰을 정확히 줄입니다. 이런 종류의 자동화는 프레임워크를 바꾸지 않아도 개발 경험을 조금씩 더 매끄럽게 만듭니다.
참고 자료
- Show GN: 파비콘을 만들어주는 간단한 zsh 커맨드 ↗ — 긱뉴스 소개 글
- Favicon Generator Gist ↗ —
make-favicon.zsh원본 스크립트 - How to Favicon in 2026: Three files that fit most needs ↗ — 현대적인 favicon 구성 가이드