Category Archives: 아키텍쳐

집단지성을 활용하는 Collaborative Filtering(CF) 알고리즘 – 추천 알고리즘으로 많이 이용되고 있지만, 한계도 알아야 해

오늘은 Collaborative Filtering에 대해 간단히 정리해보려고 합니다. 업무상 이와 관련된 내용을 자주 접하지만, 어딘가 정리를 해서 놓을 필요가 있다는 생각이 들어 블로그에 올려봅니다. 참고로 이는 전혀 새로운 알고리즘이나 방법이 아니며, 이미 학술적으로도… 또한 업계에서도 널리 응용되고 있는 방법입니다.

본 포스트에서는 Collaborative Filtering에 대해 그 정의와 응용(Application)에 대해 간단히 소개하고자 합니다.

 

1. Collaborative filtering이란?

Collaborative filtering (CF; 이하는 CF로 줄여서 표기)은 추천 시스템에서 사용하는 기법 중 하나입니다.

 

CF는 여러 에이젼트, 뷰포인트, 데이터 소스와의 협업(콜레보레이션; Collaboration)을 포함하는 기술을 사용하여 정보 또는 패턴을 필터링하는 프로세스입니다. 뉴스나 드라마에서 콜라보(Collaboration의 줄임말)를 했다는 말을 종종 들으셨을 것입니다. 콜라보란 협업(Collaboration)을 했다는 의미인데, 이를 바탕으로 CF를 다시 정의하면, 사전적으로는 여러 소스를 참조하여 불필요한 정보를 차단한다는 의미인데, 다르게 해석하면 관심 있어할 정보만 찾아준다는 것으로 풀이할 수 있습니다.

 

CF 알고리즘은 빅데이터(Big-Data)를 기반으로 처리되는데, 다음과 같은 분야에 널리 이용되고 있습니다.

  • 다양한 센서를 이용한 광물 탐사
  • 신용카드사의 고객 행태분석
  • 사용자 데이터를 기반으로 한 서비스(쇼핑몰, VOD) 등

 

알고리즘 측면에서 CF를 다시 정의하면 CF는 다양한 사용자의 선호도를 수집하여 사용자의 관심 분야를 자동으로 예측하도록 하는 방법입니다. CF의 가장 흔한 접근 방법은 “당신이 구입한 제품을 구입한 다른 고객은 A라는 제품에도 관심을 보이셨습니다.”라는 방식의 접근입니다. 다른 사례로는 “명량”이라는 영화를 본 사람이 있다고 하면, 이 사람에게 “명량을 보신 고객분들 중 많은 분들이 해적도 보셨습니다”라고 추천을 해주는 것을 예로 들을 수 있습니다. 이는 서비스를 운영하는 사람의 관점에 있어서는 2차 구매를 유도하여 또 다른 수익을 내는 기회를 만들어낼 수 있다는 장점이 있습니다. 이러한 처리 기법은 아마존(Amazon)이나 알리바바(Alibaba) 같은 쇼핑몰은 물론 넷플릭스(Netflix)같은 VOD 서비스 업체에도 적용이 된 바 있습니다.

 

 

2. CF 방법론(Methodology)

1) User-based CF

: 일반적으로 가장 많이 이용되는 방법으로 Nearest Neighbor Algorithm이라고도 불리우며 그 처리 프로세스는 다음과 같습니다.

  • Step 1: 같은 패턴을 가지는 사용자를 찾는다. 예) A라는 아이템에 대해 별 5개를 준 고객이 있다고 할 경우, 이와 같은 등급을 부여한 B라는 고객을 찾는다.
  • Step 2: 같은 유형의 사람들이 했던 패턴을 예측(Prediction) 정보로 제공한다.

 

아래의 사례가 본 사례와 유사한 것 같습니다.

집단지성을 활용하는 Collaborative Filtering(CF) 알고리즘 - 추천 알고리즘으로 많이 이용되고 있지만, 한계도 알아야 해

 

2) Item-based CF

: 아마존(Amazon)이 이를 처음으로 사용한 것으로 알려져 있으며,  통상 “users who bought x also bought y”라는 형태로 많이 알려져 있습니다. 이 방식에 대한 처리 프로세스는 다음과 같습니다.

  • Step 1: 아이템에 대해 서로의 관계를 알 수 있는 매트릭스를 만든다.
    집단지성을 활용하는 Collaborative Filtering(CF) 알고리즘 - 추천 알고리즘으로 많이 이용되고 있지만, 한계도 알아야 해
  • Step 2: 사용자와 일치하는 데이터를 찾아 매트릭스에 대입하여 현재 사용자의 선호도를 예측한다.
    집단지성을 활용하는 Collaborative Filtering(CF) 알고리즘 - 추천 알고리즘으로 많이 이용되고 있지만, 한계도 알아야 해

 

하나 주시해야 할 점은 별점(등급) 방식은 모든 사용자를 만족시키는 것이 아니라 평균적인 대중의 의견을 반영하는 것이므로 선호도나 관심도가 다양한 분야에 적용 시, 그 결과가 만족스럽지 않을 수 있습니다. 이런 경우 검색(Search)이나 Data Clustering같은 방법을 이용하는 편이 좋은 결과로 이어지는 경우가 많습니다.

 

 

3. CF 구현 방식

CF 구현방식에는 Memory-based CF, Model-based CF, Hybrid CF의 3가지 방식이 있습니다. CF 알고리즘을 적용하려고 계획하고 있다면, 그 용도와 Data Source의 Size에 대해 충분히 고민한 후 구현 방식을 정하는 것이 적절하다 판단됩니다.

 

1) Memory-based CF

Memory-based CF는 사용자의 선호도(Rating) 기반으로 사용자(User) 또는 아이템(Item)의 유사도를 계산하는 방법을 이용하는 것으로, 추천 솔루션 개발에 널리 이용됩니다. 쇼핑몰이나 VOD 서비스에서 제공하는 대다수의 추천 기술은 이 방식으로 서비스 되고 있습니다. 위에 기술했습니다만, Nearest Neighbor Algorithm이 널리 이용되고 있으며 아이템(Item)/사용자(User) 기반 top-N 추천 알고리즘 또한 널리 이용되고 있습니다.

이 방식의 단점은 다음과 같습니다.

  • 사람의 선호도(Rating) 의존적
  • 표본데이터 모수가 적으면 성능도 떨어짐. 이 때문에 새로운 사용자나 아이템이 추가되는데 따르는 확장성(Scalability)이 떨어짐.

    집단지성을 활용하는 Collaborative Filtering(CF) 알고리즘 - 추천 알고리즘으로 많이 이용되고 있지만, 한계도 알아야 해

 

2) Model-based CF

이는 Usage 데이터를 기반으로 Training을 하여 패턴을 발견하는 과학적인 기법입니다. 이는 보통 실제 Data에 대한 예측을 하는데 이용되는데, 일기예보 등이 이에 해당합니다. 여기에는 베이지안, 클러스터링, 시맨틱 등 수학적 모델을 기반으로 추천을 하는 다양한 알고리즘이 존재합니다.

Model-based CF는 Memory-based에 비해 적은 소스 모수를 사용하고 데이터가 크면 클수록 예측 퍼포먼스가 좋아 진다는 장점이 있으며, 반대로 모델을 만드는데 비용이 많이 소요되고, 데이터가 크면 클수록 퍼포먼스가 떨어진다는 단점이 있습니다.

집단지성을 활용하는 Collaborative Filtering(CF) 알고리즘 - 추천 알고리즘으로 많이 이용되고 있지만, 한계도 알아야 해

3) Hybrid CF

당연한 예측 결과겠지만, Memory-based CF와 Model-based CF를 혼용하면 적은 모수의 소스에 대해서도 대응이 가능하다는 장점이 있으나, 이에 따라 비용이 증가하고 구현 복잡도도 높아진다는 단점이 있습니다.

예를 들어 Google의 뉴스 추천 서비스가 이에 해당합니다.

 

 

4. CF의 문제점

1) 정확도

추천 시스템을 만드는 많은 과학자들이 “그래서 추천 정확도가 높아졌어?”라는 질문을 받습니다. CF만 가지고 개인화 추천의 선호도를 모두 맞추는 것은 불가능합니다, 다만 대중의 의견을 반영하였으므로 대개는 맞아떨어진다고 하는 것이 맞습니다.

2) 콜드스타트(Cold Start)

CF는 수집된 패턴을 근간으로 움직이므로, 새로운 사용자나 새로운 아이템이 등장했을 경우 사용 데이터 부족으로 인하여, 적절하게 추천되지 않을 가능성이 높습니다. 이런 경우라면 새로운 사용자의 경우에는 좋아하는 영화, 좋아하는 음식, 장르 등… 선호도를 미리 기초 데이터로 받아야 할 것이고, 새로운 아이템이 등장했을 경우에는 이것이 필요한 사람들에게 의도적으로 노출되게 하는 UI(User Interface)적 접근이 필요 할 것입니다.

집단지성을 활용하는 Collaborative Filtering(CF) 알고리즘 - 추천 알고리즘으로 많이 이용되고 있지만, 한계도 알아야 해

 

 

5. CF 알고리즘 적용 시 고려 사항

CF를 구현함에 있어, CF의 성능에 방해가 되는 여러 요인들이 있습니다. 하여 CF 구현 시 아래의 항목에 대한 대응 전략이 있는지… 미리 검토/고민 할 필요가 있습니다.

1) 소스 데이터의 분량(Data Sparsity)

2) 확장성(Scalability)

3) 유사품(Synonyms)에 대한 처리 정책

4) 검색봇(bot) 등 추천에 방해되는 인자(Grey sheep)에 대한 예외 처리 정책

5) 일부러 남의 경쟁자의 아이템에 대해 부정적인 Voting을 하고, 자기 아이템에 대해 긍정적인 Voting을 하는 Shilling attacks에 대한 대응 방안

6) 오래된 아이템(Long Tail)에 대한 Rating이 높아 새로운 아이템이 추천되지 못할 가능성에 대한 대응 방안: 신규 아이템은 별도 노출을 해주는 UI 구성 등.

 

이상 CF(Collaborative Filtering)에 대해 알아보았습니다.

 

 

서버 인프라 설계시 장애를 고려하여 만드는 Single Infra, Active-Stand-by,Active-Active, Active-Stand-by/Active-Active+DR Center

서버 인프라 설계시 장애를 최소하려는 시도를 아키텍쳐 측면에서 바라보면 다음과 같이 4가지 아키텍쳐가 존재합니다.

  • Single Infra
  • Active-Stand-by
  • Active-Active
  • Active-Stand-by/Active-Active + DR Center

 

그러면 각각을 하나하나 살펴 보겠습니다.

 

1. Single Infra

일반적으로 대다수의 서비스들이 이 아키텍쳐를 기반으로 만들어졌다고 보시면 됩니다.

서버 인프라 설계시 장애를 고려하여 만드는 Single Infra, Active-Stand-by,Active-Active, Active-Stand-by/Active-Active+DR Center

이 아키텍쳐의 특징은 나름 확장성도 있지만 장애에 취약하다는 것입니다. 즉, 해당 Zone에 물리적 장애가 생기면 서비스 전체에 장애가 생긴다는 것이죠.

서버 인프라 설계시 장애를 고려하여 만드는 Single Infra, Active-Stand-by,Active-Active, Active-Stand-by/Active-Active+DR Center

 

2. Active-Stand-by

Single Infra의 단점을 개선하기 위해 나온 아키텍쳐가 바로 Active-Stand-by입니다.

서버 인프라 설계시 장애를 고려하여 만드는 Single Infra, Active-Stand-by,Active-Active, Active-Stand-by/Active-Active+DR Center

두 존에 서버 인프라를 구축하고, 위급 상황이 발생하면 재빨리 서버를 전환한다는 발상입니다.

서버 인프라 설계시 장애를 고려하여 만드는 Single Infra, Active-Stand-by,Active-Active, Active-Stand-by/Active-Active+DR Center

 

그렇지만 사용하지 않는 서버는 쓸데없이 공간만 차지한다는 단점이 있습니다. 이런 아키텍쳐로 서비스를 하는 회사는 전세계에서 5% 이내일 것입니다. 그만큼 비용대비 효율이 좋지 않다는 것이죠. 차라리 장애가 나면 고객에게 장애공지를 하고 서비스를 안하는 것이 비용측면에서는 더 유리할 수 있습니다.

 

3. Active-Active

Active-Stand-by가 쓸데없이 멀쩡한 장비를 놀릴 수 있다는 문제가 있어 이를 개선하여 나온 솔루션이 바로 Active-Active입니다. 즉, 두 자원을 동시에 다 사용하자는 것이죠.

서버 인프라 설계시 장애를 고려하여 만드는 Single Infra, Active-Stand-by,Active-Active, Active-Stand-by/Active-Active+DR Center

이 방법은 두 Zone의 장비를 동시에 사용하므로 장애에는 매우 좋은 솔루션이라 할 수 있습니다. 그렇지만 좀더 자세히 생각 해 보면, 한쪽 Zone이 장애가 날 경우 나머지 Zone의 장비로 이를 다 커버하려 한다면 비용이 두배로 들 것입니다. 이 방법 역시 비용측면에서는 그리 똘똘한 답변이 아닙니다.

서버 인프라 설계시 장애를 고려하여 만드는 Single Infra, Active-Stand-by,Active-Active, Active-Stand-by/Active-Active+DR Center

 

4. Active-Active/Active-Stand-by with DR Center

이 방법은 위의 3가지 방법론을 총망라한 궁극의 솔루션입니다. DR Center는 Disaster Recovery Center라는 뜻인데, 이를 아키텍쳐 다이어그램으로 그리면 다음과 같습니다.

서버 인프라 설계시 장애를 고려하여 만드는 Single Infra, Active-Stand-by,Active-Active, Active-Stand-by/Active-Active+DR Center

 

궁국의 솔루션이지만 비용 측면에서는 여전히 답이 안나오는 솔루션이라 할 수 있습니다.

서버 인프라 설계시 장애를 고려하여 만드는 Single Infra, Active-Stand-by,Active-Active, Active-Stand-by/Active-Active+DR Center

이러한 시스템을 구축하는 곳이라면 아마도 은행이나 증권사정도 일텐데… 아마도 거기조차도 이러한 full system을 다 가지고 있지는 않을 것 같습니다.

제가 서비스 아키텍쳐를 책임지는 책임자이고, 회사의 정책을 결정짓는 사람이라면 Active-Stand-by를 모델로 가져가되, 서버 구축을 IDC에 직접 하지 않고 클라우드로 하겠습니다. 하여 구축비용을 최소화 하고, 장애에 대응할 수 있는 구조를 추천할 것입니다.

상용서비스의 경우 데이터 미러링에 대한 답을 가지고 있어야 할 것 같습니다.

2-Tier 아키텍쳐와 3-Tier 아키텍쳐의 다른점

아키텍쳐를 디자인하다 보면 2-Tier이냐 3-Tier이냐에 대한 질문을 까끔 듣습니다.

이는 보통 Java개발자들에게서 많이 듣는 질문이기도 한데요. 왜냐하면 J2EE 어플리케이션이 2-Tier 또는 3-Tier로 구분되기 때문입니다.

아래는 2-Tier 아키텍쳐의 사례입니다.

2-Tier 아키텍쳐와 3-Tier 아키텍쳐의 다른점

위에서 보시면 클라이언트가 비즈니스로직과 데이터베이스로직, 그리고 UI까지 다 가지고 있는 구조라고 할 수 있습니다. 위의 그림상에서 보면 다음의 두개 티어(Tier)로 구성되어져 있다고 보면 맞습니다.

  • 클라이언트 어플리케이션 (Client Tier)
  • 데이터베이스 (Data Tier)

이 아키텍쳐의 장점은 아래와 같습니다.

  • 유지보수가 쉽다
  • 커뮤니케이션이 빠르다

단점이라고 한다면

  • 사용자 수가 증가하면 어플리케이션의 퍼포먼스도 떨어진다
  • 비용 대비 비효율적이다

3-Tier 아키텍쳐(3-Tier Architecture)는 우리가  이미 많이 접해 본 구조라고 할 수 있는데 그 구성을 보면 아래와 같습니다.

2-Tier 아키텍쳐와 3-Tier 아키텍쳐의 다른점

즉, 아래와 같은 3단계 레이어로 구성이 됩니다.

  • 클라이언트 레이어
  • 비즈니스 레이어
  • 데이터 레이어

장점이라고 한다면 다음과 같습니다.

  • 가볍우면서 고성능의 컴포넌트 구현 가능
  • 확장성이 좋다
  • 퍼포먼스가 좋다 – 각각의 티어가 캐시 개념을 가져갈 수 있어 성능 개선 가능
  • 재사용 가능하다
  • 데이터 정합을 개선할 수 있다
  • 보안을 강화 할 수 있다 – 클라이언트가 DB를 직접 건드리지 못하므로
  • 비즈니스로직과 UI를 분리할 수 있다
  • 비즈니스를 세분화하여 쪼갤 수 있다
  • 유지보수가 쉽다
  • 관리하기가 쉽다
  • 각각의 컴포넌트의 의존도를 낮출 수 있다

단점이라면 복잡도가 늘어난다는 것?

요즘은 클라이언트에서 DB에 직접 접속하여 어플리케이션을 구현하는 경우가 거의 없으므로 3-Tier 내지는 4-Tier로 소프트웨어가 구현되고 있다고 보는 것이 맞을 것 같습니다.