[Project] 🪙데일리 옥션 최종 회고🪙

 

Links

원격 저장소 : https://github.com/dailyAuction/project_daily_auction

배포 링크 : http://dailyauction.site/

팀 노션 : https://www.notion.so/Daily-Auction-d180ab58cea74a9f9ad2592ba7a91db9

요구사항 정의서 : https://docs.google.com/spreadsheets/d/1eA0DrcsMQVfrVcueWP3xH4EueExcl0PKA2HXubzB63w/edit?usp=sharing 

API 문서 : https://docs.google.com/spreadsheets/d/1eA0DrcsMQVfrVcueWP3xH4EueExcl0PKA2HXubzB63w/edit?usp=sharing 

프로젝트 개요

2023.02월 부터 03월까지 약 6주간 진행한 사이드 프로젝트.

목표는 새로운 기술 학습 + 기존에 알고 있던 기술 심화 학습이었다.

실시간 통신 구현을 위해서 경매라는 서비스를 제공하는 사이트를 만들게 되었다.

역할

1. 초반 기획 때 회의를 진행하면서 효율적으로 소통하고자 노력했다.

2. 기술적으로는 웹소켓, SSE 등 실시간 기술 관련 파트를 맡았고, 차트 라이브러리를 도입했다.

3. 그 외에는 검색 기능, 검색 결과 리스트 페이지 등을 담당했다.

기술 스택

- Typescript : 지난 프로젝트에서 사용해봤는데, 다른 팀원분들은 사용해 본 적이 없다고 하셔서 공부하면서 같이 적용.

타입 시스템에 대해서 전보다 더 익숙해질 수 있었다.

- React : 지난 프로젝트에서는 Next.js 를 쓰면서 SSR을 적용했었는데, 이번에는 React 만 사용했다. 대신 Suspense 와 React.lazy 로 Code splitting 을 도입해서 성능을 최적화 하고자 했다.

- React-query : 이번 프로젝트에서 모두가 처음 써 본 그 라이브러리. 데이터 캐싱 및 서버 상태 별도로 관리하기 위해 도입했는데, 지난번 SWR 때도 느꼈지만 상태를 사용했을 때 별도의 동기화 처리가 필요 없다보니 그런 부분이 가볍고 편리하게 느껴졌다. SWR 과 차이점은 isLoading, isError 같은 상태를 자체적으로 제공해서 별도의 훅을 만들 필요가 없었다는 점? 그리고 캐시 데이터를 직접 추가하고 업데이트하는게 가능해서 실시간 통신과 함께 사용했을 때 상태값 관리에 편리함을 느꼈다.

- Recoil, TailwindCSS : 이건 기존에 사용해봤던 부분인데, 엄청나게 새롭게 뭔가를 더 적용하지는 않았다. 적어도 내 코드에서는... Recoil을 사용한 이유는, 원래는 Redux Toolkit을 적용하고 싶었는데 이 경우 Redux Toolkit 과 함께 사용할 수 있는 RTK Query 라는 미들웨어가 있어서 굳이 React-query를 사용할 필요가 없다고 느꼈기 때문에, react-query에 대한 경험치를 쌓고자 Redux 대신 Recoil을 선택했다. 또 TailwindCSS 같은 경우는 팀원들 모두 동의했고, 본인도 스타일 관련 라이브러리를 썼을 때 훨씬 속도가 빠르다고 생각했기 때문에.

기획 과정

지난 프로젝트에서 기획에 많은 시간을 쏟고도 그렇게 효율적이지 못했다는 생각이 들어서, 이번에는 뭔가 다같이 참여하면서도 시간을 많이 소요하지 않을 수 있는 방법에 대해 고민하게 되었다. 

 

나는 도메인만 결정된 상태에서 기획 단계부터 합류하게 되었는데, 도메인을 결정하면서 어떤 서비스, 어떤 페이지가 나와야 하는지 대략적으로 정리를 해두신게 있어서 거기서부터 출발했다. 참고한 레퍼런스가 있지만 그것과 100% 똑같이 만들게 아니기 때문에, 최소한으로 나와야 하는 MVP 를 결정한다는 생각으로 페이지별로 필요한 내용에 대해 시간을 정해두고 논의를 했다. 

위와 같이 각 페이지별로 필요한 내용에 대해서 서로 생각하는 바를 정리하고, 이를 취합해서 한 페이지에 어떤 컴포넌트, 어떤 데이터가 들어가야 할 지 논의를 했다. 

이 과정에서 초반에 생각하지 못했던 기능적 디테일이나 필요한 기능, 페이지에 대해서도 추가적으로 논의해서 뼈대를 만들었다.

 

그 뒤 피그마를 통해 와이어 프레임을 만들었는데, 이 과정도 그냥 백엔드 분들과 함께 만들었다. 아래와 같이 디테일은 생략된 대략적인 와이어 프레임을 만들었는데, 모바일 기반으로 만들게 되어서 UI 적으로는 조금 간단하게 만들었다. 

백엔드에서 ERD 설계를 진행하실 동안, 프론트에서는 화면 디자인을 구체화 하면서 프로토타입을 제작했다. 지난번 프로젝트와 마찬가지로 메인 컬러를 먼저 선정해서 이미지를 그린 다음 디테일에 들어갔고, 아래와 같은 컬러 Theme을 선정했다. 아무래도 경매, 입찰 뭐 이런 성격이기 때문에 경매장이 연상될 수 있는 컬러로 선정했다(고 생각한다..ㅎㅎ)

위와 같이 프로토타입을 만들면서 업무 분담을 진행했고, UI 를 만든 뒤 바로 개발에 들어갔다. 이번에는 많은 시간을 쏟을 수 없었기 때문에 페이지나 컴포넌트에 대해서 구체적으로 설계를 하고 시작했다기 보다는, 대략적인 설계를 해놓고 개발을 하면서 수정하는 방식으로 진행했다.

 

다만 진행을 하면서 유저가 가질 수 있는 여러가지 상태와 그와 연관되어 변경되어야 하는 데이터에 대해 (너무 헷갈려서) 아래 처럼 정리를 하면서 진행하긴 했다.

개발 협업 과정

시작하기에 앞서서 프론트 쪽에서는 어떤 기능을 어떤 기술을 써서 구현할건지 결정하고, 컨벤션과 개발 협업시에 필요한 내용을 논의하면서 프로젝트를 셋팅했다.

업무를 분담한 뒤에 진행하면서, 매일 어떤 일을 할 것인지, 또 오늘 어떤 일을 했는지, 논의할 내용이 있는지 대화하는 스크럼 시간을 작업 전후로 15분 정도 가졌다. 각자 업무에 대한 태스크는 깃 이슈로 자유롭게 관리했고, 나름대로 코드 퀄리티를 관리하기 위해 pr 시에 코드 리뷰를 열심히 했다. 

사실 다른 사람의 코드를 읽고 이해하는게 한 번에 될 만큼 쉽지는 않았는데, 다양하게 자주 소통하면서 서로 궁금한 점에 대해서도 묻고 답하고, 더 좋은 방법이 무엇이 있을까 고민하면서 함께 성장할 수 있었다고 생각한다. 이번에 프로젝트를 얼추 마무리 하고, 서로 구현했던 기능에 대해 설명하는 시간도 갖기로 했다. 

 

협업 이외에 개인적인 작업 과정은, 매일 작업 내용을 기록한 아래의 리스트에서 확인할 수 있다.

'프로젝트/데일리 옥션' 카테고리의 글 목록

동료 피드백

프로젝트 마무리 후 구글 폼을 만들어 동료 설문을 진행했다. 서로 강점에 대한 키워드를 뽑고 성장을 위한 피드백을 주고받았다. 나같은 경우 소통에 대한 긍정적인 면과 아쉬운 점이 두드러지는 것 같다. 이번 프로젝트에서는 동료들과의 소통도, 코딩도 어떻게 하면 효율적으로 할 수 있을까 고민을 많이 했는데 그런 고민과 행동이 유효하게 적용된 것 같아 다행이다.

 

배운 점

1. 문서화는 효율적인 소통을 돕는다.

초반에 요구사항 정의서와  api 명세서를 엑셀로 깔끔하게 작성해주셔서 백엔드 파트와 논의를 하는데 정말 원활했다. 예를 들면 api 명세서 어떤 엔드포인트에 어떤 부분에 궁금증이 있다- 고 전달하면 그게 어떤 내용인지, 무엇에 대한 논의가 이루어져야할지 빠르게 파악할 수 있었다. 초반에 아무리 수정될 여지가 있다 하더라도, 만들어둔 기본 뼈대가 있으면, 문서화가 수고로울지라도 그 뒤에 이어질 소통적 측면에서 훨씬 더 이득이 있는 것 같다.

 

2. 적당한 토크는 새로운 해결 방법을 떠오르게 한다.

지난 프로젝트에서 함께 문제에 대해 논의할 팀원이 부재한 상황이 많았다보니, 이번 프로젝트에서 이런 부분에 대해 함께 논의할 팀원들이 있다는게 무척 좋았다. 그래서 꼭 프로젝트 관련 이야기가 아니더라도 여러 이야기를 하면서 즐겁게 작업을 했던 것 같다. 너무 자주 실시간으로 얘기를 했던탓인지 에러에 대해 논의하기 전에 먼저 시간을 정했으면 좋겠다라는 피드백도 있었지만. 뭔가 문제에 대해서 다른 사람에게 설명을 할 때, 문제를 정의하고 또 다시 접근하면서 원인에 대해 스스로도 파악할 수 있었고, 팀원이 겪고 있는 문제에 대해서도 함께 생각해보면서 다른 개발자가 작성한 코드에도 좀 더 익숙해질 수 있었던 것 같다. 뭔가 좀 아쉬운 점은 내가 TMI 를 너무 남발했나? 이런 생각도 들고 ㅋㅋ 좀 자제해야하는데. 

 

3. 모듈화, 추상화, 관심사분리

이전 프로젝트부터 조금씩 신경썼던 부분인데, 이번에는 초반부터 이런 부분에 주의하면서 가독성 좋고 수정하기 용이한 코드를 만들려고 노력했다. 로직같은 경우는 최대한 훅으로 분리하려고 노력했고, 그 결과 내가 만든 커스텀 훅을 다른 분이 쓰시고 또 에러가 있을 때 직접 수정도 원활하게 하실 수 있었다. api 로직도 최대한 분리해서 메서드 형태로 분리했는데, 100% 깔끔하다는 느낌은 잘 모르겠지만, 어쨌든 역시 재사용성이 높고 특히 api를 호출하는 부분에서 좀 더 간단하고 명시적으로 접근할 수 있어서 좋았다.

 

4. 문제를 구체화하고 해결 방안을 찾고 끝까지 파고들기

이번에 함께한 팀원분들은 문제가 발생했을 때 끝까지 원인을 파고들고 해결하려는 모습을 많이 보여주신 것 같다. 솔직히 지난 프로젝트에서 혼자 끙끙대면서 끌어갔던 부분들이 많아서 이번 팀원들을 만났을 때 약간 감격스러웠고 그 덕에 나도 더 분발하게 되었던 것 같다. 문제가 발생했을 때, 어떤 기능을 구현해야 할 때 이번에는 깃 이슈를 적극적으로 활용해서 이를 위해 어떤 것을 알아야 하고 어떤 부분을 수정해야하고 또 어떤 부가적인 문제가 발생할 수 있는지 정리하고 작업을 시작했는데 효율적으로 작업하고 또 작업 단위가 세분화되어서 스스로 집중하는데에도 큰 도움이 되었던 것 같다.

 

다만 아쉬운 점은 여러 예외 상황에 대해 처리를 제대로 하지 않아서 배포 이후에 문제가 된 부분이 있었는데, 이걸 설계 단계에서 좀 더 꼼꼼하게 파악했더라면 좋았겠다. 에러처리나 예외상황에 대한 처리가 좀 미흡하다는 생각이 스스로 든다. 

마무리

이번 프로젝트를 하면서 좀 더 효율적인 소통, 효율적인 작업에 초점을 많이 맞췄다. 그 이유는 취준과 병행하면서 정해진 기간 내에 개발을 마무리 했어야 하기 때문에. 비록 일주일 정도 오버가 되긴 했지만, 나름 개발 일정을 관리하면서 하루 5시간이라는 짧은 시간을 투자해서 마무리 할 수 있었다. 

 

앞으로는 미처 해결하지 못한 에러를 매일 조금씩 해결하면서 완성도를 높여갈 생각이다. 끝~