[부스트캠프 AI Tech 5기] LV3 - Final Project

본 게시물의 내용은 '부스트캠프 AI Tech lv3의 Final Project 을 마치고 개인적인 회고로 작성하였다.

 

우리 팀은 '생성모델'을 주제로 모였던 팀으로,

너무 흔하지도 않고 괜찮은 주제를 고민하다가 앨범 커버를 맞춤형으로 빠르고 쉽게 만들어주는

💽앨범 표지 맞춤 제작 서비스💽

로 선정하게 되었다.

 

 

🎵 프로젝트 기능

1. '사용자가 입력한 노래의 Text 정보'를 통한 앨범 커버 생성

- Stable Diffusion 모델

- ChatGPT API를 사용하여 입력받은 노래 정보로 prompt를 추출하여 학습에 사용

- 약 3분 시간 소요

 

2. '사용자가 입력한 노래의 Text 정보 + 얼굴이 들어간 Image 정보'를 통해 앨범 커버 생성

- Dreambooth 모델

- ChatGPT API를 사용하여 입력받은 노래 정보로 prompt를 추출하여 학습에 사용

- 입력받은 이미지로 Fine-Tuning 함

- 약 30분 시간 소요

 

* 추가정보

노래 정보	이미지 정보
필수입력 : 노래 제목, 가수 이름 선택입력 : 앨범명, 장르, 가사 (출처 : 멜론 음원사이트)	최소 4장, 최대 10장 필요 JPG, JPEG, PNG 파일만 가능 이미지당 한 사람의 얼굴만 포함되어야 함 이미지의 성별도 추가 입력 받음

 

* 프로젝트의 자세한 내용은 아래의 Github과 Wrap-up Report를 참고해주세요.

 

 

🎵 나의 역할

1. Front-End 구축

기존에 스캐치 형태로 Streamlit을 활용한 프론트엔드는 스타일링과 디자인 커스터마이징, 특정 기능을 구현하는데 제한이 있었다. 이로 인해서 프로젝트의 완성도가 떨어지는 상황이였다. 프로젝트의 기간이 2주 밖에 남지 않았음에도 불구하고, 팀원 모두 적극적으로 동의하에 HTML/CSS, JavaScript를 활용하여 완전히 새로운 프론트엔드를 구축하기로 결정하였다.

나는 원래 프론트엔드를 담당할 생각이 없었으나, 팀 내에 웹/앱 개발 경험이 유일했어서 어쩌다보니 프론트엔드를 전반적으로 담당하게 되었던 것 같다.

사실 2주 남짓 남은 상황이였어서 기간 내에 완성하는 것이 걱정되었는데, 다행히 Bootstrap 프레임워크를 사용해서 빠르게 구축할 수 있었다..!

Bootstrap 프레임워크가 처음에는 어렵게 느껴졌으나, 유튜브 영상과 공식 문서를 통해 Boostrap의 튜토리얼, 기능 및 사용법을 찾아보고 직접 적용해보면서 빠르게 습득 할 수 있었다.

 

그리고 인터페이스는 사용자 중심의 서비스를 제공하고자 노력하였고, 팀원들의 의견을 적극적으로 반영하였다.

프론트엔드를 개발하는 입장이 되어보니, 사용자의 요구사항을 반영하는 것이 중요하단 걸 깨닫게 된 것 같다.

(개발하던 입장에선 세부 기능에만 집중하여 숲이 아닌 나무만 보게되는 경향이 있었달까..)

팀원들의 의견이 없었다면, 지금의 프론트엔드도 없었을 것이다.

당시에는 기간 내에 완성해야 한다는 압박감과 잠을 제대로 자지못해 정신적으로 피곤한 상태에선 느끼지 못했지만,

프로젝트가 끝나고보니 피드백을 많이 해줬던 팀원들 덕분에 완성도 높은 결과물을 얻은 것 같아 고마운 마음이 든다.

이 경험을 통해서 개발자 입장이 아닌 사용자 입장에서 한번 더 생각해보게 되었고, 팀원들과의 협력과 소통의 중요성도 더욱 깨닫게 되었다.

 

프론트엔드 화면은 크게 3가지로 메인화면/이미지 생성 화면/마이페이지 화면이 있다.

메인 화면은 사용자들이 프로젝트의 기능을 쉽게 이해하고 흥미를 높일 수 있도록 디자인되었다.

사용자들은 메인 화면에서 예시 이미지들을 살펴볼 수 있고, 이러한 이미지들은 BigQuery에 저장된 테이블 정보를 기반으로 가장 최신순으로 별점이 높은 이미지 12개를 표시해주었다.

이미지 생성 화면은 사용자가 앨범 커버를 손쉽게 생성할 수 있도록 직관적으로 구성되었다.

'Create' 버튼과 이미지가 표시될 위치가 사용자에게 잘 보이도록 배치하였고,

이미지는 한 번에 4개씩 보여지며, 이미지가 생성되면 각 이미지 위에 다운로드 버튼이 나타난다.

사용자는 해당 버튼을 클릭하여 리뷰를 작성한 후 이미지를 다운로드할 수 있다.

마이페이지 화면은 로그인한 사용자는 자신이 리뷰를 작성한 이미지를 최신순으로 확인할 수 있다.

이미지를 가져오는 시간을 고려하여 20개로 제한하였고, 각 이미지를 클릭하여 해당 이미지에 입력했던 정보를 확인할 수 있다.

 

아쉬운 점은 일단 기능 구현에 우선순위를 두어 디자인 부분을 좀 더 개선하지 못한 점이 아쉽긴 하다..

팀원들은 디자인에 크게 신경쓰지 않아도 된다고 말했지만, 프론트엔드를 개발하다보니 사용자에게 보여지는 부분이다보니 디자인 요소에 욕심이 생겼던 것 같다.

또한, 프로젝트 구축 과정에서 배포 준비가 되지않았기에 실제 사용자들의 피드백을 받지 못한 점이 아쉬웠다.

팀원들은 우리 프로젝트의 기능을 잘 알고있으므로 사용하는데 어려움이 없었지만,

실제 사용자들은 프로젝트에 대한 사전 지식이 없기에 쉽지 않을 수도 있다고 생각했었다.

배포가 완료된 후, 다른 캠퍼들의 사용 후기를 들어보니 다들 프론트엔드 알아보기 쉽게 잘했다고..칭찬받았다ヾ(≧▽≦*)o

(완전 기뻤다..ㅎ 힘들었던게 다 날라가는 느낌!╰(*°▽°*)╯)

 

프론트엔드 일부 화면은 아래와 같다.

메인 화면(좌) / 이미지 생성 화면(우)

* 추가 자세한 정보

Frontend

 

2. Prompt 실험

Stable Diffusion 모델을 통해 Prompt를 변경해보며, 어떤 Prompt가 이미지 생성에 효과적인지 최적의 Prompt를 찾기 위한 실험을 진행하였다.

생성 모델 특성상 평가 지표가 없어서, 어떤 모델이 더 좋은지 판단하기가 어려웠던 것 같다.

또한, 이미지의 퀄리티를 높이는데도 꽤 애먹었다.

일단, 시중에 나와있는 앨범 커버는 가수 개개인의 특성을 담고 있어서 노래 정보와 연관이 없는 경우가 많았다.

또한, 대부분 앨범 커버가 텍스트가 포함되어 있었다.

(시간이 된다면 앨범 커버에 있는 텍스트 데이터를 따로 수집하여 데이터셋을 직접 세분화해보자는 의견도 있었지만 못했다.)

 

실험했던 prompt는 아래와 같다.

1) 가사의 인사이트

가사에서 추출한 인사이트를 300자 이내로 제한하여 사용하였다.

그러나 이 경우 생성된 문장이 잘린 경우가 발생하여 좋은 결과물을 얻기엔 다소 부족해 보였고, 마찬가지로 결과도 만족스럽지 못했다.

 

2) 감정 키워드

emotion_words = ['사랑', '이별', '기쁨', '슬픔', '설렘', '미안', '후회', '우울', '행복', '불안', '불만', '분노', '외로움', '감사', '희망', '그리움', '자유', '용기', '죄책감', '환희']

20가지의 감정 키워드 중 가사에 포함된 것이 있다면, 여러 개를 뽑아달라고 하였다.

그러나 이 방법은 감정 키워드가 제한되어 과적합이 발생하는 경향을 보였다.

따라서 프롬프트를 다양하게 넣어주는 것이 결과물 개선에 도움이 될 것으로 판단할 수 있었다.

 

3) 해당 앨범커버의 노래제목과 아티스트 설명

앨범 커버에 대한 정직한 설명으로

Music Album Cover of '노래제목(영어)' by '아티스트(영어)' 를 사용하였다.

의외로 해당 앨범 커버에 대한 정직한 설명을 넣어준 것이 이전의 실험보다 퀄리티가 더 좋다고 느꼈었다.

 

4) 3번 실험에서 장르와 가사 키워드 1개 추가

3번 실험에서 '장르'와 '가사'에서 느껴지는 키워드 1개를 추가하였다.

이 방법은 3번 실험보다 약간 더 다채로운 결과를 얻을 수 있었다.

 

또한, 모든 실험에서 많이 학습시킬수록 이미지가 노이즈처럼 나오는 현상이 발생하였다.

* 추가 자세한 정보

Prompt

 

3. 데이터베이스 설계 및 구축

데이터베이스는 프론트엔드를 끝내고 나서 프로젝트 구조를 훑어보다가

기존의 데이터베이스는 설계했던 것 없이 구현하다보니 필요한 것이 생기면 column이 추가되는 방식이였다.

그러다보니 데이터가 일정한 규칙없이 들어가게 되었고, 원하는 정보를 한 번에 찾기도 어려웠다.

그래서 데이터베이스 개선이 필요해보여서 시작하였다.

 

데이터베이스 설계를 하면서, 어떻게 해야할지 고민을 많이 했었다.

먼저 첫번째는 데이터베이스 설계 원칙인 정규화 측면에서 설계해보았다.

장점으로는 중복되는 내용이 없고 일관성있는 테이블로 데이터베이스 용량을 많이 차지않는다.

하지만, 단점은 테이블을 여러 개로 분리하면서 생기는 조인 연산으로 성능 저하가 발생할 수 있고, 데이터베이스 구조가 복잡해진다.

 

두번째는 정규화를 따르지 않고 설계해보았다.

장점은 테이블 개수가 적어 조회가 빠르고 간단하다. 또한, 데이터베이스 구조가 단순해진다.

하지만, 단점은 정규화를 따르지 않으므로 중복되는 내용이 들어갈 수 있다.

 

결과적으로, 

데이터베이스 용량은 Google Cloud의 대규모 데이터셋을 저장가능한 BigQuery에 저장하므로 큰 장점은 아니라고 생각하였고, 메인화면 및 마이페이지에서 이미지를 가져오는 쿼리연산이 필요하므로 빠른 조회를 위해

정규화를 따르지 않은 두번째 데이터베이스 설계를 채택하였다.

또한, 보안성 측면을 고려해 PK는 UUID, 사용자의 이메일은 도메인을 마스킹하는 방법을 사용하였다.

 

문제는 구현 작업에 들어갔을 때 였다.

BigQuery의 특성을 미리 사전조사하여 파악하지 못한 점이였다.

구현을 진행하다보니, 테이블의 내용을 Update해야하는 쿼리문이 필요했는데

왜인지 에러가 계속 발생하였다.

찾아보니.. BigQuery는 애초에 대량의 데이터를 분석하는데 초점이 맞춰진 데이터웨어하우스여서 수정/삭제의 기능이 제한되어 있다고 한다..

 

이전의 로컬에서 저장했던 데이터웨어하우스는 기능 제한이 없었기에, 당연히 똑같은 줄 알았던 것이다..

처음부터 사전조사를 하고 데이터베이스 설계를 더 신중하게 했다면..

수정/삭제가 필요한 경우를 대비해 대안을 마련하면서

더 나은 데이터베이스를 구축할 수 있었을텐데.. 그 부분이 아쉬웠던 것 같다.

 

그래도 데이터베이스를 잘 완성하여

원하는 데이터를 확인하고자 할 때, 빠르게 확인할 수 있어서 뿌듯하였다! 

* 추가 자세한 정보

Database

 

🎵 Github

GitHub - boostcampaitech5/level3_cv_finalproject-cv-03: level3_cv_finalproject-cv-03 created by GitHub Classroom

 

🎵 Notion

Final Project(2023.07.03 ~ 2023.07.28)