Net Journalist 佐々木씨가 차세대 Social Media의 형태를 파해치는 신연재 “Social Media Second Stage”. 제 2회는 Recommendation 방법으로서 잘 알려져 있는 “Contents Filtering”과 “Collaborative Filtering”에 대해서 파해칩니다.

(2007년 9월 18일)

Recommendation의 대표적 방법
Recommendation에는 몇가지 Approach가 있다. 우선 그 Approach를 나열해 보면, 대충 아래와 같이 6가지로 분류 가능하다.

1) Rule에 기반하는 Recommendation
2) Contents Base의 Filtering
3) Collaborative Filtering
4) 통계학적인 Approach
5) Behavieral Targeting
6) Social Networking

하나씩 설명 해 보자.

1)의 Rule에 기반하는 Recommendation이라는 것은 “Business Rule 방식”, “International(의도적인) Recommendation”등으로 불린다. 예로, “미용실에서 머리를 자르러 온 사람에게, Hair Care상품을 권한다” “Printer를 사러 온 사람에게 Ink Toner를 권한다”등, 최초에 “어떤 제품을 산 사람, 어떤 행동을 한 사람에게는 이 제품이나 Service를 권한다”라는 Rule을 정해두는 방법이다. 이 Recommendation은 알기 쉽지만, 사전에 모든 Rule을 반드시 결정해 두지 않으면 안되기 때문에, 운영측에 손이 많이 간다.

“음악 Genome Project”가 받쳐주는 Contents Filtering
2)의 Contents Base의 Filtering는 Contents의 속성과 User의 기호를 Matching 시켜서, 추천하는 Approach이다. 더욱 단적인 예로서 음악 Recommendation Service의 Pandora가 있다. 현재, 일본에서는 저작권 문제로 Registration 불가능하게 되어 버린 것이 상당히 아쉽지만, 악곡의 내용을 철저하게 분석하고, 이용자의 기호에 맞춰 음악을 배신해 주는 Service이다. Site에 Sign-in하여 “Create a New Station”이라는 Button을 누르면, 좋아하는 Artist와 곡의 입력을 요구한다. 예로, Paul McCartney의 “Dance Tonight”를 입력하면 “Dance Tonight Radio”라는 가상적인 Radio국이 작성되고, “Dance Tonight”와 닯은 곡이 차례차례 재생된다.

이 Service를 받쳐주고 있는 것은 “음악 Genome Project”라는 기술이다. 각각의 악곡은 Melody와 Rithm, 경향등 여러가지 요소에 따라 구성되어 있다라고 보고, 그들의 요소를 “Genome(유전자)”라고 부르고 있다. 그리고, 하나하나의 악곡에 대해, 전문가가 수작업으로 약 400 Genome에 기반하여 점수화하여, 최초에 User가 선택한 악곡과 닮은 Genome 구조의 곡을 선택, 재생 해 가는 구조로 되어 있
다. 게다가 이 Genome의 유의성에 의해 재생 된 곡에 대해서, User측은 “I like it”과 “I don’t like it”이라는 Button으로 자신의 기호를 덧붙이는 것도 가능하다. 이로 인해 악곡 Contents와 User의 Match 정확도를 더욱 높이고 있다.

Amazon이 채용하는 Collaborative Filtering
3) Collaborative Filtering은 Amazon.com의 Recommendation에 의해 유명해 졌다. Amazon의 Top page에는 “XX씨, 추천 상품이 있습니다”라고 추천된, 책을 사면 “이 책을 산 사람은 이런 책을 사고 있습니다”라고 같은 종류의 책이 추천된다. 이것이 Collaborative Filtering이다.

Collaborative Filtering를 정말 간단하게 설명하면, 예로 A란 사람이 (A) (B) (C) (D)라는 4개의 상품을 구입했다라고 하자. 이에 반해 B라는 사람은 (A) (B) (C) (E)라는 4개의 상품을 구입하였다. A와 B는 (A) (B) (C)의 3개의 상품을 구입한 공통 내역이 있고, 취미지향이 닮았다고 예측 가능하다. 거기에서 A에게는 “(E)를 구입해 보면 어떤가요?”, B에게는 “(D)는 어떻습니까?”라고 추천하는 것이 된다. 실제로는 더욱 복잡한 일들이 행해지고 있지만, 간략화해 버리면, 위와 같은 생각 방법이 Collaborative Filtering의 기본이다.

이 Collaborative Filtering과 앞에서의 2)의 Contents Filtering은 어떤 종류의 보완 관계에 있다라고 말해도 좋을 지 모른다. 서로 결점을 보완하는 것이 가능하기 때문이다. 우선 Contents Filtering에는 다음과 같은 결점이 있다.

1) User의 기호와 Contents의 속성을 Matching시키기 위해, User의 가시화된 기호로부터 탈출 된 Contents는 추천하기 어렵다. 바꿔 말하면, User가 “내 마음에 들지 않아”라는 기호에 대해서는, Contents Filtering에서는 추천되어지지 않는다.
2)Contents의 속성을 최초에 분석하고, 분류해 두지 않으면 안된다. 위의 Pandora의 예를 들면, 우선 막대한 수의 악곡을 Genome에 기반하여 점수화한다라는 전문가의 작업이 필요하게 되어 버린다. 이것은 Cost를 증가시키는 것이 된다.

Collaborative Filtering의 이점과 “Serendipity”
Collaborative Filtering은 이들 결점을 보완가능하다. 우선 제 1)에서 Collaborative Filtering은 다른 User와의 기호의 유의성을 Base로하고 있기 때문에, Contents의 내용은 일절 고려하지 않는다. 이로 인해, 전혀 User의 기호와 맞지 않는 예상 외의 추천을 행하는 일이 있다. 이 예상 외의 추천에 의해 User는 “어, 이런 좋은 것도 있었네”라고 놀라거나, “나에게도 이런 기호가 있었네”라고 새로운 느낌을 받을 수 있다.

결국은 Serendipity이다. 이미 상당히 Popular가 된 이 말은 우연을 붙잡아 행운으로 바꾸어 버리는 능력을 가리킨다. 원래는 “Serendipity 이야기 행복을 부리는 세명의 왕자” (Elizabeth Jamison Hodges저)라는 옛날 이야기가 어원이다. 고대의 Sri lanka에 있었던 Serendip 왕국을 무대로 한 이 이야기에서 3명의 왕자는 용을 말을 수 있는 천(巻物)를 찾아서, India에서 Persia로 여행했다. 그러나 최후까지 그 천(巻物)를 발견되지 않았다. 그러나 이 과정에서 와자들은 여러가지 행운과 접하게 되고, 여러가지 것들을 발견하게 되었다. 그 “우연의 행운”의 재미를 주목한 18세기의 Italy의 문필가, Horace Walpole이 우연이라도 행운을 불러 들일 수 있는 능력을 Serendipity라고 부르자라고 아는 사람에게 편지를 썼고, 그렇게 해서 이 말이 영국권에 점점 퍼지게 되었다. 잘 알려진 사례로서는 Novel 화학상을 수상했던 白川英樹씨의 이야기가 있다. 白川씨가 polyacetylene의 합성실험을 행하고 있을 때, 촉매의 양을 100배로 해 버렸고, 이 결과 예상치 못한 “전기가 통하는 Plastic”이 생겨나 버렸다라는 허황된 이야기이다. 즉, 요구하고 있던 것과 전혀 다른 발견, 발명이 우연하게 이루어 졌고, 그런 상황을 Serendipity라고 부르게 된 셈이다.

이 Serendipity라는 말이 생긴 것은 18세기이고, 그 후 오랜동안, Serendipity는 명시적으로 얻을 수 있는 것이 아닌, 어떤 종류의 제 6 감각과 같은 것, 혹은 초능력의 한 종류라고 생각되어져 왔다. 노력하고 있다라고 해서 얻을 수 있는 것이 아닌, “그저 우연하게 행운이 찾아오면 그것은 굉장하지만, 어떻게 하면 그런 것이 가능 하지?”라는 반신반의 정도로 인식되졌던 것이다.

그런데, Internet 시대에 들어서서, 검색 Engine나 Social Bookmark등의 Web2.0적 Architecture에 따라 User 측이 예기치않던 새로운 Data와 만나는 것이 가능하게 되고, 이것이 Serendipity라는 말을 일약 주목하게한 결과가 되었다. 앞서 말한 Collaborative Filtering도 같은 맥략으로 User 측이 상상하고 있지도 않았던 우연의 만남을 연출하는 것이 가능하게 되었기 때문이다.

이점과 정반대의 Collaborative Filtering의 결점
이것은 Contents Filtering에는 불가능한 능력으로 Collaborative Filtering의 강점이 되어 있다. 그러나 이 강점은 – 뒤에서 서술하지만, Collaborative Filtering의 결점이기도하다.

또 Contents Filtering의 결점의 2)에 대해서도, Collaborative Filtering이라면, Contents의 속성을 최초에 분석해 둘 필요가 없다. 왜나면, Collaborative Filtering은 앞에 쓴 것 관 같이, Contents의 내용을 일절 보지 않기 때문이다. 그러나, 이것에 대해서도 되 돌아보면 Collaborative Filtering의 결점과 연결된다. 즉 Collaborative Filtering은 Content의 내용을 볼 필요가 없는 대신에, 처음부터 막대한 수의 고객 Data를 필요로 한다. 고객 Data가 모이지 않으면, 만족 할만한 해석결과를 얻는 것이 불가능하기 때문이다.

Collaborative Filtering의 결점을 정리해 보자. 아래와 같은 것이 된다.

1) Collaborative Filtering은 그 상품의 내용 그 차체에 대해서도 관련하지 않는다. 예로 영화의 Recommendation을 생각해 보자. Collaborative Filtering에서는 자신이 구입한 상품 Data에 기반하여, 다른 고객의 Data와 관련시켜 “당신에게 이런 추천 영화가 있습니다”라고 추천한다. 하지만, 이 경우에는 자신이 어떤 감독이나 배우, Jenre의 영화가 좋을까라는 속성은 전혀 고려되고 있지 않다. 그래서, 예를들면, 이과의 사람이 잘 살 만한 기술서를 빈번하게 구입하고 있다라면, 그 같은 층의 사람들이 비교적 좋아하는 Anime를 추천해 버린다라는 일들이 일어날 수 있다. 기술자는 책을 읽지만, Anime는 좋아하지 않는 사람에 있어서는 이 Recommendation은 유효하지 않다.
2) Collaborative Filtering은 고개의 Data가 많은 수 모이지 않으면 적절하게 Recommendation 할 수 없다.
3) Collaborative Filtering은 고객 서로의 행동의 유의성을 보고 있을 뿐, 고객의 속성을 보고 있지 않다. 예로, 부인에게 선물을 하기 위해 남편이 여성용 화장품을 구입한다면, 그 후 오랫동안 여성용 화장품을 중심으로 추천해 버리는 현상이 일어나 버릴 것이다.

앞에서도 쓴 것과 같이 Contents Filtering이라면, 1)과 2)의 문제는 Clear가능하다. 2)의 예로 들었던 영화에 대해서 말하자면:

자신이 어떤 영화를 좋아하는지를 사전에 등록해 두고, 그 기호에 맞춰 추천 받는 Contents Filtering적인 수법을 사용하면, 예로 좋아하는 영화감독, 좋아하는 배우, 좋아하는 음악가등을 등록해 두는 것만으로, 감독이나 배우, 음악가가 기용되어진 영화를 추천 받을 수 있다. 그리고, 이 방법으로는 2)의 결점 – 고객의 수가 적어도, Recommendation을 적절하게 행할 수 있다. Service 개시 직전에 손님이 아직 적은 “Cold Start”라고 불리는 단계에서는 Contents Filtering 쪽이 유효한 것이다. 하지만 3)의 고객 속성 문제애 관해서는 Contents Filtering에서도 Collaborative Filtering에서도 Cover 불가능하다. 다음회는 그 부분에 대해서 검토해보자.

※ 위 글은 아래의 링크를 번역한 글입니다. 다소 오역이 있을 수 있습니다.

http://www.itmedia.co.jp/anchordesk/articles/0709/18/news038.html