og:image와 twitter:image 차이 — 대표 이미지 우선순위 정리

카카오톡이나 슬랙에 링크를 붙여 넣으면 미리보기 카드에 대표 이미지가 뜹니다. 그런데 같은 주소인데도 카카오톡에서 본 이미지와 트위터(X)에서 본 이미지가 서로 다른 경우가 있습니다. 이건 착시가 아니라, 페이지가 og:image와 twitter:image라는 서로 다른 두 태그를 함께 선언해 두고 있어서 실제로 벌어지는 일입니다.

이 글에서는 두 태그 중 어느 쪽이 실제로 우선하는지, 그리고 코드를 열어보지 않고도 어떤 페이지가 어떤 대표 이미지를 선언해 뒀는지 직접 확인하는 방법을 정리합니다. og:image 다운로드나 대표 이미지 추출이라는 이름으로 이 기능을 찾아 들어온 경우라면, 정작 필요한 건 '어떻게 저장하느냐'보다 '어떤 이미지가 진짜 대표 이미지냐'를 먼저 아는 것일 때가 많습니다.

요약 ① 카카오톡·페이스북·슬랙 등 대부분의 공유 서비스는 og:image를 먼저 찾고, og:image가 없을 때만 twitter:image를 대신 찾아 씁니다. ② 한 페이지에 대표 이미지 태그가 여러 개 선언돼 있으면 서비스마다 실제로 보여주는 이미지가 달라질 수 있습니다. ③ 페이지 소스를 직접 뒤지지 않아도, 주소 하나만 넣으면 그 페이지가 선언해 둔 대표 이미지를 그대로 찾아볼 수 있습니다.

같은 주소인데 왜 플랫폼마다 다른 이미지가 뜨는지

블로그나 뉴스레터에 참고할 만한 다른 사이트의 글을 모으다 보면, 그 페이지를 카카오톡으로 공유했을 때 뜨는 대표 이미지와 트위터(X)에 공유했을 때 뜨는 이미지가 서로 다른 경우를 마주치게 됩니다.

분명 같은 URL을 복사해서 붙여 넣었을 뿐인데 플랫폼마다 다른 그림이 뜨니, 어느 쪽이 그 페이지의 '진짜' 대표 이미지인지 헷갈립니다. 둘 중 하나가 잘못된 건지, 아니면 원래 이렇게 설계된 건지부터 판단이 서지 않습니다.

원인을 찾으려고 개발자 도구를 열어 페이지 소스를 확인해 보면 문제가 더 복잡해 보입니다. head 태그 안에는 og:image라는 태그와 twitter:image라는 태그가 각각 따로 있고, 두 태그의 content 값(이미지 주소)이 서로 다른 페이지도 실제로 있습니다. 어느 태그를 기준으로 삼아야 할지, 왜 굳이 이미지 태그를 두 개나 따로 선언해 두는지는 코드만 봐서는 답이 나오지 않습니다.

콘텐츠 기획이나 경쟁사 조사를 할 때도 같은 문제가 반복됩니다. 여러 사이트의 대표 이미지를 참고용으로 모으려는데, 페이지마다 태그 이름과 위치가 달라서 매번 개발자 도구를 열어 눈으로 찾아야 합니다. og:image와 twitter:image의 차이를 모른 채 조사하면, 어떤 이미지를 '그 페이지의 대표 이미지'로 기록해야 할지조차 매번 새로 판단해야 하니 조사 결과의 기준도 흔들립니다.

이미지 태그가 하나뿐이면 그나마 쉽지만, 두 개 이상 있는 페이지를 만나면 그중 실제로 쓰이는 이미지가 무엇인지부터 다시 판단해야 하니 조사 속도가 눈에 띄게 느려집니다.

이런 혼란이 생기는 이유 중 하나는, 애초에 대표 이미지 태그가 og:image 하나뿐이라고 알고 있는 사람이 많기 때문입니다. og:image만 알고 있으면 twitter:image라는 별도 태그의 존재 자체가 낯설고, 두 값이 다를 수 있다는 가능성은 더더욱 생각하지 못합니다. 그러다 실제로 값이 다른 페이지를 마주치면 '둘 중 뭐가 맞는 정보인지' 판단할 기준이 없어 당황하게 됩니다.

이 문제는 남의 사이트를 조사할 때만 생기지 않습니다. 오래전에 만든 자신의 블로그나 회사 소개 페이지를 지금 공유해 봐도 비슷한 혼란을 겪을 수 있습니다. 템플릿을 바꾸거나 CMS를 옮기는 과정에서 og:image만 새로 넣고 twitter:image는 예전 값 그대로 방치해 두는 경우가 실제로 있고, 이러면 카카오톡에서는 새 이미지가, 트위터(X)에서는 옛날 이미지가 뜨는 식으로 자기 사이트 안에서조차 두 결과가 엇갈립니다.

뉴스레터나 큐레이션 콘텐츠를 만드는 실무에서도 이 문제가 반복됩니다. 여러 출처의 링크를 모아 소개 카드를 만들 때, 각 링크의 대표 이미지가 플랫폼별로 다르게 뜬다는 사실을 모르고 작업하면 미리 확인한 화면과 실제 발행 후 화면이 달라지는 경우가 생깁니다.

운영 규모가 커질수록 이 문제는 더 눈에 띕니다. 상품 페이지나 이벤트 페이지를 여러 개 관리하는 마케터라면, 페이지마다 og:image와 twitter:image를 각각 챙겼는지 하나하나 손으로 확인하기 어렵습니다. 그 결과 어떤 페이지는 카카오톡에서는 원하는 이미지가 뜨는데 트위터(X)에서는 예전 이미지나 로고만 뜨는 등, 채널마다 인상이 달라지는 상황이 방치되기 쉽습니다.

이런 불일치는 페이지를 직접 열어봐서는 절대 발견할 수 없다는 점이 더 까다롭습니다. 브라우저로 페이지를 열면 og:image든 twitter:image든 화면에는 아무런 차이 없이 똑같은 본문이 보이기 때문에, 실제로 링크를 공유해 보거나 태그를 하나하나 확인하기 전까지는 문제가 있다는 사실 자체를 알아채기 어렵습니다.

페이지 소스에서 직접 확인하는 방법

직접 확인하는 방법부터 알아봅니다. 확인하려는 페이지에서 마우스 오른쪽 버튼을 눌러 '페이지 소스 보기'를 엽니다(윈도우는 Ctrl+U, 맥은 Cmd+Option+U). 그런 다음 Ctrl+F(맥은 Cmd+F)로 og:image를 검색합니다.

meta property="og:image" content="..." 형태의 줄을 찾았다면 content 안의 주소가 그 페이지가 선언한 첫 번째 대표 이미지입니다. 이어서 twitter:image로도 검색해 봅니다. meta name="twitter:image" content="..." 줄이 따로 있다면, 그 페이지는 두 이미지를 각각 다르게 지정해 둔 것입니다.

두 태그의 주소가 완전히 같다면 더 고민할 필요가 없습니다. 문제는 주소가 서로 다를 때입니다. 이 경우 각 URL을 새 탭에 복사해 붙여 넣어 실제로 어떤 그림인지 하나씩 열어봐야 정확히 비교할 수 있습니다.

주소가 상대경로(예: /images/thumb.png 같은 형태)로 적혀 있으면 그 앞에 도메인 주소를 직접 붙여야 브라우저에서 열립니다. 예를 들어 example.com 페이지에서 이런 상대경로를 발견했다면, https://example.com/images/thumb.png처럼 도메인을 손으로 조합해야 합니다.

한 가지 더 주의할 점이 있습니다. 일부 사이트는 og:image 태그를 서버가 페이지를 내려줄 때부터 넣어 두지 않고, 자바스크립트가 실행된 뒤에야 태그를 추가하는 방식으로 만들어져 있습니다. 이런 페이지는 '페이지 소스 보기'로 열어본 원본 HTML에는 og:image가 안 보이는데, 개발자 도구의 '요소(Elements)' 탭으로 열어본 현재 DOM에는 보이는 경우가 있습니다.

이 차이 때문에 '분명 태그가 있다고 들었는데 소스 보기에는 없다'는 혼란이 생기기도 합니다. 확실하게 확인하려면 페이지 소스 보기와 개발자 도구의 요소 탭을 둘 다 열어 비교해 보는 것이 안전합니다. 다만 카카오톡·페이스북 같은 공유 플랫폼의 크롤러는 자바스크립트를 실행하지 않고 최초로 내려받은 HTML만 읽는 경우가 많으므로, 실제 공유 카드에 반영되는 값은 대개 '페이지 소스 보기' 쪽에 가깝습니다.

완전히 실제 결과를 확인하고 싶다면, 카카오톡의 '나와의 채팅'처럼 자기 자신에게만 보이는 대화방에 링크를 붙여 넣어 실제로 어떤 카드가 뜨는지 직접 확인하는 방법도 있습니다. 다만 이 방법은 카카오톡이 이미 예전에 캐시해 둔 결과를 그대로 보여줄 수도 있어, 페이지 소스의 현재 값과 항상 정확히 일치하지는 않는다는 점을 감안해야 합니다.

모바일 브라우저에서는 페이지 소스 보기 기능이 기본 메뉴에 없는 경우가 많다는 점도 알아둘 만합니다. 급하게 스마트폰에서 확인해야 한다면 주소창에 있는 주소 앞에 view-source: 를 붙여 열어보는 방법이 통하는 브라우저도 있지만, 태그를 안정적으로 비교하려면 데스크톱 브라우저에서 확인하는 편이 훨씬 수월합니다.

여러 사이트를 한 번에 조사해야 하는 상황을 가정해 보면 이 과정의 무게가 더 잘 느껴집니다. 예를 들어 협업 중인 사이트 몇 곳의 대표 이미지를 한꺼번에 정리해야 한다면, 사이트마다 페이지 소스를 열고 og:image·twitter:image를 검색하고 상대경로를 절대경로로 바꾸는 과정을 매번 되풀이해야 합니다. 사이트 하나당 확인 작업에 몇 분씩 걸리더라도, 여러 곳을 한 번에 정리해야 하는 상황이라면 그 시간이 그대로 쌓입니다.

사이트 하나만 확인할 땐 이 방법으로 충분합니다. 하지만 여러 사이트를 연달아 조사하거나, 상대경로를 매번 손으로 조합해야 하는 상황이 반복되면 이 과정이 금방 번거로워집니다. og:image와 twitter:image가 함께 있는지, 값이 같은지 다른지, 자바스크립트로 나중에 삽입되는 태그는 아닌지를 페이지마다 일일이 눈으로 대조하는 일은 사이트 몇 개만 확인해도 꽤 시간이 걸립니다.

직접 해보기 →

이 도구에 주소를 넣으면 og:image·twitter:image 등 페이지에 선언된 대표 이미지 후보를 한 번에 찾아 목록으로 보여주고, 원본 파일 그대로 저장까지 할 수 있습니다. 페이지 소스를 열어 태그를 하나하나 찾고 상대경로를 손으로 조합하는 과정 없이, 주소 하나만 넣으면 끝납니다.

찾아낸 이미지마다 '열기'와 '저장' 버튼이 함께 뜹니다. '열기'를 누르면 새 탭에서 원본 이미지를 그대로 볼 수 있고, '저장'을 누르면 파일로 바로 내려받을 수 있어, 여러 후보 이미지를 하나씩 직접 열어보며 비교하던 수동 확인 과정을 그대로 대체합니다.

og:image가 twitter:image보다 먼저 확인되는 이유

왜 굳이 og:image와 twitter:image라는 별도의 태그가 존재하고, 그중 하나가 우선권을 갖도록 굳어졌는지 이해하려면 '누가 이 태그를 읽는가'부터 봐야 합니다.

카카오톡·페이스북·슬랙처럼 링크를 공유했을 때 미리보기 카드를 그려주는 대부분의 서비스는 og:image 태그를 먼저 찾습니다. 그리고 og:image가 없을 때만 twitter:image를 대신 찾아 쓰는 방식으로 동작합니다. 즉 og:image는 사실상의 '기본값'이고, twitter:image는 그 기본값이 없을 때를 대비한 '대체값'에 가깝습니다.

og:image의 'og'는 오픈그래프(Open Graph)라는 공유용 메타 태그 규격의 줄임말입니다. 이 규격이 여러 플랫폼에서 폭넓게 통용되다 보니, 자체적으로 별도의 카드 규격을 쓰는 서비스에서도 og:image가 없으면 예비값으로 twitter:image를 참조하는 방식이 자리를 잡았고, 그 결과 og:image가 사실상의 기본값 역할을 하게 되었습니다.

참고로 브라우저에서 직접 링크를 열었을 때 보이는 화면과, 메신저·SNS에 공유했을 때 뜨는 미리보기 카드는 완전히 다른 경로로 만들어집니다. 브라우저는 페이지 전체를 렌더링해서 보여주지만, 공유 카드는 페이지 전체가 아니라 og:image·twitter:image처럼 미리 지정된 몇 개의 태그 값만 따로 뽑아 작은 카드 형태로 재구성한 결과물입니다. 그래서 페이지를 아무리 꼼꼼히 훑어봐도 대표 이미지가 화면 어디에 있는지 눈으로는 찾을 수 없는 경우가 많고, 결국 태그 자체를 확인하는 방법밖에 없습니다.

그래서 페이지를 운영하는 입장에서는 두 태그를 굳이 다 채워 넣을 이유가 생깁니다. og:image 하나만 정확히 선언해 두면 대부분의 서비스에서 문제없이 미리보기가 뜨지만, 혹시라도 og:image 인식에 실패하는 예외적인 상황에 대비해 twitter:image까지 함께 선언해 두는 일종의 안전장치로 쓰는 셈입니다.

두 태그에 똑같은 이미지 주소를 넣어 두는 사이트가 많은 것도 이 때문입니다. 어느 쪽을 읽든 결국 같은 그림이 나오게 만들어 두면, 플랫폼마다 다른 카드가 뜰 걱정을 처음부터 없앨 수 있습니다.

문제는 두 태그에 서로 다른 이미지 주소를 넣어 둔 페이지입니다. 이런 페이지는 실제로 존재하며, 이는 페이지 하나가 대표 이미지 후보를 하나 이상 선언해 두고 있다는 뜻입니다.

실제로 이 도구로 깃허브(github.com) 주소를 분석해 보면, og:image 라벨의 PNG 파일 하나와 별도로 두 번째 대표 이미지 파일이 JPG 형식으로 함께 확인됩니다. 즉 한 페이지 안에 대표 이미지로 쓸 수 있는 후보가 한 개 이상 선언돼 있는 경우가 실제로 있다는 뜻이고, 이럴 때는 서비스마다 어느 후보를 골라 보여줄지가 곧 우선순위 문제가 됩니다.

이처럼 후보가 여러 개인 페이지에서는, og:image를 우선 참조하는 서비스에서는 og:image 쪽 그림이 뜨고, 예외적으로 다른 값을 먼저 확인하는 서비스가 있다면 그쪽에서는 다른 그림이 뜰 수 있습니다. 같은 URL을 공유해도 어디서 보느냐에 따라 카드 이미지가 달라 보이는 현상은 착시가 아니라, 애초에 페이지가 그렇게 선언해 두었기 때문에 생기는 결과입니다.

이 우선순위 이야기는 og:image 값 자체가 최신 이미지를 정확히 가리키고 있다는 전제 위에서 성립합니다. 반대로 배포 직후 미리보기가 예전 이미지로 그대로 보이는 문제는 이 우선순위와는 결이 다른 별개의 현상입니다. 이는 태그 값이 잘못된 게 아니라, 카카오톡이나 페이스북 같은 서비스가 예전에 한 번 읽은 결과를 자체 캐시에 저장해 두고 재사용하기 때문에 생깁니다.

두 태그가 모두 없는 페이지도 있습니다. 오래전에 만들어졌거나 대표 이미지를 따로 신경 쓰지 않고 제작된 페이지라면 og:image도 twitter:image도 선언돼 있지 않을 수 있습니다. 이런 페이지를 도구로 분석하면 '이미지를 찾지 못했다'는 결과가 뜹니다. 이는 도구가 실패한 게 아니라, 애초에 그 페이지에 참조할 대표 이미지 태그 자체가 없다는 뜻입니다.

태그가 아예 없는 경우와, 태그는 있지만 값이 빈 상태로 남아 있는 경우는 구분할 필요가 있습니다. content 값이 비어 있으면 태그 자체는 존재해도 실질적으로는 가리키는 이미지가 없는 것과 같은 결과로 이어지고, 이런 페이지 역시 이미지를 찾지 못한 것으로 처리됩니다. 즉 태그의 '존재 여부'가 아니라 '실제로 유효한 값을 담고 있는지'가 판단 기준입니다.

이 세 가지 결과(og:image 발견, twitter:image로 대체, 둘 다 없음)만 구분할 줄 알면, 어떤 페이지를 만나든 대표 이미지와 관련된 상황을 셋 중 하나로 정리해서 이해할 수 있습니다. 복잡해 보이는 문제도 결국은 이 단순한 분기 안에서 벌어지는 일입니다.

정리하면 우선순위는 og:image가 먼저, twitter:image가 그다음, 그리고 둘 다 없으면 대표 이미지 없음이라는 세 단계로 이해하면 됩니다. 이 순서를 알고 나면, 같은 링크가 플랫폼마다 다르게 보이는 이유도, 특정 페이지에서 대표 이미지가 아예 안 뜨는 이유도 코드를 몰라도 설명할 수 있습니다.

이 우선순위를 알면 페이지를 직접 운영할 때 무엇부터 채워야 하는지도 명확해집니다. 시간이 없어 태그를 하나만 관리해야 한다면 og:image를 먼저 정확하게 채우는 쪽이 효율적입니다. twitter:image는 og:image가 실패했을 때를 대비한 두 번째 방어선이지, 평소에 더 자주 참조되는 태그는 아닙니다.

반대로 이미 두 태그를 모두 채워 둔 페이지라면, 굳이 값을 다르게 유지할 이유가 크지 않은 이상 같은 이미지 주소로 통일해 두는 편이 관리하기도 쉽고 결과도 예측하기 쉽습니다. 두 값이 다르면 다를수록, 어느 플랫폼에서 보느냐에 따라 결과가 갈리는 경우의 수가 늘어나기 때문입니다.

조사자 입장에서는 이유보다 결과가 중요합니다. 어떤 페이지가 왜 두 태그에 서로 다른 이미지를 걸어 두었는지는 페이지마다 사정이 다를 수 있지만, 지금 이 순간 어떤 이미지가 og:image로, 어떤 이미지가 나머지 후보로 선언돼 있는지는 도구로 바로 확인할 수 있는 사실입니다. 우선순위 규칙만 알고 있으면 이 결과만으로도 실제로 어떤 이미지가 카드에 뜰지 충분히 예측할 수 있습니다.

여러 사이트의 대표 이미지를 참고용으로 모아 콘텐츠를 기획하는 상황이라면 이 우선순위가 더 중요해집니다. 사이트마다 og:image와 twitter:image 중 무엇을 기준으로 삼아야 할지 매번 고민하는 대신, 항상 og:image를 기준값으로 놓고 필요할 때만 twitter:image를 보조로 확인하는 식으로 조사 순서를 통일하면 여러 사이트를 비교할 때도 일관된 기준을 유지할 수 있습니다.

og:image와 twitter:image 비교

두 태그의 성격을 표로 정리하면 다음과 같습니다.

이 표에서 가장 중요한 줄은 '확인 순서'입니다. 페이지를 직접 관리하는 입장이라면 og:image 하나만 정확히 채워 넣어도 대부분의 공유 상황을 커버할 수 있고, twitter:image는 예외 상황을 대비한 보조 장치로 이해하면 됩니다.

반대로 다른 사이트의 대표 이미지를 조사하는 입장이라면, 두 값이 같은지 다른지부터 확인하는 것이 조사의 첫 단계입니다. 값이 다르다면 그 페이지는 의도적으로 두 개의 후보를 각각 다르게 준비해 둔 것이므로, 어느 쪽이 실제로 눈에 띄는 이미지인지 우선순위를 기준으로 판단할 수 있습니다.

화질 면에서도 짚어둘 부분이 있습니다. 카카오톡이나 페이스북 같은 플랫폼은 공유 카드를 그릴 때 원본 이미지를 자체 서버 사정에 맞게 압축하거나 리사이즈해서 보여주는 경우가 많습니다. 화면에 보이는 미리보기 카드의 이미지가 원본과 화질이 다를 수 있다는 뜻입니다.

반면 도구로 저장하는 파일은 og:image·twitter:image 태그의 content 값이 가리키는 주소에서 그대로 받아오는 방식입니다. 플랫폼이 카드용으로 압축한 버전이 아니라, 페이지가 원래 선언해 둔 원본 파일에 더 가깝습니다. 조사나 자료 보관이 목적이라면 이 차이가 실제로 중요할 수 있습니다.

실전에서는 이렇게 판단하면 됩니다. 카카오톡·페이스북 등 대부분의 채널에 신경 쓴다면 og:image 값을 기준으로 삼고, 유독 트위터(X) 카드에서만 다른 이미지가 보인다는 제보를 받았을 때 twitter:image 값을 별도로 점검하는 순서가 효율적입니다. 두 값을 처음부터 비교해 두면, 나중에 어느 플랫폼에서 문제가 생기든 원인을 바로 짚을 수 있습니다.

이 차이가 실제로 문제가 되는 순간은 대개 '어느 한쪽 채널에서만 이상하다'는 제보를 받았을 때입니다. 카카오톡에서는 멀쩡한데 트위터(X)에서만 이상하다면 twitter:image를, 반대라면 og:image를 먼저 의심하면 됩니다. 두 값이 어차피 같다면 애초에 이런 제보 자체가 생기지 않으므로, 값이 다른 페이지에서만 신경 쓰면 충분합니다.

자주 막히는 지점

조사나 확인 과정에서 자주 걸리는 지점을 정리했습니다. 대부분은 도구를 잘못 쓴 게 아니라, 페이지가 태그를 어떻게 선언해 두었는지에 따라 자연스럽게 나타나는 결과입니다.

표에 정리된 항목 대부분은 도구의 오류가 아니라 페이지가 애초에 어떤 태그를 어떻게 선언해 두었는지에서 비롯됩니다. 결과가 이상하게 보인다면 먼저 그 페이지의 태그 자체가 무엇을 가리키고 있는지부터 확인하는 것이 순서입니다. 카카오톡 캐시 문제만은 예외적으로 태그가 아니라 플랫폼 쪽 사정이므로, 태그 값을 아무리 정확히 고쳐도 해결되지 않고 별도의 캐시 갱신 절차가 필요합니다.

다운로드한 이미지, 저작권은 어떻게 되나

이 도구가 가져오는 이미지는 페이지가 이미 공개적으로 선언해 둔 대표 이미지입니다. 로그인이 필요하거나 비공개로 설정된 콘텐츠까지 우회해서 가져오는 기능은 아니며, 누구나 그 페이지에 접속하면 볼 수 있는 공개된 이미지만 찾아 보여줍니다. 접근 자체가 제한된 페이지는 애초에 태그를 읽어올 수 없으므로 분석 대상에서 자연히 제외됩니다.

다만 화면에 보인다고 해서 자유롭게 써도 된다는 뜻은 아닙니다. 다운로드한 파일의 저작권은 여전히 그 이미지를 원래 만든 사람이나 페이지 운영자에게 있습니다. 콘텐츠 기획이나 경쟁사 조사를 위해 참고용으로 잠깐 확인하고 보관하는 것과, 그 이미지를 자신의 콘텐츠에 그대로 가져다 쓰는 것은 완전히 다른 문제입니다.

실제로 사용하려면 그 이미지가 본인이 직접 올린 자료이거나, 저작권자에게 명확히 허락을 받은 경우처럼 개인적이고 합법적인 범위 안에서만 활용해야 합니다. 별다른 확인 없이 다른 사이트의 대표 이미지를 그대로 재업로드하거나 재배포하면 저작권 침해로 이어질 수 있습니다.

또 하나 유의할 점은, 공개된 페이지의 대표 이미지라고 해서 그 안에 담긴 내용까지 자유롭게 다뤄도 된다는 뜻은 아니라는 것입니다. 예를 들어 개인 블로그의 프로필 사진이나 특정 인물이 담긴 사진이 og:image로 지정된 경우도 있는데, 이런 이미지는 저작권뿐 아니라 초상권 문제까지 겹칠 수 있습니다.

조사·기획 단계에서 잠깐 참고하는 것과, 그 이미지를 다른 콘텐츠에 노출시키거나 인물이 드러나는 형태로 재배포하는 것은 전혀 다른 이야기입니다. 특히 상업적으로 활용할 계획이라면 원저작자는 물론 이미지에 등장하는 인물에게도 확인을 거치는 것이 안전합니다.

예를 들어 경쟁사 제품 페이지를 조사하다가 마음에 드는 대표 이미지를 발견했다고 해서, 그 이미지를 그대로 자신의 글이나 제품 페이지의 og:image로 다시 쓰는 것은 명백히 다른 문제입니다. 이런 경우는 단순 참고가 아니라 원저작물을 그대로 가져다 쓰는 것에 해당하므로, 별도의 라이선스 확인이나 허락 없이는 피해야 합니다.

정리하면 이 도구는 '어떤 페이지가 어떤 이미지를 대표 이미지로 선언해 뒀는지' 눈으로 빠르게 확인하는 조사 도구에 가깝습니다. 찾아낸 이미지를 실제로 어디에, 어떻게 쓸지는 저작권 확인을 거친 뒤 별도로 판단해야 하는 부분입니다.

비슷한 도구와 무엇이 다른가

대표 이미지를 확인하는 방법으로는 이 밖에도 몇 가지가 더 있는데, 목적이 조금씩 다릅니다. 이름이 비슷해 보여도 '내 사이트의 태그를 점검·갱신하는 도구'와 '이미 존재하는 이미지를 찾아 저장하는 도구'는 쓰임새가 갈립니다.

페이스북이 제공하는 공유 디버거나 카카오 디벨로퍼스의 캐시 갱신 도구는 '내 사이트'의 og 태그가 제대로 인식되는지 점검하고, 필요하면 그 플랫폼의 캐시를 강제로 새로고침하는 용도입니다. 이런 도구는 대체로 자기 소유의 사이트를 관리할 때 쓰며, 다른 사이트의 이미지를 저장하는 기능은 없습니다.

같은 사이트 안에 있는 '오픈그래프 미리보기' 도구도 성격이 다릅니다. 이 도구는 주소를 넣으면 og:title·og:description·og:image 같은 태그가 실제로 카카오톡 카드처럼 어떻게 그려지는지 미리 보여주고, 태그가 누락돼 있으면 알려주는 데 초점이 있습니다. 즉 '내 사이트의 태그가 빠짐없이 잘 채워져 있는가'를 점검하는 도구입니다.

반면 이 글에서 다루는 대표 이미지 다운로드 도구는 이미 존재하는 이미지 파일 자체를 찾아 저장하는 데 초점이 있습니다. 태그가 카드로 어떻게 그려지는지가 아니라, og:image·twitter:image가 각각 어떤 파일을 가리키고 있는지, 그리고 그 파일을 원본 그대로 받아볼 수 있는지가 핵심입니다.

브라우저의 개발자 도구로 직접 페이지 소스를 뒤지는 방법과 비교하면, 이 도구는 태그를 찾고 상대경로를 절대경로로 바꾸는 반복 작업을 대신해 준다는 차이가 있습니다. 결과 자체는 페이지 소스에 이미 적혀 있는 값과 동일하며, 도구가 없는 이미지를 만들어내거나 다른 이미지로 바꿔치기하지는 않습니다.

카카오톡 안에서 공유 카드의 이미지를 우클릭해 저장하는 방법과 비교해도 차이가 있습니다. 그 방식으로 저장되는 파일은 카카오톡이 카드용으로 리사이즈·압축한 버전인 경우가 많은 반면, 이 도구는 태그가 가리키는 원본 주소에서 파일을 그대로 받아옵니다.

페이지를 화면 그대로 캡처하는 스크린샷 방식과도 성격이 다릅니다. og:image는 화면에 크게 보이는 배너 이미지가 아니라 페이지 코드 안에만 선언돼 있는 경우도 많아서, 화면을 아무리 스크롤하며 찾아봐도 눈에 띄지 않을 수 있습니다. 이 도구는 화면에 보이는 모습이 아니라 코드에 선언된 값을 기준으로 찾기 때문에, 화면 캡처로는 얻을 수 없는 결과를 보여줍니다.

참고로 이 사이트에는 성격이 비슷하지만 목적이 다른 다운로드 도구가 몇 가지 더 있습니다. 웹페이지 안의 이미지를 통째로 모아 압축 파일로 받는 도구는 대표 이미지 하나가 아니라 본문에 실린 이미지 전체를 대상으로 하고, 사이트 아이콘을 모으는 도구는 og:image가 아니라 파비콘·애플 터치 아이콘처럼 브라우저 탭이나 홈 화면에 쓰이는 아이콘을 대상으로 합니다.

세 도구 모두 '페이지에 선언된 이미지를 찾아 저장한다'는 기본 동작은 비슷하지만, 어떤 태그·어떤 용도의 이미지를 대상으로 삼느냐가 다릅니다. 지금 필요한 게 공유 카드용 대표 이미지 하나뿐이라면 이 도구가 가장 빠르고, 페이지 전체의 이미지 자료가 필요하다면 이미지 일괄 다운로드 쪽이 더 맞으며, 브라우저 탭이나 즐겨찾기에 쓰이는 아이콘이 필요하다면 파비콘 다운로드 쪽이 목적에 맞습니다.

정리

지금까지 살펴본 내용을 다시 정리합니다. og:image와 twitter:image는 둘 다 대표 이미지를 지정하는 태그이지만, 실제로 작동하는 순서와 역할은 명확히 다릅니다.

• 대부분의 공유 서비스는 og:image를 먼저 확인하고, og:image가 없을 때만 twitter:image를 대신 확인합니다.
• 두 태그의 값이 서로 다른 페이지는 실제로 있으며, 이 경우 플랫폼마다 다른 대표 이미지가 뜰 수 있습니다.
• 둘 다 없는 페이지는 '이미지를 찾지 못했다'로 처리되는 것이 정상이며 도구 오류가 아닙니다.
• 값이 다른지 같은지는 페이지 소스를 직접 열어봐도 되고, 도구로 주소 하나만 넣어도 바로 확인할 수 있습니다.
• 찾아낸 이미지는 저작권이 원저작자에게 있으므로 참고용으로만 확인하고, 실제로 쓰기 전에는 별도로 허락 여부를 확인해야 합니다.

결국 핵심은 '어떤 태그가 있느냐'가 아니라 '어떤 태그가 먼저 읽히느냐'입니다. 이 순서만 기억해 두면 같은 링크가 플랫폼마다 다르게 보이는 상황도, 대표 이미지가 아예 안 뜨는 상황도 더는 낯설게 느껴지지 않을 것입니다.

자주 묻는 질문

og:image와 twitter:image 중 뭐가 더 중요한가요?

서비스 대부분이 og:image를 먼저 확인하고, 없을 때만 twitter:image를 대신 씁니다. 그래서 페이지 하나만 관리한다면 og:image를 우선 정확히 채워 넣는 것이 실질적으로 더 중요합니다. 두 값을 같은 이미지로 맞춰 두면 어느 서비스에서 봐도 같은 카드가 뜨므로, 굳이 값을 다르게 관리할 이유가 없다면 통일해 두는 편이 관리하기도 편합니다.

두 태그의 이미지 주소가 다른 페이지가 실제로 있나요?

있습니다. 대표 이미지 후보를 하나 이상 선언해 둔 페이지가 실제로 존재하며, 이런 경우 어떤 서비스로 공유하느냐에 따라 다른 그림이 뜰 수 있습니다. 도구로 주소를 분석하면 이런 차이를 페이지 소스를 직접 뒤지지 않고도 눈으로 바로 확인할 수 있습니다. 값이 다르게 나온다면 og:image 쪽이 대부분의 채널에서 우선 반영된다고 보면 됩니다.

og:image도 twitter:image도 없는 페이지는 어떻게 되나요?

도구에서는 '이미지를 찾지 못했다'로 표시됩니다. 이는 도구가 실패한 게 아니라, 그 페이지 자체에 대표 이미지를 선언한 메타 태그가 없다는 뜻입니다. 이런 페이지를 공유하면 서비스에 따라 이미지 없는 카드가 뜨거나, 본문 속 임의의 이미지가 대신 쓰이기도 합니다. 페이지 운영자라면 og:image 태그를 새로 추가하는 것이 가장 확실한 해결책입니다.

방금 바꾼 이미지가 카카오톡에서 안 보여요. 이 글과 관련 있나요?

다른 문제입니다. 태그 자체는 바뀌었어도 카카오톡 같은 플랫폼이 예전에 읽어둔 결과를 캐시로 저장해 재사용하는 경우입니다. 이는 태그 우선순위가 아니라 캐시 문제이므로, 해당 플랫폼이 제공하는 캐시 갱신 도구로 따로 해결해야 합니다. 이 도구는 현재 태그 값을 그대로 보여줄 뿐, 플랫폼의 캐시까지 갱신해 주지는 않습니다.

이 도구로 다른 사이트 이미지를 저장해도 되나요?

공개된 페이지에 이미 노출돼 있는 이미지를 참고용으로 확인하고 보관하는 용도입니다. 다운로드한 파일의 저작권은 원저작자에게 있으므로, 본인 자료가 아니거나 권리자의 허락이 없다면 재사용이나 재배포는 저작권 침해가 될 수 있습니다. 조사·기획 단계의 개인적인 참고 용도로만 활용하는 것이 안전합니다.

상대경로로 된 이미지 주소는 어떻게 확인하나요?

페이지 소스에서 상대경로(예: /img/thumb.png)를 발견하면 그 앞에 도메인 주소를 직접 붙여 절대경로로 만들어야 브라우저에서 열립니다. 도구를 쓰면 이 과정 없이 처음부터 절대경로로 정리된 결과를 바로 받아볼 수 있어, 여러 사이트를 연달아 확인할 때 특히 편리합니다.

내 사이트의 og:image가 제대로 선언됐는지 확인하려면요?

이 도구는 이미 있는 이미지를 찾아 저장하는 용도에 가깝습니다. 자신의 사이트 태그가 빠짐없이 선언됐는지, 카카오톡 카드가 실제로 어떻게 그려지는지까지 점검하려면 오픈그래프 미리보기 도구로 직접 확인하는 편이 더 적합합니다. 두 도구를 함께 쓰면 태그 점검과 이미지 저장을 모두 처리할 수 있습니다.