밤새워 정성껏 녹음하고 편집한 오디오 콘텐츠가 검색결과 구석에 처박혀 있다면, 로봇이 전혀 알아들을 수 없는 외계어로 허공에 소리치고 있는 셈입니다.
핵심은 번역입니다. 네이버와 구글의 검색로봇은 인간의 귀를 가지지 않았습니다. 이들에게 내 웹 문서가 '단순한 글'인지, 아니면 '15분짜리 생생한 현장 오디오 파일'인지 정확히 떠먹여 주는 친절한 통역기. 그게 바로 구조화된 데이터가 존재하는 진짜 이유입니다.
막상 해보면 이게 제일 먼저 무너집니다
가까운 지인이 백색소음과 자연의 소리를 기록하는 웹사이트를 꽤 오래 운영했습니다. 나름 직접 발품을 팔아 녹음한 고음질 mp3 파일도 올리고, 텍스트도 꽉꽉 채워 넣었죠. 근데 방문자 수가 도무지 늘지 않더군요. 뼈를 깎는 고통.
솔직히 옆에서 지켜보는 저조차 안타까울 지경이었습니다. 사실 콘텐츠 자체는 무척 훌륭했습니다. 단지 네이버 검색로봇이 그 글 안에 담긴 미디어의 가치를 전혀 해석하지 못하고 자동 수집 단계에서 누락시키고 있었을 뿐이죠.
다양한 정보를 담고 있는 콘텐츠를 논리적으로 조직화해서 가공된 데이터로 만들지 않으면, 로봇 입장에서는 그냥 까만 건 글씨고 하얀 건 바탕화면일 뿐이거든요. 뭐랄까, 가장 대표적으로 관계형 데이터베이스를 떠올리면 쉽습니다. 표에 맞춰서 이름표를 척척 붙여줘야 비로소 로봇이 소화를 시작합니다.
웹 콘텐츠도 이렇게 구조화된 데이터로 정의해 보자는 노력은 아주 오래전부터 있었습니다. 인터넷 커뮤니티와 여러 관련 업체들이 기초 작업을 꾸준히 해왔고, 그 결과물이 바로 schema.org라는 사이트를 통해 전파되고 있죠. 웹 표준 기구인 W3C 내에서 공식적으로 편입될 정도로 족보 있는 규칙입니다.
실전 적용: 오디오 파일에 JSON-LD 심어보기
코딩 지식이 1도 없던 지인은 처음에 지레 겁을 먹었습니다. 마크업인가 먼가 하는 용어부터가 너무 딱딱했으니까요. 언어 형식에는 크게 Microdata, RDFa, JSON-LD 세 가지가 지원되는데 네이버에서는 널리 쓰이는 Microdata나 JSON-LD를 권장합니다. 지인은 가장 직관적인 JSON-LD 형식을 선택했습니다.
복잡해 보이지만 그냥 빈칸 채우기 게임입니다. 아래와 같은 형태의 텍스트를 메모장에 복사해 놓고 내 오디오 정보로 바꿔주기만 하면 됩니다.
"@context": "http://schema.org",
"@type": "AudioObject",
"name": "12oclock_girona.mp3",
"description": "Recorded on a terrace of Girona a sunday morning",
"contentUrl": "http://media.freesound.org/data/...",
"duration": "T0M15S",
"encodingFormat": "mp3"
· 데이터 타입(type): 웹 페이지 특성을 정의합니다. 오디오 콘텐츠이므로 AudioObject를 적습니다. (필요하다면 2개 이상의 데이터 타입을 조합할 수도 있습니다.)
· 속성(property): 재생 시간(duration)은 얼마나 되는지, 파일 형식(encodingFormat)은 무엇인지 세부 정보를 적습니다.
네이버의 차가운 경고장, 그리고 진짜 승부
코드를 페이지에 심어놓고 친구는 매일같이 네이버 검색결과 창만 새로고침했습니다. 무언가 화려한 오디오 스니펫이 뜰 줄 알았겠죠. 하지만 며칠이 지나도 묵묵부답이었습니다. 트래픽은 여전히 바닥. 그래서 망했습니다.
도대체 뭐가 문제일까 싶어 네이버의 공식 문서를 아주 꼼꼼히 다시 들여다봤습니다. 거기에 뒤통수를 치는 차가운 문장이 하나 숨어 있더군요.
아무리 구조화된 데이터를 정상적으로 마크업했을 경우라도 검색결과 반영을 완벽하게 보장하지는 않습니다. 페이지 내 실제 콘텐츠의 맥락과 가장 적합하다고 판단될 때만 검색로봇이 이를 활용해 다른 부가 정보를 노출시킵니다.
코드는 그저 거들 뿐, 내가 입력한 속성값과 실제 본문의 질이 완벽하게 일치해야 한다는 뜻입니다. 껍데기만 화려하게 포장한다고 로봇이 속아 넘어가는 시대가 아니니까요.
오류를 먼저 잡는 자가 살아남는다
지인은 다시 마음을 다잡고 근본적인 문제부터 짚어보기 시작했습니다. 가장 먼저 한 일은 본인이 작성한 코드를 검증하는 거였죠. schema.org에서 공식적으로 제공하는 '구조화된 데이터 테스팅 도구'를 띄워놓고 자신의 코드를 돌려봤습니다.
아니나 다를까, 쉼표 하나를 빼먹고 재생 시간 규격을 잘못 적어서 도구 화면에 빨간색 에러 메시지가 수두룩하게 뜨더라고요. 이렇게 작은 오탈자나 속성 누락을 찾아내는 작업. 이건 올바로 적용되었는지 확인하기 위한 생존의 필수 요건입니다.
공개된 테스팅 도구로 꼼꼼하게 뼈대를 교정하고, 텍스트 내용과 데이터 속성이 정확히 맞아떨어지기 시작한 시점. 어느 날 갑자기 지인의 오디오 포스팅이 완전히 다른 형태를 띠며 검색 최상단에 노출되기 시작했습니다. 흔해 빠진 텍스트 나열이 아니라, 오디오 재생 시간과 세부 정보들이 풍성하게 곁들여진 리치 결과로 말이죠.
글만 길게 쓴다고 알아서 찾아와 읽어주는 낭만적인 시대는 끝났습니다. 검색엔진의 언어를 이해하고, 그들이 소화하기 가장 좋은 형태의 논리적인 구조표를 내미는 사람. 오직 그 사람만이 수많은 정보의 바다에서 돋보이는 나만의 자리를 쟁취할 수 있습니다. 지금 바로 테스팅 도구를 열고 내 사이트의 번역 상태를 점검해 보세요.