[프로젝트 후기] 개발자를 위한 자동 카테고리 분류 북마크 서비스 : DevMark

 

💡프로젝트 소개

 DevMark는 2024-1 명지대학교 데이터테크놀로지 전공 캡스톤디자인에서 제작한 프로젝트이다.

 

✅ 개발 기간

2024.03.05 ~ 2024.06.11 (아이디어 선정 ~ 최종 발표, 99일)

 

✅ 개발 인원

총 4명 

서버 및 데이터 크롤링: 1명

AI 모델 선정 및 논문 작성: 1명

안드로이드 & 크롬 확장 프로그램: 2명

 

✅ 소통 방법

• 노션 + 피그마 + 줌을 통해 문서 관리, 소통 진행
• 노션 DB에 있는 ID 속성을 통해 이슈 관리를 진

 

 

💡프로젝트 진행 과정

✅ 주제 선정

북마크란?

인터넷에서 자주 찾는 웹 사이트를 별도로 등록함으로써,

주소를 매번 입력하지 않고 클릭만으로 쉽고 빠르게 접속할 수 있게 하는 일.

 

Pain Point - 최초 문제

사용자가 포스트 내에서 정보를 얻은 시점부터, 정보가 휘발되기 시작함.

 

Pain Point - 대안

이를 방지하기 위해, 북마크/메모 기능 등을 사용

 

Pain Point - 진짜 문제

기본 브라우저 북마크 기능의 한계

북마크 관리 미흡으로 인한 무분별한 북마크 쌓임.

 

 

✅ 데이터 수집

Android, AWS, Flutter, Golang, Spring, Swift, TensorFlow, Unity, ... 

많이 검색되는 언어, 프레임워크를 키워드로 하여

 

Tistory, Velog, Medium의 검색 기능을 사용.

사용한 키워드와 검색한 블로그의 도메인, 제목을 하나의 컬럼으로 저장

 

약 36개의 카테고리(키워드)를 약 300개 씩 수집하여, 총 13,000여개의 데이터를 수집

 

✅ 데이터 전처리

한국어 형태소 분석기인 KoNLPy에서 Kkma 품사 태깅을 사용하여 제목에서 명사, 외국어를 분리

-> 개발과 관련된 단어들의 경우 일반적으로 영어를 그대로 사용하기 때문에 품사 태깅에 추가

 

✅ 모델 선정

BERT 사용해 카테고리 분류를 진행한 결과: 0.08%

Word2Vec 사용해 카테고리 분류를 진행한 결과: 0.48%

 

=> 서비스에 사용하기 어려울 정도의 정확도를 보임.

 

그래서, 정확도가 낮게 나오는 이유를 분석해보니

카테고리 분류를 위해서는 Sequence를 예측하는 것이 아닌 분류하기 위한 모델이 필요하다는 것을 알게 됨.

 

결국, Naive-Bayes 모델을 사용하는 것으로 결정

 

다만, 해당 모델을 사용한 분류기의 경우 고질적인 2가지 문제가 존재.

 

1. 각각의 Class의 데이터 크기가 불균형할 경우 학습이 올바르게 진행되지 않음

2. 데이터 간 서로 독립적이다는 전제 조건이 필요함

 

실제로 데이터 수집 시 블로그 포스트의 특성 상 카테고리 마다 동일한 양의 포스트 수를 수집하기 어렵고

동일하게 수집한다 하더라도 타이틀에 포함된 단어의 개수가 모두 다르기에 균형있게 수집하기에는 어려움이 있음

게다가 다른 카테고리 포스트에서도 유사한 단어들이 사용되는 경우가 매우 많음

 

이 문제를 해결하기 위해, Complement Naive-Bayes Classifier라는 분류기를 찾게 됨.

해당 분류기는 아래와 같이 문제를 해결할 수 있음.

 

1. 각각의 Class의 데이터 크기가 불균형할 경우 학습이 올바르게 진행되지 않음

=> 특정 Class에 포함되지 않는 확률을 활용해서 보안 Class를 추가

 

2. 데이터 간 서로 독립적이다는 전제 조건이 필요함

=> 분류 가중치에 정규화를 적용하여 Feature간 의존성이 강한 클래스와 약한 클래스들의 가중치를 조절

 

✅ 모델 성능 선정 기준

 

✅ 모델 성능 검증

학부생, 현직 개발자 등 개발 관련된 지인 대상.

수집한 데이터 셋에서 무작위로 선정된 포스트 제목에 제시한 카테고리 중 가장 알맞다 생각하는 카테고리를 입력 받도록 함.

=> 설문 결과와 실제 모델을 돌린 결과를 비교하여 모델의 검증을 진행

 

설문 결과 협업 종사자 10명, 학부생 12명으로 총 22명이 설문에 응답.

 

모델 정확도: 83.3%

설문을 통한 사람의 분류 정확도: 76%

 

일부 설문의 경우 여러 카테고리가 같이 사용될 수 있는 타이틀이 존재해

설문지의 응답이 오답이 나오기는 했지만, 모델의 경우 어느 정도 잘 분류해주고 있음을 확인함.

 

 

✅ 시스템 아키텍처

Kubernetes 및 Gitops(Argo CD)를 활용한 지속 가능한 서비스 구조 설계

 

Gitops를 채택한 이유

요구사항이 빈번하게 달라지는 프로젝트 특성 상 서버 환경 및 구조 변경도 빈번하게 이루어짐

이때 서버 환경 설정을 담는 하나의 템플릿을 생성하여 관리함으로써 서비스의 관리가 편해진다는 장점이 존재함

 

✅ ERD

 

✅ 기술 스택

 

✅ LLM

해당 프로젝트에서는 사용자가 북마크 시 해당 포스트의 타이틀 추출과 요약이 필요한데, 이 기능을 수행하기 위해 LLM 모델이 사용됨.

 

토큰 제한 한계를 해결하기 위해 Gemini와 OpenAI(GPT-4o)를 적절하게 섞어서 사용함.

 

타이틀 추출의 경우,

도메인(Tistory, Velog, Medium, Github Blog ...)마다 HTML 구조가 다르고, 같은 도메인이더라도 블로그 템플릿에 따라 구조가 달라지기 때문에 이를 일일히 대응하기 보다 LLM 모델을 사용하는 것이 좋다고 판단.

 

요약의 경우,

타이틀 추출과 마찬가지고 HTML 구조를 분석할 필요 없이 LLM 모델에 HTML을 바로 넘겨 포스트의 내용을 요약이 가능

 

✅ 메뉴 트리

 

✅ 화면 설계서 (주요 화면만)

 

✅ 시연 영상 

 

💡 성과 및 배운 점

한 학기 동안 이런저런 경험을 하면서 힘든 일도 많았고 좋은 일도 있었지만, 결국 좋은 결과를 얻게 돼서 의미 있는 프로젝트였다고 생각한다. 매주 교수님의 피드백을 받고 개선해 나가면서 많은 것을 배웠고, 전공이 데이터이지만 AI 모델을 프로젝트에 직접 적용해본 건 처음이라 좋은 경험이었다. 처음에는 AI 모델이 어렵게 느껴졌지만, 해보니 그렇게 어렵지 않다는 것을 알게 되었다. 이 프로젝트를 통해 이론을 실제로 적용하면서 문제 해결 능력도 키울 수 있었던 유익한 시간이었다.