Naweke 소개
- 프로젝트 사이트 : Nike
- 고객의 라이프스타일에 맞는 UX 중심의 편집숍
- 운동을 좋아하는 사람들을 위한 의류/용품 판매
개발 기간
2022.11.14 ~ 2022.11.25
적용 기술
js, node.js, express, mysql, amazon ec2, amazon rds, linux, git
협업 툴
notion, slack, trello
프로젝트 선정 이유
짧은 기간 안에 기획부터 개발, 배포까지 진행해야 했기에 팀원 모두가 잘 알고 있는 사이트 중 웹사이트의 기본적인 기능에 더해 시간이 남을 경우 추가적으로 구현해 볼 여러 기능이 있어 선정하게 되었다.
깃허브 주소 / 데모 영상
주소 : https://github.com/applleeee/39-1st-naweke-backend
영상:
https://drive.google.com/file/d/1o3aAmo0GASWMJtAZsgmTNhARpc6Af1Y9/view?usp=share_link
팀원 소개
front
박지영
Main 레이아웃/기능, Review 레이아웃/기능, Products list 필터링(쿼리스트링), Signup 레이아웃/기능, LogIn 레이아웃/기능, Footer 레이아웃
홍석현
Main 레이아웃, Nav 레이아웃/기능, Products list 레이아웃/기능,
Products search 기능, Main 기능
김호준
Cart 레이아웃/기능
조형진
Product detail 레이아웃/기능
back
김한솔
DB Modeling, Reviews API(POST/GET/PATCH/DELETE), Products List API(GET), Likes(POST/DELETE)
이명석
DB Modeling, Auth API (POST), Products order API (POST/GET),
Product detail information API (GET)
지송현
DB Modeling, Carts API (POST/GET/PATCH/DELETE)
DB 모델링
느낀 점
잘한 점
개인적으로
- api 개발을 시간에 맞게 마무리했다.
- 완성되었다고 생각해 프런트와 테스트 해 보았을 때 특별한 에러 없이 잘 구동되었다.
- 무언가 결정되지 않은 것, 개발 전에 선행되어야 하는 여러가지를 팀원들과 부담없이 이야기 할 수 있었다.
팀적으로
- 기획 단계에서 다른 팀에 비해 오래 이야기를 나눴다. 덕분에 디테일한 부분까지 미리 결정할 수 있었다. 다만 충분한 시간이 있다면 앞의 방법이 좋겠지만 부족한 개발 기간 안에서 처음부터 디테일한 결정을 하는 것과 빠르게 개발을 시작하고 만들면서 디테일한 부분을 정하는 것 중에 어느 것이 효율적일 지는 여전히 고민이다.
- 초기 기획을 디테일하게 결정했기 때문에 db 모델링 역시 그에 맞게 디테일하게 작성할 수 있었고 이후 마무리까지 한두번의 테이블 수정으로 끝낼 수 있었다.
- 서로 막히는 부분이나 모르는 부분에 대해 편하게 이야기 할 수 있었고 역할의 구분 없이 해야하는 일을 완수하기 위해 노력했던 점이 좋았다.
아쉬운 점
개인적으로
- 초기 기획, db 모델링, 데이터 생성 등의 작업을 먼저 한 뒤에 api 개발에 들어갔다. 3가지 일이 모두 끝났을 때 총 11일의 작업 기간 중 4일 정도가 지났었다. 개발 이후 배포와 발표 준비까지 포함된 기간인 것을 고려하면 아주 촉박한 시간이다. 사실 개발 시작 시점이 늦어진 것에 대해서는 이외에도 여러 이유가 있겠지만 개인적으로 더 다양한 기능을 구현해보지 못한 점이 아쉽다.
- 개발 시작이 늦어진 이유를 좀 더 이야기해보자면 개인적으로 전체 일의 흐름이 명확히 머리 속에 그려지지 않았다. 예를 들어 서버가 발급해 준 로그인 토큰이 이후 유저의 행동에 따라 어떤 식으로 움직이는 지 정확히 그려지지 않았다. 또한 내가 개발 혹은 테스트 하기 위해 필요한 것들이 있었는데 예를 들어 상품 상세 페이지에서 상품을 장바구니에 담을 때 프런트에서 어떤 요청을 보내는지, 내가 필요한 정보를 받을 수 있는지, 또 프런트에서 필요한 정보는 무엇인지 처음부터 정확히 알기가 힘들었다. 지금 생각해 봤을 때, db 모델을 정확히 이해하고 각 기능마다 데이터의 흐름을 정확히 파악했다면 어떤 데이터를 주고받을까 고민하는 시간을 줄이고 빠르게 개발에 들어갈 수 있었을지 않았을까 하는 생각이 든다.
팀적으로
- db 모델링이 어려웠다. 아무래도 팀원 모두 거의 해본 적 없는 작업이었고 아무리 평소에 많이 사용한 서비스여도 그때마다 필요한, 보내줘야할 데이터가 무엇인지 api를 직접 만들어보기 전에 결정하는 것은 어려운 일이었다. 특히 상품에 여러 옵션이 있는 경우 어떻게 테이블을 짜야할지 막막했는데 멘토님의 리뷰 이후 방향을 잡을 수 있게 되었다. 예를 들어 같은 상품이어도 사이즈, 색 등이 다르면 다른 상품으로 인식해 고유한 아이디 값을 주는 것 등이 그랬다.
- 초기 기획 시 사용자를 고려하지 않았던 부분이 있었다. 사용자 경험보다 기술적으로 구현이 가능한가, 학습에 얼마나 도움이 되는가를 생각했기 때문에 발생한 문제였다.
- 백엔드 쪽에서 api 명세서를 늦게 작성했다. 다같이 그 부분을 놓치고 있었고 1주차가 지나고 나서야 그 사실을 인지해 급하게 만들어 프런트와 공유했다. 좀 더 일찍 문서를 작성해 공유했다면 불필요한 반복적인 질문을 피하고 각자 빠르게 개발에 집중할 수 있었을 것이다.
총평
개인 프로젝트와의 차이를 확실하게 느꼈다. 개인 프로젝트에서 혼자 순서에 맞게 일렬로 개발하는 것과 팀 프로젝트에서 여러 기능을 동시에 개발하는 것, 당연히 팀 개발의 속도가 빨라야 하지만 동시에 완성도 있게 만들기 위해선 꽤 많은 것들을 신경써야 한다는 것을 느꼈다.
이번 프로젝트에서 아쉬운 점이 많지만 사실 모두가 첫 팀 프로젝트였다는 점을 고려하면 당연히 겪는 문제일 수도 있다는 생각이 든다. 어떤 기능을 개발할 때 어떤 데이터 구조가 적합한지, 전체 개발 진행에 순서가 어떻게 되는지 등 한 번도 해보지 않고서는 알기 힘든 것들이기 때문이다.
잘한 점은 유지하고 아쉬웠던 점은 보완해서 다음 2차 프로젝트 시작해야겠다.
