1년 뒤에 작성하는 마이셀럽즈 인턴 정리

🍔  프로젝트명

[2021.08~11]

키토크 기반 뷰티 검색‧추천 서비스 글램아이의 화장품 데이터셋 매핑 자동화 모델링 프로젝트

 

 

🍔  키토그란?

사진 1 “취향필터”에서 볼 수 있듯 유저가 당장 떠올리긴 힘들지만 원하는 검색 결과를 얻을 수 있도록 세심한 취향을 포함한 추천 검색어를 바로 키토크라 부릅니다. 이 키토크를 추출하는 기술을 키토크 기술이라 명명한다면, 키토크 기술을 적용하기 위해서는 아래 사진 1처럼 풍부한 데이터셋이 바탕이 되어야 합니다.

사진 1. 원데이터셋에서 추출한 키토크 (예시)

 

🍔  목표

제가 속한 팀의 목표는 차후 키토그 추출 기술에 활용하기 위한 여러 소스에서 화장품 리뷰와 제품 데이터 (무게, 색상, 피부 타입 등)를 포함한 데이터셋 구축이었습니다.

단순 스크래핑 작업을 넘어 기존에는 각 데이터 소스(스크래핑 타깃 웹사이트) 별로 화장품 일치 여부 판단이 수기 작업에 의해 이루어졌다면, 이번 프로젝트를 통해 데이터 소스 별로 화장품 이름이 기재된 방식과 이미지를 바탕으로 텍스트의 유사도와 이미지 유사도 정도에 각 가중치를 부여해 동일 제품임으로 판단되는 혹은 의심되는 제품 개수 줄여 수기로 매핑하는 작업을 최소화시키는 것이 목표였습니다.

 

 

🍔  담당 업무

• 리뷰 및 제품 부가 설명 스크래핑 코드 작성
• 텍스트 전처리
• DB 업로드 및 업데이트

 

🍔  팀원

데이터 분석 1명 - 주임님

데이터 스크래핑, 전처리 1명 - 인턴 1명 [본인]

수기 매핑 - 인턴 1명

 

 

🍔  담당 업무 상세 + 마주친 문제 및 해결방법

• 스크래핑 과정
  • 부족한 자원과 에러 처리 문제
    웹사이트별 화장품 포스팅이 적으면 몇만 개에 많으면 100만 개 단위까지 다양했는데요, 각 제품의 리뷰데이터까지 포함해야 한다고 하였을 때, 주어진 시간, 스크래핑을 구동할 수 있는 컴퓨터 개수 등의 자원이 정해진 타임라인 안에 완료 짓기에 굉장히 부족했습니다. 그래서 각 팀원이 각 컴퓨터 3대씩 그 외에도 Colab 클라우드 서버를 2개 이상 돌리며 가능한 모든 자원을 동원하여 스크래핑을 진행했습니다 하지만 스크래핑 과정에서 예측할 수 없었던 많은 예외가 발생하고 처리해야 하는 코드가 추가되게 되는데…
    
    • 데이터 제공 서버의 의도적인 모바일 뷰 렌더링 → 기존 스크래핑 코드 무효화
    • 스크래핑 서버 외부 네트워크 문제 → 주말 동안 유실 발생

• • 응집화된 코드의 필요성
    이렇게 10대 정도의 컴퓨터가 같은 코드를 공유하는 상태에서 에러 처리 코드를 반복적으로 공유하는 상황은 프로젝트를 굉장히 지체시켰습니다. 스크래핑 코드의 경우 기능별로 함수를 분리하게 되면 하나의 목표 데이터를 스크래핑하기 위해 함수의 개수가 10여 개가 넘어가게 되고, 제품명, 제품 링크, 리뷰, 이미지 링크, 색상, 용량 등 화장품 정보까지 스크래핑할 경우 매우 많은 변수를 선언하고 저장해야 하는 상황에서, 좀 더 공유와 업데이트가 쉬운 응집화된 코드를 작성하기 위해 OOP를 실무에서 처음 사용하며 복잡하고 많은 로직을 물리적으로 하나의 클래스로 관리하였습니다. 대표적인 OOP의 다음 특성들을 구현하며 응집화의 중요성을 필히 느낀 시간이었습니다. 
    • 상속이 가능한 [상속]
    • 여러 형태로 재구성이 가능한 [다형성]
    • 본질적인 공통적 특성만 보아 캡슐로 만든 [추상화]
    • 복잡성을 단순화한 [캡슐화] - DRY (Don’t repeat yourself! 무의미한 반복은 금기시)
      

• 전처리 과정
  • 데이터 소스 별로 화장품명이 기재된 방식이 달라 동일 제품으로 판단이 어려운 문제
    • 제품 기술 목적 (판매용/설명용)에 따라 다른 제품 표기 방법
      2종, 1+1, 100ml, 증정, 무료배송처럼 상품 타이틀과 관계없이 반복적으로 출현하는 불용어 및 패턴들을 처리하는 불용어 및 패턴 리스트 생성 후 일괄 전처리.

전처리 전 후 결과

• • • 서로 다른 브랜드의 다른 상품이지만, 같은 이름을 가진 상품이 동일한 상품으로 분류되는 경우
      비교 대상 군을 브랜드 단위로 줄여, 매핑하려는 제품 A의 브랜드에 한하여 제품만 점검하기 위해 아래와 같이 브랜드 key 테이블 생성. 이에 앞서 아래와 같이 소스마다 브랜드 표기 방법이 다양하기에 각 케이스 별로 동일한 브랜드인지 판단할 수 있는 텍스트 유사도 알고리즘을 작성하였습니다.

	소스 A	소스 B
제품명	인셀덤보타랩	인셀덤
	이철커커	이철헤어커커
	박뷰 ( ← 축약된 브랜드 네임)	박준뷰티랩
	Nike ( ← 영문표기)	나이키

• 판매용 소스에 주로 나타나는 多 대 : 1 매칭
  소스 A의 경우 리뷰 데이터가 상품의 옵션이 여러 개인 상품 + 세트 상품에 관한 경우. 매핑된 상품 외에 다른 상품의 리뷰 데이터를 포함하는 문제 발생. 단일 상품 특징을 나타내는 소스 B의 상품들 여러 개를 소스 A의 세트 상품에 매핑시켜 해결. 

 

• 텍스트 모델링 과정 (tf-idf, mecab)
  주임님이 텍스트 모델을 구현해 볼 수 있는 기회를 주셔서 텍스트 tf-idf와 mecab을 활용한 모델링을 시도해 보았습니다.
  • tf-idf의 단순한 토큰화
    첫 시도로 tf-idf로 단순히 텍스트 유사도만 비교하였다가 단순히 띄어쓰기에 의한 토크나이즈가 진행되어 (썬 크림, 선크림, 썬 스틱, 썬스틱) ← 이러한 경우 유효한 의미 단위로 토큰화가 진행되지 못했습니다. 커스텀 화장품 사전을 만들어 문제를 해결할 수 있지 않을까?라는 생각해 Mecab 모델을 도입해 보았습니다.
  • Mecab의 사전 정의 단어 이외의 토큰화 문제 
    참조할 수 있는 라이브러리가 회사 내/외에 없어서 직접 만들었어야 했는데요, mecab모델에서 커스텀 화장품 사전을 만들어 (에멀젼, 스킨, 선크림) 단어들이 하나의 토큰으로 인식되도록 모델링을 해보았습니다. 영문 화장품 사전이 있어 한국어 표기법으로 번역한 후 그걸 사전으로 사용했습니다. 하지만… 영문은 한국어로 표기 시 서로 다른 자음, 쌍자음으로 (선크림, 썬크림, 애멀젼, 에멀젼) 표기될 수 있는 문제가 있었습니다. 여기서 또 토큰 추출이 안 되는 문제가 발생하여 결국에는 주임님이 새로 만드신 모델이 선택되었습니다 😅

• 디비 관리
  DBMS로 Sequel pro를 사용하였고 데이터 업로드 및 업데이트는 pymysql 라이브러리를 활용하였습니다.

 

🍔  첫 실무 경험을 하며 배운 점들

• 확실한 커뮤니케이션의 중요성
  동기적으로 진행되는 팀프로젝트의 경우에는 한 단계에서 문제가 생기면 그 뒤 단계도 연쇄적으로 영향을 주게 됩니다.
  “요구 사항을 확실히 파악하고 오래 걸리는 것보다 완벽하게 하고 넘어갈 것”을 배웠습니다.
• 능동적인 문제 해결
  모두가 바쁜 팀 프로젝트에서 모든 선택에 대한 의견을 물어 책임을 분산시키는 것은 전체적인 업무의 효율성을 낮춤을 배웠습니다. 스스로 선택하고 결과에 대해 책임집니다.

이렇게 인턴 기간을 회고를 해보지 않은 채 1년 여가 지났고, 의미 있던 경험을 문서화하는 것의 중요성을 느끼며 작성해 보았습니다.

코딩 실력 이외에도 확실한 커뮤니케이션, 끈기, 업무를 다루는 자세를 배울 수 있었던 귀중한 경험이었습니다.

이 코멘트를 마지막으로 긴 글을 마치겠습니다. 읽어주셔 감사합니다.