Share           Pin It
 메타블로그나 검색엔진 등을 통해서 이 글이 머신런닝에서 말하는 EM (Expectation Minimization) 알고리즘에 대한 포스팅인 걸로 생각/기대하고 들어오신 분들에게는 먼저 죄송하다는 말을 전합니다. 이 글은 EM 알고리즘에 대한 것이 아닙니다. EM 알고리즘을 기대하셨던 분들에게는 제가 이 포스팅을 통해서 말하려던 바가 완전히 실패한 것입니다. 저는 여러분들이 가졌던 그런 기대와, 실제 제품/서비스들이 그런 기대를 충족시키느냐에 따른 고객만족 Satisfaction에 대한 글을 적으려고 합니다. (참고. 그렇지만, 제목에 사용한 Expectation Minimization은 분명 EM알고리즘에서 차용한 표현입니다.)

 많은 서비스나 제품들을 출시하면서 기업들은 고객 만족의 정도를 측정하려고 합니다. 고객이 만족했다면 제대로된 서비스/제품의 기획/생산/출시일테고, 그렇지 못하다면 실패한 것입니다. 고객이 만족했다면, 소위 최근의 소셜마케팅/버징에서 얘기하듯이, 만족한 고객들에서 시작해서 제품/서비스에 대한 입소문이 타기 시작하고, 그런 입소문이 점점 번져서 더 큰 성공 (제품의 판매 및 서비스 이용자의 증가 등)으로 이러질 것입니다. 그런데, 이런 만족도를 측정하는 것이 말처럼 쉽지가 않습니다. 만족도를 측정하는 것이 어려운 이유는 모든 고객들이 다른 가치기준을 가지고 서비스/제품의 품질이나 만족도를 평가하기 때문입니다. 즉, 주관적인 만족도를 객관적인 수치로 표현하다는 것 자체가 어불성설일 수도 있습니다. 일단 주관도를 제외하더라도, 각 고객들이 처음에 서비스/제품을 접할 때 기대하는 기채치/기대수준이 모두 다르다는 것입니다. 그런 기대치를 상향시키면 고객들은 만족할 것이고, 그렇지 못하면 고객들은 실망할 것입니다. 이런 고객의 기대치와 만족도를 도식화하려던 시도가 있었습니다. 바로 Kano Model입니다. 

 Kano 모델은 이름에서 유추되듯이 1980년대에 Noriaki Kano 교수님에 의해서 처음 개발되어서 전파된 개념입니다. (대학에서 품질공학을 배우면 잠시 언급되는 모델입니다.) (카노모델에 대한 위키피디어 바로가기) 앞서 하이퍼링크한 위키피디어의 내용을 보시면, 카노모델을 바로 이해할 수 있습니다. 그래도, 짧게 설명한다면 고객의 만족도는 기본적으로 기대치 (기본기능)에 비례한다는 것입니다. 처음에 고객들이 어떤 제품/서비스가 제공해줄 것이라는 기능을 만족시키면 그것에 비례해서 고객의 만족도가 증가합니다. 바로 아래의 그림에서 파란색선이 보여주는 바입니다. 기본 기능에 충실하면 고객의 기대는 선형으로 증가하고, 그렇지 못하면 선형으로 감소하게 됩니다. 그런데, 카노모델에서 중요한 것은 선형의 파란색선이 아니라, 붉은색선과 녹색선이 나타내는 바입니다. 붉은색선은 기본 전체가 제품/서비스가 기본기능에는 충실할 때, 더 부가적인 기능을 제공해주면 고객들의 만족도가 선형이 아니라 비선형으로 증가하게 된다는 것을 뜻합니다. 즉, 고객이 예상/기대하지 못했던 새로운 기능이 추가되면 고객들은 만족한다는 것입니다. 붉은색선이 만족도의 양의 positive 영역에만 존재한다는 것도 주목할 것입니다. 즉, 그런 부가기능의 제공여부는 고객의 기본기대치/만족도에는 영향을 주지 않는다는 것입니다. 반대로, 녹색선이 보여주듯이 고객이 처음부터 제품/서비스에 기대했던 기본 기능을 충족시키지 못하면 파란색처럼 선형으로 만족도가 감소하는 것이 아니라 그 이상의 실망을 안겨주게 됩니다. (설명이 조금 잘못된 부분이 있을 수 있습니다.) 요약하면, 기본기능을 만족시키지 못하면 제품/서비스의 만족도는 크게 떨어지고, 기본기능만을 만족시키면 만족도는 선형으로 증가하고, 기본기능을 만족시키면서 부가기능까지 제공된다면 만족도가 기하급수적으로 증가한다는 것입니다. 여담이지만, 현재 출시되면 많은 서비스들 (제가 다니는 회사를 포함해서)이 기본기능을 만족시키지도 못하면서, 불필요한 부가기능들의 제공에 몰두하는 현상을 볼 수가 있습니다. 부가기능으로 인해서, excitement가 증가할 것으로 기대하겠지만, 기본에 충실하지 못하는 제품/서비스는 결국 고객실망으로 연결되게 됩니다.

위키피디어에 실린 카노모델을 설명하는 그래프 (GIF 그림을 그냥 가져왔는데, 투명GIF네요. 블로그 바탕이 검은색이라OTL. 죄송하지만 그림은 클릭해서 큰 사진으로 보세요.)



 최근에 다음검색에서 개편한 사항을 가지고 얘기를 해보고자 합니다. 첫번째 사례는 벌써 1년도 더 전에 개편한 사항이고, 두번째는 2~3개월 전에 개편한 내용입니다.

 첫번째 사례는 바로 내부적으로 '라인업'이라고 불린 프로젝트입니다. 당시에 SBS의 라인업이라는 프로그램이 막 중도종료한 때부터 시작했던 프로젝트입니다. 제가 2008년 3월에 다음에 처음 입사해서 맡았던 프로젝트 중에 하나가 바로 라인업입니다. 라인업은 제목에서 예상되듯이 '라인'을 '위로 올린다 (업)'는 의미를 가지고 있습니다. 여기서 말하는 '라인'은 다음검색의 검색결과 페이지에서 각각 출처별로 묶어서 보여주는데, 이 출처별 묶음을 '컬렉션 Collection'이라고 내부적으로 부르고 있습니다. 즉, 이 출처별 묶음인 컬렉션을 라인이라고 해석하면 됩니다. 이전 포스팅에서도 밝혔지만, 이 출처별보기가 네이버에서 검색기술의 한계 때문에 태어난 사생아인데, 국내에서는 너무 일반화되어서 사용되고 있습니다. 그래도, 출처별로 보여주면 많은 장점이 존재합니다. 그렇지만, 사용자가 입력한 검색어에 가장 충실한 컬렉션이나 문서가 존재함에도 불구하고 다른 이유 때문에 별로 연관성이 없는 문서/컬렉션이 최상단에 올라와서 사용자들의 검색만족도를 떨어뜨리는 부작용을 제공해주는 경우가 많습니다. 대표적으로 (지금은 거의 완화되었지만) 2008년이나 2009년 정도까지는 네이버에서 검색을 하면 (광고 컬렉션이나 특수 목적의 스페셜/컨텐츠/뉴스 컬렉션을 제외하고) 대부분 지식iN 컬렉션이 최상단에 노출되고, 다음에서 검색하면 카페 컬렉션이 최상단에 노출되는 경우가 많았습니다. 찾고자 하던 정보가 지식iN이나 카페에 존재했더라면, 사용자가 만족했겠지만 다른 컬렉션 (예를들어, 블로그 컬렉션)에 존재했다면 사용자는 원하던 검색결과를 찾기 위해서 불필요한 컬렉션을 먼저 스캔해서 봐야했고, 또는 스크롤다운을 해서 검색결과를 찾아가야하는 경우가 발생하게 됩니다. 이런 경우, 검색엔진을 이용하는 사용자들의 기대치는 가장 상단에 올라오는 결과가 내가 찾는 그 결과라는 기대치를 가지고 검색엔진을 이용하는데, 앞서 카노모델에서 설명하듯이 기본 기대치/기능을 충족시켜주지 못하는 결과가 나오게 됩니다. 그런 점에 착안해서, 사용자들이 가장 보고 싶어하는 결과를 최상단에 올려주자는 것이 라인업 프로젝트의 기본 목적입니다. 자세히 설명을 드릴 수는 없지만, 라인업 프로젝트를 위해서 1. 회사의 정책 점수 (예, 광고컬렉션을 최상단에 노출되어야 한다. 특수 목적의 컬렉션 (영화나 TV드라마 등)이 잘 매칭되면 최상단에 노출되어야 한다. 새로운 컬렉션 (예, 실시간 검색)이 오픈했기 때문에 상당기간동안 상단에 노출시켜서 사용자들의 주목/관심을 끌어들인다. 등) 2. 사용자 피드백 점수 (쉽게 설명해서, 많은 사용자들이 클릭한 컬렉션을 가능하면 상단에 노출시킨다. 일종의 집단지성 Collective Intelligence를 활용한 것입니다.) 그리고, 3. 문서/컬렉션 매칭점수 (즉, 사용자가 입력한 키워드와 잘 매칭되는 컬렉션을 상단에 노출시킨다. 즉, 보기 좋은 떡이 먹기도 좋다.)를 적절히 이용해서 현재 컬렉션간의 동적 경쟁을 시켜서, 가장 적합하다고 판단되는 컬렉션을 최상단에 노출시켜주고 있습니다. 그런데, 이런 동적 컬렉션 랭킹에도 분명 문제점이 있습니다. 바로, 고객의 (역?)기대치를 만족시키지 못한다는 것입니다. 매번 (일정기간은 컬렉션 순서가 고정되겠지만) 또는 쿼리마다 컬렉션의 노출순서가 달라진다는 점입니다. 검색엔진을 많이 사용한 사용자들은 검색을 하기 전에 미리 대강 알고 있습니다. 내가 특정 쿼리를 입력하면 카페 컬렉션은, 블로그 컬렉션은, 뉴스 컬렉션은 몇번째 즈음에 노출될 것같다는 감을 가지고 있습니다. 그런데, 라인업에서 제공하는 동적인 랭킹으로 인해서 사용자들이 기대했던 위치에 카페, 블로그, 뉴스 등의 컬렉션이 노출되지 않을 수도 있다는 것입니다. 사용자들의 만족도를 높이기 위해서 단행한 조치가, 역으로 사용자들의 기대치를 역행시키는 결과를 제공해주는 꼴이 되었습니다. 제품/서비스의 일관선 Consistency가 사용자의 기대치 모델에서 필수한 요소인데, 라인업 프로젝트의 결과물은 그런 점에서 일부 문제가 있습니다. (물론, 라인업 프로젝트를 통해서 많은 이들이 원하는 결과물이 최상단에 노출되기 때문에 전반적인 만족도는 향상되었습니다. 단지, 사용자들의 다른 기대가 조금 비틀어졌다는 것입니다.)

 두번째 사례는, '다음 통합웹 검색 MOAS'에서 밝혔던 바로 그 프로젝트입니다. 내부적으로 컬렉션 간의 결과를 썪는다는 이유에서 Fusion이라는 일반적인 이름을 사용했습니다. (그래서, 제가 담당하고 있는 시점에서 나만의 이름을 붙여주지 못해서 MOAS라는 이름을 지난 포스팅에서 그냥 명명했습니다. MOAS = Mother of All Searches 즉, 모든 검색의 어머니) 지난 포스팅을 참조하시면 알겠지만, 모아스 (모았어)는 풀텍스트 (문서의 길이가 긴 경우) 컬렉션들 (뉴스, 카페, 블로그, 게시판, 지식, 웹문서 - 처음에는 뉴스는 미포함이었지만, 지금은 가끔 포함되는 듯함)의 결과를 하나의 통합웹 컬렉션에 묶어서 보여주는 것입니다. 라인업에서는 컬렉션 단위로 가장 적합한 문서를 가진 컬렉션을 최상단에 노출시키는 것이지만, 모아스에서는 문서 단위에서 가장 최상의 문서를 최상단에 노출시켜주는 것입니다. 긴 설명은 생략하고, 모아스의 이런 방향은 제가 오래 전부터 생각하던 바라서 바람직한 시도였습니다. 그런데, 이 통합웹 컬렉션을 서비스해주는 측면에서 사용자들의 기대를 일부 만족시키지 못하는 면이 있습니다. 다음검색을 사용해보신 분들은 아시겠지만, 어떤 쿼리/검색어에 대해서는 출처별보기가 노출되고 (기존의 라인업 결과), 또 어떤 쿼리에 대해서는 통합웹 컬렉션이 노출됩니다. 많은 트라이를 해보시면, 적당히 쿼리의 길이가 길고 단어수가 많은 경우 (즉, 소위 롱테일 쿼리) 통합웹이 노출되고, 1~2 단어의 단문 쿼리에 대해서는 기존의 출처별보기가 노출되고 있습니다. 바로 이 점을 얘기하고 싶은 것입니다. 사용자들이 어떤 쿼리를 입력했을 때, 결과가 출처별보기가 나올 것같다 또는 모아보기가 나올 것같다라는 기대를 가지게 못한다는 점입니다. 출처별로 보일 것같은 쿼리를 던졌는데 모아보기가 노출되고, 반대고 모아보기가 나올 것을 기대했는데 출처별보기가 나오고... 도대체 어떤 쿼리 (형식/패턴)를 다음검색에 던져야, 출처별보기 또는 모아보기가 나올지 좀처럼 예측을 할 수가 없다는 점입니다. 그런데, 어떤 경우에 어떤 결과가 나온다는 식의 좀 구체적이고 정형화된 문서/가이드라인이라도 제공해주면 좋을텐데, 다음검색 공식 블로그에 단지 통합웹 컬렉션 오픈에 대한 공지만 나왔지, 조금 구체적인 가이드라인을 제공해주지 못했다는 아쉬움이 남습니다. 제 개인적인 바램/욕심으로는 현재 '통합웹 - 출처 구분없이 적합한 순으로 보여드립니다. - 출처별보기'라는 통합웹 컬렉션의 상단 설명에 '통합웹 가이드라인'이라는 링크를 걸어줘서 어떤 경우에 통합웹이 활성화되는지 등에 대한 간단한 가이드라인이라도 제공해주면 좋겠다는 바램입니다.

 낚시제목에서 시작해서, 카노모델을 (부정확하게) 설명드렸고, 또 다음검색에서 선보인 두가지 프로젝트/기술에서 일부 사용자들의 기대와 어긋난 결과를 제공해주는 (또는 기대를 하지 못하는) 경우가 발생할 수 있다고 글을 적었습니다. ... 적당한 클로징 멘트가 생각이 나지 않으니, 이만 적겠습니다.

댓글을 달아 주세요

Share           Pin It
 이제껏 본 블로그를 통해서 제가 지금 다니고 있는 회사 (다음 커뮤니케이션) 및 경쟁사들의 서비스나 그들의 경영/서비스 전략에 대해서 많은 비판을 올렸습니다. 제 짧은 세치혀로 그런 비판을 하는 것이 옳은가에 대한 가치판단은 아직도 서지 않습니다. 그래서, 나름 회사에 사죄한다는 의미에서 다음검색에서 담당했던 몇몇 부분들에 대해서 소개하는 글들을 몇 차례 적어볼까 합니다. 하나의 서비스/제품이 나오기까지 많은 사람들이 관여하기 때문에, 저만의 공으로 돌릴 수는 없지만 그래도 제가 했던 부분까지에 대한 소개글을 적어볼까 합니다. 그래서, 오늘은 그 첫번째 글로 다음검색의 '통합웹 컬렉션' (내부에서 통합검색에서 '출처'별 영역을 컬렉션 Collection이라 지칭하기 때문에 본 포스팅에서도 그 용어를 그대로 사용하겠습니다.)에 대한 글부터 시작하겠습니다. (아래에 용어들이 혼용되어서 이해하기가 조금 어려울 수도 있다는 점 미리 밝힙니다.)

 여러 포스팅들을 통해서 현재의 (한국의) 검색은 구글이 만들어놓은 패러다임과 네이버가 만들어놓은 패러다임에 종속되어있다고 말했습니다. 당연히 세계적으로 구글의 점유율이 거의 70%이고, 한국에서는 네이버의 점유율이 60%에 이르는 현 시점에서 어쩔 수 없는 것입니다. 그런데, 구글은 검색 그 자체에 대한 패러다임을 만들어놓았다면, 네이버는 한국적 (?) 검색에 대한 패러다임을 만들어놓았습니다. 구글의 검색 이야기는 일반 배제하고, 네이버가 만들어놓은 한국 검색의 병패는 바로 검색결과를 출처별 (컬렉션)로 보여주도록 만들었다는 것입니다. 물론, 정보의 성격에 따라서 출처별로 따로 보여줘야하는 경우가 많이 있지만, 네이버에서 시도했던 것은 검색어/쿼리에 내재된 사용자의 의도라던가 검색된 정보의 성격 등을 모두 무시하고 단순히 카페글, 지식글, 블로그글 등으로 구분했다는 점입니다. 이런 출처별 구분이 사용자들에게 더 좋은 결과를 보여주기 위한 방편으로 설계되었다면 제가 병폐라는 말까지 사용하지 않을 것입니다. 이런 출처별 보기의 시작은 기술력의 부재에서 시작했습니다. 더 엄밀히 말하면, 대용량의 데이터를 효과적으로 처리하지 못하고, 이종의 출처에서 온 정보들에 대한 랭킹기술이 부재했다는 것입니다. 그래서, 해당 출처 내에서만 검색결과를 만들어내고, 그 내에서 랭킹요소를 적용해서 통합검색에서 출처/컬렉션별로 단순하게 나열하는 것으로 검색이 끝나도록 만들었습니다. 그런데, 자신들의 기술력 부재에 대한 자성의 반응보다는 마치 사용자들의 편의를 위해서 이렇게 만들어두었다는 식의 마케팅에 집중했고, 또 그런 노력에 의해서 한국이용자들은 모두 검색하면 당연히 출처별로 보여줘야된다는 인식을 가지게 되었습니다. 그래서, 후발업체들인 다음이나 네이트 등도 당연히 출처별로 검색결과를 보여줘야되는구나라는 생각을 가졌던 것같습니다. 순전히 웹검색에 초점을 맞추던 90년대의 네이버나 엠파스 (그리고 야후, 구글 등)의 검색결과를 기억하신다면 당시에는 출처의 구분이 없었습니다. (그런데, 요즘은 구글도 출처별로 구분하기 시작해서, 전 별로 좋아하지 않습니다. 그래도, 나름 스마트하게 출처구분을 해주고 있어서 다행이라면 다행입니다.) 어쨌던 네이버의 이런 노력 (기술력의 부재의 결과)으로 '한국의 검색 = 출처별 검색'이라는 등식이 성립하였습니다. (출처별 보여주기가 나쁘다거나 장점이 없다라고 말하는 것이 아닙니다. - 단순히 네이트 '수手맨틱'검색 광고에서처럼 출처별보기를 매도하는 것이 아닙니다.) 

 제가 회사에 들어오기 전부터 그리고 회사에 들어온 이후로 계속 주장했던 것이 바로 이런 출처별 경계를 없애자는 것이었습니다 (참고). 그런데, 2년의 시간이 흐른 후에 그 작업을 제가 직접 담당하게 되었습니다. (그런데, 처음 3개월간의 프로토타입을 만드는 것까지만 저 혼자서 담당했고, 그 이후에 팀을 옮기게 되어서 다른 후속작업들은 다른 동료들이 마무리하였습니다. 그런데, 서비스가 오픈한 이후에 제 노력에 대한 보상 (?)은 어느 곳에도 없더군요. 참, 씁쓸하고 욕나오는 현실.) 이 글에서는 제가 처음 3개월동안 시도했던 출처통합에 대한 얘기를 다룰려고 합니다. 제 손을 떠난 이후의 작업에 대해서는 제가 잘 모르는 일이니 생략하겠습니다. 미리 밝혀두지만, 제가 3개월동안 작업했던 내용이나 알고리즘이 현재의 다음통합웹 컬렉션에 어느 정도 반영되었는지는 알 수가 없습니다. 완전히 새롭게 탄생했을 수도 있기 때문에, 아래에 적는 내용을 100% 신뢰하지는 마십시오. 그리고, 이 프로젝트의 아쉬운 점 한가지는 저는 보통 새로운 일을 시작할 때 제일 먼저 프로젝트/코드명을 정하는 것인데, 이 프로젝트에는 제가 정한 이름을 붙여주지 못했습니다. 단순히 위에서 내려온 일반적인 Fusion이라는 이름을 그냥 사용했습니다. 그래서, 지금이라도 이 프로젝트의 이름을 모아스 MOAS로 정했습니다. 한글로 '모았어' 즉, 모아보기라는 의미도 가지지만, 영문으로 Mother of All Searches, 즉, '모든 검색의 어머니'라는 이름을 붙여주려고 합니다. (*참고. MOAS는 미국의 대표적인 강력 폭탄인 MOAB이라는 Mother of All Bombs에서 영감을 얻은 것입니다.)

그림의 하단에 '통합웹'이라는 부분이 MOAS입니다. 기존에는 카페/블로그/게시판/지식/웹문서가 별도의 컬렉션으로 노출되었지만, 현재는 하나의 통합웹컬렉션으로 노출되고 있습니다. (참고로, 실시간검색 컬렉션에 공통적으로 나오는 @falnlov 는 눈에 익죠?)


 모아스를 설명하기 전에, 출처별 검색의 특징을 먼저 자세히 알 필요가 있는데... To make a long story short, '출처별로 다른 랭킹 알고리즘을 사용한다'입니다. 예를들어, 카페글의 경우 카페의 등급이 랭킹에 반영될텐데, 게시판글은 게시판 등급이라는 것이 존재하지 않습니다. 그리고, 뉴스 (모마스에는 미포함)글은 최신순이 정확도보다 더 높은 가중치를 받는 경우도 많습니다. 그리고, 다음검색에서는 초창기의 다음검색의 다음소프트라는 회사에서 만든 검색엔진을 사용한 부분도 있고, 회사 내에서 자체개발한 신규검색엔진을 사용하는 부분도 있습니다. 즉, 검색엔진에 따라서 검색색인방법과 랭킹방법이 다르다는 것입니다. 물론, 현재는 많은/대부분 컬렉션들이 신규엔진으로 교체되었습니다. 즉, 출처별로 검색된 문서에 태깅된 쿼리와의 매칭정도 및 검색스코어가 모두 다르고, 또 각 컬렉션의 특징을 반영해줘야하기 때문에, 단순히 출처별로 검색된 모든 문서들을 검색스코어에 따라서 나열해준다고 해서 컬렉션 퓨전이 이뤄지지 않습니다. 그래서, 이들 랭킹/검색스코어를 조정해주는 것이 컬렉션퓨젼/모아스의 핵심입니다.

 모아스에 반영된 요소들 (자세한 내용은 생략하겠습니다. 나중에 이 글이 기업정보를 빼돌렸다는 이상한 오해의 소지가 될 수가 있으니...)을 간략히 나열하겠습니다. 혹시, 더 자세한 설명이 필요한 부분은 별도로 요청해주시면, 후속글을 통해서건 아니면 별도의 방법을 통해서 알려드리겠습니다.
  • 문서별 랭킹점수: 출처별로 랭킹스코어를 계산하는 방식이 다르다고 했습니다. 그렇지만, 출처별로 해당 문서를 검색결과를 선정할 때 사용했던 점수를 모아스에서 완전히 무시할 수가 없습니다. 그런데, 앞서 말했듯이 출처별로 랭킹스코어의 스케일이 모두 다르기 때문에 스케일을 0~1로 정규화시켜줬습니다. 정규화 방법이나 선형변환, Min/Max, 표준화 등의 여러 방식이 있습니다.
  • 문서 매칭점수: 앞에 말한 문서 랭킹점수는 검색엔진에서 사용하는 모든 랭킹요소 (최신순, 정확도 등)을 고려해서 만든 문서점수라면, 문서매칭점수는 현재 검색화면상에서 보이는 검색스니펫 Snippet/summary이 사용자가 입력한 검색어 Query와의 매칭정도를 말하는 것입니다. 즉, 현재 화면상에서 검색스니펫이 사용자입력 키워드와 더 적합하게 일치하는 경우에, 모아스 결과에서 상단에 위치하게 되는 것입니다. 문서매칭점수에서 고려될 요소 중에 하나가, 문서스니펫이 얼마나 정상적이냐도 중요한 요소입니다. 문서스니펫이 상대적으로 짧다면 문제가 있을 가능성이 높고, 또는 문서가 'ㅋㅋㅋㅋ' 등으로 채워졌다면 이런 결과를 상단에 노출시켜줄 수도 없습니다. 
  • 컬렉션 매칭점수: 개별 문서스니펫에서 매칭점수를 구하듯이, 개별출처 전체에서의 매칭점수를 구했습니다. 이런 컬렉션매칭점수가 필요한 이유는, 더 적합한/매칭된 컬렉션에서 나온 문서를 최종결과에서 상단으로 올려주기 위한 것입니다.
  • 컬렉션 프리퍼런스: 이것은 사용자들이 선호하는 컬렉션의 결과를 상단에 놓기 위한 장치입니다. 특정 검색어 또는 특정 검색패턴에서 사용자들이 '카페'글을 주로 확인을 한다 등의 정보가 있다면 해당 패턴의 검색어에서는 카페글이 더 높은 우선순위를 가지게 되는 것입니다. 보통 컬렉션 프리퍼런스는 정책적인 점수가 반영이 될 수도 있고, 또 사용자들의 피드백이 반영이 될 수가 있습니다. 여담으로, 2008년도 이전의 다음검색에서는 검색최상단이 대부분 '카페'글이었습니다 (지금은 아님). 그런데, 네이버의 경우 '지식iN'이 검색최상단에 위치하는 경우가 많았습니다. 이는 다음에서는 카페를, 네이버에서는 지식을 우선시한다는 정책적인 결정이 있었기 때문입니다. 즉, 이런 정책/정치적인 논리에 의해서 최종 퓨젼결과가 달라질 수가 있다는 것입니다.  (... 컬렉션별로 줄을 세우는 방식에 대해서는 기회가 되면 다시 다루겠습니다.)
  • 중복여부: 같은 키워드에 대해서 중복/중첩된 글이 많이 나온다면 해당 문서의 중요도가 바뀔 수 있습니다. (모아스 랭킹에는 사용되지 않았지는 않았고, 단지 화면에서 중복문서 보여주기 용도로만 사용했음.)
  • 그 외에도, 글의 최신성도 사용될 수가 있고, 출처 내에서의 랭킹/순서도 모아스 랭킹에 이용되었습니다. 즉, 출처별 검색에서 카페라는 출처에서 '문서 A - B - C'의 순서로 문서를 보여주도록 소팅이 되었다면, 모아스에서도 가능하면 같은 순서를 유지하도록 해주는 것입니다. 물론, 매칭점수나 최신성점수 등에 의해서 ABC의 순서는 바뀔 수도 있습니다. 그래도, 이런 역전현상을 줄여주기 위해서 원 출처별 정열순서를 모아스에서 반영을 해준 것입니다.
  • 쿼리의 종류: 사용자들이 입력한 키워드와 서비스제공자들이 추천해주는 키워드 (실시간 급등어 등) 여부에 따라서 사용자들의 검색패턴/검색선호도가 조금씩 차이가 있습니다. 그리고, 실시간급등어의 경우 최신성이 많이 중요하기도 합니다. 그래서, 이런 사용자 입력 키워드 여부에 따라서 퓨젼/모아스 결과가 달라지게 됩니다.
  • 마지막으로 (다른 요소들이 더 사용되었을 것임), 위의 결과들을 하나로 뭉쳐주는 것...이 필요한데... (생략)

 마지막으로 퓨젼/모아스에서 중요한 요소는 도대체 언제 출처를 묶어서 보여줄 것이고, 또 언제 출처별로 따로 보여줄 것이냐에 대한 판단이 필요합니다. 이 부분은 제가 담당하지 않았기 때문에 확증적으로 말씀드릴 수 없지만... 롱테일 키워드 (조합형 검색어 및 검색어가 긴 경우)에 대해서 보통 모아스가 반응하고, 1~2 단어의 짧은 검색어에 대해서는 기존 방식인 출처별로 보여주는 경우가 많습니다. 사실 사용자들이 검색결과에 대해서 기대하는 것이 있기 때문에, 언제 모아스가 나오고 또 언제 출처별검색이 나온다라는 것을 예상할 수가 있어야하는데, 지금은 사용자들이 예측하기가 어렵습니다. 검색기대의 일관성 Consistency of Search Expectaction에 대한 고려가 다음검색에서는 많이 부족합니다. (ㅠㅠ)

 어제 밤에 이 글을 적겠다고 결심했을 때는 더 다양한 이야기를 펼쳐놓으려고 했는데, 막상 글을 적기 시작하니 어떤 내용을 담아야할지에 대한 판단이 흐려져서 그냥 생각나는 부분들만 적었습니다. 가능하면 후속글들을 통해서 빠진 부분들을 보충하겠습니다. 

댓글을 달아 주세요

  1. Tony 2010.09.01 11:50 신고 Address Modify/Delete Reply

    그래서 정치가 필요하신거에요... ㅋㅋ

  2. Favicon of http://www.seosem.kr BlogIcon 대기권탈출 2010.09.01 16:42 신고 Address Modify/Delete Reply

    다음 통합웹검색에 대해 좀 더 알게된 것 같습니다. 마지막에 언급하신 부분(검색기대의 일관성)이 어쩌면 사용자에게는 가장 큰부분 같은데 키워드광고 수익을 위해서는 어쩔 수 없는지 아니면, 다른 이유가 또 있는지 아쉽습니다.
    보통 상업적인 키워드가 포함되지 않았으면 띄워쓰기 상관없이 9자부터 통합웹검색을 보여주더군요. 다음은 새로운 검색방식을 선보였지만 사용자는 어떻게 느낄지 의문이 드네요.

    • Favicon of http://bahnsville.tistory.com BlogIcon Bahniesta 2010.09.01 19:40 신고 Address Modify/Delete

      아직은 통합웹 컬렉션을 좀더 conservative하게 적용하고 있습니다. 프로젝트를 시작할 때, 모바일에서는 좀더 공격적으로 적용한다고 들었는데,... 실제 적용되는 시점에는 제가 해당 프로젝트에 전혀 관여를 하지 못해서 어떻게 진행되는지 잘 모르겠네요.