favicon.ico 없어도 탭에 아이콘이 뜨는 이유

favicon.ico 파일을 올린 적이 없는데도 탭에 아이콘이 뜨는 사이트가 있습니다. 반대로 favicon.ico를 분명히 올려 뒀는데 탭에는 다른 그림이 나오는 사이트도 있습니다. 둘 다 고장이 아닙니다.

브라우저는 파비콘을 찾을 때 파일 이름부터 뒤지지 않습니다. 먼저 그 페이지의 head 안에 무엇이 "이게 아이콘이다"라고 선언돼 있는지부터 읽습니다. 이 글은 그 탐색 순서와, 한 사이트가 실제로 몇 개의 아이콘을 어떤 이름으로 숨겨 두고 있는지 전부 찾아내는 방법을 정리합니다.

요약 ① 브라우저는 head의 아이콘 선언(rel="icon", rel="apple-touch-icon" 등)을 먼저 확인하고, 아무 선언이 없을 때만 기본 경로 /favicon.ico를 시도합니다. ② 그래서 favicon.ico가 없어도 탭에 아이콘이 뜨는 사이트가 흔합니다 — 선언된 다른 파일이 대신 쓰이는 것입니다. ③ 실제 사이트 하나에는 용도가 다른 아이콘이 여러 개 동시에 선언돼 있는 경우가 많고, 이 도구는 그걸 전부 목록으로 찾아 보여줍니다.

favicon.ico가 없는데 아이콘이 뜨는 게 이상하게 느껴지는 이유

많은 사람이 "파비콘 = favicon.ico"라고 배웁니다. 실제로 예전에는 사이트 루트에 favicon.ico 하나만 올려 두면 끝나는 시절이 있었습니다. 그래서 지금도 개발자 커뮤니티에는 "favicon.ico를 루트에 넣었는데 왜 안 뜨죠"라는 질문과, "favicon.ico를 지웠는데 왜 여전히 아이콘이 뜨죠"라는 정반대 질문이 함께 올라옵니다.

두 질문 모두 같은 오해에서 출발합니다. favicon.ico를 유일한 정답 파일로 여기는 오해입니다. 실제로 사이트 개발자용 프레임워크나 CMS는 favicon.ico 대신(또는 함께) head 안에 아이콘 링크 태그를 직접 심어 둡니다. 이 태그가 있으면 브라우저는 굳이 /favicon.ico를 요청하지 않습니다.

그래서 개발자도구의 네트워크 탭을 열어 favicon.ico 요청이 없는 걸 보고 "파비콘이 깨졌다"고 단정하는 일이 생깁니다. 사실은 브라우저가 애초에 그 경로를 요청할 필요가 없었던 것뿐입니다. head 안의 선언만으로 이미 원하는 그림을 다 받았기 때문입니다.

같은 오해가 반대 방향으로도 작동합니다. 사이트를 리뉴얼하면서 head 태그는 새로 바꿨는데 옛날 favicon.ico 파일을 지우지 않고 그대로 서버에 남겨 두는 경우가 있습니다. 이때 탭에는 새 아이콘이 뜨는데, 누군가 주소창에 도메인/favicon.ico를 직접 쳐서 열어 보면 옛날 그림이 나옵니다. 둘 다 실재하는 파일이고, 둘 다 틀린 게 아닙니다. 단지 브라우저가 탭에 쓸 그림을 고를 때 그 경로를 아예 보지 않았을 뿐입니다.

이런 상황은 팀 안에서 실제로 혼선을 일으킵니다. 디자이너가 새 로고로 아이콘 세트를 새로 만들어 전달했는데, 개발자가 head 태그는 그대로 두고 파일 이름만 같게 바꿔치기하는 경우가 있습니다. 이때 브라우저나 CDN이 이전 파일을 캐시하고 있으면 당장은 옛 그림이 계속 보이고, 반대로 head 태그 쪽의 href 자체가 여전히 옛 파일명을 가리키고 있다면 파일을 아무리 새로 올려도 그 경로에 있는 옛 파일이 계속 불려 나옵니다. 두 원인은 겉으로 보이는 증상(안 바뀜)은 똑같아도 고쳐야 할 지점이 전혀 다릅니다. 그래서 "지금 head가 무엇을 가리키고 있는지"를 먼저 확인하는 것이 문제 해결의 출발점이 됩니다.

이 혼란은 결국 하나의 질문으로 좁혀집니다. 브라우저는 "어떤 그림을 아이콘으로 쓸지" 무엇을 기준으로, 어떤 순서로 정하는가. 다음 절에서 이걸 실제로 확인하는 방법을 다룹니다.

검색엔진 결과의 아이콘과 탭 아이콘이 다른 경우

혼란을 키우는 상황이 하나 더 있습니다. 검색 결과 목록에서 보이는 사이트 아이콘과, 그 링크를 눌러 들어갔을 때 브라우저 탭에 뜨는 아이콘이 서로 다르게 보이는 경우입니다.

두 아이콘은 각자 다른 시점에, 다른 목적으로 가져와진 그림입니다. 검색 결과의 아이콘은 검색엔진이 그 사이트를 이전에 방문했을 때 읽어 간 값이 캐시돼 있는 것이고, 지금 눈앞의 탭 아이콘은 지금 이 순간 브라우저가 새로 읽은 값입니다. 사이트가 그사이 아이콘을 교체했다면 두 값이 다르게 보이는 게 오히려 자연스럽습니다. 검색엔진이 캐시를 다시 갱신하기까지는 어느 정도 시차가 있을 수 있어, "분명히 바꿨는데 검색 결과에는 아직 옛날 그림이 남아 있다"는 상황도 흔하게 벌어집니다.

이 사실을 모르면 "검색 결과 아이콘을 저장하고 싶은데 탭 아이콘과 달라서 뭘 받아야 할지 모르겠다"는 지점에서 다시 막히게 됩니다. 결국 필요한 건 검색엔진이 예전에 읽어 간 캐시가 아니라, "지금 이 사이트가 head에 실제로 무엇을 선언해 뒀는지" 그 원본을 확인하는 일입니다. 원본을 확인해 두면 검색 결과가 나중에 갱신되더라도 결과가 어떻게 바뀔지 미리 예측할 수 있습니다.

공식/수동으로 사이트의 아이콘 선언을 확인하는 방법

가장 정확한 방법은 브라우저가 보는 그대로, 즉 페이지의 HTML 소스를 직접 여는 것입니다. 순서는 다음과 같습니다.

1. 확인하고 싶은 사이트를 엽니다.
2. 주소창에서 마우스 우클릭 후 "페이지 소스 보기"를 선택하거나, 주소 앞에 view-source:를 붙여 다시 엽니다.
3. Ctrl+F(맥은 Cmd+F)로 "icon"을 검색합니다.
4. head 태그 안에서 rel 속성에 icon이 들어간 link 태그를 하나씩 확인합니다.

이때 눈에 띄는 게 하나가 아니라 여럿일 수 있습니다. rel="icon"이 여러 줄 나오기도 하고, rel="apple-touch-icon", rel="mask-icon" 처럼 이름 자체가 다른 태그도 섞여 나옵니다. 각 태그는 href로 실제 파일 경로를, 있다면 sizes나 type으로 크기·형식 힌트를 함께 가지고 있습니다.

href가 상대 경로일 때

여기서 자주 걸리는 부분이 href 값입니다. href="/assets/icon-32.png" 처럼 앞에 도메인이 없는 상대 경로로 적혀 있는 경우가 많습니다. 이때는 지금 보고 있는 사이트의 도메인을 앞에 직접 붙여야 실제로 열 수 있는 주소가 됩니다.

예를 들어 example.com을 확인하는 중이고 href가 /assets/icon-32.png라면, 실제 이미지 주소는 example.com/assets/icon-32.png가 됩니다. 만약 href가 icon-32.png처럼 슬래시 없이 파일명만 있다면 지금 보고 있는 페이지 경로를 기준으로 다시 조합해야 하므로 더 헷갈립니다. 태그가 하나뿐이면 이 작업이 몇 초 걸리지 않지만, 태그가 대여섯 개를 넘어가면 하나씩 조합해 새 탭에 붙여 넣는 과정 자체가 반복 노동이 됩니다.

여러 사이트를 한 번에 비교해야 할 때

혼자 한 사이트만 볼 때는 소스 보기로도 어떻게든 버틸 수 있습니다. 문제는 비교 대상이 늘어날 때입니다. 경쟁사 서너 곳의 아이콘 구성을 나란히 비교하거나, 자사가 운영하는 여러 서브 도메인의 아이콘이 일관되게 맞춰져 있는지 점검하려면, 사이트 수만큼 소스 보기를 열고 head를 훑고 상대 경로를 조합하는 작업을 반복해야 합니다.

이 반복 작업에서 사람이 가장 자주 놓치는 부분은 "어떤 사이트에서 어떤 파일을 봤는지"를 기억하는 일입니다. 탭을 여러 개 열어 두고 하나씩 비교하다 보면 어느 파일이 어느 사이트 것이었는지 헷갈리기 쉽고, 파일명 자체가 icon.png처럼 사이트마다 겹치는 경우도 흔해서 다운로드 폴더에서도 뒤섞이기 쉽습니다. 주소를 바꿔 가며 매번 조회하고, 결과를 그때그때 구분해서 저장하는 것이 결국 가장 확실한 정리 방법입니다.

개발자도구 네트워크 탭으로 보조 확인하기

소스 보기 대신 개발자도구(F12)의 네트워크 탭을 열고 페이지를 새로고침한 뒤 icon이라는 단어로 필터링하는 방법도 있습니다. 이러면 지금 이 브라우저가 실제로 요청해 받아 온 파일이 보입니다.

다만 이 방법은 "지금 이 브라우저, 이 환경 조건에서 실제로 쓰인 것"만 보여줍니다. head에 선언은 돼 있지만 다른 브라우저나 다른 조건에서만 쓰이는 선언(예: 사파리 전용 mask-icon)은 지금 크롬으로 열어 보면 애초에 요청조차 되지 않아 목록에 잡히지 않습니다. 그 사이트가 가진 아이콘 선언 전체를 보려면 결국 소스 코드를 처음부터 끝까지 읽어야 합니다.

수동으로 하면 여기서부터 번거로워집니다. head 안에 태그가 열 줄 넘게 있는 사이트도 흔하고, href가 상대 경로면 실제 파일 주소로 직접 조합해서 하나씩 새 탭에 붙여 넣어 열어봐야 어떤 그림인지 알 수 있습니다. rel="mask-icon"처럼 SVG 파일인 경우 열어 봐도 색상 없이 검은 실루엣만 보여서 "이게 왜 아이콘이지" 싶기도 합니다. 게다가 head 안에 아무 선언도 없는 사이트라면, 이 방법으로는 "선언이 없다"는 사실만 확인될 뿐 브라우저가 실제로 무엇을 쓰고 있는지는 /favicon.ico를 따로 열어봐야 알 수 있습니다.

선언이 여러 개 있는 사이트일수록 이 작업은 태그 하나하나를 손으로 대조하는 일이 됩니다. 어떤 게 탭용이고, 어떤 게 iOS 홈 화면용이고, 어떤 게 사파리 마스크 아이콘용인지 이름만 보고는 바로 판단하기 어렵습니다. 상대 경로 조합, 파일 형식 판별, 용도 구분이라는 세 가지 작업을 태그 수만큼 반복해야 비로소 "이 사이트는 아이콘을 이렇게 갖추고 있구나"라는 전체 그림이 완성됩니다.

직접 해보기 →

브라우저가 여러 아이콘 중 하나를 고르는 기준 — 기술적으로 왜 이런 차이가 나는가

브라우저가 파비콘을 찾는 과정은 무작위가 아니라 정해진 순서를 따릅니다. 핵심은 이렇습니다. 브라우저는 먼저 지금 보고 있는 페이지의 head 안에 아이콘 관련 link 태그가 있는지부터 확인합니다. rel="icon", rel="apple-touch-icon", rel="mask-icon" 같은 선언이 여기 해당합니다. 이런 선언이 하나라도 있으면 브라우저는 그중 상황에 맞는 것을 골라 사용합니다. 반대로 이런 선언이 아무것도 없을 때만, 브라우저는 마지막 수단으로 그 사이트의 기본 경로인 /favicon.ico를 시도합니다.

이 순서를 알면 앞 절의 두 가지 궁금증이 자연스럽게 풀립니다. favicon.ico 파일을 올린 적이 없는데도 탭에 아이콘이 뜨는 이유는, head 안에 다른 이름의 파일을 가리키는 rel="icon" 선언이 이미 있었기 때문입니다. 브라우저 입장에서는 그 선언을 발견한 순간 더 찾을 이유가 없습니다. /favicon.ico라는 경로는 아예 시도되지 않습니다. 그래서 이 경로에 파일이 있는지 없는지는 결과에 아무 영향을 주지 않습니다.

반대로 head 안에 아이콘 선언이 전혀 없는 사이트라면, 그때는 브라우저가 정말로 /favicon.ico를 요청합니다. 이 경로에 실제 파일이 있으면 그게 탭 아이콘이 되고, 없으면 탭에는 아무 그림도 뜨지 않거나 브라우저 기본 아이콘이 뜹니다. 즉 /favicon.ico는 "항상 확인하는 기본값"이 아니라 "선언이 없을 때만 확인하는 최후의 대안"입니다. 순서를 반대로 알고 있으면 사이트를 진단할 때 계속 엉뚱한 곳을 보게 됩니다.

여기서 한 가지 더 중요한 지점이 있습니다. head 안의 선언이 하나가 아니라 여러 개인 경우, 각 선언은 서로 경쟁하는 관계가 아니라 "용도가 다른" 관계인 경우가 많다는 것입니다. 실제로 github.com의 head를 열어 확인해 보면, 이름과 형식이 전부 다른 아이콘 선언 6종이 동시에 존재합니다. fluid-icon(PNG), mask-icon(SVG), alternate icon(PNG), icon(SVG), favicon.ico(ICO), 그리고 og:image(PNG)입니다. 이 여섯 개는 하나가 다른 하나를 대체하기 위한 후보가 아니라, 애초에 쓰이는 자리가 서로 다른 별개의 그림입니다.

fluid-icon은 브라우저 탭이 아니라 데스크톱 앱처럼 페이지를 감싸는 일부 macOS 브라우저 셸에서 쓰이는 용도입니다. mask-icon은 사파리가 고정 탭이나 독(Dock) 아이콘을 단색 실루엣으로 표시할 때 참조하는 SVG로, 색상 정보 없이 형태만 담고 있어 열어 봐도 검은 실루엣으로 보이는 게 정상입니다. alternate icon과 icon(SVG)은 최신 브라우저가 스케일에 관계없이 선명하게 표시할 수 있는 벡터 아이콘 후보로 함께 준비돼 있는 경우입니다. favicon.ico는 이런 최신 형식을 지원하지 않는 오래된 환경을 위한 하위 호환용 파일입니다. og:image는 파비콘이 아니라 SNS나 메신저에 링크를 공유했을 때 미리보기로 뜨는 대표 이미지로, 애초에 탭 아이콘과는 목적 자체가 다릅니다.

이렇게 용도가 나뉘는 이유는 화면과 표시 환경이 요구하는 조건이 서로 다르기 때문입니다. 브라우저 탭은 아주 작은 자리에 빠르게 그려야 하고, 사파리의 마스크 아이콘은 색상 없이 시스템 테마색으로 다시 칠해지는 걸 전제로 만들어져야 하며, iOS 홈 화면에 추가되는 애플 터치 아이콘은 앱 아이콘처럼 정사각형에 여백 없이 꽉 채워진 그림이어야 자연스럽습니다. 이 조건을 전부 만족하는 그림 파일 하나를 만들기는 사실상 불가능하기 때문에, 사이트들은 처음부터 자리별로 최적화된 파일을 따로 준비해 head에 나란히 선언해 두는 방식을 씁니다.

이 도구는 이 원리를 그대로 활용합니다. 주소를 넣으면 head 안에 선언된 아이콘 관련 태그를 전부 찾아 목록으로 보여주고, 선언이 하나도 없는 사이트라면 기본 경로인 /favicon.ico도 함께 시도합니다. 사람이 직접 소스 보기를 열어 rel 속성을 하나하나 찾고, href의 상대 경로를 실제 주소로 조합해 새 탭에서 열어 확인하던 과정을 한 번의 조회로 대신하는 것입니다. 찾아낸 항목 중 필요한 것만 골라 낱개로 받거나, 전부 ZIP으로 한 번에 받을 수도 있습니다.

왜 favicon.ico 하나로 통일하지 않는가

여기까지 읽으면 자연스럽게 "그냥 favicon.ico 하나로 통일하면 훨씬 간단하지 않나"라는 의문이 듭니다. 실제로 예전에는 그런 시절이 있었습니다. 지금 여러 선언을 나란히 두는 사이트가 많아진 배경은, 파비콘이 쓰이는 자리 자체가 예전보다 훨씬 늘어났기 때문입니다.

과거에는 파비콘이 쓰이는 자리가 브라우저 탭 하나뿐이었습니다. 지금은 탭 외에도 iOS·안드로이드 홈 화면 아이콘, 사파리의 고정 탭·독 실루엣, 브라우저 즐겨찾기 목록, 검색 결과 목록, SNS 공유 미리보기까지 늘어났습니다. 자리마다 요구하는 조건(정사각형 여백 없는 그림, 색상 없는 실루엣, 작은 해상도에서도 뭉개지지 않는 벡터)이 서로 다르다 보니, 파일 하나로는 모든 자리를 다 만족시킬 수 없게 된 것입니다. 여러 선언이 늘어난 건 복잡해지려고 그런 게 아니라, 표시되는 자리가 다양해진 결과를 그대로 반영한 것입니다.

바꿔 말하면, head 안의 아이콘 선언 개수는 그 사이트가 신경 쓰고 있는 표시 환경의 가짓수와 대략 비례합니다. 선언이 하나뿐인 사이트는 탭 정도만 챙긴 것이고, 여섯 개가 넘는 사이트는 탭·모바일 홈 화면·사파리·SNS 공유까지 각각 따로 준비해 둔 것입니다. 이 숫자만 봐도 그 사이트가 얼마나 여러 채널을 염두에 두고 만들어졌는지 가늠할 수 있습니다.

확장자와 파일 형식이 곧이곧대로 대응하지 않는 이유

또 하나 헷갈리는 지점은 파일 형식입니다. rel="icon" 태그가 가리키는 파일이 항상 ICO 형식인 것은 아닙니다. PNG를 가리킬 수도 있고 SVG를 가리킬 수도 있습니다. rel 값 자체는 "이게 아이콘 역할을 한다"는 의미만 담고 있을 뿐, 파일 형식을 강제하지는 않습니다. 실제 형식은 href가 가리키는 파일의 확장자와, 태그에 함께 적힌 type 속성으로 판단해야 합니다.

이 때문에 사람이 눈으로 훑어볼 때는 "rel="icon"이니까 당연히 .ico 파일이겠지"라고 짐작했다가, 실제로는 .png나 .svg인 걸 보고 다시 확인하는 일이 반복되기 쉽습니다. 이 도구가 목록에 형식을 함께 표시해 주는 이유도 여기에 있습니다.

사이트를 조사할 때 이 구조가 왜 유용한가

이 탐색 순서를 알고 나면 사이트 하나를 조사하는 방식 자체가 달라집니다. 단순히 "아이콘이 몇 개 있나"를 세는 게 아니라, "이 사이트가 어떤 표시 환경까지 신경 써서 준비해 뒀는가"를 읽어낼 수 있게 됩니다.

예를 들어 apple-touch-icon 선언이 없는 사이트는 iOS 홈 화면에 추가했을 때 브라우저가 자체적으로 만든 기본 아이콘이나 페이지 캡처 이미지가 대신 쓰일 수 있습니다. mask-icon이 없는 사이트는 사파리에서 고정 탭으로 열었을 때 다른 아이콘이 대신 그 자리를 채우게 됩니다. 이런 차이는 사이트 운영자가 어느 채널까지 세심하게 관리하고 있는지를 보여주는 단서가 되기도 합니다. 자사 사이트를 점검할 때도, 경쟁사 사이트의 완성도를 참고할 때도 같은 방식으로 읽을 수 있습니다.

화질·포맷·케이스 비교

같은 "아이콘"이라는 이름 아래에도 실제로는 형식과 용도가 전부 다릅니다. 무엇이 어떤 자리를 위한 파일인지 표로 정리하면 다음과 같습니다.

표에서 알 수 있듯, mask-icon처럼 색상 정보가 없는 파일을 다른 아이콘 대신 쓰면 실루엣만 남아 이상하게 보입니다. 반대로 og:image는 파비콘 자리에 쓰라고 만든 파일이 아니므로, 이 도구가 목록에 함께 보여주더라도 탭 아이콘 용도로 받아 쓰기에는 맞지 않습니다. 자리에 맞는 파일을 고르는 게 핵심입니다.

이 표를 반대로 읽으면 "내가 지금 어느 파일을 받아야 하는가"에 대한 답도 자연스럽게 됩니다. 지금 만들고 있는 결과물이 브라우저 탭 목업이라면 icon 계열을, iOS 홈 화면에 추가된 모습을 보여주려면 apple-touch-icon을, 사파리 고정 탭 UI를 재현하려면 mask-icon을 받으면 됩니다. 반대로 목적이 정해지지 않은 채 "일단 다 받아 두자"는 식으로 접근하면, 나중에 어느 파일이 어디에 쓰이는 것이었는지 다시 헷갈리게 됩니다. 받을 때 파일명에 자리를 함께 적어 두는 습관이 도움이 됩니다.

형식 차이도 실무에서 영향을 줍니다. ICO 파일은 한 파일 안에 여러 해상도를 동시에 담을 수 있는 컨테이너 형식이라 오래된 환경까지 폭넓게 지원되지만, 편집 프로그램에 따라 열어 보는 방식이 다릅니다. PNG는 대부분의 이미지 편집기에서 바로 열리고 수정하기 쉽습니다. SVG는 벡터라 확대해도 계단 현상이 생기지 않지만, mask-icon처럼 색상이 빠진 경우 일반 뷰어에서는 의도한 것과 다르게 보일 수 있다는 점을 감안해야 합니다.

자주 막히는 지점

이 표에 없는 새로운 증상을 만났다면, 대개는 "지금 보이는 문제가 파일 자체의 문제인지, 아니면 애초에 브라우저가 다른 파일을 보고 있는 것인지"를 먼저 구분하는 것으로 원인을 반 이상 좁힐 수 있습니다. head 선언을 다시 확인하는 것이 가장 먼저 할 일입니다.

저작권과 합법적 사용 범위

이 도구로 찾아낸 아이콘은 어디까지나 공개돼 있는 페이지의 head에 선언된 파일을 그대로 열람·저장하는 것입니다. 하지만 그 파일 자체의 저작권은 그 사이트를 운영하는 원저작자에게 있다는 사실은 바뀌지 않습니다.

본인이 관리하는 사이트의 아이콘을 점검하거나, 자신이 만든 브랜드 자산이 여러 환경에서 잘 표시되는지 확인하는 용도로 쓰는 것은 아무 문제가 없습니다. 반면 다른 브랜드의 로고나 아이콘을 그대로 가져다 자신의 제품이나 서비스에 재사용하거나, 원저작자처럼 보이도록 재배포하는 것은 상표권·저작권 문제로 이어질 수 있습니다.

경쟁사 브랜딩이 어떤 식으로 구성돼 있는지 조사하거나 참고하는 용도로 사용하는 정도는 폭넓게 받아들여지지만, 그 결과물을 그대로 복제해 쓰는 것과는 다른 이야기입니다. 다운로드한 파일을 실제로 활용하려면 본인의 자료이거나, 원저작자로부터 명시적으로 사용을 허락받은 경우로 한정하는 것이 안전합니다.

이 도구가 다루는 대상은 처음부터 공개된 페이지에 공개적으로 선언된 파일에 한정됩니다. 로그인이 필요한 비공개 페이지나 접근 권한이 걸린 영역의 자원을 우회해서 가져오는 기능이 아닙니다. 누구나 브라우저로 그 사이트를 열면 똑같이 받아 갈 수 있는 파일을 조회하고 정리해서 보여주는 것뿐이며, 이 지점이 "공개된 콘텐츠만 다룬다"는 원칙과 맞닿아 있습니다.

같은 이유로, 자사 사이트나 제품의 아이콘이 실제로 의도한 대로 여러 환경에 노출되고 있는지 스스로 점검하는 용도로도 자연스럽게 쓸 수 있습니다. 리뉴얼 이후 옛날 아이콘 파일이 서버에 그대로 남아 있지는 않은지, 신규 채널에 필요한 선언이 빠지지는 않았는지 확인하는 데는 저작권 문제가 애초에 발생하지 않습니다.

디자인 조사를 목적으로 여러 사이트의 아이콘을 모아 볼 때도, 그 결과물을 내부 참고 자료로 두는 것과 외부에 그대로 공개하거나 재배포하는 것은 구분해야 합니다. 참고용으로 모아 둔 자료라도 원저작자 표시 없이 마치 자신의 것처럼 배포하면 저작권 문제로 번질 수 있으므로, 조사 단계와 실제 사용 단계를 분리해서 생각하는 편이 안전합니다.

비슷한 도구·플랫폼과 무엇이 다른지

파비콘 관련 도구는 크게 두 갈래로 나뉩니다. 하나는 이미지 한 장을 올리면 여러 크기의 파비콘 파일을 새로 만들어주는 생성 도구이고, 다른 하나는 이미 존재하는 사이트에서 이미 선언된 아이콘을 찾아내는 추출 도구입니다. 이 둘은 입력값부터 다릅니다. 생성 도구는 "내가 가진 원본 이미지"를 입력으로 받고, 추출 도구는 "확인하고 싶은 사이트 주소"를 입력으로 받습니다.

브라우저 개발자도구의 네트워크 탭으로도 비슷한 확인이 가능하긴 합니다. 페이지를 새로고침하면서 icon이라는 키워드로 필터링하면 실제로 요청된 파일들이 보입니다. 다만 이 방법은 그 순간 브라우저가 실제로 요청한 파일만 보여줄 뿐, head에 선언은 돼 있지만 그 브라우저·환경 조건에서는 요청되지 않은 다른 선언(예: 다른 브라우저 전용 mask-icon)까지는 한눈에 보여주지 않습니다. 소스 코드를 직접 읽어 모든 rel 선언을 훑어야 전체 그림이 보입니다.

이 도구는 head 소스를 파싱해 선언된 항목을 전부 나열하고, 선언이 없을 때의 기본 경로 시도까지 함께 처리해 사람이 브라우저별·환경별로 여러 번 확인해야 했던 과정을 한 번의 조회로 압축한 것입니다. 결과를 훑어보는 데서 그치지 않고 필요한 파일만 골라 저장까지 이어진다는 점도 단순 조회 도구와 다른 지점입니다.

파비콘 관련 브라우저 확장 프로그램도 있습니다. 이런 확장은 지금 열려 있는 탭이 실제로 어떤 파일을 아이콘으로 쓰고 있는지 빠르게 보여주는 데는 유용하지만, 대개 "지금 이 탭에 쓰인 파일 하나"에 초점이 맞춰져 있어 그 사이트가 다른 자리(홈 화면, 마스크 아이콘)를 위해 별도로 선언해 둔 나머지 파일까지 한 번에 보여주지는 않는 경우가 많습니다. 반면 이 도구는 애초에 조회 대상을 "주소 하나"로 잡고, 그 주소의 head 전체를 훑어 선언된 모든 아이콘 후보를 한 번에 모아 보여주는 방식을 씁니다.

또한 이미지 편집 프로그램에 딸린 "웹사이트에서 아이콘 가져오기" 류의 부가 기능과 비교하면, 이 도구는 별도 설치나 가입 없이 브라우저에서 주소만 넣으면 바로 결과를 확인할 수 있다는 점이 다릅니다. 결과를 확인한 뒤 필요한 것만 골라 낱개로 받거나 ZIP으로 한 번에 정리해 받을 수 있어, 조사와 저장이 같은 화면 안에서 끝납니다.

앞서 다룬 '파비콘 크기가 각각 어디에 쓰이는지' 설명하는 글과는 질문 자체가 다릅니다. 그 글이 "16px과 180px이 왜 다른가"라는 크기의 의미를 다룬다면, 이 글은 "브라우저가 여러 선언 중 무엇을 먼저 찾아 쓰는가"라는 탐색 순서를 다룹니다. 새로 파비콘을 만드는 상황이라면 크기를 다룬 글이, 이미 있는 사이트의 아이콘을 전부 찾아내야 하는 상황이라면 이 도구와 이 글이 더 맞는 방향입니다.

정리

• 브라우저는 head의 아이콘 선언을 먼저 확인하고, 선언이 없을 때만 기본 경로 /favicon.ico를 시도합니다.
• 그래서 favicon.ico가 없어도 탭에 아이콘이 뜨는 사이트가 흔하고, 반대로 favicon.ico가 있어도 안 쓰이는 사이트도 흔합니다.
• 실제 사이트 하나에 탭용·사파리 마스크용·iOS 홈 화면용·SNS 공유용 아이콘이 형식까지 다르게 동시에 선언돼 있을 수 있습니다.
• 이 도구는 선언된 항목을 전부 목록으로 찾아 필요한 것만 낱개 또는 ZIP으로 저장하게 해줍니다.
• 다운로드한 파일을 실제로 활용할 때는 본인 자료이거나 허락받은 경우로 용도를 한정하는 것이 안전합니다.

자주 묻는 질문

favicon.ico가 없는데도 탭에 아이콘이 뜨는 게 정상인가요?

정상입니다. 브라우저는 페이지 head에 rel="icon" 같은 아이콘 선언이 있으면 그것을 먼저 사용하고, /favicon.ico는 선언이 전혀 없을 때만 최후의 대안으로 시도합니다. 즉 head 선언이 있는 사이트라면 favicon.ico 파일의 존재 여부는 탭 아이콘 표시에 아무 영향을 주지 않습니다. 개발자도구에서 favicon.ico 요청이 안 보인다고 해서 아이콘이 깨진 것은 아니며, 오히려 head 선언만으로 이미 해결됐다는 뜻으로 읽는 게 맞습니다. 반대로 favicon.ico 파일이 서버에 남아 있는데도 브라우저가 그 파일을 전혀 요청하지 않는 것 역시 같은 이유로 정상적인 동작입니다.

목록에 여러 개가 나오는데 뭐가 진짜 파비콘인가요?

전부 진짜입니다. 다만 쓰이는 자리가 서로 다릅니다. 탭에는 icon 선언이, iOS 홈 화면에는 apple-touch-icon이, 사파리 고정 탭에는 mask-icon이 각각 따로 쓰입니다. 어느 하나가 대표 파일이고 나머지가 여분인 구조가 아니라, 표시 환경마다 요구 조건이 달라 애초에 별도로 준비해 둔 것입니다. 필요한 자리에 맞는 항목을 고르면 되고, 어떤 자리에 쓸지 아직 정하지 않았다면 우선 탭에서 가장 흔히 쓰이는 icon 계열부터 확인하는 것이 무난합니다.

mask-icon을 받았는데 색이 없고 검은 실루엣만 보입니다. 고장 난 건가요?

고장이 아닙니다. mask-icon은 사파리가 고정 탭이나 독 아이콘을 표시할 때 시스템 테마색으로 다시 칠해서 쓰도록 만들어진 SVG라, 파일 자체에는 형태 정보만 있고 색상 정보가 빠져 있는 것이 정상입니다. 이미지 뷰어로 그냥 열면 검은 실루엣으로 보이는 게 원래 설계입니다. 색이 있는 그림이 필요하다면 다른 형식(icon, apple-touch-icon)을 받으면 됩니다. mask-icon 자체가 필요한 상황이라면, 실루엣만으로도 사파리가 알아서 배경색과 대비되는 색을 입혀 표시하므로 그대로 활용하면 됩니다.

og:image도 목록에 나오던데 이것도 파비콘인가요?

아닙니다. og:image는 SNS나 메신저에 링크를 공유했을 때 미리보기로 뜨는 대표 이미지로, 목적 자체가 탭 아이콘과 다릅니다. head 안에서 아이콘 선언과 비슷한 위치에 함께 적혀 있는 경우가 많아 목록에 같이 나올 수 있지만, 브라우저 탭에는 쓰이지 않는 별개의 이미지입니다. 대체로 파비콘보다 훨씬 큰 해상도로 준비돼 있는데, 이는 SNS 카드 형태로 넓게 표시되기 때문입니다. 용도를 구분해서 필요한 항목만 받는 것이 좋습니다.

크기(16, 32, 180px 등)는 어떤 의미인가요?

작은 크기는 브라우저 탭처럼 좁은 자리를 위한 것이고, 180px 전후의 큰 크기는 iOS 홈 화면처럼 넓은 자리를 위한 것입니다. 같은 rel="icon"이라도 sizes 값이 다른 여러 파일이 함께 선언돼 있으면, 브라우저는 지금 그려야 할 자리에 맞는 값을 골라 씁니다. 크기별로 정확히 무엇이 어디에 쓰이는지, 왜 여러 크기가 필요한지는 별도로 다룬 글에서 자세히 설명하고 있으니 참고하면 됩니다. 이 글의 초점은 크기 자체보다 브라우저가 여러 선언 중 무엇을 먼저 찾아 쓰는지입니다.

다른 사이트에서 찾은 아이콘을 제 사이트에 써도 되나요?

권장하지 않습니다. head에 공개돼 있어 누구나 열람할 수 있다는 사실과, 그 파일을 재사용해도 된다는 것은 다른 문제입니다. 아이콘 파일의 저작권은 원저작자에게 있으므로, 본인이 만든 자료가 아니거나 명시적으로 사용을 허락받지 않았다면 그대로 가져다 쓰는 것은 상표권·저작권 문제로 이어질 수 있습니다. 경쟁사 브랜딩을 참고하는 조사 목적 정도로 활용 범위를 한정하는 것이 안전하며, 실제로 제품이나 서비스에 아이콘이 필요하다면 직접 제작하거나 사용 권한이 명확한 소재를 쓰는 편이 뒤탈이 없습니다.

사이트에 아이콘 선언이 하나도 없다고 나오면 어떻게 해야 하나요?

그 사이트가 실제로 아이콘을 전혀 두지 않았거나, 기본 경로인 /favicon.ico에도 파일이 없다는 뜻입니다. 본인이 관리하는 사이트라면 최소한 하나의 아이콘 선언을 head에 추가하는 것이 좋습니다. 아무 선언도 없으면 브라우저 기본 아이콘이 뜨거나 탭이 빈 채로 남아, 다른 탭들 사이에서 눈에 띄지 않게 됩니다. 이미지 한 장으로 필요한 크기의 파비콘 파일을 새로 만들고 싶다면, 추출이 아니라 생성을 해주는 별도 도구를 쓰면 됩니다.