Wecode 2차 프로젝트 회고록

 

 

프로젝트 소개

 

 

Kream 쇼핑몰을 모델링으로 한 예술품 경매 사이트

Wecode에서 2차로 진행한 프로젝트 사이트는 Kream으로 결정했다. 우리 팀은 웹 사이트를 똑같이 클론하는 클론코딩을 하고 싶지 않았다. 팀원들의 의견을 종합해 Kream에서 특별한 소재(?)가 무엇이고 어떤것으로 우리가 다른 기획방향으로 소재를 녹여낼 수 있을까에 대한 회의를 가장 많이 했었던 것 같다. 물론 비슷하게 따라 만드는 것은 기획도 크게 필요없고 비슷하게 구현한 하면 되니 더욱 쉽겠지만, 내가 개발공부를 기획의 부분도 회사에 입사하게 되었을 때, 이해해야 할 부분이라고 생각했다. 백엔드 팀원 2명과 프론트 팀원 1명 그리고 나까지 4명이서 기획을 시작했다. 

우리는 Kream의 경매라는 시스템과 한정판아이템이라는 것이 독특한 아이덴티티들이라고 생각했고, 이를 중심으로 독창적인 기획을 어떻게 만들어 낼지에 대해 생각했다. 나는 팀원들과 회의에서 본인의 작품을 경매로 등록할 수 있는 플랫폼은 어떤가에 대해 팀원들에게 의견을 구했고, 팀원들의 긍정적인 답변으로 기획을 보다 구체화시켰다. 

 

 

우리팀은 국내 화가들이 참여할 수 있는 미술품 경매 플랫폼을 만들기로 결정했다. 다른 플랫폼들과 차별점이 필요하다고 생각하여, 우리는 '국내 화가'로 범위를 정했고, 스스로 자신의 작품을 등록할 수 있도록 자율성을 부여하기로 했다. 우리는 이 플랫폼으로 국내화가들이 자신의 가치를 높이고, 일반인들에게는 보다 미술품에 대한 접근을 보편적으로 넓히기 위한 목적으로 서비스를 개발하자고 의견을 모았다.

 

 

개발기간

• 2023.3.2 ~ 2023.4.5 (10일)

 

기획기간

• 2023.3.27 ~ 2023.3.29 (3일)

 

팀 구성

• 백엔드 2명
• 프론트엔드 2명

 

기술스택

• Frontend
  • Javascript
  • React
  • Styled-Components

 

구현기능

• 카카오API 소셜로그인
• 카카오API 배송지기능
• 카카오API QR결제기능
• 검색 & 필터링기능
• 상품리스트 무한스크롤
• WebSocket 실시간 입찰기능
• 위시리스트 상품보관
• 마이페이지에서 낙찰된 상품 구매
• 입찰자의 비매너를 방지하기 위한 동의서작성
• 경매물품 등록기능

 

 

프로젝트 진행과정

 

 

화이트 보드에 이어 Figma를 활용한 기획

화이트 보드를 이용해 기획회의를 한 장면

먼저 빠르게 회의를 하기 위해 화이트 보드로 치열하게 페이지를 기획하기 시작했다. 사용자에게 필요한 부분이 어느부분인지, 사용자 플로우가 자연스러운지, 자연스러운 기능 배치가 가능한지 프론트엔드로서 많은 고민을 했었다. 내가 사용자라면(?)라는 생각으로 사용자가 집중 할 수 있는 작품리스트 부분들은 한 페이지에 한 작품만이 뚜렷하게 보이도록 구현하기로 결정했다. 나이키 홈페이지처럼 물건을 비교하는 것이 아니라 사용자가 웹에서 작품을 감상할 수 있었으면 좋겠다는 생각에 의견을 표출했고, 팀원의 긍정적인 동의로 합을 맞췄다.

 

 

나는 피그마를 한 번도 사용해본 적이 없지만 꼭 필요할 것 같아 속성으로 배우기 시작했다. 다른 팀원들 중에 피그마를 사용해서 회의를 하는 모습이 부러웠다. 다른 팀원은 피그마를 이용해서 디자인을 했던 경험이 있었다. 우리팀이 화이트보드에 기획한 내용을 사진으로 공유했지만, 피그마처럼 디테일한 부분을 헷갈리지 않도록 표시하고 싶었다. 당장 개발에 들어가는 것 보다 팀의 방향이 확실하게 일원화되어야 한다고 생각해 피그마작성이 꼭 필요하다고 생각해 피그마를 배우기 시작했다.

완성하고 나서 보니 우리가 작업해야 할 방향, 추가구현으로 회의했었던 부분, 우선적으로 작업을 처리해야 할 것들이 뚜렷하게 보이기 시작했다. 피그마를 작성하기에 당장 코드를 치고있는 옆 팀원을 보며 마음을 졸이기도 했다. 그러나 백엔드와 프론트엔드가 불협화음으로 기획이 꼬이는 것 보다 한 발짝 늦더라도 함께 나아가는것이 중요하다고 생각했다.

 

 

Planning Meeting

우리는 Planning Meeting을 총 2번 가지기로 결정했다.

 

우리팀은 Trello로 협업툴을 정했고, 크게 Backlog/ To-Do (이주 스프린트)/ In Progress/ In Review (PR)로 정했다. 프론트엔드 팀원과 백엔드 팀원이 서로 작업이 얼마나 진행되는지 쉽게 보여주기 위해 되도록 프론트적 단어를 제외하고 기능위주로 풀어서 티켓을 작성했다.

 

우리팀은 회의를 통해 현실적으로 구현가능한 최소사항 그리고 우선사항 티켓들을 먼저 만들었다. 이후 매 주 Planning Meeting에서 진행과정을 공유하고 커뮤니케이션을 통해 추가구현이 가능한 부분을 상의해서 가능하다면 구현하고 물리적으로 시간상 불가능할 것 같다면 과감하게 티켓을 옮기지 않기로 했다.

 

 

Daily Stand-Up Meeting

우리팀은 매일 각자의 작업내용과 현황을 공유하고 어떻게 진행되어 가는지, 현재 막힌부분이나 힘들었던 부분, 도움이 될 수 있는 내용들을 공유하였다. 서로 속도를 맞춰가며 기능구현을 위해서 Daily Stand-Up Meeting을 제외하고도 중간중간 회의를 진행하기도 했다. Daily Stand-Up Meeting의 회의록은 내가 작성했고, 필요한 부분이나 내용이 있다면 다음날 팀원들에게 상기시켜 회의를 이어나가기도 했다.

 

 

 

프로젝트를 통해 얻게 된 부분

 

 

협업의 중요성과 팀원들과의 커뮤니케이션

프로젝트를 진행하면서 프론트 팀원과의 회의보다 기능을 구현하기 위한 백엔드 팀원과의 커뮤니케이션이 훨씬 잦았던 것 같다. 프론트 팀원과는 각자의 맡은 역할에 충실하게 작업하면서, 막히는 부분이나 힘든 부분에서 서로 공유하며 커뮤니케이션을 했었다. 백엔드 팀원과는 데이터의 구조나 데이터가 전송되는 코드들에 대해서 커뮤니케이션을 많이 했었다. 그 과정에서 에러를 마주했을 때, 서로 누구의 탓도 하지 않고 자신이 할 수 있는 최선을 다하며 에러를 해결하려 노력했다. 

기억나는 백엔드 팀원과 커뮤니케이션은 카카오QR API를 구현할 때이다.

  const handleOrderSubmit = () => {
    fetch(API.KAKAOPAY, {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json; charset=utf-8',
        Authorization: localStorage.getItem('login-token'),
      },
      body: JSON.stringify(addressData),
    })
      .then(res => res.json())
      .then(data => {
        window.open(data.data);
      });
    navigate('/mypage');
  };

결제를 구현하는 코드에서 Token 없이 구현할 때는 정상적으로 잘 구현이 됐다. 그러나 Header에 Token을 넣으니 redirect가 되지 않았다. 이전에 작성한 하단부분 navigate('/mypage')가 작동하지 않았다. 백엔드 팀원과 서로의 코드를 보며 에러핸들링을 하기 위해 6시간을 투자했었다.

많은 고민과 소통 끝에 백엔드 팀원의 코드에 redirect를 작성하여 에러를 해결할 수 있었다.

 

협업이라는 것을 1차 프로젝트에 이어 두 번째로 경험하게 되었다. 팀원들은 다들 배려심이 높았고, 문제가 생겼을 때 적극적인 소통으로 문제를 해결해나갔다. 좋은 팀원들을 만나서 프로젝트 기간 동안 즐거웠고, 백엔드 팀원과의 대화에서 백엔드의 고충은 어떤 부분인지, 해결할 수 있는 부분과 없는 부분을 좀 더 배우게 되었던 것 같다.

 

 

프로젝트 중 아쉬웠던 점

 

 

우리팀은 다른 팀에 비해 프론트인원이 1명 적었다. 그에 비해 백엔드 팀원들은 월등하게 잘 하는 분들이었고, Styled-Components를 처음 사용해보며 익숙해지기까지 시간이 꽤나 걸렸었다. 원래 기획했던 부분에서 추가적으로 구현하고 싶었던 기능들이 많았었는데, 프로젝트 기간 내에 구현하지 못해서 아쉬웠다. 

 

급하게 기능들을 구현하다 보니 코드를 깔끔하게 작성하지 못 했다고 생각했다. 어느 블로그 글에서 개발부채 라는 단어를 처음 보고 흥미있게 읽었던 기억이 있다. 기능 구현을 위해 아무렇게나 코드를 작성하게 된다면 결국 나중엔 리팩토링을 위해 이자가 붙어 부채로 돌아온다는 말이었다. 처음 개발할 때 클린하게 코드를 작성하면 좋겠지만, 아직은 이게 좋은 코드인지 잘 모를때가 많아 멘토님들께 여쭙곤 한다. 그러나 리팩토링을 통해 코드를 개선하겠지만, 내가 코드를 작성하면서 개발부채라는 단어를 생각하며 아무렇게나 작성하지 않게 된게 중요하다고 생각했다. 이후 항상 한 줄을 작성하더라도 고민하던 계기가 되었던 것 같다.

 

 

내가 구현한 기능

 

 

• 카카오페이 QR결제기능

 

 

• 카카오주소 라이브러리 적용
• 주문정보 입력 및 결제플로우

 

• 판매자의 작품등록 기능 구현

 

 

• 입찰내역을 데이터를 받아 마이페이지에서 구현

 

 

프로젝트를 마무리하며

 

누구보다 치열하게 코드를 쳤었던 기억이 있다. 마지막 Waka-time을 보니 뿌듯했었다. 팀원들의 실력이 뛰어나 커뮤니케이션에서 부터 회의까지 코드적인부분 뿐만 아니라 소통하는 방법도 많이 배웠다. 어느 블로그 글에서 나는 같이 일하고 싶은 개발자인가? 라는 글을 감명깊에 읽었었다. 프로젝트를 끝내고 되돌아보면서 나는 같이 일하고 싶은 개발자인지 스스로 되돌아보았다. 동료들의 칭찬과 수고했다고 진심으로 반겨주는 팀원들을 보고, 그런 고민에서 나는 충분히 같이 일하고 싶은 개발자로 성장할 수 있겠다고 생각했다. 다른 팀과 비교했을 때, 우리팀의 분위기가 제일 좋은 편이었다.(그렇다고 다른 팀의 분위기가 안 좋았던 것은 아니지만) 

서로 체력적으로도 많이 힘들었고, 함께 에러를 해결하려 밤새고 고민했던 기억에 뭉클하기도 하다. 그러나 결과물이 만족스럽게 배포되어서 그 동안 고생했던 부분들을 보상받는 기분이었다.

우리 팀원들 그리고 동기들 모두 여기서 각자 취업준비를 하러 나가게 되어서 섭섭하지만, 누구보다 열심히 했던 우리 동기들과 우리 Wevre팀원들을 항상 응원해요!!1