Blue Mosaic 프로젝트 소개 및 회고록1 #GDSC #FE

 

     Blue Mosaic     

 

 

" 해양 보호 프로젝트는 해양 쓰레기 문제를 해결하고 해양 생태계를 보호하기 위한 프로젝트입니다. 우리의 목표는 쓰레기의 종류와 양을 파악하고, 해양 생물의 다양성을 조사하는 것입니다. 이를 위해 우리는 gemini-1.0-pro-vision-latest를 활용하여 쓰레기와 해양 생물의 사진을 분석합니다. 이 프로젝트를 통해 지속 가능한 해양 사용에 기여하고, 해양 생물에 대한 공중 인식을 증진시키는 것을 기대합니다. "

"The Marine Protection Project is an initiative aimed at addressing the issue of marine litter and preserving marine ecosystems. Our goal is to identify the types and quantities of trash, and to investigate the diversity of marine life. To achieve this, we are using gemini-1.0-pro-vision-latest to analyze photos of trash and marine creatures. Through this project, we hope to contribute to sustainable marine use and enhance public awareness of marine life."

- 시연 영상 ( Demo Video ) -

https://youtu.be/w9DMoIpzgzk

 
팀원 정보
 
BE: 2명 FE: 1명 AI: 1명
개발 기간 : 2024-01-22 ~ 2024-02-26 (1 month)

---

 
#목차
 
1. 들어가기
2. 어라? 벌써부터
3. 프론트 살려줘
4. API 연결의 달인이 되자
5. 그렇다면 어떻게 했는데
 

---

# 들어가기

 
개인적으로 기대가 컸던 GDSC 팀프로젝트이다. Google DSC라서 헉,, 나 구글소속? 라는 기대감 속에 팀프로젝트를 진행했다. GDSC는 학교내에서도 기본적인 프로젝트는 진행할 수 있는 학우들이 모인 나름 쟁쟁한 동아리라 기대가 더 컸었다. 첫 오프라인 회의는 순조롭게 진행되었다.
 

 
늘 그랬듯이 노션 페이지로 일정관리를 진행하였고,, 이는 얼마안가 사용하지 않았다. ㅋㅋㅋㅋㅋㅋ 사실상 노션의 주기능은 문서 정리 및 관리, API 문서 및 일정관리에 주 핵심인데, 사실 관리할 일이 많지 않았다. 문서도 주제를 정하고 나서는 개발할 때 볼 일이 많이 없었고, API도 스웨거를 사용했다. 그러나 노션에서 모든 주제 회의와 인사이트를 미리 정리했기 때문에 프로젝트 영문 소개 구글 폼제출에서 시간을 많이 절약할 수 있었다.
 
 
 

# 어라? 벌써부터

 
이번 프로젝트에서 가장 큰 문제는 팀원들의 프로젝트 참여도였다. 첫 오프라인 주제회의 이후 두 명의 팀원이 카톡에서 대답을 하지않기 시작했다. 어쩌다보니 내가 팀장 비슷한 일을 하고 있었고, 심지어 직무도 1인 프론트였다.
 
??? : 확 화면에 안 띄워버릴라
 
내가 프론트라서 다행인건지, 눈에 보여서 티가 많이나는 이 프론트는 막중한 책임감이 생겼고, 대답도 하지않는 이 팀원들을 어떻게 해야할지,,, 참 고민이 많았다. 코어진이 있는 톡방에서 대답을 하지 않다니? 다행히 백엔드였던 영인 언니가 이제부터 카톡을 확인하면, 체크 표시를 하기로 했고 주의만 줬을 뿐 사실상 의미가 없었다 . . . 이때부터 AI 팀원은 대부분의 회의에 불참했다. AI의 학습률을 최대한으로 높이기 위해 우선순위를 뒤로 했는데, 솔루션챌린지 첫 마감전에 AI를 연결못하겠다하고 마지막까지 참여를 하지않았다. google API를 사용하자는 대책이 나왔으나, 그는 탈주했다. 사실상 3인 개발인 이유,,,
 
AI가 주기능이지만 쓰레기 수집과 해양 생물 분석은 백엔드와의 연결도 하지 못했다. 주기능을 제외하고 개발을 진행하였으나 일정이 모두 밀려서 제출 3일전에 다른 백엔드 준호님이 gemini-1.0-pro-vision-latest를 사용하여 모두 만들었다. 그는 도대체,,,
 
 

# 프론트 살려줘

 
 

 
여기까지 읽었다면 프로젝트가 얼마나 P형으로, 벼락치기로 돌아갔는지 감이 올 것이다. AI의 여파로 백엔드 쪽 API는 제출 전까지 수정사항이 있었고, 프론트는 상시대기하며 무박해커톤을 할 수 밖에 없었다. 각종 API가 바로바로 올라올 때마다 확인을 해야했고, 많은 오류로 다시 돌려보내야했다. 특히 FormData를 통한 이미지 전달은 Swagger 요구명세와 달라서 API 연결 과정에서 여러번 확인이 필요했다. 나중에 프론트에서 오류가 나더라도 돌아오는 건 제 컴퓨터에선 돌아가는데요??라는 대답이였다. 그리하여 깃허브 merge 방식을 squash and merge에서 일반 merge로 바꾸어 커밋 메세지를 팀원이 편하게 확인 할 수 있게 변경했고 프론트단에서 해당 커밋 메시지를 확인하라고 VSC 로 확인하는 법을 알려주고 더 시간이 촉박해서 실시간으로 화면공유로 보여줘야했다.

# API 연결의 달인이 되자

스마일게이트 데브 캠프가 19일에 끝나서 사실상 20~26일 코어 개발이었다. 그래서 그전에 최대한 백엔드 API라도 개발이 끝나길 바랐다. 그러나 위와 같은 사태로 추가적인 개발이 끊이질 않았고 프론트는 신속정확 API 연결을 위한 페이지를 고려했다. 내 체력이 다하면 이 프로젝트는 망한다는 생각이 나를 이끌었다.


이번 프로젝트로 API를 어떻게 관리하는지 도가 텄다.  코드 수정 없이 코드 추가만으로도 스웨거와 최적이 되도록 관리하는지 깨달았다. 따라서 디스코드 화면공유를 하며 30초 만에 API를 추가하고, zustand 스토어는 기존 코드 재사용으로 2분 만에 연결하여 백엔드 API를 최소 3분 내에 확인할 수 있었다.

백엔드는 컵라면을 먹지 못할 것이다. 많은 API 반환으로 프론트가 프로젝트의 생산력을 올릴 수 있는 방법은 빠르고 정확한 API 연결 및 확인이었다.

# 그렇다면 어떻게 했는데

 

 
 30초내 API 연결을 위해서는 코드 재작성을 최소화히고 재사용성을 극대화해야한다. 이는 코드를 추가하면 작동하게 붕어빵틀에서 붕어빵 찍어내듯 객체화를 해야하는 이유였다. 깃허브에서도 기존의 squash and merge에서 기본 머지로 변경해서 백엔드도 커밋내역을 편하게 확인하게 해주었다.


이제부터 1인 프론트로 어떻게 프로젝트를 관리하고 객체화한 객체리터럴 코드를 작성했는지 다음 포스팅에서 알아보자.
https://dingx2-story.tistory.com/129

React API 스웨거(spring swagger)와 axios 최적화로 관리하는 방법, 커스텀 인스턴스 객체 모듈화 + 객체