깃허브링크
https://github.com/dev2820/MMM
프로젝트 개요
MZ 세대가 자기관리의 중요성에 주목하고 있습니다.
2020년에 들어서며 외모를 경쟁력으로 생각하며 패션과 미용에 시간을 투자하는 남성들, 일명 그루밍족의 등장으로 국내 남성 화장품 시장의 규모가 폭발적으로 증가하고 있습니다. 하지만, 여전히 남성의 메이크업은 여전히 사회적으로 좋지 않은 인식을 받고 있습니다.
오픈서베이에서 조사한 남성 그루밍 트렌드 리포트 2021을 보면, 메이크업을 하지 않는 이유로 남성스럽지 않다는 부정적 인식, 시작 방법을 몰라서 등이 언급되고 있습니다.
MMM 프로젝트는 이와같은 메이크업 시작을 막는 진입장벽을 해소하는 솔루션을 제공하기 위해 기획된 서비스입니다.
개발 환경
| 분야 | 사용툴 |
|---|---|
| Front-end | Vue, Vuex, Vue-router |
| Back-end | Nodejs, Express |
| DB | MySQL |
| DevOps | Google Cloud Platform, Docker, Github |
| Communication & Design | Figma |
| AI | Tensorflow, Scikit-learn, Teachable Machine |
후기
Frontend 2명, Backend 2명, AI 1명, 총 5명으로 이루어진 팀이었습니다. Frontend 1명, Backend 1명은 기존에 같이 팀프로젝트를 진행해본 팀원이고 나머지는 프로젝트가 처음이었습니다.
개발 기간은 2021/11/09 ~ 2021/11/30 으로 3주간 진행되었습니다. 첫 1주일은 주제 선정 및 서비스 구상, 나머지 2주간 코드 작성을 진행했습니다. 이번 프로젝트의 핵심은 어떻게 최소한의 시간을 투자해 프로젝트를 완성시키냐 였습니다. 5명 모두 학생이기 때문에 수업&과제를 하면서 프로젝트를 진행해야했거든요. 처음부터 난이도가 높았습니다.
주제선정은 썩 마음에 들진 않았다.
주제선정에서부터 어려웠습니다. 주제가 MZ를 위한 웹/앱 서비스였죠. 이게 주제를 명확히 제시하는듯 하면서도 아주 광범위하고 모호한 주제입니다. MZ의 개념상 정의는 10~40대를 아우르기 때문에 사실 핸드폰에 익숙한 사람들은 모두 해당했거든요. 때문에 MZ를 어떤사람들로 볼 지부터 토론이 진행됐습니다. 그리고 모든 팀원이 만족할만한 아이디어도 안나왔어요. 마지막에 겨우겨우 제가 꺼낸 아이디어로 진행을 시작했습니다.
서비스 구조 & 역할 분담은 빠르게 진행됐다.
전에 같이 프로젝트를 진행해본 팀원들이 있어서 역할분담은 빠르게 진행됐습니다. 서비스 구조는 들어가는 시간을 아끼기위해 최대한 간단하고 기본적인 구조로 짰고, 스키마도 최대한 간단하게, 짰습니다.
Frontend 프레임워크는 제가 익숙한 Vue를 쓰기로 했습니다. Vue는 러닝커브가 낮으니 다른 팀원도 짧은 시간안에 프레임워크에 적응할거라는 판단이었습니다.
Backend도 최대한 익숙한 프레임워크로 가자는 판단이었습니다. Express에 MySQL을 쓰기로 했죠. 다만 조금 욕심을 내기로 했습니다. 데모 사이트를 만들어야하니 클라우드 이용은 필수였고, Docker를 사용해 앱을 서비스해보기로 했습니다. 둘 다 Backend 팀원들에겐 처음 쓰는 것들이었죠. 도커는 다음 프로젝트를 위해 경험을 쌓는다는 생각으로 써보자고 밀어붙였습니다.
팀원간의 소통 및 디자인은 Figma를 쓰기로 했습니다. Figma에 회의 내용을 정리하고 디자인도 올려놓고, API나 스키마도 정리해서 올리자고 했습니다. Figma를 100% 활용하진 못했지만, 간단한 소통 및 회의용으로 충분히 알차게 썼습니다.
오늘 회의는 일찍 끝날겁니다!
구성을 최대한 간단하게 하고도 시간이 압도적으로 모자랐습니다. 이 적은 시간을 최대한 활용하기 위한 선택지는 2개였습니다.
-
개발 시간을 길게 가지고 회의를 적게 가진다.
개발 시간이 길어진 만큼 기능의 완성도는 높아지겠지만, 잘못 만들게되면 합치는 과정에서 시간이 모자를 수 있는 리스크를 지닌 방법이었습니다. -
회의를 자주하고 대신 개발 시간을 적게 가진다.
개발 시간을 짧게 가지니 완성도는 떨어집니다만, 개발할 때 방향성이 틀어지는 것을 막고, 발생하는 문제를 빠르게 캐치할 수 있는 장점을 지닌 방법입니다.
이 프로젝트에선 2번 방법으로 진행했습니다. 1번 방법으로 갔다가 자칫 잘못 구현하고 버리는 코드가 생기거나 돌아가지 않게 되어 프로젝트 자체가 펑 터져버리는 경우는 피하고 싶었습니다.
생기는 문제를 빠르게 캐치하고 방향성이 틀어지지 않으면서 유연하게 구성을 바꿔가기 위해서 2~3일에 한 번씩 회의를 했습니다. 이러한 전략은 좋았지만, 팀원을 갈아넣는 전략이기도 했습니다. 회의는 빠르게 끝내고 싶었지만 새벽 2시까지 진행되는 일이 허다했죠.
"오늘 회의는 이론상 일찍 끝나!" 라고 매 회의때 말했지만 지켜진 적은 없었습니다. ㅎ...
결국, 어느 정도 타협하게 됐다.
그래도 시간이 모자랐습니다. 결국 조금씩 타협하기로 했죠. 서비스의 핵심 기능을 제외하고 데모사이트라는 점을 감안해서 최대한 핵심 기능에 집중하고 자잘한 부분을 잘라내기로 했습니다. 디자인의 세세한 부분, 컴포넌트의 재사용성, 정돈된 코드, 일부 자잘한 기능들 등등... 난개발 된 부분도 눈 질끈감고 넘어가야했습니다. 프로젝트가 끝나고보니 역시 Front부분 완성도가 떨어지는 것 같아 아쉬웠습니다.
아차! 저작권
프로젝트 막바지에 예상치 못한 문제를 마딱드렸습니다. 프로젝트에 사용한 자료들에 저작권이 걸려있던 것입니다. 마지막에 아차! 싶었죠. 결국 대부분의 자료를 파기하고 자료를 직접 제작했습니다. 완성도를 더욱 떨어뜨리고 시간을 잡아먹는 요인이었습니다.
발표용 PPT 준비
발표용 PPT를 만드는 것도 속전속결로 하기위해 Canva를 이용했습니다. 미리 만들어진 템플릿을 가져다쓰고, 팀원들과 같은 화면을 보며 동시에 작업할 수 있고, 프레젠테이션 녹음도 되더라구요. Canva 사용 경험은 정말 좋았습니다. 특히 시간을 많이 절약할 수 있었던 것 같습니다.
결과는?
이번에도 광탈입니다. 하하.
하지만 떨어져서 아쉬운 것보다도 시간에 쫒겨 완성도를 높이지 못한 점이 너무 아쉬웠습니다. 분명 더 잘할 수 있었는데요. 이렇게 찝찝하게 프로젝트를 끝낸건 또 처음이네요.
팀원들이 말하는 좋았던 점
팀원들이 말하는 좋았던 점은 다음과 같았습니다.
안써본 기술,툴을 써봐서 좋았다.
팀원들은 GCP,Docker를 이번 프로젝트를 통해 처음으로 사용해봤습니다. 저도 완전한 서비스 런칭을 경험해보는걸 목표로 생각하고 GCP와 Docker 사용을 억지로 추진하긴 했습니다.
역할 분담이 잘 된것 같아 좋았다. 또 협업이 잘 이루어졌다.
확실히 팀원들도 한번 프로젝트를 같이 진행하면서 경험이 쌓였고 저도 경험이 쌓인 상태라 협업이나 역할분담에서 더 노련한 모습을 보일 수 있지 않았나 생각합니다.
공부했던 내용을 프로젝트에 적용해 볼 수 있어 좋았다.
이번에 AI를 공부하던 팀원이 프로젝트에 새로 들어왔는데, 제대로 된 데이터 셋도 구했고, 공부했던 내용을 적용해볼 수 있어 좋았다고 합니다.
좋았던 점을 종합하자면
처음써보는 것들 투성이였지만, 그래서 좋았다.
아이러니하게도 Backend를 맡은 팀원들은 GCP,Docker를 처음 써봤고, 개중에 서버 개발이 처음인 팀원도 있었죠. Frontend를 맡은 팀원은 React를 사용하는 팀원이었지만 이번기회에 Vue를 처음으로 써보게 됐습니다. AI를 맡은 팀원은 서비스 개발이 처음이었죠.
즉, 모두가 처음 써보는것들 투성이였고, 모두 짧은 시간동안 새로운 것들에 적응하기 위해 고군분투했습니다. 하지만 팀원들이 오히려 새로운 경험이 좋았다고 해서 너무 고마웠습니다. 힘든 경험이었을텐데 말이죠. 배워가는 점이 있었다니 다행입니다.
팀원들이 말하는 아쉬웠던 점
쿼리작성이 익숙하지 않았다.
이번에 학교에서 데이터베이스 수업을 들었고, 배운 내용을 적용해봤습니다만. 익숙하지 않아 완성도가 낮게 나온 것 같다고 아쉽다고 했습니다. 특히 View, Trigger 등을 적용 못해본게 아쉽다고 하더라구요.
서버가 처음이라 익숙하지 못해 아쉬웠다.
서버를 이번 프로젝트를 통해 처음 시작한 팀원이 있었는데, 기존에 Backend를 맡던 팀원이 가르쳐주며 서버 개발을 보조했습니다. 기여도가 높지 못해서 아쉬웠다고 합니다.
Backend를 몰라서 협업에 한계를 느꼈다.
AI를 맡은 팀원분이 말씀해준 내용입니다. 서비스 개발 경험이 없었기 때문에 서버가 어떻게 돌아가는지 몰라 협업에서 한계를 느꼈다고 하네요.
Github를 제대로 이용하지 못했다.
저도 공감하는 내용입니다. 브랜치를 나누고 브랜치 전략을 세워 개발했어야 하는데, main브랜치에 다 때려 박았죠 하하. 변명을 하자면 신경쓸 여유가 없었습니다. 팀장인 저도 코드작성에 열을 기울여야했거든요. 확실히 아쉬운 부분입니다.
주제 선정을 너무 어렵게 생각했다.
처음엔 이런 저런 서비스를 구상해보고 실제로 런칭된 서비스와 겹치지 않도록 하는데 집중했습니다. 하지만 프로젝트가 끝나고보니 다른 서비스와 겹치는 지는 크게 중요하지 않게 느꼈다고 하더군요. 사실 주제를 잘못잡았다고 생각하진 않습니다만, 겹친다는 이유로 아깝게 배제된 아이디어들이 있었던 것도 사실이었습니다.
저작권을 초기에 고려하지 못한점
프로젝트 마지막쯤에 예상치 못한 저작권 문제에 맞닥뜨려 준비한 자료를 내다 버리는 일이 있었죠. 다음에는 조심해야겠습니다.
아쉬웠던 점을 종합하자면
대체로 시간 부족과 프로젝트에서 드러났던 본인들의 미숙한 부분을 아쉽게 생각하는 것 같았습니다.
내가 좋았던 점
어쨌든 완성했다.
아쉬움이 많이 남는 프로젝트였음에도 2주동안 학교 수업을 들어가며 코드작성을 완료했다는 사실이 놀랍긴 했습니다. 그만큼 몸을 갈아 넣기는 했죠. 하지만 이런 경험도 언젠가 했을 거라는 생각이 들긴 합니다. 예방주사 맞았다고 생각하려구요.
노는 인원이 없었다.
당연히 노는 인원은 없어야겠지만, 이번 프로젝트는 팀원들을 100% 활용했다는 느낌이었습니다. 모두 처절하게 바빴습니다. 이 편이 한명의 노는 인원이 생기는 것보단 나은 것 같더라구요.
짧게 자주 회의를 가지는 전략
짧게 자주 회의를 가지는 전략은 성공적이었습니다. 절대적인 개발 시간은 좀 모자랐지만, 틀어지는 일 없이 다 같이 공통된 목표로 직진한 느낌이었습니다. 앞으로는 짧은 기간안에도 높은 완성도를 가져올 수 있도록 재활용 가능한 코드를 많이 만들어야겠다는 생각이 들었습니다. 서버나 컴포넌트는 재활용 가능하도록 미리 만들어 놓을 수 있으니까요.
다음에도 짧게 자주 회의를 가지되, 재활용 가능한 컴포넌트와 서버로 사람이 갈리는 일은 막아보려 합니다.
내가 아쉬웠던 점
github 활용
브랜치 전략을 새우지 못한 점이 많이 아쉽습니다. 프로젝트가 끝나고 히스토리를 보니까 만신창이더라구요. 팀장인 저도 개발에 집중해야했기에 Commit도, Merge도 마구잡이로 이루어졌습니다. 이 때문에 완성된 코드가 일부 소실되는 해프닝도 발생했는데, 이렇게 난개발하고도 그 정도로 그친게 다행일 정도였습니다. 다음엔 commit 규약을 만들고 브랜치 전략을 새우면 좋을 것 같다는 생각이 들었습니다.
프론트 완성도
완성도가 낮은 점은 어쩔 수 없었다 생각이 들면서도 미련이 남습니다. 이런 공모전에선 겉으로 보이는게 50%라고 생각하는데도 급조되어 낮은 완성도를 보이는 컴포넌트들을 그냥 사용했습니다. 좋았던 점에서도 언급했지만 재사용 가능한 컴포넌트를 미리 만들어 놓았다면 이렇게 고생하지 않았을텐데 라는 생각이 자꾸 들었습니다.
종합하자면
높은 난이도의 프로젝트였고 그만큼 많은 어려움에 부딛혔던 프로젝트였습니다.
아쉬움도 많이 남지만 앞으로의 개발인생에 좋은 반면교사가 되어줄거라 생각합니다.
