대시보드용으로 50개 사이트의 아이콘을 스크립트로 가져와야 하는데 직접 호스팅하고 싶지는 않다면, 공개 favicon API를 사용하면 단 두 줄의 코드로 해결할 수 있습니다. 그렇다면 어떤 서비스를 선택해야 할까요? DuckDuckGo favicon API는 수년 동안 조용히 이 역할을 수행해 왔으며, Google의 S2 서비스와 직접 /favicon.ico 요청과 함께 고려해 볼 수 있는 옵션입니다.
각 옵션은 반환하는 파일 형식도 다르고, 부하 상황에서 동작 방식도 다르며, 사이트에 아이콘이 없을 때의 실패 양상도 제각각입니다. 잘못 선택하면 썸네일이 깨지거나 로그에 정체 모를 404 응답이 쌓이는 결과를 초래합니다.
빠른 비교: DuckDuckGo Favicon API vs 대안 서비스
| 평가 항목 | DuckDuckGo | Google S2 | 직접 /favicon.ico |
|---|---|---|---|
| 엔드포인트 패턴 | icons.duckduckgo.com/ip3/{domain}.ico | s2.googleusercontent.com/s2/favicons?domain={domain} | {site}/favicon.ico |
| 반환 형식 | ICO only | PNG (기본 16x16) | 사이트가 제공하는 형식 그대로 |
| 기본 크기 | 멀티 사이즈 ICO 컨테이너 | 16x16 (sz=64까지) | 사이트 정의값 |
| 공개된 rate limit 문서 | 없음 | 없음 | 사이트별 CORS / 서버 정책 |
| CORS 친화성 | 예 (예외 있음) | 예 | 대부분 아니오 |
| 프록시 / privacy 계층 | 예 (DuckDuckGo 프록시) | 예 (Google 프록시) | 없음 |
| 아이콘 부재 시 fallback | 404 반환 | 기본 지구본 아이콘 반환 | 404 또는 HTML 오류 |
| 적합한 용도 | 탭 스타일 아이콘, ICO가 필요한 경우 | 작은 이미지 썸네일, SERP와 동일한 표시 | 원본 소스 자산을 그대로 가져와야 할 때 |
DuckDuckGo Favicon API의 실제 동작 방식
엔드포인트 구조는 매우 간단합니다: https://icons.duckduckgo.com/ip3/example.com.ico. DuckDuckGo는 자체 인프라에서 해당 사이트의 실제 favicon을 가져온 뒤, 필요 시 ICO 컨테이너로 변환하여 자사 CDN을 통해 제공합니다. 원본(origin) 서버로 직접 요청을 보내지 않으므로 대부분의 CORS 제약을 우회할 수 있습니다.
이 프록시 방식 덕분에 URL 자체가 프라이버시를 보호하는 fetch 역할도 함께 수행합니다. 방문자의 브라우저가 아이콘을 렌더링하기 위해 대상 사이트에 직접 요청하지 않기 때문입니다. 이는 Google의 s2.googleusercontent.com이 사용하는 방식과 동일하며, 별도의 헤더 없이 어느 출처에서든 <img> 태그로 동작하는 이유입니다.
포맷 제한 사항
가장 큰 주의점은 DuckDuckGo가 ICO만 반환한다는 점입니다. iOS 스타일 목록에 선명한 64x64 PNG가 필요하다면 직접 변환해야 합니다. 저희 PNG to ICO 변환 가이드에서는 반대 방향 변환을 다루고 있지만, 동일한 도구로 양쪽 방향 모두 처리할 수 있습니다. ICO만으로 충분한 프로젝트—데스크톱 브라우저 탭, 구형 <link rel='icon'> fallback—의 경우 DuckDuckGo가 가장 손쉬운 선택입니다.
DuckDuckGo Favicon API가 적합한 경우
- 변환 단계 없이 ICO가 필요한 경우. 브라우저 탭 fallback, 구형 IE 지원, Windows 바로가기는 여전히 ICO를 필요로 하며, DuckDuckGo는 이를 즉시 제공합니다.
- 브라우저에서 직접 가져오면서 CORS 설정이 전혀 필요 없는 경우. DuckDuckGo와 Google 모두 요청을 프록시 처리하지만, DuckDuckGo는 역사적으로 hot-link에 더 관대한 태도를 보여왔습니다.
- 프라이버시를 존중하는 프록시를 원하는 경우. DuckDuckGo는 추적 없음을 브랜드 모토로 삼고 있어, 덕분에 favicon 엔드포인트가 Google보다 덜 감시적인 인상을 줍니다.
Google S2가 더 나은 선택인 경우
- ICO가 아닌 PNG가 필요한 경우. Google 엔드포인트는 기본적으로
image/png를 제공하며, 최대 64 픽셀까지의sz=파라미터를 지원합니다. - SERP 스타일 목록을 구축 중인 경우. Google은 사이트에 favicon이 없을 때 기본 지구본 아이콘을 반환합니다. 반면 DuckDuckGo는 404를 반환하므로 이를 별도로 처리해야 합니다.
- 일관된 16x16 썸네일이 필요한 경우. Google의 응답은 항상 작고 빠르며 예측 가능합니다.
직접 /favicon.ico를 사용해도 괜찮은 경우
신뢰할 수 있는 단일 사이트 — 자체 CDN, 파트너 사이트, 검증된 출처 — 에서는 favicon을 직접 가져오는 것이 원본 자산을 최고 해상도로 확보할 수 있는 가장 확실한 방법입니다. SVG, 멀티해상도 ICO, 애니메이션 PNG 등 해당 사이트가 실제로 제공하는 자산을 그대로 받을 수 있습니다. 다만 트레이드오프는 CORS입니다. 대부분의 사이트는 브라우저가 필요로 하는 헤더를 함께 보내지 않기 때문에 이 방식은 서버 간(server-to-server)에서만 동작하며 클라이언트 측에서는 사용할 수 없습니다.
대량으로 가져오기 작업을 수행할 경우, rate limit 관련 문서가 부재하다는 점은 실제 리스크입니다. 일부 출처는 50회 요청 후 429 응답을 반환하지만, 그렇지 않은 경우도 있습니다. 이러한 리스크를 흡수해 주는 것이 바로 공개(public) API들이 존재하는 이유이기도 합니다.
Recommendation
브라우저 탭이나 목록 뷰에서 동작하는 아이콘이 필요한 대부분의 클라이언트 측 프로젝트에서 ICO 포맷이 필요하다면 DuckDuckGo favicon API가 적합한 기본 선택입니다. 자체 아이콘도 함께 배포해야 한다면 무료 favicon generator와 함께 사용하시기 바랍니다. PNG 썸네일과 Google SERP와 동일한 품질의 결과가 필요하다면 Google의 S2 엔드포인트가 더 빠르고 예측 가능합니다. 최고 해상도의 원본 파일이 필요한 신뢰 가능한 단일 도메인 환경에 한해 /favicon.ico 직접 가져오기를 사용하시기 바랍니다.
어떤 API를 선택하든 결과를 캐시하시기 바랍니다. 브라우저의 favicon 요청은 잘 알려져 있듯이 매우 집요하게(sticky) 캐시에 남아 있는 특성이 있어, 서버 측에서 캐싱을 적용하지 않으면 매 페이지 로드마다 DuckDuckGo의 CDN에 반복 요청을 보내게 되므로, 서버에 캐싱을 두는 것이 도움이 됩니다.
Check the documented requirements
HTML Standard는 rel='icon'을 현재 페이지를 대표하는 아이콘의 link relationship으로 정의하고 있습니다.