1차 프로젝트 회고록 & 위코드 5주차

1. About team Seoulminer - mining codes

• 개발기간: 2023.06.23 ~ 2023.07.07
• 깃헙 링크 : FrontEnd, BackEnd

Clone Coding project - 배민문방구

• 웹 개발의 첫 걸음을 뗀 seoulminers는 사람들이 가장 일상적으로 영위하는 행동 중 하나인 상거래를 웹페이지로 구현해 보기로 했다.
• 그러던 중 우리의 눈에 발견된 우아한형제들의 우아한 브랜드, 배민문방구
• 우리에게 주어진 시간은 단 2주. 2번만의 스프린트 안에 최대한 클론 할 수 있는 범위 내에서 우당탕탕 이나마 굴러가는 프로덕트를 만들어 내야 한다.

우리가 구현해야 할 행위 - 전자상거래

인터넷이 우리 생활에 보급된 이래, 사람들이 현실세계에서 영위하는 행동들 중 많은 수가 온라인의 세계로 이식되었다. 특히 상거래는 유사 이래 가장 많이 수행된 사람과 사람 사이의 상호작용일 것이다. 인류의 근간을 이루는 상거래 행위부터 차근차근 구현해 보기로 했다.

PEFT 분석

Product: 우리의 프로덕트가 커버하는 제품과 서비스는 어떤 종류의 것일까? 

1. eCommerce를 영위: 네트워크 상에서 이루어지는 제품의 거래
   1. 실제로 제품을 보고 구매의사결정을 내리는 것이 아닌, 웹페이지에 게시된 정보를 바탕으로 구매의사결정을 내리게 됨. 따라서 제공 가능한 선에서 상품에 대한 상세 정보를 제공할 수 있어야 함.
   2. 구매의사 결정 및 지불이 끝났다고 해서 바로 상품을 수령할 수 있지 않으므로, 상품인도 시 필요한 정보가 잘 관리되어야 함.
2. 취급품목: 재미있는 소품
   1. 특이하고 기성품이 아닌 이벤트성 상품을 판매함.
   2. 가격대도 부담없이 구매할 수 있는 수준.

End-user: 우리의 프로덕트는 어떤 사람이 사용하게 될까? 

1. 재미있는 소품을 사용할 만한 사람들
   1. 이 사람들은 특이한 물건을 사용하는 것을 / 특이한 선물을 하는 것을 좋아한다.

Feature: 우리의 프로덕트는 어떤 기능을 가지고 있어야할까?

eCommerce를 운영하기 위해서는, 최소한 아래의 기능을 가지고 있어야 한다고 판단된다.

1. SignUp: 엔드유저를 인지하는 회원가입 기능.
   1. 어떤 사람이 어떤 품목을 얼마만큼 구매했는지를 알 수 있어야 한다. 이를 위해서는 해당하는 엔드유저를 특정할 수 있어야 하며, 회원가입을 통해 웹페이지 내의 활동에 대해 엔드유저를 특정할 수 있다.
   2. 아울러 특정 엔드유저의 주소지 등에 대한 정보도 관리해야 구매건에 대해 배송등의 사후처리도 수행할 수 있다.
   3. 따라서 회원가입 기능 및 엔드유저 정보 관리 기능은 이커머스에 있어 근간이 되는 기능이다.
2. SignIn: 엔드유저의 구매행위를 지원하고 분석하는 로그인 기능.
   1. 로그인 기능을 통해, 어떤 엔드유저가 웹페이지 상에서 어떤 행동을 취했는지 파악할 수 있다.
   2. 특히 eCommerce는 거래가 메인이 되는 만큼, 거래의 주체를 정확히 특정하고 파악할 수 있어야 한다. 이를 위해서는 로그인 기능은 필수다.
3. ProductView: 엔드유저에게 상품의 정보를 제공하는 상품조회 기능.
   1. 상품을 팔기 위해서는, 구매자가 해당 상품에 대한 정보를 제공받을 수 있어야 한다.
   2. 상품의 물리적 실체를 관찰하고 구매의사를 내릴 수 있는 것이 아니다 보니, 매체 안에서 제공할 수 있는 한도 안에서 최대한 상세한 정보를 전달해야 한다.
   3. 상품의 리스트도 볼 수 있어야 하고, 개별상품에 대한 접근도 가능해야 한다.
4. Cart: 엔드유저가 구매의사가 있는 상품의 데이터를 저장하는 장바구니 기능.
   1. 엔드유저의 구매 편의성을 위해, 장바구니 기능을 제공해야 한다.
   2. 엔드유저는 로그인한 상태에서 본인이 구매하고자 하는 상품들을 담아두었다가 한번에 구매를 할 수 있어야 한다.
5. Order: 엔드유저의 구매이력을 확인, 확정하는 주문서 기능.
   1. 엔드유저가 구매한 상품에 대해, 판매자도 그 내역을 확인해야 상품의 배송 등의 사후절차를 진행할 수 있다.
   2. 아울러 관계법령 상 거래에 대한 정보는 일정 기간 보관되어야 한다.

Tech: front end 가 사용할 기술스택

• 기술스택 (Front End) : 자바스크립트, 리액트, SCSS

 

• 협업툴      

 

ERD 구성

데이터의 모양을 파악하기 위해 초기 작업을 front와 back이 함께 작업을 했다.

---

2. Project 시연 영상

 

---

3. 내가 맡은 역할

개발

1. SignUp
   • 첫번째 페이지
     1. 레이아웃
     2. 약관동의 - 전체 동의 및 부분 동의
     3. 필수 체크 박스 누르면 버튼 활성화
     4. 백엔드에게 유저 정보 POST
   • 두번째 페이지
     1. 레이아웃
     2. 정규표현식에 따라 유저정보 입력할 수 있으며 조건에 맞으면 버튼 활성화
     3. 회원가입 성공 시 축하 모달 띄워주고 3초 뒤에 자동으로 main 페이지로 이동
     4. 백엔드에게 유저 정보 POST
2. SignIn
   • 레이아웃
   • 입력창에 입력하면 버튼 활성화
   • 백엔드에게 유저 정보 POST
3. main page
   • nav
     1. 토큰 유무에 따른 로그인/ 로그아웃 버튼 변화
     2. nav toggle에서 토큰 유무에 따른 로그인/ 로그아웃 UI 변화
     3. 비로그인 시 장바구니 버튼 클릭 시 로그인 페이지로 이동
     4. 쿼리스트링 이용해 카테고리 버튼 클릭 시 상품리스트페이지에 그에 맞는 정보 보여줌 GET
   • main
     1. 백엔드에게 정보 받아옴 GET
     2. hover 시 이미지 및 글자 색 바뀌도록 구현
   • 상품 리스트 page
     1. 쿼리스트링을 이용해 백엔드에게 카테고리에 맞는 정보 받아옴 GET
     2. 카테고리 ID에 따라 카테고리 제목 바뀌는 UI 구현
     3. hover 시 이미지 및 글자 색 바뀌도록 구현
4. 상품 상세 page
   • 레이아웃
   • 수량 올리면 총 금액 바뀌도록 구현
   • 수량이 1이상이며 재고수량과 같거나 적을 때 장바구니, 바로구매 버튼 활성화
   • 재고수량보다 많을 시 버튼 비활성화 되면서 재고부족 글 보여줌
   • 장바구니 버튼 클릭 시 백엔드에게 해당 상품의 정보 보내줌 POST
   • 장바구니 버튼 클릭 시 장바구니에 추가되었다는 alert 창 보여줌
   • 바로구매 버튼 클릭 시 localStorage에 저장 후 구매 페이지로 넘어가서 정보 불러옴
   • 현재 상품의 카테고리에 맞는 추천 상품 리스트 보여줌
   • 상품정보/구매후기/상세정보 버튼에 따라 다른 UI 구현
   • useParams 사용해 상품 별 정보 바뀌는 정보 받아옴 GET
5. 404 page
   • 레이아웃
   • 라우터 통해서 404페이지에는 nav, footer 안보이도록 구현
6. Cart
   • 레이아웃
   • 결제하기 버튼 클릭 시 백엔드에게 데이터 보내줌 POST
   • 아이템 전제삭제 버튼 클릭 시 백엔드에게 수정 요청 PATCH
7. Order
   • 모든 입력창 입력해야 버튼 활성화
   • 결제수단 및 전체동의 체크박스 구현
   • 장바구니에서 결제창으로 오는 경우와 바로구매로 오는 경우에 따라 다른 정보 불러옴
     1. 장바구니 : 백엔드에게 장바구니에 있는 상품 목록 받아옴
     2. 바로구매 : localStorage에 있는 상품 정보 꺼내서 보여주고 결제버튼 누르면 삭제됨
   • 장바구니에 있던 물품 결제 시에는 구매 성공 모달 창 띄워줌

 

아래 링크를 통해 기술 관련 블로그로 들어갈 수 있다.

'오늘도 삽질 중/React.js' 카테고리의 글 목록

 

Project manager

1. trello를 통해 전체적인 프로젝트 진행률 파악 및 팀원들에게 업무 배분

• 모든 티켓들을 Backlog - To do - In Progress - Done 으로 나누어 업무
• 2주차의 딜레이 예상 후 1주차 티켓 배분
• 예상했던 진행률보다 늦어지는 팀원의 티켓 재배분
• 전체 티켓 완료 일시 예상 후 그 이후 일정 토의
• 1주 단위의 스플린트를 2차례 진행해 업무 흐름 파악

2. 개개인과의 잦은 소통으로 팀원의 요구사항 반영하려고 노력함

• 회의시간의 적절성 파악
• 원하는 업무의 유무
• blocker 유무 및 해결방법 논의

---

4. 추가로 더 해보고 싶은것

• 소셜로그인
• 외부 API 이용한 주소 조회
• point 차감 방식의 결제
• 로그인페이지에서 아이디 저장
• 장바구니에서 상품 선택삭제 기능

---

5. 프로젝트를 진행하며 느낀점

내가 생각한 개발자란

 이번 프로젝트를 통해 개발자의 이런저러한 면모를 많이 느낄 수 있었다. 특히 나는 간호학과 출신이라 과제를 안한다는건 말도 안된다고 생각해왔고 질이 조금 떨어지더라도 완성을 해야한다고 생각해왔는데 이번 프로젝트를 진행하면서 개발자의 프로젝트에는 완성이라는 것이 있을까? 완성의 의미가 무엇일까라는 생각이 많이 들었다. 나에게 첫 프로젝트의 완성은 flow 대로 기본적인 것들은 구현을 하자 였는데 프로젝트가 끝날 때 쯤부터 프/백 붙여보니 처음에는 생각 못 했지만 기본 구현인 것 같지만 또 너무 사소해서 추가 구현 같은 것들도 많이 보여서 어디까지가 기본구현이고 어디까지가 추가구현인지 선을 구별하기가 어려웠다. 나중에는 이번 프로젝트가 끝난다고 더이상의 추가구현을 안 하는 것도 아니었기 때문에 기한내에 구현한 곳 까지 제출을 하고 그 이후로는 리팩토링, 추가구현을 하면 되겠다고 생각하게 되었다.

 그리고 개발자에게 제일 중요한 것은 소통능력이라고 느꼈다. 먼저 프론트끼리도 소통이 중요하다고 느꼈다. 한번은 컴포넌트를 재사용 할 수 있도록 분리해두었는데 동기분은 파일을 존재조차 몰라서 추가로 컴포넌트를 만드셔서 시간을 소비한 적도 있었다. 또 기획 단계에서 컴포넌트를 미리 분리해서 만드려고 그림을 그려두었는데 공유를 했지만 공식문서화가 되지 않아 다르게 설계가 된 적도 있었다. 이 경험을 바탕으로 다음 프로젝트에서는 공유할 내용이 있으면 모두 문서화 해서 남겨두어야겠다고 생각했고 어떤 사소한 것이라도 같이 나누려고 해야겠다고 다짐했다.

 백엔드와 프론트와의 소통 또한 굉장히 중요하다고 느꼈다. 먼저 서로에게 요구사항이 있기 때문에 조금만 어긋나더라도 서로의 감정이 상할 수 있기 때문에 말을 예쁘게 해야했고 프론트-프론트보다 프론트-백엔드일 때 의견충돌이 많아서 그 상황을 지혜롭게 해결할 수 있어야했다. 먼저 최대한 효율적으로 소통하기 위해 우리는 api주소, heders, body 등 필요한 데이터들을 공식문서화 했다. 공식문서를 통해 백엔드는 대화의 오류를 줄이고 소통을 할 수 있었고 프론트 또한 더욱 편하게 작업을 할 수 있었다. 그리고 노션에 모든 미팅 로그를 남기고 기획 문서, ERD 등 서로 공유해야할 문서들을 등록해 두어 바로바로 확인하면서 작업을 할 수 있었던 것도 우리팀의 큰 장점이었다고 생각한다. 이렇게 소통을 하려고 노력했음에도 불구하고 우리는 이제 막 개발자를 시작한 사람들이라 프로젝트가 어떻게 굴러가는지, 어떤 정보를 받아와야하고, 서로는 어떤 일을 하고 있는지에 대한 지식이 부족해 여러번 부딫혔다. 자칫 잘못하면 감정이 크게 상할 수 있던 일도 서로가 프로젝트 하느라 잠도 못자고 예민하고 힘들겠거니하고 이해하며 넘어간 적도 있고 감정이 상했더라도 같이 밥먹으면서 잘 풀었던 것 같다. (이게 바로 한국인의 밥심인가?) 이번 프로젝트를 경험으로 삼아 다음 프로젝트에는 영양가있는 소통을 더 자주 해보려고 노력해야겠다.

 

첫 팀 프로젝트

 첫 프로젝트를 하면서 제일 자주 겪었던 어려움은 프론트가 2명이라 나눠서 작업을 해야한다는 것이었다. 위스타그램의 경우 혼자 모든 코드를 짜서 내 진도만 생각하면 되고 에러가 나더라도 내 코드라 금방 고칠 수 있었다. 프로젝트는 팀이라서 파트를 나눠 코드를 짜다보니 계속 conflict가 생기고 해결하고의 반복이었다. 그리고 혼자 짤 땐 모든 코드가 내가 짠 코드라 다 파악이 되어있었지만 다른 분이 짜둔 코드에서 내가 작업을 해야하는 상황에는 그 분의 코드를 다 파악한 뒤 그 위에 내 코드를 얹어야하는 것도 어렵게 다가왔다. 하지만 다른 사람의 코드를 리뷰하는 것도 재밌었고 같은 기능이지만 동기분과 나와의 코드가 다르거나 내가 모르는 방식으로 구현하는 경우에는 배워가는 것도 많았다. 특히 다른사람의 코드와 내 코드가 어우러져 하나의 프로젝트가 구현이 되었다는것이 너무 신기했고 혼자 진행했던 위스타그램보다  훨씬 더 뿌듯했다.

 

seoulminer에서 나는

 조마다 PM을 project manager와 product manager로 나눠 2명이 리더의 역할을 가져가야 했었다. 그 중 project manager를 맡게 되었고 이번 프로젝트 기간동안 전반적인 트렐로 티켓을 관리하게 되었다. 이번 우리 팀은 나 포함 프론트가 2명 백엔드가 3명으로 프론트 수가 모자란 조였는데도 불구하고 첫번째 주에 정해두었던 목표치를 모두 완료하고 2주차 티켓도 각자 하나씩 더 할 수 있었다. 백엔드 쪽은 다들 뛰어나는 실력을 가지고 있어서 ERD를 짜느라 수요일부터 티켓 배부를 시작했는데 금방 끝내고 다음 티켓 달라고 하셨고 추가구현도 많이 진행하실 수 있었다.

 하지만 2주차에 들어서면서 장바구니와 주문/결제 페이지가 나오면서 많은 딜레이가 생겼다. 프론트도, 백엔드도 2주차에 딜레이가 생길 것이라 예상하고 1주차에 다른 페이지의 티켓들을 미리 끝내뒀는데도 안해봤던 장바구니와 주문/결제 페이지는 많이 어렵게 다가왔던 것 같다. 특히 장바구니 파트가 http method 중 get, post patch, delete 가 들어가서 더욱 까다롭게 느껴졌던 것 같다. 내 티켓을 다 했지만 프로젝트는 협업이기 때문에 동기의 티켓을 가져와서 추가로 더 진행을 했었다. 동기와 함께 열심히 작업을 했지만 결국 장바구니의 patch와 개별삭제의 delete는 구현해내지 못해서 아쉬웠다. 왜 안됐었는지 이유를 찾고 추가로 더 작업을 해보아야겠다고 생각했다.

 

프로젝트를 끝마치며

  온보딩 기간부터 프로젝트 전까지 javascript, css, html, react, scss를 배우면서 위스타그램도 해보고 간단한 게임도 만들어보았지만 다 혼자 하는 것들이라 프론트와의 협업, 백엔드와의 협업은 경험해보지 못 했었다. 로그인, 회원가입 페이지를 제일 처음 구현하기 시작했던 나는 프로젝트의 시작과 동시에 백엔드와의 통신을 하게되었고 기존에 작업하던것보다 데이터의 양도 엄청 늘고 http method를 통해 데이터 요청도 해야했다. 매번 mock data만 쓰던 나는 처음 프로젝트를 할 때만 해도 백엔드와의 통신이 어렵게만 느껴졌는데 지금은 하면되지 라는 마음이 더 크다. 사실 아직까지는 쿼리스트링이나 useLocation 을 쓰고 하는 작업들이 처음 해보는 것들이라 너무 생소하고 어렵다. 하지만 이것 또한 하다보면 어느새 쉽게 느껴질 것이라고 생각한다. 처음 flex를 만나고 어려워했지만 지금은 정렬을 해야하는 상황이면 flex를 먼저 찾는 것 처럼 말이다. 회고록을 쭉 작성하면서 이번 프로젝트에서 가져가야할 점과 고쳐야할 점을 알 수 있게 되었으니 이걸 토대로 다음 프로젝트는 더더욱 퀄리티 좋고 팀원들과의 소통도 더욱더 원활하게 할 수 있도록 노력해야겠다.