링크 붙여넣을 때 보이는 이미지는 어디서 오는 것일까?
들어가기 전에
이 글은 링크의 미리보기 제목, 설명, 이미지의 정체에 대해서 알고 싶은 마케터들을 위해 유용한 내용을 담고 있습니다.
오늘날 페이스북이나, 네이버 블로그, 카카오톡 등에서 어떤 링크에 대한 미리보기 제목, 설명, 이미지를 제공하고 있습니다. 링크를 붙여넣을 때 생기는 미리보기 제목, 설명, 이미지는 도대체 어디에서 오는 것일까요?
HTML 문서의 head와 메타정보
우리가 보고 있는 웹사이트는 기본적으로 HTML문서라는 사실을 모두 알고 계실겁니다. 이 HTML 문서는 크게는 head와 body라는 두 부분으로 구성되어 있습니다. 이 중 head에는 그 웹페이지를 구성하는 여러 가지 CSS, JavaScript 코드 조각들이나 참조 링크 등이 들어있고, 가장 중요하게는 오늘 다룰 메타 데이터들이 HTML 태그를 통해 담겨있습니다.
여기서 말하는 메타 데이터란 쉽게 말하면 해당 웹페이지를 구성하는 여러 구조화된 정보들 예컨대 제목, 설명, 이미지 등을 아예 명시적으로 웹페이지쪽에서 직접 정해서 표기해준 것을 말합니다. 예를 들어서 아래와 같습니다.
왜 이렇게 직접 표기해줘야 하는가? 크롤러도 하나의 소프트웨어 프로그램인지라 HTML 문서를 보면 자동으로 무엇이 제목인지, 무엇이 내용에 대한 3줄 요약인지, 무엇이 대표 이미지인지 100% 자동으로 판별하기 아주 어렵습니다. 따라서 웹사이트가 직접 저렇게 적어서 알려줘야 하는 것입니다. (아무리 머신러닝, 딥러닝, 자연어처리 기술이 발전해도 웹문서와 같이 비정형적인 정보에 대한 100% 정확도의 의미 인식은 불가합니다.)
그리고 이런 메타 데이터를 표기하는 방법에 대한 기본 방법(기본 HTML5 title, description 태그 등)을 제외한 제 3의 방법 중 비교적 통일되고 인정된 방법으로서 우리가 알아보고자 하는 페이스북의 오픈그래프(Open Graph) 프로토콜이 있고, 이 오픈그래프 프로토콜이 우리가 보는 미리보기 화면의 실체를 구성하는 메타 데이터 표기방법입니다.
결론적으로 우리가 미리보기를 통해 보는 제목, 설명, 이미지는 이렇게 HTML 문서의 head에 표기된 오픈그래프 프로토콜에 의해서 나타나고 있습니다. 그 구체적인 작동 원래는 아래와 같습니다.
사용자가 링크를 입력창에 입력합니다.
페이스북, 네이버 블로그, 카카오톡은 입력창의 문자열이 "링크"라는 것을 파악합니다. (흔히 말하는 정규표현식으로 해당 문자열이 링크라는 것을 알아냅니다.)
링크라는 것이 파악되면 페이스북, 네이버 블로그, 카카오톡의 크롤러는 미리 그 웹사이트를 방문해서 HTML head의 오픈그래프(Open Graph) 메타 데이터를 긁어옵니다.
이중에서도 og:title, og:description, og:image가 각각 제목, 설명, 이미지의 정보를 나타냅니다.
그리고 그 정보를 바탕으로 미리보기 화면을 생성해주게 됩니다.
미리보기의 정체, 페이스북의 오픈그래프 프로토콜
오픈그래프 웹사이트에 가면 아래와 같이 오픈그래프에 대한 간단한 설명이 나와있습니다.
오픈그래프 프로토콜은 페이스북에서 처음 만들어졌으며, Dublin Core, link-rel canonical, Microformats, 그리고 RDFa로부터 영감을 받았습니다. 이 페이지의 설계서는 버전 0.9의 Open Web Foundation Agreement 아래에서 사용 가능합니다. 이 웹사이트는 오픈소스이며, 2014년 10월 20일에 최종 업데이트 되었습니다.
그 간편함으로 인하여 현재는 그 창시자인 페이스북은 물론이고, 네이버 블로그, 카카오톡 등에서도 널리 사용하고 있습니다.
위에서 보듯이 기본적인 메타 데이터로는 제목(title), 설명(description), 대표 이미지(image), 표준 링크(url) 등이 있습니다. (여기서 canonicanl link, 즉 표준 링크란 같은 콘텐츠를 가리키는 여러 개의 URL 중에서 대표 하나의 URL을 말합니다. 이는 현실에 있는 실제 대상들을 가상의 그래프 기반 데이터베이스로 표현하려는 페이스북의 거대한 계획에서 중요한 요소입니다. 왜냐하면 하나의 대상은 원칙적으로 단 하나의 링크만으로 참조되어야 하기 때문입니다.)
이외에도 그 대상에 대한 구조화된(Structure) 데이터를 표현할 수 있는 여러 메타 데이터 표기용 태그들이 지원되고 있습니다. 자세한 것은 오픈그래프 웹사이트에서 확인할 수 있습니다.
웹의 세계에서 오픈그래프가 가지는 위상
오픈그래프는 웹의 세계에서 아주 높은 위상을 가지고 있습니다. 오늘날 웹페이지들이 어떤 기술을 가지고 만들어졌는지를 분석해주는 사이트 builtwith의 통계에 따르면 오픈그래프는 웹문서를 이루고 있는 여러 기술들 중에서 상당히 상위권에 포진하고 있습니다.
정말 기본적이고, 보편적인 JavaScript, CSS까지 포함해도 전체 기술 중 7번째에 올라와 있습니다. 숫자를 보면 대략적으로 상위권 10,000개의 웹사이트 중 약 4,200여 개의 사이트들이 오픈그래프를 사용하고 있는 것을 알 수 있습니다. 온갖 다양한 웹사이트 만드는 기술이 포진하고 있는 웹의 생태계에서 이 정도라면 아주 대단한 유행으로 볼 수 있을 것입니다.
좀 더 풍부한 메타데이터를 지원하는 트위터
그러나 모두가 "페이스북"의 제목, 설명, 이미지 식의 오픈그래프 사용법에 동의하는 것은 아닙니다. 비록 우리가 크게 많이 사용하는 페이스북, 네이버 블로그, 카카오톡 등 대다수의 서비스에서는 오픈그래프 프로토콜에만 준하여 미리보기를 보여주지만 트위터는 이에 더하여 자체적인 메타데이터 표기법을 가지고 있습니다.
만약 트위터에서 제공하는 메타데이터만 있을 경우 자사의 것을 먼저 참조하지만, 오픈그래프만 있을 경우 오픈그래프도 참조하고 있습니다. 그럼에도 불구하고 트위터의 메타 데이터 표기법도 결국에 오픈그래프를 참조한 것입니다.
자세한 내용은 트위터의 개발자 문서를 참조해주세요.
우리 웹사이트의 오픈그래프 적용 여부, 어떻게 알아보나?
페이스북은 오픈그래프에 대한 개발자들과 마케터들의 디버깅을 지원하기 위해 "Sharing Debugger"를 지원하고 있습니다. 사용 방법은 간단합니다.
사이트에 들어가서 검사하고 싶은 링크를 입력하면 됩니다. 그럼 아래와 같이 해당 링크에 대한 분석결과를 받아볼 수 있습니다.
개발자는 고쳤다는데, 왜 미리보기가 바뀌지 않았을까?
프로그래밍의 세계에서 캐싱(Caching)은 반복적으로 호출되는 특정한 데이터를 캐시 메모리에 일종의 "임시"로 저장하여 다음 번에 호출될 때 더 빨리 해당 데이터를 공급해주는 것을 말합니다.
구체적으로는 데이터베이스에 저장된 어떤 정보를 한 번 불러온 후 캐시 메모리에 저장해놓거나, 어떤 HTML, CSS, JavaScript로 이뤄진 웹문서 전체 혹은 이미지 전체를 캐싱하기도 합니다. (전자에는 Memcached, Redis와 같은 시스템들이, 후자는 흔히들 "CDN"이라고 부르는 시스템들이 속할 것입니다.)
우리가 보는 모든 현대적인 웹서비스들, 앱들에는 이러한 캐싱 시스템이 구축되어 있습니다. 페이스북이나 네이버 블로그, 카카오톡 또한 예외가 아닙니다. 사용자들 입장에서는 더 빨리 웹사이트나 이미지가 로딩되서 좋고, 서비스측에서는 데이터베이스 구동에 들어가는 막대한 서버 자원을 절약할 수 있어서 좋습니다.
일반적으로 이런 캐싱에는 TTL(Time-to-Live)라는 소멸시효가 걸려있는데, 이 소멸시효가 지나지 않은 경우 계속적으로 이미 캐싱된 데이터를 참조해서 불러올 수 있습니다.
따라서 실제로 서버에서 내려주는 HTML 웹문서 상의 오픈그래프는 바꼈을지라도, 이미 캐시된 웹문서가 내려지고 있는 상황일 수 있습니다. 즉, 저 TTL이 만료되기 전까지는 아무리 본 서버에서 개발자가 다시 개발해줘도, 미리보기는 바뀌지 않을 것입니다.
이 경우 페이스북은 다행히 캐싱을 리로드할 수 있는 버튼을 "Sharing Debugger"를 통해서 지원하고 있습니다.
카카오스토리의 경우 내부 개발자 도구를 통해서 카카오스토리 링크 정보 얻기 (/v1/api/story/linkinfo)
API 호출을 통해 (외부 호출은 캐싱 번복 안됨) 캐싱을 리로드할 수 있도록 지원하고 있습니다.
클릭 2의 미스터리
미리보기 제목, 설명, 이미지와 관련된 사소한 현상입니다. 가끔 내가 바로 쓴 글을 페이스북에 올리면 바로 조회수가 2로 올라가는 현상을 볼 수 있습니다. 앞서서 말씀드린 것과 같이 크롤러가 우리 사이트를 한 번 "미리" 방문하는 현상 때문에 조회수가 1 올라갑니다.
구글과 같이 방금 방문한 사람이 크롤러라는 것을 명시해주는 경우도 있지만, 페이스북처럼 크롤러라는 것을 전혀 알 수 없게 해놓는 경우도 있습니다. 즉, 미리보기 화면이 로딩되는 것은 곧 나의 웹사이트를 페이스북에서 익명 유저가 1번 방문하는 것과 동일하다는 것을 인지해야 합니다.
결론
최근 카카오톡, 네이버 블로그 등 기존에 오픈그래프를 통한 미리보기를 지원하지 않았던 서비스들이 대거 오픈그래프를 지원하기 시작하면서 점점 더 이 미리보기 페이지에 들어가는 og:title, og:description, og:image를 넣는 것이 중요해지고 있습니다. (네이버 스마트 에디터 3.0 출시 이후부터 오픈그래프 더욱 강조하기 시작)
특히 설치링크라면 더더욱 사소한 문구 하나의 차이가 큰 설치율의 증감을 초래할 수도 있습니다.
따라서 반드시 아래와 같이 하시길 바랍니다.
og:title, og:description, og:image를 HTML의 head에 반드시 넣고, 제대로 반영되었는지를 "Sharing Debugger"를 통해서 확인한다.
실제로 카카오톡, 페이스북, 네이버 블로그 등 사용하고자 하는 마케팅 채널에 링크를 넣고 미리보기 화면을 확인한다. (실제 보여지는 이미지가 사이즈가 각 서비스마다 다르기 때문에 반드시 주의할 것)
가능하다면 A/B 테스팅을 통해서 어떤 문구나 이미지가 가장 좋은 효과를 보이는지 확인한다.
끝으로 에어브릿지 심플링크 서비스는 설치링크에 대한 커스텀 og tag 설정 기능을 제공하고 있습니다. 따라서 개발자와 협의하면서 개발 일정에 맞출 필요가 없습니다. ("og tag 바꿔주세요"라고 메일을 보내거나 회의를 할 필요가 없습니다.)
