[협업회고,TIL] Node.js 4번째 팀 프로젝트 - 이커머스(쇼핑몰)

 

 

 

 

https://youtu.be/MWd31ouFq_8 

 

1. 프로젝트 소개

• 프로젝트명: 오레오오조 베이커리
• 프로젝트 기간 : 2023.02.01. ~ 2023.02.08.
• 간단 설명: 빵집에 들어서 빵들을 골라담아 구매하는 것 같은 간편함!
• OREO-OZO의 마음과 열정이 담긴 Bakery Shop에 놀러오세요.
• 핵심 기능
  1. 상품 구매
  2. 실시간 상담 채팅
  3. 관리자 백오피스 - 상품 관리 및 회원 관리, 주문 관리
• 개발 GitHub : https://github.com/KimHyungJip/oreo
• 시연 영상 : https://youtu.be/MWd31ouFq_8

2. 개발 인원 및 역할

• 장준호: 회원가입 및 로그인, 마이페이지 회원 관리, 실시간 채팅
• 이호승: 관리자페이지 - 상품 관리, 회원 관리, 총 주문 목록 조회
• 김희서: 관리자페이지 - 상품 관리, 회원 관리, 총 주문 목록 조회
• 김재광: 검색 기능, 프론트엔드(메인 및 상품카드, header, footer) 구현 및 조정
• 김형집: 장바구니 - 상품 주문, 웹소켓 처리

3. 사용 기술

 

4. 초안과 와이어 프레임

 

5. 프로젝트 화면 구현(영상 참고)

메인 페이지

장바구니 페이지

주문 내역 페이지

관리자 메인 페이지

회원 관리 페이지

상품 관리 페이지

주문 / 판매 내역 조회 페이지

6. ERD

• 처음에 수정에 수정을 거듭하며 최대한 DB 설계를 완성하여 프로젝트에 들어갔다. 개발을 진행하며 미처 생각지 못한 attribute들이 필요하게 되어서 user테이블의 salt 항목처럼 도중에 추가한 것도 있지만, 대체로 기존의 스키마를 기준으로 크게 중요하지 않은 사항들은 추가하지 않음으로써 핵심 기능에 집중해 개발할 수 있었다.
• 처음부터 모두의 동의하에 DB 모델을 만들어 놓으니, 이후로는 모두가 같은 재료(테이블명과 필드명)를 사용해 예측 가능한 요리를 내놓을 것이라는 믿음이 있어 수월히 개발할 수 있었다. 팀원들간에 의논 사항을 내놓을 때나 도움을 주고 받을 때 특히 도움되었고 좋았다.

7. API 명세

https://www.notion.so/fa88d4e0c0824d00bbfbca09ed59e94a?v=8add84a848c544a1aa22e1f439c94c80 

오레오오조 베이커리 API

• S.A. 피드백에서 PATCH가 아닌 PUT 메소드를 사용하는 이유를 지적받아서, PUT과 PATCH의 차이점에 대해 알아보았다 :
  • PUT 메소드의 경우 프론트로부터 해당 엔티티의 자원 전체를 제공받는다.
  • 그 후 DB에 타겟 데이터가 있다면 그 전체를 ‘덮어씌우고’ 200(ok) 상태코드를 반환하고, 타겟 데이터가 존재하지 않는 상태라면 새로이 데이터를 만들고 201(created)를 반환해 알려주는 로직을 따른다.
  • PATCH 메소드의 경우는 프론트가 해당 엔티티의 어트리뷰트 전체를 제공할 필요가 없다.
  • 타겟 데이터를 ‘부분 업데이트’ 하고 성공 코드 200(ok)를 반환하든지, 찾지 못하고 에러 코드를 반환하든지의 로직을 따른다.
  ⇒ ‘부분 수정’을 목표로 하는 현재의 수정 API들은 PUT이 아니라 PATCH 요청을 보내는 것이 맞겠다는 결론이 나왔다. 이번 개발 중에 적용하지는 못했지만 다음 프로젝트부터는 잘 고려해서 사용할 수 있을 것 같다.
•  

7. 잘한 점

• API 명세대로 코드 구성을 잘하였다.
• 각자 파트를 끝낸 뒤 도움이 필요한 팀원에게 적절하게 도움을 주면서 서로 도와가며 프로젝트를 하였다.
• 팀원들과 꾸준하고 많은 소통을 통해 개발 과정에서 서로의 의견을 조율하였다.
• 매일 2번 서로의 진행 상황을 알 수 있어서 좋았다.

8. 해결한 내용

• 회원 비밀번호 암호화 후 저장 구현함.
• multer와 AWS S3를 이용해 상품 이미지를 클라우드에 저장함.
• 관리자 여부 확인하기
• : admin 이라는 미들웨어를 만들어 도입하고, API url에 ‘/admin’을 추가하여서 관리자 확인이 필요한 엔드포인트라는 것을 명시한 것. 나름대로 스스로 생각하고 긴가민가하며 시도해본 것인데 생각보다 잘 작동하고 코드도 self describing하게 명시적으로 작성된 것 같아 뿌듯했다.

middlwares/admin.js

admin.js 미들웨어 활용 예시) routes/product_routes.js

관리자가 아닌 상태에서 억지로 접근해 본 상품 등록 API

9. 아쉬웠던 점, 해결하지 못한 부분

• 프로젝트 진행을 할 때 생각보다 오래 걸리는 부분도 있고 자잘한 에러 부분도 있어서 통합테스트는 구현하지 못했는데 그 부분이 아쉽다.
• 페이지네이션을 적용해야 하는 페이지에는 Restful API를 사용하지 못했던 점
• : 만들어 놓은 API 엔드포인트를 활용하지 못하고 Service 계층의 메소드를 인터셉트해와 res.render로 뿌려주는 방식을 취했다. 동적으로 렌더링하는 방식(프론트에서 API를 호출하는 방식)도 여러가지로 고민해보았으나 완성하지 못한 것이 아쉬웠다. Sequalize의 COUNT를 비롯해 association을 이용한 기능들이 있다는 힌트를 얻어서, 다음엔 이것을 활용해 구현해볼 수 있을 것 같다.
• AccessToken 뿐만 아니라 RefreshToken도 발급되도록 만들었으나 결국 AccessToken밖에 실제 로그인에 활용하지 못한 점
• ⇒ RefreshToken을 어디에 저장해야 할지 열띠게 토론도 하고 조사도 해보았지만 결론을 내지 못한 점이 아쉽다.

KPT

Keep

• 작업 상황 서로 체크하기
• 매일 시간 정해서 회의하기
• 문제 발생 시 도움 요청하기

Problem

• 프로젝트 진행 속도가 조금 늦어서 욕심내서 더 구현해볼 부분들을 못했다.
• 기능 구현 이후, 마감 기한 내에 테스트 코드 구현하지 못하여 아쉬움
• 역할 중복 발생! 역할 분담에 대한 고민이 적지 않았나? ( 역할 분담 예시 : 테이블 기준으로 유저 파트 / 관리자 파트 / 상품 파트 … )
• 각자 작성한 코드에 대해 공유 속도가 느린 케이스도 있었음. 팀원 간 작성된 코드에 대해 더 빨리 공유가 될 수 있지 않았을까?
• 프로젝트 투입 전 공부가 충분히 안 된 부분도 있지 않았나.
• 폴더 구조에 대해 잘 정리가 되지 않았던 듯. 파일이 늘어날 수록 복잡해짐. vs code 파일 및 폴더 정렬이 abc 순이라서 복잡했음.
• 그 이외, API, ERD… 등 정리.

Try

• 초심 잃지 않기 위해 매일 리마인드 하기.
• 기능 구현에 속도 빨라지기, 테스트 코드 구현에 익숙해지기
• 역할 분담을 잘 해보기, 담당 역할마다 3계층 기능 구현해보기.
• 작성한 코드 혹은 API 구성에 대해 변경 사항이 있는 경우 팀원 간 빠른 시간 내 공유하기(깃허브)
• 프로젝트 투입 전 공부가 잘 진행될 수 있도록, 학습에 어려움 있는 경우 먼저 파악하며 해결해보기.
• 폴더 구조 정리 : 컨트롤러-서비스-레포지토리만의 상위 폴더 하나 만들어서 좀 더 정리가 가능할듯.

Feel 느낀점

• 소통이 원활히 잘되니 회의하면서 결정하는 것도 잘 되었고 프로젝트 진행에도 긍정적인 영향을 주었던 것 같아서 소통이 정말 중요하다는 것을 느꼈다.
• 완성을 못 시킨 상태로, 프로젝트 끝난 적이 있었는데, 이번이 기회라고 생각했다. 협업이 잘 되어서 만족스럽다.
• 부족한 점이 있지만 다들 잘 해주셔서 감사합니다.
• 역할 분담이 잘 된 것 같아 고마웠다. 시간 및 에너지를 투입해서 기능으로 구현이 되는 게 당연한데, 이게 이번에 팀 협업이 잘 되어서 좋았다.

Github Repository

https://github.com/KimHyungJip/oreo.git

GitHub - KimHyungJip/oreo

 

 

팀원 블로그

장준호:

이호승: https://velog.io/@juwalove7

김재광: https://veams.tistory.com/

김형집: atathj (형집) - velog

김희서: https://dev-ocean.tistory.com

 

 

 

이번 팀 협업에 대한 개인 회고

1) 초기에 마이페이지의 회원정보 조회 및 수정, 주문내역 조회를 담당했는데, 이대로는 시간 내 프로젝트 마무리를 제대로 못할 것 같아서, 다른 팀원 분 두 분이 나누어 담당을 도와주셨다.

- 나는 이번 프로젝트에서 ejs를 활용을 제안하였다. 하지만 서버에서 화면단으로 변수를 불러오는 것을 구현해보려 했는데, 잘 되질 않았다. 실력이 좋은 어떤 팀원은 ajax를 활용해서 함수를 만들고, 나 대신 회원개인정보 조회 기능을 금새 구현하셨다. 자신이 가장 자신있는 방법을 선택하신 것 같았다. 방식은 달랐지만 개발 속도가 매우 빠른 것을 보고 신기했다.  

 

2) 이 때문에 나의 역할이 붕 떠버린 상황이 됐다. 이때 나는 프론트엔드 부분을 먼저 진행하기로 하였고, ejs를 활용하여 메인 페이지의 뼈대를 만들었고, 팀원들에게 공유하였다. 특히 이번엔 express-ejs-layouts 라이브러리를 활용했는데, 그동안 팀 협업에 참여하면서 웹페이지마다 header와 footer의 동일한 코드가 반복적으로 들어가는 것을 보고 비효율적이지 않은가 의문이 들었기 때문이었다. header와 body, footer를 따로 분리하여 각 부분만 유지보수 할 수 있게 구축하였고, 팀원 각자가 구현한 기능이 우리 웹페이지에 통합되어 개발이 진철이 될 수 있도록 기여한 것 같다. 결과적으로도 팀원은 물론이고 튜터님께도 코드 리뷰를 받으며 인정을 받아 뿌듯했다.

 

3) 그동안의 프로젝트를 참여하면서 CSS를 거의 다루어보질 않았는데, 이번에 많이 학습하는 경험을 가졌다.

- 여러가지 작업중 상품 카드 상품명, 가격과 상품 이미지의 위치가 정렬이 되지 않고 각자 따로 놀고 있는 상황이었는데, 사진 크기와 상품 카드 내부 위치를 조정을 하는 작업이 기억에 남는다. 더불어 브랜드로고 디자인하는 것도 재미있었다.

 

4) 백엔드 개발자가 되려한 상황에서, 팀 프로젝트 마감이 다가오는데도 백엔드 작업에는 기여하지 못한 것에 스스로 괴로움이 있었다. 아쉬움이 생겨서, 프로젝트 마감 전날 밤, 나는 팀원들에게 검색 기능을 추가하기로 선언하였다. 쪽잠을 자고 공부를 해서, 마감 직전에 검색 기능의 구현을 나름대로 완료할 수 있어서 뿌듯했다. 

 

- 프로젝트 시작 전 라우츠-컨트롤러-서비스-레포지토리로 이어지는 레이어드 아키텍쳐를 충분히 이해 못한 상태로 참여했다. 처음 맡았던 역할을 제대로 하지 못했지만, 어쨋든 초반에 맡았던 기능을 구현하려고 머리 싸매며 투입된 시간과 에너지가 있다보니, 프로젝트 막바지에는 이 개념 및 활용법을 이해하게 되었다. 그래서 막바지에라도 검색 기능을 시간 안에 구현할 수 있었던 것 같다.

 

5) 물론 우리팀이 목표와 달리 구현하지 못한 기능도 있다. 대략 구현은 했지만 디테일이 부족한 기능과 코드도 있었다. 눈에 잘 들어오지 않는 코드, 실시간 채팅기능, 테스트 코드 작성 등.... 하지만 소통능력이 좋은 좋은 팀원들을 만나 협업과정이 즐거웠고, 결과물도 낼 수 있어서 지금까지의 4개 미니 프로젝트 중에서 가장 만족스러운 협업 경험이 되었다.

- 일단 결과물의 완성도가 있다. 도중에 프로젝트 완성을 위하여 서로 자기 역할 찾는 것에 적극적이었고, 팀원 간 실력도 배분도 잘 된 것 같다.

- 그동안의 학습 경험이 쌓인 덕분에, 깃과 깃허브도 이번엔 다들 기본 이상은 활용할 수 있어서, main-develop브랜치-feature브랜치 패턴대로 초반부터 깃허브에 기반하여 협업을 할 수 있었다.

- 팀장님의 활동이 인상적이었다. 개발 분야와는 거리가 많이 멀었던 그의 이력은 독특했는데, 다른 사람들과 함께 어울리면서 팀 목표가 잘 수행될 수 있도록 돕는 역량을 쌓아온듯 했다. 협업 기간에 작업 진행사항을 꼼꼼하게 체크하면서, 팀원들 간의 능력을 파악하며 시간과 에너지가 적재적소에 분배될 수 있도록 수시로 조정하곤 했다. 이렇게 관리 및 통제를 중시하다보면 상대의 마음을 다치게 하기 쉬울 수 있는데, 상대에 관심을 가지며 배려하는 말투를 쓰는 등 그의 모습이 인상적이었다.

 

6) 실력이 좋은 팀원은 왜 실력이 좋은가 지켜보는 기간이기도 했다. 그들에게 일상에서 어떻게 공부하고 있는지 이것저것 물어보기도 했다. 실력이 좋은 팀원들의 공통점이 있었다. 그들은 자기가 경험한 기술적인 어려움을 해결할 때까지 손에서 끈질기게 놓질 않았다. 꾸준한 것은 물론이다. 주어진 시간에 몰입할 뿐만 아니라, 어떤 때는 약간 자학적으로 보일정도로...보통 휴식시간이나 잠을 줄여서라도 그 문제 정체를 알기 위해 고민하고, 해결하려고 한다. 끝까지 말이다. 이런 시간이 누적되니까 부트캠프 기간 중간에는 다른 동료들과 실력이 차이가 뚜렷하게 나타난다. 실력이 생기니까, 동료들이 그들을 찾는다. 다른 팀원들의 문제도 더 자주 도우면서 성장한다. 그러면서 더 자기 역할에 대한 역량을 기른다. 누군가에게는 사전의 개발 경험, 전공자, 비전공자 이런 배경은 어느 순간 별로 의미가 없어지는 구분이 되는 것 같다.