2차 프로젝트 회고 👟SREAM

리졔·2023년 9월 11일

회고록

목록 보기

1/1

1. 프로젝트 소개

한정판을 좋아하는 Z세대들에게 활발한 소비 및 투자로 리셀 스니커즈 시장을 확대하는 서비스를 기획
리셀이라는 새로운 소비 트렌드를 캐치한 한정판 스니커즈 거래 중개 서비스
단순한 중개에서 벗어나 패션을 즐기는 고객들이 입찰 문화를 통해 소통할 수 있는 플랫폼
구매자와 판매자가 모두 플랫폼을 이용 가능
회원가입/로그인/로그아웃, 메인페이지, 상세페이지, 입찰과 즉시체결, 결제페이지 등의 기능을 구현

제작하기 앞서 타 사이트를 벤치마킹하여 Product 분석을 먼저 진행했습니다.

👉 PET분석 및 구현기능 선정 노션링크!!!

⏰ 개발 기간

23.08.21 ~ 23.09.01

🧑‍💻 멤버 구성

FrontEnd : 이지혜, 전미혜
BackEnd : 홍지수, 양지은, 김민수, 최지준

⚙️ 기술 스택

FrontEnd : Javacript, React, SCSS
Back-End : Javascript, mysql, node.js
CommonTools : github, slack, trello, notion

📌 담당 파트

① 사이즈선택

원하는 상품을 클릭하면 사이즈를 선택하는 화면으로 이동 하며 동적 라우팅으로 상품 정보를 불러옴
사이즈를 선택하면 아래의 버튼 활성화
: 구매/판매 시, 사용자가 사이즈를 선택 후 다음 페이지로 넘어가기 때문에 이후에 사이즈 재선택을 요구하는 불필요한 과정을 축소
쿼리스트링을 이용하여 선택한 데이터를 다음 페이지(즉시/입찰)로 전달하여 통신 과정을 줄임

② 즉시구매/즉시판매

해당 상품의 사이즈를 선택하면, 제품의 판매 입찰과 즉시 판매 컴포넌트를 토글로 구현
: 처음 받아온 데이터를 토글에 따라 다르게 출력
즉시구매/즉시 판매에서 서버에서 받아온 상품데이터의 가격을 저장하여 즉시구매하기 버튼을 누를 때 페이지 이동과 함께 가격데이터를 전송

③ 구매입찰/판매입찰

즉시구매/즉시판매와는 다르게 구매입찰/판매입찰에서는 유저가 직접 입력한 금액을 입력

입찰하기 버튼을 누를 때 페이지 이동과 함께 가격데이터를 전송
입찰 마감기한을 선택하면, 날짜가 자동계산되어 출력

④ 결제페이지

결제 페이지에서 사용자가 선택한 상품데이터를 불러옴

보유 포인트로 결제 가능
: 토큰으로 고객 정보를 확인, 해당 고객이 보유한 포인트를 사용하여 결제
구매/판매에 필요한 결제 금액을 표시하고 내가 입력한 포인트를 실시간으로 출력
: 포인트와 상품 또는 배송비의 총액이 일치하는지를 확인 가능
보유 포인트가 입력 포인트보다 클 경우 경고메시지 출력
: 보유한 포인트 내에서 올바른 입력을 유도

입력 금액과 결제가 필요한 총액이 일치할 경우 결제 버튼 활성화
: 불일치 시 다음 과정으로 넘어가면서 결제 재선택을 요구하는 불필요한 과정을 축소
결제된 금액(포인트)를 서버로 전달하여 사용한 포인트를 보유 포인트에서 차감

2. 프로젝트 진행

2-1. Daily Stand-UP meeting

우리는 매일매일 프론트와 백엔드 간의 미팅을 진행했다. Trello를 활용하여 각 포지션별 현재 진행사항을 공유했고, 같은 기능을 구현하고 있는 프-백 간의 팀원들끼리도 속도를 맞춰가면서 기능을 완성해나갔다. 이 과정 덕분에 각 페이지에서 백엔드와 프론트간의 진행의 불균형이 생기지 않았다! 이해되지 않거나 수정된 사항도 즉각 반영할 수 있어서 좋았고 무엇보다 정해진 시간에 다들 참여하여 열정적으로 하다보니 어느새 완성되어있었다.👏🏻👏🏻👏🏻

2-2. FE-BE의 소통

아무래도 핵심기능이 경매였는데 모두 처음해보는 형태다 보니 고민이 많았다.
그래서 프로젝트 초반에 백엔드 팀원분들이 ERD와 초기세팅을 하는데 시간을 쏟으시는 동안에, 프론트가 어느정도 레이아웃을 먼저 하고 있는 상태였다. 그래서 프론트가 목데이터를 먼저 작성했는데 지금 생각해보면 그걸 노션에 정리해서 공유했으면 백엔드 분들이 참고해서 데이터를 만들기에 더 효율적이었을 것 같다는 생각이 든다. 💭

그래도 다행인 점은, 미팅 후 한 공간에 모여서 진행했기 때문에 그때그때 필요한 정보를 공유할 수 있었다는 점이다. 만약 그게 아니었다면 데이터 형태 수정으로 시간을 더 많이 소요하지 않았을까 하는 생각이 든다.
그리고 늘 미팅에 늦지 않게 참석하고, 같은 공간에서 진행하기 위해 모여준 팀원들에게 감사하다.✨

2-3. 협업하는 태도

프로젝트 시작하기에 앞서 백엔드 분들이 먼저 어떤 식으로 데이터를 저장하고 넘겨줄 건지 흐름같은 것을 설명해주셔서 필요한 정보들에 대해 사전 협의를 하고 진행했는데도 중간에 수정사항이 생기는 건 어쩔 수 없었다.
프로젝트를 진행하면서 프론트끼리의 교류도 물론 있었지만, 같은 기능을 담당하고 있는 백엔드와 교류가 훨씬 많았다! 데이터를 어떤 형태로 받을 수 있는지, 어떻게 요청해야 하는지, 나는 어떤 정보들을 보내줘야 하는지 등 맞춰야 할 것들이 한두 가지가 아니었다.
그리고 이 과정에서 프론트가 좀 더 일처리를 해야 할 때도, 아니면 백엔드에서 더 무언가의 과정을 처리해야만 진행이 될 때도 있었다. 아직 우리는 각자의 역할만 알기 때문에 서로가 어떻게 이 일들을 처리하는지 알 수가 없었다. 그래서 내가 이런 이런 부분을 요청할 때에도 이게 간단하게 해줄 수 있는 일인지 , 대공사가 생기는 일인지 알 수가 없었다. 그래서 모든 요청들이 조심스러웠던 것 같다.
그래서 최대한 프론트 팀원과도 상의후에 백엔드 팀원분께 부탁드렸는데, 최대한!!! 정말 최대한으로 맞춰주려고 노력하셨다. 그래서 너무 감사했다...!😭
그리고 백엔드에서 프론트로 수정사항을 부탁하실 때도 아주 조심스럽게 물어봐주시는 게 느껴져서 서로 각자의 영역을 존중하고 배려하는 우리 팀이 너무 좋았다.ㅎㅎㅎ

2-4. 기억에 남는 코드

<Routes>
          <Route path="/" element={<Main />} />
          <Route path="/login" element={<Login />} />
          <Route path="/sign-up" element={<SignUp />} />
          <Route path="/product-list" element={<ProductList />} />
          <Route
            path="/product-detail/:productId"
            element={<ProductDetail />}
          />
          <Route path="/bookmark" element={<Bookmark />} />
          <Route
            path="/purchase-size/:productId"
            element={<SizeSelect isPurchaseSize={true} />}
          />
          <Route path="/sell-size/:productId" element={<SizeSelect />} />
          <Route
            path="/purchase-option/:requestSize"
            element={<PurchaseOption />}
          />
          <Route path="/sell-option/:requestSize" element={<SellOption />} />
          <Route path="/size-select/:productId" element={<SizeSelect />} />
          <Route path="/payment/:productId" element={<Payment />} />
        </Routes>

입찰과 즉시거래를 토글 버튼으로 분리하여 데이터를 보여줘야 하는데, 그 과정에서 데이터를 동작 라우트 매개변수로 사용해 본게 처음이어서 신기했다.
일반적으로 쿼리 파라미터는 URL 뒷부분에 ?를 붙이고 key=value 형식으로 데이터를 전달하는데, 이러한 방식은 다양한 쿼리 파라미터를 사용하여 필요한 정보를 전달할 수 있지만, 경로에 포함된 정보가 아니라 URL의 일부로써 데이터를 전달한다.
반면에 동적 라우트 매개변수는 URL 경로 자체에 변수를 포함시키기 때문에, 경로의 구조 자체가 데이터를 나타내므로 데이터가 더 직관적으로 URL에 표현된다.
동적 라우트 매개변수를 사용하는 것은 주로 RESTful API 디자인과 관련이 있고 제품 상세 페이지와 같은 단일 리소스에 대한 정보를 전달할 때에는 동적 라우트 매개변수를 사용하는 것이 일반적이라고 한다.

3. 프로젝트를 마치며,,,

잘한 점
팀원들간의 소통에 신경을 많이 썼다는 점이다. 아무래도 프론트와 백엔드가 협업하는 처음 프로젝트다 보니 미숙한 점도 물론 있었지만, 매일 스탠드업 미팅을 하며 서로 의견을 맞추고, 티켓을 조율하면서 시간 안에 완성하도록 모두 노력했다는 점이다.

아쉬운 점
일단 기능을 구현해야겠다는 생각에 코드의 재활용성이나 컴포넌트의 분리에 신경을 많이 쓰지 못한 것 같다. 기능은 돌아갔지만 구매와 판매가 비슷한 로직을 사용하는데 그런 부분을 고려하지 못한 게 아쉬웠다. 다음 프로젝트에는 좀 더 신경쓰며 코드를 작성해야겠다고 생각했다.

내가 모르는 부분을 같이 찾아봐주고 고민해주면서 챗지피티에 의존하지 않도록 도와줘서 너무 고마워여!!!!!!🥹
우리 팀 모두 너무 고생많았고, 마지막 날까지 서로 배려하면서 프로젝트 마무리 할 수 있어서 너무 좋았어요❣️❣️

리졔