신입이 만드는 추천시스템-1(개요)

이 글은 제가 작업했던 내용을 정리하기 위해 수기 형식으로 작성된 글입니다.

---

난 건축공학을 전공해 건축구조회사를 3년간 다니다 그만두고 인공지능을 배우고 싶어 국비지원을 활용해서 A업체의 인공지능 국비교육을 들었다.

 

인공지능을 시작한 이유는 하나였다. 영화로만 봤던 기술들이 실제로 개발되고 발전되어 나가 구현되는 것까지 눈앞에서 보고 싶었다. 내가 그 과정에 참여할 수 있다면 더 좋다고 생각했다.

 

그렇게 시작한 국비교육을 들으며 파이썬 기초에서부터 머신러닝 전반에 이르는 지식의 흐름을 배웠다.

A업체의 교육은 인공지능(딥러닝)관련 분야 중 특정 분야를 집중적으로 알려주기보다는 ‘전체 분야에 이런 게 있어’라는 느낌의 교육이었다.

 

전체적인 그림을 배우는데 매우 효과적이었고 이를 통해 얇고 넓게 알게 된 느낌이기는 하지만 아직도 내 무기가 정해지지 않아서 불안하기도 하고 이대로 취업시장에 나갔다가는 큰 낭패를 볼 것 같았다.

 

그래서 A업체에 퍼실리테이터로 계약해 월급을 받으며 취업준비를 했다.

취업준비를 하면서 난생처음 포트폴리오도 만들어보고 코딩테스트도 준비해보고 CS공부도 해보았다.

그렇게 교육부터 이직준비까지 총 1년이 걸렸고, 교육을 시작하기 전 리프레쉬 시간도 가지고 이런저런 공부도 혼자 해보면서 총 1년 6개월의 시간이 걸렸다.

 

그러면서 로망이 하나 생겼다.

언젠가 개개인이 ‘아이언맨’의 자비스와 같은 개인비서를 가지게 되고 그 개인비서의 성능과 사용할 서비스를 커스터마이징 하게 될 수 있게 된다면, 그 서비스를 만들고 판매하고 추천해주는 플랫폼을 만들고 싶어졌다. 그 플랫폼을 당장은 만들 수 없겠지만, 적어도 어떠한 기업이 만들 때 그 과정에 참여하고 싶어졌다.

 

그러기 위해서는 그 기업에서 활약할 수 있는 기술이 필요했다. 난 그 기술로 추천 시스템을 선택했다. 지금도 다양한 분야에서 적용되고 있어 활용범위가 넓고, 개개인의 행동에 기반한 로그 데이터 등으로 개개인에 맞추어 무언가를 제공하는 부분이 마음에 들었다.

 

그리고 2022년 2월 10일, 겨울이 아직 죽지 않았다고 기승을 부리던 날에 나는 D회사에 입사하게 되었다.

D회사는 정부과제를 진행하면서 크리에이터와 광고주간 연결해주는 걸 주요 아이템으로 삼고 있는 회사였다. 여기서 정부과제는 크리에이터와 광고주 간에 단순 연결이 아니라 연관성이 높은 크리에이터 혹은 광고주를 머신러닝을 활용하여 추천해주는 시스템을 개발하는 것이었다.

 

내가 담당했던 부분은 크리에이터 채널의 메타데이터와 광고주 제안서의 메타데이터를 추출하여 각 메타데이터를 기반으로 크리에이터에게는 채널 컨텐츠에 걸맞은 제안서를, 광고주에게는 제안서에 적합한 크리에이터를 추천해주는 로직을 구현하는 부분이었다.

 

내가 입사하기 전의 전임자가 구현했던 추천로직은 TF-IDF기법을 활용한 유사도 기반의 추천 로직이었다. 문서를 구성하는 단어들의 빈도와 역 빈도로 단어 빈도 행렬에 가중치를 곱하여 문서별 행렬을 만들고 이를 기반으로 유사도를 구해 추천해주는 시스템이었다. (자세한 내용은 아래의 참조 부분을 살펴보면 좋을 것 같다.)

 

D회사가 운용하고 있는 서비스에서의 추천 시스템은 단순히 크리에이터 혹은 광고주에게 유사한 item(크리에이터 또는 제안서)를 노출시켜주는 방식이었다.

 

노출만 시켜주는 방식이라면 TF-IDF방식이 매우 효율적이었다. 리소스도 많이 쓰이지 않고 효과적으로 구현된 추천 시스템이라고 생각했다.

 

하지만 난 전임자가 만들어 놓은 추천 시스템에서 좀 더 활용도 높은 추천시스템을 만들고 싶었다.

그래서 단어의 빈도수를 활용하기 보다 단어 자체의 의미가 추천 시스템에 적용되면 좋겠다고 생각했다.

 

최종적으로 생각했던건 사용자가 원하는 키워드를 검색하면 사용자에 따라 해당 검색어에 알맞은 크리에이터나 제안서를 보여주는 추천 시스템이었다.

 

이를 위해 CTO를 설득해 워드 임베딩 방식을 도입해 추천 시스템을 만들어보기로 했다.

 

워드 임베딩 방식에는 여러 가지가 있는데 그중 내가 써먹어봐야지 생각했던 방법은 두 가지였다.

그중 하나가 Word2Vec이고, 다른 하나는 FastText였다.

 

Word2Vec방식은 간단하게 말하자면 문장을 구성하는 단어들을 가지고 벡터를 만드는 방식이다.

인공신경망을 활용하기 때문에 Input값과 Output값이 명확하게 나뉘는데, 주변 단어를 Input값으로 넣고, 타깃 단어를 Output으로 받는 방식인 CBOW방식과 타겟 단어를 Input값으로 넣고, 주변 단어를 Output으로 받는 방식인 Skip-gram방식이 있다.

두 방식은 Input의 형태만 다를 뿐 “단어”를 Input값으로 활용한다는 면에선 공통점을 가진다.

 

Fast-Text방식은 Word2Vec방식의 확장 버전이라고 생각하면 편할 것 같다.

기존의 Word2Vec방식은 Input값으로 단어를 활용하며, 단어를 문장의 최소 단위로 생각했지만, Fast-Text방식은 단어를 더 쪼갠 n-gram형식을 Input값으로 활용하며, 문장의 최소단위로 생각했다.

간단해 보이지만 두 방식의 차이는 학습되지 않았던 단어를 벡터화할때 다른 결과를 보여주었다. Word2Vec방식 같은 경우, 기존에 학습된 단어사전에 없다고 오류를 만들어내지만 Fast-Text의 경우 n-gram을 통해 해당 단어를 벡터화 할 수 있다.

 

이러한 Fast-Text의 특성과 모든 단어를 다 학습하는 것은 어렵다고 판단했기 때문에 최종적으로 Fast-Text를 기반으로 추천 시스템을 구성하기로 결정했다. (자세한 내용은 아래의 참조 부분을 살펴보면 좋을 것 같다.)

워드 임베딩을 활용해서 구축하려고 했던 추천방식은 아래와 같은 로직으로 작동된다.

---

1. 텍스트 데이터 수집(크리에이터 콘텐츠, 광고주 제안서)
2. 텍스트 데이터 전처리 및 키워드화
3. 키워드로 워드 임베딩 모델 학습
4. 아이템 벡터화

---

이렇게 생성된 벡터로 유사도를 구해 추천하는 방식이 내가 생각했던 추천 시스템이었다.

그림으로 나타내자면 이런 느낌?

 

이렇게 추천 로직을 만들고 난 후에 아래와 같은 방향성을 가지고 플라스크를 기반으로 한 웹서버를 구축할 것이다.

---

1. 플라스크로 단일 서버 구축하기
2. 검색 성능 향상
3. 포트 포워딩으로 외부 접속 허용하기
4. uWSGI와 gunicorn

---

사실 플라스크 단일 서버로만 구축하는 건 개발 단계에서만 사용되는 방식이다.

플라스크 단일 서버로는 여러 명의 사용자가 해당 웹서버를 사용하는 것이 힘들기 때문이다.

그래서 실제적으로 플라스크 또는 장고를 활용하여 웹서버를 구축할 때는 nginx+uWSGI+Flask의 형태로 구축하게 된다.

하지만 실제적으로 추천 시스템 서버를 여러 개 운용하지는 않을 예정이라 nginx는 제외한 uWSGI만을 적용할 것이다.

 

참조링크

TF-IDF 관련 링크
https://wikidocs.net/31698

 

FastText 관련 링크
https://wikidocs.net/22883