Imgenie는 네이버 커넥트재단에서 운영했던 부스트캠프 AI Tech의 최종 프로젝트로 만들었던 프로젝트다.
사용자가 이미지를 넣으면 노래를 추천해주는 서비스인데, 부캠이 끝나고도 미련이 남아 계속 개발을 했었다.
이 글은 이제 적어도 나는 얼추 마무리를 지어야 할 때가 온 것 같아 적는 회고글이다.
서비스는 아직 운영중이다. http://imgenie.co/ 이 링크로 들어오면 해볼 수 있다.
서비스에 대한 소개는 깃허브 저장소 혹은 노션 페이지를 참고하시면 되겠다.
🎯 초기 개발 목표
처음 개발할때는 프로젝트에 대해 걱정과 자신감 모두 마음속에 품고 있었다.
걱정은 이미지로 부터 음악을 추천해주는게 가능한 일인가? (성능에 대한 평가가 가능한가?) 싶었고, 그동안 우리 팀원들이 다들 잘해주셨기 때문에 다 잘 될것이라는 믿음이 있었다.
진로에 대한 고민도 빼먹을 수 없다. 제 아무리 회사들이 관심없다는 부캠 프로젝트지만 어필해 볼수는 있을 터! 내가 여기서 어떤 일을 했는지가 내가 지원하는 회사를 결정한다고 생각했기 때문이다.
아무튼 다시 우리의 혹은 나의 초기 개발 목표는 대충 아래와 같다.
- 추천 방법론 결정: 이미지에서 노래를 추천해주는 시스템은 개발 시점에는 도전적인 과제였다. 때문에 제대로된 노래를 추천해주는 방법론을 결정하는게 가장 중요했다.
- 추천 모델 도입: 우리 팀은 부캠에서 추천 시스템 팀이였고, 추천 시스템에 대해 배워왔었다. CV프로젝트에 가깝지만 그래도 해보고 싶었다.
- 멋진 화면 구현: streamlit같은 단순하고 데모버전과 같은 디자인 대신 화면을 직접 구현해 사람들의 관심을 한눈에 받고 싶었다.
- 지속 가능한 서비스: 부캠 기간동안만 서비스 하고 내리는건 좋지 않아보인다. 단순히 시도 해봤다는 것에 의의를 두는걸 넘어서 실제로 서비스가 가능한 서비스를 만들고자 했다.
- 크롤링 및 모델 자동 학습: 새로운 노래도 추천 해주고 싶어서 자동으로 크롤링한 후, 모델을 학습하고자 했다.
- 적극적인 Jira 사용: 원래 git은 사용하고 있었지만 현업에서 잘 쓰는 Jira를 도입하고자 했다.
- 쉬운 배포: 내 목표로, 오픈소스라면 타인이 코드를 쉽게 돌려 서버를 배포할 수 있어야 한다고 생각했다.
⭐️ 목표 달성 여부
아래 목표를 달성하기 위해 여러 부분에서 노력했다. 전부는 아니지만 많이 하고자한 바를 이뤘다!
목표 달성 여부를 먼저 보여주고 아래 문단에서 설명한다.
- 추천 방법론 결정: ✅
- 추천 모델 도입: 🫤
- 멋진 화면 구현: ✅
- 지속 가능한 서비스: ✅
- 크롤링 및 모델 자동 학습: 🫤
- 적극적인 Jira 사용: ✅
- 쉬운 배포: ✅
✅ 추천 방법론 결정
추천 방법론은 레퍼런스가 없어 꽤나 골치를 먹었다.
5월 10일에 아이디어가 처음 나왔는데, 7월까지 방법론에 대해 고민 또 고민 했다.
결국 어떤 05년생🤪 팀원이 레퍼런스가 될 논문을 가져왔다. "Image Is All for Music Retrieval: Interactive Music Retrieval System Using Images with Mood and Theme Attributes"
이 논문에선 이미지에서 분위기와 테마를 고려해서 음악을 검색하는 방법론을 소개하고 있다.
2단계로 이루어져있다.
1. DB에 준비되어 있는 이미지들과 쿼리 이미지의 유사도를 구함 (피쳐벡터를 가지고 비교함)
2. 상위 이미지들의 태그를 고른뒤 해당 태그와 매칭되는 노래를 출력한다.
우리는 조금 데이터가 달라 이 방법론을 그대로 가져올 순 없다.
우리의 데이터는 지니뮤직에서 크롤링했는데, 음악에는 태그가 있어도 분위기가 있는 일상사진이 없다.
때문에 플레이리스트를 사용해야 했다. (플레이리스트는 수록곡에 어울리는 일상 이미지를 달아주기 때문에 적합하다고 판단했다)
그래서 아래와 같다.
피쳐백터를 구하는 과정에는 VIT가 쓰였고, 위 논문과 달리 상위 k개의 플레이리스트를 선정한다.
그 후, 곡을 선정하는데 음악의 장르와 좋아요 수, 노래 개시 날짜를 이용해 룰베이스로 골라냈다.
(선호장르를 초기 화면에 사용자에게 고르라고 한다)
서비스 개선을 하면서 k개수가 조금 변동이 있긴 했지만 이 과정은 변함이 없다.
🫤 추천 모델 도입
추천모델은 부캠이 끝난 8월 부터 고도화 스프린트를 파서 하려고 했었다.
그렇기 때문에 우리는 서비스 내내 추천결과와 피드백(좋아요)을 로그를 모으고 있었다.
결국 추천이 잘 되는지 판단하기 위해선 이러한 데이터가 필요하기 때문이다.
개인화 추천에도 필요하기도 하고..
현재는 이 목표를 달성하지 못했다. 피드백 데이터가 600개 정도 되었는데
허수를 빼고나니 300개밖에 안된다. 이정도면 손으로 직접하는게 더 나을 수 있다.
그래서 추천모델 도입은 어렵다.
✅ 멋진 화면 구현
프론트를 구현해본 경험이 모두 부족해서 streamlit을 사용해서 구현하려 했었다.
그런데 이런 프레임워크를 사용하면 하나의 거대한 프로젝트 뭉탱이가 될것 같았다.
우리는 서비스 디자인에도 욕심이 있었기 때문에 사용에 용이하고 자료가 많은 React를 도입했다.
우린 애초에 프론트-백엔드-크롤링 팀 3명과 모델팀 2명으로 나누었는데 인력이 남는 것도 이유가 되었던 것 같다.
나와 같은 팀이였던 호랭이와 알빠노 팀원은 리엑트 강의를 바로 듣기 시작했는데 추진력에 놀랐다.
디자인은 사실 호랭이와 명예 팀원인 루시퍼님이(로고까지 만들어주셨다) 많이 도와주었다.
3주라는 짧은 기간동안 화면단은 많이 바뀌었다.
초기엔 위와 같은 디자인이었다. 파스텔 톤으로 가려했으나 블랙이 더 멋있어 보여서 바꾸게 되었다.
그리고 원래 결과 페이지의 음악 재생바는 유튜브 임베드로 되어있었다.
그 짧은 기간에 유튜브도 크롤링 했었다. (근데 유튜브에 워낙 없는게 많아가지고~ 검색도 잘안되고.. 이건 알빠노?님이 해주셨다)
지금은 스포티파이 api를 이용해 스크래핑한(api 호출해서 얻은 mp3를 db에 저장해둔다.) sample mp3파일을 틀어주는 형식으로 바꾸었다. 덕분에 대부분의 노래를 재생할 수 있었고 화면도 깔끔해졌지만 30초밖에 못듣는다.
개발에 있어선 화면 구현에 있어선 사실 리엑트를 잘 몰라 훅이나 컴포넌트를 제대로 활용하지 못한것 같기도 하다.
나는 구식이라는 함수형 컴포넌트를 주구창장 썼었는데.. 이 때문에 나중에 리팩토링을 하게 되었다.
✅ 지속가능한 서비스
우리는 애초에 서비스를 부캠이 끝나고도 서비스하고 싶었다.
물론 부캠에서 제공한 클라우드 서버를 이용해 개발을 해왔기 때문에 3주동안은 이걸로 서비스 할 수 있었다.
근데 부캠이 끝나고 8월이 된다면 이제 짐을 빼야 한다.
그래서 gcp를 대안으로 골랐다.
이유는 "gcp의 빅쿼리를 사용할지도 몰라서"와 "무료라서 ㅎㅎ" 사실 그래서 프론트는 진작에 gcp 컨테이너 위에 올려두었다.
애초에 그걸로 사람들에게 공개했다.
근데 백엔드는 좀 골치가 아프다.
모델이 들어가기 때문에 러닝시간이 길어질 수 있고 컴퓨팅 자원을 많이 쓰게되면 비용이 발생하기 때문이다.
그래서 미루다 미루다 결국 8월이 되서야 부랴부랴 짐을 옮기기 시작했다.
의외로 컴퓨팅 이슈는 발생하지 않았다.
조금 느리긴 했지만 10초안에 결과가 나와서 괜찮았고 무엇보다 이제 쓰는 사람이 없어 오히려 gcp는 .... 인스턴스 종료하라고 했다.
오히려 이슈는 로그에서 발생했다. 우리가 추천 모델에 활용하려고 했던 그 로그파일들인데.. 이렇게 서버를 옮기면 로그파일도 옮겨야 하고 불편함이 많았다.
때문에 DB를 구축하게 되었는데 이건 크롤링 파트에서 소개한다.
✅ 쉬운 배포
우리팀에서 나는 도커 중독자로서 도커를 계속해서 어필했다.
부캠에서 준 머신에는 왜 도커 안됨? 부터 시작해서 주구장창 도커를 외쳤더랬다~
도커를 어필한 이유는 다음과 같다.
- 도커를 이용하면 서버를 잘 모르는 팀원도 쉽게 서버를 올릴 수 있음 (환경 설정 이슈를 방지할 수 있음)
- github action이나 젠킨스를 연동해 개발 서버를 만들어 볼 수 있음
- gcp 무료 기간은 3개월이니 자주 서버를 배포해야 함
- 무중단 배포나 A/B 테스트를 해볼 수 있음 (쿠버네티스를 도입하거나 해서)
결국 8월 이후에 고도화 기간엔 도커화하는데 노력을 기울였다.
dev와 main브랜치에 커밋이 올라가면 dockerhub에 이미지를 만들어 업로드 했고,
dev 브랜치에 커밋이 올라가면 개발서버에, main 브랜치에 커밋이 올라가면 릴리즈서버에 자동으로 이미지를 갱신해주는 workflow를 작성하기까지 했다. (gcp에서 이미지 최적화 os를 지원하기 때문에 이걸 이용했다)
서버를 올리는 사람은 해당 명령어를 실행하고 깃헙 레포 환경설정만 바꿔주면 되겠다.
🫤 크롤링 및 자동 학습 도입
우리는 강의에서 airflow를 배웠기 때문이기도 했지만 최신곡도 추천해주고 싶어서 airflow를 도입해 크롤링부터 모델 학습까지 자동으로 돌리고 싶었다.
헌데 일단 문제가 있었다. 크롤링 코드는 yaml파일로 설정을 관리해야 했고, 출력도 csv로 나오기 때문에 다루기 어려웠다.
때문에 우리는 DB를 도입해 데이터를 좀 더 효율적으로 관리하고자 했다.
DB 설계에 큰 어려움은 없었다. 아래와 같은 초기 ERD가 있었기 때문이다.
왜 이런게 있냐면.. DB를 계속해서 어필하는 누군가가 있었기 때문 핫핫
DB는 mongoDB를 사용했기 때문에 위와같은 ERD는 어느정도 관계만 보는데 사용되었다.
크롤링 코드도 DB에 연결해 자동으로 DB에 없는 플리를 검색해서 갱신해준다.
근데.. 모델과 airflow 코드가 준비되지 않았다.😭
앞으로 더 한다면 이 목표가 우선순위가 될 것 같다.
✅ 적극적인 Jira 사용
나는 이전부터 jira에 대해 어필을 했었고, 팀원들도 잘 맞춰줘서 지라와 같은 협업 툴을 잘 써먹고자 했다.
처음에는 노션에 대부분을 적어두었기 때문에 노션지라(05년생 서동생이 맹글어주셨다) + 깃헙 이슈를 사용해서 프로젝트를 관리했다.
브랜치와 이슈가 묶이는게 정말 좋았다.
jira는 이번 최종프로젝트에 도입을 시작했다. 해보니 jira에선 이슈를 티켓이라고 하던데.. 큰 이유는 없는 것 같다. (그냥 멋있으려고! 참)
이번에는 깃헙 레포를 여러개로 만들어 관리했었는데 이를 하나의 프로젝트로 관리했다.
아쉬운점은 지라의 자동화나 배포같은 기능을 활용하지 못해서 아쉽다.
이번에는 그냥 이슈 관리용도로만 사용했다고 봐야겠다.
👏 끝마무리
Imgenie는 진짜 만드는것도 재밌었고 팀원분들도 너무 좋았다. 결과도 잘 나와서 너무 기쁘다.
8월동안은 아쉬운 마음에 자꾸 이 프로젝트를 붙들고 살았는데 앞으로는 역량을 키우기 위해 다른걸 해봐야겠다!
'프로그래밍 > 부스트캠프 AI' 카테고리의 다른 글
| [IMGenie] 결과 페이지 추가와 카카오톡 공유하기 (0) | 2023.10.06 |
|---|---|
| [Imgenie] https와 쿠키를 도입했음 (0) | 2023.09.27 |
| [Movie Rec] S3Rec의 모듈화 시도 (0) | 2023.06.25 |
| [DKT] Github Action 테스트 도입 (1) | 2023.05.20 |
| [DKT] lgbm에 label을 feature로 넣으면... (0) | 2023.05.12 |
