이번에 진행한 프로젝트 묘미(MyoMi) 는 샐러드/도시락/밀키트 주 단위 정기배송 서비스이다. 따로 따로 주문하며 배송비도, 적립금도, 회원 혜택도 놓쳐왔던 (나 자신을 포함한)알뜰한 현대인들의 지갑을 챙겨줄 식품 정기배송 플랫폼에 대한 목마름으로 기획/제작하게 되었다.
어떤 서비스를 만들어야 할까? 사실 이 세상에 없는 서비스를 창조하고 싶은 마음이야 있었지만, 비전공자 5명이 한달동안 해낼 수 있는 현실적인 프로젝트를 하기로했다. 도메인을 생각하다보니 자연스럽게 현재 우리 팀원들에게 가장 맞닿아 있는 것이 무엇인가 고민하는 거였다.
팀원끼리 수다처럼 얘기하는걸 들어보면, 교육장 근처에서 점심을 사먹는데, 물가가 많이 올라서 매일 만원가까이 되는 돈을 쓰는것이 부담된다는 말이 가장 많았다. 그래서 도시락을 싸다니기로 했는데 프로젝트가 시작하고나서 늦은 퇴근이 잦아지다보니 집에가서 매일 점심/저녁 도시락을 챙기기도 힘들다는 것이었다.
그렇다면, 우리가 원하고 필요한 서비스를 만들어볼까? 라는 생각에 프로젝트 묘미는 시작되었다.
이번 프로젝트는 개인적으로 현실적이면서도 규모가 조금은 큰 프로젝트를 만들고 싶은 욕심이 있었다. 왜냐하면 팀원으로 참여했던 첫 프로젝트는 단순 게시판, 댓글, 쪽지, 프로필 정도의 기능만 있었기에 아쉬움이 크게 남았기 때문이다.
기존에 우리가 참고했던 플랫폼은, 아래와 같은 사이트 들이다.
1. 포켓 도시락(Pocket Dosirak)
2. 그리팅(Greating) 밀키트 배송 서비스이다. 영국에 있을 때 Hello Fresh 라는 서비스를 이용해본 적 있는데, 밀키트의 매력에 빠져서 우리 서비스에도 밀키트를 넣기로했다. 한국에서는 어떤식으로 판매하는지 궁금해서 살펴봤다.
3. 포켓 샐러드(Pocket Salad) 우리 프로젝트에서 가장 많이 참고한 사이트이다. 실제로 구매를 해보고 정기배송 서비스에서 수령일 선택, 판매자에게 문의가 필요한 부분에 대해서 참고했고, 사실 프론트쪽에 자신있는 분이 없어서 똑같이 따라만들기라도 제대로 해보자! 해서 디자인도 가장 많이 참고했다.
간단하게 팀 규칙 먼저 정하고, 이벤트 스토밍을 진행했다.
이벤트 스토밍을 통해 팀원분들이 이 프로젝트에서 우리가 제공하고 싶은 서비스나 도메인을 한눈에 파악하고 서비스 로직이나, 시나리오를 한눈에 파악하기를 바랐다.
또한 같은 기능이라도 서로 생각하는 로직이 다른것을 조금은 방지하기 위해, 기능적 align을 맞추기 위해 진행하게 되었다.
이번 프로젝트에서 노션을 적극 활용했다. 활용한 부분은 아래와 같다.
주 단위 스프린트 설정: 주 별로 집중해서 개발해야할 기능, 업무 등을 나누고 피드백
어제 진행한 부분 / 오늘 진행할 부분 / 기능 구현시 만났던 오류 공유
같은 오류를 여러명이 겪었을 때 빠른 디버깅 가능
기능구현시 필요한 자료, 참고한 자료 공유
Trigger, Procedure, Scheduler 등 공통으로 필요한 코드 및 자료 공유
양방향 연관관계로 맺어진 기능이 많다보니 세부기능 구현 중 겹치는 부분이 생겼는데, 각자 맡은 기능에 대해 세부적으로 정의 해놓지를 않아서 같은 기능을 두사람이 구현하고 나중에 발견하게 되었다.
무서운 시간 낭비!
누가 어떤 기능을 맡았고, 남은 기능이 무엇인지 파악할 수 있었다. 또한 겹치는 기능은 누가 어떤식으로 구현할지 보고 정할 수 있었고, 다른 사람의 기능중 어떤 부분이 추가적으로 진행되어야 할지 토론/토의해서 결정할 수 있었다.
이벤트 스토밍을 꽤나 꼼꼼하게 했음에도 불구하고 ERD를 정말 여러번 수정했다.
먼저, 크게는 복합키의 존재를 몰랐을 때 모든 테이블에 각각 고유값을 따로 주는 방식으로 했는데 그로인해 의미없는 Sequence의 무의미한 생성이 반복되었다.
우리는 처음엔 배포까지가 목적이었기 때문에 퍼포먼스를 생각하면 컬럼을 줄이고, 정규화가 필수였기 때문에 정보도 찾고 자문을 구하다가 복합키의 존재를 알고 나서 테이블이 조금 더 정리가 되었다.
테이블에 대한 관점. 처음에는 어떤 하나의 entity에 대한 모든 정보를 하나의 테이블이 가지고 있다고 생각했다.
예를들어, 주문 테이블이 있다면 그 주문 테이블에 주문 정보 뿐만 아니라 배송지 정보나 주문 상세 정보까지 다 담아줬었다.
정규화의 필요성을 알고나서는 주문을 총 3개의 테이블로 찢어버렸다!
이렇게 나눠주니 기능 구현을 할 때 필요한 정보만 DB에서 Select 해 올 수 있어서 퍼포먼스가 향상되었다.
즉, Entity 도메인이 하나더라도 그에 대한 모든 정보를 하나의 테이블이 가지고 있을 필요는 없다!
트러블 슈팅 내용은 포트폴리오에 따로 정리할 것
팀장으로서와, 동시에 팀원으로서 후기를 남겨보고자 한다.
딱히 앞장서거나 나서서 뭔가를 하는 성격은 아니지만, 이번 프로젝트에 욕심이 있었어서 그런지 의견이나 아이디어를 많이 냈고 필요시 설득도 열심히 했던것 같다. 그 결과이려나? 팀장을 맡아주시면 안되겠냐는 팀원분들의 말에 팀의 '장'이라는게 무섭고 무거워서 '그렇다면 PM이라는 이름의 팀장을 하겠습니다.'라고 대답해버렸다.
우선 스스로 자문을 했던 것은, 내가 누군가를 이끌고 도울 수 있는 역량을 가지고 있는가? 였다. 나도 배우는 입장이기 때문에 모르는 것을 만났을 때 잘못된 방향으로 이끌면 어떡하지? 하며 팀장으로서의 내 모습을 계속 의심하게 되었다.
그리고 내린 결론은, 처음에는 '가장 잘하는 사람이 팀장이 되어야하는게 아닌가? 난 아닌데..!' 라는 생각이 강했지만, 하다보니 가장 잘하는 사람이 가장 좋은 퍼포먼스를 낼 수 있도록 분위기를 만들고, 주춤하는 사람들이 있다면 백업하고 서포트하는게 팀장의 역할이구나 싶었다.
내가 가장 잘하는 사람이 아님을 인정하는 것. 내게 가장 필요한 태도이자, 가장 잘한 것이라고 생각한다. 팀원분들이 질문을 해주셨을 때 나도 모르는 거라면 같이 공부하고 구현하고, 해보고 되는 것을 나누고 더 좋은 방법은 있나 함께 찾아보기를 반복하면서 큰 성장을 할 수 있었으니까.
그래도 아쉬움이 남는다면, 팀원들이 가지고 있는 개개인의 역량 중 장점을 잘 파악하여 업무를 나누고 싶었는데, 그 과정이 정말 어려웠다는 점. 만약 다시 프로젝트를 할 수 있다면 저 스스로의 장점과 팀원들의 능력치, 역량을 잘 파악하며 일을 배분하지 않았을까 생각한다.
일단 첫번째 부트캠프에서 짐만 되어가는 나 자신에 실망하고 스스로의 Hater가 되어서 절망적이었던거에 비하면, 정말 많이 성장했구나 싶었다. 프로젝트 시작할 때 부터 끝날 때 까지 질질 끌려갔던 과거의 나에서 프로젝트 시작전에 내가 맡을 부분을 미리 생각해보면서 자료를 찾으며 미리 준비를 했다.
기능 구현에 어려움이 있는 팀원분의 백업으로도 열심히 참여했는데, 첫번째 부트캠프에서 나를 도와줬던 많은 팀원들이 생각났다. 도와주면서도 배우고, 도와줄 수 있음에 기뻤다. 내가 성장했다는 증거 같아서!
첫 프로젝트에서 1인분이라도 제대로 하는 팀원이 되자!가 목표였는데, 어느새 1인분 이상을 해내는 팀원이 된 나를 발견할 수 있었던 프로젝트였다.
성언PM님 넘 멋져요!!
종종 깃허브로 눈팅만 조금씩했었는데, 완성도 높은 프로젝트를 마무리하셨네요
수고많으셨습니다!글 읽으면서 정성과 열정이 느껴져서 저도 동기부여가 됩니다!!